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

[James Polk <[e-mail]>]

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.


>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 <[e-mail]> 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'.

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?
>
>
>I believe that technically it's not a WG document, and no WG 
>consensus is being asked for.

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.
>
>Don't get me wrong though - this whole thing is weird, and I don't 
>like the precedent this may set.

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


>-hadriel