[dhcwg] Ketan Talaulikar's No Objection on draft-ietf-dhc-rf c8415bis-09: (with COMMENT)

Ketan Talaulikar has entered the following ballot position for
draft-ietf-dhc-rfc8415bis-09: 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/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/



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

Thanks to the authors and the WG for their work on this document for getting
DHCPv6 to Internet Standard.

I've focused on the changes from RFC8415. However, instead of looking at only
the diff between the two, I've looked at what other (non-technical) changes
that are required have been made. Since this document is going to specify an
Internet Standard, its bar should be higher. Please consider all of my comments
below with the spirit of making this document crisp and current with the
objective of helping a someone new implement DHCPv6 from scratch.

All the comments below have been provided inline in the idnits output of v09 of
the document. If you do not see the <EoRv09> at the end of the email, please
check the mailer archive since certain email clients are known to truncate
reviews.

17      Abstract

19         This document describes the Dynamic Host Configuration Protocol for
20         IPv6 (DHCPv6): an extensible mechanism for configuring nodes with

<minor> perhaps ... s/describes/specifies ?

274     1.1.  Relationship to Previous DHCPv6 Standards

276        The initial specification of DHCPv6 was defined in [RFC3315], and a
277        number of follow-up documents were published over the years:

<major> I see that this document is trying to carry forward history prior
to RFC8415 about DHCPv6 specifications. I find this concerning since it asks
the reader to go back to those old and obsoleted documents when reading this
brand new RFC. My concern is that it has the potential to at worst confuse and
at best waste time of someone trying to implement DHCPv6 afresh. Especially,
given that this is moving to Internet Standard, I would like to discuss if
there are any problems in removing all references to the obsoleted documents
other than RFC8415 itself.

The reader could be pointed to RFC8415 section 1.1 for history (just as done
for IA_TA).

311     1.2.  Relationship to DHCPv4

313        The operational models and relevant configuration information for
314        DHCPv4 [RFC2131] [RFC2132] and DHCPv6 are sufficiently different that
315        integration between the two services is not included in this
316        document.  [RFC3315] suggested that future work might be to extend
317        DHCPv6 to carry IPv4 address and configuration information.  However,
318        the current consensus of the IETF is that DHCPv4 should be used
319        rather than DHCPv6 when conveying IPv4 configuration information to

<major> The above text may be harmful to new implementations of DHCPv6. If the
WG has taken the decision to not use it for IPv4, then isn't now the
time to clarify this aspect before this moves to Internet Standard? If I were
implementing DHCPv6 currently, would I design and write code expecting that at
some point, my implementation would need to support IPv4 as well? Or, can
the spec provide definitive clarity to implementors on such aspects and not
carry forward these uncertainties?

324        Merging DHCPv4 and DHCPv6 configuration is out of scope for this
325        document.  [RFC4477] discusses some issues and possible strategies

<major> Is this important consideration not yet settled by the WG? If it is
then suggest clarifying. If it is not then does it impact maturity level to
move to Internet Standard?

326        for running DHCPv4 and DHCPv6 services together.  While [RFC4477] is
327        a bit dated, it provides a good overview of the issues at hand.

683        A DHCP client sends messages using a reserved, link-scoped multicast
684        destination address (ALL_DHCP_Relay_Agenda_and_service - ff02::1:2)

<minor> How about s/client sends messages/client sends all messages/ ... to
better express the change and its intent?

793     6.1.  Stateless DHCP

795        Stateless DHCP [RFC3736] can be used at any time, typically when a
796        node requires some missing or expired configuration information that
797        is available via DHCP.

<major> RFC8415 obsoleted RFC3736. This document obsoletes RFC8415. Why do we
still need to reference RFC3736 for this term. Perhaps we should have a forward
reference to section 6.1 of this document instead? Please see similar comments
for a few other references to obsoleted RFCs.

836     6.3.  DHCP for Prefix Delegation

838        The prefix delegation mechanism, originally described in [RFC3633],

<major> Isn't the reference to RFC3633 that has been obsoleted to the 2nd
degree avoidable?

