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

Hi Dan,

OK, I just sent a note as you suggested.

Cheers,

Gonzalo

On 29/09/2013 1:18 PM, Romascanu, Dan (Dan) wrote:
> I think that the problem is mostly with the folks out of the WG who could not see the messages distributed before. Re-sending the external review announcement with the complete set of milestones would solve this. 
> 
> Regards,
> 
> Dan
>  
> 
> 
> 
>> -----Original Message-----
>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]
>> Sent: Sunday, September 29, 2013 1:13 PM
>> To: Romascanu, Dan (Dan)
>> Cc: DRAGE, Keith (Keith); James Polk; insipid@ietf.org; 'Gonzalo
>> Salgueiro (gsalguei)'
>> Subject: Re: [Insipid] WG Review: INtermediary-safe SIP session ID
>> (insipid)
>>
>> Hi Dan,
>>
>> so, in practical terms, what do you want me to do? I (and the chairs
>> before) have already distributed the milestones before so that the WG
>> can review them. Do you want me to do something else?
>>
>> Thanks,
>>
>> Gonzalo
>>
>> On 29/09/2013 1:07 PM, Romascanu, Dan (Dan) wrote:
>>> But we ARE discussing a charter update. So let is also include the new
>> milestones in the discussion. This does not change the process, it just
>> allows to comment the text related to the scope and the milestones on
>> the same occasion.
>>>
>>> Regards,
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]
>>>> Sent: Sunday, September 29, 2013 1:04 PM
>>>> To: Romascanu, Dan (Dan)
>>>> Cc: DRAGE, Keith (Keith); James Polk; insipid@ietf.org; 'Gonzalo
>>>> Salgueiro (gsalguei)'
>>>> Subject: Re: [Insipid] WG Review: INtermediary-safe SIP session ID
>>>> (insipid)
>>>>
>>>> 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:Gonzalo.Camarillo@ericsson.com]
>>>>>> Sent: Sunday, September 29, 2013 12:58 PM
>>>>>> To: Romascanu, Dan (Dan)
>>>>>> Cc: DRAGE, Keith (Keith); James Polk; insipid@ietf.org; '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: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org]
>>>>>>>> On Behalf Of Gonzalo Camarillo
>>>>>>>> Sent: Sunday, September 29, 2013 11:35 AM
>>>>>>>> To: DRAGE, Keith (Keith)
>>>>>>>> Cc: James Polk; insipid@ietf.org; '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.ht
>>>>>>>>> ml
>>>>>>>>>
>>>>>>>>> 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: insipid-bounces@ietf.org
>>>>>>>>>> [mailto:insipid-bounces@ietf.org] On Behalf Of James Polk
>>>>>>>>>> Sent: 27 September 2013 19:54
>>>>>>>>>> To: 'Gonzalo Salgueiro (gsalguei)'; DRAGE, Keith (Keith);
>>>>>>>>>> Gonzalo Camarillo
>>>>>>>>>> Cc: insipid@ietf.org
>>>>>>>>>> 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 <gsalguei@cisco.com>
>>>>>>>>>>>   Keith Drage <keith.drage@alcatel-lucent.com>
>>>>>>>>>>>
>>>>>>>>>>> Assigned Area Director:
>>>>>>>>>>>   Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
>>>>>>>>>>>
>>>>>>>>>>> Mailing list
>>>>>>>>>>>   Address: insipid@ietf.org
>>>>>>>>>>>   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
>>>>>>>>>>> insipid@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/insipid
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> insipid mailing list
>>>>>>>>>> insipid@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/insipid
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> insipid mailing list
>>>>>>>> insipid@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/insipid
>>>>>
>>>
> 