Hi Martin,
On 8/15/22 14:49, Schanzenbach, Martin wrote:
I do not agree that the registration policy should allow multiple entries for the same
subdomain or be "free for all" as it is currently in the draft.
...> So, from my authors hat, I would appreciate FCFS
That's a good point, and I agree. However, I think that addressing FCFS is an
issue that is separate from the carve-out problem.
My take would be: first establish consensus on the carve-out mechanism, then
let's talk about what the naming allocation policy is within the carve-out.
The first (carve-out process) I consider an IETF task; the second (allocation
policy within the carve-out) I'm not so sure about. But again, I think that
question comes later.
; ideally also existing RFC/Other Specification + Implementation(s) for a
registration in the registry.
Of course, as proposed by someone else, not using any TLD and just allowing us
to specify a protocol without touching the namespace at all would also be a
viable option.
How would you feel about using an underscored top level?
For example, _gns instead of gns.alt, or _whatever (perhaps several of those?).
That would give you a top-level mount point in the domain name space, which may feel less
second-class to GNS users, and you could trade the prescribed "alt" string
(which is charged with meaning) for a more neutral underscore.
In terms of specification, I think that would be pretty straightforward: To get
started, we could basically pass a document that says
If you're going to use a top-level name for a non-DNS purpose,
please prepend an underscore to whatever you're using. DNS
stub and full resolvers, stop resolution when you see this.
We wouldn't have to declare an explicit list (registry) of special-use
top-level names at that point.
It's very simple, and definitely better than giving no guidance. It will be
within non-DNS proponents' interests to use this convention, as namespace
collisions are harmful to them as well.
OTOH, if we don't give guidance, people (not GNS specifically) will just
continue camping on more ASCII TLDs for non-DNS uses. That's the exact thing we
are aiming to avoid.
Best,
Peter
--
https://desec.io/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
