Subject: [Insipid] Timing for publishing draft-kaplan-insipid-session-id

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 10 Sep 2013 19:09:18 +0300

Hi,

as you know, the following draft has gone through an IETF LC and it has
gotten a few comments:

http://datatracker.ietf.org/doc/draft-kaplan-insipid-session-id/

Some of the concerns relate to the fact that we are publishing this
document before INSIPID produces a solution document, which will be
backwards compatible with the solution described in the draft above.

My question to this group is: do we have a reason to publish this draft
before the INSIPID solution draft is ready?

Thanks,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 10 Sep 2013 16:24:22 +0000

Hi,

If we want to ensure the INSIPID solution is backward compatible, isn't that a good reason to first publish the thing it is going to be backward compatible with?

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] on behalf of Gonzalo Camarillo [[email-masked]]
Sent: Tuesday, 10 September 2013 7:09 PM
To: [email-masked]
Subject: [Insipid] Timing for publishing draft-kaplan-insipid-session-id

Hi,

Thanks,

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

---

From: Andrew Allen <[email-masked]>
Date: Tue, 10 Sep 2013 16:34:15 +0000

Gonzalo

The kaplan draft is a dependency from 3GPP release 9 (finalised about 2010) and the lack of a published referencable RFC is holding up development of mobile terminals. So publication of this is urgent.

Andrew 

----- Original Message -----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: Tuesday, September 10, 2013 11:09 AM Central Standard Time
To: [email-masked] <[email-masked]>
Subject: [Insipid] Timing for publishing draft-kaplan-insipid-session-id

Hi,

Thanks,

Gonzalo

---------------------------------------------------------------------
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, 10 Sep 2013 16:39:19 +0000

Gonzalo

I understood from the discussions in IETF that publishing of draft-kaplan-insipid-session-id was to document what had been already been documented in draft-kaplan-dispatch-session-id.

If this still is the case, I do not see why waiting will help.

I'd support publishing  of draft-kaplan-insipid-session-id as soon as possible.

/atle

________________________________ 

Atle Monrad
3GPP CT Chairman

Group Function Technology - Standardization and Technical Regulation 
Ericsson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
Sent: 10. september 2013 17:09
To: [email-masked]
Subject: [Insipid] Timing for publishing draft-kaplan-insipid-session-id

Hi,

as you know, the following draft has gone through an IETF LC and it has gotten a few comments:

Some of the concerns relate to the fact that we are publishing this document before INSIPID produces a solution document, which will be backwards compatible with the solution described in the draft above.

My question to this group is: do we have a reason to publish this draft before the INSIPID solution draft is ready?

Thanks,

Gonzalo

---

From: James Polk <[email-masked]>
Date: Tue, 10 Sep 2013 18:09:43 -0500

Gonzalo

I, however, do not agree with draft-kaplan-insipid-session-id being 
published as an informational RFC before the INSIPID solution is 
published as a standards-track. Nor do I want this document IANA 
registering the SIP header Session-ID, such as it currently attempts 
to do. At best, they should be consecutive RFC numbers with the 
INSIPID solution number having the lower number. If that means the 
kaplan draft has to wait in the RFC-Editor queue for the solution 
draft - so be it. That's what Dan R. from his Gen-Art review stated 
as his first major issue with the kaplan draft. Robert Sparks backed 
that opinion up by agreeing with that (and the rest of Dan's review). 
Gonzalo Salgueiro, one of INSIPID's WG chairs, says he stated that 
same view in a previously sent email to this list.

INSIPID, from its inception, has had the charter item to IANA 
register this SIP header, and the draft-kaplan-insipid-session-id is 
not even a WG item, so why is everyone now in such a rush to have 
this draft do what a WG is supposed to do? Could it be the kaplan 
draft couldn't create a WG to form consensus on its own, so now folks 
are wanting to rush ahead of themselves to claim WG consensus where 
there wasn't any such consensus within any WG, let alone INSIPID?

James

At 11:39 AM 9/10/2013, Atle Monrad wrote:
>Gonzalo
>
>I understood from the discussions in IETF that publishing of 
>draft-kaplan-insipid-session-id was to document what had been 
>already been documented in draft-kaplan-dispatch-session-id.
>
>My question to this group is: do we have a reason to publish this 
>draft before the INSIPID solution draft is ready?
>
>Thanks,
>
>Gonzalo

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 10 Sep 2013 22:14:36 -0400

I don't know if you read the rest of the Gen-ART review thread - it moved off of the ietf list to this INSIPID WG mailing list.

See this one:
http://www.ietf.org/mail-archive/web/insipid/current/msg00680.html

Other comments inline...

On Sep 10, 2013, at 7:09 PM, James Polk <[email-masked]> wrote:

> I, however, do not agree with draft-kaplan-insipid-session-id being published as an informational RFC before the INSIPID solution is published as a standards-track. Nor do I want this document IANA registering the SIP header Session-ID, such as it currently attempts to do. At best, they should be consecutive RFC numbers with the INSIPID solution number having the lower number. If that means the kaplan draft has to wait in the RFC-Editor queue for the solution draft - so be it. That's what Dan R. from his Gen-Art review stated as his first major issue with the kaplan draft. Robert Sparks backed that opinion up by agreeing with that (and the rest of Dan's review). Gonzalo Salgueiro, one of INSIPID's WG chairs, says he stated that same view in a previously sent email to this list.
> 
> INSIPID, from its inception, has had the charter item to IANA register this SIP header

