Re-, Thanks, Éric.
On 9715 point, I suggested to not soften the language around it as this would impact the clarity of the guidance. That one was move to normative. Thanks for flagging that. FWIW, the full changes can be seen here: https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-3901bis-11&url2=draft-ietf-dnsop-3901bis-12&difftype=--html Cheers, Med De : Eric Vyncke (evyncke) <[email protected]> Envoyé : jeudi 22 janvier 2026 14:23 À : [email protected]; The IESG <[email protected]> Cc : [email protected]; [email protected]; [email protected]; [email protected] Objet : Re: Éric Vyncke's Discuss on draft-ietf-dnsop-3901bis-11: (with DISCUSS and COMMENT) Hello Tobias, Thanks for your prompt reply. I am sure that we will converge and I will be happy to ballot a supporting YES 😉 (once the revised I-D is submitted). See below for EV> (for the open points, all others are OK) Regards -éric From: Tobias Fiebig <[email protected]<mailto:[email protected]>> Date: Thursday, 22 January 2026 at 09:43 To: Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>>, The IESG <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: Re: Éric Vyncke's Discuss on draft-ietf-dnsop-3901bis-11: (with DISCUSS and COMMENT) Hello Éric, thank you for your review. Please find my responses inline. I will try to get the PR(s) for this in ASAP. > --------------------------------------------------------------------- > - > DISCUSS: > --------------------------------------------------------------------- > - > > > # Éric Vyncke INT AD comments for draft-ietf-dnsop-3901bis-11 > > CC @evyncke > > Thank you for the work put into this document. Let's polish this > draft to make > it very useful as it should be. > > Please note as well that I am still on sick leave, i.e., I may not > have read > all the multiple recent threads about this I-D. > > Please find below some blocking DISCUSS points (some trivial to > address), some > non-blocking COMMENT points/nits (replies would be appreciated even > if only for > my own education). > > Special thanks to Ondřej Surý for the shepherd's detailed write-up > including > the WG consensus *and* the justification of the intended status. > > I also note that there have been several cross-posting with the V6OPS > mailing > list by the responsible AD and the authors. These were a good and > sensible > actions. > > I hope that this review helps to improve the document, > > Regards, > > -éric > > Note: this ballot comments follow the Markdown syntax of > https://github.com/mnot/ietf-comments/tree/main, i.e., they can be > processed by > a tool to create github issues. > > ## DISCUSS (blocking) > > As noted in > https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/ > , > a DISCUSS ballot is a request to have a discussion on the points > below; I > really think that the document would be improved with a change here, > but can be > convinced otherwise. > > ### Title > > As the document is about mixed IPv4/IPv6 environments, then the title > is > incorrect as it only mention IPv6. Suggest using "Operational > Guidelines for > DNS UDP/TCP Transport in Mixed IPv4/IPv6 Environment" or something > similar. The title so far build on the title used in 3901. I think there are no strong feelings about this, and would be happy to change it to your suggestion. > ### Section 2 > > RFC 5375 must be a normative reference even if it is itself an > informational RFC. This will be changed. > I am also puzzled by the focus on GUA and ignoring ULA while there > are nearly no words about RFC 1918 addresses. While there are some > words in section 3.2 about RFC 1918, there are none about ULA. We will add text on ULA as well. > ### Section 3.2 > > `DNS servers SHOULD follow [RFC9715]` this makes RFC 9715 a normative > reference (and create a downref). This combination is used in multiple places. I think this can either be resolved by removing the BCP14 language dependence on 9715, or by accepting the downref. For the first option, I would reformulate the text as follows: "DNS servers SHOULD avoid packet fragmentation. Examples on how to do this for UDP transports can be found in [RFC9715]." What are your thoughts on this? EV> The above text is addressing one instance, unsure whether it could be done in all instances though. > ### Section 4.1 > > `To avoid reachability issues, authoritative DNS servers SHOULD NOT > use > IPv4-embedded addresses` is really looking for trouble, please use > "MUST NOT". > (this is basically the "Widespread deployment would be damaging to > the > Internet" point in the IESG DISCUSS criteria list). > > Same issue about `Both IPv4 and IPv6 transports SHOULD serve > identical DNS > data` else this is a recipe for big troubles. Happy to change this to MUST/MUST NOT > > --------------------------------------------------------------------- > - > COMMENT: > --------------------------------------------------------------------- > - > > > ## COMMENTS (non-blocking) > > ### Load balancing & DNS > > Should there be some text about CDN selecting the 'closest' server by > serving different RR based on the resolver IP ? Does it have any > impact on this document? I don't think that this is relevant here, as the document does not talk about global RRset consistency, and as long as the NS RRsets comply with the document, it does not matter if there are different v4/v6 reachable NS dpeending on region. EV> fair enough > ### Abstract and section 2 > > Unsure what is a `native IPv6 address`, suggest using 'plain IPv6 > address' at least in the abstract or simply "global unicast address". Will change this to GUA. > ### Section 3.1 > > `The following name-related misconfigurations` is this an exhaustive > list ? > > Strongly suggest to add a text similar to RFC 9471 `At the time of > this writing, addresses (A or AAAA records) for a delegation's > authoritative name servers are the only type of glue defined for the > DNS.` when discussing glue records as I hope that DELEG will produce > another, related, delegation system. Thanks, this is a very useful suggestion which we did not think of. Will integrate this. > ### Section 3.2 > > `DNS servers SHOULD follow [RFC9715]`, per > https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ > , > especially in a BCP, when can the SHOULD be bypassed ? Why not a MUST > ? The cause here is the nature of RFC9715 as informational. See also my suggestions on re-wording above to remove the 9715 dependence, and making it a clear option example. EV> the use of SHOULD must come with consequences or when to bypass it though. > There is also a contradiction between `DNS servers SHOULD follow > [RFC9715]` and `This can be accomplished by setting a corresponding > EDNS(0) size` as the EDNS(0) is set by the resolver AFAIK. Yes, this needs to be clarified; What should happen is that the authoritative NS should cap received EDNS0 sizes, i.e., always act as if a maximum of 1400/1232 was received. EV> clarifications would be welcome (like MSS 'clamping') > `Hence, DNS servers MAY set an MSS of no more than 1388 octets for > TCP connections.` why not something stronger than a MAY ? Should > there be guidance as well for the resolvers ? This is a MAY, because there were various strong opinions on the ideal MSS (see also 9715 with 1400 vs. 1280). EV> what about using "IS RECOMMENDED" ? > s/Guidance in this *document* focuses on IP address family > support/Guidance in this *section* focuses on IP address family > support/ ? This sounds reasonable, but i have to go through the text again. > ### Section 4.1 > > As noted before, please explain when the SHOULD can be bypassed or > what are the consequences of bypassing it. Will add a sentence clarifying this; Essentially, the implication is reduced reachability / namespace fragmentation. > While the main part of the section recommends 2 name server per > address family, the final list only mentions 1. Is it on purpose ? > Again a 'dangling' SHOULD. This is a remnant from earlier editing. Numbers will be adjusted. EV> thanks > ### Section 4.2 > > This SHOULD has the companion statements: `Every recursive DNS > resolver SHOULD be dual-stack` :-) I cannot parse this comment. Could you maybe clarify what you mean with this? EV> every SHOULD must have some text about either what are the consequences if not followed or when it can be bypassed (especially in a BCP). > ### Section 5 > > Unsure whether the text about PREF64 is relevant in this section or > even in this document. This was very explicitly requested during WG discussions given text related to Recursive NS discovery in Section 4. EV> still puzzled, but this is OK With best regards, Tobias -- My working day may not be your working day. Please do not feel obliged to reply to my email outside of your normal working hours. ----------------------------------------------------------------- Tobias Fiebig, Forschungsgruppe Internet Architecture (INET) Max-Planck-Institut für Informatik, Campus E14, 66123 Saarbrücken E1 4 - Raum 517 mobil: +31 616 80 98 99 ____________________________________________________________________________________________________________ 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.
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
