On Tue, Aug 16, 2022 at 10:15 PM Schanzenbach, Martin < mschanzenb...@posteo.de> wrote:
> Hi, > > > On 16. Aug 2022, at 16:32, David Conrad <d...@virtualized.org> wrote: > > > > Signed PGP part > > On Aug 15, 2022, at 7:07 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie> > wrote:On 16/08/2022 03:01, John Levine wrote: > >>> Right. If it's FCFS, I am sure I am not the only person who will be > >>> waiting at the gate with thousands of preemptive registrations. > >> Why? > > > > Because they believe (or are convinced) there is or will be profit in > it. My experience has been that the majority of folks who are getting > Unstoppable Domains TLDs haven’t the slightest clue what they are or why > they’re not particularly useful. And they’re paying actual money, not > merely (say) copying a document and changing a few words or wading through > mind-numbing technical process. They are speculators and if the cost of > obtaining the “asset” is below what the projected/potential value may be, > then they’ll “invest”. > > > > That is exactly why IMO the namespaces under .alt must have a technical > merit and this merit gives the protocol a shot at a (or a few based on the > technical design) (free) name under .alt. > It should not be possible to get such a name in the registry without a > technical justification (e.g. a spec that proposes a new way of doing name > resolution). No political or policy considerations necessary. > And this is why there must be a registration policy and process. > What you are describing does not resemble draft-ietf-dnsop-alt-tld, which would define the "alt" SUDN. That document says: There is no IANA registry for names under the ALT TLD - it is an unmanaged namespace, and developers are responsible for dealing with any collisions that may occur under .alt. If you want a SUDN for technically meritorious non-DNS names, perhaps you should distinguish that proposal from .alt. This merit needs to be established, yes. And I think it should be done > through review by the IETF or the ISE. > And yes, there is a reason why this sounds a bit like a RFC6761 SU-TLD, > because the motivation makes sense to me. > In this case, the path forward is clear: propose GNS as a standards-track RFC, proceed through to publication, and use the RFC 6761 process to claim a SUDN for it. Publication of a standards-track RFC is the IETF's sole mechanism for indicating support for the merit of a technical proposal, and is also the threshold for use of RFC 6761. However, if the IETF does not have consensus to adopt GNS as a standard, then it is difficult to see why the IETF would allocate a portion of the namespace for it.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