It's a nit, but the INSIPID charter does not mention a particular header labeled 'Session-ID'.

> , and the draft-kaplan-insipid-session-id is not even a WG item, so why is everyone now in such a rush to have this draft do what a WG is supposed to do? Could it be the kaplan draft couldn't create a WG to form consensus on its own

Actually, as far as I know, the older kaplan drafts are in fact what triggered creation of the INSIPID WG.  No?

I never re-submitted it for consideration as an INSIPID WG draft, because the requirements document has a requirement the older kaplan drafts didn't fulfill while the Cisco draft did.  I don't care who authors drafts; in fact I usually prefer it's someone else, because getting IETF drafts published is a major pain.  :)

> , so now folks are wanting to rush ahead of themselves to claim WG consensus where there wasn't any such consensus within any WG, let alone INSIPID?

I believe that technically it's not a WG document, and no WG consensus is being asked for.

The reason it makes sense to publish the kaplan draft *before* the INSIPID WG one is because of the decision to make the INSIPID one backwards-compatible.  Because of that, arguably the kaplan draft *should* be the first one to register the header name and define the ABNF, and then the INSIPID WG one can expand the ABNF and update the IANA registration to point to the INSIPID WG's RFC.

If the WG draft-ietf-insipid-session-id fundamentally changes the 'Session-ID' header from what it is in draft-kaplan-insipid-session-id, in a non-backwards-compatible fashion, then it won't have met the agreement reached in IETF 85 for adopting draft-jones-insipid-session-id-0 as the new WG document solution.  If we decide that's ok, that's fine; but I think we actually need to register a new header name in that case... something other than 'Session-ID'.  We know 'Session-ID' is already in-use in the wild, and there are plenty of more strings available for header names.

Don't get me wrong though - this whole thing is weird, and I don't like the precedent this may set.

-hadriel

---

From: Atle Monrad <[email-masked]>
Date: Wed, 11 Sep 2013 09:58:42 +0000

James

This was discussed in the INSIPID session in Berlin under the agenda point:

- Update on draft-kaplan-session-id being published as Historic

I couldn't find the official minutes, but in this discussion the change from Historic -> Informational was clarified by Gonzalo and it was agreed to submit the draft-kaplan-dispatch-session-id-03 as Informational which initiated the versions -00 to -03 of draft-kaplan-insipid-session-id by Hadriel over a few days. This is quite well reflected on the INSIPID list in emails by Hadriel, Keith and Mary.

As this draft reflects the background and history of the session ID, completing this draft will in my view help progress and document what exist e.g. in 3GPP.

If it is not possible to agree on a fully backwards compatible solution - unfortunate, but I cannot see making changes to history (draft-kaplan-dispatch-session-id aka draft-kaplan-insipid-session-id) to be of any help. I rather think having a stable base will benefit specification of the INSIPID-solution.

Thanks
/atle

Atle Monrad
3GPP CT Chairman

-----Original Message-----
From: James Polk [mailto:[email-masked]] 
Sent: 11. september 2013 00:10
To: Atle Monrad; Gonzalo Camarillo; [email-masked]
Subject: Re: [Insipid] Timing for publishing draft-kaplan-insipid-session-id

Gonzalo

I, however, do not agree with draft-kaplan-insipid-session-id being published as an informational RFC before the INSIPID solution is published as a standards-track. Nor do I want this document IANA registering the SIP header Session-ID, such as it currently attempts to do. At best, they should be consecutive RFC numbers with the INSIPID solution number having the lower number. If that means the kaplan draft has to wait in the RFC-Editor queue for the solution draft - so be it. That's what Dan R. from his Gen-Art review stated as his first major issue with the kaplan draft. Robert Sparks backed that opinion up by agreeing with that (and the rest of Dan's review). 
Gonzalo Salgueiro, one of INSIPID's WG chairs, says he stated that same view in a previously sent email to this list.

INSIPID, from its inception, has had the charter item to IANA register this SIP header, and the draft-kaplan-insipid-session-id is not even a WG item, so why is everyone now in such a rush to have this draft do what a WG is supposed to do? Could it be the kaplan draft couldn't create a WG to form consensus on its own, so now folks are wanting to rush ahead of themselves to claim WG consensus where there wasn't any such consensus within any WG, let alone INSIPID?

James

---

From: <[email-masked]>
Date: Wed, 11 Sep 2013 13:04:26 +0200

+1

BR
Roland

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Atle Monrad
Gesendet: Dienstag, 10. September 2013 18:39
An: Gonzalo Camarillo; [email-masked]
Betreff: Re: [Insipid] Timing for publishing draft-kaplan-insipid-session-id

Gonzalo

/atle

Atle Monrad
3GPP CT Chairman

Group Function Technology - Standardization and Technical Regulation Ericsson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
Sent: 10. september 2013 17:09
To: [email-masked]
Subject: [Insipid] Timing for publishing draft-kaplan-insipid-session-id

Hi,

Thanks,

Gonzalo

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 11 Sep 2013 12:06:21 +0000

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, September 11, 2013 7:04 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Insipid] Timing for publishing draft-kaplan-insipid-session-id

+1

BR
Roland

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Atle Monrad
Gesendet: Dienstag, 10. September 2013 18:39
An: Gonzalo Camarillo; [email-masked]
Betreff: Re: [Insipid] Timing for publishing draft-kaplan-insipid-session-id

Gonzalo

/atle

