Re: [netmod] yang-data-ext issues

Martin Bjorklund <mbj@tail-f.com> Mon, 16 April 2018 14:52 UTC

Return-Path: <mbj@tail-f.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 42B57126B6E for <netmod@ietfa.amsl.com>; Mon, 16 Apr 2018 07:52:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RV9ngpDjNUQE for <netmod@ietfa.amsl.com>; Mon, 16 Apr 2018 07:52:55 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E8C8012DA0D for <netmod@ietf.org>; Mon, 16 Apr 2018 07:52:54 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 3FE841AE00A0; Mon, 16 Apr 2018 16:52:53 +0200 (CEST)
Date: Mon, 16 Apr 2018 16:52:52 +0200
Message-Id: <20180416.165252.1949100412452419279.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CABCOCHQS5SdJhZrgoVug4Lux2WLCmieN26Kte_FEdzh9VB=riw@mail.gmail.com>
References: <20180416.145617.1262098657698751846.mbj@tail-f.com> <CABCOCHQS5SdJhZrgoVug4Lux2WLCmieN26Kte_FEdzh9VB=riw@mail.gmail.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/jxX132xN7kqZW7igWR2zwA4ASfg>
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: Mon, 16 Apr 2018 14:52:59 -0000

Hi,

Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
> 
> I am strongly opposed to this change because it breaks the rule in YANG 1.1
> that there cannot be 2 sibling nodes defined in the same module namespace.
> 
> IMO since any yang-data nodes are ALLOWED to be used at the top-level,
> then these top-level nodes cannot have conflicting names.

What do you mean with "used at the top-level"?  Do you mean that they
are allowed to be used e.g. in an XML instance document?  If so, we
should not allow more than one container either.

> It is very important when parsing an instance document that the instance
> data
> can be associated with the correct schema.  This is not possible if the
> same top-level node has multiple yang-data nodes defined.

Correct.  And a structure with more than one node is also not possible
to use in an instance document, but we still allow it.

There is no requirement that a yang-data structure MUST be used as a
single instance document.

My point is that it should be up to the designer that define a
yang-data structure to ensure the structure can be used properly.  In
some cases it means that the designer uses a single container, in some
cases it means that two different strcutures have unique nodes, and in
other cases it might mean that all lists have keys.  We should ensure
that all these use cases are supported.


/martin



> If one needs to define data that is not top-level, (1) use augment-yang-data
> or (2) use a different module.
> 
> 
> Andy
> 
> 
> 
> On Mon, Apr 16, 2018 at 5:56 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> 
> > 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
> >