SIPPING - IETF 65 Agenda
Chairs: Mary Barnes and Gonzalo Camarillo
Scribes: Spencer Dawkins <spencer@mcsr-labs.org>

WEDENSDAY, March 22, 2006, 1300-1500, Chantilly W
1300 - 1315 15 minutes Chairs Status and Agenda Bash

• Softarmor.com supplementary web page will be discontinued, will be using official IETF tools instead
• May use this for designated reviewers, but official tools need this for Gen-ART anyway
• Effort is huge for individual submissions
• Allison - want to use this group as guinea pigs for new states (like, who is reviewing) between now and Montreal
• Security directorate also needs a Gen-ARTish tool, for the same reason
• Friday agenda has lots of very short slots
• Have published ten more drafts in RFC editor's queue, plus five more publication requested
• SIPPING will be able to think of tackling new work (after Consent is finished)
  
• Doing one-slide summaries of some new drafts - isomaki-sipping-file-transfer
• Do we do requirements in this working group, or just solutions?
• MMUSIC slides also presented here for information (accepting file transfer using offer/accept)
  
• Cullen - "do you reject at INVITE time, or at MSRP time?" Don't actually care, that's what other people were asking
• Dean - SDP variations - are you doing this so IMS can bill you separately for media types? Gonzalo - completely orthogonal
• Jabber - ICE interactions? There are none, this is inline signalling
  
• Hasabe-race-condition-examples - some organizational changes, would like to get WG opinions on this draft
• Paul - supports this - there's a lot of confusion out there in the world, need to write down the folklore. This needs feedback more than anything else ("clear enough to help?")
• Dean - RFC, either WG or AD-sponsored. May get better review as WG item. Hum is to adopt as WG item.
  
• Multi-transcoding Use Case - author sent home to explain scenarios where this is possible, has updated the draft, please comment on list about this draft
• SIP LDAP User Schema - please  read and comment
  

1315 - 1335 20 minutes Dan Petrie
 Config Framework Split
 draft-ietf-sipping-config-framework-08.txt
draft-ietf-sipping-xcap-config-00.txt
draft-ietf-simple-xcap-diff-03.txt 

• Have dependency issue, divided into two parts to bypass XCAP normative dependencies on document and auid even header parameters
• Also fixed nits, clarifications, device certificate usage
  
• Issue is "how does device know the profile server supports XCAP?"
• Options are (1) Profile delivery server rejects if not supported, (2) XCAP mandatory, (3) Profile delivery server give the smallest profile subset that includes document path or auid
• Jonathan - we have all these event parameters that we are extending and realizing that we don't have extension mechanisms for this. (3) is wrong, you want something like (1) or (2).
• Rohan - in this case, what would the client asking for this do, besides going back and retrieving entire document? Rohan likes (3), but it's that the server returns the entire document.
• Jonathan - don't like client requests A and server returns B.
• Aki - saying that server doesn't know anything about XCAP? HTTP servers understand URIs, they understand the path partially. Sounds like we want to do (1).
• Jonathan - variations here - no XCAP, no support for document parameter, document does not exist...
• Do we ignore parameters we don't understand in 3265? Parameters getting pretty important to understand, the direction we're going.
• Not sure document will actually get done quicker after the split anyway (XCAP has just concluded WGLC).
• Rohan - Allison asked me to do this document's PROTO statement, I looked at dependencies and don't think we can ship the document in this form anyway (is just informative).
• Jonathan - don't think XCAP is too bad a dependency. Perhaps paranoid that people are trying to get XCAP out of the way (can do configuration without this XCAP stuff) - maybe reasonable, but then we need to discover support for XCAP, etc.
  
• Dan - has always been a requirement for configuration to work, independently of XCAP.
• Paul - "doesn't work, try a different way" - we've been here before with REGISTER instance IDs - bounced this because people wouldn't tolerate the traffic (would be bad to try everything twice). Prefer (3).
• Aki - This is a 420 going back
• Jonathan - the problem isn't that XCAP is broken, it's that we've got an optional capability with no way to signal support. Let's be crisp.
• Rohan - reasonable to have option tag, but would Jonathan be OK with base profile delivery mechanism that has RFC 3265 behavior (ignore unknown headers)?
• Gonzalo - don't have time for detailed discussion here. Who has opinion on making XCAP mandatory? Not many. Who thinks it should be mandatory? No one in the room - need to take this to the mailing list.

