SIPPING NOTES, August 3, 2005 (IETF 63, Paris) STATUS AND AGENDA BASH ====================== Presenter: WG Chairs Refer to slides for: - RFCs posted since last IETF - Drafts in RFC Editor queue - Drafts with Area Director or IESG Torture test draft (draft-ietf-sipping-torture-tests-05.txt) has some problems with the S/MIME examples. Dean Willis and Cullen Jennings noted that examples in drafts need to be correct in general. Following 4 documents are past Working Group Last Call: 1) URI-list Services A bunch of drafts. Waiting for consent framework. 2) RTCP Summary There was a submission problem in the last IETF as well as this time, which should be resolved after black-out. Dean Willis noted that a few more changes are still needed (minor stuff). 3) Trait-based Authorization Document received few comments during WGLC and chairs asked if the document is really ready. Dean Willis (chair) asked for a hum from people that read the document and thought it ready. Few people had read it. Consensus among those that read it that it's ready. Jon Peterson noted that everybody thinks it's a good idea, but nobody seems to really care. Gonzalo Camarillo (chair) said that the chairs will do a thorough review. Volunteers solicited as well 4) PoC Settings Event Package Expert review has been performed There is one ongoing Working Group Last Call: 1) Call Control Transfer (draft-ietf-sipping-cc-transfer-05.txt) - Open Issue with Multiple-Recipient MESSAGE draft (draft-ietf-sipping-uri-list-message-03.txt): The draft is done and waiting for the consent framework, however it is inconsistent with SIP guidelines for extensions and NIT actions. Rohan Mahy (as chair) has some concerns with the document (congestion seemed to be a concern). The other two chairs (Dean Willis and Gonzalo Camarillo) do not share the concerns. It was noted that OMA is using the draft and some warnings could simply be added to the text. Cullen Jennings noted that this has been discussed before (extensively), and we came to consensus back then (a year ago). Miguel Garcia-Martin stated that we had already agreed to do this. OMA needs it. A bit late to deprecate. Markus (Isomaki ?) thought it was useful and that there are no good alternatives on the table. Rohan asked if it is harmful Markus stated that if there are issues, they should be documented in draft, but should still go forward. Rohan asked if there were any objections to take forward with warnings added. There were no objections and Gonzalo (chair) noted that there was consensus to go forward with warnings added. The following individual submissions were discussed briefly: 1) draft-sohel-sipping-s-bc-concept-arch-00.txt Not really in scope of SIPPING (talking about decomposition). Maybe SIP Forum can take a look at it or move forward as individual. 2) draft-elwell-sipping-redirection-reason-02.txt: May be used for TISPAN. Need discussion around Reason phrase and how to use it in responses (per TISPAN adhoc) anyway. Reason phrases in responses in pure SIP is bad. Open issue if ok for PSTN interwork. A few comments followed Cullen: The problem has showed up in various drafts. Seems clear we need to deal with the problem at least. Jon Peterson We do want to examine the problem. Problem is tunneling the information in other protocol. Need to do someting that works for native SIP. Francois Audet: Don't like using existing PSTN code points (too many). Should not have PSTN pollution. Gonzalo (chair) concluded that we will study problem. WG is interested. Will talk to ADs. Later on will determine if this draft will be adopted or not. 3) h323-sip-conf-requirement: Gonzalo (chair) stated that he doesn't see WG expertise and interest on this. 4) draft-levin-simple-interdomain-reqs-02.txt: Currently in -03 version (just before Paris). A few comments were made regarding this: Cullen: Disagree with slide. Good to have BCP for this stuff, but not clear this document is right for that. Need to wait for VOIPPEER BOF output (this doc will be discussed there as well) Orit Levin: Agree with slides Jon Peterson: VOIPPEER is not about e-mail etc. so draft may not necessarily fall there. Henry Sinnreich:Topic being discussed all over the industry. If you disagree with draft (as Cullen does) then somebody should write another draft Aki Niemi: Title wrong. Should be "how to build a walled garden in SIP/SIMPLE". Draft author (not Orit): Important topic. Gonzalo (chair) concluded that there is in the topic. Some agree with draft, some don't. Discuss on mailing list. Need to discuss with ADs on whether can get added to charter 5) draft-hasebe-sipping-exceptional-procedure-example-01.txt Clarifying exception procedures. Want call flows for things that are not clear in the RFCs. Some claim these are not just examples but actually clarify the RFCs. Few comments followed: Gonzalo: Seems there is interest, however should it be individual or WG ? Cullen: Important, lots of people like them. Doesn't really matter whether individual or WG item. Paul Kyzivat: Agree with Cullen. Gonzalo (chair) then took a hum on whether this is useful work in SIPPING. There was consensus that it is useful work in SIPPING. A few volunteers agreed to work on it. 6) draft-aki-niemi-cal-events Aki Niemi asked for people to take a look at it and read it. - Milestones were discussed: Gonzalo noted that some people cannot update the milestones on the IETF web-site. Cullen Jennings asked for milestones to be updated on the softarmor web-site then. Dean asked that if people have concerns with the milestones, then they should post to the mailing list. Finally, there was discussion around updating milestones. In particular, it was requested that WGLC should be scheduled ahead of time (and not all at the same time). SESSION-INDEPENDENT POLICIES ============================ Draft: draft-ietf-sipping-session-indep-policy-03.txt Presenter: Volker Hilt Volker presented status of the session independent policy work (see slides for details). Major change: alignment of policy format with profile datasets framework (the structure of the ID was also changed as a consequence: policy attributes went into policy framework, etc.) The authors asked for people to comment on the draft. SESSION-SPECIFIC POLICY USE CASES ================================= Draft: draft-hilt-sipping-policy-usecases-00 Presenter: Volker Hilt Volker presented the draft (see slides for details). SESSION-SPECIFIC POLICIES ========================= Draft: draft-hilt-sipping-session-spec-policy-03 Presenter: Volker Hilt Design of policy channel between UA and Policy Server is major open issue right now (see slides for details). The policy channel is used to a) Submit session information to policy server b) Retrieve session policies from policy server The mechanism for retrieving session policies is subscription-based: * UA subscribes to policies on the policy server (policy server URI received during the INVITE transaction) * Subscription covers the policies the policy server as composed for the UA (one subsription per session or long-running subscription covering all active sessions) * Policies and policy changes are conveyed via notifications. The mechanism is furthermore based on the config framework: * introduces new profile type "policy" * decouples subscriptions to session-specific policies from other sources of profile information * Same mechanism as for session-independent policies (adds another source of policy information the UA needs to consider for it sessions) * Alternative: Define a new policy event package A few comments were made on this: Constantino (?) : Comment/concern around efficiency when having to get policy all the time. Especially on wireless networks. Gonzalo: Will take efficiency into consideration when designing details. For the use cases, we should consider use case with two policy servers Volker: Just doing the same thing twice. Gonzalo: Would be good to include in scenarious document. Submit Session Information * Three alternatives considered last time. Proposal this time is to use PUBLISH-based mechanism: + UA uses PUBLISH to convey information about current session to the policy server + Policy Server composes policies for the UA and makes them available through a subscription + UA can setup subscription and publish session information at the same time + Third parties may also publish information that is relevant to session policies. The following comments were then made: James Polk: A UA publishes to a compositor (which then publishes to policy server) or to the policy server ? Volker: PS is the compositor. Rohan: Not publishing policy, publishing a filter effectively. Volker: There is some processing on the policy server based on input it receives from multiple sources. Bandwidth information may be provided to the policy server. Gonzalo: BW information, etc. and other resource information to the PS is out of scope of what we are doing here. Rohan: What we are really just doing here is providing information to the policy server Cullen: Either providing a proposal or a filter on different proposals. Is the question "I'm using port 5060, or I need to use a port" ? Jonathan: SDP is describing what we'd like to do. One answer can simply be yes or no. Another could be more detailed, e.g. "remove the video". Rohan (chair) concluded that more discussion around mechanisms is needed here (on the list). CONSENT FRAMEWORK ================= Draft: draft-ietf-sipping-consent-framework-02.txt Presenter: Gonzalo Camarillo See slides for details. Fundamental architectural change this time * Simplifies approach, previous approach was getting complicated and lot of overhead. Following e-mail approach now. * Consent applies when users are added to a translation at a relay * Not when the translation is executed at the relay * Like in an e-mail mailing list. Decoupled: * Requesting for permission * Amplification attack avoidance + Credit-based approach. + Adding 3000 users, you will need to go ask 3000 people if they are ok with that. + Avoid amplification attack by imposing same overhead on requesting user as requesting user is imposing on the relay (i.e. 3000 messages in this case). Authentication Model: * Return routability (CONSENT carries unguessable URI that the PUBLISH needs to be sent to). * SIP Identitity can be used if available Simplification: * The Relay is always the one that sends the CONSENT (allows for migration from return routability to SIP identity) * Assume that endpoints cannot sign their permission documents. * Simple mechanism for inter-domain scenarios * A different mechanism to deal with your registrar (e.g CPL). Registrar problem out of scope for now. Comments from floor: Jon Peterson: Why does REFER go to relay instead of directly to user being added to relay (which then sends PUBLISH to relay) ? Gonzalo: The relay is always the one that sends the CONSENT (message). Allows for an easy migration from return routability to SIP identity. Assume that endpoints cannot sign their permission documents. Jon: There are alternatives to SIP identity. Don't need to create state in relay. Will go read the draft. Cullen: Want the indirection where requested cannot talk directly to the added user (doing it through relay). Need for anonymous participant on list. Dean: Previous approach used per sender/recipient pair authorization. Now it is per receiver/list authorization. Permission document format: * target (relay performing the translation) * sender (needed for relays that handle request-contained URI lists, e.g. an INVITE with a URI-list in it) * recipient * Operations (methods) Jonathan Rosenberg noted that senders could be modeled as a list (?). Gonzalo agreed with that. Permission Revocation: * Upload an "empty" permission document to the relay Aki Niemi: How does user B revoke permission in the env where permission was granted in one UA and you want to revoke in another ? Gonzalo: Need knowledge of secret-URI to revoke it. Details to be worked out on how to share among multiple UAs. Note that 3rd party registrations is something we don't handle now (registrar out of scope). Comments were then solicited as to whether people think this is the right approach: Paul Kyzivat: Concern about additional burden on registrars. Gonzalo: Registrar ruled out of scope for now so not an issue. Jonathan: Originally, translation was the thing that was protected and applied equally well to register and non-register. AOR to contact translation is translation as well. In case of third-party registration, the consent is not obvious (registering something else than my own AOR). Gonzalo asked if the WG is comfortable with this direction. There was consensus on the direction. SIP-UNFRIENDLY FUNCTIONS IN CURRENT COMMUNICATION ARCHITECTURES =============================================================== Draft: draft-camarillo-sipping-sbc-funcs-01.txt Presenter: Jani Hautakorpi Purpose of document * Document those functions in current communication architectures that break SIP in some way * These functions are caused mainly by Session Border Controllers (SBCs) * This document provides a foundation for future work (identity existing mechanism and/or new work) Changes since -00 * Two drafts from previous IETF have been combined here Next steps: * Author's see document as stable enough for future work to be based on it * Does the WG want to adopt this draft as a WG item. Comments from the floor: : Deployment scenarios document as well (on SBCs ?). please read Gonzalo: To be clear, this document is not just about SBCs. Jonathan: Helpful document. VOIPPEER BOF seems to play in here as well. A good idea to collect requirements from there. Gonzalo: ADs are interested in documenting things that break SIP. Rohan (as individual): Interesting work. Should continue working on it. Jon: Important to recognize that VOIPPEER looks at a very big picture. Not clear it would be the right place to talk about a document like this. Probably good to get requirements from there, but if working on doc it should probably be in this group. Cullen: Have comments on the draft (don't agree with everything in there). For example, it talks about what happens with B2BUAs breaking SIP, but doesn't talk about Record-Routing. There is a lot of listings in there, but not much explanation of the actual issues. Jonathan: Agree with Cullents point. Would also like to hear more details. Should definitely write these things down. Doesn't necessarily need to go to RFC James Polk: Like the work. One-line statements however are not sufficient. Need more detail. Rohan: Send these comments to list and/or authors. Robert Sparks: Clarify what the purpose of the draft is. Do we just identity problems or do we also identify solutions ? Need to be clearer for next round. James Polk: Concern with documenting shortcomings (may linger around as RFC even after they get addressed - see that all the time with RSVP) Francois Audet: Have to be a bit careful about very general statements. Henry Sinnreich: Could be home for the 10 transparency principles announced by Dean long time ago. Rohan: Please post those to the list. SIP EVENT THROTTLES =================== Draft: draft-niemi-sipping-event-throttle-03.txt Presenter: Aki Niemi Summary of changes * Explicitly uses Resource List Server (RLS) to aggregate a set of subscriptions (fairly major change in scope) * RLS now does throttling + Throttle much more efficient + Better probability for support (support much more likely here than on all endpoints) + Ability to change throttle on the fly * Author's view: this should now address most of people's concerns. Comment from floor: Andrew Allen: Does this restrict the scope to RLS ? Aki: Can still use it in other places, but is meant to be used with RLS. Do need an RLS to make full use of it though, but doesn't limit it to RLS. Open issues: * Default throttle for a resource list ? * Proposal: extend list format * Ability to send out-of-band * Require issues (option tag) + Keep it or loose it ? Comment: Aki: People say not needed, but don't see that. Rohan: To summarize the issue. Could always unsubscribe if filter not supported. Can always look at response code indicating body not supported (?). Open issues, continued: * RLS batching: need to define the algorithm + Avoid starvation + Implies a "nice" value per buddy ? + However, is this really going to be a problem ? Comments from floor: Cullen: Never reordered messages, which is critical. A "nice" value would seem to violate that which is a great concern. Aki: RLS not reordering notifications for a particular subscription. Cullen: Seems to limit scope to specific buddy-list use case. Aki: Don't believe so. Maybe take this to the list. Aki: Agree with Cullen that it seems very complex. Rohan: Does anybody feel they really need this (batching functionality). Jonathan: Don't mind it, but shouldn't be in this document Rohan (chair) noted that it should not be in this document (consensus on this point). Summary: * Use throttling to list subscriptions * Is this starting to look more reasonable ? + WG item (in SIP) ? Rohan (chair) asking for consensus on direction of work. There was consensus that it's the right direction. Roham (chair) asking whether it is ready to send to SIP. Notetaker heard few hums for ready and few hums for not ready (consensus did not seem clear). SIP EVENTS FRAMEWORK ISSUES =========================== Draft: draft-niemi-sipping-subnot-issues-00.txt Presenter: Aki Niemi Problem #1: Inability to Persist state * Not possible to carry over state in refresh * Notifier always sends the latest state (even when subscriber has it already) * Contrast: Conditional HTTP GET (If-None-Match: "etag") * Solution: Suppress superfluous NOTIFY + NOTIFY cariers SIP-ETag + SUBSCRIBE carries SIP-If-None-Match * Open Issue: What to suppress + Entire NOTIFY or body only ? Comments from floor: Cullen: Don't understand the HTTP analogy. HTTP is a polling mechanism. Here we should only get a notify when something actually changes. Rohan: Clarify that you have some of the state info already. Rohan: Like second approach of omitting body. Jonathan: Seem to be jumping into solutions. Reasonable thing to look at but need to take a step back. If attachment to network changes I need to resubscribe. GRUU helps here since GRUU doesn't change in that case (adds a layer of indirection) and hence you don't need to resubscribe to everything. Rohan: Still need to refresh the subscribe in order to make sure you didn't loose anything. Jonathan: Seems to get into handoff detail. Not clear you lost anything. Rohan: Even so, still a problem if you just refresh your subscription. Sparks: Slides seem to talk about NOTIFYs within a subscription. Also applies across SUBSCRIPTIONS. Aki: Yes - trying to solve both of those (essentially, do I already have the state, irrespective of whether I have a subscription or not). Adam Roach: Suppressing body seems OK (similar to what HTTP does - sends a 204: there is nothing here for you). Problem #2: Intolerance to Network Connectivity Hiccups Aki: Note error in draft. Not a MUST terminate subscription, but SHOULD. * If NOTIFY times out, the notified SHOULD terminate subscription + Not clear when not to terminate it (fail soft) and how + Assumes subscriber refreshes when net is back + Bad user experience in long-lasting subs * Solution: Define behavior for failing soft + When ? + How ? * Eg., back-off scheme and suppress state + Subscription-State: zombie;reason=timeout Comments from floor: Rohan: If keep sending NOTIFYs, how long do you keep on doing it (e.g. if phone is gone) ? Difference between intermittent loss of connectivity and ... Aki: Discussed a bit on maling list last week and reasonable proposal made. Try to send a NOTIFY and then back-off exponentially up to a certain time limit and then give up. Cullen: Have some concerns. Also, most of the NOTIFY's will be so big they don't fit in the MTU so will use TCP, and in that case it's not clear there's really a problem. Adam: If expiration times are on the order of days, then this is a problem but you shouldn't do that. Aki: Well, certificate package does have a long expiration time Jonathan: Maybe it shouldn't then. : Agree with Cullen's point. Sparks: Some confusion around timeout of subscription versus timeout of transaction (in draft ?) Aki: Agree, will remove second problem and only deal with first. REG EVENT PACKAGE EXTENSIONS ============================ Draft: draft-kyzivat-sipping-gruu-reg-event-03 Presenter: Paul Kyzivat Reason for draft: * The reg-event package is broken by the GRUU extension * Have proposed this before, but didn't get much traction. Proposal: * Add another "gruu" section to document returned by reg-event. * Draft defines extension element for application/reginfo+xml Paul asked if we should fix the reg-event package this way ? Dave Oran said it was sufficiently simple to just last call. Dean Willis (chair) asked if anybody would object to doing this. Nobody objected. Rohan (chair) asked that Paul submit it as a WG document after which there will be a WGLC on it.