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

[Magnus Westerlund <[e-mail]>]

Hi David,

Thanks for your review.

I forwarded your message to the WG. We have other documents with similar
security considerations that needs to be clarified. I am taking your
feedback serious and tries the WG to provide feedback on your comments.
I think there will be a benefit in clarifying the implementation
requirements for these solutions.

Cheers

Magnus

David Harrington skrev:
> 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]
> 


-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------