And now, my response to John's note...
On 8/3/2016 6:58 PM, John Levine wrote:
The services, on the other hand, were thoroughly cleaned up by RFC
6335. It collected a bunch of informal lists into one place, renamed
a few old names with unfortunate characters, and put them into a tidy
and very large Service Name and Transport Protocol Port Number
Registry. It says in section 5.2 that the service name for a SRV
record MUST follow the syntax rules (ldh with at least one letter and
no leading or trailing or double hyphens, prefixed with an underscore)
and SHOULD be registered in the registry.
If folks agree that this adequately serves the registry function for the
_service, second-level underscore name for SRV and URI, that's fine. As
of Berlin, I thought I heard that there was (still) deviations.
However this introduces a requirement for some additional changes and
I'm not exactly sure where. SRV maps _serve to STD 2 and explicity maps
that to RFC 1700. So the SRV RFC needs to be updated.
But of course with additional research, I find that the RFC John is
cited says that it already has updated the SRV RFC. This provide
yet-another example why we should aggressively deprecate use of RFC
access via
https://www.ietf.org/rfc/
in favor of the datatracker path, since the former doesn't show errata
or update markers, while the latter does. So does the RFC Editor's path:
https://www.rfc-editor.org/info/rfc2782
Interestingly, STD 2 appears to have been formally eliminated, since it
is not listed by the RFC Editor:
https://www.rfc-editor.org/standards
So after going through all that and then looking at RFC 6335, including
its assorted references to support for SRV, I gather the IANA table in
question is:
Service Name and Transport Protocol Port Number Registry
http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
For URI records RFC 7553 says they're either named the same as SRV
records, or they use enumservice names from the Enumservice
Declaring a namespace as the union of two, independently-maintained
registries is a very efficient way to encourage -- actually in
theoretical terms, it guarantees -- collisions.
Other than SRV and URI records, there's a handful of two component
prefix names like _adsp._domainkey and _report._dmarc. As far as I
tell the rest are all all one or two per main name, so listing them
shouldn't be too hard. But please, don't duplicate registries that
already exist.
This line of concern, I think, reduces to the view that the recent
versions of the _underscore draft espoused, which is that the primary
concern needs to be the top-level underscore name, since it draws from a
'global' namespace. For any interesting top-level underscore name --
_proto set for SRV are /not/ sufficiently interesting (distinctive)
which is why we need to worry about their associated _service string --
any underscore names at a lower level are only of interest to the
specification defining them. That is, the global effort can ignore them.
Anyhow, if there is community agreement that the Service Name and
Transport Protocol Port Number Registry is sufficient for SRV (and URI?)
_proto names, then the current draft need do no more than include a
reminder to consult that registry. Yes?
d/
ps. Hmmm. Isn't this draft supposed to be discussed in dnsop and not apps?
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