Discussion resumed at end of the session

• Rohan - Real issue is, what do you do if you don't support XCAP at all? Different from what you do if you support XCAP but there's an error. For any event package in general, we haven't needed a mechanism to negotiate whether you support a new header, and don't think we will. No need for mechanism if nothing bad happens if you DON'T support the new header.
• Jonathan - different problem (someone wants to find out that someone else added a third person to the buddy list. We're pushing this back to a separate event notification. My understanding is that IMS doesn't use this.
• Andrew Allen - IMS requires a registration first.
• Jonathan - aren't they using non-SIP mechanisms?
• Rohan - no suprise that IMS doesn't work the way we think. IE-HTTP works fine today. Would I be using a mobile client that doesn't support XCAP? You only get profiles with application types.
• Jonathan - what does application mean if you remove document and auid? Get a 404 - what's the problem?
• Dan - not sure negotiation mechanism is necessary - doesn't make sense.
• Jonathan - what can you do if server doesn't support something you want?
• Rohan - disagree that can't do anything useful.
• Gonzalo - please take this to the list.
• Jonathan - question is whether new stuff is extensible or not.
  

1325 - 1330 5 minutes Sumanth Channabasappa
Jean-Francois Mule
Use Case and Considerations for SIPPING  config
draft-channabasappa-sipua-config-mgmt-00.txt

• UA configuration and managment are different
• Has three different use cases, focused on third use case here.
• SIPPING framework can be used for both configuration and management
• Must traverse NATs and firewalls in today's networks
• Use SIP-based mechanisms to establish management sessions?
• Rohan - negotiate something? Correct, management isn't done through SIP, only required parameters
• Cullen - management for what? SIP calls aren't working? so can't use it to manage SIP devices, right?
• Assuming that UA needs to be managed, working on how to do this.
• Jonathan - network wants to read statistics off the device - assumed this use case for the draft. Could be "phone home" poke.
• Dan - could be reading firmware versions, etc.
• Heshim - commands are different from queries
• Dan R (AD) - could you coordinate with management framework being worked in management area?
  

1340 - 1425 45 minutes Gonzalo Camarillo Consent Framework
draft-ietf-sipping-consent-framework-04.txt
draft-camarillo-sip-consent-method-00.txt
draft-camarillo-sipping-consent-reg-event-00.txt
draft-camarillo-sipping-consent-format-00.txt
draft-camarillo-sipping-grant-permission-00.txt
draft-camarillo-sipping-list-state-00.txt

• Requirements are in RFC Editor's queue
• WG consensus on framework direction, needed normative behavior documents that implemented the framework
• Based permission document on common policy format (new conditions - sender, target - and new action - trans-handling)
• Could use XCAP to manipulate URI list
• Use XCAP-diff to inform about changes in state of the list - could we use XCAP-patch as well?
• Rohan - what's the problem with XCAP? Does not provide "this change". Need URI for Refers-to.
• Jonathan - has many problems - mixing state machine and static data together - may want to know about events, not just state changes. Mix them, you need both. This is all XCAP-specific. Could have separate event class.
• Henning - general problem is that XCAP becomes a more procedure-oriented protocol - no good way to tell you what actually happened. Even for simple notifications this is a kludge - need warnings around this. We've already done the damage for "simple event notification" -
  
• Andrew Allen - seeing proposals like this all the time.
• Jonathan - don't think we should press reset button on all simple notifications, but tunneling a protocol though a document is a mistake. We have a better solution.
• Alternative - list format remains unmodified (extension to XCAP), separate event package with pending permissions.
• Jonathan - don't agree an extension is required at all.
• Gonzalo - translation could be XCAP, registration, or other mechanisms
• Permission-Upload header field used by client to upload permission document. Ipen issue - header field or part of permission document? Choosing header field in draft for now.
• Grant-Permission Event Package - uses XCAP-diff - should it use XCAP-patch as well? Client needs to delete permission documents.
• Could use permission server to generate URI that routes instead.
• Consent in Registration - not applicable when SIP-Outbound is being used. (have already consented to rceive traffic).
• Extension to reg-event (new <consent-status> element), with separate event package with pending permissions.
• Request-contained URI lists generate errors when they have one or more invalid URIs
• Open issues - does a URO get added to the list just by arriving in a request? or do clients need to use XCAP? Clients have no incentive to remove documents from servers (or servers can garbage-collect)
• Andrew Allen - could we have expires? We decided not to.
• Jonathan - two sides - bottom pieces are me and other guy, top pieces are consent server and relay. Consent server issues are different from relay issues - we're conflating them.
• Would like to finish ASAP, but this isn't trivial. We will request reviewers for next version.
• How many people read the documents? Not a lot, but more than Gonzalo expected.
  
• Rohan - how many understood? :-)
• How many planning to implement?
• Henning - this is a blind alley, too complex to implement, giving SIP a bad name, five specs with event packages to do one operation. People will ignore consent if we do it this way. No one will understand it, no one will use it, and it doesn't add a single dollar to revenue - good luck getting implementations.
• Robert - this is like two orders of magnitude too complex. Do we really want a single mechanism to solve the problem that got us here in the first place?
• Jonathan - complexity is because of the requirements. If you accept them, you're here. Not because of the generality.
• Dean - all OMA services are normatively dependent on this, we've got to solve this anyway.
• Jonathan - core interim requirement was that we can't have a single amplification in the network. If you relax that, you have explosions.
• Cullen - we all agreed to go here. If we remove requirements we can't solve the problem. Do we can all the stuff associated with this?
• Rohan - disagree - I did not agree to do this, it was a requirement from the IESG to specify something to address explosions. SIPPING was asked to solve this problem, it's IRTF material.
• Cullen - we can solve the problem but the solution is too complicated and no one will implement it. That's not an IRTF thing.
• Aki - we're making things very hard for the good guys.
• Gonzalo - if you're OK with being an amplifier, don't implement this.
• Robert - if requirement list can't be reduced and still solve the problem, could we reduce requirement list and solve OTHER problems (contact lists, explicitly)? Take a smaller hammer to smaller problems?
• Gonzalo - complexity of solution would be exactly the same.
• Henning - argue that if you can solve the first one, the other stuff is easy - if no one implements the first one, you'll get kludges for the second ones, and they'll be silly one-off implementation efforts. I admire your persistence, but no one will even be able to provide feedback and they'll hum just to be finished. And then it will be mandated into other things. This is a valuable exercise, but we need to honestly say that the cost benefit analysis failed. Don't do this just because you're chartered to do it.
• Dean - came up with SIP way to do this that was a kludge, and it's better than this.
• Jonathan - I look forward to reading your drafts. You'll either drop requirements or end up in the same thing.
• Rohan - sending e-mail gives you the same problem, the explosion happens in e-mail instead.
• Cullen - it's still a milestone, as long as it's a milestone, we need to do this.

