comments on draft-ietf-ipoib-dhcp-over-infiniband-10.txt

I just became aware of this draft, so please forgive the
late response.

--Barr


Section 2.1, "IPoIB specific usage of DHCP message fields"

    "htype" (hardware address type) MUST be 32 [ARPPARAM]
    --  a better reference for the hardware address type
	  would be
	  http://www.iana.org/assignments/arp-parameters

    "hlen" (hardware address length) MUST be 0.
    --  I strongly disagree:  just because the hardware
        address does not fit in the 'chaddr' field is not a
        good reason to put the "wrong" value in	the length
        field.

    "chaddr" (client hardware address) field MUST be zeroed.
    --  While I understand that the IP over InfiniBand
        Architecture document specifies that a link-layer
        address is composed to 4 octets of Queue Pair Number
        and 16 octets of Global Identifier, is there any
        value (read: makes the operation of relay agents or
        other networking components easier or simpler) to
        inserting the 16-octet GID as the 'chaddr?'  My
        concern is that some devices might treat 0 as an
        invalid value for 'chaddr.'
    --  Of course, if the GID were used for 'chaddr' then
        the value of 'hlen' should be 16, which conflicts
        with my statement above.  I've no simple solution to
        that conundrum.

    "client-identifier" option MUST be used in DHCP
    messages.
    --  while this is probably the only choice for
        identifying a client uniquely, there are a few
        issues with it:
        (a) host system processes using	DHCPINFORM messages
            to request additional parameters do not use the
            client identifier option at all.
        (b) some DHCPv4 servers may be configured to ignore
            the client identifier option.
        (c) many DHCPv4 servers use the 'htype' and 'chaddr'
            fields exclusively, ignoring the client
            identifier option, when assigning fixed IP
            addresses to "known" or "registered" clients

    The "client-identifier" used in DHCP messages MUST
conform to
    [DHC_3315id].
    --  this reference should be updated to RFC 4361.
    --  despite the text in section 6.5 of RFC 4361, a
        DHCPv4 server should not expect that all client
        identifiers received from clients will conform to
        RFC 4361.  As a result, the client identifier SHOULD
        continue to be treated by a DHCPv4 server as an
        opaque value.

Section 2.2, "Use of the BROADCAST flag"

    A DHCP client on IPoIB MUST set the BROADCAST flag in
DHCPDISCOVER
    and DHCPREQUEST messages (and set "ciaddr" to zero) to
ensure that
    the server (or the relay agent) broadcasts its reply to
the client.
    -- This is not quite correct.  The client SHOULD set the
BROADCAST
       flag in DHCPDISCOVER and DHCPREQUEST messages sent
from the INIT
       or SELECTING states if it cannot receive unicast
messages before
       being configured with an IP address.
    -- Clients restarting with a previously assigned IP
address enter
       the INIT-REBOOT state and while RFC 2131 specifies
that they
       broadcast DHCPREQUEST to the local broadcast address,
they
       SHOULD NOT set the BROADCAST flag:  if the server
verifies that
       the requested IP address had been previously assigned
to the
       client and there is time remaining before the lease
expires,
       then the DHCPACK message may be unicast to the client
IP address.