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=>
- Re: [netmod] yang-data-ext issues Kent Watsen
- Re: [netmod] yang-data-ext issues Joe Clarke
- Re: [netmod] yang-data-ext issues Kent Watsen
- [netmod] yang-data-ext issues Martin Bjorklund
- Re: [netmod] yang-data-ext issues Joe Clarke
- Re: [netmod] yang-data-ext issues Andy Bierman
- Re: [netmod] yang-data-ext issues Martin Bjorklund
- Re: [netmod] yang-data-ext issues Martin Bjorklund
- Re: [netmod] yang-data-ext issues Andy Bierman
- Re: [netmod] yang-data-ext issues Robert Wilton
- Re: [netmod] yang-data-ext issues Andy Bierman
- Re: [netmod] yang-data-ext issues Martin Bjorklund
- Re: [netmod] yang-data-ext issues Robert Wilton
- Re: [netmod] yang-data-ext issues Andy Bierman
- Re: [netmod] yang-data-ext issues Ladislav Lhotka
- Re: [netmod] yang-data-ext issues Kent Watsen
- Re: [netmod] yang-data-ext issues Martin Bjorklund
- Re: [netmod] yang-data-ext issues Andy Bierman
- Re: [netmod] yang-data-ext issues Martin Bjorklund
- Re: [netmod] yang-data-ext issues Andy Bierman
- Re: [netmod] yang-data-ext issues Kent Watsen
- Re: [netmod] yang-data-ext issues Robert Varga
- Re: [netmod] yang-data-ext issues Ladislav Lhotka
- Re: [netmod] yang-data-ext issues Martin Bjorklund
- Re: [netmod] yang-data-ext issues Andy Bierman
- Re: [netmod] yang-data-ext issues Martin Bjorklund
- Re: [netmod] yang-data-ext issues Andy Bierman
- Re: [netmod] yang-data-ext issues Robert Varga
- Re: [netmod] yang-data-ext issues Juergen Schoenwaelder
- Re: [netmod] yang-data-ext issues Robert Varga
- Re: [netmod] yang-data-ext issues Juergen Schoenwaelder
- Re: [netmod] yang-data-ext issues Martin Bjorklund
- Re: [netmod] yang-data-ext issues Martin Bjorklund
- Re: [netmod] yang-data-ext issues Andy Bierman
- Re: [netmod] yang-data-ext issues Martin Bjorklund
- Re: [netmod] yang-data-ext issues Andy Bierman
- [netmod] Extensions vs new YANG versions [was Re:… Robert Wilton
- Re: [netmod] yang-data-ext issues Robert Wilton
- Re: [netmod] Extensions vs new YANG versions [was… Ladislav Lhotka
- Re: [netmod] yang-data-ext issues Ladislav Lhotka
- Re: [netmod] yang-data-ext issues Ladislav Lhotka
- Re: [netmod] yang-data-ext issues Martin Bjorklund
- Re: [netmod] yang-data-ext issues Martin Bjorklund
- Re: [netmod] yang-data-ext issues Martin Bjorklund
- Re: [netmod] yang-data-ext issues Ladislav Lhotka
- Re: [netmod] yang-data-ext issues Andy Bierman
- Re: [netmod] yang-data-ext issues Kent Watsen
- Re: [netmod] yang-data-ext issues Martin Bjorklund
- Re: [netmod] yang-data-ext issues Martin Bjorklund
- Re: [netmod] yang-data-ext issues Andy Bierman
- Re: [netmod] yang-data-ext issues Andy Bierman
- Re: [netmod] yang-data-ext issues Ladislav Lhotka
- Re: [netmod] yang-data-ext issues Juergen Schoenwaelder
- Re: [netmod] yang-data-ext issues Ladislav Lhotka
- Re: [netmod] yang-data-ext issues Andy Bierman
- Re: [netmod] yang-data-ext issues Ladislav Lhotka
- Re: [netmod] yang-data-ext issues Ladislav Lhotka
- Re: [netmod] yang-data-ext issues Andy Bierman
- Re: [netmod] yang-data-ext issues Ladislav Lhotka
- Re: [netmod] yang-data-ext issues Martin Bjorklund
- Re: [netmod] yang-data-ext issues Robert Wilton
- Re: [netmod] yang-data-ext issues Ladislav Lhotka
- Re: [netmod] yang-data-ext issues Robert Wilton
- Re: [netmod] yang-data-ext issues Ladislav Lhotka
- Re: [netmod] yang-data-ext issues Juergen Schoenwaelder
- Re: [netmod] yang-data-ext issues Ladislav Lhotka
- Re: [netmod] yang-data-ext issues Andy Bierman
- Re: [netmod] yang-data-ext issues Juergen Schoenwaelder
- Re: [netmod] yang-data-ext issues Ladislav Lhotka
- Re: [netmod] yang-data-ext issues Kent Watsen
- Re: [netmod] yang-data-ext issues Andy Bierman
- Re: [netmod] yang-data-ext issues Kent Watsen
- Re: [netmod] yang-data-ext issues Juergen Schoenwaelder
- Re: [netmod] yang-data-ext issues Kent Watsen
- Re: [netmod] yang-data-ext issues Juergen Schoenwaelder
- Re: [netmod] yang-data-ext issues Martin Bjorklund
- Re: [netmod] yang-data-ext issues Ladislav Lhotka
- Re: [netmod] yang-data-ext issues Martin Bjorklund
- Re: [netmod] yang-data-ext issues Martin Bjorklund
- Re: [netmod] yang-data-ext issues Martin Bjorklund
- Re: [netmod] yang-data-ext issues Ladislav Lhotka
- Re: [netmod] yang-data-ext issues Martin Bjorklund
- Re: [netmod] yang-data-ext issues Robert Wilton
- Re: [netmod] yang-data-ext issues Martin Bjorklund
- Re: [netmod] yang-data-ext issues Juergen Schoenwaelder
- Re: [netmod] yang-data-ext issues Ladislav Lhotka
- Re: [netmod] yang-data-ext issues Robert Varga
- Re: [netmod] yang-data-ext issues Robert Varga
- Re: [netmod] yang-data-ext issues Kent Watsen
- Re: [netmod] yang-data-ext issues Juergen Schoenwaelder
- Re: [netmod] yang-data-ext issues Andy Bierman
- Re: [netmod] yang-data-ext issues Kent Watsen
- Re: [netmod] yang-data-ext issues Ladislav Lhotka