1425 - 1445 20 minutes Volker Hilt Session Policies
 draft-hilt-sipping-session-policy-framework-01.txt
draft-hilt-sipping-policy-package-01.txt
draft-ietf-sipping-media-policy-dataset-00.txt

• Should have been submitted as WG item (sorry!)
• Added confidentiality of SDP concern in Security Considerations section.
• Changed content disposition type for policies
• Clarified SDP extension use
• Depends on policy framework draft
• Major open issue - how to submit session information to the policy server? (Sending a session description to policy server, getting a possibly-modified description back).
• Option 1 - PUBLISH/SUBSCRIBE (but we could run into deadlocks)
• Option 2 - SUBSCRIBE bodies
• Proposed to stay with current mechanism based on SUBSCRIBE only
• Andrew Allen - what was objection to second option? just remember there was a problem, don't remember details
• Discussions to continue on mailing list

Rohan - if you have comments on the config framework, please look at the current version - would like to get something done this week. Too late for an ad hoc, but need to continue discussions.

1445 - 1500 15 minutes Arnoud van Wijk ToIP draft-ietf-sipping-toip-04.txt

• Who has read the draft? Almost no one
• Draft is WG item, WGLC finished Nov 2005, this version addresses comments received.
• Have gotten new discussion recently
• Main discussion seems to be around purpose of the draft (title is about requirements, document is about framework).
• Some changes to confusing 03 structure.
• List comments said "contradictory and incomplete" - no evidence of contradictory, missing items promised but seem to include peer-to-peer and QoS. Think missing items are OOS for current draft.
• Seek WG agreement on Scope of Draft, WGLC changes, additional ToIP related work is likely?
• We have a reviewer (and chairs will be reviewing update, too).
• Rohan - does anyone think Peer-to-peer is in scope?
  

