Subject: [Insipid] Meeting minutes of Berlin meeting

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 19 Sep 2013 11:40:23 +0000

The meeting minutes for the Berlin meeting have finally been completed. These are as follows:

Keith

-------------------------------------

IETF-87, Berlin, Germany
INtermediary-safe SIP session ID (INSIPID) WG
==================================================

Chairs: Gonzalo Salgueiro ([email-masked])
        Keith Drage ([email-masked])      

THURSDAY, August 1, 2013, 1520-1650 (Room: Charlottenburg 1)
------------------------------------------------------------

Introduction and Status Update
------------------------------

Presenter:		Chairs
Slides: 		slides-87-insipid-0

            - Agenda bash, Note Well, Note-takers and Jabber scribes, etc.
            - WG status since IETF86 in Orlando
            - Action items, milestone dates, etc.
            - Update on draft-kaplan-session-id being published as Historic
            - Results of WGLC & Next Steps for Session-ID Requirements draft

Discussion about updating IPR declarations against the drafts. Holders of existing declarations against the author draft for the solution mechanism should investigate whether they still apply to the WG solution draft and make the appropriate declarations.

Agenda bash - no changes

Requirements & Use Case document completed WGLC. Publication has been requested (just).

It was indicated that Hadriel Kaplan will publish a new version of the kaplan-session-id draft, which will then be progressed by Gonzalo Camarillo. draft-kaplan-session-id to be published as AD sponsored Informational. Gonzalo Camarillo identified that he IESG had a conversation about this particular
draft. The IESG decided to make it Informational because while RFC 2026 seems to allow the use of Historic RFCs for this purpose, section 6.4 talks about Historic RFCs only in the context of Standards Track RFCs. That was why Informational seemed a better choice. When he gets the writeup, Gonzalo Camarillo will initiate IETF last call.

It was stressed that the Kaplan draft is not a working group item. Its impact on the working group is on the compatibility issue discussed in the last meeting and also later in this meeting.

It was indicated that INSIPID has been given the task, from DISPATCH, to consider whether the log requirements work be accepted as a work item in INSIPID (see discussion later in the meeting).

Review and discussion of Session-ID solution
--------------------------------------------

Presenter:            	Gonzalo Salgueiro
Draft:                	draft-ietf-insipid-session-id-02
Slides:			slides-87-insipid-1.pptx

            - Summary of changes since -00 version
            - Review and discussion of updated session id call flows
            - Next steps

Summary of changes since -00 version
Open Issue: Example 9.6
Open Issue: 9.9 OOD REFER needs to be fixed

Open Issue: Do we have enough call flows. Decision: Make sure we have enough normative language to cover the call flow behavior

Null value:
It was discussed whether a dedicated null value should be used for the header field value in case one part of the session-id is not available, or whether the value should simply be left empty. Discussion about local vs remote values. It was commented, that depending on whether the header field value and header field parameter values will be switched (depending on in which direction a session-id is sent), there may not be a case where the header field value does not have a value.
Decision: if need a null, go with all 0's but might not need depending on next issue outcome

Backward compatibility:
Must of the discussion was around backward compatibility with the kaplan-session-id draft. It has previously been agreed, and there is a requirement for, backward compatibility, but comments have been raised that

Maintaining order and placement of Session ID in responses for backwards compatibility. Long and convoluted discussion about this issue. If the header field value and header field parameter values are switched, the solution will not work with entities that have implemented the draft-session-id draft. The authors of draft-ietf-sinsipid-session-id claimed that, if the order of the header field value and header field parameter are not switched, there are use-cases (mainly related to transfer) that will not work. Discussion about Paul Jone's concern.
Keith as Chair: How do we prove that this change to the draft will work?
Hadriel Kaplan indicated that he will, based on the existing use-case call flows, contribute versions of the call flows where the order is not switched, in order to determine whether there are use-cases that will not work. One mail requested per example.

Missing text for requirements:
Laura Leis requested additional rule text on B2BUA behavior, when one entity does not support the session id. Related to requirements Req-1 and Req-5 in draft-ietf-insipid-session-id-reqts-08.
Hadriel Kaplan recommended to just copy the B2BUA behavior text from draft-kaplan-insipid-session-id, and modify as appropriate.
Laura will post to list with suggested text.

Discussion of LogMe Requirements draft
--------------------------------------
         
Presenter:            	Peter Dawes
Draft:                	draft-dawes-dispatch-logme-reqs-02
Slides:			slides-87-insipid-2.pdf

	- Dispatch summary
	- Problem description
	- Is this the right solution and scope for INSIPID to address?
	- Should we cover only part in INSIPID (mods to Sess-ID)? Or all aspects?

Peter Dawes had initially submitted the draft to DISPATCH. Based on discussions, it was decided to dispatch the draft to the INSIPID, which will determine whether INSIPID is the right place for all the work, and whether some parts of the work belongs somewhere else. There was an agreement that the aim should be to do the work in INSIPID only.

Requirements:
Peter Dawes presented the requirements, and proposed new text for the INSIPID charter, in order to include the SIP log marking.

Lots of discussion about how the mechanism might work.

Hadriel Kaplan asked whether the work needs to cover cases where logged information is passed through several service providers and/or domains (as the information in many cases will be stripped of or discarded anyway) or whether the scope could be limited to a single provider/domain. It would probably also make it easier to pass the security review.

It was requested and clarified that it should be possible to initiate logging in a SIP response, in cases where the need for logging does not occur until the response is sent.

Chairs: Do we want to scope this work down?

Proposed charter:
Discussion about security issues of doing this cross domain
What part should be done in INSIPID?
Mary Barnes indicated that there is too much and detailed text in the suggested charter update. The chairs indicated that they will sort it out with the ADs.

Impact on the session-id work:
It was agreed that the work should not hold up the work on the session-id mechanism.

Show of hands:

Question:  Does anyone want to discuss the scope, or can INSIPID do everything associated with the work?
Outcome:   No objection to doing everything in INSIPID.

Question:  Support the work being done in INSIPID:
Outcome:   approx 12 to 14 in favor, nobody opposed

Question:  How many people will actively contribute:  
Outcome:   9 and a half

It was concluded that there is enough interest and motivation in the WG to start the work. The chairs will talk to the ADs.
 
Wrap-up (Chairs)
----------------

            - Next steps
            - Action items review

Session-id:
- New version of kaplan-session-id to be submitted.

- Updated call-flows, based on session-id part values not being switched, to be sent to the list.
Hadriel will post backwards compatible example call flows based on those in the current session identifier solutions draft by end of next week
 
Log-me requirements:
Alternatives to LogMe draft should be submitted in following weeks 
Solution draft will come later.

No need was seen for virtual interim meeting. Issues can be discussed on the list. Transfer use-cases may require need for interim, but it is not known at this point.