Last Call Review of draft-peterson-rai-rfc3427bis-
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
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
* 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 "" 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  should be [RFC3265] and the
reference to  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.