Minutes of the SIPPING WG Session at IETF 74
=================================================
Meeting chaired by:

This session was run as a joint SIP and SIPPING session covering currently and nearly chartered work items in both WGs. The WG dicussions were followed by a 30 minute discussion of the SIP Change Process proposing two new WGs: SIPCORE and DISPATCH, for which "dryrun" sessions are scheduled earlier in the week (Tuesday and Wednesday, 1300-1500, respectively). Please see the SIP WG minutes for details of the documents covered in those slots.

Minutes edited by Mary Barnes

Based on detailed notes by Daryl Malas and Andrew Allen

Jabber: http://www3.ietf.org/meetings/ietf-logs/sipping/

Slides presented included in the proceedings.

In addition, 2 adhoc SIPPING WG sessions were held during the week, with the minutes provided below:



Friday, March 27, 2009
--------------------------------------------

Agenda item highlights:
=======================


Topic: Agenda Bash
--------------------
Discussions led by: Chairs

The chairs presented the current status of the WG.  The SIPPING WG has made some progress on work items in the  the past few months, although the group is still having difficulty in getting work items updated more than once per IETF meeting cycle. Two  new RFCs (5390 and 5407) have been published since IETF-73,  two docs moved to the RFC editor's Q and one document has been Pub Requested.

It was highlighted that the SIP end-to-end performance metrics document (draft-ietf-pmol-sip-perf-metrics-03)  is undergoing WGLC in the PMOL WG.  In addition, charts were presented on other items of potential interest, which were not discussed in the meeting due to limits on the agenda time:

Topic: Re-INVITE Handling in SIP & Media State under Preconditions in SIP

Discussion led by: Gonzalo Camarillo
Relevant documents: 
        draft-camarillo-sipping-reinvite-00.txt
        draft-camarillo-sipping-precons-00.txt

Gonzalo provided detailed background on the problem as to the semantics of an error response to a re-INVITE as specified in Section 12.2.2 of RFC 3261 - the question being what exactly is meant by "the state changes associated with it".

Two solutions to the problem were put forth: 1) Clarify how to use the current spec -  i.e., full rollback  2) Specify different semantics.  It was noted that the solution may impact the offer-answer draft, which should be updated to include normative references to the agreed solution document(s).

Only two people in the WG session were comfortable making a decision on the proposal and Gonzalo clarified that the objective of this WG presentation/discussion was to make folks aware of the issues. 

Conclusion: Discussion to continue on the SIPPING WG mailing list and early review of the documents to take place.


Topic: Reject-offer-in-PRACK-issue (based on ML discussion)

Discussion led by: Christer Holmberg
Relevant documents: 
        draft-ietf-sipping-sip-offeranswer-10.txt
        (Note: doc has completed  "IETF LC")

Christer provided the background of the problem with RFC 3262 more or less assuming that a PRACK will be responded to using the 200 OK response code - i.e.,  SDP offer received in PRACK cannot be rejected using a 4xx response code.  Previously, it was agreed to allow the sending of a non-200 response to PRACK - i.e., 488 response to reject the SDP offer.

The open issue remains as to whether a non-200 response ceases the retransmission of the reliable 18x response associated with the PRACK?  The proposal was to clarify (in an update to RFC 3262) that a non-200 response does NOT cease retransmission of the reliable provisional response. However, concerns were raised that the solution would introduce a backwards compatibility problem and that the solution may cause worse problems than what already exist.  Thus, there was no agreement on the proposed way forward, although there was fundamental agreement that the problem does exist.

Conclusion: Discussion to continue on the SIPPING WG mailing list.

Topic: Identity

Discussion led by: Hadriel Kaplan
Relevant documents: draft-elwell-sip-e2e-identity-important-03

Hadriel provided background on the requirement to provide the ability to identify who the other party is - that information is currently sent as “e2e authenticated identification”.  Cases where this would be problematic were discussed including B2BUAs that modify signed parts and E.164 URIs.  Several solution requirements were put forth with regards to tolerating intermediaries changing things like port/IP address, contact, user part of to/from, etc.

