Re: [netmod] yang-data-ext issues

Ladislav Lhotka <lhotka@nic.cz> Tue, 17 April 2018 05:35 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 909EB12EAB9 for <netmod@ietfa.amsl.com>; Mon, 16 Apr 2018 22:35:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 FvIgvEM4Bs2a for <netmod@ietfa.amsl.com>; Mon, 16 Apr 2018 22:35:47 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id A64DB12D892 for <netmod@ietf.org>; Mon, 16 Apr 2018 22:35:45 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id 35C4E1820157; Tue, 17 Apr 2018 07:33:32 +0200 (CEST)
Received: from localhost (unknown [89.24.57.237]) by trail.lhotka.name (Postfix) with ESMTPSA id 8CB2A1820051; Tue, 17 Apr 2018 07:33:29 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Martin Bjorklund <mbj@tail-f.com>, netmod@ietf.org
In-Reply-To: <20180416.145617.1262098657698751846.mbj@tail-f.com>
References: <20180416.145617.1262098657698751846.mbj@tail-f.com>
Mail-Followup-To: Martin Bjorklund <mbj@tail-f.com>, netmod@ietf.org
Date: Tue, 17 Apr 2018 07:35:37 +0200
Message-ID: <87h8oal7iu.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/cQqFLsW7ESoWecSq4YucvznZeFY>
Subject: Re: [netmod] yang-data-ext issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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, 17 Apr 2018 05:35:50 -0000

Hi,

this is a slippery slope. If we want to turn YANG into a general-purpose
schema language, it should IMO be done the other way around: design a
general-purpose schema language with a sound architecture, and then use
it for defining schemas of datastores, protocol messages or whatever.

YANG extensions make changes to the original YANG architecture way too
easy, but the result may be a bastard with no architecture at all.

Lada

Martin Bjorklund <mbj@tail-f.com> writes:

> Hi,
>
> While preparing draft-ietf-netmod-yang-data-ext-02, it turned out that
> it is not clear what, if any, restrictions should be enforced for
> yang-data structures.  Even among the authors we have different ideas
> for how this should work.
>
> Background:
>
> In 8040, the original yang-data extension had a restriction that said
> that a yang-data structure MUST have exactly one container, since it
> wouldn't be possible to have a yang-data structure in an XML instance
> document otherwise.
>
> Since people want to use yang-data structures in other places, this
> restriction was lifted in the new draft:
>
>    There is no longer an assumption that a yang data structure can
>    only be used as a top-level abstraction, instead of nested within
>    some other data structure.
>
>
> With this in mind, here's a use case that I think we ought to support:
>
>   rpc my-first-rpc {
>     description
>       "Bla bla...
>        If an error occurs, <error-info> will contain an instance of
>        the yang-data structure 'my-first-rpc-error-info'.";
>     ...
>   }
>
>   yang-data my-first-rpc-error-info {
>     leaf reason { ... }
>     container user-info { ... }
>   }
>
>   rpc my-second-rpc {
>     description
>       "Bla bla...
>        If an error occurs, <error-info> will contain an instance of
>        the yang-data structure 'my-second-rpc-error-info'.";
>     ...
>   }
>
>   yang-data my-second-rpc-error-info {
>     leaf reason { ... }
>     leaf important-url { ... }
>   }
>
> (maybe in the future we could even have a YANG extension statement to
> formalize the description:
>
>    rpc my-first-rpc {
>      ...
>      opx:error-info-structure my-first-rpc-error-info;
>    }
>
> but this is not point now.)
>
> In the example above, note that the leaf "reason" is present in both
> structures.  IMO this is not a problem, since these structures are
> used in different contexts.
>
> My point is that I think we should impose as few restrictions as
> possible to the yang-data extension.  It should be up to the user of
> yang-data to ensure that the structure is defined in such a way so
> that it can be used properly.  For example, a structure that is
> supposed to describe an XML instance document cannot define two leafs
> at the top level.
>
> If the WG agrees with what I wrote above, we need to change the
> augment-yang-data extension so that you would write for example:
>
>   yx:augment-yang-data /ex:my-first-rpc-error-info/ex:user-info {
>     ...
>   }
>
> Comments?
>
>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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