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@xxxxxxxxxxx>
To: "Romascanu, Dan (Dan)" <dromasca@xxxxxxxxx>
CC: "gen-art@xxxxxxxx" <gen-art@xxxxxxxx>,
"draft-kaplan-insipid-session-id.all@xxxxxxxxxxxxxx"
<draft-kaplan-insipid-session-id.all@xxxxxxxxxxxxxx>,
"insipid@xxxxxxxx"
<insipid@xxxxxxxx>
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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________
insipid mailing list
insipid@xxxxxxxx
https://www.ietf.org/mailman/listinfo/insipid