This is the message I sent to the WG chairs o 11/30, in response to this special request. Steve ------ Folks, As per your request I reviewed the subject document. It has a LOT of problems: - the authors are inconsistent in their use of terms in various places in the document (e.g., trust zone, trust domain, trust group) - the authors do not clearly define what they mean by static, manual, or dynamic keying. they then make general assertions about the costs of various keying methods without providing any analysis to support their assertions. - the authors are clearly big proponents of group keying, and so they sweep under the rug all the details of what one has to do to authenticate group members to a group key server and what the server needs to do to distribute keys to the group members. there may be good arguments for why group keying is preferable to alternatives, but this document does not make that case - the authors assert that tunnel mode ESP is unsuitable for use with RSVP due to a MITM vulnerability, but the argument they present is flawed. - the authors assert that using the group keying mechanisms in RFC 3547 solves the problems of using IPsec with RSVP, which contradicts statements elsewhere about problems with IPsec protocols and RSVP. - the authors argue that Section 3.1 of RFC 5374 describes how to use tunnel mode in a way that fixes problems otherwise present with AH or ESP, but the argument is suspect. The cited section talks about a new version of tunnel mode for use by secruity gateways when sending traffic on multicast SAs, but there is not reason why routers using RSVP should be viewed as secruity gateways with respect to RSVP traffic. - overall, the document is very poorly organized. it rambles and makes arguments in one section that appear to contradict analyses in other sections. I have attached an edited version of the document with suggested edits and lots of comments. Steve Attachment: draft-ietf-tsvwg-rsvp-security-groupkeying-05.pdf Description: Adobe PDF document