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

[Mary Barnes <[e-mail]>]

On Tue, Jul 30, 2013 at 9:38 PM, James Polk <[e-mail]> wrote:

> 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 "...
> 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.
>
[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]

>
> James
>
> At 09:28 AM 7/30/2013, Andrew Allen wrote:
>
>> Content-Language: en-US
>> Content-Type: multipart/alternative;
>>
>> 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<[e-mail]>
>> ]
>> Sent: Tuesday, July 30, 2013 06:18 AM Central Standard Time
>> To: Hadriel Kaplan <[e-mail]>
>> Cc: DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.**com<[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:hadriel.kaplan@**oracle.com<[e-mail]>
>> >hadriel.kaplan@**oracle.com <[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:
>> keith.drage@alcatel-**lucent.com <[e-mail]>>
>> keith.drage@**alcatel-lucent.com <[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:insipid-bounces@ietf.**org <[e-mail]>>
>> [e-mail] [mailto:insipid-bounces@ietf.**org<[e-mail]>]
>> On Behalf
>> >> Of Paul E. Jones
>> >> Sent: 09 July 2013 00:17
>> >> To: <mailto:[e-mail]>insip**[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]>insip**[e-mail] <[e-mail]>
>>
>> >> https://www.ietf.org/mailman/**listinfo/insipid<https://www.ietf.org/mailman/listinfo/insipid>
>> > ______________________________**_________________
>> > insipid mailing list
>> > <mailto:[e-mail]>insip**[e-mail] <[e-mail]>
>>
>> > https://www.ietf.org/mailman/**listinfo/insipid<https://www.ietf.org/mailman/listinfo/insipid>
>>
>> ______________________________**_________________
>> insipid mailing list
>> <mailto:[e-mail]>insip**[e-mail] <[e-mail]>
>>
>> https://www.ietf.org/mailman/**listinfo/insipid<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<https://www.ietf.org/mailman/listinfo/insipid>
>>
>
> ______________________________**_________________
> insipid mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/insipid<https://www.ietf.org/mailman/listinfo/insipid>
>