Re: [netmod] yang-data-ext issues

Ladislav Lhotka <> Wed, 02 May 2018 06:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1D81F12D870 for <>; Tue, 1 May 2018 23:54:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5MOToLjnl7Yl for <>; Tue, 1 May 2018 23:54:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3587E12D872 for <>; Tue, 1 May 2018 23:54:15 -0700 (PDT)
Received: by (Postfix, from userid 109) id 6391F182015D; Wed, 2 May 2018 08:59:08 +0200 (CEST)
Received: from localhost (unknown []) by (Postfix) with ESMTPSA id 4B8541820051; Wed, 2 May 2018 08:59:05 +0200 (CEST)
From: Ladislav Lhotka <>
To: Kent Watsen <>, Andy Bierman <>
Cc: NetMod WG <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <20180427144708.6ekknrajexvz5yvf@elstar.local> <> <> <> <>
Mail-Followup-To: Kent Watsen <>, Andy Bierman <>, NetMod WG <>
Date: Wed, 02 May 2018 08:54:18 +0200
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [netmod] yang-data-ext issues
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 May 2018 06:54:18 -0000

Kent Watsen <> writes:

> Lada writes:
>> Andy writes:
>>>IMO, the yang-data defined in RFC 8040 has a clear purpose, and it
>>>is sufficient for that purpose, which is a YANG representation of
>>>an instance document (such as a protocol message or file).
>> The same is basically true even without the extension. For example, I
>> fail to see any benefit from using yang-data in a module like
>> ietf-zerotouch-information.
> I don't understand this, how else would you propose to define the
> JSON-or-XML encoded payload of the CMS structure?

Do the same, just remove the extension. I don't see any terrible things
happening, and *all* tools shoud be able to process it easily.

>>> I am in favor if keeping the yang-data in RFC 8040 and not
>>> creating a new version of it that is unconstrained.
>>> There does not seem to be consensus on how to do this,
>>> or even consensus that it is a good idea.
>> If the extension is deemed necessary, I would also prefer this 
>> approach to making the extension a Proposed Standard.
> I don't understand talk about abandoning this draft.  There is no question
> that it is needed (e.g., anima vouch, zerotouch, tail-f's
> "structure"),

So let me pose this question - why is it actually needed in these cases?
I can see some need whenever such data has to be mixed with normal
configuration and state data in the same module, but it is (I guess) not
the case in the above applications.

> and RFC 8040 is unsatisfactory because 1) it doesn't allow a top-level
> 'choice' between two containers and 2) it requires drafts to reference 
> RFC 8040, even though the drafts may have nothing to do with RESTCONF.
> Sure, maybe we have convinced ourselves that yang-data is not needed
> to model error-info, but that doesn't negate the other use case.
> We need a way to indicate that some data-model represents a stand-alone
> data structure.  It is not configuration, operational state, an RPC, or
> a notification.  It can only appear as a descendent of the 'module'

That's fine, but YANG wasn't designed to be a general schema language,
and I am against making such fundamental changes via extensions.


> statement.  All 'action', 'notification', 'config', and 'if-feature'
> descendent statements are ignored.  For the purpose of 'must' and '
> when' statements, the yang-data structure is its own context root.  It
> has a namespace and a unique local name (unique only to other yang-data
> defined within the same module; it's okay if an RPC, notification, or
> top-level data node has the same name).  Anything else?
> Kent // contributor

Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67