[This time it should make it to the list]
-------- Original Message --------
Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-lineid-02.txt>
Date: Tue, 08 Nov 2011 08:50:42 -0800
From: Erik Nordmark <[email protected]>
To: Suresh Krishnan <[email protected]>
CC: Erik Nordmark <[email protected]>, Glen Turner <[email protected]>,
6man Mailing List <[email protected]>, Brian Haberman
<[email protected]>, Bob Hinden <[email protected]>
On 11/6/11 5:24 PM, Suresh Krishnan wrote:
Will do. Would a simple statement e.g. that it is a null terminated
text string be sufficient or did you want more details?
Or should we refer to the corresponding DHCPv4 relay option?
I think the simple case is when operators reuse the syntax
they use for line identification with DHCPv4. But I haven't
look at exactly how that DHCP option is specified.
The corresponding DHCPv4 relay option (defined in RFC3046) and the
corresponding DHCPv6 relay option (defined in RFC4649) are both
defined as opaque with no character set information. That is what
makes definition more difficult.
I guess I don't understand why we would want to constrain it any more
than the DHCP relay options.
It would be helpful to put a sentence in section 7 providing the
motivation for it being just an opaque byte string. Something like
The Line Identification is an opaque sequence of "Option Length"
number of bytes (with no NULL termination etc). That matches
the lack of constraints on the corresponding DHCPv4 and DHCPv6
relay options.
Erik
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
