Hello, 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. This draft defines a new destination option for IPv6 datagrams that tunnel router solicitation and router advertisement messages. The purpose of the option is to allow an edge router in a broadband subscriber network to identify a particular subscriber that comes up. I found the draft a bit confusing. Terms are referred to before they are defined and once defined are not consistently used. There were several paragraphs that I had to re-read a couple times to figure out what was being intended. I would suggest the following editorial changes: - in section 1.1, move definition of GPON and RG up before they are referred to (AN, and Edge Router, respectively) - in section 5.3, pick either AN or "access node" and stick to it. By sometimes referring to the entity by acronym and sometimes by full name, the casual reader (me) does not immediately tie them together and creates 2 entities in his mind as he's putting the described behavior together. - in section 6.2 it talks about creating a new IPv6 datagram, then about adding the option to it and how to determine the contents of this datagram, and then it says a new IPv6 datagram is created. Wait, so there's 2 IPv6 datagrams or is this the same one? I had to read this a few times to figure out what's going on. There is an apparent technical problem in section 7 where the new option is laid out. The option type is an octet and the option length is also an octet (whose length does not include the option type or itself). Then follows the a field for the length of the lineID and the lineID itself. But the length of the lineID is 2 octets implying that a lineID can be more than 255 octets long. How does this work? If the lineID itself is greater than 253 octets then the length required to be encoded in the option length would be greater than 255 which cannot be described with a single octet. Either there is the possibility of a valid but unparsable option that would likely make the rest of the packet unparsable too (which is bad) or the lineID can never be greater than 253 octets which then makes me ask why the field to encode its length has to be 2 octets? The other option is, of course, that I'm completely missing something. If that's the case, forgive my ignorance but please do enlighten me. I found no security issues with the draft that require the attention of the ADs. The Security Considerations mention that this is all unauthenticated and should only be used on a network where the communicating entities are already trusted, which seems reasonable for the way this will be deployed. regards, Dan.