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. The draft is a generally well-written description of some issues with securing neighbour discovery when proxies are involved. As a problem statement draft I find it just fine. I have two minor security comments and a few nits below. Stephen. 1. The suggestion at the end of 4.2 that certificate serial number or time field ordering be used to indicate relationships between end entities seems very hacky. I'd suggest either deleting that if its felt to be unlikely used, or else, if its actually likely to be used, then documenting how it could actually work 2. 7.2 mentions "signed, non-repudiable certificates" which is a horribly odd phrase. Hopefully that's just sloppy language. (s/signed, non-repudiable//), but if not, then its a concern (the concern being that non-repudiation in protocols is mythical). Nits: 1. 2nd last para of 3.1: fix word ordering in last sentence, think it ought say: Such a message would be valid according to the SEND specification, if the Target Address and the source IPv6 address of the Neighbor Advertisement weren't different [RFC3971]. 2. 2.2.4 1st para: similar word ordering, maybe: The router or CA may then be able to certify proxying for only a subset of the prefixes for which it is certified. 3. 1st sentence of 7.2: s/The certificagte delegation/Certificate delegation/