Re: [netmod] [Editorial Errata Reported] RFC7950 (5642)
Martin Bjorklund <mbj@tail-f.com> Mon, 09 September 2019 07:38 UTC
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6514D1200B2 for <netmod@ietfa.amsl.com>; Mon, 9 Sep 2019 00:38:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 dWK2Skdatnff for <netmod@ietfa.amsl.com>; Mon, 9 Sep 2019 00:38:06 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 927B51200C5 for <netmod@ietf.org>; Mon, 9 Sep 2019 00:38:06 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 45C2A1AE0118; Mon, 9 Sep 2019 09:38:05 +0200 (CEST)
Date: Mon, 09 Sep 2019 09:37:41 +0200
Message-Id: <20190909.093741.128094169571185151.mbj@tail-f.com>
To: warren@kumari.net
Cc: andy@yumaworks.com, peter.loborg@ericsson.com, rfc-editor@rfc-editor.org, ibagdona@gmail.com, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CAHw9_iLb8Bf6ntnjM+c5bxawTkvw3Q0opr5wgAwvnWLOoHnpAA@mail.gmail.com>
References: <20190221.193325.152438307014996574.mbj@tail-f.com> <CABCOCHSx50uOPeF6AXYsobe2uPBMrx4pkFnHr7GKMTJpq-HR2Q@mail.gmail.com> <CAHw9_iLb8Bf6ntnjM+c5bxawTkvw3Q0opr5wgAwvnWLOoHnpAA@mail.gmail.com>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/L3rZ7qFjnpsPeRJ4FfJZegWXdig>
Subject: Re: [netmod] [Editorial Errata Reported] RFC7950 (5642)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Sep 2019 07:38:09 -0000
Warren Kumari <warren@kumari.net> wrote: > On Thu, Feb 21, 2019 at 1:53 PM Andy Bierman <andy@yumaworks.com> wrote: > > > > > > > > On Thu, Feb 21, 2019 at 10:33 AM Martin Bjorklund <mbj@tail-f.com> wrote: > >> > >> Andy Bierman <andy@yumaworks.com> wrote: > >> > On Thu, Feb 21, 2019 at 10:07 AM Peter Loborg <peter.loborg@ericsson.com> > >> > wrote: > >> > > >> > > > >> > > > >> > > Your example is fine – but the gammar is ch14 specifies something > >> > > different: > >> > > > >> > > > >> > > > >> > > enum-stmt = enum-keyword sep string optsep > >> > > > >> > > (";" / > >> > > > >> > > "{" stmtsep > >> > > > >> > > ;; these stmts can appear in any order > >> > > > >> > > *if-feature-stmt > >> > > > >> > > [value-stmt] > >> > > > >> > > [status-stmt] > >> > > > >> > > [description-stmt] > >> > > > >> > > [reference-stmt] > >> > > > >> > > "}") stmtsep > >> > > > >> > > > >> > > > >> > > It clearly states string, not quoted-string. These two have the following > >> > > rules: > >> > > > >> > > > >> > > > >> > > quoted-string = (DQUOTE string DQUOTE) / (SQUOTE string SQUOTE) > >> > > > >> > > > >> > > > >> > > string = < an unquoted string, as returned by > > >> > > > >> > > < the scanner, that matches the rule > > >> > > > >> > > < yang-string > > >> > > > >> > > > >> > > > >> > > >> > > >> > The text in 9.6.4 is correct. > >> > The ABNF is wrong. > >> > >> No, the ABNF is correct. The ABNF doens't handle concatenation etc. > >> The idea is that the scanner handles quotes and concatenation and > >> returns a "string". > >> > > > > > > OK -- it is confusing that the rule quoted-string exists, but it > > is only for key and leaf-list predicates. > > Hi all, > > I'm trying to go through and do some cleanup of the dangling Errata. > I'm *certainly* not an expert here, and so am relying on y'all. > From what I've been able to figure out, the consensus is that this > Errata should be rejected, yes? Yes. /martin > W > > > > > > > >> > >> > >> /martin > >> > > > > Andy > > > >> > >> > >> > >> > > >> > > >> > > >> > > …and in 6.1.3 we can read that: > >> > > > >> > > An unquoted string is any sequence of characters that does not > >> > > > >> > > contain any space, tab, carriage return, or line feed characters, a > >> > > > >> > > single or double quote character, a semicolon (";"), braces ("{" or > >> > > > >> > > "}"), or comment sequences ("//", "/*", or "*/"). > >> > > > >> > > > >> > > > >> > > Note that any keyword can legally appear as an unquoted string. > >> > > > >> > > > >> > > > >> > > Since the section so clearly writes about single quoted strings and double > >> > > quoted strings, there can unfortunately be no interpretation that would > >> > > allow “identifier” to be called an unquoted string – even though it follows > >> > > the rules about limited character contents. > >> > > > >> > > > >> > > > >> > > Hence – this is not a matter of opinion – it’s a matter of reading what’s > >> > > actually written in the RFC. > >> > > > >> > > > >> > > > >> > > But on the subject of opinion… > >> > > > >> > > > >> > > > >> > > enum "This is also legal"; // should definitely always be illegal > >> > > > >> > > > >> > > > >> > > …as we cannot create a language binding to enum constructs in any major > >> > > programming languages. > >> > > > >> > > > >> > > > >> > > >> > There are many aspects of YANG that do not map directly to programming > >> > languages, > >> > such as allowing '.' in identifiers. > >> > > >> > > >> > > >> > > Br, > >> > > > >> > > Peter > >> > > > >> > > >> > > >> > Andy > >> > > >> > > >> > > > >> > > > >> > > > >> > > > >> > > *From:* Andy Bierman <andy@yumaworks.com> > >> > > *Sent:* den 21 februari 2019 18:45 > >> > > *To:* Martin Bjorklund <mbj@tail-f.com> > >> > > *Cc:* RFC Editor <rfc-editor@rfc-editor.org>; Ignas Bagdonas < > >> > > ibagdona@gmail.com>; NetMod WG <netmod@ietf.org>; Peter Loborg < > >> > > peter.loborg@ericsson.com>; Warren Kumari <warren@kumari.net> > >> > > *Subject:* Re: [netmod] [Editorial Errata Reported] RFC7950 (5642) > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > On Thu, Feb 21, 2019 at 8:53 AM Martin Bjorklund <mbj@tail-f.com> wrote: > >> > > > >> > > RFC Errata System <rfc-editor@rfc-editor.org> wrote: > >> > > > The following errata report has been submitted for RFC7950, > >> > > > "The YANG 1.1 Data Modeling Language". > >> > > > > >> > > > -------------------------------------- > >> > > > You may review the report below and at: > >> > > > http://www.rfc-editor.org/errata/eid5642 > >> > > > > >> > > > -------------------------------------- > >> > > > Type: Editorial > >> > > > Reported by: Peter Loborg <peter.loborg@ericsson.com> > >> > > > > >> > > > Section: 9.6.4 > >> > > > > >> > > > Original Text > >> > > > ------------- > >> > > > It takes as an argument a string that is the assigned name. > >> > > > > >> > > > Corrected Text > >> > > > -------------- > >> > > > It takes as an argument an unquoted string that is the assigned name. > >> > > > >> > > This is not correct. The enum argument is not different from any > >> > > other keyword's arguments in YANG. See e.g. the example in 9.12.4: > >> > > > >> > > type enumeration { > >> > > enum "unbounded"; > >> > > } > >> > > > >> > > The following is also legal: > >> > > > >> > > enum "unb" + 'ounded'; > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > enum "This is also legal"; > >> > > > >> > > > >> > > > >> > > 9.6.4. The "enum" Statement > >> > > > >> > > > >> > > > >> > > The "enum" statement, which is a substatement to the "type" > >> > > > >> > > statement, MUST be present if the type is "enumeration". It is > >> > > > >> > > repeatedly used to specify each assigned name of an enumeration type. > >> > > > >> > > It takes as an argument a string that is the assigned name. *The* > >> > > > >> > > * string MUST NOT be zero-length and MUST NOT have any leading or* > >> > > > >> > > * trailing whitespace characters* (any Unicode character with the > >> > > > >> > > "White_Space" property). The use of Unicode control codes SHOULD be > >> > > > >> > > avoided. > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > This errata should be rejected. > >> > > > >> > > > >> > > > >> > > /martin > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > Andy > >> > > > >> > > > >> > > > >> > > > >> > > > > >> > > > Notes > >> > > > ----- > >> > > > Readers are not beeing made aware that careful reading of section 6.1.3 > >> > > and the detailed definition of string in section 14 must be consulted. > >> > > > For comming versions of this RFC it would be preferable to use a more > >> > > specialized grammar token for these cases (e.g. unquoted-string). > >> > > > > >> > > > Instructions: > >> > > > ------------- > >> > > > This erratum is currently posted as "Reported". If necessary, please > >> > > > use "Reply All" to discuss whether it should be verified or > >> > > > rejected. When a decision is reached, the verifying party > >> > > > can log in to change the status and edit the report, if necessary. > >> > > > > >> > > > -------------------------------------- > >> > > > RFC7950 (draft-ietf-netmod-rfc6020bis-14) > >> > > > -------------------------------------- > >> > > > Title : The YANG 1.1 Data Modeling Language > >> > > > Publication Date : August 2016 > >> > > > Author(s) : M. Bjorklund, Ed. > >> > > > Category : PROPOSED STANDARD > >> > > > Source : Network Modeling > >> > > > Area : Operations and Management > >> > > > Stream : IETF > >> > > > Verifying Party : IESG > >> > > > > >> > > > >> > > _______________________________________________ > >> > > netmod mailing list > >> > > netmod@ietf.org > >> > > https://www.ietf.org/mailman/listinfo/netmod > >> > > > >> > > > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf >
- [netmod] [Editorial Errata Reported] RFC7950 (564… RFC Errata System
- Re: [netmod] [Editorial Errata Reported] RFC7950 … Martin Bjorklund
- Re: [netmod] [Editorial Errata Reported] RFC7950 … Juergen Schoenwaelder
- Re: [netmod] [Editorial Errata Reported] RFC7950 … Andy Bierman
- Re: [netmod] [Editorial Errata Reported] RFC7950 … Andy Bierman
- Re: [netmod] [Editorial Errata Reported] RFC7950 … Martin Bjorklund
- Re: [netmod] [Editorial Errata Reported] RFC7950 … Juergen Schoenwaelder
- Re: [netmod] [Editorial Errata Reported] RFC7950 … Andy Bierman
- Re: [netmod] [Editorial Errata Reported] RFC7950 … Ladislav Lhotka
- Re: [netmod] [Editorial Errata Reported] RFC7950 … Balázs Lengyel
- Re: [netmod] [Editorial Errata Reported] RFC7950 … Juergen Schoenwaelder
- Re: [netmod] [Editorial Errata Reported] RFC7950 … Balázs Lengyel
- Re: [netmod] [Editorial Errata Reported] RFC7950 … Juergen Schoenwaelder
- Re: [netmod] [Editorial Errata Reported] RFC7950 … Ladislav Lhotka
- Re: [netmod] [Editorial Errata Reported] RFC7950 … Peter Loborg
- Re: [netmod] [Editorial Errata Reported] RFC7950 … Kent Watsen
- Re: [netmod] [Editorial Errata Reported] RFC7950 … Warren Kumari
- Re: [netmod] [Editorial Errata Reported] RFC7950 … Martin Bjorklund
- Re: [netmod] [Editorial Errata Reported] RFC7950 … Joel Jaeggli