Notes from SIPPING Session 1 at IETF 62

Reported by Spencer Dawkins

SIPPING - IETF 62 Agenda
Chairs: Gonzalo Camarillo, Rohan Mahy, and Dean Willis

THURSDAY, March 10, 2005, 0900-1130,  Salon D
Time Length Discussion Leader Topic Relevant Documents Slides
0900 - 0915 15 minutes Chairs Status and Agenda Bash

    •      Robert Sparks pointed out that SipIT registration closes next week
    •     Please look at "Semi Regular Examples" individual I-D and comment to the author
    •     Robert Sparks talked about dialog-usage I-D - not on the agenda, please look at it and comment
    •     We have volunteers to review Torture Test draft, but please send e-mail to Robert/Gonzalo if you'd like to help
    •     Have published Early Session Disposition/Early Media as RFCs, Transcoding and 3GPP R5 are in RFC Editor Queue
    •     Conferencing drafts are post WGLC (so is URI-list Services), but all are dependent on consent framework
    •     Please ignore official milestones on IETF web page - they are outdated
    •     We would like for people to work for more than one week each IETF cycle
    •     Cullen is working on security flows draft in SIP - please read and comment, authors think they are done
    •     Location requirements was moved to SIP, so this milestone will go there, too
0915 - 0945 30 minutes Dan Petrie -  Configuration Framework and Data Sets
 draft-ietf-sipping-config-framework-06.txt

    •     Delivery server mandates HTTP/HTTPS, UA can choose either
    •     Security section in framework has been rewritten
    •     Separated Normative/Informative references
    •     Event package names and parameters had several issues raised on the list, mostly (not all) cosmetic
    •     Other comments on the list - looking for more use case examples, cross references to normative descriptions, less terse security section, clarify "cache" term, need name-addr, token references
    •     XCAP section is too abstract - remove this section or better define use and scheme for "document" and "app-id" header parameters - need a volunteer to provide text in this section - needs to be either correct or removed, but we can figure out which offline - issue is mostly where we define a binding, don't need a new package to support XCAP - will work this off-line
    •     Cullen - security as described doesn't work for anything except HTTP transport (LDAP, etc.), but we said we can use more than HTTP as transport - need to pass userid and password in SIP if we're going to allow other transports - and dropping the other protocols would be fine with Cullen - any objections to pulling these protocols out? None in the room - if we can demonstrate it's possible to use another protocol, fine - there's not even a procedure for negotiating transport, this is multiple options that don't help interoperability, HTTP/HTTPS are mandatory for server, why do we need this? Choices are bad  - we could fix this, but do we want to? Fixing this doesn't seem to be the consensus of the group - Dan will remove references to other transports in the next revision
    •     This draft is just about ready for last call - if you'd like to implement, please contact the authors
draft-petrie-sipping-profile-datasets-01.txt

    •     Added use case scenarios, removed more complicated constraints elements, added simpler constraints attributes, defined default merging algorithms, added examples correlated to use cases
    •     There are properties that may occur in more than one profile - need to merge/resolve collisions. Merging strategy is specific to the property. Some properties need to be constrained, some properities need to be mandated or disallowed
    •     Need to specify what properties may/may not be changed
    •     Proposing a profile hiearchy of precedence - device, user, application, local-network
    •     Merging will be statically associated with a specific property, and constrained by "policy" attribute
    •     Right direction? Generally positive-to-neutral thumbs display from people who have read the document
    •     If there are use cases where hiearchy doesn't work, please say so!
    •     Framework document is almost done, except that there's no default content type in the framework. This is the likely default type - can the framework proceed without this work being completed? Rohan thinks that this would be OK because the framework useful - chairs have discussed with Allyson
    •     Volker - what about cases where there are conflicts with no common ground? What is the appropriate resolution? Highest-hierarchy wins in Dan's proposal, is this OK?
    •     What about specific-case overrides? Dan worries about the degrees of trust we'd be tripping over - would you trust the local-network to change your user agent? Is trust about content of data, or about source of data?
    •     Cullen - conflicts can be real - if you have no ethernet card, you can't make calls, no matter what - we need to finish, this is the most important work going on in SIPPING right now
    •     Discussions will continue on the list
0945 - 1015 30 minutes - Volker Hilt - Session Policies
draft-ietf-sipping-session-indep-policy-02.txt

    •     Minor changes on this draft
