Re: [DNSOP] [apps-discuss] Draft of interest in DNSOP: draft-ietf-dnsop-attrleaf

[Dave Crocker <[e-mail]>]

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