Subject: [Insipid] draft-ietf-insipid-session-id-01

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 8 Jul 2013 19:17:15 -0400

Folks,

I posted a new version of draft-ietf-insipid-session-id for your
consideration.

One significant addition is one to address a comment Laura had about
ensuring that intermediary devices can consistently re-create a UUID and
remain stateless.  New text is introduced in Section 4.1 that describes how
such entities can construct the UUIDs.

Section 6 was also revised with text to explain that the UUID order relates
to who sends the message.  It also discusses the longevity of the UUID,
logging, and changes to the "remote" UUID.

Previously, requests were made for additional call flows.  Those were not
added to the document,  but the requests are listed as TODO items in
section(s) under section 9.  There is also a TODO for section 9 related to
requested changes to section 9 to make it cleared the text is just examples.

Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 9 Jul 2013 00:41:11 +0000

(As WG cochair)

As well as reviewing the document generally, it would be useful if the WG membership could indicate any issues they think need face to face discussion time in Berlin.

Or is everything going perfectly?

Apart from what is listed below, is anything else missing from the document?

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul E. Jones
> Sent: 09 July 2013 00:17
> To: [email-masked]
> Subject: [Insipid] draft-ietf-insipid-session-id-01
> 
> Folks,
> 
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 29 Jul 2013 04:06:25 -0400

I think there needs some discussion and justification for why the sess-id value order/placement is swapped in SIP responses and upstream requests, instead of being kept the same order throughout.  This order-changing breaks backward compatibility with the older Session-ID individual draft, and is arguably harder to use/find in logs and wireshark for troubleshooting purposes.  I think someone mentioned some reason this re-ordering was necessary, but I can't recall what it is and I don't see it explained in the draft.

-hadriel

---

From: Laura Liess <[email-masked]>
Date: Tue, 30 Jul 2013 13:18:53 +0200

I agree with Hadriel.  If I remember correctly, we had an agreement in the
WG that the identifier defined here has to be backward compatible with the
session-id identifier defined in Hadriel's draft and that a reference to
this draft has to be added.

Backward incompatibility with Hadriel's session-id would be a big drawback
for the implementation of the new identifier within carrier networks.
Carriers as my employer, where Hadriel's session-id is already implemented,
will never switch to the new identifier. They will require the old
identifier for any new systems they buy, including conferencing systems.

Because Hadriel's session-id is used in the 3GPP IMS specificatios, I
assume that the situation is the same for other carriers using IMS.

Thank you
Laura

2013/7/29 Hadriel Kaplan <[email-masked]>

>
> I think there needs some discussion and justification for why the sess-id
> value order/placement is swapped in SIP responses and upstream requests,
> instead of being kept the same order throughout.  This order-changing
> breaks backward compatibility with the older Session-ID individual draft,
> and is arguably harder to use/find in logs and wireshark for
> troubleshooting purposes.  I think someone mentioned some reason this
> re-ordering was necessary, but I can't recall what it is and I don't see it
> explained in the draft.
>
> -hadriel
>
>
> > As well as reviewing the document generally, it would be useful if the
> WG membership could indicate any issues they think need face to face
> discussion time in Berlin.
> >

---

From: <[email-masked]>
Date: Tue, 30 Jul 2013 13:38:17 +0200

Full support of Laura's statement.

BR

Roland

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Laura Liess
Gesendet: Dienstag, 30. Juli 2013 13:19
An: Hadriel Kaplan
Cc: DRAGE, Keith (Keith); [email-masked]
Betreff: Re: [Insipid] draft-ietf-insipid-session-id-01

I agree with Hadriel.  If I remember correctly, we had an agreement in the WG that the identifier defined here has to be backward compatible with the session-id identifier defined in Hadriel's draft and that a reference to this draft has to be added.

Backward incompatibility with Hadriel's session-id would be a big drawback for the implementation of the new identifier within carrier networks. Carriers as my employer, where Hadriel's session-id is already implemented, will never switch to the new identifier. They will require the old identifier for any new systems they buy, including conferencing systems.

Because Hadriel's session-id is used in the 3GPP IMS specificatios, I assume that the situation is the same for other carriers using IMS.

Thank you
Laura

2013/7/29 Hadriel Kaplan <[email-masked]<mailto:[email-masked]>>

