Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments. As far as I can tell, the document is ready to be published from a technical point of view. Since similar filters are known to be useful for DHCPv4, I assume that this specification will also be useful for DHCPv6. I am not sure, though, why this is proposed as a Best Current Practice (BCP) RFC. The cousing, RFC 6105, is Informational. I guess this points down to OPSEC charter text that says "The OPSEC WG is will not write or modify protocols." But taking the charter politics aside for a moment, it seems strange to publish a document using phrases such as "claim compliance with this specification" as BCP. Editorial nits: - I do not like the two 'aforementioned' in the abstract and the second may even not be accurate (or one needs a very liberal definition of mechanism). Here is an attempt of a rewrite: This document specifies a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers. It is based on DHCPv6 packet-filtering at the layer-2 device at which the packets are received. A similar mechanism has been widely deployed in IPv4 networks ('DHCP snooping'), and hence it is desirable that similar functionality be provided for IPv6 networks. - Section 5 is titled "DHCPv6-Shield Implementation Advice". It uses RFC2129 MUST language and talks about criteria for compliance. Is "Advice" really the right word for this? Sounds a bit soft for what are actually implementation requirements. - At the end of section 7, s/address. spoofing/address spoofing/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 < http://www.jacobs-university.de/ >