Atle Monrad
3GPP CT Chairman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
Sent: 10. september 2013 17:09
To: [email-masked]
Subject: [Insipid] Timing for publishing draft-kaplan-insipid-session-id

Hi,

Thanks,

Gonzalo

---

From: Laura Liess <[email-masked]>
Date: Wed, 11 Sep 2013 14:22:44 +0200

This is  also my opinion.

Laura

2013/9/11 Atle Monrad <[email-masked]>

> I couldn't find the official minutes, but in this discussion the change
> from Historic -> Informational was clarified by Gonzalo and it was agreed
> to submit the draft-kaplan-dispatch-session-id-03 as Informational which
> initiated the versions -00 to -03 of draft-kaplan-insipid-session-id by
> Hadriel over a few days. This is quite well reflected on the INSIPID list
> in emails by Hadriel, Keith and Mary.
>
> As this draft reflects the background and history of the session ID,
> completing this draft will in my view help progress and document what exist
> e.g. in 3GPP.
>
> If it is not possible to agree on a fully backwards compatible solution -
> unfortunate, but I cannot see making changes to history
> (draft-kaplan-dispatch-session-id aka draft-kaplan-insipid-session-id) to
> be of any help. I rather think having a stable base will benefit
> specification of the INSIPID-solution.
>
> Thanks
> /atle
>
> published as an informational RFC before the INSIPID solution is published
> as a standards-track. Nor do I want this document IANA registering the SIP
> header Session-ID, such as it currently attempts to do. At best, they
> should be consecutive RFC numbers with the INSIPID solution number having
> the lower number. If that means the kaplan draft has to wait in the
> RFC-Editor queue for the solution draft - so be it. That's what Dan R. from
> his Gen-Art review stated as his first major issue with the kaplan draft.
> Robert Sparks backed that opinion up by agreeing with that (and the rest of
> Dan's review).
> Gonzalo Salgueiro, one of INSIPID's WG chairs, says he stated that same
> view in a previously sent email to this list.
>
> INSIPID, from its inception, has had the charter item to IANA register
> this SIP header, and the draft-kaplan-insipid-session-id is not even a WG
> item, so why is everyone now in such a rush to have this draft do what a WG
> is supposed to do? Could it be the kaplan draft couldn't create a WG to
> form consensus on its own, so now folks are wanting to rush ahead of
> themselves to claim WG consensus where there wasn't any such consensus
> within any WG, let alone INSIPID?
>
> James
>

---

From: James Polk <[email-masked]>
Date: Wed, 11 Sep 2013 15:26:49 -0500

At 09:14 PM 9/10/2013, Hadriel Kaplan wrote:

>I don't know if you read the rest of the Gen-ART review thread - it 
>moved off of the ietf list

I have looked and cannot find this Gen-ART review ever on the IETF 
list. I have been told it never was on the IETF list, rather it was 
only on the Gen-ART list, which most of us are *not* on, so limiting 
the posting of a review to that list is next to useless (IMO - but I 
could be wrong).

>  to this INSIPID WG mailing list.

yep, I've read all 13 messages on that thread.

> > I, however, do not agree with draft-kaplan-insipid-session-id 
> being published as an informational RFC before the INSIPID solution 
> is published as a standards-track. Nor do I want this document IANA 
> registering the SIP header Session-ID, such as it currently 
> attempts to do. At best, they should be consecutive RFC numbers 
> with the INSIPID solution number having the lower number. If that 
> means the kaplan draft has to wait in the RFC-Editor queue for the 
> solution draft - so be it. That's what Dan R. from his Gen-Art 
> review stated as his first major issue with the kaplan draft. 
> Robert Sparks backed that opinion up by agreeing with that (and the 
> rest of Dan's review). Gonzalo Salgueiro, one of INSIPID's WG 
> chairs, says he stated that same view in a previously sent email to this list.
> >
> register this SIP header

you're right. However, from before the WG was chartered what 
eventually became the WG solutions draft was in play, creating the 
Session-ID header, so it's not like the WG, once formed, debated on 
what the header should be called.

> > , and the draft-kaplan-insipid-session-id is not even a WG item, 
> so why is everyone now in such a rush to have this draft do what a 
> WG is supposed to do? Could it be the kaplan draft couldn't create 
> a WG to form consensus on its own
>
>Actually, as far as I know, the older kaplan drafts are in fact what 
>triggered creation of the INSIPID WG.  No?

they wondered for better than 5 years before the WG was created. By 
that time, a requirements doc and another solution doc were published 
(i.e., before and during discussions in DISPATCH).

>I never re-submitted it for consideration as an INSIPID WG draft, 
>because the requirements document has a requirement the older kaplan 
>drafts didn't fulfill while the Cisco draft did.  I don't care who 
>authors drafts; in fact I usually prefer it's someone else, because 
>getting IETF drafts published is a major pain.  :)

you don't have to tell me about that hassle... ;-)

> > , so now folks are wanting to rush ahead of themselves to claim 
> WG consensus where there wasn't any such consensus within any WG, 
> let alone INSIPID?
>
>

No, it's absolutely _not_ a WG product. That doesn't mean it's not 
trying - intentionally or not - to get around the process started by 
an existing WG in the IETF.

>The reason it makes sense to publish the kaplan draft *before* the 
>INSIPID WG one is because of the decision to make the INSIPID one 
>backwards-compatible.

You state that as if you have no faith in the WG to make sure the new 
solution will be as backwards compatible with the old version as it 
can be... and I find that troubling, considering just how easy it is 
for someone to throw a monkey wrench in the process within the rules 
of the process.

>Because of that, arguably the kaplan draft *should* be the first one 
>to register the header name and define the ABNF, and then the 
>INSIPID WG one can expand the ABNF and update the IANA registration 
>to point to the INSIPID WG's RFC.

That means that there will be one definition for Session-ID for the 
couple of months before the INSIPID solution changes the definition 
and IANA registry ... why do we want to do that? Will it make sense 
to the IESG to do that?

>If the WG draft-ietf-insipid-session-id fundamentally changes the 
>'Session-ID' header from what it is in 
>draft-kaplan-insipid-session-id, in a non-backwards-compatible 
>fashion, then it won't have met the agreement reached in IETF 85 for 
>adopting draft-jones-insipid-session-id-0 as the new WG document solution.

I've always stated we editors of the jones draft will make the 
solution as backwards compatible with the kaplan draft as possible, 
but that a 2 value ID will run into problems with a single value 
implementation, and that should be obvious to everyone who thinks 
about it for a second.

That said, we have received ZERO comments to our latest proposal that 
we think actually accomplishes this no matter the version of the 
endpoint that initiates or receives the SIP message... zero... and 
that's really disheartening.

>If we decide that's ok, that's fine; but I think we actually need to 
>register a new header name in that case... something other than 
>'Session-ID'.  We know 'Session-ID' is already in-use in the wild, 
>and there are plenty of more strings available for header names.
>

If the kaplan draft reaches RFC status before the INSIPID solutions 
draft does, that's a precedent we'll soon regret all over the IETF. 
That's why I'm backing Dan's proposal (which Robert and Gonzalo S. 
agree with) that has your kaplan draft sitting on a shelf until the 
INSIPID solution draft reaches standards-track RFC status. If that's 
allowed to happen, this whole thing gets far less weird.

