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

Eric Rescorla <ekr@rtfm.com> Tue, 09 October 2018 23:23 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB82E130E4C; Tue, 9 Oct 2018 16:23:34 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla <ekr@rtfm.com>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-dnsop-attrleaf@ietf.org, dnsop-chairs@ietf.org, Benno Overeinder <benno@NLnetLabs.nl>, dnsop@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, benno@NLnetLabs.nl
X-Test-IDTracker: no
X-IETF-IDTracker: 6.86.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153912741495.10634.9667308743378893802.idtracker@ietfa.amsl.com>
Date: Tue, 09 Oct 2018 16:23:34 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/vAAVayuedXURrBquSBPoxM4gErQ>
Subject: [DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-attrleaf-13: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Oct 2018 23:23:35 -0000

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?