Piling on [Gen-art] Gen-ART review of draft-kaplan-insipid-session-id-03

All

I've been out on leave since just after Berlin (which I had to cancel 
at the last minute, so I wasn't able to attend in realtime, or 
present the INSIPID reqs and solutions drafts - which I normally do 
at each IETF). Somewhere along the way, it was decided that 
draft-kaplan-insipid-session-id should be informational and not 
historic. I backed this draft becoming historic, and wouldn't have 
backed this draft becoming an informational RFC, for some very 
specific reasons that Dan's Gen-Art review successfully tease out. 
I'm glad to see that Robert and Gonzalo Salgueiro (INSIPID WG chair) 
each generally agree to (Robert's agreement is below, Gonzalo's note 
of agreement is the next message on this thread on the INSIPID list).
Basically, as the author of more than 50% of the requirements doc 
text and approximately 70% of the solution doc text (from a 2 draft 
WG) I'm intimately familiar with the topic. We, as a WG, have 2 
existing legacy drafts that were never intended to reach RFC because 
they could never get any WG to reach consensus on either; I'm 
referring to draft-kaplan-insipid-session-id-00 and 
draft-kaplan-insipid-session-id-03 (neither is compatible the other). 
But, that didn't stop 3GPP from referencing one of the (the -03 
version of the kaplan draft) - and only a few months ago it was 
decided in INSIPID that we would rather have kaplan-03 as a separate 
historic RFC than an appendix within the existing solution doc 
currently progressing in INSIPID.
But alas, now with this "magical" change, the kaplan-03 _IS_ going to 
become an I-RFC, and it's going to be AD-sponsored, so the authors 
really don't have to abide by the INSIPID WG - and I have a problem 
with that on many levels.
#1 - this bait-and-switch will produce a non-historic RFC, where 
there was NOT any specific call for consensus to do that reassignment 
on the INSIPID list. I deem that a process violation.
#2 - with IETF LC about or actually over, one could interpret any 
failure of the INSIPID WG to produce a standards-track RFC with this 
kaplan-03 document as an informational RFC as INSIPID's meeting some 
measure of success within the WG, and that is not acceptable. 
Attempting to get WG consensus to point #1 would have addressed or at 
least fleshed this out.
#3 - I firmly want what Dan refers to with his Major issue #1 below, 
in that, as a condition of the INSIPID WG successfully documenting a 
standards-track solution, this kaplan-03 draft can then be published 
- perhaps even consecutive RFCs - as an I-RFC that way the INSIPID 
solution RFC(to-be) does all the IANA registration because it has the 
lower RFC number.
#4 - I am firmly opposed to the kaplan-03 draft IANA registering any 
part of the new Session-ID header. I would like to point out that if 
Dan's #1 major issue is worked out, his major issue #2 will also 
likely be worked out as a result of making the changes necessary for 
major issue #1.
The kaplan-03 draft should be written with INSIPID's express plan to 
produce their own solution, with the intention of the kaplan-03 
document being approved *after* the INSIPID solution is RFC'd.
James


