Subject: Re: [art] draft-ietf-dnsop-attrleaf

From: Dave Crocker <[email-masked]>
Date: Wed, 2 Aug 2017 10:18:35 -0700

On 7/28/2017 8:54 AM, Adam Roach wrote:
> The document is pretty clear about its intended scope, containing 
> statements like:
> 
>> Only the right-most names are registered in the IANA Underscore table
> 
> and
> 
>> The current definition of a global underscore registry attends only to 
>> the "upper-level" names used for these RRs, that is the "_proto" names.
> 
> But then the table includes things like "_ldap" and "_certificates". The 
> only SRV records for (e.g.) LDAP will look like "_ldap._tcp...", which 
> (according

Howdy.

(Posting this on ART, since that's got the active thread on attrleaf, 
for the moment.)

Thanks for the thoughtful comments on the draft.

I've been mulling over the challenges of this registration topic for 
more than a decade, constantly being hoisted on the petard of 
established practice...

First, underscores can be used for multiple levels of node name.  Trying 
to deal with that fully, in a single spec produced an especially 
confused draft, roughly 10 years ago.  More recently it became clear 
that this is best handled by the described simplification the spec now 
declares -- essentially distinguishing between 'top-level' underscore 
names and separately deal with those below.  But, as you note, this is 
not fully or adequately implemented in the latest versions of the draft. 
  But I'll leave details about further fixes for that, for the moment, 
because...

Second, and much worse, is that the original documentation of underscore 
use created an inherently-problematic arrangement:  Attempting to 
synthesize some of the registration by incorporating entries in 
independent registration tables documented in SRV and URI 
specifications.  The semantics therefore would mean there would be more 
than one 'authority' for name registration.  This is a registration 
model designed to produce collisions.

Efforts have been to retrofit an administrative model that accommodated 
this, where the idea of real-time conflict detection and resolution -- 
by infinitely diligent and perfectly perceptive -- IANA staff is one of 
the more recent suggestions.  Unfortunately, there is an essential and 
practical difference between 'excellent' and 'perfect', where the latter 
is an inappropriate goal for human performance.

I've come to the conclusion that "accommodating" the established 
registration practices is a fundamentally wrong path.  The only way to 
solve a problem of multiple registration authorities is to create a 
single registration authority.

That is, the right path is to create a simple and obvious registration 
model, and, separately, go back and fix the problematic documents.

Therefore I propose to:

    1. Have this document define the simple, sole, authoritative 
mechanism for registering "top-level" (global scope) underscore names.

    2. Create a separate document that specifies modifications to the 
SRV and URI documents, rationalizing the use of underscore names, 
through the mechanism defined in -attrleaf-.

Thoughts?

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 3 Aug 2017 00:35:26 -0000

>through the mechanism defined in -attrleaf-.

It seems a bit late to change SRV.  Or would you only adjust the
documentation to match observed reality?

For URI, it points at other RFCs to get the protocol/service and
enumservice names.  Are you proposing to change URI to add an
extra level of name, or do you want to reach through and change
the enumservice RFCs too?

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Wed, 2 Aug 2017 17:42:16 -0700

> documentation to match observed reality?

The latter.  The change is to the registration process, not to SRV, per 
se.  That is, take a snapshot of the existing SRV underscore usage and 
re-specify it in terms of an underscore registry, rather than in terms 
of an inheritance from another registry.

> the enumservice RFCs too?

Same approach as for SRV.  Shift to use the underscore registry.  My 
understanding is that URI has little adoption, so even if the result is 
some usage changes, that might not be intolerable.

d/

---

From: "John R Levine" <[email-masked]>
Date: 2 Aug 2017 20:46:54 -0400

On Wed, 2 Aug 2017, Dave Crocker wrote:
> understanding is that URI has little adoption, so even if the result is some 
> usage changes, that might not be intolerable.

It is my impression that you can count the number of prtocols used in SRV 
records on the fingers of one hand, and the number of enumservice types 
that people actually use on the fingers of the other, so that's probably 
workable.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Adam Roach <[email-masked]>
Date: Wed, 9 Aug 2017 18:25:33 -0500

On 8/2/17 7:42 PM, Dave Crocker wrote:
> The latter.  The change is to the registration process, not to SRV, 
> per se.  That is, take a snapshot of the existing SRV underscore usage 
> and re-specify it in terms of an underscore registry, rather than in 
> terms of an inheritance from another registry.

That would appear to call for a slightly more narrow scope than the 
current document, which claims to be registering underscore usage for 
SRV, TXT, and URI RRs as well as (and I don't quite get this) NAPTR RRs. 
The reason I don't get the NAPTR treatment is: my understanding of NAPTR 
records doesn't include any kind of underscore-prefixed name components 
at all. My knowledge of NAPTR is mostly informed by SIP's usage of 
NAPTR; but I'm pretty sure that, in a generic sense, the overall 
procedure here is to feed in an underscore-free name in as your query, 
and to get back a giant slew of records that indicate various available 
services in their respective "Service" fields, along with a string 
transform that should be applied to the original name, the result of 
which is then fed back into another query for the service of interest.

I have to concede that the situation around registration of NAPTR 
Service values has always baffled me, and section 9 of RFC 3403 makes 
essentially no sense as far as I can tell. SIP solved this problem in 
its little corner of the NAPTR world with the registry at 
<https://www.iana.org/assignments/sip-table/sip-table.xhtml>. I have no 
idea how other protocols are supposed to deal with this situation; or, 
indeed, how one might hope to avoid collisions if the "MPLS-TP Shared 
Ring Protection" mechanism and the "Message Session Relay Protocol" both 
decided to use a NAPTR Service value of "MSRP+D2T".

Practically, for this document, I would recommend having a unified table 
for SRV and URI records, initially containing:

 1. _tcp
 2. _udp
 3. _sctp (implict in rfc6733)

There's also the odd matter of _LDAP, _HTTP, and _OCSP, used by RFC4386 
in what I presume was a misunderstanding of what was meant by "Proto" in 
SRV's definition of that term -- I would think we want to put these in 
the table but mark them experimental and/or deprecated. In fact, I think 
we would want to stipulate that new entries in this registry cannot 
contain any value other than those registered at 
<https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml>.

I would recommend documenting and registering the underscore leaf nodes 
used by TXT records as a completely separate concern and in a different 
IANA table (although still as part of this document), as they mean 
something rather different than what's defined for SRV and URI. I 
believe the initial tables looks something like this at the moment 
(although I may have overlooked one or two):

 1. _domainkey
 2. _dmarc (rfc7489)
 3. _spf
 4. _vouch
 5. _tcp (implicit in rfc6764, rfc7808)

If you want to fix the NAPTR Service registry issue I highlight above, I 
would recommend doing this in a different document. It feels like a 
rather different problem, and the presence of the SIP registry (which 
would need to be subsumed into any complete registry) would seem to make 
it much more complicated to deal with.

/a

---

From: "John R Levine" <[email-masked]>
Date: 9 Aug 2017 19:36:55 -0400

On Wed, 9 Aug 2017, Adam Roach wrote:
> That would appear to call for a slightly more narrow scope than the current 
> document, which claims to be registering underscore usage for SRV, TXT, and 
> URI RRs as well as (and I don't quite get this) NAPTR RRs. ...

See rfc3588 which has some _sctp names for NAPTR records.

> I would recommend documenting and registering the underscore leaf nodes used 
> by TXT records as a completely separate concern and in a different IANA table

That would rather defeat the purpose here, since the goal is to identify 
and ideally prevent name collisions.  Or are you saying that names for TXT 
and for SRV or URI are separate namespaces?

Regards,

---

From: Mark Andrews <[email-masked]>
Date: Thu, 10 Aug 2017 09:44:36 +1000

> and for SRV or URI are separate namespaces?

Unless you have non-overlapping syntax rules they can't be seperate
namespaces.  As long as they both have a single prefix underscore
they are both in the same namespace.

> _______________________________________________
> art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/art
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "John R Levine" <[email-masked]>
Date: 9 Aug 2017 20:42:56 -0400

> they are both in the same namespace.

That's what I thought, too.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Wed, 9 Aug 2017 18:15:03 -0700

On 8/9/2017 4:25 PM, Adam Roach wrote:
> IANA table

Adam,

(Leaving for later, all other comments about the note, other than to say 
thanks for reading the draft, thinking about it, and commenting...)

Your above seems to be calling for two registries that assign out of the 
same namespace.  (Being specified in the same document doesn't matter if 
there are two tables.)

I'm hoping I've seriously misunderstood, since the entire goal of my 
simplification proposal is to avoid exactly that.

Please to set me right.

d/

---

From: Adam Roach <[email-masked]>
Date: Wed, 9 Aug 2017 21:38:02 -0500

On 8/9/17 8:15 PM, Dave Crocker wrote:
>> I would recommend documenting and registering the underscore leaf 
>> nodes used by TXT records as a completely separate concern and in a 
>> different IANA table
>
>
> Adam,
>
> (Leaving for later, all other comments about the note, other than to 
> say thanks for reading the draft, thinking about it, and commenting...)
>
> Your above seems to be calling for two registries that assign out of 
> the same namespace.  (Being specified in the same document doesn't 
> matter if there are two tables.)
>

So, I'll reiterate explicitly what I've only implied to this point: I'm 
not a DNS expert; I've simply dealt with protocols that use DNS, and 
I've managed DNS zones.

What I do know is that I can ask for an RR of type FOO for 
something.example.com and get a response with an answer, and I can ask 
for an RR of type BAR for something.example.com, and get a response with 
no answers. I've internalized this as FOO and BAR being different things 
-- different scopes, effectively -- but (based on your and John Levine's 
and Mark Andrew's responses) clearly have an incorrect mental model of 
what's considered "namespaces," at least as compared to people who deal 
with DNS in more detail.

So ignore the aspect of my proposal that suggested two tables. I think 
the remainder is sound, which probably just resolves to cleaning up the 
table so that it contains only seven entries and removing discussion of 
NAPTR RRs.

/a

---

From: Dave Crocker <[email-masked]>
Date: Wed, 9 Aug 2017 19:49:56 -0700

> what's considered "namespaces," at least as compared to people who deal 

Ahh, interesting.  This might point to a need for some additional 
explanatory (and maybe even denotational) text in the draft.  (I work 
from the theory that confusion in one serious reader is likely an 
indicator that others will suffer the same fate.)

So:

      Scope is meant as a static property, not one dependent on the 
nature of the query.  It is an artifact of the DNS name.

Hence, some.example.com defines the scope, independent of any RR under it.

And in case it's relevant to add this:

      The namespace of the proposed registry covers all node names that 
begin with an underscore and are the 'highest' occurrence of an 
underscore name.

d/

---

From: Adam Roach <[email-masked]>
Date: Wed, 9 Aug 2017 21:52:10 -0500

> See rfc3588 which has some _sctp names for NAPTR records. 

I presume you're referring to the example in Appendix B? I can see how 
it might look like that on first glance, but a careful parsing of what's 
there shows that the only reason it looks like that is because there's 
been some formatting damage. The literal text that's there is:

    ;;          order pref flags service           regexp  replacement
       IN NAPTR 50   50  "s"  "AAA+D2S"           ""
       _diameter._sctp.example.com IN NAPTR 100  50  "s"  "AAA+D2T"
       ""  _aaa._tcp.example.com

This is accompanied with an explanation that there are two NAPTR records 
present (one for AAA+D2S and one for AAA+D2T). I suppose you're reading 
the second line of this text to say "the host 
_diameter._sctp.example.com has an NAPTR record for 'AAA+D2T', with an 
empty regexp and a replacement of '_aaa._tcp.example.com"

Aside from that being kind of nonsense, I'll note that the *first* 
record (if this "_diameter._sctp.example.com" string is part of the 
second record) has no replacement value -- which clearly doesn't work.

The only way this makes sense is if you read the first record as:

   IN NAPTR 50   50  "s"  "AAA+D2S"  ""  _diameter._sctp.example.com

...and the second record as:

   IN NAPTR 100  50  "s"  "AAA+D2T"  ""  _aaa._tcp.example.com

...at which point it becomes clear that the underscores are only in the 
"replacement" field, and not used as input for NAPTR.

I'll file an erratum.

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 9 Aug 2017 22:10:41 -0500

> I'll file an erratum. 

Actually, I was about to until I noticed that this RFC is obsolete, and 
the replacement RFC has fixed the formatting issue. Never mind :)

/a

---

From: Mark Andrews <[email-masked]>
Date: Thu, 10 Aug 2017 13:13:34 +1000

In message <[email-masked]>, Adam Roach write
> "replacement" field, and not used as input for NAPTR.

While you are reporting the NAPTR records the formatting the SRV
records is also poorly presented.  Line breaks and indenting is
critical.

   ;;          Priority Weight Port   Target
      IN SRV  0        1      5060   server1.example.com IN SRV  0
      2      5060   server2.example.com

should be

  ;;          Priority Weight Port   Target
      IN SRV  0        1      5060   server1.example.com
      IN SRV  0	       2      5060   server2.example.com

Personally I would have had the owner names there as well but I didn't
write this document.

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 10 Aug 2017 07:49:42 -0400

> through the mechanism defined in -attrleaf-.

Dave

As the DNSOP Chair who has been pestering you regularly to keep working 
on this pragmatic approach to the problem, I would agree.
(as well the comments from others)

tim