-hadriel

On Jul 8, 2013, at 8:41 PM, "DRAGE, Keith (Keith)" <[email-masked]<mailto:[email-masked]>> wrote:

>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
>> Of Paul E. Jones
>> Sent: 09 July 2013 00:17
>> To: [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
insipid mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/insipid

---

From: Andrew Allen <[email-masked]>
Date: Tue, 30 Jul 2013 14:28:03 +0000

I also concur with Laura's recollection. That agreement was the basis to move forward with the Jones draft as the WG draft.

Andrew

From: Laura Liess [mailto:[email-masked]]
Sent: Tuesday, July 30, 2013 06:18 AM Central Standard Time
To: Hadriel Kaplan <[email-masked]>
Cc: DRAGE, Keith (Keith) <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Insipid] draft-ietf-insipid-session-id-01

Thank you
Laura

-hadriel

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Atle Monrad <[email-masked]>
Date: Tue, 30 Jul 2013 14:36:04 +0000

Hi

I’d like to team up with Hadriel, Laura, Roland and Andrew on the support for not breaking the BW compatibility.

thanks
/atle

________________________________

Atle Monrad
3GPP CT Chairman

Group Function Technology – Standardization and Technical Regulation
Ericsson

From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Allen
Sent: 30. juli 2013 16:28
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Insipid] draft-ietf-insipid-session-id-01

Andrew

From: Laura Liess [mailto:[email-masked]]
Sent: Tuesday, July 30, 2013 06:18 AM Central Standard Time
To: Hadriel Kaplan <[email-masked]<mailto:[email-masked]>>
Cc: DRAGE, Keith (Keith) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Insipid] draft-ietf-insipid-session-id-01

Thank you
Laura

-hadriel

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 30 Jul 2013 14:52:20 +0000

+1.5

From: [email-masked] [mailto:[email-masked]] On Behalf Of Atle Monrad
Sent: Tuesday, July 30, 2013 10:36 AM
To: Andrew Allen; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Insipid] draft-ietf-insipid-session-id-01

Hi

thanks
/atle

Atle Monrad
3GPP CT Chairman

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Andrew Allen
Sent: 30. juli 2013 16:28
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Insipid] draft-ietf-insipid-session-id-01

Andrew

Thank you
Laura

-hadriel

---

From: James Polk <[email-masked]>
Date: Tue, 30 Jul 2013 21:38:20 -0500

I don't concur with Laura's recollection.

The WG agreement was that we (the Jones draft authors) had to try as 
hard as we could to be backwards compatible with something that's 
only in draft form. That's why we put into the Jones draft a 
backwards compatibility section, which has holes in it - because it 
was Christer's lab that was the only one doing the testing, and the 
Jones draft authors haven't heard any new information from him since 
last summer (even though we've asked that several questions be 
answered last August and/or September).

 From the initial indiv-00 version of the Jones draft, that 
Session-ID has been in two parts. The Kaplan draft, and what's been 
implemented before it reached RFC status, was a 1-part Session-ID. 
We've made every attempt to address how a 2-part value can be 
backwards compatible with a 1-part value, but there are certain 
circumstances in which that compatibility just isn't there.

I find it interesting that Laura's note to the list includes the line 
"... Carriers as my employer, where Hadriel's session-id is already 
implemented, will never switch to the new identifier...". I remember 
a company saying that same thing about the SIP Diversion header, 
which predated the History-Info header by like 5 years, and still the 
History-Info header was the one to make it to Standard-track RFC.

James

