Re: [netmod] yang-data-ext issues

Robert Wilton <rwilton@cisco.com> Mon, 16 April 2018 15:44 UTC

Return-Path: <rwilton@cisco.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 6F1A312706D for <netmod@ietfa.amsl.com>; Mon, 16 Apr 2018 08:44:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 5ebF9V6AqGFp for <netmod@ietfa.amsl.com>; Mon, 16 Apr 2018 08:44:30 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14D5126DEE for <netmod@ietf.org>; Mon, 16 Apr 2018 08:44:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15338; q=dns/txt; s=iport; t=1523893470; x=1525103070; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=1T6tv+Abr+GgPvqUtoUX5N/UUq8bky/3SNZwCvIu0ks=; b=EoGez2qyf+8qGarcvTgHcHVJFOn9rcwvTccfDLIKY3v4XomzXw0WbWgg KoM9ZO30kHxUyTwhmkzPcuF5/wIztkMDUWhQiKAKZnFsx6HxRM8X+XrLk RR5lgYDiIPNG/+ivMc8pcW8pj6G6p4HDhdpMHsyMAaJdAnkIgpb7R7qdF Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AxAgCaxNRa/xbLJq0ZAUIZAQEBAQEBAQEBAQEBBwEBAQEBgk1GgRAXYyiDZ4gCXo1/CCGBD41+hGqBewsYAQqEFUsCgmU0GAECAQEBAQEBAmwcDIUjAQEBAwEBIUsbCQIYJwMCAicfEQYBDAYCAQEXhHIPiRZum0CCHB+EOINmgioFiVo/gQ8jDIJcgxEBAYRgglQCjASLYAiONQaHR4UEin+FIIElHDgmgSwzGggbFTuCQ4FwMBeIWYU/PjCOOAEB
X-IronPort-AV: E=Sophos;i="5.48,459,1517875200"; d="scan'208,217";a="3175051"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Apr 2018 15:44:09 +0000
Received: from [10.63.23.73] (dhcp-ensft1-uk-vla370-10-63-23-73.cisco.com [10.63.23.73]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w3GFi9op023348; Mon, 16 Apr 2018 15:44:09 GMT
To: Andy Bierman <andy@yumaworks.com>, Martin Bjorklund <mbj@tail-f.com>, NetMod WG <netmod@ietf.org>
References: <20180416.145617.1262098657698751846.mbj@tail-f.com> <CABCOCHQS5SdJhZrgoVug4Lux2WLCmieN26Kte_FEdzh9VB=riw@mail.gmail.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <ef8e1caf-686e-1074-d094-6b6cd907a1a8@cisco.com>
Date: Mon, 16 Apr 2018 16:44:07 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <CABCOCHQS5SdJhZrgoVug4Lux2WLCmieN26Kte_FEdzh9VB=riw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------F3AD200D7A5971CBE5583381"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/JtJtMXhG_Duwab8QtPdgIuqR3v0>
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 15:44:33 -0000

Don't groupings have a somewhat similar concern?

  E.g. if two groupings define the same data node name and are used at 
the same point then you would get a namespace clash, but YANG does not 
disallow the groupings:

      grouping foo_widget {
        leaf name {
          type string;
          description "Name of my foo widget";
        }
      }

      grouping bar_widget {
        leaf name {
          type string;
          description "Name of my bar widget";
        }
      }

      container all_widgets {
        uses foo_widget;
        uses bar_widget;
      }


The principal difference here, is that the compiler can easily check and 
reject the conflict at the uses statements.

Hence I think that it would be good if we could find a solution for 
yang-data-ext that doesn't not require all root yang-data nodes to be 
unique, since that feels somewhat clunky.  I.e. my preference is to keep 
them less restrictive, as Martin has proposed, if this is feasible.

Thanks,
Rob


On 16/04/2018 15:36, Andy Bierman 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.
>
> 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 
> <mailto: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 <mailto:netmod@ietf.org>
>     https://www.ietf.org/mailman/listinfo/netmod
>     <https://www.ietf.org/mailman/listinfo/netmod>
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod