[dhcwg] Eric Rescorla's No Objection on draft-ietf-dhc-rfc3315bis-10: (with COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-dhc-rfc3315bis-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-rfc3315bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Document: draft-ietf-dhc-rfc3315bis-10.txt

This document was quite clear and well written. A few small comments
below.

It would have been easier for me to have a bit of intro about why
both the 4-message and 2-message rapid commit exchanges exist
and maybe some guidance about when to use each one.

I am finding the guidance on DUIDs a bit confusing. Rather than
having a bunch of constructions that produce variable length
things that are intended to be unique, why not just take all
those values and feed them into a hash function and then you
could just have UUIDs?

I'm a little sad that the transaction ID is so short. This doesn't
seem like really enough to provide uniqueness against guessing
attacks.

We're trying to discourage HMAC-MD5. Do you have any way to
transition to something stronger?

The description of how to actually do replay detection seems pretty
thin. Do you think more detail would be helpful here.


Editorial:


S 1.
   DHCPv6 can also provide only other configuration options (i.e., no
   addresses or prefixes).  That implies that the server does not have

Perhaps "DHCP can also be used just to provide..."


S 2.
Nit: do you want to cite 8174.


S 4.2.
When acronyms are used ahead of their definition, it would be good to
expand them.


S 21.22.
What is the part of the IPv6-prefix after prefix-length filled with?
Does it matter?