Last Call Review of draft-kaplan-insipid-session-id-03
review-kaplan-insipid-session-id-03-genart-lc-romascanu-2013-08-21-00

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-track 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 security 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