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

[Christer Holmberg <[e-mail]>]

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ä: [e-mail] [mailto:[e-mail]] Puolesta James Polk
Lähetetty: 31. heinäkuuta 2013 5:38
Vastaanottaja: Andrew Allen; [e-mail]; [e-mail]
Kopio: [e-mail]; [e-mail]
Aihe: Re: [Insipid] draft-ietf-insipid-session-id-01

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
>
>From: Laura Liess [mailto:[e-mail]]
>Sent: Tuesday, July 30, 2013 06:18 AM Central Standard Time
>To: Hadriel Kaplan <[e-mail]>
>Cc: DRAGE, Keith (Keith) <[e-mail]>; 
>[e-mail] <[e-mail]>
>Subject: 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
><<mailto:[e-mail]>[e-mail]>
>
>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:[e-mail]>[e-mail]> 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.
> >
> > Or is everything going perfectly?
> >
> > Apart from what is listed below, is anything else missing from
> the document?
> >
> > Regards
> >
> > Keith
> >
> >> -----Original Message-----
> >> From: <mailto:[e-mail]>[e-mail]
> [mailto:[e-mail]] On Behalf
> >> Of Paul E. Jones
> >> Sent: 09 July 2013 00:17
> >> To: <mailto:[e-mail]>[e-mail]
> >> Subject: [Insipid] draft-ietf-insipid-session-id-01
> >>
> >> 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
> >>
> >>
> >> _______________________________________________
> >> insipid mailing list
> >> <mailto:[e-mail]>[e-mail]
> >> https://www.ietf.org/mailman/listinfo/insipid
> > _______________________________________________
> > insipid mailing list
> > <mailto:[e-mail]>[e-mail]
> > https://www.ietf.org/mailman/listinfo/insipid
>
>_______________________________________________
>insipid mailing list
><mailto:[e-mail]>[e-mail]
>https://www.ietf.org/mailman/listinfo/insipid
>
>
>---------------------------------------------------------------------
>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.
>_______________________________________________
>insipid mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/insipid

_______________________________________________
insipid mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/insipid