Re: Piling on [Gen-art] Gen-ART review of draft-kaplan-insipid-session-i

Gonzalo

comments in-line (for context) below

At 05:47 AM 9/12/2013, Gonzalo Camarillo wrote:
> Hi,
>
> there have been several threads related to this draft and not all of
> them have taken place on the IETF general list. Let's try and use this
> thread to resolve the few issues that have been brought up during the
> IETF LC.
>
> 1) Informational vs. Historic
>
> This draft documents a mechanism that has been widely deployed in the
> field. The goal is to have a stable reference (i.e., an RFC) to the
> mechanism. Examples of groups that need to reference this mechanism are
> the INSIPID WG and 3GPP, which uses it in the IMS. In order to make the
> goal of the draft clear, the Abstract says the following:
>
>    This RFC, which contains the text of an individual Internet Draft
>    that was submitted originally to the DISPATCH Working Group, is
>    being published now as an Informational document to provide a
>    reference for later RFCs.  The mechanism defined in this document
>    has been widely deployed, and is being followed in a backward-
>    compatible fashion for a new Standards Track RFC in the INSIPID
>    Working Group.  The original Abstract follows.
>
> Additionally, the IETF LC said the following:
>
> > Note that this IETF last call is not intended to form IETF consensus on
> > the content of this document. Consequently, the IESG is only looking for
> > comments on the value of publishing this document as-is, not for
> > comments on the content of the document.
>
> In addition, we had to decide whether the eventual RFC would be Historic
> or Informational. The IETF has not been consistent in how to publish
> this type of stuff in the past. Sometimes we have used Historic RFCs and
> sometimes we have used Informational ones. At some point, we can have a
> discussion, issue an IESG statement or an RFC explaining what to do in
> these cases, and be done with it. However, at this point we do not have
> consistent guidelines. The IESG had a conversation about this particular
> draft. We decided to make it Informational because while RFC 2026 seems
> to allow the use of Historic RFCs for this purpose, Section 6.4 talks
> about Historic RFCs only in the context of Standards Track RFCs.
>
> http://tools.ietf.org/html/rfc2026#section-6.4
>
> That was why Informational seemed a better choice.
>
> In any case, whether this RFC becomes Informational or Historic, is a
> very minor issue, IMHO. As Hadriel, editor of this draft, has mentioned
> many times, most people out there do not even know the differences
> between the different types of RFCs.  It is far more important to
> clearly document why this mechanism is being published. So, if you have
> comments on the Abstract (e.g., if you think it could be clearer),
> please send text.
>
> 2) IANA Considerations and relation with the mechanism being developed
> in the INSIPID WG
>
> This draft is an individual submission that is being AD sponsored. So,
> it is not a product of the INSIPID WG. Note that per the SIP Change
> Process documented in RFC 5727, it is perfectly acceptable to register
> SIP header fields in this way:
>
> http://tools.ietf.org/html/rfc5727#section-4
>
> Therefore, this draft registers the Session-ID header field with the
> IANA. The designated expert is reviewing this registration, per the
> rules in RFC 5727.
>
> There have been comments regarding the fact that the mechanism being
> developed by the INSIPID WG will be backwards compatible with the
> mechanism described in this draft. That is a decision the INSIPID WG has
> made, although it is not part of the requirements document the WG has
> produced. Note that it is completely OK for a WG to decide to meet
> additional requirements such as this one while developing a mechanism.
>
> The issue is that, when the INSIPID mechanism is eventually published as
> an RFC, it will probably use the same header field name (i.e.,
> Session-ID). Therefore, the IANA Registry would need to be updated to
> point to that RFC instead of this draft. Updating the IANA registry in
> this way when INSIPID completes its charter does not seem to be a
> problem. Even if INSIPID, for whatever reason, did not manage to produce
> a mechanism in the future, the IANA registry would point to this draft
> so that no other RFC could reuse the Session-ID token.
>
> Therefore, there does not seem to be a good reason for delaying the
> publication of this draft, considering that 3GPP needs to reference it
> in one of its releases and they have tight deadlines.
>
> Comments?
Yeah - playing devil's advocate here, say you have a small group of 
participants from another SDO that only want this kaplan draft to 
reach RFC status, say, by sabotaging any further work coming out of a 
WG (in this case INSIPID) to ensure that their AD-sponsored draft is 
the only solution that reaches RFC (and I'm not saying 3GPP is doing 
this, I'm merely playing devil's advocate)... then in publishing this 
non-WG consensus draft (that's been around for 5 years now) as an RFC 
before the INSIPID (or any) WG standards-track solution is published 
as an RFC is undercutting this and any other WG in the same situation?
To quote you from above "...most people out there do not even know 
the differences between the different types of RFCs..."
In other words, I'm postulating that if a small subset of a WG could 
get their favorite draft that has (and will) not reach WG consensus 
published as an RFC, then where exactly is this subset going to 
benefit from a competing proposal, even if backwards compatible (it's 
gotta be more complicated to implement, right?), published in "phase 
II" or any WG?
Said even another way - couldn't this small subset make enough of a 
stink about the WG draft, once they have gotten their ID published as 
an RFC, to ensure it will never be published?
Is that really where we want to go as a community?

I'm suggesting that this AD-sponsored draft *not* get published until 
after the WG solution is published (originally proposed by Dan 
Romascanu in his Gen-ART review of this draft). Do this, and I 
believe this problem of getting around any WG intent goes away.
James


> Cheers,
>
> Gonzalo
>
>
> On 04/09/2013 10:41 PM, James Polk wrote:> 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
> >
> >