Subject: [DNSOP] Adam Roach's No Objection on draft-ietf-dnsop-attrleaf-fix-04: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Mon, 08 Oct 2018 20:43:09 -0700

Adam Roach has entered the following ballot position for
draft-ietf-dnsop-attrleaf-fix-04: No Objection

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

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

Echoing comments from my review of draft-ietf-dnsop-attrleaf: I believe this
document needs to also include RFC 6763 and RFC 4386; and that it should not
include RFC 6733. Please see that review for details.

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

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

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

§§2.1 and 2.2:

>  An effort has been made to locate existing drafts that
>  do this, register the global underscored names, and list them in this
>  document.

I think this text ("list them in this document") is left over from before this
document was split from draft-ietf-dnsop-attrleaf.

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

§2.3:

This ties back to my discuss on draft-ietf-dnsop-attrleaf, and needs to be
changed in a way that is consistent with however that issue is resolved. The
current list of entries added by draft-ietf-dnsop-attrleaf strongly implies that
the contents of https://www.iana.org/assignments/enum-services were
automatically imported into the namespace created by the Underscore Global
Registry by the simple existence of RFC 7553. If that's the case, it seems that
the following text in this document...

>  For any document that specifies the use of a "URI" RRset

...doesn't capture the real process here. As RFC 7553 will continue to exist
into the future, it seems that the trigger is addition of new Enumservice
entries, rather than the explicit specification of a new URI RRset.

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

§3.1:

>  The specification for a domain name under, which an SRV [RFC2782]
>  resource record appears, provides a template for use of underscored

Nit: "...a domain name, under which..."

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

§3.2:

As a very minor nit, the cited original text for RFC 6117 §4.1 kind of blends in
with the text of this document. I would propose indenting it as was done with
the rest of the quoted content in this section.

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

§3.3:

>  consumes all names beginning with the string "_ta-", when using the
>  NUL RR in the query.

Nit: I believe the record type is called "NULL" rather than "NUL".

---

From: Dave Crocker <[email-masked]>
Date: Wed, 10 Oct 2018 09:51:20 -0400

Responding to your additional comments...

> include RFC 6733. Please see that review for details.

RFC 6733 (Diameter):

      Section 5.2 #3 cites SRV usage with underscore details.  So it 
should remain in -fix, to trigger review of this text if/when the spec 
is revised.

      However the entry in the base table, citing it, should be removed, 
because the RFC 6733 _tls text is an example and not a spec.

RFC 6763:

      Wow.  Whole new RR category for the table, for PTR usage (in the 
base spec, as well as -fix.)

      If I am reading 6763 correctly, in terms of 'global' underscored 
use and distinguishing its 'hypotheticals' from actual usage, it only 
reserves _tcp and _udp.  (For example, its use of _ipp is second-level 
and therefore not global.)

RFC 4386:

      SRV usage.  So, yeah, it's in -fix.

> document was split from draft-ietf-dnsop-attrleaf.

oops.  However I think it useful to highlight the possibility of names' 
having been missed in the initialization of the registry -- and your 
review here has nicely demonstrated the issue... -- so rather than drop 
that sentence, I've modified it to:

      An effort has been made to locate existing drafts that do this,
      register the global underscored names, and list them in the initial
      set of names added to the registry.

> entries, rather than the explicit specification of a new URI RRset.

Given the choice of de-coupling maintenance of the tables, there is no 
goal to make an entry into the underscore table for each new name in 
enumservice.  Rather there is a need to make an entry in the underscore 
table for every URI use of a new underscore entry.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Adam Roach <[email-masked]>
Date: Wed, 10 Oct 2018 10:49:01 -0500

On 10/10/18 8:51 AM, Dave Crocker wrote:
> If I am reading 6763 correctly, in terms of 'global' underscored use 
> and distinguishing its 'hypotheticals' from actual usage, it only 

That's my reading as well.

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 10 Oct 2018 10:52:23 -0500

> Responding to your additional comments... 

Thanks!

I think this reply covers everything that warranted a specific response 
except for the questions in the following three comments, which are 
asking specifically about URI RRs:

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

/a

---

From: Dave Crocker <[email-masked]>
Date: Wed, 10 Oct 2018 12:38:59 -0400

> asking specifically about URI RRs:

Drat.  Sorry.  I'll blame it on limited screen real estate while 
traveling, impeding a careful audit...

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

I believe it was not intentional.  I've added it to the draft because I 
can't think of a downside to its being there...

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

ack.

>>   - RFC 7533 is mentioned elsewhere in the document as the reason 

Hmmm.  I like your last bullet, as a way of choosing between citing 
definition of the RR vs definition of the name.  Thanks!

d/