Re: [Insipid] WG Review: INtermediary-safe SIP session ID (insipid)

[Gonzalo Camarillo <[e-mail]>]

Hi Dan,

yes, because the first two are the existing milestones. The last two are
added as a result of this charter update.

Cheers,

Gonzalo

On 29/09/2013 1:00 PM, Romascanu, Dan (Dan) wrote:
> OK, thanks, this makes sense. The announcement included only the first two. 
> 
> Dan
> 
> 
> 
> 
>> -----Original Message-----
>> From: Gonzalo Camarillo [mailto:[e-mail]]
>> Sent: Sunday, September 29, 2013 12:58 PM
>> To: Romascanu, Dan (Dan)
>> Cc: DRAGE, Keith (Keith); James Polk; [e-mail]; 'Gonzalo
>> Salgueiro (gsalguei)'
>> Subject: Re: [Insipid] WG Review: INtermediary-safe SIP session ID
>> (insipid)
>>
>> Hi Dan,
>>
>> the proposed milestones can be found on the slides Keith mentioned in
>> his email below. I copy them below for your convenience:
>>
>> Dec 2012 Requirements and use cases for new identifier sent to IESG (as
>> informational)
>>
>> Feb 2013 Specification of the new identifier sent to the IESG (PS)
>>
>> Dec 2013 Requirements for marking SIP sessions for logging to IESG
>> (Informational)
>>
>> Mar 2014 Protocol for marking SIP sessions for logging to IESG (Proposed
>> standard
>>
>> Cheers,
>>
>> Gonzalo
>>
>>
>> On 29/09/2013 12:27 PM, Romascanu, Dan (Dan) wrote:
>>> Hi Gonzalo,
>>>
>>> I understand that the process of review and approval of the milestones
>> is different, but at such point in time when the charter is sent for
>> external review I think it would be good to synchronize the two
>> processed. It does not make sense to me to review a charter whose
>> milestones are in the past, obviously not in synch with the rest of the
>> text.
>>>
>>> Regards,
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On
>>>> Behalf Of Gonzalo Camarillo
>>>> Sent: Sunday, September 29, 2013 11:35 AM
>>>> To: DRAGE, Keith (Keith)
>>>> Cc: James Polk; [e-mail]; 'Gonzalo Salgueiro (gsalguei)'
>>>> Subject: Re: [Insipid] WG Review: INtermediary-safe SIP session ID
>>>> (insipid)
>>>>
>>>> Hi,
>>>>
>>>> with respect to the milestones, the review of charters follows a
>>>> different review process than the milestones, which can be easily
>>>> updated by the chairs and the responsible AD without going through
>>>> IETF, IESG, and IAB reviews.
>>>>
>>>> So, once the charter is approved, the chairs will add the updated
>>>> milestones to the tracker.
>>>>
>>>> Cheers,
>>>>
>>>> Gonzalo
>>>>
>>>> On 27/09/2013 10:12 PM, DRAGE, Keith (Keith) wrote:
>>>>> The relevant mail was:
>>>>>
>>>>> http://www.ietf.org/mail-archive/web/insipid/current/msg00642.html
>>>>>
>>>>> Sent on 2nd August 2013.
>>>>>
>>>>> If you go to the link in this message you will see a slide with a
>>>> coloured version just for your benefit.
>>>>>
>>>>> Not sure why the new milestones are missing - there should
>>>>> ultimately
>>>> be two new ones. May Gonzalo Camarillo can comment.
>>>>>
>>>>> regards
>>>>>
>>>>> Keith
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [e-mail] [mailto:[e-mail]] On
>>>>>> Behalf Of James Polk
>>>>>> Sent: 27 September 2013 19:54
>>>>>> To: 'Gonzalo Salgueiro (gsalguei)'; DRAGE, Keith (Keith); Gonzalo
>>>>>> Camarillo
>>>>>> Cc: [e-mail]
>>>>>> Subject: Re: [Insipid] WG Review: INtermediary-safe SIP session ID
>>>>>> (insipid)
>>>>>>
>>>>>> Chairs and AD
>>>>>>
>>>>>> Lacking a good local diff tool, can you articulate what exactly is
>>>>>> being proposed to change from the existing charter, and why was
>>>>>> this necessary or needed or asked for?
>>>>>>
>>>>>> I mean, the focus of the charter is still on the 2 drafts we've
>>>>>> been working on for some time now, and that doesn't appear to have
>>>>>> changed. Additionally, there are no new milestones.
>>>>>>
>>>>>> I seemed to have missed the memo that brought this all about.
>>>>>>
>>>>>> James
>>>>>>
>>>>>> At 11:08 AM 9/27/2013, The IESG wrote:
>>>>>>> The INtermediary-safe SIP session ID (insipid) working group in
>>>>>>> the Real-time Applications and Infrastructure Area of the IETF is
>>>>>>> undergoing rechartering. The IESG has not made any determination
>>>>>>> yet. The following draft charter was submitted, and is provided
>>>>>>> for informational purposes only. Please send your comments to the
>>>>>>> IESG mailing list (iesg at
>>>>>>> ietf.org) by 2013-10-07.
>>>>>>>
>>>>>>> INtermediary-safe SIP session ID (insipid)
>>>>>>> ------------------------------------------------
>>>>>>> Current Status: Active WG
>>>>>>>
>>>>>>> Chairs:
>>>>>>>   Gonzalo Salgueiro <[e-mail]>
>>>>>>>   Keith Drage <[e-mail]>
>>>>>>>
>>>>>>> Assigned Area Director:
>>>>>>>   Gonzalo Camarillo <[e-mail]>
>>>>>>>
>>>>>>> Mailing list
>>>>>>>   Address: [e-mail]
>>>>>>>   To Subscribe: https://www.ietf.org/mailman/listinfo/insipid
>>>>>>>   Archive: http://www.ietf.org/mail-archive/web/insipid/
>>>>>>>
>>>>>>> Charter:
>>>>>>>
>>>>>>> An end-to-end session identifier in SIP-based multimedia
>>>>>>> communication networks refers to the ability for endpoints,
>>>>>>> intermediate devices, and management and monitoring system to
>>>>>>> identify and correlate SIP messages and dialogs of the same
>>>>>>> higher-level end-to-end "communication session" across multiple
>>>>>>> SIP devices, hops, and administrative domains.  Unfortunately,
>>>>>>> there are a number of factors that contribute to the fact that the
>>>>>>> current dialog identifiers defined in SIP are not suitable for
>>>>>>> end-to-end session identification. Perhaps the most important
>>>>>>> factor worth describing is that in real-world deployments of
>>>>>>> Back-to-Back User Agents (B2BUAs) devices like Session Border
>>>>>>> Controllers (SBC) often change the call identifiers (e.g., the
>>>>>>> From-tag and To-tag that are used in conjunction with the Call-ID
>>>>>>> header to make the dialog-id) as the session signaling passes
>> through.
>>>>>>>
>>>>>>> An end-to-end session identifier should allow the possibility to
>>>>>>> identify the communication session from the point of origin,
>>>>>>> passing through any number of intermediaries, to the ultimate
>>>>>>> point of termination. It should have the same aim as the From-tag,
>>>>>>> To-tag and Call-ID conjunction, but should not be mangled by
>> intermediaries.
>>>>>>>
>>>>>>> A SIP end-to-end session identifier has been considered as
>>>>>>> possible solution of different use cases like troubleshooting,
>>>>>>> billing, session recording, media and signaling correlation, and
>> so forth.
>>>>>>> Some of these requirements come from other working groups within
>>>>>>> the RAI area (e.g., SIPRec).  Moreover, other standards
>>>>>>> organizations have identified the need for SIP and H.323 to carry
>>>>>>> the same
>>>> "session ID"
>>>>>>> value so that it is possible to identify a call end-to-end even
>>>>>>> when performing inter working between protocols.
>>>>>>>
>>>>>>> Troubleshooting SIP signalling end-to-end becomes impractical as
>>>>>>> networks grow and become interconnected, including connection via
>>>>>>> transit networks, because the path that SIP signalling will take
>>>>>>> between clients cannot be predicted and the signalling volume and
>>>>>>> geographical spread are too large.
>>>>>>>
>>>>>>> This group will focus on two documents:
>>>>>>>
>>>>>>> The first document will specify a SIP identifier that has the same
>>>>>>> aim as the From-tag, To-tag and Call-ID conjunction, but is less
>>>>>>> likely to be mangled by intermediaries.  In doing this work, the
>>>>>>> group will pay attention to the privacy implications of a "session
>>>>>>> ID", for example considering the possibility to make it
>>>>>>> intractable for nodes to correlate "session IDs" generated by the
>>>>>>> same user for different sessions.
>>>>>>>
>>>>>>> The second document will define an indicator that can be added to
>>>>>>> the SIP protocol to indicate that signalling should be logged. The
>>>>>>> indicator will typically be applied as part of network testing
>>>>>>> controlled by the network operator and not used in regular client
>>>>>>> signalling.  However, such marking can be carried end-to-end
>>>>>>> including the SIP terminals, even if a session originates and
>>>>>>> terminates in different networks.
>>>>>>>
>>>>>>> Milestones:
>>>>>>>   Dec 2012 - Requirements and use cases for new identifier sent to
>>>>>>> IESG (as informational)
>>>>>>>   Feb 2013 - Specification of the new identifier sent to the IESG
>>>>>>> (PS)
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> insipid mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/insipid
>>>>>>
>>>>>> _______________________________________________
>>>>>> insipid mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/insipid
>>>>
>>>> _______________________________________________
>>>> insipid mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/insipid
>