Re: [netmod] Text in import to indicate whether a module is needed as import-only or as implemented
Andy Bierman <andy@yumaworks.com> Thu, 05 March 2020 15:43 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 7A63C3A1698 for <netmod@ietfa.amsl.com>; Thu, 5 Mar 2020 07:43:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 du1_H-hfhZHn for <netmod@ietfa.amsl.com>; Thu, 5 Mar 2020 07:43:02 -0800 (PST)
Received: from mail-yw1-xc42.google.com (mail-yw1-xc42.google.com [IPv6:2607:f8b0:4864:20::c42]) (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 BD3C83A1695 for <netmod@ietf.org>; Thu, 5 Mar 2020 07:43:01 -0800 (PST)
Received: by mail-yw1-xc42.google.com with SMTP id t192so5987496ywe.7 for <netmod@ietf.org>; Thu, 05 Mar 2020 07:43:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gaeo9QhjQ/x0rZ1AsIq/3usBAWRRvzCScvbaARYpQ6A=; b=GiXI9tUwRhUEdbnzechKwNbnrgwvxZQdwut0oCFCFpazVOHe8pZCLZq14jyD3EVVJO 0utEQq+jJnplHLpyqDA5THnOr/IsqZ/7F7MKHmWUNcJ9KtzKu+LxFBn5o758k/0WFSuX EfgxhnKQoR+PA/5JFjj+Yi0MM6rnQiFzJ1GLopM3ZUDZttJKqMdtK5fkYTN//7rbPvqa MWzJmclF/18QYzI7yfbxfDbZ6/63gTe7dtxQGw0yCKYXGfJz3+NkI2CP4PFthTryDj0a eTrO2X5FjYWMOl/KQg4wHXbDUWHSvbq6CtBQOnCXw5DR75U+t4+RzZH90HmyR2GbVErn JvrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gaeo9QhjQ/x0rZ1AsIq/3usBAWRRvzCScvbaARYpQ6A=; b=JMP+rbf5Lx4K6VM1eaOqCZjlsN3zzFyr07gttIDVgLtFgWebLSLstZSimTPYvQRzb2 vyO3ZzyCUXFIYObz4hcB2uFjDumsrGvkloVw2JersZE7D8nm/4Z22K3JQ65dgs6iWDjF DeNgTAo0CCJtx9530RC6Dvx+8LIJAc1gaw47KYnVr8RJu3l9gBmfUSWfUN/RECQXCOWS zA9dz/xk1ZARG8+R7DfGXFNRZSoxMsfzwQh7AOsZaoU0hq45IBiWdOT4Wbzhbiul2hLR ds0rC6cqtnDUhh5q0Q4T4X/oUc9JCKIGgU3xSZwcAidbcepy74kn69d2uq3ma6fyjNjA BLCA==
X-Gm-Message-State: ANhLgQ0WFkQJUZ3aUT+RLTIVEP/2uWK3AaDFjk9u8+p/BTJoIL0sY1fI MZdc8cBTzWgEtycy3XJzm6AF3POjYe2GpGRNSfbExA==
X-Google-Smtp-Source: ADFU+vvoYJVFF9JZSqrz1XpWmDGhAMKe4q5UEdEcWIJBhsEDhLS9TA7tUjNiyaMSBXctJnvvTm9dSbPtLEd0512iIoY=
X-Received: by 2002:a25:4d42:: with SMTP id a63mr7518777ybb.145.1583422980708; Thu, 05 Mar 2020 07:43:00 -0800 (PST)
MIME-Version: 1.0
References: <d3520549f06107de8939af24268f56f56683fbb0.camel@nic.cz> <CABCOCHRFQrXgGKB10B9MXbKa2vMfaY3eWaj5Sp4W0DPQ0F-pGQ@mail.gmail.com> <VI1PR07MB40472B4BEFB581AEE4F7C158F0230@VI1PR07MB4047.eurprd07.prod.outlook.com><20200107.143818.1928135118621633911.mbj@tail-f.com> <VI1PR07MB404773908BCA102EFBB6EE46F03F0@VI1PR07MB4047.eurprd07.prod.outlook.com> <e28ccc2b5b632d861dcdcc8b59184d1b81eb4406.camel@nic.cz> <CABCOCHQ5ps3SMfBiFatqN1R2MFbvY1WRyO9548nOZr1-GKuQ=g@mail.gmail.com> <bbc48da835fc0829dc179e89a8553095b1244677.camel@nic.cz> <CABCOCHR=qBJ=uKK29RP4ynumabeZiaWY-MM30VuG9fsQ6Rq95Q@mail.gmail.com> <940da771-440b-6e42-eaf7-12bc5626441a@cisco.com> <CABCOCHTcp=3cG1ed_3H-XtZdTUOj8O4hEq0sPjdf9d9B3yURsg@mail.gmail.com> <6c7419ed4553947cd84930c240a14cf5f91fac11.camel@nic.cz> <CABCOCHSGYiEsuEEgHZ1Jf6fDXTWn0WxbPewAa=grwy9+7yudYQ@mail.gmail.com> <c58da422-e0b0-75dd-0d94-96fd1ae12007@cisco.com> <CABCOCHRJvVF7NNyyTupYq39DmJN=1xKwmQxMfzF0T-ss0hFM8g@mail.gmail.com> <DB7PR07MB4011F6397EDC5CE7723880F5F0E20@DB7PR07MB4011.eurprd07.prod.outlook.com>
In-Reply-To: <DB7PR07MB4011F6397EDC5CE7723880F5F0E20@DB7PR07MB4011.eurprd07.prod.outlook.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 05 Mar 2020 07:42:49 -0800
Message-ID: <CABCOCHRARyZogky8STdmJSJZNOoKNERwNda4GS=DVp3K7kRxHA@mail.gmail.com>
To: Balázs Lengyel <balazs.lengyel@ericsson.com>
Cc: Benoit Claise <bclaise@cisco.com>, NETMOD WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004b727705a01d64d4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/2di-vg6Pu5Ohb1HmtgUSTX12SDw>
Subject: Re: [netmod] Text in import to indicate whether a module is needed as import-only or as implemented
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 05 Mar 2020 15:43:07 -0000
On Thu, Mar 5, 2020 at 5:31 AM Balázs Lengyel <balazs.lengyel@ericsson.com> wrote: > Hello, > > Putting this information on individual schema nodes can be a problem if a > module uses imported items a lot. We have modules with 100+ schema nodes > that use an import, while there are only 7 modules imported. Adding the > statement (mandatory/optional to implement) 100 times would be a lot of > text. I also doubt that people will check all 100 places. > > IMHO alternatives a) or b) are feasible. (I like a) the best) > This is a strawman -- nobody suggested duplicating the same text over and over in data nodes. The same issue exists with the reference-stmt. We don't require (or encourage) people to place a reference to an external RFC on every leaf. The same judgement can be used here. > Regards Balazs > > Andy > > > *From:* netmod <netmod-bounces@ietf.org> *On Behalf Of *Andy Bierman > *Sent:* 2020. március 3., kedd 17:14 > *To:* Benoit Claise <bclaise@cisco.com> > *Cc:* NETMOD WG <netmod@ietf.org> > *Subject:* Re: [netmod] Text in import to indicate whether a module is > needed as import-only or as implemented > > > > > > > > On Tue, Mar 3, 2020 at 12:45 AM Benoit Claise <bclaise@cisco.com> wrote: > > Hi, > > > > > > On Mon, Mar 2, 2020 at 10:23 AM Ladislav Lhotka <lhotka@nic.cz> wrote: > > On Mon, 2020-03-02 at 09:52 -0800, Andy Bierman wrote: > > > > > > On Mon, Mar 2, 2020 at 8:57 AM Benoit Claise <bclaise@cisco.com> wrote: > > > Sorry to resurrect this old email thread. > > > To me, it's an important piece of information to know that > ietf-netconf-acm > > > is optional to implement. > > > > > > It seems that we have 3 potential places where to insert this > information > > > 1. The associated document. We could and should insert it into the RFC > text. > > > Drawback: Somehow the YANG module is looked at independently of the > > > associated document > > > 2. import-stmt: people on the list apparently don't like this > > > 3. module description? What harm would it do if the description could > > > contain this info? > > > > > > > > > > IMO it makes more sense to summarize the imported modules that need to be > > implemented > > and not mention the ones that are not required. The module > description-stmt > > is better > > than each import. (YANG 1.1 allows the same module to be imported > multiple > > times). > > Modules that have to be implemented can be imported only once. Adding this > information to the import statement for such modules is IMO more effective > than > having it in the module description. I don't get how it could become a > problem. > > > > I do not think this info helps very much. It is duplicate info. > > It should be in the description-stmts for the objects defined in the > module. > > Well, I had in mind the module description > The "description-stmts for the objects defined in the module" is yet > another place. > > > > > > The object descriptions are the correct level of granularity to be useful. > > A boolean statement wrt/ module implementation is required vs not required > is not very useful. > > Rarely is the entire module either fully required or nothing to implement > at all. > > > > IMO it is wrong to conflate the import-stmt with conformance requirements. > > It is merely a mechanism to bind local prefix usage to an external module. > > Text like "revision X or derived from X is required" is appropriate for > the import-stmt because > > it refers to the binding between prefix and imported module revision used. > > > > Consider how this extra documentation work scales to a big module like > ietf-bgp. > > There are multiple submodules, each with overlapping imports and each with > their own module header. > > > > > > Andy > > > > It is also self-evident (and defined in YANG) that if you augment some > external node > > you have to implement the augmented module. > > > > This is the classic definition of a CLR. > > > > Lada > > > > > > Trying to decompose the problem space .... > I believe it's common sense to include in the RFC text that > ietf-netconf-acm is optional to implement (to take the example in question > in > https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-11 > ) > Do we agree that this information should also be contained somewhere, > somehow in the YANG module? I would say: yes > > If yes, what are the options? > I agree with Juergen (in a reply in this email thread): ideally a tooling > answer would be better. This will take some time. So what do we do now? > 3 options: > a. import description (description-stmt in import-stmt) > > module ietf-system-capabilities { > > yang-version 1.1; > > namespace > > "urn:ietf:params:xml:ns:yang:ietf-system-capabilities"; > > prefix sysc; > > > > import ietf-netconf-acm > > { prefix nacm; } > > description "*ietf-netconf-acm is optional to implement*."; > > } > > > b. module description (description-stmt in meta-stmts in > module-stmt/submodule-stmt) > > module ietf-system-capabilities { > > yang-version 1.1; > > namespace > > "urn:ietf:params:xml:ns:yang:ietf-system-capabilities"; > > prefix sysc; > > > > import ietf-netconf-acm { prefix nacm; } > > > > import ietf-yang-library { > > prefix yanglib; > > description "Revision 2019-01-04 or a > > revision derived from it is REQUIRED."; > > } > > > > organization > > "IETF NETCONF (Network Configuration) Working Group"; > > contact > > "WG Web: <https://datatracker.ietf.org/wg/netconf/> > > WG List: <mailto:netconf@ietf.org> <netconf@ietf.org> > > > > Editor: Balazs Lengyel > > <mailto:balazs.lengyel@ericsson.com> <balazs.lengyel@ericsson.com>"; > > description > > "This module specifies a module intended to contain system > > capabilities. System capabilities may include capabilities of a > > NETCONF or RESTCONF server or a notification publisher. > > > > ... > > > > > > *ietf-netconf-acm is optional to implement."* > > c. description-stmts for the objects defined in the module > > leaf node-selector { > > type nacm:node-instance-identifier; > > description > > "Selects the data nodes for which capabilities are > > specified. The special value '/' denotes all data nodes > > in the datastore. *ietf-netconf-acm is optional to implement.*"; > > } > > > c. looks weird to me, and might need repetitions in different YANG > objects. In the end, as an implementer, I only care to understand whether I > need to implement "ietf-netconf-acm" as a prequesite to implement > ietf-system-capabilities. > > Between a. and b., I have no strong preferences. > However, a. seems to be the logical place to me. > > Regards, Benoit > > > > > > > Regards, Benoit > > > > > > > Andy > > > > > > > > > > On Wed, Jan 8, 2020 at 5:44 AM Ladislav Lhotka <lhotka@nic.cz> > wrote: > > > > > On Wed, 2020-01-08 at 04:49 -0800, Andy Bierman wrote: > > > > > > > > > > > > On Wed, Jan 8, 2020 at 1:11 AM Ladislav Lhotka <lhotka@nic.cz> > wrote: > > > > > > > On Tue, 2020-01-07 at 14:29 +0000, Balázs Lengyel wrote: > > > > > > > > If that is the consensus, I can remove the description > statements, > > > > > no big > > > > > > > > deal. (I actually like the statements, but they are not > important > > > > > for this > > > > > > > > draft) > > > > > > > > > > > > > > Of course, it is not that important, but I don't see how this > > > > > information > > > > > > > could > > > > > > > be harmful, if it is included with the import. In my view, it > is not > > > > > meant > > > > > > > as a > > > > > > > conformance requirement but just an info from the module author > > > > > about the > > > > > > > meaning of the import statement. > > > > > > > > > > > > > > > > > > > It adds a lot of extra work but more importantly the import-stmt > is > > > > > the wrong > > > > > > place > > > > > > > > > > What work do you mean? I thought that it would be just info for > > > > > potential > > > > > developers (or their managers) that implementing the module > requires > > > > > implementing other modules and functionality - or not. > > > > > > > > > > > > > > > > > > > > > > It is duplication because the individual data-def statements should > have > > > > any notes > > > > about implementation requirements. The duplication may even be wrong. > > > > E.g., in the module it says NACM is not required, but what if some > objects > > > > have NACM requirements listed in the Security Considerations section? > > > > That is the RFC section to discuss NACM requirements. > > > > > > > > > > > > > For example, if a module imports ietf-netconf-nacm only for using > "node- > > > > > instance-identifier" type, it is relatively uninteresting. > Otherwise, > > > > > implementation of the module may just be out of question. > > > > > > > > > > > > > > > > to document such a complex and unrelated issue as server > conformance > > > > > > requirements. > > > > > > > > > > > > > > > > > > > The root of this problem (and design flaw of YANG, IMO) is that > > > > > import is > > > > > > > "overloaded" with two different purposes, one of which > effectively > > > > > requires > > > > > > > that > > > > > > > the imported module be also implemented, while the other > doesn't. > > > > > > > > > > > > > > > > > > > The import-stmt is only used to map a local prefix to an external > > > > > module. > > > > > > > > > > But one thing is using a prefix for accessing top-level types and > > > > > groupings > > > > > (i.e. stuff in YANG modules), and another thing is accessing schema > > > > > nodes, which > > > > > have to be present in the schema tree. In complicated data models, > it is > > > > > not > > > > > exactly easy to figure out all these dependencies. > > > > > > > > > > > > > > > > > > I do not agree these are different things. > > > > In both cases the prefix is used to determine the imported module > that > > > > contains the identifier. > > > > > > > > > > > > > So maybe what is really overloaded are the namespace prefixes: > they are > > > > > used for > > > > > addressing YANG modules, schema nodes and instances (in XPath). > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > This proposal to add conformance info the the import-stmt would > > > > > overload it > > > > > > with > > > > > > another purpose. > > > > > > > > > > > > Not even a typedef is easy to classify (e.g., leafref requires > > > > > implementation > > > > > > of a data node). > > > > > > I certainly agree that YANG conformance is poorly specified, > poorly > > > > > > understood, and > > > > > > in real need of improvement. Likewise, the import-stmt is also > in need > > > > > of some > > > > > > improvement > > > > > > since import-by-exact-revision is (and has always been) poorly > > > > > designed. > > > > > > > > > > > > > > > > > > > Lada > > > > > > > > > > > > > > > Balazs > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Martin Bjorklund <mbj@tail-f.com> > > > > > > > > Sent: Tuesday, January 7, 2020 2:38 PM > > > > > > > > To: Balázs Lengyel <balazs.lengyel@ericsson.com> > > > > > > > > Cc: andy@yumaworks.com; lhotka@nic.cz; netmod@ietf.org > > > > > > > > Subject: Re: [netmod] Text in import to indicate whether a > module > > > > > is > > > > > > > needed as > > > > > > > > import-only or as implemented > > > > > > > > > > > > > > > > Hi > > > > > > > > > > > > > > > > I agree w/ Andy and others that we should not add this to the > > > > > import's > > > > > > > > description. I don't think this kind of conformance text > belongs > > > > > to the > > > > > > > > import's description. If you think it is important to state > this, > > > > > the > > > > > > > best > > > > > > > > place is probably as plain text in the document itself. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > Balázs Lengyel <balazs.lengyel=40ericsson.com@dmarc.ietf.org > > > > > > > wrote: > > > > > > > > > As a draft author who was asked to add text about the > imports > > > > > IMHO > > > > > > > > > > > > > > > > > > * it would be easy for me to remove the description from > the > > > > > import. > > > > > > > > > Actually I really just want to know what is acceptable to > the > > > > > group, so > > > > > > > I > > > > > > > > > can proceed > > > > > > > > > * I also think that adding this text is in most cases > easy and > > > > > it does > > > > > > > not > > > > > > > > > need updates later. > > > > > > > > > * The rules in some cases might not be trivial. > > > > > > > > > > > > > > > > > > * Imported YAMs need to be implemented if > > > > > > > > > > > > > > > > > > * Imported parts are included in Xpath (augment, when, > must, > > > > > require- > > > > > > > > > instance) > > > > > > > > > > > > > > > > > > * Imported YAMs do not need to be implemented if only the > > > > > following > > > > > > > are > > > > > > > > > used > > > > > > > > > > > > > > > > > > * Types > > > > > > > > > * Features > > > > > > > > > * extensions > > > > > > > > > > > > > > > > > > * Ambiguous if > > > > > > > > > > > > > > > > > > * groupings are used > > > > > > > > > * if the dependency is not formally defined by YANG, but > > > > > functionally > > > > > > > > > needed. (E.g. notification-capabilities does not formally > need > > > > > YANG- > > > > > > > > > Push > > > > > > > to > > > > > > > > > be implemented, however there is no sense in defining > > > > > capabilities if > > > > > > > YANG- > > > > > > > > > Push is itself not implemented.) > > > > > > > > > * deviation ? > > > > > > > > > * other cases ? > > > > > > > > > > > > > > > > > > Regards Balazs > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: netmod <netmod-bounces@ietf.org> On Behalf Of Andy > Bierman > > > > > > > > > Sent: 2019. december 19., csütörtök 17:23 > > > > > > > > > To: Ladislav Lhotka <lhotka@nic.cz> > > > > > > > > > Cc: NetMod WG <netmod@ietf.org> > > > > > > > > > Subject: Re: [netmod] Text in import to indicate whether a > > > > > module is > > > > > > > > > needed as import-only or as implemented > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Dec 19, 2019 at 8:00 AM Ladislav Lhotka < > lhotka@nic.cz > > > > > <mailto: > <%0b>> > > > > > > > lhotka@nic.cz> > wrote: > > > > > > > > > > > > > > > > > > On Thu, 2019-12-19 at 07:52 +0000, Schönwälder, Jürgen > wrote: > > > > > > > > > > On Thu, Dec 19, 2019 at 08:23:27AM +0100, Ladislav Lhotka > > > > > wrote: > > > > > > > > > > > I don't see how YANG syntax defines this. If a module > > > > > imports > > > > > > > > > > > ietf-netconf- acm, it could be because > > > > > > > > > > > > > > > > > > > > > > - it just uses a typedef, such as "node-instance- > > > > > identifier", and > > > > > > > then > > > > > > > > > > > ietf-netconf-acm needn't be implemented (but can be), > > > > > > > > > > > > > > > > > > > > > > or > > > > > > > > > > > > > > > > > > > > > > - it augments ietf-netconf-acm, which makes sense only > if > > > > > the latter > > > > > > > > > > > module is implemented. > > > > > > > > > > > > > > > > > > > > > > It it the YANG library that specifies whether a module > is > > > > > > > > > > > implemented or not, but the "import" statement itself > > > > > doesn't tell > > > > > > > you > > > > > > > > > > > anything. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Can we not assume that an implementor will figure out the > > > > > difference? > > > > > > > > > > > > > > > > > > An implementor should be able to figure it out, but other > > > > > potential > > > > > > > > > module users may not. For example, if somebody is > evaluating > > > > > whether > > > > > > > > > to use a module for their device or not, it is important > to know > > > > > that > > > > > > > > > NACM has to be implemented (or not). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You seem to be talking about a new conformance > documentation > > > > > procedure > > > > > > > > > > > > > > > > > > that attempts to solve the problem "to use modules A, B, > and C > > > > > > > > > together > > > > > > > > > > > > > > > > > > to achieve some functionality X, all these conditions need > to be > > > > > met".. > > > > > > > > > > > > > > > > > > (Sounds more like a problem for YANG Packages to solve) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > IMO this is a much harder problem than something that can > be > > > > > solved > > > > > > > > > > > > > > > > > > with extra description-stmt text. The writer is likely to > get it > > > > > wrong > > > > > > > > > or not > > > > > > > > > > > > > > > > > > keep it up to date, so a tool to analyze the file seems > like a > > > > > better > > > > > > > > > solution. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Lada > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Or someone writes a pyang plugin to determine from the > schema > > > > > tree > > > > > > > > > > the kind of imports there are (for a given set of > features). > > > > > > > > > > > > > > > > > > > > /js > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Ladislav Lhotka > > > > > > > > > Head, CZ.NIC Labs > > > > > > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > netmod mailing list > > > > > > > > > netmod@ietf.org <mailto:netmod@ietf.org> > > > > > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > > > > -- > > > > > Ladislav Lhotka > > > > > Head, CZ.NIC Labs > > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > > _______________________________________________ > > > > > netmod mailing list > > > > > netmod@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > >
- Re: [netmod] Text in import to indicate whether a… Balázs Lengyel
- Re: [netmod] Text in import to indicate whether a… Martin Bjorklund
- [netmod] Text in import to indicate whether a mod… Balázs Lengyel
- Re: [netmod] Text in import to indicate whether a… Andy Bierman
- Re: [netmod] Text in import to indicate whether a… Ladislav Lhotka
- Re: [netmod] Text in import to indicate whether a… Schönwälder
- Re: [netmod] Text in import to indicate whether a… Ladislav Lhotka
- Re: [netmod] Text in import to indicate whether a… Andy Bierman
- Re: [netmod] Text in import to indicate whether a… Balázs Lengyel
- Re: [netmod] Text in import to indicate whether a… Ladislav Lhotka
- Re: [netmod] Text in import to indicate whether a… Andy Bierman
- Re: [netmod] Text in import to indicate whether a… Ladislav Lhotka
- Re: [netmod] Text in import to indicate whether a… Andy Bierman
- Re: [netmod] Text in import to indicate whether a… Benoit Claise
- Re: [netmod] Text in import to indicate whether a… Andy Bierman
- Re: [netmod] Text in import to indicate whether a… Ladislav Lhotka
- Re: [netmod] Text in import to indicate whether a… Andy Bierman
- Re: [netmod] Text in import to indicate whether a… Schönwälder, Jürgen
- Re: [netmod] Text in import to indicate whether a… Benoit Claise
- Re: [netmod] Text in import to indicate whether a… Andy Bierman
- Re: [netmod] Text in import to indicate whether a… Balázs Lengyel
- Re: [netmod] Text in import to indicate whether a… Andy Bierman
- Re: [netmod] Text in import to indicate whether a… Balázs Lengyel
- Re: [netmod] Text in import to indicate whether a… Andy Bierman