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

[Brian Adamson <[e-mail]>]

All,

I have submitted an updated NORM draft that I hope fully addresses  
Dave's comments here.  I actually took his recommendations on clarity  
of requirements language (SHOULDs, etc) throughout the whole document  
and not just the security issues section.   There were a number of  
cases where there were lower-case "should", "must", etc that needed to  
be emphasized with upper case or alternative language used to make the  
requirements aspects clearer.  This was a worthwhile exercise as I  
found a few more grammatical errors, etc as well.



Brian Adamson
[e-mail]




On May 4, 2009, at 4:25 PM, David Harrington wrote:

> 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
> [e-mail]
> [e-mail]
> [e-mail]
>