Hi Tobias, I don't see any email about -12. Perhaps resubmit the update?
Ondrej -- Ondřej Surý (He/Him) [email protected] > On 22. 1. 2026, at 15:24, Tobias Fiebig <[email protected]> wrote: > > 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]