James

---

From: James Polk <[email-masked]>
Date: Wed, 11 Sep 2013 15:39:24 -0500

At 04:58 AM 9/11/2013, Atle Monrad wrote:
>I couldn't find the official minutes, but in this discussion the 
>change from Historic -> Informational was clarified by Gonzalo and 
>it was agreed to submit the draft-kaplan-dispatch-session-id-03 as 
>Informational which initiated the versions -00 to -03 of 
>draft-kaplan-insipid-session-id by Hadriel over a few days.

without having attended Berlin for medical reasons - it's hard to 
make judgements about conversations that occurred within or outside 
of sessions WITHOUT any minutes. The chairs should have posted an 
email to the list about the reasons for the change, but they haven't. 
It's the middle of September, and INSIPID was in July...

>This is quite well reflected on the INSIPID list in emails by 
>Hadriel, Keith and Mary.

Not with the why, or asking if everyone agreed to the kaplan draft 
with this change in mind.

>completing this draft will in my view help progress and document 
>what exist e.g. in 3GPP.

The kaplan draft does not address more than half the requirements of 
the INSIPID requirements draft. So, in my mind, it is insufficient to 
more forward with this draft as a informational RFC without 
circumventing IETF process and procedures, unless the kaplan doc is 
RFC'd later than the existing solutions draft to remove any and all confusion.

>If it is not possible to agree on a fully backwards compatible 
>solution - unfortunate, but I cannot see making changes to history 
>(draft-kaplan-dispatch-session-id aka 
>draft-kaplan-insipid-session-id) to be of any help. I rather think 
>having a stable base will benefit specification of the INSIPID-solution.

I don't see how you get here from there.

James

>draft couldn't create a WG to form consensus on its own, so now 
>folks are wanting to rush ahead of themselves to claim WG consensus 
>where there wasn't any such consensus within any WG, let alone INSIPID?
>
>James
>

---

From: Robert Sparks <[email-masked]>
Date: Wed, 11 Sep 2013 15:55:41 -0500

FWIW:

The WG was copied on the genart-thread, so you should have seen the 
whole thing here.

That said, the archives for genart are open. You can find the whole 
thread starting here:
<http://www.ietf.org/mail-archive/web/gen-art/current/msg08909.html>

You can see Dan's original genart review by hitting [Thread Prev] on 
that page.

RjS

On 9/11/13 3:26 PM, James Polk wrote:
>> > , and the draft-kaplan-insipid-session-id is not even a WG item, so 
>> why is everyone now in such a rush to have this draft do what a WG is 
>> supposed to do? Could it be the kaplan draft couldn't create a WG to 
>> form consensus on its own
>>
>> > , so now folks are wanting to rush ahead of themselves to claim WG 
>> consensus where there wasn't any such consensus within any WG, let 
>> alone INSIPID?
>>
>>
>> to register the header name and define the ABNF, and then the INSIPID 
>> WG one can expand the ABNF and update the IANA registration to point 
>> to the INSIPID WG's RFC.
>
> and IANA registry ... why do we want to do that? Will it make sense to 
> the IESG to do that?
>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 11 Sep 2013 18:05:51 -0400

> yep, I've read all 13 messages on that thread.

Then you should have seen the note where I stated *I* didn't change it to Informational, nor did this WG.  I was told to change it to Informational by the shepherding AD, because the IESG said to.  Or at least that was my understanding.

> 
> No, it's absolutely _not_ a WG product. That doesn't mean it's not trying - intentionally or not - to get around the process started by an existing WG in the IETF.

See above.

