| Thanks Jinmei.
- Bernie (from iPad) On May 5, 2025, at 8:05 PM, Tatuya Jinmei via Datatracker <noreply@xxxxxxxx> 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".
|
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
