[13:47:53] --- tga73 has joined
[13:48:02] --- tga73 has left
[13:51:29] --- slavitch has joined
[13:52:14] --- frodek has joined
[13:55:44] <slavitch> Are people setting up yet?
[13:58:18] --- tskj has joined
[13:58:29] <frodek> yes. But start soon now
[14:00:53] --- cullenfluffyjennings@gmail.com has joined
[14:04:06] --- gas has joined
[14:04:15] --- hardie@jabber.psg.com has joined
[14:04:15] --- tianlinyi has joined
[14:04:25] --- miki has joined
[14:04:54] --- spencerdawkins has joined
[14:05:05] <frodek> there seems to be no one willing to act as a jabber scribe
[14:05:15] <hardie@jabber.psg.com> sigh
[14:05:36] --- plivesey has joined
[14:06:07] <cullenfluffyjennings@gmail.com> If anyone is in the room that can scribe, that would be great.
[14:06:23] <cullenfluffyjennings@gmail.com> I will try and watch and if there are questions, I can ask them
[14:07:59] --- tga73 has joined
[14:08:06] --- LouBerger has joined
[14:09:10] --- bew has joined
[14:09:36] --- m_7777 has joined
[14:09:57] <spencerdawkins> can we use interims to scan through new drafts?
[14:10:23] --- rohan has joined
[14:10:40] <rohan> i
[14:10:49] <rohan> i will scripe for a little while
[14:11:08] <spencerdawkins> thnks!
[14:11:35] <rohan> a lot of drafts have progressed to RFC ed (5 since IETF64) and Pub Requested
[14:11:38] --- tfroment has joined
[14:11:43] <rohan> we should be able to start some new work
[14:12:08] <rohan> chairs are presenting a single slide on several drafts
[14:12:14] <rohan> requirements for file transfer
[14:12:37] <rohan> and file transfer mech are being mentioned
[14:13:06] <rohan> file xfer mech presented in mmusic describes how to describe a file transfer using the offer/answer model
[14:13:25] <rohan> conclusion in mmusic was to check that this is ok in sipping, then proceed in mmusic
[14:13:46] <tfroment> status slides: http://www3.ietf.org/proceedings/06mar/slides/sipping-0.ppt
[14:14:48] <rohan> requirements question from cullen is do i need to agree during INVITE if its ok to get a file for gonzalo, or is it ok to accept a file transfer then reject actual file in first MSRP message
[14:15:00] <rohan> dean asked about billing, gonzalo said its completely orthogonal
[14:15:13] <rohan> no objection to proceed in mmusic
[14:15:19] --- jason.fischl has joined
[14:15:28] <rohan> race conditions drafts now
[14:15:56] <rohan> paul k thinks it is good to have this written down
[14:16:24] <rohan> does this help as written?
[14:16:41] <rohan> dean wants this published either as WG item or AD-sponsored individual
[14:16:53] <rohan> hum
[14:17:14] <rohan> failrly strong hum in favor, no objections
[14:17:33] <rohan> now discussing multiple transcoding draft
[14:17:38] <hardie@jabber.psg.com> I think it would be useful to look at interactions with ICE
[14:17:45] <rohan> draft-kang-sipping-transc-sceanrio
[14:17:49] <hardie@jabber.psg.com> (oops, that was for race condition draft, but I'll send mail to author)
[14:17:50] --- ft has joined
[14:17:54] --- bhoeneis has joined
[14:18:00] --- Alan H has joined
[14:18:01] <rohan> gonzalo asked pls read
[14:18:57] <rohan> asked ted's question
[14:19:18] <rohan> will be discussed in mmusic, but gonzalo thinks no conflict with ice
[14:19:31] <rohan> now config-framework
[14:19:59] --- jr111 has joined
[14:20:29] <rohan> changes: nits/edits, fixed certificate usage, split xcap stuff out
[14:20:44] --- Alan H has left
[14:21:01] <rohan> http://scm.sipfoundry.org/rep/ietf-drafts/sipping/config-framework/draft-ietf-sipping-xcap-config-00.txt
[14:21:10] <rohan> is location for separate draft with xcap stuff
[14:21:22] <rohan> issues are all with xcap draft
[14:21:36] <rohan> how does device know if config server supports xcap?
[14:21:50] <rohan> (how specific a path can go in the 'document' parameter
[14:22:01] <rohan> 3 options
[14:22:22] <rohan> 1. reject subscription if it has document or auid parameter that is not supported
[14:22:32] <rohan> 2. macke xcap mandatory on all config servers
[14:22:53] <rohan> 3. config server delivers the smallest content it can
[14:23:32] <rohan> JDR: is it problem we have no mechanism to negotiation Event header params?
[14:23:50] <rohan> he does not like 3
[14:24:18] <rohan> what if you ask and there is no xcap server
[14:24:45] <rohan> jdr suggests reject (1) in generic way
[14:24:51] --- shidaschubert has joined
[14:25:03] <rohan> he wants reason in error
[14:25:04] --- Alan H has joined
[14:26:46] <rohan> rohan: no harm comes if server ignores
[14:26:59] <rohan> JDR: would like this to be explicit
[14:27:30] --- mnvakil has joined
[14:27:33] <rohan> hisham: could it be an XCAP server that does not want to provide profile at that granularity, or otherwise did not like path
[14:27:47] <rohan> jdr: several cases
[14:28:04] <rohan> doesn't support XCAP at all
[14:28:08] <rohan> doesn't support auid
[14:28:14] <rohan> path does not exist
[14:28:15] <rohan> etc..
[14:28:29] <rohan> jdr thinks best thing is just reject request
[14:29:12] <rohan> rohan: 3265 says you ignore params you don't understand
[14:29:30] <rohan> jdr: use option-tag
[14:31:03] --- dwillis has joined
[14:31:20] --- joshlitt has joined
[14:31:23] --- dwillis has left: Logged out
[14:32:05] --- slavitch has left
[14:32:17] <rohan> jdr and rohan discussed motivation for splitting the doc
[14:32:56] <rohan> JDR: was it *really* necessary to remove dependency on XCAP when it is already in WGLC. we've done worse
[14:33:30] <rohan> rohan: was doing proto writeup and came up with the dependency as an issue
[14:33:50] <rohan> gonzalo: was this a requirement when we added config-framwork as a milestone
[14:34:10] <rohan> dan: no (but this was added later when xcap-package was merged in)
[14:34:22] --- dwillis has joined
[14:34:28] <rohan> paul k: might be bad to try twice. maybe using 3.
[14:34:53] <spencerdawkins> who is speaking?
[14:34:54] <rohan> aki: suggest just probing with option-tag
[14:35:00] <spencerdawkins> thnks
[14:35:01] <rohan> aki niemi just spoke
[14:35:34] <rohan> dan: maybe xcap should have been a separate uir
[14:36:02] <rohan> jdr: one of his hot buttons. xcap is not broken. this package has optional components that we can't signal
[14:36:11] <dwillis> on with gaim on nokia 77O.
[14:36:22] <rohan> <scary>
[14:36:48] --- jjmbcom has joined
[14:37:37] --- tfroment has left
[14:37:55] --- slavitch has joined
[14:38:37] <cullenfluffyjennings@gmail.com> we have stggrong consensus that xcap should not be madetory
[14:38:39] <rohan> poll: should xcap be mandatory?
[14:38:53] <rohan> no hands for mandatory, many hands for not mandatory
[14:39:02] <spencerdawkins> thnks
[14:39:11] <spencerdawkins> can't look up and type at same time!
[14:39:26] --- LouBerger has left
[14:40:07] <rohan> rohan: is it ok if we add an option tag but default action is according to 3265 (ignore unknown params and return whole doc)? jdr: no
[14:40:15] <rohan> discussion cut off by chairs
[14:40:58] <rohan> draft-channabasappa-sipua-config-mgmt-00
[14:41:13] <rohan> management and config are different
[14:41:31] --- LouBerger has joined
[14:41:43] <rohan> some sip uas are apparently managed with CLI and SNMP, not using same mech for config
[14:42:41] <rohan> asking to define sip-based mech to negotiate management sessions (and solve NAT traversal)
[14:43:48] <rohan> not done with SIP, separate management protocol with ports/etc. negotiated via SIP
[14:44:07] <hardie@jabber.psg.com> so, use SIP to set up netconf?
[14:44:13] <rohan> cullen: management for what? is it because something is broken?
[14:44:19] <hardie@jabber.psg.com> or something netconf-ish?
[14:44:21] <rohan> to ted: yes effectively
[14:44:53] <rohan> speaker: management not only when broken, monitoring for SLAs for example
[14:45:00] <dwillis> Turn for snmp relay?
[14:45:07] <rohan> bingo
[14:45:18] <hardie@jabber.psg.com> Hmm.
[14:45:22] --- ttfrttfr has joined
[14:45:41] <rohan> cullen: wanting to make stuff more granular (i didn't understand what he is saying)
[14:45:58] <slavitch> seems like a use-case for p2psip :^)
[14:46:08] <slavitch> (sorry)
[14:46:08] <rohan> bleech
[14:46:38] --- ttfrttfr has left
[14:46:40] <rohan> JDR: repeats use case
[14:47:09] <rohan> JDR: want "phone call home" poke
[14:47:29] <rohan> dan p: wants to query whats there
[14:47:47] --- ttfrttfr has joined
[14:47:48] <rohan> hisham: difference from commands and getting info with queries
[14:48:11] <rohan> jdr: FCAPs is management - fault, config, accounting, performance
[14:48:16] <rohan> what about everything else
[14:48:45] <rohan> dan romanscu (sp?)
[14:49:05] <rohan> /scu/escu/
[14:49:07] <hardie@jabber.psg.com> Not for the mic, but this doesn't make sense to me from a skimming read of the draft
[14:49:30] <rohan> consent work up now
[14:50:32] <rohan> gonz: when relay does translation, relay needs to get permissions to forward
[14:51:01] <rohan> 1st need document format for permissions. they based on common-policy format
[14:51:09] <rohan> summary of common-policy
[14:51:27] <rohan> new conditions definied: sender and target, new action : trans-handling
[14:51:55] <dwillis> have you Read TR069 from D S L Forum?
[14:52:31] <rohan> to dean: yes
[14:52:32] <ttfrttfr> @hardie: agree with you
[14:52:49] <rohan> open issues
[14:53:40] <rohan> gonzalo walking through how mech works to add recipient
[14:54:24] <rohan> list-state event package terms about changes in state of list
[14:54:49] <rohan> uses XCAP diff
[14:55:04] <rohan> need to model process in server as another client
[14:55:30] --- plivesey has left
[14:55:49] --- Alan H has left
[14:55:56] --- Alan H has joined
[14:56:02] <dwillis> l think the use of SlP to wakeup a management agent is veRy clever.
[14:56:28] <rohan> problem 1 is you need to get URIs by subscribing
[14:57:05] <rohan> jdr: mixing state machine and state data together, including failure states
[14:57:33] <rohan> document need to include what are really events (and transient) in the document
[14:57:37] <rohan> this is all XCAP specific
[14:58:11] <rohan> all this because rohan asked for a summary of the problem
[14:58:21] <hardie@jabber.psg.com> go rohan!
[14:58:51] <rohan> hgs: hides real action. twiddle something so server can implictly deduce what it needs to do. this is a kludge
[14:59:24] <rohan> don't do *document* updates to trigger immediate server actions
[15:00:04] <rohan> andrew allen: we should clarify this, since oma is doing this too
[15:00:39] <rohan> jdr: xcap is good at updating document. database do have triggers on data update, but tunneling a protocol inside a document is a bad idea
[15:01:13] <rohan> proposal: minor XCAP extension to say some operation is pending
[15:01:30] <rohan> server needs to do something.
[15:01:44] <rohan> would be independent from mechanism to create the translation
[15:02:20] <rohan> JDR: we can just use 202 2616 calls out pointer to get progress of your request
[15:02:31] <rohan> JDR: no XCAP extensions neede
[15:03:23] <rohan> on to CONSENT request and Permission-Upload header field which provides URI to send PUBLISH to upload perm doc
[15:03:34] <rohan> open issue header field or part of perm document
[15:03:46] <rohan> proposal, stay with header field
[15:04:02] --- Alan H has left
[15:04:02] <rohan> @ted: where are you now?
[15:04:19] <hardie@jabber.psg.com> imapext
[15:04:24] <hardie@jabber.psg.com> Metropolitan
[15:04:24] <rohan> thx
[15:04:41] <rohan> grant permission event pack
[15:05:03] <rohan> uses xcap diff, issue: should it use xcap patch as well
[15:05:17] <rohan> issue 2: how to delete permission docs?
[15:07:17] <hardie@jabber.psg.com> Are we on draft-camarillo-sipping-grant-permission-00.txt?
[15:07:26] <rohan> i think so
[15:07:31] <ttfrttfr> use case: "ask for a permission to add user in a list" is already handled in SIMPLE stuff, is consent another way to do this?
[15:07:50] <rohan> yes, but for a bunch of other stuff, more generic
[15:08:11] <rohan> CONSENT is not needed for REGISTER with outbound (this is implict)
[15:08:32] <rohan> can do extension to reg-event pacakge to do something
[15:09:32] <rohan> to know when a registration (and the consent implied) are ok
[15:11:50] <spencerdawkins> what was last slide about :-(
[15:12:15] <rohan> no clue
[15:12:21] <rohan> new open issue
[15:12:36] <rohan> does a URI get added to the list just by arriving in some new request?
[15:12:53] <rohan> or does the client need to use XCAP to add URI
[15:13:54] <spencerdawkins> :-)
[15:14:17] <rohan> jdr: two sides to this. left side and right side <huh?>
[15:15:00] --- a.hawrylyshen@gmail.com has joined
[15:15:08] <rohan> this slide talks about garbage collection of my XCAP server (for consents, etc.. for OTHER folks)
[15:15:36] <spencerdawkins> bottom pieces are me and other guy, top pieces are consent server and relay.
[15:15:40] <rohan> gonzalo will revise documents
[15:16:56] <rohan> queried who read (~20+) and who understood (3)
[15:17:09] <rohan> who's planning to implement: zero
[15:17:26] <rohan> hgs: this is so complicated, academic exercise
[15:17:34] <rohan> <lots of laughing>
[15:17:38] --- slavitch has left
[15:17:49] <rohan> hgs: can we push reset. it gives sip a bad name
[15:18:10] <rohan> is there a more scopable problem here?
[15:19:07] <rohan> rjs: thought about authorizing using similar model
[15:19:35] <rohan> rjs: mechanism for just what he wanted was 2 orders of magnitude smaller than this
[15:19:40] <rohan> it may be too general
[15:19:57] <rohan> may want to do just a few uses such as exploders
[15:20:25] <rohan> jdr: complexity does not come from implementation, its that we've been asked to do something that nobody has done.
[15:20:36] <rohan> jdr: if you accept these at requirements, then you are here
[15:20:58] <rohan> dean: all of list services (critical to OMA) depend on this
[15:21:13] <rohan> hgs: practical solution, email with link to click on
[15:21:32] <rohan> jdr: core requirement from boston is can't even have first explosion without this
[15:21:53] <rohan> cullen: we did agree to do this
[15:22:04] <rohan> not sure what we can remove and solve original problem
[15:22:29] <rohan> we c an also stop doing explosion, but nobody really wants that
[15:23:45] <rohan> rohan: i did not agree to this. this was required on us by IESG
[15:24:13] <rohan> it is too hard of a problem to be solved as one of 40 milestones on the side in the SIPPING WG
[15:24:49] <rohan> its too much to bite off, maybe it should be solved in IRTF
[15:25:08] <rohan> heart was in the right place (problem does exist), but this is too hard
[15:25:14] --- sdotson has joined
[15:25:40] <rohan> rjs: maybe wee can relax some part of the requirements (ex: don't need consent for registrations)
[15:25:53] <rohan> rjs: pick either smaller hammer or bigger hammer
[15:26:05] <rohan> gonz: wouldn't change anything. it would be just as complex
[15:27:09] <rohan> a bit earlier jdr: we know how to do this, its just complex, IRTF wouldn't make problem easier
[15:27:29] <rohan> hgs: glad you worked it out, but lets not use this
[15:29:32] <rohan> jdr: please write a draft suggesting subset of requirements
[15:30:05] <rohan> jdr: i hate being on the receiving end of non-constructive complaints and no suggestion about what to do instead
[15:30:19] <rohan> hgs: suggesting an impractical approach involving email
[15:31:11] --- joshlitt has left: Replaced by new connection
[15:31:20] <rohan> rohan: still results in moving amplification problem to email
[15:32:22] --- dmalas has joined
[15:32:46] <rohan> jdr: no, you only get a mail if you try to send a sip request to someone new
[15:33:11] <rohan> rohan not at mic: but there is no security binding between sip and email, so i coudl get spammed that way
[15:33:20] <rohan> new presentation on session policy
[15:33:35] <rohan> should have been submitted as draft-ietf-
[15:33:38] <rohan> changes
[15:33:47] <rohan> confidential sdp is in sec consider
[15:33:56] <rohan> content dispo changed
[15:34:01] <hardie@jabber.psg.com> Tis draft-hilt-sipping-session-policy-framework-01.txt?
[15:34:02] <rohan> sdp text updated
[15:34:14] <rohan> yes
[15:34:43] <rohan> open issue with session-specific policies how to submit session information to policy server?
[15:35:19] <rohan> model now is submit session description to policy server and get back policy (possibly as modified sess-desc)
[15:35:27] <dwillis> so use siP message Method instead of email
[15:35:50] <rohan> dean taking over as scribe for a bit
[15:36:17] <rohan> Describing option 1 from slides and its open issues
[15:37:00] <hardie@jabber.psg.com> It's not clear to me what schemes are permitted for the policy Server URI
[15:37:02] <rohan> potential for deadlocks
[15:37:55] <rohan> User agent has policy for offer but is waiting for a notify on the answer policy while the proxy is waiting for the answer to make policy.
[15:38:46] <ttfrttfr> why not HTTP instead of subscribe/notify between ua and policy server?
[15:38:53] <hardie@jabber.psg.com> dean: is this expected to be a sip/sips URI?
[15:39:03] <rohan> Second discussion point is need to manage two soft states in UA and policy server
[15:39:03] <hardie@jabber.psg.com> The draft is not clear about what schemes are permitted.
[15:39:11] <rohan> Option 2; Subscribe bodies
[15:39:51] --- tskj has left
[15:40:02] <rohan> only one soft state to track.
[15:40:38] <rohan> Next steps: stay with current mech based only on subscribe
[15:43:33] <rohan> rohan: (i'm typing again now)
[15:43:46] <sdotson> the sound is horrible for this room
[15:43:52] <rohan> can we please make some progress on config framework before leaving this week?
[15:44:24] <rohan> people who don't like document and have not commented within last few weeks, please ping author and rohan
[15:44:31] <rohan> what do we do to proceed
[15:44:47] <rohan> gonz: interested parties meet immediately after meeting
[15:44:48] --- bew has left: Disconnected
[15:44:59] <rohan> ToIP framework
[15:45:12] <rohan> aka. mud wrestling
[15:45:40] <rohan> main question is around purpose. is it a frameowkr, a requirements doc, a floor wax, or a desert topping
[15:45:41] --- tga73 has left
[15:46:21] <rohan> changed structure so each section is clear on at least its purpose
[15:46:29] --- hardie@jabber.psg.com has left
[15:47:02] <rohan> some complaints that document is contradictory but no concrete issues mentioned
[15:47:15] <rohan> complaint that document is missing things like QoS and p2p
[15:47:31] <rohan> is this kind of stuff in scope? arnoud thinks it is not in scope
[15:47:41] --- jr111 has left
[15:47:48] --- Adam has joined
[15:48:07] <rohan> @adam, send me an invite again
[15:48:25] <rohan> dean accidentally cancelled your request
[15:48:41] <rohan> proposal for way forward with ToIP
[15:48:48] --- sdotson has left
[15:48:51] <Adam> Rohan: don't worry about it.
[15:48:52] --- ft has left
[15:49:10] --- derek has joined
[15:49:16] <rohan> mbarnes: yes, WG wants to finish
[15:49:27] <rohan> mbarnes: tom taylor volunteers to review
[15:49:34] --- derek has left
[15:51:04] --- mnvakil has left
[15:54:30] <rohan> discussion of whether IMS can use sipping config work.
[15:54:56] <rohan> Probably not, as it requires a subscription that IMS clients can't launch until they've been configured.
[15:55:34] <rohan> More interesting to ask what happens when somebody who does config framework also wants to use SIMPLE work.
[15:55:42] <Adam> I'm very impressed by Rohan's ability to type and speak at the microphone at the same time. :)
[15:55:55] <rohan> Since it is useful to integrate the two
[15:55:59] <spencerdawkins> scary - note that I'm sitting down
[15:56:02] <rohan> and to get a guest typist while speaking
[15:56:05] <spencerdawkins> :-)
[15:56:17] <rohan> even if my mobile
[15:56:52] <rohan> 's content delivery server doesn't support xcap, I can get a notify saying my buddlylist has changes. I can get a URL to the full document, and decide whether or not I want to download the whole thing.
[15:57:37] <rohan> debate around profile type's impact on error state prevention here.
[15:58:06] <rohan> some confusion on profile=application parameter
[15:58:38] <rohan> what does it mean to subscribe with a profile type not supported by the server? You get an empty document. Like what happens if you subscribe to a nonexistent document -- a 404 situation.
[15:58:51] <rohan> JDR argues these are different error conditions.
[15:59:35] <rohan> Dan says you have no good reason to have a profile delivery server that doesn't support xcap if you want to do this, and it just isn't going to work.
[16:00:06] <rohan> But Rohan says he gave an example that shows something useful can be accomplished in this case.
[16:00:30] <rohan> Gonzalo calls time, says the 3 of dan rohan jdr should go chat
[16:01:17] <rohan> Dan asks is this can be separated out so that base can proceed? JDR thinks possibly not, as that would make the new thing a separate event package and not an extension.
[16:01:30] --- cullenfluffyjennings@gmail.com has left: Logged out
[16:01:32] <rohan> Meetking to resume friday at 0900
[16:01:42] --- a.hawrylyshen@gmail.com has left
[16:01:49] --- dmalas has left
[16:02:14] <rohan> byebye
[16:02:28] --- dwillis has left: Logged out
[16:03:19] --- jason.fischl has left
[16:07:48] --- Adam has left
[16:08:58] --- rohan has left
[16:09:05] --- LouBerger has left
[16:09:30] --- spencerdawkins has left
[16:16:53] --- gas has left: Replaced by new connection
[16:17:46] --- tianlinyi has left
[16:18:43] --- bhoeneis has left
[16:18:48] --- frodek has left
[16:24:00] --- m_7777 has left
[16:28:25] --- shidaschubert has left: Logged out
[16:32:49] --- mnvakil has joined
[16:42:34] --- ttfrttfr has left: Disconnected
[16:48:17] --- jjmbcom has left
[17:02:49] --- mnvakil has left
[17:29:49] --- miki has left
[17:53:13] --- spencerdawkins has joined
[18:00:39] --- spencerdawkins has left
[18:10:57] --- spencerdawkins has joined
[18:32:23] --- spencerdawkins has left
[19:13:39] --- juha.wiljakka has joined
[19:14:02] --- juha.wiljakka has left