Hi Dan,
  Thanks a lot for your comments. Please find responses inline.

On 06/30/2012 01:49 PM, Dan Harkins wrote:
> 
>   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.

Will make these changes.


> 
>   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 LineIDLen is actually 8 bits like you suspected and there is an
error in the ascii art. I will fix this in the next rev.

> 
>   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.

Great.

Thanks
Suresh