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

Andy Bierman <> Fri, 12 July 2019 21:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2626C12030D for <>; Fri, 12 Jul 2019 14:16:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.603
X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r4SfcJ7Eo3LY for <>; Fri, 12 Jul 2019 14:16:42 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 71ED91200D5 for <>; Fri, 12 Jul 2019 14:16:42 -0700 (PDT)
Received: by with SMTP id r15so2463226lfm.11 for <>; Fri, 12 Jul 2019 14:16:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZxrYDx0Tk5siBKsUz7QiwqF9g0dWjw8HB27vmMCbDEg=; b=vJuPU+IY5vQ+wZ2F6/DOch5tGKk8OFmgQpqEusQTCUBhNrAV3764GZxcxkv7q+xbH9 V0N2V2B6eWc5Il8/w1HwuQ0KrytvsyRbv1El6mNw6V9uLs8McYjBpCEZNpPzgHGM/J0z SHAQpfWU0cvvBAK3S52J0JGr7nUjAao2ugkEyG3wcZUEA3dAAvlkGSBSsI8KarapvxXo 78ujxx0RKLA87URJ4Wfwe9Bo40i2CroQ1B/gNdK2UMCEz9fWtKImfn1b6Gnw2IOiW8M4 BoF370wBw6iysNcn2bs1+KnWLwIOoZt9JtQAx5f3mZ4eDW1/eThYMslwbJLfRoBo7DZ7 Dogg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZxrYDx0Tk5siBKsUz7QiwqF9g0dWjw8HB27vmMCbDEg=; b=U/bf68bj4kGWcAZD0gGDEqCnuhAfsspMS+Blms8AYGdPJkuUPfdpzBbJhwVo+c5+hP 2kSFYKqtXlbnAZnRUAa2Q0W+h+ZXW4fjDOnimFhl3orpXKPB05+ZwPmQ/z9GoP1PhIbC /6BEMG5WsPa/hkecWsUzohv5orCtbCzXP8VRAmbT8z/UCBLayh9SujrN9cJZa7bdaoHu 4dLyk3Jyk0v5xETgWMC+jp1l0ZL0DefZm1xpNOK8U4TzbZ6whKTWekUtdwZbPI3oAiiM ctiAxaCh6FIUtrhLClFLZ7PQKNhjvpMrRk6aBy5I3mczC04Z6G6wGZyp1A7cMPEeNHoK yI7g==
X-Gm-Message-State: APjAAAUWVYghTr66pwuKPfU7A5Sk/iNzU13G+qlj0vYoqBjWmK1snqHL Df1a4rmVcW4VcaMDCl+QiOcgpdgzN2EPhX6UOkkKjA==
X-Google-Smtp-Source: APXvYqyppQvtIkuMyIWG7KtURef/qDTC9DnEoNL2mtOWdkjgqsVIR2olhqIbZXHSj3GskG9V7mmGD2dzp5ls8Xm52PU=
X-Received: by 2002:ac2:514b:: with SMTP id q11mr5889692lfd.33.1562966200350; Fri, 12 Jul 2019 14:16:40 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Andy Bierman <>
Date: Fri, 12 Jul 2019 14:16:29 -0700
Message-ID: <>
To: IETF Secretariat <>
Cc:,, Core <>
Content-Type: multipart/alternative; boundary="0000000000002b0d8f058d826d0c"
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: Fri, 12 Jul 2019 21:16:45 -0000

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
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