Hello Eric, as a follow-up, -12 addressing these points is now under submission. For some reason, though, the datatracker seems to not have delivered the submission-confirm message to my email account. So if someone can overwrite that and let -12 be published... would be greatly appreciated.
With best regards, Tobias On Thu, 2026-01-22 at 14:22 +0000, Eric Vyncke (evyncke) wrote: > Tobias, > > Working in the same time zone is so efficient 😉 > > Unsure whether you can submit a revised ID and whether I can review > it before the telechat 😉 but I am sure that in the coming days all > be cleared. > > Thanks for the work done! > > -éric > > From: Tobias Fiebig <[email protected]> > Date: Thursday, 22 January 2026 at 14:46 > To: Eric Vyncke (evyncke) <[email protected]>, The IESG > <[email protected]> > Cc: [email protected] <[email protected]>, > [email protected] <[email protected]>, > [email protected] <[email protected]> > , [email protected] <[email protected]> > Subject: Re: Éric Vyncke's Discuss on draft-ietf-dnsop-3901bis-11: > (with DISCUSS and COMMENT) > > Hello Eric, > > Thanks for the quick reply. Again, inline, with some filler text > removed. > > > > ### 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. > > Checking in with Med, we converged to rather have 9715 become > normative; He will file a downref. > > > > ### 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') > > The text now clarifies this (making explicit that the authoritative > NS > uses 1400/1232 as the maximum EDNS(0) size received, even if a query > has a higher EDNS(0) size set. > > > > `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" ? > > I can live with that. Changing. > > > > > > ### 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). > > Ah, makes sense. Adding that: > > -Every recursive DNS resolver <bcp14>SHOULD</bcp14> be dual-stack. > +To ensure robust DNS resolution even when facing namespace > fragmentation, every recursive DNS resolver <bcp14>SHOULD</bcp14> be > dual-stack. > +Exceptions apply if one of the below methods to prevent namespace > fragmentation are in place. > > > 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 -- 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 _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
