Re: [netmod] [Technical Errata Reported] RFC7950 (5879)

Ladislav Lhotka <lhotka@nic.cz> Tue, 22 October 2019 19:19 UTC

Return-Path: <lhotka@nic.cz>
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 13518120945 for <netmod@ietfa.amsl.com>; Tue, 22 Oct 2019 12:19:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.997
X-Spam-Level:
X-Spam-Status: No, score=-6.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 wGegC5YwKX9z for <netmod@ietfa.amsl.com>; Tue, 22 Oct 2019 12:19:12 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 182B2120994 for <netmod@ietf.org>; Tue, 22 Oct 2019 12:19:11 -0700 (PDT)
Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:a77:4b4a:dc25:79cc]) by mail.nic.cz (Postfix) with ESMTPSA id 14254140EAF; Tue, 22 Oct 2019 21:19:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1571771948; bh=0DnWVob10MT6QOZvDXVGzObXXnVnE/GM+Y9zvBBxruI=; h=From:To:Date; b=fTLKJUf1QDxUlVR9XT2AeBlEA0EaLI7icrSv1TdAUxvcXhAcitvwocHd+kApjAnLa FwfsX6aqvOnTHuqOT6QqNjxPqpaX21RwGdcwZaK3obSoabYynkbE5KvNwb8/OqTS1N pvFLFKNCEkOofllNGcLl5T10YHEb8gW+klCcSyfQ=
Message-ID: <ef9774e65a3f3cb3af6d50f6dc769ddd3b71d757.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: Martin Bjorklund <mbj@tail-f.com>, rfc-editor@rfc-editor.org
Cc: ibagdona@gmail.com, warren@kumari.net, joelja@bogus.com, kent+ietf@watsen.net, lberger@labn.net, netmod@ietf.org
Date: Tue, 22 Oct 2019 21:19:07 +0200
In-Reply-To: <20191022.170229.971604522071303700.mbj@tail-f.com>
References: <20191022114319.CD85BF4071D@rfc-editor.org> <20191022.170229.971604522071303700.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.100.3 at mail.nic.cz
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/H4XCWcbG2Yv0Ph0ZOoUvzk0j-Cg>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5879)
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: Tue, 22 Oct 2019 19:19:18 -0000

On Tue, 2019-10-22 at 17:02 +0200, Martin Bjorklund wrote:
> Hi,
> 
> The problem is that it is not clear that we can use this new
> definition with the rest of the text in the RFC that uses this term.
> For example, section 7.1.5 talks about "the imported module's schema
> tree", and this doesn't really work if the schema tree is not tied to
> a module.

On the other hand, sec. 9.9 says (and that's how I stumbled upon this):

   The "path" substatement (Section 9.9.2) is used to identify the
   referred leaf or leaf-list node in the schema tree.

With the current definition of schema tree, it would mean that the referred leaf
or leaf-list node must be in the same module, which is of course a nonsense.

Lada

> 
> Also the proposed definition is recursive since it is defined in
> terms of "schema node", and a "schema node" is already defined as "a
> node in the schema tree".
> 
> So it probably makes sense to look at this definition (and the text
> and other definitions) if we do a document update, but as it is
> currently written I think it should be rejected.
> 
> 
> /martin
> 
> 
> 
> 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:
> > https://www.rfc-editor.org/errata/eid5879
> > 
> > --------------------------------------
> > Type: Technical
> > Reported by: Ladislav Lhotka <lhotka@nic.cz>;
> > 
> > Section: 3
> > 
> > Original Text
> > -------------
> > o  schema tree: The definition hierarchy specified within a module.
> > 
> > 
> > Corrected Text
> > --------------
> > o  schema tree: The hierarchy of schema nodes defined in the set of all
> modules 
> >    implemented by a server, as specified in the YANG library data [RFC7895].
> > 
> > 
> > 
> > Notes
> > -----
> > The original definition of the term has two problems:
> > 
> > 1. Schema tree is not limited to a single module. Some YANG constructs, such
> as augment and leafref type, may refer to a schema node that is defined in
> another module.
> > 
> > 2. Apart from schema nodes, YANG modules contain definitions that do not
> contribute to the schema tree: groupings, typedefs, identities etc.
> > 
> > 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
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67