Hi Qin, all, Thank you for the comments.
For the second point, I agree the text is confusing. The procedure in the last sentence in the text you quoted refers to the DNR procedure that takes places in the LAN side. After thinking about this, I think we can just focus on what happens on the WAN side as this is sufficient to illustrate the usage. Also made other minor edits as you can see in this diff<https://www.ietf.org/rfcdiff?url1=draft-boucadair-opsawg-add-encrypted-dns&url2=https://raw.githubusercontent.com/boucadair/draft-boucadair-opsawg-add-encrypted-dns/master/draft-boucadair-opsawg-add-encrypted-dns.txt> to address your first point as well. Please let me know if any further change is needed. Thanks. Cheers, Med De : OPSAWG <[email protected]> De la part de Qin Wu EnvoyΓ© : jeudi 15 septembre 2022 15:39 Γ : Joe Clarke (jclarke) <[email protected]>; [email protected] Objet : Re: [OPSAWG] π CALL FOR ADOPTION: RADIUS Extensions for Encrypted DNS Med: I have read the latest version of draft-boucadair-opsawg-add-encrypted-dns and support adoption of this work with the following comments: 1. Section 1, paragraph 1said: β The information used to populate DHCP messages and/or IPv6 Router Advertisements relies upon specific Remote Authentication Dial-In User Service (RADIUS) [RFC2865] attributes, such as the DNS-Server-IPv6-Address Attribute specified in [RFC6911]. β Is relying on specific RADIUS attributes mandatory? Can we rely on other AAA message, e.g., Diameter message protocol to populate DHCP messages, no? 2. Section 1, paragraph 5 said: β The procedure defined in [I-D.ietf-add-dnr] is thus followed between the DHCPv6 client and the DHCPv6 server. The same procedure is followed between the DHCPv6 client on endpoints serviced by the CPE and the DHCPv6 server on CPE. β I am not clear which procedure in which section can be followed between DHCPv6 client and the DHCPv6 server. I thought when the DHCP message is sent back to the client, the task is done, and the client consume content extracted from DHCP rely message and Establish DNS session with DNS server, no? Also I am wondering why draft-boucadair-opsawg-add-encrypted-dns is not consolidated into [I-D.ietf-add-dnr] if the procedure described in this draft can work together with the procedure defined in [I-D.ietf-add-dnr]. Also I want to better understand the last sentence, i.e., βThe same procedure is followed between the DHCPv6 client on endpoints serviced by the CPE and the DHCPv6 server on CPE. β Do you mean the DHCPv6 client and DHCP server are hosted on the same CPE? No Would it be great to make them clear. Thanks for taking my comments into consideration. -Qin εδ»ΆδΊΊ: OPSAWG [mailto:[email protected]] 代葨 Joe Clarke (jclarke) ειζΆι΄: 2022εΉ΄9ζ14ζ₯ 22:28 ζΆδ»ΆδΊΊ: [email protected]<mailto:[email protected]> δΈ»ι’: [OPSAWG] π CALL FOR ADOPTION: RADIUS Extensions for Encrypted DNS Hello, WG. I like Henkβs subject icon. Makes for some attention-grabbing. This work has been discussed previously in opsawg, going back over a year. The authors have continued to progress the work and would like to gauge WG interest in adopting it. One might ask, why opsawg? The radext WG has been concluded, but, like IPFIX, there is interest in continuing to produce extensions for RADIUS. It was suggested by Benjamin Kaduk that opsawg was a potential fit for this work. Therefore, this kicks off a two-week CfA for https://datatracker.ietf.org/doc/draft-boucadair-opsawg-add-encrypted-dns/. Please comment on-list with support and/or discussion of the work. Thanks. Joe _________________________________________________________________________________________________________________________ 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.
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