FRIDAY, March 24 9, 2006, 0900-1130, Coronado A

Time Length Discussion Leader Topic Relevant Documents
 
0900 - 0905 5 minutes Chairs Agenda Bash

• Some moving around of agenda items, plus some lightning talks...
  
• Hannes reported on discussions about SPIT authorization policies - is this useful at all? Please send feedback to mailing list.
• Robert - could we focus on open issues, and not on the millions of drafts? Gonzalo - we will be more aggressive about managing the agenda in future meetings
• Gonzalo also talked about the changes to the Consent framework - will move to MESSAGE request with XML body and human-readable body. Permission server will be store-and-forward IM server - if this isn't available, can't get consent if someone is offline. Retrieval protocol is out of scope, PUBLISH with HTTP optional (does not need to contain the document).
• Rohan - does request go straight to receipient if recipient is online? Yes.
• Gonzalo will update the drafts for next meeting.
  

0905 - 0920 15 minutes Robert Sparks Multiple Dialog Usages in SIP draft-ietf-sipping-dialogusage-01.txt

• Has been indvidual draft for 18 months. This revision catches up with standardized error codes, added a section categorizing messages that start and terminate usages, various editorial fixes/clarifications.
• Should probably add guidance on error codes to extension guidelines - AUTH-48 change? Should work.
• Keith - can you put enough text in for people to work things out for themselves? Not sure we have enough text already.
• Planned changes - 481s are internally inconsistent, need to discuss "forking" at UAC behavior in 482, editorial changes and examples from the list.
• WGLC/Publish next version. Also need a plan to execute changes in other documents (this is a separate effort) - and will take place in SIP WG.
  

0920 - 0925 5 minutes Robert Sparks Limiting the Damage from Amplification Attacks in SIP Proxies draft-sparks-sipping-max-breadth-00.txt

• Discussed in detail at SIPit 17 - proposed change breaks max-forwards, so now thinking about "max-breadth" that bounds the number of active branches at any point in time.
  
• Rohan - Not  necessary with loop detection in SIP? Robert disagrees (this is the number of participants in an attack).
• Loop detection helps, but doesn't fix the problem. We're counting the number of message hops, not the number of messages. We're not going to do math at the white board.
  
• Can monitor depletion of max-breadth and provide early warning, diagnostics for emerging problems.
• List discussion before SIPit 18, please.
• Cullen - how many messages? Same number as before, we're just serializing the messages - won't make entire server farm fall over based on one message.
• Cullen - does this help? Not sure if doing the same number of computations over a longer timescale is actually useful. Do we need to delay between computations? Otherwise, we're 100 percent CPU busy anyway because we always have work to do.
• Does anyone actually have this limit now? No one that showed up at SIPit.

1055 - 1105 10 minutes Miki Hasebe Race Condition Examples draft-hasebe-sipping-race-examples-00.txt
0925 - 0935 10 minutes Byron Campen An Efficient Loop Detection Algorithm for SIP Proxies draft-campen-sipping-stack-loop-detect-00.txt

