Subject: [DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-attrleaf-13: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Tue, 09 Oct 2018 16:23:34 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-dnsop-attrleaf-13: 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/

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

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D5596

COMMENTS

>      However some services have defined an operational convention, which
>      applies to DNS leaf nodes that are under a DNS branch having one or
>      more reserved node names, each beginning with an _underscore.  The
>      underscored naming construct defines a semantic scope for DNS record
>      types that are associated with the parent domain, above the
>      underscored branch.  This specification explores the nature of this

This text is a bit hard to parse for the layman. Here's my attempted
rewrite, which captures what I think this means.

Conventionally, this construct associates data with the parent domain,
with the underscored label instead denoting the type of the data.

I'm not sure if that helps, but perhaps something along these lines?

S 1.1.
>   
>   1.1.  Underscore Scoping
>   
>      As an alternative to defining a new RR type, some DNS service
>      enhancements call for using an existing resource record type, but
>      specify a restricted scope for its occurrence.  Scope is meant as a

I think I get why you are saying "scope" here, but it's kind of not
that good fit with the programming concepts of scope as I am familiar
with.

It seems like there are two benefits to this convention (1) indicating
the type of the data (2) the ability to do a selective query.

Perhaps it would be clearer to introduce the convention first with the
typing benefit and then explain that this also gives you the ability
to do a selective query.

S 2.
>                         +----------------------------+
>   
>                          Examples of Underscored Names
>   
>      Only global underscored names are registered in the IANA Underscore
>      Global table.

so just for clarify, in the examples above, only _service[1-4] and
_authority would need to be registered?

---

From: Dave Crocker <[email-masked]>
Date: Wed, 10 Oct 2018 16:18:47 -0400

Eric,

> I'm not sure if that helps, but perhaps something along these lines?

Yeah, this has been an oddly challenging bit of text to formulate.  Perhaps:

      However some services use an operational convention for defining 
specific interpretations of an RRset, by locating the records in a DNS 
branch, under the parent domain to which the RRset actually applies. 
The top of this subordinate branch is defined by a naming convention 
that uses a reserved node name, which begins with an _underscore.

> that good fit with the programming concepts of scope as I am familiar

    So I took your concern as an excuse to review the CS definition and 
find that I still think its application here is appropriate...  And it 
has not seemed to cause confusion for others.

> _authority would need to be registered?

Yes.  (And I've added a sentence noting that point, for clarity. Thanks.)

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 10 Oct 2018 13:26:56 -0700

> that uses a reserved node name, which begins with an _underscore.

Sure, this seems fine.

> has not seemed to cause confusion for others.

OK, well I don't think I agree, but this is a non-blocking comment, so I
don't think there's much point in continuing to debate it.

-Ekr