Hi Tobias/Erik, Seems that you both converged that editing an I-D is more appropriate here.
@Tobias, can you please review the changes proposed by Erik in the other thread: https://mailarchive.ietf.org/arch/msg/dnsop/9uyXVO_mWhOB76TdRyRq8LlQsNA/? Thanks. Cheers, Med > -----Message d'origine----- > De : Tobias Fiebig <[email protected]> > Envoyé : dimanche 17 mai 2026 11:29 > À : Erik Nygren <[email protected]> > Cc : dnsop WG <[email protected]>; [email protected] list > <[email protected]>; Gorry Fairhurst <[email protected]>; draft- > [email protected]; Ondřej Surý <[email protected]> > Objet : [DNSOP] Re: libc 3 resolver limitation and draft-ietf- > dnsop-3901bis (was Gorry Fairhurst's No Objection on draft-ietf- > dnsop-3901bis-15: (with COMMENT)) > > > Moin, > > 1) The one mentioned in the draft where only a subset of > resolvers > > have the ability to resolve for each address family. This is > > certainly a problem of its own -- I wonder how well various stub > > resolvers deal with this? Having different partial connectivity > from > > different stub resolvers but configured as the same may confuse > some > > of the stub resolvers and will cause performance issues. I'm > > unconvinced that having a subset of them dual-stacked is good > enough > > to avoid problems, as many stubs aren't good with handling cases > where > > their recursive resolvers have partial functionality. > > This should be something that can be relatively exhaustively > measured with a bunch of implementations. Sounds like an ideal > student project to me. I will try to keep that in mind when an > opportunity comes by. > > > 2) The one I'm raising where it is important to make sure the > client > > receives at least one recursive resolver its stub resolver or > stub > > library can reach is separate/distinct. This isn't covered in > the > > current draft, but I agree that it is messy enough that it is > likely > > hard to cover with just a small update here. (I'm actually not > sure > > there is a heuristic that always works.) > > I think this should start out with an informational draft > outlining the problem; This will likely get some of the messy-ness > out, and might lead to a good recommendation. Let me mark this > thread as 'unread', so i remember to setup a skeleton structure > for an I-D. > > With best regards, > Tobias > > -- > Univ.Prof. Dr.-Ing. Tobias Fiebig > T +31 616 80 98 99 > M [email protected] > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] ____________________________________________________________________________________________________________ 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]