• Assume that all nodes have a unique number ("node value") that gets stacked and sorted as request is forwarded.
• Rohan - not sure what the benefit is here, but bigger question is, can routing area review this? Hasn't gotten enough attention here (too many drafts, not enough attention for any single draft), most people in the room haven't thought about this..
• Computational and space complexity - O(n), O(log n) average space requirement.
• Jonathan - O(n) gives n string comparisons - do people really have a problem with this?
• Robert - dorking with Vias was biggest source of SIPit bugs for years - this is why we added max-forwards.
• Jonathan - we need to clearly define the problem. Computational complexity is not the problem, need a description of the SIPit problems.
• Robert - computational complexity was a major reason for max-forwards in the first place.
• Henning - need to make sure that we don't spend all the computational savings performing this algorithm. Make sure we don't miss a multiplicative constant, because the numbers aren't that big anyway.
• Malicious proxies and UACs cannot cause algorithm to fail, non-participating proxies don't affect loop detection as long as there is at least one participating proxy.
• Several possible shortcomings (please see slides for details) - including, B2BUAs that dork with the headers that we need.
• Robert - SIP has fork loop draft now, "MUST do some form of loop direction, SHOULD/MAY do 3261". Did not hit back pressure in SIP.
• Jonathan - concerns about implementers ignoring MAY, should be SHOULD.
• Jonathan - loop versus spiral? Please read the draft.
• Adam - People don't make implementation decisions based on RFC numbers.
• Rohan - need to use UPDATEs in RFC text. MAY is insufficient guidance for people who follow the recommendations.
• Keith - is this document ready for WGLC? Is this document going anywhere? Would be nice to do it.
• Cullen - need to think before we make a decision, only about five people ready to make decision today.

0935 - 0950 15 minutes Andrew Allen Requirements for IMS service identification Email thread

• IMS was a service identiier, OMA, TISPAN, 3GPP now defining service identifiers.
• Want this work done in IETF, not 3GPP, for general solution
  
• IMS Service report is 23.816.
• Jonathan - we have 10 minutes for each topic, there has been a lot of discussion already
• 15 requirements for communication identifier from 3GPP (see presentation).
• Jonathan - thank you/rest of 3GPP participants for bringing this up. Defining protocols is more than syntax. Please use the same model in the future.
• Gonzalo - want to work with 3GPP as they make decisions.
• Jonathan - requirements are vague, need to be very specific about what you want something to happen in specific situations. Is the requirement to stove-pipe specific applications that don't interoperate with other clients? That would be appropriate Require tag. Can I send a SUBSCRIBE to an OMA presence server? Should this interoperate? Andrew thinks so (although value added features would not be available). What actually needs to be known? Liked CSCF model because of filters, etc. This breaks 3GPP service model.
  
• Keith - document isn't good at giving requirements, it's good at justifying them. Need to know what the actual requirements are.
• Paul - we need a draft. Not helpful to have pointers to material written in a different vocabulary. Someone who can represent the requirement needs to write it up in a focused way. Mailing list discussion just disappears.
• Jonathan - disagree, don't want to raise the bar for other SDOs who are trying to work with us. We're at the cusp between 3GPP and OMA making decisions that totally break interoperability. Can someone shepherd this?
• Gonzalo - agree, it's important to understand the requirements.
  
• SIPPING is interested in being involved in this work.

1010 - 1020 10 minutes Jonathan Rosenberg Overload Requirements draft-rosenberg-sipping-overload-reqs-00.txt

• 503 mechanism works fine, but what if entire network is overloaded? Too much work to tell peers that all of the elements are busy. Doing overload processing early, but this isn't enough to avoid congestion collapse.
• Retry-After is also bad because it can cascade onto other overloaded elements (only active elements are overloaded).
• Has actually crashed networks in practice today.
• 503 actually means lots of things - overloaded and protocol errors are conflated.
• Do not have have proposed solution yet, only requirements.
• Steve Norris - when people don't have this mechanism, they benefit over people who do.
  
