RE: [Sipping] Draft Minutes, SIPPING WG, IETF 56

["Drage, Keith (Keith)" <[e-mail]>]

Text of minutes:

"Do we want to work on this problem?  That is the real issue for us to 
decide now.

Many people approached the mic and agreed to the requirements being valid.

Gonzalo took a hum level on taking the requirements as base for the work 
going forward.  Hum level indicated interest."

Firstly, I thought the hum was on having a requirements document in this area being worked as a working group draft, rather than on the current contents. While I do not have any major issues with the contents, I prefer to get this correct.

Secondly, one of the comments I made at the mic related to the relationship to the solutions document in http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-session-policy-00.txt to the effect that the requirements document should be advanced, and when we have the requirements document agreed, we will then see if this solutions draft is the correct solution, or whether others exist. I think that it is important to capture something to this effect.

Keith

Keith Drage
Lucent Technologies
Tel: [phone]
Email: [e-mail] 

> -----Original Message-----
> From: Dean Willis [mailto:[e-mail]]
> Sent: 13 April 2003 02:29
> To: [e-mail]
> Subject: [Sipping] Draft Minutes, SIPPING WG, IETF 56
> 
> 
> draft minuets are posted at:
> http://www.softarmor.com/sipping/meets/ietf56/notes/minutes.html
> 
> text follows
> 
> Draft Minutes, SIPPING Working Group. IETF 56
> edited by Dean Willis
> 
> Session 1, Monday March 1700, 1930-2200
> 
> Scribe: Vijay Gurbani, Mary Barnes
> Chat coordinator: Al with the Hat
> 
> 
> Chairs called meeting to order.
> Agenda agreed as:
> 
> 1930 Agenda Bash
> 1935 Status -- Chairs
> Call Control Issues
> 1945 Service Examples, Alan Johnston
>     draft-ietf-sipping-service-examples-04.txt
> 1955 Call Control -- Transfer, Allan Johnston
>     draft-ietf-sipping-cc-transfer-01.txt
> 2005 Caller Preferences Use cases, Jonathan Rosenberg
>     draft-rosenberg-sipping-callerprefs-usecases-00.txt
> NAT and Policy Issues
> 2015 Persistent Connection Management Requirements, Vijay K. Gurbani
>     draft-jain-sipping-persistent-conn-reqs-00.txt
>     draft-ietf-sipping-connect-reuse-reqs-00.txt
> 2035 SIP Network Address Translation, Jonathan Rosenberg
>     draft-ietf-sipping-nat-scenarios-00.txt
>     draft-rosenberg-sipping-ice-00.txt
> 2045 Session Policy Requiments, Jonathan Rosenberg
>     draft-rosenberg-sipping-session-policy-00.txt
> 2055 URI Leasing, Jonathan Rosenberg
>     draft-rosenberg-sipping-lease-00.txt
> Design Teams
> 2105 SIP Conferencing Design Team, Alan Johnston
>     Web Page for the Design Team
> 2135 Application Server Interaction Design Team, Jonathan Rosenberg
>     Web Page for the Design Team
> 2140 Transcoding Design Team, Gonzalo Camarillo
>     Web Page for the Design Team
> 2145 Emergency Calls Design Team, Jon Peterson
>     Web Page for the Design Team
> 2150 Limiting Notifications Rate, Aki Niemi
>     draft-niemi-sipping-event-throttle-reqs-01.txt
> 2200 Wrap
> 
> 
> Topic: Service Examples, Alan Johnston
> 
> Moving well. Author wishes to add some text discussing how to 
> implement 
> some servcies and discussing trade-offs and expects that 
> draft will be 
> complete before next meeting
> 
> Topic: cc-transfer, Alan Johnston
> 
> Slides presented, included in proceedings.
> 
> This version had few changes: added a section on use of Referred-By 
> header.  Added selected message details.  Added many more 
> call flows on 
> attended transfer and unattended transfer.  Added a security 
> consideration section.  No known open issues with the I-D. 
> Group polled 
> on readiness for WGLC: No objections noted.  Audience asked 
> if there was 
> any overlap or dependency on globally-routable contact URI 
> work. Author 
> belives there is currently no dependency, but that if the GRURI work 
> completes, it would be nice to reference it from this draft.
> 
> 
> Topic: Status report: Chairs
> 
> Slides presented, included in proceedings.
> 
> We have 3 RFCs which have been published, considering the 
> amount of work 
> we had on our plate.  2 on IESG queue; bunch of individual I-D. 3 in 
> here that are ready for WGLC.  A lot of work is blocked on 
> other stuff 
> -- call control, ICE, work going on in midcom, etc.
> 
> Note chairs believe that formal expert review is not required for all 
> individual drafts. Current policy is to announce the draft to 
> the list, 
> and ask the participantst to verify that the draft does not conflict 
> with WG efforts. Under the current process, we do a formal 
> expert review 
> for P-headers or when asked to do so by IESG/ADs.
> 
> It may be useful for us to split things into smaller groups 
> -- some I-Ds 
> document usage of SIP, others talk about services (cc-conferening, 
> cc-transfer).  It may be appropriate to let some of this work proceed 
> without supervision of the WG.  We may end up doing this in Vienna in 
> order to get up to speed.  Will like to get comments on the 
> mailing list 
> or after session on if this is okay.
> 
> 
> 
> Topic: Caller-Preferences Use Cases, Jonathan Rosenberg
> 
> Slides presented, included in proceedings.
> 
> 
> Poll: Useful, interest in accepting as WG document? Strong consensus 
> recorded. AD suggested that these use cases be packaged with 
> CallerPrefs 
> drafts.
> 
> 
> 
> Topic: ICE, Jonathan Rosenberg
> 
> Slides presented, included in proceedings.
> 
> Provides general methodology for using address-fixing 
> protocols to get 
> SIP through NAT.
> 
> Question: What is the impact if some sort of underlying mobility 
> function causes node address changes? Does ICE resolve? Ans: Unknown, 
> but we think it should work if the frequency of address 
> changes is lower 
> than 1/RTT.
> 
> Question: Does having STUN server on every node open up the 
> network to 
> denial-of-service attacks on NAT translation? Ans: No -- at least, no 
> more than port-scanning already would.
> 
> Poll: Who read: fairly large number.
> 
> Question: Muxing STUN and media -- is that required? What is the 
> implication of demux? Ans: It seems to be feasible to use 
> magic-cookies 
> in the TUN level to work it out.
> 
> Comment: This DOES require widespread deployment to be useful, can we 
> get that? Ans: If it works, people will implement it.
> 
> Question: What are implications if only one end supports?  
> Ans: We fall 
> back to what we have now. Question: IS it easier to fix the 
> NAT than to 
> fix the SIP? Ans. Debatable.  There's a lot of $39 NAT boxes 
> out there.
> 
> Poll: How many people would be interested in implementing? (several) 
> Will one volunteer to write the preconditions (document 
> things like like 
> SDP changes, requirements in SIPPING) Yes-- Cullen Jennings.
> 
> Poll: Would you like this work to be documented in SIPPING, 
> along with 
> fallback to previous modes? Ans: Loud response, a few dissenters. 
> Proposal: Cullen to work on preconditions, Jonathan to work on 
> furthering ICE draft, WG to request authorization to pursue 
> as WG effort.
> 
> 
> 
> Topic: Session Policy Requirements, Jonathan Rosenberg
> 
> Slides presented, included in proceedings.
> 
> Slides presented reviewed scenarios. Poll: Do we want to work 
> on this? 
> Brian Rosen reports that he really needs this for dealing with 6Mb/s 
> streams and managing admissions policy dynamically. Another 
> comment made 
> that this approach could obviate the need for some B2BUAs. 
> Comment that 
> we should add requirements to do this without "new headers" 
> and it shoud 
> work with e2e encryption (req #1 in presentation). Poll: who 
> thinks we 
> should take this work on as a baseline for requirements? Strong 
> consensus reported, none opposed.
> 
> What happens when a service provider wants to insist on some 
> aspects of 
> a session (media flows through a realy, video not be used, 
> etc.) So far 
> this has been done with SDP modification.  Well known 
> problems: does not 
> work with data encryption, requires proxies to have knowledge 
> of session 
> descriptions, proxy complexity increases, ...
> 
> Solution: 3GPP does this -- they use 488 as a response code to list 
> codecs which are acceptable.  This has some drawbacks as well.
> 
> Do we want to work on this problem?  That is the real issue for us to 
> decide now.
> 
> Many people approached the mic and agreed to the requirements 
> being valid.
> 
> Gonzalo took a hum level on taking the requirements as base 
> for the work 
> going forward.  Hum level indicated interest.
> 
> 
> 
> 
> Topic: URI Leasing, Jonathan Rosenberg
> 
> Slides presented, included in proceedings.
> 
> Material introduced from slides.
> 
> Question: This allows for temporally scoped URIs. Can we give 
> an example 
> of where this would be useful? Ans. Assume a conference call running 
> over a set time. Discussion that current document may be a 
> bit complex 
> in this area. The word "temporal" is probably misapplied in 
> this context 
> and the author would like to withdraw it. This all comes down to 
> embedded route headers vs. a lease-and-preference model. 
> Perhaps we need 
> to step up a level and ask what the top-level requirements 
> really are? 
> The draft proposes three explicit. There may be also "without hiding 
> state in the domain name" and some others.
> 
> Comment: Leasing seems to imply temporal scoping. Huh? Long 
> discussion . . .
> 
> Comment: It seems that all of the given requirements could be met by 
> relaxing a single restriction in 3261.
> 
> Conclusion: More list discussion on requirements needed.
> 
> 
> 
> Topic: App Interaction Design Team, Jonathan Rosenberg
> 
> Slides presented, included in proceedings.
> 
> Minimal activity since last meeting. We should develop use cases 
> illustrating the requirements. Jonathan Rosenberg requested that 
> proposed use cases be sent to him via email.
> 
> 
> 
> Topic: Persistent Connections, Vijay Gurbani
> 
> Slides presented included in proceedings.
> 
> Basics presented. Discussion ensued.
> 
> Question: What is the requirement difference between signaled 
> persistence and simply configuring persistence?
> 
> Assertion: Reuse is only important in the client-server case.
> 
> Assertion: This sounds like my kids discussing bedtime. There 
> is really 
> only reason to close a TCP connection -- to recover resources. 
> Therefore, the interesting thing, is not how do connections 
> come up, but 
> figuring out which connection to kill if we need to kill one.
> 
> Assertion: the mechanism here is equivalent to "just doing the right 
> thing" with TCP, so we should fix it operationally, not by 
> changing the 
> protocol.
> 
> Poll:  Should we change the SIP spec to encourage leaving TCP 
> connections open unless they need to be closed? Strong consensus 
> reported. Proposed that we do minimal bug fixes in SIP, and do a 
> separate document with an operational focus on "how to" reuse TCP, 
> initially as a discussion and possibly leading into a BCP. No 
> objections 
> noted. Vijay Gurbani may volunteer to lead on a usage document.
> 
> 
> 
> Topic: Conferencing Design Team, Alan Johnstson
> 
> Requirements, Framework, and Call Control ready for WG adoption. 
> Conference Policy is splitting into two and should be ready shortly. 
> Media policies work requirements progressing, work on policy 
> manipulation is ongoing, and the policy work needs a new 
> home. MMUSIC is 
> not going to adopt this in their new charter.
> 
> Question: This policy work is related to data manipulation in SIMPLE, 
> can we combine it? Ans: Probably not. One is data manipulation, the 
> other is policy RPC.
> 
> Open issues recapped in slides.
> 
> Discussion of absolute vs. relative time in focus. Why not 
> have absolute 
> time? Ans. Simplifies timeing coordination on focus.
> 
> Comment: We do have requirements for realtime transitional 
> controls for 
> things like camera-follows-speaker. SOAP and ACAP don't 
> combine to meet 
> this requirement. Ans: This is for more persistent policy, not 
> floor-control. Floor-control remains a media problem.
> 
> Poll: Do we wish to, as proposed, adopt the requirements, 
> framework, and 
> call control drafts as wg efforts? Strong consensus, no objections.
> 
> Question: Is discovery in-scope? It could be a furball.
> 
> Request: Make focus migration happen sooner rather than 
> later. This will 
> be required for three-way to more-way migrations. This is 
> also important 
> from a fault recovery standpoint. The call-control is easy, 
> just a REFER 
> series, but handling the policy migration is more interesting.
> 
> Discussion: Policy group needs working group home.  Rohan: 
> mmusic will 
> NOT be chartered to do this; so it is either us or a new BOF. 
>  Will work 
> it out with the ADs later.  We have not been told that we 
> have to stop 
> working on this.
> 
> Open issues: conference policy protocol, floor control, notifications.
> 
> Proposed: Adopt Reqs, framework, and call control I-Ds as WG 
> documents. 
>   Poll taken, and strong consensus reported.
> 
> Open reqs: discovery, focus role migration, cascading and 
> camera control.
> 
> 
> 
> Topic: Hearing impaired media transcoding, Gonzalo Camarillo
> 
> Work proceeding, no surprises.  Author reports little  progresssince 
> last IETF and  believes that now that we have media policy I-D and 
> session policy reqs, we will make more progress for the next IETF.
> 
> 
> 
> Topic: Emergency calling design team, Jon Peterson
> 
> Work proceeding, will try to have face-to-face meeting here. 
> Two cases 
> -- regular 911 calls, and PSAP access-link replacement. Can we divide 
> these two cases so that there is something available for 
> "today's PSTN 
> PSAP"?
> 
> 
> 
> Topic:  Event Throttling Requirements, Aki Niemi
> 
> Notification rate limiting is the "common factor" among most of the 
> event filtering discussions. Issues: Is the model accurate and 
> appropriate? Do we need both the leaky bucket and the strict 
> throttle? 
> Is it ok to leave handling of quarantined notifications out 
> of scope? Is 
> this work useful?
> 
> Discussion: It may be important to have a different 
> throttling mechanism 
> for "aggregated/filtered" notifications than for simply 
> prioritized or 
> decimated notifications. The current work does not really consider 
> notification volume/size, just counts. Discussion about the 
> difference 
> between quarantine and gating/throttling functions. One can define a 
> five-token multibucket scenario that's fairly complete. Is this too 
> complicated to be practical? Volutneers to review reqs -- Jonathan, 
> David Oran, and Tomn Taylor volunttered. Poll for adoption: none 
> opposed. Question: Is there standardization required to be 
> able to rate 
> limit?
> 
> Event Throttle Requirements, Aki Niemi
> 
> Aki went through the model and the requirements (see slides). 
> Issues: Is 
> the model accurate and appropriate? Do we need both 
> leaky-bucket and the 
> strict throttle models, or is only one of them enough?
> 
> Observation from floor: Quarantining and throttling are not the same 
> thing. One introduces delay the other control rates.
> 
> Rohan: Jonathan, Dave Oran and Dean will review the I-D and 
> the  WG will 
> receive an update from them before this becomes a WG document.
> 
> 
> 
> 
> 
> Session 2, Wednesday March 19, 1530-1730:
> 
> Scribes: Paul Kyzivat, Vijay Gurbani
> Chat coordinator: Brian Rosen
> 
> Session called to-order by chairs. Agenda agreed as follows:
> 
> 1530 Agenda Bash
> Security Related Issues
> 1535 Role-based Authorization Requirements, Jon Peterson
>     draft-peterson-sipping-role-authz-00.txt
> 1545 Request History, Mary Barnes
>     draft-ietf-sipping-req-history-02.txt
>     draft-barnes-sipping-history-info-02.txt
> Operations
> 1605 SIP Endpoint Service Charging Requirements, Wolfgang Beck
>     draft-beck-sipping-svc-charging-req-01.txt
> 1615 SIP User Agent Configuration - Dan Petrie
>     draft-ietf-sipping-config-framework-00.txt
> 1625 Issues in Dual Stack Environments, Hakan Persson
>     draft-persson-sipping-sip-issues-dual-stack-00.txt
> 1635 SIP-AAA Requirements, Gonzalo Camarillo
>     draft-ietf-sipping-aaa-req-02.txt
> Media Related Issues
> 1645 Early Media, Gonzalo Camarillo
>     draft-camarillo-sipping-early-media-01.txt
> 1710 Network Announcements, Eric Burger
>     draft-burger-sipping-netann-05.txt
> 1720 Considerations on the IPREP Requirements, Jon Peterson
>     draft-peterson-sipping-ieprep-00.txt
> 1730 Wrap
> 
> 
> 
> Topic: Role-Based Authentication, Jon Peterson
> 
> Slides introduce concept. Question: Can you show some use 
> cases? Assume 
> two previously unassociated carriers in a federation wish to exchange 
> calls. One carrier issues an authorization object, which the caller 
> hands to the other carrier, allowing the call to proceed. 
> Other examples 
> followed.
> 
> Discussion from floor:  Are we proposing replacing identity 
> with  roles? 
>   Jon responded that this could encompass identity, but maybe not. 
> suggested from floor that we add more in doc explaining relationship 
> between identity and roles, agreed to by author.
> 
> Request: Somebody asked for more use cases. Was also 
> concerned whether 
> all stated  requirements were self consistent.
> 
> Observation from floor: Jiri Kuthan suggested that this was a 
> replacement/alternative for  network asserted identity.
> 
> Observation from floor:  Somebody suggested that Role wasn’t 
> exactly the 
> right term to use.
> 
> 
> 
> Topic: Request History Rqmts and Solution, Mary Barnes
> 
> Slides presented, included in proceedings. Mary Barnes 
> presented current 
> status of both documents. Both  requirements and solution 
> have had two 
> new versions since last meeting,  now up to -02. Mary 
> explained changes. 
> Of note - separating out security  requirements, to separate document.
> 
> Remaining open issue is security, which is work-in-progress, which a 
> seperate security solution draft expected soon.
> 
> Consensus that requirements document is roughly complete and 
> should be 
> referred to SIP WG for action. Chairs need to refer to AD for 
> approval.
> 
> 
> 
> Topic: SIP Endpoint Service Charging Requirements, Wolfgang Beck
> 
> Slides presented included in proceedings.
> 
> Introduces requirements and a model for third-party trust assignment 
> with SIP. Possibly combinable with role-based-authorization.
> 
> Proposal: this should be two drafts, one around charging and another 
> about advice-of-charge.
> 
> Comment: this seems to be limited to a fixedSIP architecture as 
> currently written.
> 
> Comment:  the evaluation of the requirements presented in the draft 
> would be greatly aided by the inclusion of use cases.
> 
> Comment: reading the document indicates a specific business model 
> in-mind. Work here should be network agnostic and not make 
> assumptions 
> about who is paying (like caller always pays) etc.
> 
> Question from chairs: Are we interested in trying to gather 
> requirements 
> to support an endpoint based charging model (i.e., not billing from 
> intermediaries). Consensus that we would like to see the work more 
> completely illustrated, including use cases, before 
> considering its utility.
> 
> 
> 
> Topic: Config Framework, Dan Petrie
> 
> Slides presented included in proceedings.
> 
> Open Question: Should HTTPS be a SHOULD or MUST strength 
> reequirement: 
> Ans. MUST implement, SHOULD use. Open Question: Is HTTPish 
> preferred to 
> LDAP or ACAP?
> Open Question: Is this related to NETCONF work?
> 
> Discussion: There are issues here that cannot be fixed with 
> HTTPS pixie 
> dust. You need a separate mechanism of top of HTTPS to verify the 
> identity of the node requesting configuration. Of course, 
> this needs to 
> be configured in. So there is a bootstrapping problem.
> 
> Open question: device identity parameters: User-agent header? New 
> header? No decision made.
> 
> Open question: How to indicate profile type? Accept-header or event 
> header parameter or request-URI? Comment: this is the same problem as 
> SIMPLE's buddy list management and should use the same mechanism. 
> Further discussion taken to the list.
> 
> Dan Petrie presented. Identified changes from prior version.
> (draft-petrie-sipping-config-framework-00)
> 
> There were comments about strength of use for HTTPS for content 
> indirection in here. General sentiment seemed to be that 
> HTTPS should be 
> MUST implement, SHOULD use. Other protocols other than http/https are 
> also possible.
> 
> Henning Schulzrinne said https isn’t enough. Said there were both 
> confidentiality issues as well as way to ensure the client gets the 
> right data. In absence of client cert, which you can’t assume during 
> config, presents difficult problems – how to bootstrap.
> 
> Dan acknowledged this problem, and said he has already proposed to do 
> work to deal with that. Further discussion went on. Rohan asked that
> this go to list.
> 
> Dan requested input on list for where device identification 
> should go – 
> in User-Agent header or somewhere else.
> 
> Discussion of profile type – where to indicate in 
> subscription. Jonathan 
> Rosenberg thought you could subscribe to a different request uri for 
> each kind of thing. Rohan Mahy disagreed. Was sent to the list for 
> discussion.
> 
> Jonathan suggested this is similar to SIMPLE problem regarding 
> buddylists, and the two works should be synchronized.
> 
> 
> 
> Topic: Dual-Stack Issues, Hakan Persson
> 
> Slides introduce problem and recaps several solutions. The "contact" 
> problem seems to be addressable in part by dual-interfaced 
> record-route 
> and in part by ICE. The document will be revisited by the author 
> exlporing usage of these techniques and, if the solution is 
> satisfactory, can become a usage document illustrating the 
> solution to 
> the problems it has already raised.
> 
> 
> 
> Topic: AAA Req, Gonzalo Camarillo
> 
> Slides presented included in proceedings.
> 
> Currently in WGLC. Poll: Any issues that have been missed? No new 
> issues. Attendees encouraged to follw WGLC.
> 
> 
> 
> Topic: Early Media, Gonzalo Camarillo
> 
> Slides presented included in proceedings.
> 
> Open issues: There appear to be three ringback states from ISUP, and 
> only two codes (180, 183) available in SIP. Not all protagonists are 
> present and the author proposes to hold a conference call for 
> resolution. Debate ensued anyhow, trying to capture essence of the 
> issue. Francois, Flemming, Rohan,  others agreed to send use cases 
> illustrating the issues they need solved. Poll: should we add 
> a flag? No 
> clear consensus
> 
> 
> 
> Topic: Network Announcements, Eric Burger
> 
> Slides presented included in proceedings.
> 
> Open Issue: Media on Hold? What does a media server do when 
> it gets put 
> on hold? This seems to be application specific, not a SIP 
> protocol problem.
> 
> Open Issue: 409 Result code proposal? Suggestion from audience Can we 
> TRY not to use things that are used in HTTP to mean something 
> different? 
> Sugggestion: Could we use a standard response code and a 
> Reason field? 
> Conversation deferred to list with emphasis on 6xx vs 4xx debate.
> 
> Open Issue: Multiple Media Streams:?  What do do then, to 
> play multiple 
> things? Eric asserted this isn’t an issue if the target uri is a 
> composite object. He wanted to know if that is the 
> predominant use case. 
> And if not, how would the multiple streams be synced? Brian Rosen 
> wondered why it isn’t good enough to pick one stream. 
> Confusion reigns, 
> deferred to list.
> 
> Open issue: IS everything in this draft consistent with WG usage? We 
> need to be sure we're aligned with conferencing and early media work? 
> Author asked to work with Alan Johnston on conferencing 
> alignment, and 
> Gonzalo Camarillo on early media.
> 
> 
> 
> Topic: IEPREP Considerations, Jon Peterson
> 
> SIPPING asked to provide formal response to the IEPREP 
> considerations, 
> widely discussed on mailing list. Open Issue: SHOULD we address this 
> here? As there is already work in SIP on the priority header? 
> Should we 
> do it here?
> 
> Discussion:
> 
> Jon Peterson presented. Said this work was in response to requests by 
> area directors for comments on RFC3478. This is Jon’s private 
> attempt at 
> comments, based on some discussion on list.
> 
> Jon raised privacy issues. Henning said there are fundamental 
> tradeoffs 
> between privacy and proxies, and that therefore it is 
> necessary to offer 
> endpoint with options for either.
> 
> Keith Drage asserted that either there is an error in the IEPREP 
> requirements that ought to be fixed there, or else it should be dealt 
> with by SIP in responding to the requirements, so there is no 
> need for 
> SIPPING draft in this instance. Allison Mankin agreed, said the area 
> directors could deal with this aspect now, and don’t  need 
> any more input.
> 
> Rohan observed that SIP already adopted a mechanism that 
> relates to this. :
> 
> Meeting concluded.
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP