[DNSOP] Attrleaf _second-Level modifications (was: Re: Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-03.txt)

[Dave Crocker <[e-mail]>]

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