• Jonathan - this isn't a new problem, has been studied a lot in TSV, have asked for their help here.
• ??? don't make things binary - two values ("stop sending me stuff", and "start sending me stuff"). Also OK to reject REGISTERs, then INVITEs, then ...
• Rohan - what to do when I get 503s from three different proxies? Jonathan - should be changed to 500 at proxies - Robert - but it's widely implemented, and widely implemented wrong. This is very valuable, needs to be high priority.
• ??? - No way for downstream proxies to tell sending proxy to send things "somewhere else".
• Magnus - need to cooperate between SIP and traditional TSVs. Is this total load, or nework load? It's load on the SIP proxies (not at TCP layer).
• Steve - please comment on TISPAN, too!
• Allison - gave plug for this in TSVWG, what's the best data they can be looking at, so they understand what you're worrying about? People would love to load up simulators, etc. and give you something that will work. Actual topologies, what's the load, where does the problem occur, etc.
• Sohal Khan - good work here. When you turn on a new proxy and do discovery? This isn't quite in scope now.
• James Polk - shape feedback to the upstream proxies? (I'm at 70 percent now...)? This is actually the right way to go, and is in the draft now.
• Keith - what aspects of this might be more general and solved more generally?
• Gonzalo - continue this work? Hums are "yes", none opposed.
  

0950 - 1000 10 minutes Steffen Fries SIP Identity Usage in Enterprise Scenarios draft-fries-sipping-identity-enterprise-scenario-02.txt

• Completely rewritten since IETF 64.
  
• Defines BCP approach (uses SIP-Identity, MIKEY), uses in-band protected certificate provisioning with implicit binding to an identity.
• Interest in bringing this work forward?
• Jon - thought the draft is much clearer in this version. May be closer to RAI area discussions earlier this week (although we are talking about signaling, not securing the media).
• Gonzalo - now doing security in SIP now, not SIPPING

1000 - 1010 10 minutes Jani Hautakorpi Requirements from SIP Session Border Control Deployments draft-camarillo-sipping-sbc-funcs-03.txt

• Draft name has changed ("requirements from SBC deployments").
• Would like list of SBC functions to be as complete as possible.
• Gonzalo - questions at previous meetings were on scope, and people seem to be happier about this version.
• Jon - doing work in this direction is still very important, because of reasons we've already talkd about. Don't know how we will accomplish usable SBC deployments.
• Andrew - "list of things that we recomment what SBCs don't do"?
• Jon - judgement and censure are probably not useful for us.
• Andrew - point is that people make informed decisions, not that they make specific decisions.
• James Polk - motivation per requirement? Agree that we are not the police (but then James flogged Jon with his ponytail). May not even keep them in the document, just to help us move the documents along.
• Gonzalo - hum was to continue this work in the future.
  

1020 - 1030 10 minutes Salvatore Loreto Same Session Header Field draft-loreto-sipping-dialog-correlation-00.txt

• People may want to use different devices for a single session - use Same-Session header field to allow correlation.
• JOIN behavior - how to signal to remote end point? Is JOIN the right way to do this?
• Rohan - not quite "same session", but the "same conversation" - a focus gives you a control point. This doesn't have to be a "CONFERENCE", existing messaging is almost sufficient. Need to think about what happens when you have four nodes, not just three.
• Paul - why aren't these nodes using 3PCC to correlate two devices without annoying other devices on the call?
• Cullen - I thought this included mixing, and now I'm understanding that it doesn't.
• Gonzalo - 3PCC introduces considerable complexity here.
• John Elwell - Don't think JOIN is appropriate mechanism here, not sure we have the right architecture.
  
• Jonathan - JOIN doesn't mean you are conferencing, it means you support JOIN. This is a lot like the IMS discussion - still on the fence with this.
• Gonzalo - 3PCC does work, it's just more complicated.
• Gonzalo - will continue to work on this,
  

Jason Fischl SIP for Media over DTLS draft-fischl-sipping-media-dtls-00.txt
5 minutes Haseeb Akhtar New SIP Headers for Reducing SIP Message Size and 3G Wireless Support in the SIP/SDP Static Dictionary for SigComp
 draft-akhtar-sipping-header-reduction-00.txt
 draft-akhtar-sipping-3g-static-dictionary-00.txt

• Wireless bandwidth is very restricted, even for 3G/4G - average throughput per user is KB/sec, much lower than native speed.
• Would also like to do initial SIP messages over control channel (and there's a serious size limit here, something around 200 bytes).
• Initial SIGCOMP isn't enough - conservative estimate is 50-percent reduction.. INVITE does not compress well. Two URIs plus Contact, plus identity leaves 80 bytes for the rest of the mesage.
  
•  Persistent states across calls may not be a viable option.
• Cullen - if you don't use persistent state across calls, your INVITE gets bigger because you are sending entire dictionary at the beginning of each call. This isn't enough motivation to create a profile of SIP.
• ??? - ???
• Cullen - need to involve ROHC here.
• Sohan - have been through five or six proprietary solutions here. Like IETF, like IETF RFCs, need to work on this mechanism. Thank Nortel for showing their solution here.
• Ben - we thought SIGCOMP was the solution - either it does or doesn't, we need to figure out what the requirements really are.
• ??? - does this negatively affect SIGCOMP?
• Gonzalo - will discuss with ROHC before we do anything.

1105 - 1110 5 minutes Peili Xu The User-registered Routable UA URL draft-xu-sipping-uruu-00.txt

• Motivation is that people have multiple phones, let people call exactly the right phones.
• Adds a human-readable field to AOR.
• Relationship with GRUU - they are different, and serve different requirements. They can coexist.
• This is similar to ISDN "sub-address" mechanism (and interworks with this as well).
• Naming versus feature? prefer naming-oriented.
• Subnames are REGISTERed and and may be called directly.
• Rohan - thank you for clearly explaining use cases in draft and in presentation. If you can route to an instance-ID using Outbound, and the instance-ID has a description, would that be sufficient? If Bob can build names like bob.office in my own system, is the requirement is to interwork in a heterogenous environment? User can control this.
  
• Paul - more to say about use cases - there are ways to meet most of these requirements, but not in the same way for each requirement (sub-addressing is already in TEL URI, for example). This is a good start at requirement, need a little more requirements work and then can tell if we can already solve the problems at that point.
• Andrew - look at rich presence context and then re-examine.
• Brian - explain why existing mechanisms don't solve the problem in the draft ("next revision of the draft").

1110 - 1120 10 minutes Xiao Wang Requirements for batch Subscriptions Refreshment draft-wang-sip-brs-00.txt

• Issue is refreshing soft state for lots of subscriptions between servers - using bandwidth, server resources, etc.
• Extend SUBSCRIBE-NOTIFY or define new method to refresh multiple subscriptions
• Comments on draft?
• Gonzalo - please get involved in drafts and see if we get traction
  
• Andrew - agree this is important, may even kill deployment of presence in wireless world
  

1120 - 1130 10 minutes Rocky Wang A method to override the barring services draft-rocky-sipping-override-barring-00.txt

• Follow-on to IETF 64 - using SAML and other methods to override call barring solutions.
• Three kinds of overriding - by priorities, by password ... are there any others?
• May use SAML, may use CPC from PSTN model
• Will collect the service flow using CPC parameter extension defined in draft-mahy-iptel-cpc
• Who read the draft? A number of people
• Andrew - is this emergency service, or is there another scenario? Just one piece of this.
• Rohan - PacketCable did a proprietary mechanism for ordinary operator barge-in, not emeergincy service.
• Jon - Tunneling PSTN network parameters that servers have to understand introduces questions about interworking, and our overall strategy. Include certain ISUP parameters within SIP may make sense, tunneling may not be the preferred solution.
• James Polk - one example of user to call police officer directly? That would be a problem with wild security problems involving DOS attacks on police. Rocky - could this be useful? James - probably a three-party call.
• Steve Norris - don't forget CPC codes aren't completely standardized in the world (regional codes, etc.).

SAML-CPC draft

• Follow-on from previous IETF discussions. Need to hook better to SAML.