948        A client that has delegated any of the address space received through
949        DHCP Prefix Delegation MUST NOT issue a DHCP Release on the relevant
950        delegated prefix while any of the address space is outstanding.
951        [RFC9096] section WPD-9 makes this Best Current Practice.  That

<minor> I didn't find a section WPD-9 in RFC9096. Is it section 3.1? If so,
please rephrase. If still using WPD-9, please expand that acronym.

1009    7.1.  Multicast Addresses

1011       [RFC3315] registered the following multicast addresses, and this
1012       specification is now authoritative for:

<major> The reference to RFC3315 is outdated and incorrect. The IANA registry
points to RFC8415. What does it mean "now authoritative for"? That was perhaps
appropriate for RFC8415, but seems very odd for this document.

1029    7.2.  UDP Ports

1031       Clients listen for DHCP messages on UDP port 546.  Servers and relay
1032       agents listen for DHCP messages on UDP port 547.

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

<major> Suggest rephrasing for clarity.

SUGGEST
           Clients listen for DHCP messages on UDP port 546.  Servers and relay
           agents listen for DHCP messages on UDP port 547. These designated
           destination ports MUST be used for sending DHCP messages (e.g.,
           clients sending to port 547).

           Clients, servers, and relay agents MAY send DHCP messages from any
           UDP (source) port they are allowed to use, including their designated
           destination ports.

1950       Clients, relay agents, and servers MUST NOT discard messages that
1951       contain unknown options (or instances of vendor options with unknown
1952       enterprise-number values).  These options should be ignored as if
1953       they were not present.  This is critical to provide for future
1954       extensions of DHCP.

<major> There was a text blob here in RFC8415 that used normative MUST to
discard certain unicast messages. That has been removed. Is that really
appropriate? Was this text wrong? I am not a DHCP expert, but this seems like
going beyond the stated desire to remove the Server Unicast Option?

1956       A client or server MUST discard any received DHCP messages with an
1957       unknown message type.

2316    18.1.  A Single Exchange for Multiple IA Options

2318       This document assumes that a client SHOULD use a single transaction
2319       for all of the IA options required on an interface; this simplifies
2320       the client implementation and reduces the potential number of
2321       transactions required (for the background on this design choice,
2322       refer to Section 4 of [RFC7550]).  To facilitate a client's use of a

<major> Isn't the reference to RFC7550 that has been obsoleted to the 2nd
degree avoidable?

3319       When a client receives a Reconfigure message from the server, the
3320       client initiates sending a Renew, Rebind, or Information-request
3321       message as indicated by msg-type in the Reconfigure Message option
3322       (see Section 21.19).  The server sends IAs and/or other configuration
3323       information to the client in a Reply message.  The server MAY include
3324       options containing the IAs and new values for other configuration
3325       parameters in the Reply message, even if those IAs and parameters
3326       were not requested in the client's message.

<major> Since the text blobs related to use of unicast in each of the
following sub-sections have been removed, perhaps we need something here to
indicate that the handling of unicast messages for all these messages is
covered in section 18.4 ?

3933    19.1.  Relaying a Client Message or a Relay-forward Message

3935       A relay agent relays both messages from clients and Relay-forward
3936       messages from other relay agents.  When a relay agent receives a
3937       Relay-forward message, a recognized message type for which it is not
3938       the intended target, or an unrecognized message type [RFC7283], it

<major> Isn't the reference to RFC7283 that has been obsoleted to the 2nd
degree avoidable?

4790    21.11.  Authentication Option

4792       The Authentication option carries authentication information to
4793       authenticate the identity and contents of DHCP messages.  The use of
4794       the Authentication option is described in Section 20.  The delayed
4795       authentication protocol, defined in [RFC3315], was obsoleted by
4796       [RFC8415].  The format of the Authentication option is:

<major> If this is something that was already obsoleted by RFC8415, why is it
even present in this document?

6092       [RFC8415]  Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
6093                  Richardson, M., Jiang, S., Lemon, T., and T. Winters,
6094                  "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
6095                  RFC 8415, DOI 10.17487/RFC8415, November 2018,
6096                  <https://www.rfc-editor.org/info/rfc8415>.

<major> RFC8415 should be an informative reference since it is being obsoleted
by this document.

6098    26.2.  Informative References

<EoRv09>



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