A number of concerns were raised, in particular many felt that an intermediary should not be able to change the suggested fields.   A question was raised as to whether the identity of concern was a person or device.  In addition, folks asked for articulation of  the problem that isn't solved by RFC 4474. 

Conclusion: There was consensus to work on the Identity problem in IETF. However, not necessarily on the specific requirements/issues discussed.  Suggested solutions to this specific issue are requested to be posted to the SIP WG mailing list.
 

Topic: User Agent Profile Datasets

Discussion led by: Dale Worley
Relevant documents:
        draft-ietf-sipping-profile-datasets-03.txt

The primary changes were the addition of a terminology section.  Dale presented a summary of points that were discussed at a design team meeting on Thursday morning.  Proposed solutions were also discussed. Quite a few people in the WG have read the document and several agreed to serve as document reviewers.

The chair (Mary) stated that the doc must be aggressively updated and reviewed so that we can target WGLC by the end of May 2009 due to the number of other documents for which this document is a dependency.

Conclusion: Document will be updated by editor (Dale) based on presented proposals. Bi-weekly design team conference calls should be scheduled to discuss and resolve any remaining issues that are identified.  Once the document has been updating, resolving all open issues, a WGLC review will be scheduled.


Topic: Overload Design and modeling

Discussion led by: Volker Hilt
Relevant documents:
        draft-ietf-sipping-overload-design-02

Volker provided the status of this document, which describes design considerations and models for overload control.  It was mentioned that the current document does not include simulation results.  Details of the simulations and results are available externally in published papers, etc. Volker will provide links to the information.

A question was raised as to where the solution will be developed - that will occur in another working group (to be announced pending approval/completion of RAI restructuring). 

Conclusion: Volker to submit updated document. Once available, WGLC will be announced.


Topic: Event Throttle

Discussion led by: Krisztian Kiss
Relevant document:
        draft-niemi-sipping-event-throttle-08

This document provides additional event header field parameters (throttle, force and average) with which the rate of event notifications can be controlled.
The notifier can adjust the parms and they can be changed dynamically.  The document was updating reflecting comments from a pre-WGLC review.

A question was raised as to who would implement this solution - the response being that folks that implement presence are interested in this doucment and it  is a dependency for GEOPRIV work, as well as OMA.

Two open issues with proposed solutions were discussed:

1) Retransmission of NOTIFY vs. new transaction, the solution for which was that this document won't specify the exact method for when to start the mechanism and the parameters only apply to new transactions.

2) Average formula - there were several suggestions including using a moving average and exponential smoothing. Additional WG feedback is needed on this issue.


Conclusion: There was consensus to work on this document.  Update to be submitted by editor once solution to issues agreed. Once submitted, WGLC review to commence.

Topic: SIP Change Process

Discussion led by: Jon Peterson
Relevant document: draft-peterson-rai-rfc3427bis-01 

Jon presented 6 items to kick off discussions, including how to handle 1) Option-tags, 2) what is “Informational”?,  3) Deliverables of DISPATCH,  4) Rapidity/Efficiency of DISPATCH,  5) Existing work and/or a “cleanup” WG,  6) Changing the culture. 

A suggestion was made that proprietary option-tags should also be allowed and concerns were raised as to how much documentation is required to define a new option-tag.  The last point was re-enforced with folks suggesting that without changing the way we do things, the new DISPATCH WG could well end up being very much like SIPPING.  For example, several people suggested that having earlier deadlines for the new work is the only feasible way for the new model to be effective. Concerns were also raised that if we spin off too many work items into new WGs, the scheduling problem (which is already bad) becomes even worse.  Also, conference calls as a way to move work forwarded was suggested, although there were concerns about the calls being feasible across multiple timezones. 

Conclusion: There was general consensus to go forward with the proposed changes, although only one chair voted in support of the changes.