>> The reason it makes sense to publish the kaplan draft *before* the INSIPID WG one is because of the decision to make the INSIPID one backwards-compatible.
> 
> You state that as if you have no faith in the WG to make sure the new solution will be as backwards compatible with the old version as it can be... and I find that troubling, considering just how easy it is for someone to throw a monkey wrench in the process within the rules of the process.

Actually if you listen to the audio recording of the Berlin meeting, I think you'll find I was very much of the opinion that the WG draft could be made backwards-compatible; and I was given an action item to take the call flows form the WG draft and change them to show how they could be backwards-compatibel and email those to the list.  I did that, here:
http://www.ietf.org/mail-archive/web/insipid/current/msg00673.html
http://www.ietf.org/mail-archive/web/insipid/current/msg00674.html
http://www.ietf.org/mail-archive/web/insipid/current/msg00675.html

> I've always stated we editors of the jones draft will make the solution as backwards compatible with the kaplan draft as possible, but that a 2 value ID will run into problems with a single value implementation, and that should be obvious to everyone who thinks about it for a second.
> That said, we have received ZERO comments to our latest proposal that we think actually accomplishes this no matter the version of the endpoint that initiates or receives the SIP message... zero... and that's really disheartening.

Ummm... what latest proposal?  I may have missed an email somewhere.

-hadriel

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 11 Sep 2013 22:17:11 +0000

Hi Gonzalo,

I have a clarifying question. Assuming the kaplan draft is published
first, is it intended that the insipid WG draft that is eventually
published will obsolete the kaplan draft?

Cheers,
Charles

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 12 Sep 2013 14:04:08 +0300

Hi Charles,

if the INSIPID solution is backwards compatible and uses the same header
field name and syntax as the old mechanism, then yes, it will obsolete
the previous spec.

In any case, as I have said many times, when writing drafts it is much
better to clearly write what the draft intends to do than to rely on the
status of the RFC. People will understand a clear paragraph much better
than a combination of RFC types.

Cheers,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 12 Sep 2013 13:12:43 +0000

Hi,

>>> I've always stated we editors of the jones draft will make the solution as backwards compatible with the kaplan draft as 
>>> possible, but that a 2 value ID will run into problems with a single value implementation, and that should be obvious to 
>>> everyone who thinks about it for a second.
>> That said, we have received ZERO comments to our latest proposal that we think actually accomplishes this no matter 
>> the version of the endpoint that initiates or receives the SIP message... zero... and that's really disheartening.
>

One of my early proposal was that, if either endpoint supports Kaplan, we simply won't use the 2 value ID.

So, if the one sending the INVITE only supports Kaplan (we need to define how that is determined), the receiver does not add the 2nd part, copies the received value into the response, and uses that in any subsequent request/response within the session.

And, if the receiver only supports Kaplan (the sender will figure this out since the receiver won't add the 2nd part), then only one part will be used in each request/response through the session.

Now, that takes care of backward compatibility as far as the endpoints are concerned. However, there could of course be an intermediary that doesn't support the INSIPID mechanism, but the question is whether that matters.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 12 Sep 2013 18:54:01 -0400

If for some reason the insipid wg should implode without producing an 
RFC, I don't want the Kaplan draft out there as anything but historic.

I have a somewhat weird proposal that might satisfy some of the issues here:

1) Further modify the Kaplan draft to explain the situation, that there 
is no intent to standardize it, and that draft... is intended to replace 
it. Make that a *normative* reference. I guess this means that the 
kaplan draft would need to be stds track. But it won't become an RFC 
until it is has been replaced.

2) Make a normative reference from the new draft to the kaplan draft, 
and mark it as replacing the kaplan draft.

Then they can only only proceed to RFC *together*.

Another way to accomplish this would be to put the body of the kaplan 
draft into the new draft as a non-normative annex.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 12 Sep 2013 19:03:06 -0400

I just now saw Gonzalo's forward of the message about Historic vs. 
Informational. Maybe that changes my first comment below, but not the rest.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Sep 2013 12:51:37 +0000

Hi,

> draft into the new draft as a non-normative annex.

That would be tricky for old 3GPP releases. They would have to profile the RFC, and say that only the annex applies - which would be kinda strange.

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 13 Sep 2013 09:07:32 -0400

> Now, that takes care of backward compatibility as far as the endpoints are concerned. However, there could of course be an intermediary that doesn't support the INSIPID mechanism, but the question…

Huh, interesting proposal.  Is that the proposal James was talking about?

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Sep 2013 13:37:45 +0000

Hi,

>>>>> but that a 2 value ID will run into problems with a single value implementation, and that should be obvious to everyone who thinks about it for a second.
>>>> That said, we have received ZERO comments to our latest proposal 
>>>> that we think actually accomplishes this no matter the version of the endpoint that initiates or receives the SIP message... zero... and that's really disheartening.
>>> 
>> So, if the one sending the INVITE only supports Kaplan (we need to define how that is determined), the receiver does not add the 2nd part, copies the 
>> received value into the response, and uses that in any subsequent request/response within the session.

I don't know :)

Regards,

Christer

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 14 Sep 2013 01:39:40 -0400

Christer,

Are there actually any 3GPP releases implementing the Kaplan draft?

Earlier, Andrew stated:

"The kaplan draft is a dependency from 3GPP release 9 (finalised about 2010)
and the lack of a published referencable RFC is holding up development of
mobile terminals."

That sounds as if it is not presently implemented.

I was also a little surprised that it might be holding up mobile terminals
since Laura indicated previously that the main use case for the Kaplan draft
is tracking calls within an administrative domain (e.g., ingress SBC to
egress SBC).  She made that comment as we were discussing the fact that
things will break when using the Kaplan draft if a call goes into an
enterprise PBX.

