Re: [dhcwg] unresolved comments in dhcpv6-25

[Ralph Droms <[e-mail]>]

Responses to your other comments:


   15. What if a client receives a reconfigure message but none of the
       configuration information was provided by the server (that sends
       the reconfigure)?  What if only a part of the configuration
       information was provided by the server?  Section 19.3.1 is not
       clear (enough) about the cases.

Are you asking what the client should do if the server's Reply message
doesn't include all the configuration information specified by the
client in the Request or Information-request message?

   16. (Relevant to the comment 12 above) Section 19.3.1 says

	the client
	ignores any additional Reconfigure messages (regardless
	of the transaction ID in the Reconfigure message) until
	the exchange is complete.  Subsequent Reconfigure messages
	(again independent of the transaction ID) cause the client
	to initiate a new exchange.

   But, according to Section 19.1.1, the transaction ID should always be
   0.  So I don't get the rationale about the wording here.  Does this
   simply mean the client should always ignore the transaction-ID?  If
   so, it seems to me more natural to say so explicitly.

You are correct; wording fixed.

   17. Section 21.5.2 says

      A DHCP message MUST NOT contain more than one Authentication option
      when using the delayed authentication protocol.

   Then, what if a received message contains more than one Authentication
   option?  Ignore the entire message, ignore the authentication options
   (but a particular one), or others?

Added text to section "Message Validation":

   Any DHCP message that includes more than one authentication option
   MUST be discarded.

   (an editorial comment) we need some additional white space in this
   paragraph:

      ...
      in the DHCP message to facilitate processing of the authentication
      information.The format of the Authentication...

   after "information".

Fixed (deleted sentence specifying placement of authentication
option).

   18. Section 21.5.3 says

      receiver computes the MAC as described in [9].  The entire DHCP
      message (except the MAC field of the authentication option itself),
      is used as input to the HMAC-MDS computation function.

   This is not very clear to me.  Does this mean we should regard the MAC
   field as an all-0 field when computation?

Text about MAC field in MAC computation has been clarified.

   19. We need a closing parenthesis in the first sentence of Section
       21.5.5.4:

      If the server has selected a key for the client in a previous message
      exchange (see section 21.5.6.1, the client MUST use the same key
      to generate the authentication information.

   The appropriate point should be after "21.5.6.1".

Fixed.

   20. Section 22.5 says

      An identity association for temporary addresses option MUST NOT
      appear in a Renew or Rebind message.

   What should the receiving node do if this condition is broken?

IA_TA now allowed in Renew or Rebind; DHCP allows lifetimes of
temporary addresses to be extended.

   21. Section 22.14 specifies to use a UTF-8 encoded text string, but it
       seems to me too much.  I think a simple ascii text is enough.
       (However, this may be based on a consensus of a former discussion,
       and if so, I don't oppose to the result.)

The DHC WG as settled on UTF-8 for text strings like this...

   22. Section 22.17 says

      A DHCP message MUST NOT contain more than one Vendor Class option.

   What should the receiving node do if this condition is broken?

   23. Section 22.18 says

      A DHCP message MUST NOT contain
      more than one Vendor-specific Information option with the same
      Enterprise Number.

   What should the receiving node do if this condition is broken?

(See below)

   24. Section 22.19 says

      This option MUST NOT
      appear in any message except a Relay-Forward or Relay-Reply message.

   What should the receiving node do if this condition is broken?  (This
   question should be extended in a general form; "what should the
   receiving node do if an option is included in a message in which the
   option MUST NOT be appeared?")

In general, the decision about how to proceed with messages that don't
adhere to the rules about option inclusion - for example, if the
message includes more than one Vendor-specific Information option with
the same Enterprise number - is a policy decision for the DHCP
server.


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg