[dhcwg] Re: draft-ietf-dhc-rfc8415bis-09 telechat Intdir rev iew

Thanks Jinmei.

I just created some issues to track these comments in github. See https://github.com/dhcwg/rfc8415bis/issues.

- Bernie (from iPad)

> On May 5, 2025, at 8:05 PM, Tatuya Jinmei via Datatracker <[email protected]> wrote:
> 
> Document: draft-ietf-dhc-rfc8415bis
> Title: Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
> Reviewer: Tatuya Jinmei
> Review result: Ready
> 
> I am an assigned INT directorate reviewer for
> <draft-ietf-dhc-rfc8415bis-09.txt>. These comments were written primarily for
> the benefit of the Internet Area Directors. Document editors and shepherd(s)
> should treat these comments just like they would treat comments from any other
> IETF contributors and resolve them along with any other Last Call comments that
> have been received. For more details on the INT Directorate, see
> https://datatracker.ietf.org/group/intdir/about/.
> 
> Based on my review, the document is ready for publication.
> 
> While the entire document is very large, the actual changes from RFC8415 are
> small as listed in Appendix A. I primarily focused on those changes, and these
> (in particular, deprecating IA_TA and the server unicast feature) are
> reasonable.
> 
> I've noticed a few minor comments while reading the entire draft (which are
> actually not specific to this bis version). The authors may or may not want to
> address them.
> 
> - 18.2.2
>   *  Initiate the server discovery process described in Section 18.
> 
> I'm not sure if "Section 18" is an appropriate reference to "server discovery
> process". I've checked RFC3315, and found that it referred to "section 17",
> whose title is "DHCP Server Solicitation". Maybe a better equivalent of this in
> this draft is Section 18.2.1?
> 
> Section 18.2.10.3 has the same issue in its reference to "Section 18". (And
> there may be some more).
> 
> - 18.2.4
>   A client MUST also initiate a Renew/Reply message exchange before
>   time T1 if the client's link-local address used in previous
>   interactions with the server is no longer valid and it is willing to
>   receive Reconfigure messages.
> 
> It's not very clear to me why link-local address is specifically mentioned
> here. Perhaps it's because the client could receive a Reconfigure message to
> that link-local address. But, if so, doesn't a non link-local address have the
> same issue (even if it would be rare to use a non LL address for DHCP message
> exchanges to/from a client)? Perhaps we should say something like "if the
> client's address used as the destination address in previous messages from the
> server is no longer valid"?
> 
> - 18.2.5
>   The message exchange is terminated when the valid lifetimes of all
>   leases across all IAs have expired, at which time the client uses the
>   Solicit message to locate a new DHCP server and sends a Request for
>   the expired IAs to the new server.  If the terminated Rebind exchange
>   was initiated as a result of receiving a Reconfigure message, the
>   client ignores and discards the Reconfigure message.
> 
> I don't understand the second sentence: what's "the" Reconfigure message? If it
> the one that triggered REBIND, it was already processed, so "ignores and
> discard" don't make sense. Perhaps it should be similar to 18.2.4, which states
> "ignores and discards any additional Reconfigure messages it may receive"?
> 
> - 18.3.10
>   If the original message was received directly by the server, the
>   server unicasts the Advertise or Reply message directly to the client
>   using the address in the source address field from the IP datagram in
>   which the original message was received.  The Advertise or Reply
>   message MUST be unicast through the interface on which the original
>   message was received.
> 
> This may be pedantic, but I think limiting the outgoing interface is too
> strict. I guess the intent is to ensure that the Reply is sent back to the link
> to which ALL_DHCP_Relay_Agenda_and_service belongs (which makes sense). Since
> Section 17 seems to be aware of the case where two interfaces belong to the
> same link, I think we can also be flexible here, e.g., replacing "interface"
> with "link".
> 
> 
>

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