[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 <nordm...@sonic.net>
To: Suresh Krishnan <suresh.krish...@ericsson.com>
CC: Erik Nordmark <nordm...@acm.org>, Glen Turner <g...@gdt.id.au>,
6man Mailing List <ipv6@ietf.org>, Brian Haberman
<br...@innovationslab.net>, Bob Hinden <bob.hin...@gmail.com>
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
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
