Re: [netmod] yang-data-ext issues

Andy Bierman <andy@yumaworks.com> Mon, 16 April 2018 14:36 UTC

Return-Path: <andy@yumaworks.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 28BBC12DA1A for <netmod@ietfa.amsl.com>; Mon, 16 Apr 2018 07:36:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 KaeXRbx-FUH3 for <netmod@ietfa.amsl.com>; Mon, 16 Apr 2018 07:36:20 -0700 (PDT)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ABA41200C5 for <netmod@ietf.org>; Mon, 16 Apr 2018 07:36:20 -0700 (PDT)
Received: by mail-lf0-x22c.google.com with SMTP id p142-v6so22439104lfd.6 for <netmod@ietf.org>; Mon, 16 Apr 2018 07:36:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fg6iiBL9cilfTY9sjsq0V44VUl7EVofMLENtiTzKciU=; b=I+9TdsRUqTeheaO9F29F6/l6tNSS2+4N9cxehhDfNHJSS+Nw+kbs51xKWrZPFroYfG diWTfBR6Dt+v8Xfu+xJTlnXObe4jRarpNubFEgyQNOzkdIgskxzvi2A6ZvqilKOzOPSF RzxMsGFN3Lu/wgVMgsmHm3gRVV/Sz7ytAOieFLJeKexHnJZpUOB559WBXg8iuPogStlQ wegmiSnhBPJucb4WBY2bnuil5gXR6LFfgAUViqJGzeSrlTqPZPMvZTM/GkKpfB8WPqsa /OmNrbHgHPpuSnfOZnmKKzM24MNA1Rpx6Tt3acajgSA9VRB4F3NV26RfAt24dZmXW8xE L3NQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fg6iiBL9cilfTY9sjsq0V44VUl7EVofMLENtiTzKciU=; b=qqcsMjQVJknsRHpzGAat7gKGBNXLv9MeVdQ3Dry7GZp3r0l3XmcEGYWyv9+SKzWVMh LeXSvF3qG/wVunOTFVS3TkSehDA7wzwsmzbnqOLKAHG8ffNadrwzkJJHiGFxybq03fde zNaOpxZHd/4kCZMedIXjeCCFIzSBayhXNoLx43sA9q7aVm+P4UBum3n2C3fhkobLeeVZ 0O9iXOIr3kQtmX6N7jpCxKX0HFoNCL3a3PaU6ACeYEP1J0H7N1zLP3AWLE8bacIyxErq B7HYkETfMTgvnVl92XZ8l2IOAxt/ZRhuli5Aj3A3mfAEEpZ8ko9jXdGbLAvoNxOQYCoG wr9Q==
X-Gm-Message-State: ALQs6tBRi5HI5eB+AD4pCcRXtZ5iQ9ycB8eoS1z2piW46oKjRGTMDA/P 3oh0lpazyeu0AWxt3rvb4LmAHO2k0Bx5UYIY9/6xtw==
X-Google-Smtp-Source: AIpwx4/kPCDchjyz6vHL83su7wD7g/ESf+ZyeDcgqewLjVq4MjRwK2ZVhHTOMJfyiSu9kqtOnHdxLsila8H+C/8it/E=
X-Received: by 2002:a19:d720:: with SMTP id o32-v6mr14377413lfg.89.1523889378221; Mon, 16 Apr 2018 07:36:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:d8c6:0:0:0:0:0 with HTTP; Mon, 16 Apr 2018 07:36:16 -0700 (PDT)
In-Reply-To: <20180416.145617.1262098657698751846.mbj@tail-f.com>
References: <20180416.145617.1262098657698751846.mbj@tail-f.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Mon, 16 Apr 2018 07:36:16 -0700
Message-ID: <CABCOCHQS5SdJhZrgoVug4Lux2WLCmieN26Kte_FEdzh9VB=riw@mail.gmail.com>
To: Martin Bjorklund <mbj@tail-f.com>
Cc: NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000011030b0569f8252f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ImCQ-9bnpkzdDTCH38OZW0dCL1o>
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:36:23 -0000

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.

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.

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
>