Re: [secdir] secdir review of draft-peterson-rai-rfc3427bis-02.txt

[Jon Peterson <[e-mail]>]

Hello Stephen,

Sorry for the lengthy delay getting back to you on this one.

This is a very detailed and helpful review that caught a lot of important
issues. I've given your points below some consideration, and discussed a bit
with the RAI ADs. To the most important issue first:

I do agree that the level of security expertise required of the Designated
Expert is a potential area of concern. The decision to allow IANA
registration of headers supervised by a Designated Expert was not an easy
one, though we believe it balances the needs of the community to specify new
headers freely and rapidly with the basic mandate to prevent conflicts in
the namespace and preserve interoperability. The SIP community has become
large and diverse, and represents a huge number of interests who define new
proprietary headers today without leaving a trace in the IANA precisely
because the original RF3427 process is too cumbersome. We would like to lure
those parties into registering those headers with this more lightweight
process.

As the "stuckee" who reviewed many of the P- header submissions under the
original RFC3427 over the past six years, it was my own judgment that
external parties mostly used the P- header process to specify the conveyance
of information which had value to their own systems but did not alter SIP
transaction processing. Reducing the P- header process to the one in
RFC3427bis, where these IANA-registered headers are "informational" in
nature ,is a small incremental step from the P- usage under the original
RFC3427.

If a proposed header introduced a new SIP security mechanism to replace,
say, RFC2617-style authentication or TLS, I think it unambiguously would not
be purely "informational" in nature - they would, as new text in RFC3427
says, "redefine or contradict normative behavior defined in standards track
SIP specifications." While I agree that the review of a RAI Area Expert is
not the same as a security review, I do believe the Designated Expert can
distinguish between a mechanism that changes the behavior of SIP and one
that does not. I suspect anything that undermined the security of SIP in
that sense would fail this check, and thus be ineligible for registration
through this "informational" channel.

Does that make sense? This is your most substantive comment, but it also
proposes that we reverse more or less the sole motivation for this document
- making it easier to register headers of an informational nature.

Regarding the second concern about IANA registration of headers, the
longevity of external references versus RFCs, for the most part (from the
precedent of P- headers) we expect that external standards bodies will be a
primary customer of this mechanism, and thus we don't want to rule out
pointers to their own long-lived publications.  RFC5226 does have a
registration model called "Specification Required" which, on balance, I
wouldn't object to using here if that would remove your concern.

It might appear that the other stipulations in RFC3427 Section 4.1 that
applied to reviewers of P- headers no longer apply in RFC3427bis, but
actually almost all of them are preserved, including the review of overlap
(that's actually in RFC3427bis Section 4 in the paragraph right before
bullet 1), and of course the Expert Reviewer. The only things actually
removed are the request for clear documents (which is a bit of a
motherhood-and-apple-pie requirement) and the applicability statement, and
that only because there is no longer necessarily an RFC for it to live in -
we can't expect an external publication to have an IETF-ready applicability
statement. 

To some of your more detailed points:
 
> * Does the term "consensus" in the first sentence of the
>   third paragraph of section 3 refer to WG consensus or
>   IETF consensus? I believe that it refers to WG consensus
>   but this should be clarified.

It does indeed mean WG consensus, fixed.

> * The last sentence of the fifth paragraph in section 3
>   says that the DISPATCH working group may "approve
>   proposals for extensions if the requirements are judged
>   to be appropriate to SIP, but are not sufficiently
>   general for standards track activity." I think that
>   these proposals would then proceed as individual
>   submissions. If that's right, I suggest that this be
>   mentioned in this sentence.

This sentence is actually a holdover from the original RFC3427 and needs to
be eliminated, as a separate reviewer recently pointed out. The DISPATCH WG
is not chartered to perform any protocol work whatsoever. So in a sense you
are correct that these proposals would proceed as individual submissions,
but the DISPATCH WG does not in any sense "approve" them.

