Last Call Review of draft-peterson-rai-rfc3427bis-

Request Review of draft-peterson-rai-rfc3427bis
Requested rev. no specific revision (document currently at 04)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-03-25
Requested 2009-03-13
Other Reviews
Review State Completed
Reviewer Steve Hanna
Review review-peterson-rai-rfc3427bis-secdir-lc-hanna-2009-08-03
Posted at
Draft last updated 2009-08-03
Review completed: 2009-08-03


I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document replaces RFC 3427, refining the SIP change process.
Although I have some familiarity with SIP, my knowledge of this
area is minimal. I have not participated in any of the RAI WGs
or in the SIP change process. My comments should therefore mainly
be taken as those of an IETF "common man" and a security expert.

I have very few security concerns related to this document.
As with RFC 3427, this document continues to require all new
SIP headers and event packages (the only extensions that can
be registered without going through an IETF WG) to be reviewed
by a Designated Expert using guidelines that include strict
security requirements.

My only security concern with this process is that a Designated
Expert might not have much or any security expertise. A truly
dedicated reviewer without such expertise would seek specialized
review for security issues but many reviewers are overworked or
not able to obtain security help. This problem could be solved
by requiring all SIP extensions to become RFCs, therefore ensuring
that they get broad review, including secdir reviews. RFC 3427
required this. This draft proposes to remove the requirement
for RFC publication for SIP headers, allowing IANA registration
of SIP headers that receive Designated Expert review but are
not published as RFCs. I suggest that this change not be made
since it will reduce the security review of these extensions.

Another reason to not allow IANA registration of SIP headers
without RFC publication is that there may not be a permanent and
clear definition of these headers. If a header is only documented
on a vendor web site, that documentation can disappear at any time.

Other changes that were made to the SIP header registration
process include a large reduction in the number of guidelines
for expert reviewers. The requirements dropped include these:
applicability to SIP, lack of overlap with current or planned
SIP extensions, clear documents, and an applicability statement
when the extension is not suitable for use on the Internet.
Removing those guidelines seems unwise to me.

I have divided the rest of my comments into substantive and
non-substantive comments. First, the substantive ones.

* 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.

* 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.

* 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.

* 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".

* 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.

* 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.

* 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.

Here are my non-substantive comments.

* In the first paragraph of section 2, "SIP has to preserve"
  should be "SIP has been to preserve".

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

* 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.

* 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.

* 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.

* 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".

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

* 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].

* 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.

* 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.

* 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.