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

[Dave Crocker <[e-mail]>]

Folks (including Patrik)...

Hi.

Checking on where group views are, now that some exchanges have happened 
and time has passed...

On 8/3/2016 8:48 PM, Dave Crocker wrote:
> 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.

I believe I saw this resolved as a 'nevermind'.  That is, the believed 
deviations turn out not to be a concern, based on Ray's one posting.  Yes?


> 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

And the draft -attrleaf- needs to point to this, I believe.


>> 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.

Patrik's and John 's postings notwithstanding, I'm still concerned about 
the proposed way of handling this, namely to rely on IANA to do a manual 
check of the two registries the URI RR might call on.  First, it does 
not seem reasonable to me to impose that burden on the IANA staff and 
second a manual process like that is almost certain to produce errors.


On 8/3/2016 9:05 PM, John R Levine wrote:
 > I suppose, but since the two registries exist and the URI RFC says to
 > use both of them as _name, that horse has left the barn.

I think it left the theoretical barn, but not the practical one.  We've 
been told that there is not yet any uptake in the URI RR.  That makes it 
plausible to modify its spec to eliminate this problem.

Really, the burden of trying to have on-going coordination for the URI 
RR, between two different registries is worth finding a way to avoid. 
The problem is that I am not sure what to suggest that will work for URI 
usage.

Suggestions?


d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net