Moin,

On Fri, 2025-08-08 at 08:20 -0700, Tommy Jensen wrote:
> Commentary in-line, minor nits on GitHub incoming.

GH nit addressed! Thanks.

> 
>  Always a fan of definition references, especially as I was reminded
> of this by the RFC Editor yesterday for a different draft.

Added, see mail to Nick.


> > >  > Section 3.2:
> > >  > - The draft suggests to use an MSS of 1240 bytes for IPv4 and
> > > 1220
> > >  > bytes 
> > >  >   for IPv6 to avoid MTU blackholes on TCP, but in the next
> > > paragraph 
> > >  >   also mentions the problems that may arise due to the use of
> > > NAT64. 
> > >  >   Why not always use an MSS of 1220 and be safe?
> > >  >   -> Same argument also applies to Section 4.1
> > >  
> > >  This kind of makes sense. I will change it in the working copy
> > > for now.
> > >  However, it would be nice to hear some more opinions on this
> > > from the
> > >  list.
>  I support this change also.

Thanks!

> > >  I would pick this up for only v6 for now; v4 is messy enough
> > > already...
> > >  
> > >  I put in: "Authoritative DNS servers <bcp14>SHOULD NOT</bcp14>
> > > use
> > >  addresses from IPv6 transition technologies to be reachable."
> > > for now.
> > 
>  I agree with the spirit of the change but find this sentence a
> little confusing. Noting I tend to prefer verbosity, I'd suggest but
> not insist on something like: "Authoritative DNS servers
> <bcp14>SHOULD</bcp14> use native IPv6 addresses instead of IPv6
> addresses synthesized using IPv6 transition technologies to avoid
> reachability issues."

I went for the (even more verbose):

"To avoid reachability issues, authoritative DNS servers
<bcp14>SHOULD</bcp14> use native IPv6 addresses instead of IPv6
addresses synthesized using IPv6 transition technologies for receiving
queries."

Thanks for the input; Will push a new rev soon.

With best regards,
Tobias

-- 
Dr.-Ing. Tobias Fiebig
T +31 616 80 98 99
M [email protected]
Pronouns: he/him/his

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to