Last Call Review of draft-ietf-rmt-pi-norm-revised-

Request Review of draft-ietf-rmt-pi-norm-revised
Requested rev. no specific revision (document currently at 14)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-03-24
Requested 2009-05-01
Authors Joseph Macker, Carsten Bormann, Mark Handley, Brian Adamson
Draft last updated 2009-05-24
Completed reviews Secdir Last Call review of -?? by David Harrington
Secdir Last Call review of -?? by David Harrington
Assignment Reviewer David Harrington
State Completed
Review review-ietf-rmt-pi-norm-revised-secdir-lc-harrington-2009-05-24
Review completed: 2009-05-24



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.

The document specifies a protocol (or an update to a protocol) that
provides end-to-end reliable transport of bulk data objects or streams

over multicast routing and forwarding services. It also provides a
congestion control scheme. It is designed to permit different
upper layer services to utilize its services in different ways.

I previousaly reviewed the -09- revision, where I asked that the 
specification tighen up requirements, ala RFC2119, especially in the
Security Considerations. That was done to a degree. 

More should be done. There are places with text like "It is expected
that ..."
that might be better expressed as SHOULDs. There are lower case
must/should/may/require uses.

Since this is a requested early review, let me also comment on
document clarity.

I found some of the paragraphs have conditionals in them, often
following a 
statement of MUST or SHOULD compliance. I think the "However ..."
really hurt the clarity of the specification. For example:
   Large NORM group sizes will necessitate some form of key management
   that does rely upon shared secrets.  The GDOI and GSAKMP protocols
   mentioned here allow for certificate-based authentication.  It is
   RECOMMENDED these certificates use IP addresses for authentication
   although it may alternatively possible to have authentication
   associated with pre-assigned NormNodeId values.  However, it is
   likely that available group key management implementations will not
   be NORM-specific.

Is the information after "RECOMMENDED these certificates use IP
addresses for authentication" really needed here?
If I alternately have authentication associated with re-assigned
NormNodeId values, and do not support IP adresses for authentication,
am I still compliant?

A pet peeve - "it should be noted that" is almost always not needed.
Just make the statement, 
which effectively notes the point. Nothing "should" about it!

The same pet peeve variations: unnecessary introductory phrases or
clauses in sentences:

s/The principal issue is that configuration
   and operation of IPsec typically requires privileged user
   and operation of IPsec typically requires privileged user
s/It is expected that additional specifications may/
   Additional specifications MAY/

Some words to look at whether they are really necessary:
It is expected that
As previously noted, 
Note that
as always
as mentioned in section x.x
as noted

David Harrington
dbharrington at
ietfdbh at
dharrington at