On 2/29/2016 7:54 AM, Paul Wouters wrote:
Some comments so far:
thanks for pursuing this. responses:
Normally we try to leave "private use" ranges in registries for people
to experiment on. It would be good to have that here as well, or else we
won't be able to differentiate experimentation from standarization. I
suggest reserving the double underscore space (__*) for private use
(provided this isn't already in wide use)
There is a real problem with private naming, and that is that any use of
private names that becomes successful is then faced with having to
change all existing behaviors to move to a publicly-registered name.
I think it makes more sense to have new uses choose a name that can
eventually be registered and simply experiment with it 'raw' until then.
Given the size of the namespace, the likelihood of a collision during
initial testing is quite small. To make it even smaller, we can make
the barrier to getting an entry in the _Underscore registry very low.
The document should probably explain the RRtype listed in the registry
and interaction/allowance with CNAME/DNAME.
1. What do you mean 'explain' and why should the registry contain this
information? Specifically, how is that information essential to simple
and useful operation of the registry?
2. Entries of this type run the risk of either repeating text in the
actual specification -- and therefore diverging from it if the spec
changes -- or badly summarizing the spec.
Are there any known already existing conflicts where two protocols use
the same underscore entry. If so, how do we resolve that issue?
I don't recall seeing any, in spite of how many _underscore names there
already are.
What are the requirements for entry into this registry. I would not want
to see a rush of people registering vanity names for pet projects,
taking away all the sensible one word entries. I see _mail is available :)
Well, we know the concern about vanity use of DNS-related names is a
long way from silly, so alas I guess we have to worry about that. grrr...
From the list of IANA choices for this:
http://tools.ietf.org/html/rfc5226#section-4.2
I'm inclined to suggest 'Specification Required'. In my own view, an
internet draft ought to qualify, since they no longer disappear, but I
believe the community view is that it would require an RFC or the like.
d/
--
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
