[secdir] secdir review of draft-ietf-rmt-pi-norm-revised-11

"David Harrington" <ietfdbh@comcast.net> Mon, 04 May 2009 20:23 UTC

From: David Harrington <ietfdbh@comcast.net>
To: secdir@ietf.org
Date: Mon, 04 May 2009 16:25:01 -0400
Message-ID: <05a401c9ccf6$67ac3550$0600a8c0@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcnM9ma544Dx/Yr6RNyYA24XSVmxyQ==
Cc: 'Magnus Westerlund' <magnus.westerlund@ericsson.com>, tim.polk@nist.gov, Pasi.Eronen@nokia.com, adamson@itd.nrl.navy.mil, M.Handley@cs.ucl.ac.uk, cabo@tzi.org, 'Joe Macker' <macker@itd.nrl.navy.mil>, 'Lorenzo Vicisano' <lorenzo@vicisano.net>
Subject: [secdir] secdir review of draft-ietf-rmt-pi-norm-revised-11
Precedence: list

Hi,

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 ..."
conditionals
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
   authorization./Configuration
   and operation of IPsec typically requires privileged user
   authorization./
s/It is expected that additional specifications may/
   Additional specifications MAY/

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






David Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharrington@huawei.com

[secdir] secdir review of draft-ietf-rmt-pi-norm-… David Harrington
Re: [secdir] secdir review of draft-ietf-rmt-pi-n… Magnus Westerlund
Re: [secdir] secdir review of draft-ietf-rmt-pi-n… Brian Adamson