Subject: [DNSOP] Adam Roach's Discuss on draft-ietf-dnsop-attrleaf-13: (with DISCUSS and COMMENT)

From: Adam Roach <[email-masked]>
Date: Mon, 08 Oct 2018 19:15:08 -0700

Adam Roach has entered the following ballot position for
draft-ietf-dnsop-attrleaf-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm glad to see this registry finally being set up, and want to thank everyone
who helped get the document ready. I understand that this has been a large
archaeological undertaking, and that the relatively small size of the document
belies the large amount of actual work that went into it.

I have one top-level concern about the registry, a handful of proposed
corrections to the initial table, and some very minor editorial nits. I present
the following feedback in that order.

---------------------------------------------------------------------------

I have some very strong concerns about the handling for the "URI" RRTYPE.
As far as I can tell, the entries in the initial table were formed by starting
with the entries in
https://www.iana.org/assignments/enum-services/enum-services.xhtml, adding the
most popular entries from
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml,
("dccp", "sctp", "tcp", and "udp") and removing "web".

Please note that it is entirely possible that I've missed an important detail
here, and am merely confused.

My top-line concern is that, while the table established by this document
appears to intend to be a strict superset of the Enumservices table, there are
no instructions of any kind to the IANA that would result in these tables
remaining in sync -- that is, when a new service is added to the "Enumservice
Registrations" table, one might presume that it needs to also appear in the
new registry established by this document.

I would imagine this could be handled either by asking the IANA to add
instructions to the "Enumservice Registrations" table indicating that a
corresponding entry must be added to this one; or simply by including the
contents of that table by reference rather than by value into this one. I'm
pretty agnostic about which approach is taken.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Related to the topic in my DISCUSS, I have three very closely related comments:

Comment 1: Was the removal of "web" intentional?

Comment 2: These initial entries misspell "xmpp" as "xmp"

Comment 3: Is it envisioned that all future URI entries in this table will
reference RFC 7533? That doesn't quite seem right. My instinct is that it would
serve the users of this registry better if:

 - _iax refers to RFC 6315
 - _acct refers to RFC 7566
 - All other enumservice-based URI entries in the current table refer to
   RFC 6118
 - RFC 7533 is mentioned elsewhere in the document as the reason enumservices
   appear in the table.

---------------------------------------------------------------------------

RFC 6763 §6 says:

   Every DNS-SD service MUST have a TXT record in addition to its SRV
   record, with the same name, even if the service has no additional
   data to store and the TXT record contains no more than a single zero
   byte.

It's worth noting that RFC 6763 limits its use strictly to the use of "_tcp" and
"_udp" -- all non-TCP transports are coded as "_udp". So I believe the following
entries need to be added:

              | TXT        | _tcp             | [RFC6763]  |
              | TXT        | _udp             | [RFC6763]  |

---------------------------------------------------------------------------

RFC 4386 §2 defines Global SRV records for _ldap, _http, and _ocsp. So:

              | SRV        | _ldap            | [RFC4386]  |
              | SRV        | _http            | [RFC4386]  |
              | SRV        | _ocsp            | [RFC4386]  |

---------------------------------------------------------------------------

Regarding the existing entry:

              | SRV        | _tls             | [RFC6733]  |

RFC 6733 uses this name non-normatively in an example, as an intermediate
target while resolving an NAPTR record, and it is clearly a site-local
decision rather than a protocol element. I do not believe this should be
construed as reserving the name; its use in this context is clearly, in the
words of this document's introduction, "a matter of operational convention,
rather than defined protocol semantics."

---------------------------------------------------------------------------

§1.1:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in [RFC2119].

Minor nit: please consider using the boilerplate from RFC 8174.

---------------------------------------------------------------------------

§4.1:

>  o  The table is to be maintained with entries sorted by the first
>     column (RR Type) and, within that, the second column (_Node Name).

