Re: [core] The CORE WG has placed draft-veillette-core-yang-library in state "Call For Adoption By WG Issued"

Michel Veillette <> Mon, 15 July 2019 14:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EE4E5120157; Mon, 15 Jul 2019 07:37:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.8
X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KAtLkLR6IlWW; Mon, 15 Jul 2019 07:37:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C260B12015C; Mon, 15 Jul 2019 07:37:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-Trilliant-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=az78oDuzFWV25JBbDUfZd1NHOS+vRgbT/ml/p5Ci5ys=; b=MHJYKH4kg3x1LXY2Fo7v+ez5T/rdLRkvKzrZBrbyzklPToCVXSirdrEaQ2Z8aj6TgmgHInCYAydrdO/YLEriWADux2toSirwn4jDi4l2SPoqz6mA4m2bLiDwldf69S4dHcDE7xpO4N7QujWDHop/GEH7rWtLGXzfOXenI6N2kVU=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Mon, 15 Jul 2019 14:37:08 +0000
Received: from ([fe80::1e6:493d:1ca9:ba82]) by ([fe80::1e6:493d:1ca9:ba82%7]) with mapi id 15.20.2073.012; Mon, 15 Jul 2019 14:37:07 +0000
From: Michel Veillette <>
To: Andy Bierman <>, IETF Secretariat <>
CC: "" <>, "" <>, Core <>
Thread-Topic: [core] The CORE WG has placed draft-veillette-core-yang-library in state "Call For Adoption By WG Issued"
Thread-Index: AQHVN/3dcAv7wXPl5UO8jjBweVNxDabHfiiAgARDusA=
Date: Mon, 15 Jul 2019 14:37:07 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: fr-CA, en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 35adc834-266a-409b-30c3-08d70931e9fc
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BL0PR06MB4562;
x-ms-traffictypediagnostic: BL0PR06MB4562:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 00997889E7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(39840400004)(396003)(366004)(376002)(136003)(189003)(199004)(33656002)(54906003)(6116002)(790700001)(110136005)(316002)(4326008)(3846002)(2906002)(86362001)(76116006)(66476007)(186003)(26005)(66446008)(64756008)(66556008)(66946007)(76176011)(6506007)(99286004)(68736007)(7696005)(5660300002)(102836004)(52536014)(53546011)(966005)(14444005)(55016002)(476003)(7736002)(256004)(53936002)(6436002)(66066001)(229853002)(14454004)(54896002)(81156014)(8676002)(81166006)(9686003)(6246003)(478600001)(486006)(606006)(6306002)(8936002)(236005)(25786009)(74316002)(71190400001)(71200400001)(11346002)(446003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4562;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: qOeJ7ezodZp7kUwdPZtzDz8sJHLoL1WrfaHuV9UKikGHWsgh0Bwav6ZNIvrnPWQGb4D/rBMgHdLcyReyqHjRRtpl5JkBGxpwk0UegitP3oXg4RoS0ulxhc1LUaJOwVBCY4xm0YB6nHegs56dbP5QuKtqibl7TFQ6k6j+LdQEURQKGccBydrShDBnEJDgTBJvdIQxCz446MrLLtZtUsJn/LHrLNuh/lfYp86HdqxQw35X01YRc8wXOXirPSAJlH/E40mcKAcIw7G0NfreOOcyl7mzmvpnMgcrYoYE5afq0FLXZwSoPesy9fmASMduhQAkKD24Jj0FAbeoXOQCRMQH0ecECq5RhRXe2ZWwoceOvjYfTp/nvoyCasVJxxF+HyEesaH45iEBkzY5r5wnYgcRre6fT+DV6yC+khCUyUBp3d0=
Content-Type: multipart/alternative; boundary="_000_BL0PR06MB5042F6FBD47E8C3757D620C29ACF0BL0PR06MB5042namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 35adc834-266a-409b-30c3-08d70931e9fc
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2019 14:37:07.7642 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4562
Archived-At: <>
Subject: Re: [core] The CORE WG has placed draft-veillette-core-yang-library in state "Call For Adoption By WG Issued"
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Jul 2019 14:37:13 -0000

Hi Andy

I effectively see some values in supporting the module names.
However, these names should be optional leaves and not mandatory keys.
Simply augmenting the existing “ietf-yang-library” will increase its size, which makes this solution even less friendly to constrained devices and networks.

Hope to see you in MTL to discuss these changes,

From: Andy Bierman <>
Sent: 12 juillet 2019 17:16
To: IETF Secretariat <>
Cc:;; Core <>
Subject: Re: [core] The CORE WG has placed draft-veillette-core-yang-library in state "Call For Adoption By WG Issued"

On Thu, Jul 11, 2019 at 8:32 AM IETF Secretariat <<>> wrote:

The CORE WG has placed draft-veillette-core-yang-library in state
Call For Adoption By WG Issued (entered by Carsten Bormann)

The document is available at<>

I do not know if there is a clear problem statement presented and agreed upon by the CORE WG yet.
The YANG Library (RFC 8525) is used by a server to provide a client with details about the YANG modules
that are implemented in the server.

The draft proposed for adoption is a cut-and-paste-and-replace version of this RFC.
The strings used as list keys (e.g., /yang-library/module/name) are replaced by SID values.
Other key leafs such as /yang-library/schema/name are replaced by int8 leafs instead of strings.

IMO there are better solution approaches, considering that this data structure will be
relatively static, and there is a caching mechanism built into RFC 8525 to reduce
retrieval of the entire YANG library.

It does not seem realistic that a server would have only SIDs installed and no way to get the module names.
This is a short list, unlike the list of YANG data nodes. So it should be OK to simply augment the existing module
with SID values.  If the list key replacements are really needed, then a deviation module could be used by CORECONF
(e.g. deviate replace {type-stmt}) instead of a replacement module.

I agree it will be important for a CORECONF client to determine the YANG library details for each server.
This could be offline data or directly retrievable from the server. The solution need to be resolved by the WG.
I support the problem statement by not this solution.


Till 2019-07-18

core mailing list<><>