So what is the true state of the implementation?  Is it really being used
today?

Paul

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Christer Holmberg
> Sent: Friday, September 13, 2013 8:52 AM
> To: Paul Kyzivat; [email-masked]
> That would be tricky for old 3GPP releases. They would have to profile the
> RFC, and say that only the annex applies - which would be kinda strange.
> 
> Regards,
> 
> Christer

---

From: Andrew Allen <[email-masked]>
Date: Sat, 14 Sep 2013 12:01:03 +0000

Paul

The kaplan draft is referenced in 3GPP releases 9,10 and 11. 3GPP are currently working on release 12 so it has been referenced for a long time.

My understanding is that the kaplan draftt has at least been implemented by some networks however it is also mandatory according to 3GPP specifications for a mobile terminal that is a conference participant  to also include the session-ID. For a mobile device vendor implementing an internet draft in millions of devices is a big issue becaause this is an unstable reference. Therefore this situation of uncertanity regarding the status of the kaplan draft and backwards compatibiity with INSIPID standards track solution is holding up mobile devices being compliant to 3GPP release 9, 10 and 11.

Andrew

----- Original Message -----
From: Paul E. Jones [mailto:[email-masked]]
Sent: Saturday, September 14, 2013 12:39 AM Central Standard Time
To: 'Christer Holmberg' <[email-masked]>; 'Paul Kyzivat' <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Insipid] Timing for publishing draft-kaplan-insipid-session-id

Christer,

Earlier, Andrew stated:

Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 14 Sep 2013 14:25:12 +0000

Hi Paul,

I can tell you that the company I represent definately have implemented the Kaplan draft (I also know that others have implemented it), and it has been deployed. Also, I believe I was the one who initially raised the whole backward compatibility issue, so I guess I am the one to blame for this whole mess  :)

I can't really speak on behalf of the mobile phone business. But, related to what Andrew said: people generally do want to wait for drafts to be published before they get implemented and deployed. But, in the case of Session-Id, the Kaplan draft has been around for YEARS, so it simply was not possible.

And, as we have had this discussion before, so I really think we should focus on getting the solution done.

Regards,

Christer

________________________________________
From: Paul E. Jones [[email-masked]]
Sent: Saturday, 14 September 2013 8:39 AM
To: Christer Holmberg; 'Paul Kyzivat'; [email-masked]
Subject: RE: [Insipid] Timing for publishing draft-kaplan-insipid-session-id

Christer,

Earlier, Andrew stated:

Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 14 Sep 2013 14:33:06 +0000

Hi,

Does anyone have issues with my suggestion below? I believe it could be a rather straight forward solution. Paul, James & co get what they want, and the backward compatibility folks get what they want :)

The only question is how a sender indicates that it support the INSIPID mechanism. From a pure SIP protocol perspective, I believe a media feature tag would be the most feasible mechanism. Now, Hadriel have indicated that some intermediaires may remove feature tags. However, in this case, maybe that would actually be a GOOD thing, because it would automatically take care of the case where there are intermediares that don't support the INSIPID mechanism in the path :)

What do people think? If needed, I am willing to provide text.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] on behalf of Christer Holmberg [[email-masked]]
Sent: Thursday, 12 September 2013 4:12 PM
To: Hadriel Kaplan; James Polk
Cc: Atle Monrad; [email-masked]; Gonzalo Camarillo
Subject: Re: [Insipid] Timing for publishing draft-kaplan-insipid-session-id

Hi,

Regards,

Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 15 Sep 2013 23:37:32 +0000

Rather than a new feature tag, why cannot something within the header field itself define the support, e.g. even a dummy value in the proposed additional header field parameter.

Surely one the characteristics we would not want that goes with a media feature tag, is the possible selection of the recipient terminal based on the support of the extension - that certainly does not figure in our requirements.

Regards

Keith

