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".