On Thu, Mar 9, 2023 at 10:23 PM <mohamed.boucadair@xxxxxxxxxx> wrote: > [Med] What is actually more important in this para is the part in > [...]. That text is there to provide an example of when the > attributes can be present in CoA-Request. I have no problem with that part, and I didn't mean it's less important than the use of DHCPv6 Reconfigure by omitting that part. > [Med] These considerations are specific to the dhcp options that > will be carried in the RADIUS attribute. The security considerations > (including issues with the use of reconfigure) fall under this part: >> Security considerations specific to the DHCP options that are carried >> in RADIUS are discussed in relevant documents that specify these >> options. Do you specifically mean draft-ietf-add-dnr-13? I first expected that while reviewing draft-ietf-opsawg-add-encrypted-dns and checked it, but it didn't discuss anything about DHCPv6 Reconfigure. That's one reason why I raised the point in my review. >From your response, I'd suggest: - Describe the DHCP part of reconfigure operation in more detail in draft-ietf-add-dnr (including whether to use Reconfigure message in the first place), and/or - Remove the reference to DHCPv6 reconfigure from opsawg-add-encrypted-dns and just say something like "How the DHCPv6 server uses the new encrypted DNS resolver information is out of scope of this document." > [Med] I also hesitated, but MAY is not used here as this does not > impact interop. I had to reread Sections 5/6 of RFC2119 regularly > for may/MAY. I don't object here. > [Med] The use of normative language is justified here because we > don't want the RADIUS servers to blindly pass data. What this text > says is that the attributes should not be seen as opaque data by the > RADIUS server but it should understand the encoding of the enclosed > options. Hmm, I didn't read it that way. If that's the intent (and if I understand it correctly), "For ease of administrator configuration" especially sounds awkward, since it seems to say the purpose of this requirement is better UX. Again, assuming I understand the intent correctly, I'd suggest something like this: The RADIUS server SHOULD reject a configuration attempt of including a DHCP option in a DHCP*-Options RADIUS attribute if the server does not understand that DHCP option and its format. -- jinmei -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
