Hi Tatuya, Thank you for the feedback. Please see inline. Cheers, Med > -----Message d'origine----- > De : JINMEI Tatuya / 神明達哉 <jinmei@xxxxxxxxxx> > Envoyé : lundi 13 mars 2023 20:46 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx> > Cc : int-dir@xxxxxxxx; draft-ietf-opsawg-add-encrypted- > dns.all@xxxxxxxx; last-call@xxxxxxxx; opsawg@xxxxxxxx > Objet : Re: [dhcwg] Intdir telechat review of draft-ietf-opsawg- > add-encrypted-dns-10 > > > [Med] OK. Added a reminder of where to find dhcp-related > security > > issues with a specific RFC for reconfigured-specific issues > (RFC6977). > > RFC6977 is specific to reconfiguration with relay agents., and > just provides generic discussions. [Med] The base specs + 6977 provides good pointers for security considerations that are relevant to DHCP-triggered reconfiguration upon receipt of CoA. Both considerations at the servers/relays are covered in these specs. If you have better informative pointers, please share them. Thanks. What I expected in this draft > in this context is how such discussions can apply to this specific > usage of Section 5. [Med] Section 5 illustrates how CoA-requests can be used to carry the new attributes and how a change of the configuration is propagated till the requesting client. Security considerations on the server/relay--dhcp clients are those that are discussed in the generic documents + specific dhcp options. Hence, the current wording in the Sec Sections. I'm fine with deferring such a discussion to > draft-ietf-add-dnr; I'm also fine with just removing any reference > to Reconfigure from this draft (and maybe stating that's an out- > of-scope topic). [Med] I don't understand this position as what we are discussing here is ** an example ** (not a reco or a new feature) to illustrate the use of the attributes with CoA. That example wouldn’t be complete if the DHCP leg is not exemplified as well. Issues with reconfigure are well-known and adequate references for readers who want to learn more are now provided in the document. But the added reference to RFC6977 doesn't > address my point. > > > [Med] Thanks. We went with a more elaborated version to better > explain > > the intent and call out the constraints: > > Thank you for the update. It looks good to me. > [Med] Great. > -- > jinmei _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
