Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01

Is there something else that the link-layer address could be mis-construed as to referring to? Even after they read the section about how it is to be attached describing hardware type as specified in RFC? 

3. DHCPv6 Client Link-layer Address Option 

The format of the DHCPv6 Client Link-layer Address option is shown 
below. 
0 1 2 3 
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| OPTION_CLIENT_LINKLAYER_ADDR | option-length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| hardware type (16 bits) | | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 
| link-layer address (variable length) | 
| | 
| | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

option-code: OPTION_CLIENT_LINKLAYER_ADDR (TBD) 
option-length: 2 + length of link-layer address 
hardware type: Client Link-layer address type. The hardware type MUST be a 
valid hardware type assigned by the IANA, as described in [RFC0826] 
link-layer address: Client Link-layer address. 

----- Original Message -----

> From: "Chuck Anderson" <cra@WPI.EDU>
> To: "Ted Lemon" <Ted.Lemon@nominum.com>
> Cc: "dhc WG" <dhcwg@ietf.org>
> Sent: Thursday, August 16, 2012 2:21:30 PM
> Subject: Re: [dhcwg] WGLC:
> draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01

> On Thu, Aug 16, 2012 at 05:43:12PM +0000, Ted Lemon wrote:
> > Chuck, I think I can read your response as saying that you are
> > happy with the draft as it is, and while you would not oppose
> > having the draft say how the DHCP server might acquire the link
> > local address for a packet that arrived without being relayed, you
> > don't think it's necessary or desirable, correct? (I ask only so
> > that we will know what to do later on when we evaluate consensus).

> I don't think it is necessary to update this draft to specify how a
> DHCP server might acquire the link layer address from a non-relayed
> packet, and I'm somewhat opposed to updating this particular draft
> for
> that behavior now only because it would add more delay.

> However, I do recognize that there may be benefit to updating section
> 4 to clarify what LL address is to be put into the RELAY-FORW option,
> but I'm open to others' opinions on this. Do others think this text
> is clear enough, or do we need to clarify what goes into the "client
> link-layer address option"? Right now it just doesn't say what goes
> in there:

> "4. DHCPv6 Relay Agent Behavior

> DHCPv6 Relay agents which are directly connected to clients/hosts MAY
> include client link-layer address option in relayed DHCPv6 (RELAY-
> FORW) message. The DHCPv6 Relay agent behaviour can depend on
> configuration that decides whether Client Link-layer Address option
> needs to be processed and included.

> In Relay chaining scenarios, any other relay agent other than first
> hop DHCPv6 Relay agent or DHCPv6 LDRA [RFC6221] MUST not add this
> option."
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg