Hey Florian,
Thank you for the feedback, and thank you for sharing your draft. My main
concern with your -00 is the introduction of yet another mechanism for
discovering the prefix:
The DNS resolver MAY return an IPv6 prefix or a comma separated
list of prefixes to indicate not just that DNS64 is being
performed but also to let the client know which prefix or prefixes
are in use. The prefixes MUST be represented using the canonical
representation format of [RFC5952].
Please do not give implementors the temptation. We do not need another
discovery mechanism and the conflict resolution guidance that would require.
Thanks,
Tommy
> -----Original Message-----
> From: Florian Obser <florian+i...@narrans.de>
> Sent: Monday, October 21, 2024 7:43 AM
> To: Nick Buraglio <burag...@forwardingplane.net>
> Cc: dnsop@ietf.org; Jen Linkova <furr...@gmail.com>; Tommy Jensen
> <jensen.tho...@microsoft.com>
> Subject: [EXTERNAL] Re: [DNSOP] New draft regarding RFC7050
>
> On 2024-09-09 17:51 -05, Nick Buraglio <burag...@forwardingplane.net> wrote:
> > dnsop folks,
> >
> > Based on some conversations and discussions at the end of the second
> > session at 120, several of us worked out a draft to address what we
> > believe are some notable details in RFC7050. This draft was just
> > submitted to the datatracker, and we would appreciate any input,
> > comments, corrections, and productive discussion from the expertise of
> > the group. The draft can be read at
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> > tracker.ietf.org%2Fdoc%2Fdraft-buraglio-deprecate7050%2F&data=05%7C02%
> >
> 7CJensen.Thomas%40microsoft.com%7Cd8fc7fd951164c6fef2108dcf1dea66d%7
> C7
> >
> 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638651185889707957%7CU
> nknown
> >
> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> CJ
> >
> XVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Z0wnaQB6DepNHsEOTTQoEwKDSSaVp
> V%2BmixKSZ
> > e2dnFE%3D&reserved=0
> >
> > Thanks in advance, we look forward to anything the list is willing to
> > provide.
>
> I think this plain needs killing, RFC8781 is so much better.
>
> It occurred to me that a validating stub resolver still needs to know if its
> upstream
> is messing with DNS. With RFC9606 we can just ask the resolver what it's
> doing,
> so I put up
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack
> er.ietf.org%2Fdoc%2Fdraft-fobser-resinfo-
> dns64%2F&data=05%7C02%7CJensen.Thomas%40microsoft.com%7Cd8fc7fd951
> 164c6fef2108dcf1dea66d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
> 7C638651185889729988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdat
> a=RzAZTujnuR79y7vYjzkJSFdUidrcq1YqJZszZbW5TOI%3D&reserved=0
>
> A validating stub can then avoid that resolver or do more fancy things like
> spotting
> that the resolver did DNS64 synthesis, ignore that answer and do its own
> synthesis using the 8781 prefix...
>
> >
> > Thanks!
> >
> > nb
> > _______________________________________________
> > DNSOP mailing list -- dnsop@ietf.org
> > To unsubscribe send an email to dnsop-le...@ietf.org
> >
>
> --
> In my defence, I have been left unsupervised.
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
