[dhcwg] Mohamed Boucadair's Discuss on draft-ietf-dhc-rfc841 5bis-09: (with DISCUSS and COMMENT)

Mohamed Boucadair has entered the following ballot position for
draft-ietf-dhc-rfc8415bis-09: Discuss

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi Tomek, Bernie, Michael, Sheng, and Tim,

Thank you for the effort put into this important piece of work. I will be
definitely balloting "YES".

Thanks to Tim Chown for his outstanding OPSDIR review. I appreciate that the
authors already engaged to address the review. I hear the arguments made by the
authors for the proposal to cite some recent specs. I'm monitoring that
discussion and hope the right balance will be found given the intended IS
status.

Till then, I borrow the main issue from Tom as a DICUSS point. I added an
additional easy-to-fix DISCUSS point based on a review of the diff vs 8415.

# Consistency (raised by Tim)

"
I think there’s two main areas of concern.

One is the use of MUST in some places and not in others, for the same context,
e.g., “the client MUST insert foo” vs “the client inserts foo”. That happens
inconsistently e.g. in Section 18.

The other is the inconsistency in what’s said in Sections 16 and 18. I’d
suggest someone (an author) goes through them both and checks in detail.  One
way to simplify it would be to just remove section 16, much like the last
Appendix where there might (but I didn’t check) also be inconsistencies.  But
that validation information being spelled out from the spec in Section 18 is
useful.

It’s also clear that the spec has evolved over time so the document has a
somewhat “patchwork” feel to it.  The way Reconfigure authentication is
introduced (or rather isn’t) and then very ambiguous up until it’s spelled out
in Section 18 is a good example.  So it depends if you, or the IESG, care about
that.

The other points in my review I made because they seemed odd to me, or
confusing.  If you’ve been working to that spec since it was 3315 I suspect you
wouldn’t feel that way. "

# RFC8415 is not normative

Please move RFC8415 to be listed as Informative. That one will be obsoleted.


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

# Section 1

OLD:
   DHCPv6 also provides a mechanism for automated delegation of IPv6
   prefixes using DHCPv6.

NEW:
   DHCPv6 also supports a mechanism for automated delegation of IPv6
   prefixes.

# Section 4.2

OLD:
   IA_TA                     Identity Association for Temporary
                             Addresses: an IA that carries temporary
                             addresses (see [RFC8981]).  This option is
                             obsolete.

NEW:
   IA_TA                     Identity Association for Temporary
                             Addresses: an IA that carries temporary
                             addresses (see [RFC8981]). This option is
                             obsoleted by this document.

# Section 7.2

CURRENT:
   Clients, servers, and relay agents MAY send DHCP messages from any
   UDP (source) port they are allowed to use, including their designated
   destination ports.  Nevertheless, regardless of the source port used,
   DHCP messages MUST be sent to ports specified above (e.g., clients
   sending to port 547).

What is meant by "designated destination ports"? What is a "designated
destination port" for a server?

Please reword.

The same wording is used in other parts of the spec. Please update those as
well. Thanks.

# Section 21.5

OLD:
   The Identity Association for Temporary Addresses (IA_TA) option is
   obsolete.

NEW:
   The Identity Association for Temporary Addresses (IA_TA) option is
   obsoleted.

# Section 21.7

CURRENT:
   A client MUST include an Option Request option in a Solicit, Request,
   Renew, Rebind, or Information-request message to inform the server
   about options the client wants the server to send to the client.  For
   certain message types, some option codes MUST be included in the
   Option Request option; see [IANA-OPTION-DETAILS] for details.

Glad to see that the table was replaced with the pointer to the IANA registry.
Can we add a sentence to say that registry is the authoritative reference for
the up-to-date options?

# Section 22: Implementation Status

If this is not done yet, please consider having the implem details in a public
page (wiki) and add the link as "related_implementations" under "Additional
resources" in the datatracker.



_______________________________________________
dhcwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]