draft-hilt-sipping-session-spec-policy-02.txt  

    •     Chair interrupt - Not enough people are reading these drafts! This is important work
    •     Adam - SIP/SIPPING/SIMPLE/XCON drafts on the agenda = more than four novels that come out in the four weeks before a meeting - it's not realistic to expect everyone to read everything
    •     Agenda is actually in "priority order" - but this is news to a lot of people
    •     James Polk - people are writing drafts, too, they don't have time to read them
    •     Paul - if these drafts were spaced out ... interim meetings?
    •     Cullen - interim meetings suck and are not the solution to this problem in general (although they do help)
    •     Back to the draft...
    •     Major change is to simplify format
    •     BSPF policies are XML elements with flat structure - merging rules are defined individually for each policy element
    •     Merging rules are defined for each policy element
    •     Open issue 1 - what elements should be included? proposals to add media and protocol elements - feedback?
    •     Dave - there are registries for lots of these elements - doing elements as text strings is going to be de-synchronized - if there's not an XML scheme, design one for the IANA and then everyone will have it
    •     We have XCON media elements, too - where do we draw the line?
    •     We've run into validation problems with extensibility mechanisms - can't look up extensible values in the registry, right?
    •     --------------------
    •     Jonathan - would like to use "we're going to use this" as criterion for adding elements
    •     Dan - primary reason for local-network profile was for policy, but no reason you couldn't put policy in other profiles with a well-defined hierarchy
    •     Do we need a transcoder as an element? Defer this to later discussion
    •     Open issue 2 - how to deal with policy conflicts
    •     If policies are enforced in the network, there will be times you can't make a call - but that's OK, it's a fact of life
    •     Policy channel protocol is an Open Issue
    •     SUBSCRIBE/NOTIFY? Plus PUBLISH? with SDP in the SUBSCRIBE body?
    •     HTTP? Asynchronous updates aren't possible
    •     COPS? UA would be PEP
    •     BEEP? this would allow asynchronous updates, but isn't widely implemented in UAs
    •     Feedback? Henning - this is getting close to NETCONF framework - should look at this draft before designing it again piece by piece
    •     Is SUBSCRIBE/NOTIFY good enough? Sending SDP in body is OK
    •     Jonathan - how about Corba? Just kidding ...
    •     -------------------
    •     What are the demands for session-dependent policy? We need to have this discussion before we can move forward
    •     Tom Taylor - go with SUBSCRIBE/NOTIFY model
    •     Paul - session-independent and session-dependent are two ways of looking at the same thing. One is just more efficient than the other
    •     Jon - "Pre-empt" is a great word - things that change and need to be sent to UAs
    •     Jonathan - is this turning into CAC? We need use cases to understand what people are trying to do, to move forward - what are the higher-level things people are trying to do?
    •     Gonzalo - people who don't want to disclose all the rules in their network, only what you need to know for a specific session
    •     What is way forward to this work? Continue discussions on the list
    •     James Polk - are we talking about policy servers that communicate across domains? No, this is out of scope - policy servers talk to UAs
