Re: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt

[Matthew Ryan <[e-mail]>]

First, a couple of typos:
Section 3.1.3, 4th paragraph:
   easily be predicted.  The nonce is imbedded as a 128-bit value of the
'imbedded' should be 'embedded', or 'included'

Section 3.1.4, 2nd paragraph:
   A DHCP server has indicates its support through the inclusion of the
remove the 'has'.


I think some clarifications are needed on renew behavior, and
server support advertisement.

Section 3.1.4 states:
  The client will receive a Forcerenew Nonce from the server in the
  initial DHCP Ack message from the server.
which could be construed to imply that the nonce is only chosen
during the initial 4-way handshake.

However, the protocol interaction diagram in section 3.1.1
seems to indicate that, during a renew, the server may/must
(unclear) create a new nonce.

I believe it needs to be clarified whether the server should/must
generate a new nonce on each renew, and whether the client must
accept a new nonce on each renew.

In addition, sections 3.1.3 (server considerations) and 3.1.4
(client considerations) seem to state different things as to
how a server advertises its support for forcerenew-nonce.  Both
sections mention that the server indicates support by including
the FORCERENEW_NONCE_CAPABLE option in OFFERs, but 3.1.4 also
mentions that the server MUST include a forcerenew-nonce
authentication option with type set to zero.  It seems to me
that if a server MUST emit both the FORCERENEW_NONCE_CAPABLE
option and the authentication option, it should explicitly
state so in the server considerations section (3.1.3).  Also,
since 3.1.3 states that the server chooses a nonce only in
response to a REQUEST, what should the value in the OFFER be?

However, I'm not sure I see the need for a server to return
BOTH the FORCERENEW_NONCE_CAPABLE option, and the authentication
type 0 in the OFFER, in order to advertise that it is capable
of forcerenew-nonce.

- Matt