The Multicast Group Security Architecture
draft-ietf-msec-arch-05

From OPS Directorate (Pekka):


nits:
-----
 - there are some references which aren't referred to in the body of 
the draft, at least RFC3552.
 - IPR section should be added, even though it's likely the 
architecture document would be subject to such IPR (rather than the 
referred methods)

I have the following editorial comment:

   This is true because multicast routing protocols generally require 
   the source of an IP multicast packet to remain unchanged in order to 
   create distribution trees.

>> It is not clear to me how the second sentence follows from
>> the third...  

   However, if NAT is deployed in a network 
   for IP multicast packets (e.g., between administrative entities), 
   then the connectivity of senders and receivers may be adversely 
   affected. 

>> What is "a network for IP multicast packets"?  And, how is this
>> sentence consistent with the statement that "In general, NAT is
>> not a problem with IP multicast traffic"?

Nits: No copyright, IPR boilerplate

Some of the informative references are to very old IDs.  draft-balenson-groupkeymgmt-oft is probably the worst; it's from 1999...

Nit:  In section 4.2, there is a bounding box around figure 3.  Since 3a and 3b represent
different set relationships, having a bound box around the whole is confusing (as it looks
like a set containing the sets in 3a and 3b).  If others find it similarly confusing, 
I'd suggest splitting 3a and 3b out of the box.