Re: [netmod] yang-data-ext issues

Kent Watsen <kwatsen@juniper.net> Wed, 18 April 2018 17:27 UTC

Return-Path: <kwatsen@juniper.net>
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 A2ED412D881 for <netmod@ietfa.amsl.com>; Wed, 18 Apr 2018 10:27:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.711
X-Spam-Level:
X-Spam-Status: No, score=-0.711 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 zqiVHbjS7e7d for <netmod@ietfa.amsl.com>; Wed, 18 Apr 2018 10:26:58 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD951126D85 for <netmod@ietf.org>; Wed, 18 Apr 2018 10:26:57 -0700 (PDT)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3IHKFdW029338; Wed, 18 Apr 2018 10:26:56 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=Zj4XSzCvW/DN27okVtpIXZyfICqv+U7oPRbhmd9dvf4=; b=ElnhiXo1AEjHBNGhWnKn4oBaMLrxGNTjeYOWlznW18eVTZsF7GYsHOqHTocd+RjyftNX xRyr2jLX7sig+EBFsWxSa6enwTMnjcnAO4s52N4dDoDofzMQDrstCJQcWesLlD6zvPzV uWenKZVtfJTcBb8m6QAyuDE9VntlrwRHALzXGo+2oOb3+W1OtYH5W3R97L3TaHX/6U1a rwUFMLqrB9WdCsoGSsfKOULGHEWlNPXunzzqLUEaCxqfcAXXqWTTcbak7jFhDKDFEM/x ElUQWduWjnwMV0zFS9NYMaDurVJvAq0jHZQYcCSY47qQX1oacOOiJXv3gbaNhBEv/t5v /A==
Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0056.outbound.protection.outlook.com [216.32.180.56]) by mx0b-00273201.pphosted.com with ESMTP id 2he9gj84ty-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 18 Apr 2018 10:26:56 -0700
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3065.namprd05.prod.outlook.com (10.173.218.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.696.5; Wed, 18 Apr 2018 17:26:53 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::173:36cf:42b7:5965]) by DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::173:36cf:42b7:5965%4]) with mapi id 15.20.0696.011; Wed, 18 Apr 2018 17:26:53 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Andy Bierman <andy@yumaworks.com>, Robert Wilton <rwilton@cisco.com>
CC: NetMod WG <netmod@ietf.org>
Thread-Topic: [netmod] yang-data-ext issues
Thread-Index: AQHT1YJYRSnZmZlnhU6JIK4LoPfNTqQDdYgAgAAS9YCAAAZpAIAACwoAgAAFOICAAuemAA==
Date: Wed, 18 Apr 2018 17:26:53 +0000
Message-ID: <AD15A3E2-71BC-4134-AAFD-BA249ABDEEB1@juniper.net>
References: <20180416.145617.1262098657698751846.mbj@tail-f.com> <CABCOCHQS5SdJhZrgoVug4Lux2WLCmieN26Kte_FEdzh9VB=riw@mail.gmail.com> <ef8e1caf-686e-1074-d094-6b6cd907a1a8@cisco.com> <CABCOCHRr=h=G43aJqwVRc+pcs-QV93_adHB4hDQckkVpacH8eA@mail.gmail.com> <6e111dfc-efc7-109f-40f5-8cdba72021fc@cisco.com> <CABCOCHSMQbg6jbafgq90E26OxSGf=9ERDxamJ3s9cp_LN4QC_w@mail.gmail.com>
In-Reply-To: <CABCOCHSMQbg6jbafgq90E26OxSGf=9ERDxamJ3s9cp_LN4QC_w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3065; 7:k+tPdQF6vaKGLlfn017rXuP7ITsopjuU36a3LVuLi7lcClHons3QrEhzBr8vWkLDtns6S8rNABi0w/rj1xRV402cuGs1QHwPObXS/t+arqthxp9CTjVi6u6UKFc8yg/epU1UM3ziIJ6PM40vmklUy5d2iv1cdvSMt2uJYRCC1YVXqBMrdEof4+FYlHk1wsaPDoH7iDTiObmllNOKpMcvIz/e2Sk3j1OgLpncCYTkKp/LX26O2YZkKLJISzjZ1bF8
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:DM5PR05MB3065;
x-ms-traffictypediagnostic: DM5PR05MB3065:
x-microsoft-antispam-prvs: <DM5PR05MB306517395AC13AD6944E075BA5B60@DM5PR05MB3065.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(10436049006162)(131327999870524)(95692535739014)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231232)(944501327)(52105095)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR05MB3065; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3065;
x-forefront-prvs: 06469BCC91
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39380400002)(366004)(39860400002)(376002)(99286004)(316002)(11346002)(966005)(3660700001)(3280700002)(7736002)(8676002)(2616005)(446003)(110136005)(476003)(81166006)(14454004)(93886005)(8936002)(229853002)(2906002)(82746002)(26005)(4326008)(186003)(53936002)(36756003)(33656002)(54896002)(6306002)(86362001)(6512007)(66066001)(561944003)(606006)(6486002)(25786009)(53546011)(6506007)(236005)(5250100002)(478600001)(3846002)(6246003)(76176011)(83716003)(6436002)(59450400001)(6116002)(102836004)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3065; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; MLV:sfv;
x-microsoft-antispam-message-info: XiHM0opgO+fz99BkQ/J3FyTFvxrJHbQLGWcgRjt/Gru5j/+y6piKFMSmyT4QNjNMTVREBxQksAOnsXkNoiM67qcousZ6NhyNVMEw3rhoW+lrpnkAFWEoBlUPBEZf5XYOzWYcIZw/X6qVXZ5EQQeYVuX91aMYSfoFaTR4EU0Kb9LjFqec/UPJbDEx3+9eeAu+
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AD15A3E271BC4134AAFDBA249ABDEEB1junipernet_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: d24806b4-e120-40a1-0eee-08d5a55193e9
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: d24806b4-e120-40a1-0eee-08d5a55193e9
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2018 17:26:53.4782 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3065
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-18_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804180156
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/sBci1LbcS7jTScTFQPd-7kNRvF8>
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: Wed, 18 Apr 2018 17:27:02 -0000

