Mohamed, Exactly, and I think there are concerns raised against “successful operational experience”. And of course the IETF does not reclassify any or all documents just because they fulfil the criteria.
Ole > On 10 Apr 2026, at 06:07, [email protected] wrote: > > Hi all, > > Brian clarified the point, but I'd like to remind the exact criteria required > by this process: > > The request for reclassification is sent to the IESG along with an > explanation of how the criteria have been met. The criteria are: > > (1) There are at least two independent interoperating implementations > with widespread deployment and successful operational experience. > > (2) There are no errata against the specification that would cause a > new implementation to fail to interoperate with deployed ones. > > (3) There are no unused features in the specification that greatly > increase implementation complexity. > > (4) If the technology required to implement the specification > requires patented or otherwise controlled technology, then the > set of implementations must demonstrate at least two independent, > separate and successful uses of the licensing process. > > Cheers, > Med > >> -----Message d'origine----- >> De : Brian E Carpenter <[email protected]> >> Envoyé : jeudi 9 avril 2026 22:21 >> À : Paul Vixie <[email protected]>; [email protected] >> Cc : IPv6 Operations <[email protected]>; Philip Homburg <pch-dnsop- >> [email protected]> >> Objet : [DNSOP] Re: [v6ops] Re: Re: Moving DNS64 (RFC6147) to >> Internet Standard >> >> >> On 10-Apr-26 07:17, Paul Vixie wrote: >>> On Thursday, April 9, 2026 12:12:12 PM PDT Philip Homburg wrote: >>> >>>>> ... >>> >>>> >>> >>>> In my opinion we should strongly discourage deploying DNS64. >> So >>> moving >>> >>>> DNS64 to Internet Standard sends completely the wrong >> message. >> >> I'm very torn on that, because like it or not DNS64 is stable, >> well-defined, and widely implemented. (I'd also prefer to abolish >> the problem by abolishing the distinction between Proposed >> Standard and Internet Standard, but that's another story.) >> >>> >>> so, i agree, but: >>> >>>> DNS64 is incompatible with local DNSSEC validation. This >> combines >>> the > worst of both worlds: something doesn't work both because >> of >>> DNSSEC and > IPv6. >>>> >>>> New deployments of NAT64 should either use some kind of >> address >>> synthesis > in a library or deploy a CLAT. >> >> I don't think there's much disagreement with that. >> >>> we should not need new deployments of v6/v4 transition >> technology almost 20 years after june 6 2006, and it's time for >> the IETF to occupy that position. >> >> But we still do need co-existence for very practical reasons. >> That's why v6ops is developing the IPv6-mostly approach in draft- >> ietf-v6ops-6mops, which explicitly says: >> "Those concerns make DNS64 a suboptimal and undesirable solution >> long-term. >> To eliminate the needs for DNS64..." etc. >> >> So we might end up with DNS64 completely meeting the requirements >> for Internet Standard status and being operationally deprecated. >> Yes, it's a paradox. >> >> Brian >> >> _______________________________________________ >> 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] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
