Reviewer: Tatuya Jinmei Review result: Ready with Issues I am an assigned INT directorate reviewer for draft-ietf-opsawg-add-encrypted-dns-10.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, if I was on the IESG I would ballot this document as DISCUSS. I have the following (possible) DISCUSS/ABSTAIN level issue. The draft states in section 5: Should any encrypted DNS-related information (e.g., Authentication Domain Name (ADN), IPv6 address) change, [...]. The NAS replaces the old encrypted DNS resolver information with the new one and sends a DHCPv6 Reconfigure message which leads the DHCPv6 client to initiate a Renew/Reply message exchange with the DHCPv6 server. I suspect the use of Reconfigure is not always feasible. A Reconfigure message needs to be authenticated (per RFC8415), and the only available method for the authentication is the Reconfiguration Key Authentication Protocol. But this protocol is weak in that a shared secret first needs to be sent from the server to the client in plain text. It may be justifiable in the intended use case (between a CPE and NAS, and the communication path between them can be considered reasonably protected), but I believe such considerations should be described explicitly, either/both in this section or/add in Section 6. Now, I'm not sure if such an update operation is an integral part of this draft. If it's considered to be a minor case (e.g. the information is mostly static and periodic renew would suffice), or the matter of updates itself is mostly out of scope of this doc, then my comment on this point is also minor. On the other hand, if it's important to describe how such an update works with this RADIUS extension, then I'd regard it as a DISCUSS level issue. And, in the latter case, I believe DHCPv4-specific considerations on the same point should be included, too. The following are other (possible) issues I found with this document that may need be addressed before publication (I don't necessarily think these SHOULD be "corrected"): (All of these are about Section 3) - I wonder whether the two "may"s in this text need to be normative "MAY"s. RADIUS implementations may support a configuration parameter to control the DHCP options that can be included in a DHCP*-Options RADIUS attribute. Likewise, DHCP server implementations may support a configuration parameter to control the permitted DHCP options in a DHCP*-Options RADIUS attribute. - This "SHOULD" looks awkward to me. While it's a nice suggestion for implementers, it doesn't affect interoperability. I'd suggest making it a non-normative recommendation. For ease of administrator configuration, the RADIUS server SHOULD expose the DHCP options and allow administrators to configure them, instead of requiring them to be entered as opaque data. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