At 09:28 AM 7/30/2013, Andrew Allen wrote:
>Content-Language: en-US
>Content-Type: multipart/alternative;
> 
>boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338DED5BDXMB104ADSrimnet_"
>
>
>I also concur with Laura's recollection. That agreement was the 
>basis to move forward with the Jones draft as the WG draft.
>
>Andrew
>
>I agree with Hadriel.  If I remember correctly, we had an agreement 
>in the WG that the identifier defined here has to be backward 
>compatible with the session-id identifier defined in Hadriel's draft 
>and that a reference to this draft has to be added.
>
>Backward incompatibility with Hadriel's session-id would be a big 
>drawback for the implementation of the new identifier within carrier 
>networks. Carriers as my employer, where Hadriel's session-id is 
>already implemented, will never switch to the new identifier. They 
>will require the old identifier for any new systems they buy, 
>including conferencing systems.
>
>Because Hadriel's session-id is used in the 3GPP IMS specificatios, 
>I assume that the situation is the same for other carriers using IMS.
>
>Thank you
>Laura
>
>
>
>2013/7/29 Hadriel Kaplan 
><<mailto:[email-masked]>[email-masked]>
>
>I think there needs some discussion and justification for why the 
>sess-id value order/placement is swapped in SIP responses and 
>upstream requests, instead of being kept the same order 
>throughout.  This order-changing breaks backward compatibility with 
>the older Session-ID individual draft, and is arguably harder to 
>use/find in logs and wireshark for troubleshooting purposes.  I 
>think someone mentioned some reason this re-ordering was necessary, 
>but I can't recall what it is and I don't see it explained in the draft.
>
>-hadriel
>
>
>On Jul 8, 2013, at 8:41 PM, "DRAGE, Keith (Keith)" 
><<mailto:[email-masked]>[email-masked]> wrote:
>
> > (As WG cochair)
> >
> > As well as reviewing the document generally, it would be useful 
> if the WG membership could indicate any issues they think need face 
> to face discussion time in Berlin.
> >
> >> From: <mailto:[email-masked]>[email-masked] 
> [mailto:[email-masked]] On Behalf
> >> Of Paul E. Jones
> >> Sent: 09 July 2013 00:17
> >> To: <mailto:[email-masked]>[email-masked]
> >> <mailto:[email-masked]>[email-masked]
> > <mailto:[email-masked]>[email-masked]
><mailto:[email-masked]>[email-masked]
>This transmission (including any attachments) may contain 
>confidential information, privileged material (including material 
>protected by the solicitor-client or other applicable privileges), 
>or constitute non-public information. Any use of this information by 
>anyone other than the intended recipient is prohibited. If you have 
>received this transmission in error, please immediately reply to the 
>sender and delete this information from your system. Use, 
>dissemination, distribution, or reproduction of this transmission by 
>unintended recipients is not authorized and may be unlawful.

---

From: "VAN GEEL Jan (CIS/SCC)" <[email-masked]>
Date: Wed, 31 Jul 2013 07:03:21 +0000

I support “not breaking the BW compatibility”

So  +1

Jan Van Geel
IT and Network Specialist
Belgacom CIS/SCC/FVC
Tel: +32 2 202 1035
Tel: +32 2 207 9032
Email : [email-masked]<mailto:[email-masked]>

From: [email-masked] [mailto:[email-masked]] On Behalf Of DOLLY, MARTIN C
Sent: Tuesday 30 July 2013 16:52
To: Atle Monrad; Andrew Allen; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Insipid] draft-ietf-insipid-session-id-01

+1.5

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Atle Monrad
Sent: Tuesday, July 30, 2013 10:36 AM
To: Andrew Allen; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Insipid] draft-ietf-insipid-session-id-01

Hi

thanks
/atle

Atle Monrad
3GPP CT Chairman

Andrew

Thank you
Laura

-hadriel

***** Disclaimer *****
http://www.belgacom.be/maildisclaimer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Jul 2013 09:16:30 +0000

Hi,

I apologize if there are some questions I was expected to answer, and have failed to do so.

Having said that, I HAVE previously given comments regarding the backward compatibility of the INSIPID solution, and how it can be made backward compatible.

One issue I have raised is regarding the changing or order (depending on in which direction the identifier is sent). 

I have also indicated that a "Kaplan entity" will not add any parts to the session-id, and the INSIPID solution need to be prepared for that

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: [email-masked] [mailto:[email-masked]] Puolesta James Polk
Lähetetty: 31. heinäkuuta 2013 5:38
Vastaanottaja: Andrew Allen; [email-masked]; [email-masked]
Kopio: [email-masked]; [email-masked]
Aihe: Re: [Insipid] draft-ietf-insipid-session-id-01

