[DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-attrleaf-13: (with COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Wed, 10 October 2018 18:07 UTC
Return-Path: <kaduk@mit.edu>
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 A6F4E127133; Wed, 10 Oct 2018 11:07:38 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dnsop-attrleaf@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, Benno Overeinder <benno@NLnetLabs.nl>, dnsop-chairs@ietf.org, benno@NLnetLabs.nl, dnsop@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.86.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153919485867.5828.1159385971315306368.idtracker@ietfa.amsl.com>
Date: Wed, 10 Oct 2018 11:07:38 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/mmFBGQjJS-2jJKgcsuuw2Of2Oo4>
Subject: [DNSOP] Benjamin Kaduk'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: Wed, 10 Oct 2018 18:07:39 -0000
Benjamin Kaduk 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: ---------------------------------------------------------------------- I'm happy to see this registry created and populated; I would be balloting YES except that I do not think I have time to follow all the references for the initial registry contents. That said, I do share Adam's concern about IANA being more reliable than authors of future enum-services documents at remembering to (check whether to) update a second table, but the subsequent discussion about not all enum-services necessarily being used in URI records seems to support the current scheme. I also have some section-by-section comments. Abstract Formally, any DNS resource record may occur under any domain name. 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. [...] nit: just "underscore" or "_", I think -- "_underscore" is not a well recognized character. Section 1.4 Conversely, a wildcard such as *.example.com can match any name including an underscored name. So, a wildcard might match an underscored name, returning a record that is the type controlled by the underscored name but is not intended to be used in the underscored context and does not conform to its rules. This could perhaps benefit from greater clarity on which entity's perspective the "not intended" applies to. I assume the entity making the wild query does not intend to interpret the response in an underscore context, but the language is a bit hard to follow. Section 3 This section provides a basic template that can be used to register new entries in the IANA DNS Underscore Global Scoped Entry Registry, if the global underscored name above the RRTYPE is not already registered. [...] I'm not sure how to parse "name above the RRTYPE", since (1) the RRTYPE record can have the owner name that is the global underscored name, and (2) the RRTYPE is, well, a record type and not a name. Section 4.1 I would consider adding another 8126 citation for "Expert Review" procedures. Section 4.3 There are some URI usages with node names _kerberos, _kpasswd, and _kerberos-adm listed in draft-ietf-kitten-krb-service-discovery (and implemented, per http://web.mit.edu/kerberos/krb5-latest/doc/admin/realm_config.html#kdc-discovery). It's unclear whether they meet the WG's criteria for inclusion in the initial registry contents, especially at such a late stage of the document's lifecycle. Section 5 For the purposes of this Expert Review, other matters of the specification's technical quality, adequacy or the like are outside of scope. I have mixed feelings about wanting to keep registration open to avoid squatting, but also about wanting to allow the experts to reject requests that do not provide a clear and interoperable description of what the RRTYPE+name is used for. I do think that the first bullet point ("sufficeintly clear, precise and complete") allows the experts some leeway in this regard, but when limited by this statement I'm not sure it provides the experts enough leeway. Section 6 One could perhaps argue that by creating a global registry this document reduces the likelihood of inadvertent collision, and that such collision could have security consequences. But it would be a bit of a stretch.
- [DNSOP] Benjamin Kaduk's No Objection on draft-ie… Benjamin Kaduk