IETF Logo Mail Archive

Re: [netmod] [Technical Errata Reported] RFC8342 (5514)

Rohit R Ranade <rohitrranade@huawei.com> Wed, 19 December 2018 03:35 UTC

Return-Path: <rohitrranade@huawei.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 435EC130DC8 for <netmod@ietfa.amsl.com>; Tue, 18 Dec 2018 19:35:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 S0rJUEMqS6R2 for <netmod@ietfa.amsl.com>; Tue, 18 Dec 2018 19:35:44 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 60B1E12F1A5 for <netmod@ietf.org>; Tue, 18 Dec 2018 19:35:44 -0800 (PST)
Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id BD6B091F09361 for <netmod@ietf.org>; Wed, 19 Dec 2018 03:35:39 +0000 (GMT)
Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 19 Dec 2018 03:35:40 +0000
Received: from DGGEML530-MBS.china.huawei.com ([169.254.8.165]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0415.000; Wed, 19 Dec 2018 11:35:28 +0800
From: Rohit R Ranade <rohitrranade@huawei.com>
To: Kent Watsen <kwatsen@juniper.net>, Andy Bierman <andy@yumaworks.com>, Lou Berger <lberger@labn.net>
CC: Ignas Bagdonas <ibagdona@gmail.com>, Warren Kumari <warren@kumari.net>, NetMod WG <netmod@ietf.org>, RFC Errata System <rfc-editor@rfc-editor.org>
Thread-Topic: [netmod] [Technical Errata Reported] RFC8342 (5514)
Thread-Index: AQHUXJCS1czPI27EsEa0hT7/Fs4rk6UP6SeAgAAhjoCAACVcAIAAHT4AgAALWACAAntMgIAAqF6AgAAFW4CAARrTgIAAMTiAgAAVWYCAAB6NAIAAFGUAgAAKs4CAcL23cA==
Date: Wed, 19 Dec 2018 03:35:27 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BCB29CA@dggeml530-mbs.china.huawei.com>
References: <20181005101427.bw7qo7ertxk2dj5d@anna.jacobs.jacobs-university.de> <1b34ccac-831f-505d-d40b-c21234efc475@labn.net> <20181005142816.avs2es2ymvc7qxwx@anna.jacobs.jacobs-university.de> <2e2f0188-770c-5fad-6a9d-a0be3abd1fce@labn.net> <CABCOCHS4GOVYC0FRJEtCpzQ+VB=u6g0LDEmL1ULqysBA=yhzNg@mail.gmail.com> <20181007064721.i4gfbmhrldvmtgbz@anna.jacobs.jacobs-university.de> <CABCOCHTZMabKuu-T4mGAwiaeWDpSWZopFB42W8A+u7g6ZvRg7w@mail.gmail.com> <20181007170907.23ussvtcds7ftnab@anna.jacobs.jacobs-university.de> <973c0b2d-cc42-fdc6-d405-dd7e561a37a3@cisco.com> <0073d57d-217d-3fff-54c3-7f0cf062c0cc@labn.net> <20181008141357.pme6q4aw2v66yi4m@anna.jacobs.jacobs-university.de> <75052af6-665d-f248-7082-c9a0f4f4ab3d@labn.net> <CABCOCHQdo1LXkET4FgJeBEi2MuwboqTHghWO4c+K701+5TFXCw@mail.gmail.com> <8385F653-C23A-4101-BE30-11670D4DD4FA@juniper.net>
In-Reply-To: <8385F653-C23A-4101-BE30-11670D4DD4FA@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.150.121]
Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6BCB29CAdggeml530mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/LHJZmf5gtESX6Nobwst0OwXbGG4>
Subject: Re: [netmod] [Technical Errata Reported] RFC8342 (5514)
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: Wed, 19 Dec 2018 03:35:47 -0000

Hi All,

So the conclusion here is to raise an Errata on RFC 7950 ? Can others please provide your thoughts.

With Regards,
Rohit

From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen
Sent: 08 October 2018 23:25
To: Andy Bierman <andy@yumaworks.com>; Lou Berger <lberger@labn.net>
Cc: Ignas Bagdonas <ibagdona@gmail.com>; Warren Kumari <warren@kumari.net>; NetMod WG <netmod@ietf.org>; RFC Errata System <rfc-editor@rfc-editor.org>
Subject: Re: [netmod] [Technical Errata Reported] RFC8342 (5514)


> After reading the RFC details, it seems that the example is intentional based on
> the text about NP-containers.
>
> I think an errata could be used because the sentence about a top-level origin must be defined
> could be interpreted to define "top-level" as the topmost level for which the origin property
> is applicable.  It appears the intent was to exclude NP-containers from this requirement.

Yes, it was intentional to exclude np-containers, I view something like:

OLD:
    The origin for any top-level configuration data nodes must be specified.
NEW:
    The origin for any top-level configuration data nodes, except
    non-presence containers, must be specified.

to be almost editorial in nature.  That said, I also do not think that it’s needed, in that I think
one could argue that an np-container isn’t actually “configuration” at all, it’s just implicitly
there providing a skeleton to hang stuff off of.

RFC 8342 says:

   o  configuration: Data that is required to get a device from its
      initial default state into a desired operational state.

An np-container doesn’t actually do this.   RFC 7950 says:

   o  non-presence container: A container that has no meaning of its
      own, existing only to contain child nodes.

Bingo.  RFC 7950 also says:

   o  data node: A node in the schema tree that can be instantiated in a
       data tree.  One of container, leaf, leaf-list, list,  anydata, and anyxml.

Note that it says “container” without clarification.  Clearly an np-container isn’t “data”
so, if there is to be an errata, perhaps it should be against  RFC 7950, for instance:

NEW
   o  data node: A node in the schema tree that can be instantiated in a
       data tree.  One of presence container, leaf, leaf-list, list,  anydata, and anyxml.


Kent // contributor

v2.23.0 | Report a Bug | By Email