> Date: Thu, 22 Aug 2013 12:08:26 -0500
> From: Robert Sparks <rjsparks(_at_)nostrum(_dot_)com>
> To: "Romascanu, Dan (Dan)" <dromasca(_at_)avaya(_dot_)com>
> CC: "gen-art(_at_)ietf(_dot_)org" <gen-art(_at_)ietf(_dot_)org>,
>         
> "draft-kaplan-insipid-session-id(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org"
>         <draft-kaplan-insipid-session-id(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org>, 
> "insipid(_at_)ietf(_dot_)org"
>         <insipid(_at_)ietf(_dot_)org>
> Subject: Re: [Insipid] [Gen-art] Gen-ART review of
>         draft-kaplan-insipid-session-id-03.txt
>
> Adding the working group.
>
> Dan - thanks for this review. I've been working towards trying to 
> express a concern, and this really helped clarify what was bothering me.
> This document, AFAIK, _is not_ actually trying to register the 
> Session-ID header with IANA, even though there is a section that 
> looks like it does.
> Rather, that registration is in 
> http://datatracker.ietf.org/doc/draft-ietf-insipid-session-id/
> That is a very good example of how just adding the explanatory 
> paragraph at the beginning of the document isn't enough to turn this 
> into something that documents an earlier path considered and 
> implementation that exists current deployments - the text needs to 
> be touched in several places to make it clear that's what the 
> document is doing.  In the IANA considerations case, one possible 
> adjustment is to change the text to "here's what known 
> implementations have used for syntax. See 
> [draft-ietf-insipid-session-id] for the intended registered syntax", 
> and not issue instructions to IANA.
> It's more work for Hadriel, but I think it's necessary.
>
> RjS
>
>
> On 8/21/13 12:26 PM, Romascanu, Dan (Dan) wrote:
> > I am the assigned Gen-ART reviewer for this draft. For background 
> > on Gen-ART, please see the FAQ at
> > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> >
> > Please resolve these comments along with any other Last Call 
> > comments you may receive.
> > Document: draft-kaplan-insipid-session-id-03.txt
> > Reviewer: Dan Romascanu
> > Review Date: 8/21
> > IETF LC End Date: 8/30
> > IESG Telechat date:
> >
> > Summary:
> > Ready with Issues
> >
> > Major issues:
> >
> > 1. In similar situations when IETF WGs decided to document 
> > proprietary solutions that were used as a basis for standards-track 
> > RFCs Historic RFCs were issued rather than Informational RFCs. See 
> > for example RFC 5412, 5413, 5414 which documented the prior art 
> > that was used to create RFC 5415. Publication of these documents 
> > was also withhold until the standards-track RFC was published. None 
> > of these precedents is followed here. One of the reasons for the WG 
> > to prefer Informational rather than Historic is the fact that the 
> > registration of a new SIP header field is required from IANA, and 
> > in conformance with RFC 5727 this can be done in an Informational 
> > RFC, but not in a Historic one. What is missing however is clear 
> > text that the solution described in this document is a legacy 
> > solution and that the solution going forward is the one that is 
> > being defined by the INSIPID WG. The IESG should also consider 
> > whether this document should be approved for publication before the standards
> -t
> >   rack solution defined by the INSIPID WG is also published.
> >
> > 2. The Abstract makes the claim that the Standards-Track RFC that 
> > will be eventually produced by the INSIPID WG will be developped in 
> > a backwards-compatible manner with this document. This does not 
> > seem appropriate here - if at all such a requirement should be 
> > included in draft-ietf-insipid-session-id-reqts-08.txt. However it 
> > does not appear there, and that document was recently submitted for 
> > publication to the IESG, so the WG did not include it in its consensus.
> > Minor issues:
> >
> > 1. The IANA considerations sections need to be more explicit in 
> > demonstrating that the conditions for registration of extension SIP 
> > header fields in Informational RFCs have been met as per RFC 5727. 
> > That RFC defines that Designated Expert review needs to happen for 
> > such new registrations - I could not find a proof that such a 
> > review took place in the shepherd write-up. Actually the question 
> > about the expert reviews is not answered directly, instead of an 
> > answer wide deployment is mentioned, but that deployment could not 
> > use this SIP header field which was not yet approved. According to 
> > RFC 5727 there are two basic conditions that need to be verified by 
> > the Designated Expert - that the proposed header field must be of a 
> > purely informational nature and must not significantly change the 
> > behavior of SIP entities that support it, and that the proposed 
> > header field must not undermine SIP security in any sense, and that 
> > the Informational RFC defining the header field must address
> se
> >   curity issues in detail, as if it were a standards-track 
> > document. I believe that both conditions are met by the I-D, but 
> > there is no adequate text in the IANA considerations section to explain this.
> > Nits/editorial comments:
> >
> >
> > Regards,
> >
> > Dan
> >
> >
> > _______________________________________________
> > Gen-art mailing list
> > Gen-art(_at_)ietf(_dot_)org
> > https://www.ietf.org/mailman/listinfo/gen-art
>
> _______________________________________________
> insipid mailing list
> insipid(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/insipid