1015 - 1045 30 minutes Gonzalo Camarillo - Consent Framework
 draft-ietf-sipping-consent-reqs-00.txt
 draft-ietf-sipping-consent-framework-01.txt 

    •     Mostly stable - add text about amplification attacks, cross-domain consent
    •     Translation requests- use a header instead of Request-URI? similar to Record-Route header?
    •     Dave Oran - is there a privacy problem revealing the target of the translation? exactly, that's why we're avoiding Request-URI
    •     Don't have a strong preference between Request-URI and header - feedback from the WG?
    •     Can you keep all the state you need encrypted in a URI parameter (like GRUUs/GRIDs)? We think so
    •     Please give feedback if you have an opinion!
    •     SIP PUBLISH, XCAP, or a hybrid?
    •     XCAP allows a read operation, SIP PUBLISH can use SIP Identity
    •     Maybe don't want to restrict consent framework to UAs that support XCAP
    •     Jon - use PUBLISH with SUBSCRIBE? Actually, yes, and SUBSCRIBE could provide read operations
    •     Henning - how is this fundamentally different from configuration requirements?
    •     Does a user add a single document or a lot of documents? This affects SUBSCRIBE/PUBLISH alternative
    •     Can you aggregate documents for different users in a single PUBLISH? This is the same issue as previously
    •     XCAP would work better if you are uploading to your own proxy
    •     Discussion of prearranged permissions is too brief in the current draft
    •     Rohan - support hybrid model - some people do want to do write operations without read operations - with PUBLISH as must-implement
    •     Jonathan - no one will implement anything except mandatory-to-implement - somebody is going to try to do buddy lists with this, if we're going here, let's kill XCAP. PUBLISH only works with totally flat composition policy - in the general-case,  people don't want to see notifications, so forcing SUBSCRIBE is awkward - can you do wildcard-style filtering in this model?
    •     Markus - Should accommodate devices that don't implement XCAP - PUBLISH should be mandatory-to-implement
    •     Dean - consent information isn't just uploading to local proxy - there is no single respository that knows about all consent. This isn't a composited document world we're talking about
    •     Rohan - primary operation is write operation, in many cases the user doesn't care about read operations anyway. There are lots of things that PUBLISH prevents, and this is NOT a bad thing
    •     Dave Oran - is there a requirement to revoke consent? Don't you have to keep state about where you've consented to what? How does putting headers everywhere help with retargeting?
    •     Dean - this is like a mailing list where every message tells you how to unsubscribe - Jon - but this is more like an exploder that relies on identities? What is trust relationship with the other server? Just return-rerouteability
    •     Markus - what about case where you DO want to talk to your own proxy?
    •     Hesham - you want to create an event package in order to use PUBLISH - "small terminals won't implement XCAP" is a weak argument, because XCAP is a thin layer on top of HTTP and small terminals implement HTTP
    •     Jonathan - I hate to pick a protocol because it has the right identification characteristics - Imagine a SIP exploder the size of the IETF list - we don't have anything like this yet, but we're working on it - role-based consent?
    •     Cullen - critical to remember that you consent about your AOR, so consent needs to work when you consent from a great handset and then try to revoke from the lamest of handsets
    •     ---------------------- resumed discussion at end of meeting ----------------------------------
    •     Rohan - we can do SIP PUBLISH right now
    •     Jonathan - this affects basic SIP processing, want to support minimal UAs - even XML isn't required in SIP today - but I think I can describe how to use XCAP whether you understand XCAP or not, just define documents well - RFC 3261 doesn't even require PUBLISH, so...
    •     Jon - differences really are slight - need a consolidated authorization approach, and that would be XCAP, but I support the hybrid approach
    •     Rohan - two issues here, ease of implementation for a really dumb device, and deployment - today, we have PUBLISH - we should move forward with PUBLISH as mandatory-to-implement
    •     Jonathan - what isn't deployed today is SIP Identity, don't kid ourselves about where we are. I know where we will go - PUBLISH will be in every phone and PUBLISH will take over this functionality as hack extensions
    •     Rohan - don't agree that this will happen. SIP Identity is deployable, even if it hasn't been deployed, you're comparing this to approaches that don't even exist yet.
    •     There are no real low-end devices that don't support HTTP, and they have for years
    •     Paul - How do we handle XCAP avalanche restart when we get new IP addresses? Rohan - does this apply to consent?
    •     Hesham - Need an event package (repeating) - we are going to use PUBLISH and THEN define an event package?
    •     User agents are smarter than you think - why can't we do just one solution?
    •     Mandatory-to-implement? Don't have a hum consensus at this time
1045 - 1100 15 minutes Gonzalo Camarillo - Transcoding Framework
 draft-ietf-sipping-transc-framework-01.txt

    •      No change from previous version, just resubmitted
    •     No signalling from transcoder to called party
    •     Problems with this model - lots of messages over slow radio links, many UAs don't support 3pcc. New model needed
    •     Treat the transcoder as if it was a conference, address it as if it was a proxy?
    •     Conference model requires UAs to support list bodies
    •     Route model prevents you from knowing who is the RTP recipient from the SDP contents
    •     This is not just an SBC topic, it's for B2BUAs
    •     Jon - route model means you lose control of consent - conference makes this implicit
    •     Eric - conference model just works, router model breaks SIP stuff - how to have receiving party request transcoding?
    •     For Route model, originator needs to know he needs to request transcoding? But this can be done with OPTIONS, etc. You have to discover this anyway. We're trying to avoid "trusting the network to do the right thing"
    •     Do we all like the conferencing model? Gonzalo will reissue the conferencing-only version of the draft after the IETF
    •     Jonathan is OK with the conferencing model - concerned that proxy will still be making the same decisions with no consent - but they can do this today anyway
1100 - 1105 5 minutes  Gonzalo Camarillo - IPv6 Transition
 draft-camarillo-sipping-v6-transition-00.txt

    •      IESG is requiring SIPPING to have IPv6 transition document using existing mechanisms (ICE, ANAT ) - defining new mechanisms is out of scope
    •     Allison - v6ops is asking for this - does anyone have energy other than Gonzolo? Cullen will help review this document
    •     Adopt as baseline text? Unanimous hum "yes".
1105 - 1115  10 minutes Jani Hautakorpi - SBC Functions
 draft-camarillo-sipping-sbc-funcs-00.txt
draft-bhatia-sipping-sbc-00.txt

    •     Two drafts on functions with SBCs, intended as input to related WGs in IET
    •     Scope is to identify non-SIP friendly functions (not to define SBCs)
    •     Spencer - what target WGs? SIP, probably SIPPING as well
    •     Ben - want to say "no" for new work in this working group, with too much to do now, but need to find a way to move this forward - design team? Design team is already working in this space.