I like Andy's proposal below, for the argument of the 'yang-data' statement to encode some meta-information regarding the context/namespace in which it's used, but I wonder how it really works.  For instance, would "top" and "error-info" be the only allowed base-path values for the argument? and what is the value of the remainder of the path?  are we expecting for there to be some kind us 'uses' statement that can refer to just the base-path component to implement substitution-group like behavior?

Kent // contributor


On 4/16/18, 1:05 PM, "netmod on behalf of Andy Bierman" <netmod-bounces@ietf.org<mailto:netmod-bounces@ietf.org> on behalf of andy@yumaworks.com<mailto:andy@yumaworks.com>> wrote:



On Mon, Apr 16, 2018 at 9:46 AM, Robert Wilton <rwilton@cisco.com<mailto:rwilton@cisco.com>> wrote:



On 16/04/2018 17:07, Andy Bierman wrote:


On Mon, Apr 16, 2018 at 8:44 AM, Robert Wilton <rwilton@cisco.com<mailto:rwilton@cisco.com>> wrote:

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.



It is not clunky that 2 top-level YANG data nodes in the same module
have unique names. This is simple and deterministic.
This restriction has not been a problem so far.
I agree with the statements above.

But it is not clear to me that yang-data-ext is really defining new top level data nodes that are part of the same tree/namespace as the configuration/state nodes.  In Martin's examples they were used within RPCs, and it the forcing the names to be unique in that context that I think would be clunky.  E.g. in Martin's example forcing different names for "reason" and "user-info" doesn't seem to be helpful.




The yang-data statement has to define the context or new abstract namespace,
or whatever this hack is called.
Perhaps.  I think that this depends on how they are used.


The yang-data statement has to specify the expansion point, or
at least specify that it is or is not the top-level.

  yang-data top/name1 {
      container mydata;
  }

where context is something like "top" or "error-info", etc.

It is trivial to use groupings if the same set of nodes needs to be used in different contexts:


  yang-data error-info/name1 {
      container mydata;
  }

Only the context named "top" is restricted to a resulting single-container
and cannot have duplicate names.

This is OK:

  x:yang-data error-info/my-error1 {
      leaf reason {}
  }


  x:yang-data error-info/my-error2 {
      leaf reason {}
  }




Could a fix for this be something along the lines of:
 - yang-data names must be unique amongst other top level data nodes within the module.
 - if yang-data extensions are used at the top level then their name must be used as a single top level container.
 - if a yang-data extension is used within another structure then the yang-data name is excluded, and the top level nodes defined in the yang-data definition are used ....


  Every tool that implements yang-data has to be able
to interpret a yang-data statement exactly the same way.

If you want to reinvent XSD substitutionGroup, then do it right.
I'm not familiar with them.  From a quick read, I don't see how they are related to the problem that we are trying to solve here.


A substitutionGroup allows a point int the schema to be identified by name.
Different elements can be defined that match this name, which then can be
used (like a YANG choice) at the specified schema point.
(e.g. error-info above is like a substitutionGroup)



Thanks,
Rob

Andy







Thanks,
Rob


Andy


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.)



I see no reason to reinvent the grouping-stmt.
You could easily say opx:error-info-structure argument is a grouping name
as it is a yang-data name.



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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=q6I_yKbXVoahv9h5I1wZiQMUeHLZ5XWuMohEYtypmzs&s=jECZMhypw9LtuxzuntkFNM-8lm7xpztYwDDLOxCM_8k&e=>




_______________________________________________

netmod mailing list

netmod@ietf.org<mailto:netmod@ietf.org>

https://www.ietf.org/mailman/listinfo/netmod<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=q6I_yKbXVoahv9h5I1wZiQMUeHLZ5XWuMohEYtypmzs&s=jECZMhypw9LtuxzuntkFNM-8lm7xpztYwDDLOxCM_8k&e=>