I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I found no major issues with this document. The security considerations section doesn't really discuss who is trusting whom for what in great detail. I assume that the RG client and RG server implicitly trust one another as they are on the same box and communication between them is outside the scope of the document. I also assume that the SP server treats the RG client and RG server as a single entity and does not care that the options are in control of the RG client before they reach the RG server. Most of this seems obvious, but this might clear things up a bit: "The RG client and RG server are collocated within the RG and are treated as the same entity by the SP server. The communication mechanism between the RG client and RG server is local to the RG and assumed to protect the option from unauthorized access in transit. A rogue server can use this option to pass invalid information to the RG client, which would then be passed to the Client hosts by the RG server. This invalid information could be used to mount a denial of service attack or a man-in-the-middle attack against some applications. Authentication of DHCP messages (RFC 3118 [RFC3118] and section 20 of RFC 3315 [RFC3315]) can be used to ensure that the contents of this option are not altered in transit between the SP DHCP server and RG client." The other comment I have is that I don't think RFC 3118 isn't particularly deployable. I can see it being used between the SP server and RG client where management relationships are in place, but I'm not sure it is very realistic to deploy between client hosts and the RG server. Do other mechanisms such as L2 protection help here? Cheers, Joe