On 3/22/2018 2:41 PM, Ray Bellis wrote:
Dave,
I think this is much improved :)
A few nits:
Each globally-registered underscore name owns a distinct, subordinate
name space.
except when it doesn't (i.e. the SRV transports all share the *same*
subordinate name space).
Well, ummm, I think this demonstrates the difference between theory and
practice. In theoretical terms -- as far as the global registration
scheme goes -- they /do/ have their own name spaces. In practical
terms, they adhere to some additional conventions that choose to use the
same subordinate one.
I suppose some sort of language that notes this possibility -- since
it's a popular choice -- is worth adding, to moderate the tone of
independence in the current draft.
- on that note, _sctp and _dccp are missing from the global table.
ack.
- the table formatting is pretty poor, do we really need any more
than just "NAME", "RR" and "REFERENCE"? The ID field just seems
to be an alternate mnemonic for the (already unique) underscore
label itself
I added control because the message header field registration work has
it and it occurred to me it's worth marking.
- the IANA considerations still refer to the now non-existent common
second-level table
darn. thought i'd expunged them all.
the word 'second' appears to now be fully absent from the next version
of the draft...
Not a nit:
- is there a reference for IANA "First Come First Served" rules, and
should we perhaps also mandate "specification required" as a
pre-condition for registration? We don't want that table filled
with any old junk without a stable specification.
What is the downside of leaving the requirement out?
I'm a minimalist in terms of the role of a registry. To the extent
possible, I think that it only has to do registration with
accountability. There are cases where more stringent requirements make
sense, but I don't see this as one of them: there not any danger I can
see in a useless registration entry and there's lots of namespace.
Thoughts?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
