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

[Dave Crocker <[e-mail]>]

Apologies.  There was a posting about this draft in apps-discuss and I 
made the mistake of responding with a substantive proposal on that list. 
  John Levine then responded to the substance, also on apps-discuss. 
I'm reposting this to dnsop to move the thread over to the correct list. 
  I'll forward John's note, to record it, and then finally send a 
response to his note...  sigh.  /really/ sorry.

d/


-------- Forwarded Message --------
Subject: Re: [apps-discuss] Draft of interest in DNSOP: 
draft-ietf-dnsop-attrleaf
Date: Wed, 3 Aug 2016 15:20:04 -0700
From: Dave Crocker <[e-mail]>
Reply-To: [e-mail]
Organization: Brandenburg InternetWorking
To: Patrik Fältström <[e-mail]>, Tim Wicinski <[e-mail]>
CC: [e-mail]

On 7/20/2016 1:59 AM, Patrik Fältström wrote:
> On 20 Jul 2016, at 7:57, Tim Wicinski wrote:
>
>> This draft is not just looking at SRV records, but TXT records which document such behavior.
>
> And URI.



URI:

I think I didn't respond to this:  URI showed up after the original 
drafting of the doc, but yes it needs to be included.  However after 
some very basic research it appears that the URI RR does not yet have 
traction.  So the current doc needs to account for its existence but I 
think it does not create additional registry entries, especially since 
it emulates SRV.



Subordindate Table(s):

More significant is the handling of the second-level underscore node 
name for the two-level naming constructs (where the upper-level is a 
protocol string, used by SRV and URI.  Ray had suggested a way to deal 
with this quite a long time ago and I promptly forgot what it was.  When 
the topic renewed during Berlin, I finally gravitated towards a model 
that luckily was along the lines he proposed...

In practical terms, the second-level underscore names need to be 
registered explicitly, although one might think the SRV doc has covered 
this by pointing to a table.  By my reading, that reference is more 
conceptual than a detailed registry reference.

The set of protocol (upper-level) names is small and should be in the 
registry explicitly.  One might argue that the reference to the separate 
protocol table suffices but this is a case that seems better handled by 
the mild redundancy.

As for the second-level underscore names, I propose that they /also/ be 
registered in this one table.  In theoretical terms, one could argue for 
a separate table, or maybe many of them (one under each top-level 
underscore protocol name) but that purity-drive choice seems somewhere 
between inefficient and silly.

If we thought there would be lots of independent uses of the same name, 
but under different upper-level underscore (protocol) names, we'd need 
all the separate, subordinate names.  And indeed, this is what bogged me 
down originally.

But no one, including me, so far thinks this is a realistic need.  So 
finding a way to simplify this down to one table seems eminently reasonable.

Thoughts?

d/