Minor nit: I suggest that this document would be improved by sorting the table
in §4.3 in this order as well.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 9 Oct 2018 13:56:10 -0400

> https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/
I will be on a plane during this telechat (actually, I hope to have landed
before the telechat, but no guarantees, etc.)

I'm OK with either of the above solutions (and hope that Dave is as well).
W

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Dave Crocker <[email-masked]>
Date: Tue, 9 Oct 2018 14:22:51 -0400

> new registry established by this document.

Adam,

Ongoing dependence on these other tables was the original model, and for 
a long time.  It is not the model now.

A major motivation for making this change was exactly to avoid the 
synchronization challenge you note. So the round of effort that produced 
the document split to a base and and a -fix also produced a change in 
the use of the independent tables.

The current specification /eliminates/ dependence on these other tables.

The goal has been to register all the names that are known to be used, 
from the various other tables, and then modify the specs that were 
originally written using those other tables to, instead, require making 
further additions directly and only to the _underscore registry.

There was quite a bit of discussion about the challenge of 
synchronization.  This was not helped by the fact that the IANA folk are 
so accommodating and expressed a willingness to attempt to keep things 
in sync. However it isn't reasonable to task them with that on-going 
synchronization effort: it's certain to fail at some point.  So instead 
we eliminated the requirement.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Adam Roach <[email-masked]>
Date: Tue, 9 Oct 2018 13:45:52 -0500

On 10/9/18 1:22 PM, Dave Crocker wrote:
> Ongoing dependence on these other tables was the original model, and 
> for a long time.  It is not the model now.
>
> synchronization challenge you note. So the round of effort that 
> produced the document split to a base and and a -fix also produced a 
> change in the use of the independent tables.
>
> originally written using those other tables to, instead, require 
> making further additions directly and only to the _underscore registry.
>
> synchronization.  This was not helped by the fact that the IANA folk 
> are so accommodating and expressed a willingness to attempt to keep 
> things in sync. However it isn't reasonable to task them with that 
> on-going synchronization effort: it's certain to fail at some point.  
> So instead we eliminated the requirement. 

This is based on an assumption that document authors who add 
enumservices are more likely to notice the need [1] to add their service 
name to two tables than the IANA are. Given the respective levels of 
rigor, that seems like a losing bet.

/a

____
[1] Given the 100% coverage in the current table (modulo the "web" 
issue, which I continue to suspect to be an error), "need" seems to be 
appropriate here.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 9 Oct 2018 15:21:00 -0400

> rigor, that seems like a losing bet.

There is certainly a substantive discussion to have about this, since 
the working group did.

But I'll suggest something simple, in the hope that it actually 
simplifies things in process terms:

      This issue was discussed at some length within the working group,
      including disagreements of the sort you raise now.  Eventually the
      working group finally settled on the choices made in the draft.

That is, this is a matter of some tradeoffs that the working group 
considered.

d/

ps. FWIW Personal comment:  having to coordinate tables based the SRV 
spec is unfortunate.  Thinking about having to factor in the URI details 
pretty much blew me by the fact of it's using /two/ tables and how it 
used them.

---

From: Adam Roach <[email-masked]>
Date: Tue, 9 Oct 2018 14:33:18 -0500

On 10/9/18 2:21 PM, Dave Crocker wrote:
>> enumservices are more likely to notice the need [1] to add their 
>> service name to two tables than the IANA are. Given the respective 
>> levels of rigor, that seems like a losing bet.
>
>

That's a fair point. I still believe that this arrangement makes the 
situation as it pertains to URL RRs worse rather than better, but I'm 
willing to call myself in the rough here. If another AD sees fit to 
DISCUSS this issue, I will support them. But I'll clear my own discuss 
now, as it seems that we've reached a difference of opinions regarding 
harm rather than demonstrable harm.

/a

---

From: Dave Crocker <[email-masked]>
Date: Wed, 10 Oct 2018 07:50:32 -0400

> harm rather than demonstrable harm.

Thanks!

d/