Re: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-iana-class-type-yang-03: (with COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Fri, 04 June 2021 18:34 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC80E3A1C65; Fri, 4 Jun 2021 11:34:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Level:
X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLxjWXdSneqN; Fri, 4 Jun 2021 11:34:18 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 200343A1C64; Fri, 4 Jun 2021 11:34:17 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 154IYAra028906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 4 Jun 2021 14:34:15 -0400
Date: Fri, 04 Jun 2021 11:34:09 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Ladislav Lhotka <ladislav.lhotka@nic.cz>
Cc: The IESG <iesg@ietf.org>, draft-ietf-dnsop-iana-class-type-yang@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, benno@nlnetlabs.nl
Message-ID: <20210604183409.GU32395@kduck.mit.edu>
References: <162268964645.31215.6261002179076683391@ietfa.amsl.com> <87fsxyhvam.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <87fsxyhvam.fsf@nic.cz>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/TazPMgOgN55uHdGXGMNjGYhUJ6E>
Subject: Re: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-iana-class-type-yang-03: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Fri, 04 Jun 2021 18:34:23 -0000
Hi Lada, On Fri, Jun 04, 2021 at 10:46:09AM +0200, Ladislav Lhotka wrote: > Hi Benjamin, > > thanks for the review, please see below. > > Benjamin Kaduk via Datatracker <noreply@ietf.org> writes: > > ... > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Like Roman, I applaud the use of XSLT to avoid specifying redundant information > > and allow for reasonably automated updates. Some other comments below. > > > > Section 3 > > > > The IANA document "Domain Name System (DNS) Parameters" > > [IANA-DNS-PARAMETERS] contains altogether thirteen registries. The > > > > I suggest "at the time of this writing" just in case we add or remove > > some registries. > > OK, added. > > > > > Section 4 > > > > Upon publication of this document, the initial revision of the "iana- > > dns-class-rr-type" YANG module SHALL be created by applying the XSLT > > stylesheet from Appendix A to the XML version of > > [IANA-DNS-PARAMETERS]. > > > > This is just a random observation from a bystander, but my understanding > > is that IANA is gradually moving registries to a database backend, so > > that the XML version may in some sense not be the "most authoritative" > > version (or the "preferred form for modification" to use the open-source > > software jargon). The XML format mand XSLT are both quite well-defined, > > and the database backend might not be, though, so it's not clear that > > moving to a procedure to generate YANG directly from the database would > > be an advantage over taking a detour via XML. > > That's why this document only deals with the initial revision of the module. Whilst it is perfectly possible that IANA will use the stylesheet for subsequent revisions, it is officially out of scope for this document. > > > > > "status": Include only if a class or type registration has been > > deprecated or obsoleted. In both cases, use the value "obsolete" > > as the argument of the "status" statement. > > > > I don't see any logic in the XSLT that looks for "deprecated", just > > "OBSOLETE". (This may be fine, given that there's not currently > > anything listed as deprecated in the live registry...) > > Right, the XSLT stylesheet is expected to work on those two registries in their current state. The registry XML is loose in some respects and it is not clear (to me at least) how a deprecated entry will exactly look like. It would be certainly better to indicate the status e.g. with an XML attribute. Searching for magic words like "OBSOLETE" in the entry text is brittle, but it's currently the only way. Understood about the current way being brittle but nothing better being available (yet). My comment here was intended more along the lines of an apparent inconsistency between the text and the code -- the text says that we will set "status obsolete" if the registration is deprecated, but the XSLT doesn't do that. IMO it would be better to either drop the text about deprecated or add code to look for it (but this is just a non-blocking comment so my opinion doesn't count for too much). > > > > Section 5 > > > > The XSLT is only run over trusted input, so it is safe to ignore the > > risk of any issues due to improper escaping or input validation. > > Whether or not we need to note this property in the RFC is not entirely > > clear, though. > > I assume that the resulting YANG module will also be validated, e.g. with pyang, so any unintentional translation errors should be discovered. I guess that gets a bit into Francesca's point about how involved the DEs or other parties will be when (new) output is generated. I don't think we need to say more in this subthread, though. > > > > Appendix A > > > > This appendix contains an XSLT 1.0 stylesheet [W3C.REC-xslt-19991116] > > that is intended to be used for generating the initial revision of > > the "iana-dns-class-rr-type" YANG module. This is achieved by > > > > Is this only going to be used for the initial revision, or for updates > > as well? > > As I wrote, the official target is only the initial revision. > > > > > <variable name="lf">
</variable> > > > > This seems unused (and instead we have a lot of 
 literals). > > Correct, I first used this variable but then realized its use is in fact clumsier that the literal character entity. Will remove the definition. Makes sense that actually using it is clumsier than the literal. > > > > contact > > " Internet Assigned Numbers Authority > > > > The leading spaces seem a little out of place in the rendered output, to > > me. > > > > This tries to follow the usual formatting conventions used e.g. in the iana-if-type module (RFC 7224). Unfortunately, YANG doesn't support any markup in the description text. > > > description > > "This YANG module translates IANA registries 'DNS CLASSes' and > > 'Resource Record (RR) TYPEs' to YANG derived types. > > [...] > > This initial version of this YANG module was generated from > > the corresponding IANA registries using a XSLT stylesheet > > > > Though I guess this part might not work well for a non-initial revision. > > Right, the descriptions of subsequent revisions will have to be edited manually because the registries themselves contain no revision info, only revision date. > > > > > "IANA 'Domain Name System (DNS) Parameters' registry > > https://www.iana.org/assignments/dns-parameters";</text> > > <text>

</text> > > > > I may be missing something, but why two <text> children of the > > <variable>? > > The resulting line would exceed 72 characters, if the two LF entities were inserted directly after the semicolon. Ah! Thanks for the explanation. > > > > <apply-templates > > select="iana:registry[@id='dns-parameters-2']"/> > > <apply-templates > > select="iana:registry[@id='dns-parameters-4']"/> > > > > Hardcoding the names "dns-parameters-2" and "dns-parameters-4" is in the > > class of things that (if I understand correctly) IANA is not always keen > > on people doing. In this case it's probably not a big issue, since the > > output of the transformation will be looked at by a human before it's > > published, and we can modify the template if needed, but I do wonder if > > any identifier more closely aligned to the registry's role is available. > > Again, it is only required to work for the initial revision. I would be happy to work with IANA on a more "durable" version of the stylesheet but, as you wrote, the XML format may not be maintained for long. I feel pretty confident that IANA will continue to publish an XML version even if it ends up being generated from some other source. Anyway, there's no urgency for getting a more "durable" version, so we should probably just wait and react if any issues arise in the future. Thanks, Ben
- [DNSOP] Benjamin Kaduk's No Objection on draft-ie… Benjamin Kaduk via Datatracker
- Re: [DNSOP] Benjamin Kaduk's No Objection on draf… Ladislav Lhotka
- Re: [DNSOP] Benjamin Kaduk's No Objection on draf… Benjamin Kaduk
- Re: [DNSOP] Benjamin Kaduk's No Objection on draf… Ladislav Lhotka