> Sent: 14 September 2013 15:33
> Does anyone have issues with my suggestion below? I believe it could be a
> rather straight forward solution. Paul, James & co get what they want, and
> the backward compatibility folks get what they want :)
> 
> The only question is how a sender indicates that it support the INSIPID
> mechanism. From a pure SIP protocol perspective, I believe a media feature
> tag would be the most feasible mechanism. Now, Hadriel have indicated that
> some intermediaires may remove feature tags. However, in this case, maybe
> that would actually be a GOOD thing, because it would automatically take
> care of the case where there are intermediares that don't support the
> INSIPID mechanism in the path :)
> 
> From: [email-masked] [[email-masked]] on behalf of
> Christer Holmberg [[email-masked]]
> solution as backwards compatible with the kaplan draft as
> >>> possible, but that a 2 value ID will run into problems with a single
> value implementation, and that should be obvious to
> we think actually accomplishes this no matter
> >> the version of the endpoint that initiates or receives the SIP
> message... zero... and that's really disheartening.
> >
> So, if the one sending the INVITE only supports Kaplan (we need to define
> how that is determined), the receiver does not add the 2nd part, copies
> the received value into the response, and uses that in any subsequent
> request/response within the session.
> 
> And, if the receiver only supports Kaplan (the sender will figure this out
> since the receiver won't add the 2nd part), then only one part will be
> used in each request/response through the session.
> 
> Now, that takes care of backward compatibility as far as the endpoints are
> concerned. However, there could of course be an intermediary that doesn't
> support the INSIPID mechanism, but the question is whether that matters.
> 
> Regards,
> 
> Christer
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 15 Sep 2013 23:39:16 +0000

It has been stated in the INSIPID meetings that at least one, and maybe more, operators have deployed the Kaplan draft.

Regards

Keith

> Of Paul E. Jones
> Sent: 14 September 2013 06:40
> To: 'Christer Holmberg'; 'Paul Kyzivat'; [email-masked]
> > Subject: Re: [Insipid] Timing for publishing draft-kaplan-insipid-
> session-
> > id
> >
> > Hi,
> >

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 16 Sep 2013 00:48:44 -0400

Christer,

Your proposal is along the lines of what I've written a couple of times now.
What James Polk and I are thinking is that we could use the "remote"
parameter in Alice's INVITE set to "null" to indicate that she supports the
INSIPID draft.  If that is not there, then behavior falls back to Kaplan.
Likewise, the response will either echo the received value (per Kaplan) or
include a different value in the reply along with placing the received UUID
in the remote parameter (per INSIPID).

I think that's workable, but it does make the endpoint more complicated to
implement since it has to change behavior based on what it believes the
remote end supports.  And it still does not address the issues one will see
with a Kaplan device calling another Kaplan device and having the call
transferred to another device.  (In that case, one end will think that the
Session-ID is one value, while the other end thinks it is a different value.
I'm still puzzled over the insistence of going forward with the Kaplan draft
or trying to be backward-compatible with it, given we know it will not
always yield an end-to-end Session ID.)

Paul

> Sent: Saturday, September 14, 2013 10:33 AM

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 16 Sep 2013 08:16:55 +0000

Hi,

>Surely one the characteristics we would not want that goes with a media feature tag, is the possible selection of the recipient terminal based on the support of the extension - that certainly does n…

A feature tag is what we normally use to indicate capabilities, so I see no reason why we would need to have additional requirements for using it.

Having said that, I am not religious about what mechanism is used, as long as there is *A* mechanism for the receiver to figure out whether the sender supports the feature or not.

Regards,

Christer

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Christer Holmberg
> Subject: Re: [Insipid] Timing for publishing 
> draft-kaplan-insipid-session- id
> 
> Hi,
> 
> Does anyone have issues with my suggestion below? I believe it could 
> be a rather straight forward solution. Paul, James & co get what they 
> want, and the backward compatibility folks get what they want :)
> 
> The only question is how a sender indicates that it support the 
> INSIPID mechanism. From a pure SIP protocol perspective, I believe a 
> media feature tag would be the most feasible mechanism. Now, Hadriel 
> have indicated that some intermediaires may remove feature tags. 
> However, in this case, maybe that would actually be a GOOD thing, 
> because it would automatically take care of the case where there are 
> intermediares that don't support the INSIPID mechanism in the path :)
> 
> Subject: Re: [Insipid] Timing for publishing 
> draft-kaplan-insipid-session- id
> 
> Hi,
> 
> >> that
> So, if the one sending the INVITE only supports Kaplan (we need to 
> define how that is determined), the receiver does not add the 2nd 
> part, copies the received value into the response, and uses that in 
> any subsequent request/response within the session.
> 
> And, if the receiver only supports Kaplan (the sender will figure this 
> out since the receiver won't add the 2nd part), then only one part 
> will be used in each request/response through the session.
> 
> Now, that takes care of backward compatibility as far as the endpoints 
> are concerned. However, there could of course be an intermediary that 
> doesn't support the INSIPID mechanism, but the question is whether that matters.
> 
> Regards,
> 
> Christer
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 16 Sep 2013 09:24:53 +0000

Hi,

>Your proposal is along the lines of what I've written a couple of times now.

Excellent. Feel free to share some updated draft text reflecting that, so we can have a look at it, and discuss it on the list, BEFORE the Vancouver f2f meeting.

>What James Polk and I are thinking is that we could use the "remote" parameter in Alice's INVITE set to "null" to indicate that she supports the INSIPID draft.

True, now I remember that.

>If that is not there, then behavior falls back to Kaplan.

Yes.

>Likewise, the response will either echo the received value (per Kaplan) or include a different value in the reply along with placing the received UUID in the remote parameter (per INSIPID).

Awesome.

>I think that's workable, but it does make the endpoint more complicated to implement since it has to change behavior based on what it believes the remote end supports.

I don't think it makes things more complicated. The Kaplan mechanism is as easy as it gets. You only need to store a value and use it - in the same way use store e.g. the Call-Id header field value.

>And it still does not address the issues one will see with a Kaplan device calling another Kaplan device and having the call transferred to another 
>device.  (In that case, one end will think that the Session-ID is one value, while the other end thinks it is a different value.

The intention is NOT to improve the Kaplan solution. What doesn't work today, won't work tomorrow.

>I'm still puzzled over the insistence of going forward with the Kaplan draft or trying to be backward-compatible with it, given we know it will not always yield an end-to-end Session ID.)

People use it for what it does. 

Regards,

Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 16 Sep 2013 10:22:58 +0000

[As WG cochair]

[Note change of name of thread for this discussion]

Note that this discussion of fallback can be taken at two extremes.

1)	If remote end support of the Kaplan draft, rather than WG solution draft, is detected then follow the procedures of Kaplan [normative reference]; or

2)	If remote end support of the Kaplan draft, rather than WG solution draft, is detected then perform only a subset of the procedures of the WG solution draft.