> * The first paragraph of section 4.1 says that "Normal
>   event packages can be created and registered by the
>   publication of any Working Group RFC (Informational,
>   Standards Track, Experimental), provided that the RFC
>   is a chartered working group item." However, the
>   next paragraph describes how individual submissions
>   for event packages may be published. This seems to
>   be a contradiction. Maybe the sentence that I just
>   quoted is not intended to exhaustively describe all
>   the ways that event packages can be created. If that's
>   the case, the sentence should be clarified.

I'm not quite sure I see the contradiction you do here - but nor do I really
think the first sentence you quote above really adds any value to the
section, so I'm happy to remove it. The remainder of the guidance here is
more exact.  

These below are all very welcome!

> * Paragraph four of section 4.1 says that the procedure
>   for registering event packages developed outside the
>   scope of an IETF working group is "RFC Required".
>   However, the process described in the following
>   paragraphs would better be described as "RFC Required
>   with Designated Expert Review".

Okay, I'll put that.

> * As the first paragraph in the Security Considerations
>   section says, feature interactions can have significant
>   security implications. However, the text should go one
>   step beyond to require that all RFCs that modify or
>   extend SIP must consider the security implications of
>   feature interactions.

Okay, I'll tag that on to the last sentence of the Sec Cons.

> * The fifth paragraph of section 7 says that "For event
>   template packages, registrations must follow the RFC5226
>   processes for Standards Action." Actually, the earlier
>   part of this document included an additional requirement
>   that such specifications must be developed by an IETF
>   Working Group. Probably that should be documented here.

Added.

> * The fifth paragraph of section 7 also states that
>   IETF Review is the process used for ordinary event
>   packages. That is not consistent with section 4.1,
>   which states that the process for these is RFC Required
>   (with Designated Expert review). I think that
>   section 4.1 is correct and the text in section 7
>   should be updated.

Fixed.

> Here are my non-substantive comments.
> 
> * In the first paragraph of section 2, "SIP has to preserve"
>   should be "SIP has been to preserve".

Fxd.

> * In the first paragraph of section 2.1, the word "exists"
>   should be removed from the end of the first sentence.

Fxd.

> * In the second paragraph of section 2.1, the phrase
>   "updates or obsoletes" is not clear. I suggest using
>   the phrase "documents that update or obsolete".
>   Further, I suggest adding the phrase "or their successors"
>   at the end of that sentence.

Fxd.

> * In the third paragraph of section 2.1, "will the use"
>   should be "will use". In the following sentence, delete
>   the phrase "and the rest of this document". That is
>   a copy and paste error left over from RFC 3427,
>   I think. In the last sentence of this paragraph,
>   I suggest changing "any protocol in the IETF" to
>   "SIP (and any protocol in the IETF)". The emphasis
>   should be on SIP in this document.

Yeah, that latter bit is all legacy text, nuking.

> * In the fourth paragraph of section 2.1, change the
>   first sentence to say "IETF working group" instead
>   of just "working group". I think that's the intent
>   but someone could read it to include working groups
>   of other organizations also.

Fxd.

> * In the second paragraph of section 4, there's an
>   extra comma after "While". Also, I think the word
>   "general" is missing after the phrase "deal with
>   a point solution and are not".

Fxd and Fxd.

> * In the sixth paragraph of section 4, the phrase
>   "Informational IETF specifications" would be
>   clearer if it was replaced by "Informational RFCs".

Fxd.

> * The first paragraph of section 4.1 includes a
>   reference to "[6]" but references in this spec
>   are of the form "[RFCXXXX]". I believe this
>   reference is supposed to be [RFC3265].

Fxd.

> * In the numbered list at the end of section 4.1,
>   several references use the wrong format. The
>   references to [6] should be [RFC3265] and the
>   reference to [3] should be [RFC3261], I think.

Fxd.

> * The text "(See Section 4)" appears in the list
>   at the end of section 4.1 but the meaning of
>   this text is not clear. Please clarify.

That's in reference to the "must not redefine or contradict normative
behavior" text in Section 4 - I think that's clear where it is now.

> * More numeric references appear in section 6.
>   These can easily be transformed to the more
>   explicit style used in this document since
>   the RFC numbers are adjacent to the references.

Fxd!