The Multicast Group Security Architecture
RFC 3740
Yes
No Objection
Note: This ballot was opened for revision 05 and is now closed.
(Russ Housley; former steering group member) Yes
(Allison Mankin; former steering group member) No Objection
(Bert Wijnen; former steering group member) (was Discuss) No Objection
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)
(Margaret Cullen; former steering group member) No Objection
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"?
(Ned Freed; former steering group member) No Objection
Nits: No copyright, IPR boilerplate
(Steven Bellovin; former steering group member) No Objection
Some of the informative references are to very old IDs. draft-balenson-groupkeymgmt-oft is probably the worst; it's from 1999...
(Ted Hardie; former steering group member) No Objection
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.