On 3/20/2018 9:31 AM, John R. Levine wrote:
2. SRV and URI
These need more detailed text, very much in the s/old/new style.
The current text in them does a use-by-reference of existing tables
defined for other purposes. The Update text will, instead, specify a
requirement for adding entries in the Global or Common Second-Level
registries.
The second level registry, though, is a problem, because it tries to
redefine the naming rules for SRV records. RFC 2782 said that SRV
second level names are from the services in Assiged Numbers STD 2. RFC
3400 abolished STD 2 in favor of an IANA registry. That registry, the
Service Name and Transport Protocol Port Number Registry, was cleaned up
by RFC 6335 which reiterates the fact that the service names in that
registry are the services used to name SRV records. RFC 7335 states
that URI records are named the same as SRV, and also says you can use
enumservice _subtype._type.
We need to change the description of the second level name registry to
say that SRV and URI are special, they use names from Ports and Services
at the second level and URI uses enumservice subtypes, and take out all
of the SRV entries. What's left is the grabbag of second level names
used for other stuff like NAPTR and _adsp._domainkey.
Folks,
Level set:
*****
I think what hung me up was mostly missing the reference to
'second-level' while focusing too much on the presence of
the word 'special'.
*****
For any use of an underscore first-level name, that also uses a
second-level name, the authority over that second-level belongs entirely
and solely to that first-level name.
..._my-second._firsta.example
and
..._my-second._firstb.example
have no conflict.
So here's what needs to be clearer in the main attrleaf document and the
fixup document:
All /first-level/ uses of underscore names MUST be registered in
the single, /global/ registry, for in order to avoid collisions.
For second-level names, any name assignment scheme can be used, as
long as it prevents collisions /within the scope of its own
first-level name/.
In the case of SRV, for example, that means that for the core SRV
template specification document:
1. The first-level, _Proto name assignment text has to be updated
to use the new, Attrleaf global table.
2. The second-level _Service name assignment text can remain
unchanged, per RFC 6335.
Point #2 is actually not 'special' at all. I'd entirely missed that the
very strong need to do the first-level fixup did not also require
messing with the existing second-level.
As for the proposed 'common, second-level' table...
Given that this seems to reduce the Attrleaf 'common second-level' table
to only _adsp, I think it best to remove that table entirely from the
main attrleaf document, and instead have the separate fixup document
contain some text specific to the DKIM document's domain naming scheme,
to indicate how future second-level names should be assigned. Since
ADSP is historic, specifying modification to it doesn't make sense to
modify it.
Thoughts?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