My understanding of the compatibility discussion in the WG was that the viewpoint of the meeting was nearer 2), and Christer's input below seems to be in that direction. Adherance to 1) is certainly not envisaged, otherwise that would have to be a standards track document. There may be some middle ground where some special actions are possible. The ideal is getting to 2).

As chair, I would like to see called out for explicit WG agreement, once what the remote end supports has been determined, any procedures that are extra to support interoperability with Kaplan rather than subsetting of the full procedures.

Regards

Keith

> Sent: 16 September 2013 10:25
> To: Paul E. Jones; 'Hadriel Kaplan'; 'James Polk'
> Excellent. Feel free to share some updated draft text reflecting that, so
> we can have a look at it, and discuss it on the list, BEFORE the Vancouver
> f2f meeting.
> 
> parameter in Alice's INVITE set to "null" to indicate that she supports
> the INSIPID draft.
> 
> >Likewise, the response will either echo the received value (per Kaplan)
> or include a different value in the reply along with placing the received
> UUID in the remote parameter (per INSIPID).
> 
> Awesome.
> 
> >I think that's workable, but it does make the endpoint more complicated
> to implement since it has to change behavior based on what it believes the
> remote end supports.
> 
> I don't think it makes things more complicated. The Kaplan mechanism is as
> easy as it gets. You only need to store a value and use it - in the same
> way use store e.g. the Call-Id header field value.
> 
> >And it still does not address the issues one will see with a Kaplan
> device calling another Kaplan device and having the call transferred to
> another
> >device.  (In that case, one end will think that the Session-ID is one
> value, while the other end thinks it is a different value.
> 
> >I'm still puzzled over the insistence of going forward with the Kaplan
> draft or trying to be backward-compatible with it, given we know it will
> not always yield an end-to-end Session ID.)
>

---

From: James Polk <[email-masked]>
Date: Mon, 16 Sep 2013 11:42:24 -0500

At 08:37 AM 9/13/2013, Christer Holmberg wrote:
> >>>>> but that a 2 value ID will run into problems with a single 
> value implementation, and that should be obvious to everyone who 
> thinks about it for a second.
> >>>> that we think actually accomplishes this no matter the version 
> of the endpoint that initiates or receives the SIP message... 
> zero... and that's really disheartening.
> >>>
> >> One of my early proposal was that, if either endpoint supports 
> Kaplan, we simply won't use the 2 value ID.
> >> So, if the one sending the INVITE only supports Kaplan (we need 
> to define how that is determined), the receiver does not add the 
> 2nd part, copies the
> >> received value into the response, and uses that in any 
> subsequent request/response within the session.
> >> And, if the receiver only supports Kaplan (the sender will 
> figure this out since the receiver won't add the 2nd part), then 
> only one part will be used in each request/response through the session.
> >> Now, that takes care of backward compatibility as far as the 
> endpoints are concerned. However, there could of course be an 
> intermediary that doesn't support the INSIPID mechanism, but the 
> question is whether that matters.
> >

no, it was not. Paul Jones has introduced my proposal to the list, 
but I'm almost finished putting it in draft form, to be submitted 
this week, for all of us to have a concrete proposal (that can be 
torn to shreds ;-) ) before our f2f in Vancouver.

James

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 16 Sep 2013 17:18:17 +0000

Hi,

Regarding alternative 2), I guess the most "extreme" would be to not publish draft-kaplan at all, and normatively describe all procedures (including the Kaplan procedures) in draft-insipid.

However, and I guess Keith can correct me if I'm wrong, in order to be able to reference draft-insipid in older 3GPP releases, usage of the new "2 value mechanism" would have to be optional, so that draft-insipid can be added to older releases without introducing new functionality.

At least we would not need to spend time arguing which draft is published first, and hopefully we would get rid of the conspiracy theories about people wanting to sabotage work etc...

Regards,

Christer

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: 16. syyskuuta 2013 13:23
To: Christer Holmberg; Paul E. Jones; 'Hadriel Kaplan'; 'James Polk'
Cc: Atle Monrad; [email-masked]; Gonzalo Camarillo
Subject: RE: Fallback between legacy and WG solution mechanisms (was Timing for publishing draft-kaplan-insipid-session-id)

[As WG cochair]

Regards

Keith

> >Your proposal is along the lines of what I've written a couple of 
> >times
> now.
> 
> Excellent. Feel free to share some updated draft text reflecting that, 
> so we can have a look at it, and discuss it on the list, BEFORE the 
> Vancouver f2f meeting.
> 
> parameter in Alice's INVITE set to "null" to indicate that she 
> supports the INSIPID draft.
> 
> or include a different value in the reply along with placing the 
> received UUID in the remote parameter (per INSIPID).
> 
> Awesome.
> 
> to implement since it has to change behavior based on what it believes 
> the remote end supports.
> 
> I don't think it makes things more complicated. The Kaplan mechanism 
> is as easy as it gets. You only need to store a value and use it - in 
> the same way use store e.g. the Call-Id header field value.
> 
> device calling another Kaplan device and having the call transferred 
> to another
> draft or trying to be backward-compatible with it, given we know it 
> will not always yield an end-to-end Session ID.)
> 
> > be a rather straight forward solution. Paul, James & co get what 
> > they want, and the backward compatibility folks get what they want 
> > :)
> >
> > From: [email-masked] [[email-masked]] on behalf 
> > of Christer Holmberg [[email-masked]]
> > And, if the receiver only supports Kaplan (the sender will figure 
> > this out since the receiver won't add the 2nd part), then only one 
> > part will be used in each request/response through the session.
> >