"hardware" data-expr and RFC-3315

[Philip A. Prindeville]

I'm looking at RFC 3315, section 9.4 right now, and seeing:

9.4. DUID Based on Link-layer Address [DUID-LL]

   This type of DUID consists of two octets containing the DUID type 3,
   a two octet network hardware type code, followed by the link-layer
   address of any one network interface that is permanently connected to
   the client or server device.  For example, a host that has a network
   interface implemented in a chip that is unlikely to be removed and
   used elsewhere could use a DUID-LL.  The hardware type MUST be a
   valid hardware type assigned by the IANA, as described in RFC 826
   [14].  The hardware type is stored in network byte order.  The
   link-layer address is stored in canonical form, as described in RFC
   2464 [2].  The following diagram illustrates the format of a DUID-LL:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               3               |    hardware type (16 bits)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .             link-layer address (variable length)              .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The choice of network interface can be completely arbitrary, as long
   as that interface provides a unique link-layer address and is
   permanently attached to the device on which the DUID-LL is being
   generated.  The same DUID-LL SHOULD be used in configuring all
   network interfaces connected to the device, regardless of which
   interface's link-layer address was used to generate the DUID.

   DUID-LL is recommended for devices that have a permanently-connected
   network interface with a link-layer address, and do not have
   nonvolatile, writable stable storage.  DUID-LL MUST NOT be used by
   DHCP clients or servers that cannot tell whether or not a network
   interface is permanently attached to the device on which the DHCP
   client is running.


and wondering if the function "hardware" should be replaced by two functions, one called "hardware-type" which returns the ARP-type (as per ASSIGNED NUMBERS, "ADDRESS RESOLUTION PROTOCOL PARAMETERS"), and another called "hardware-addr", which reutrns the unadorned MAC address itself (i.e. what would be substring(hardware, 1, 1023) currently).

The hardware type would need to be packed into octet format, and one could implement RFC-3315's DUID-LL's as:

send dhcp-client-identifier concat(03, encode-int(hardware-type), hardware-addr);

instead.

Is it worth filing a bug to get these two functions implemented?

Thanks,

-Philip