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

["John R Levine" <[e-mail]>]

> If folks agree that this [RFC6355] 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 can believe it, but as I suggested, if that's the case, register the 
rogue names in the service name registry.  It's FCFS, not a big deal.

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

Use the rfc-index.txt that comes along with the rsync'ed RFCs.  It has 
what is supposed to be a complete list of what updates and obsoletes what.

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

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.  In any particular 
context a URI record will either be used to look up a regular service or 
an enumservice but not both so if there were a collision, it wouldn't 
matter since the context would tell you which one is intended.  The RFC's 
authors are Patrik and Olaf, so we could ask them if that's what they had 
in mind.  At this point there are only four live proto names and two dozen 
enumservice names, so by my eyeball inspection, there's currently no 
collisions.

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

So far, so good.

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

Is there an extra /not/ in there?  Service names only appear as child 
names of _proto so the _proto are the only ones that can have collision 
problems.

Regards,
John Levine, [e-mail], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.