The WG agreement was that we (the Jones draft authors) had to try as hard as we could to be backwards compatible with something that's only in draft form. That's why we put into the Jones draft a backwards compatibility section, which has holes in it - because it was Christer's lab that was the only one doing the testing, and the Jones draft authors haven't heard any new information from him since last summer (even though we've asked that several questions be answered last August and/or September).

 From the initial indiv-00 version of the Jones draft, that Session-ID has been in two parts. The Kaplan draft, and what's been implemented before it reached RFC status, was a 1-part Session-ID. 
We've made every attempt to address how a 2-part value can be backwards compatible with a 1-part value, but there are certain circumstances in which that compatibility just isn't there.

I find it interesting that Laura's note to the list includes the line "... Carriers as my employer, where Hadriel's session-id is already implemented, will never switch to the new identifier...". I remember a company saying that same thing about the SIP Diversion header, which predated the History-Info header by like 5 years, and still the History-Info header was the one to make it to Standard-track RFC.

James

At 09:28 AM 7/30/2013, Andrew Allen wrote:
>I also concur with Laura's recollection. That agreement was the basis 
>to move forward with the Jones draft as the WG draft.
>
>Andrew
>
>I agree with Hadriel.  If I remember correctly, we had an agreement in 
>the WG that the identifier defined here has to be backward compatible 
>with the session-id identifier defined in Hadriel's draft and that a 
>reference to this draft has to be added.
>
>already implemented, will never switch to the new identifier. They will 
>require the old identifier for any new systems they buy, including 
>conferencing systems.
>
>sess-id value order/placement is swapped in SIP responses and upstream 
>requests, instead of being kept the same order throughout.  This 
>order-changing breaks backward compatibility with the older Session-ID 
>individual draft, and is arguably harder to use/find in logs and 
>wireshark for troubleshooting purposes.  I think someone mentioned some 
>reason this re-ordering was necessary, but I can't recall what it is 
>and I don't see it explained in the draft.
>
>-hadriel
>
>
> if the WG membership could indicate any issues they think need face to 
> face discussion time in Berlin.
> >
> >> One significant addition is one to address a comment Laura had 
> >> about ensuring that intermediary devices can consistently re-create 
> >> a UUID and remain stateless.  New text is introduced in Section 4.1 
> >> that describes how such entities can construct the UUIDs.
> >>
> >> Section 6 was also revised with text to explain that the UUID order 
> >> relates to who sends the message.  It also discusses the longevity 
> >> of the UUID, logging, and changes to the "remote" UUID.
> >>
> >> Previously, requests were made for additional call flows.  Those 
> >> were not added to the document,  but the requests are listed as 
> >> TODO items in
> >> section(s) under section 9.  There is also a TODO for section 9 
> >> related to requested changes to section 9 to make it cleared the 
> >> text is just examples.
> >>
> >> Paul
> >>
> >>
>This transmission (including any attachments) may contain confidential 
>information, privileged material (including material protected by the 
>solicitor-client or other applicable privileges), or constitute 
>non-public information. Any use of this information by anyone other 
>than the intended recipient is prohibited. If you have received this 
>transmission in error, please immediately reply to the sender and 
>delete this information from your system. Use, dissemination, 
>distribution, or reproduction of this transmission by unintended 
>recipients is not authorized and may be unlawful.

---

From: Mary Barnes <[email-masked]>
Date: Wed, 31 Jul 2013 07:37:48 -0500

> I don't concur with Laura's recollection.
[MB] Laura's recollection is correct based on the WG minutes from IETF-85:
http://www.ietf.org/proceedings/85/minutes/minutes-85-insipid
The minutes state the following:

Nobody in the room objected against that the
draft-jones-insipid-session-id-01.txt describes backward compatibility
to the session-id as defined in the Kaplan draft
(draft-kaplan-dispatch-session-id).

Chairs - Any objections to the backwards compatibility as described in
-01 version - No objections noted.

Decision: to keep the new draft backwards compatible with regard to
draft-kaplan-dispatch-session-id

[/MB]

> The WG agreement was that we (the Jones draft authors) had to try as hard
> as we could to be backwards compatible with something that's only in draft
> form. That's why we put into the Jones draft a backwards compatibility
> section, which has holes in it - because it was Christer's lab that was the
> only one doing the testing, and the Jones draft authors haven't heard any
> new information from him since last summer (even though we've asked that
> several questions be answered last August and/or September).
>
> From the initial indiv-00 version of the Jones draft, that Session-ID has
> been in two parts. The Kaplan draft, and what's been implemented before it
> reached RFC status, was a 1-part Session-ID. We've made every attempt to
> address how a 2-part value can be backwards compatible with a 1-part value,
> but there are certain circumstances in which that compatibility just isn't
> there.

> I find it interesting that Laura's note to the list includes the line "...
> will never switch to the new identifier...". I remember a company saying
> that same thing about the SIP Diversion header, which predated the
> History-Info header by like 5 years, and still the History-Info header was
> the one to make it to Standard-track RFC.
>
[MB] Most everyone I know that supports History-Info also still supports
Diversion.  Also, there was an end run and Diversion was published on the
independent stream.  So, in the end we lost that battle.  Personally, I
think this "must be backwards" is a bad idea, but that was the consensus of
this WG. [/MB]

>> boundary="_000_**BBF5DDFE515C3946BC18D733B20DAD**
>> 2338DED5BDXMB104ADSrimnet_"
>>
>>
>>
>> I also concur with Laura's recollection. That agreement was the basis to
>> move forward with the Jones draft as the WG draft.
>>
>> Andrew
>>
>> From: Laura Liess [mailto:laura.liess.dt@**googlemail.com<[email-masked]>
>> ]
>> Cc: DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.**com<[email-masked]>>;
>> [email-masked] <[email-masked]>
>> Subject: Re: [Insipid] draft-ietf-insipid-session-id-**01
>>
>> the WG that the identifier defined here has to be backward compatible with
>> the session-id identifier defined in Hadriel's draft and that a reference
>> to this draft has to be added.
>>
>> networks. Carriers as my employer, where Hadriel's session-id is already
>> implemented, will never switch to the new identifier. They will require the
>> old identifier for any new systems they buy, including conferencing systems.
>>
>> 2013/7/29 Hadriel Kaplan <<mailto:hadriel.kaplan@**oracle.com<[email-masked]>
>> >hadriel.kaplan@**oracle.com <[email-masked]>>
>>
>>
>> On Jul 8, 2013, at 8:41 PM, "DRAGE, Keith (Keith)" <<mailto:
>> keith.drage@alcatel-**lucent.com <[email-masked]>>
>> keith.drage@**alcatel-lucent.com <[email-masked]>> wrote:
>>
>> > (As WG cochair)
>> >
>> >> From: <mailto:insipid-bounces@ietf.**org <[email-masked]>>
>> [email-masked] [mailto:insipid-bounces@ietf.**org<[email-masked]>]
>> On Behalf
>> >> Of Paul E. Jones
>> >> Sent: 09 July 2013 00:17
>> >> To: <mailto:[email-masked]>[email-masked] <[email-masked]>
>> >> Subject: [Insipid] draft-ietf-insipid-session-id-**01
>> >>
>> >> Folks,
>> >>
>> >> relates
>> related to
>> >> ______________________________**_________________
>> >> insipid mailing list
>> >> <mailto:[email-masked]>[email-masked] <[email-masked]>
>>
>> >> https://www.ietf.org/mailman/**listinfo/insipid<https://www.ietf.org/mailman/listinfo/insipid>
>> > ______________________________**_________________
>> > insipid mailing list
>> > <mailto:[email-masked]>[email-masked] <[email-masked]>
>>
>> > https://www.ietf.org/mailman/**listinfo/insipid<https://www.ietf.org/mailman/listinfo/insipid>
>>
>> ______________________________**_________________
>> insipid mailing list
>> <mailto:[email-masked]>[email-masked] <[email-masked]>
>>
>> https://www.ietf.org/mailman/**listinfo/insipid<https://www.ietf.org/mailman/listinfo/insipid>
>>
>>
>> ------------------------------**------------------------------**---------
>> solicitor-client or other applicable privileges), or constitute non-public
>> information. Any use of this information by anyone other than the intended
>> recipient is prohibited. If you have received this transmission in error,
>> please immediately reply to the sender and delete this information from
>> your system. Use, dissemination, distribution, or reproduction of this
>> transmission by unintended recipients is not authorized and may be unlawful.
>> ______________________________**_________________
>> insipid mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/insipid<https://www.ietf.org/mailman/listinfo/insipid>
>>
>
> ______________________________**_________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/insipid<https://www.ietf.org/mailman/listinfo/insipid>
>