The Multicast Group Security Architecture
RFC 3740

Note: This ballot was opened for revision 05 and is now closed.

(Russ Housley) Yes

(Steven Bellovin) No Objection

Comment (2004-01-07 for -)
No email
send info
Some of the informative references are to very old IDs.  draft-balenson-groupkeymgmt-oft is probably the worst; it's from 1999...

(Margaret Cullen) No Objection

Comment (2004-01-08 for -)
No email
send info
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 

>> 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"?

(Ned Freed) No Objection

Comment (2003-12-20 for -)
No email
send info
Nits: No copyright, IPR boilerplate

(Ted Hardie) No Objection

Comment (2004-01-08 for -)
No email
send info
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.

(Allison Mankin) No Objection

(Bert Wijnen) (was Discuss) No Objection

Comment (2004-01-08)
No email
send info
From OPS Directorate (Pekka):

 - 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)