On Kerberos, we need to note that one use case of Kerberos is Microsoft Active Directory; MS AD is behind a number of name collisions that happened in the 2012 root zone expansion, including one string that will likely never show the light of day in the root (.corp). So, this might be the telltale sign, not the good fortune ahead one.
We also could think into this in terms of what we can do; .alt, .arpa and .internal all look feasible and could alleviate potential collisions(.arpa already succeeded in .home.arpa). Will blockchain start-ups adopt them ? Likely not, because they just want the end run around ICANN and couldn't care less about interoperability. But by providing those that do care with options, we get more friends and less foes. Rubens > On 13 Aug 2022, at 23:27, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > Signed PGP part > > So I think this discussion might benefit from also > remembering that we have a decades-long and widely > deployed history of IETF standard name forms that > use the same name syntax as domain names that may > or may not be related to names used in the DNS. > > Kerberos [1] does exactly that. > > And the sky never fell, nor has anyone had to pay > large numbers of currency units to pick a kerberos > realm name afaik. > > I'm not saying this solves the conundrum, but I do > assert that this fact invalidates some arguments to > the effect that the IETF cannot standardise another > "global" name form using the same syntax because of > problems that may or may not be caused by overlaps in > the name spaces - we've not had critical problems with > doing just that for nearly 30 years. (Since RFC1510.) > > Cheers, > S. > > [1] https://www.rfc-editor.org/rfc/rfc4120#page-55 > <OpenPGP_0x5AB2FAF17B172BEA.asc> > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
