Re: [netmod] Text in import to indicate whether a module is needed as import-only or as implemented

Andy Bierman <andy@yumaworks.com> Tue, 03 March 2020 16:14 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 7340C3A22EE for <netmod@ietfa.amsl.com>; Tue, 3 Mar 2020 08:14:14 -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 HdYQEYLzkDSm for <netmod@ietfa.amsl.com>; Tue, 3 Mar 2020 08:14:10 -0800 (PST)
Received: from mail-yw1-xc32.google.com (mail-yw1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) (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 633133A2309 for <netmod@ietf.org>; Tue, 3 Mar 2020 08:14:10 -0800 (PST)
Received: by mail-yw1-xc32.google.com with SMTP id y62so3779467ywd.13 for <netmod@ietf.org>; Tue, 03 Mar 2020 08:14:10 -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=WETmQnAc2yYk2dzwsaugZZ3v0usSIOsZF8tocfn1JiA=; b=r3gF9TQIU4YJwseq7RUACPKaTzby34etUzlOKNdNZjhDvlXX4hChzgzdleoBCiNyLR MgesBZfxeDBWNDMp53cif3CfuBkQ5YKUszaK8qgky33iNdNktfkJdHvVH3hawoZ/k5YP DOL9vQiGV0Ta/CMQpfURkCIFbw+L9ExCzxSwQbkFEDsJ6jH5s8zpr8gn6551P93+duI7 HaWK+/jvHxOOB/c6+Lsv0uLtigIlZFQSiZhFypnkbIfnb61opuXKdQCGBaGov/laH9Hx 3Pc4VYioQKrE8bShK5L2cAba5bSDrWEmVLw4Gykhfe86qtxhG/kE3Pui3k8X+uWcLOgG QQYg==
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=WETmQnAc2yYk2dzwsaugZZ3v0usSIOsZF8tocfn1JiA=; b=rdEkM5uu77s+AQS79vNh09xh2x52AAQSrAm2SbS1VsK+ImhZLT8ZLxLzbffZ1/mQ+p I4/SWAvfZnLoRVhF+ZdWO/ENq8i0NLup3TcYzF4yuLXVxHwoPGWAjDua1Jw9FByfa4pW dFRhRYFv0WJaBEjl8MmsNSxtTiZfaTPLhnWYS1Y4L0RkK4r22ubPeEOeVqK4ovkVPbJx eYBKFQAOjiHctuDMkWCKrjee2T+K6hfrqteXrm/yocBj4VfGYCdn9MWO2V3oeUPkqkwF EHJVURsBmeuKtvLqV/mBaYMNxZvz19wC3CSzvtxkJgTGNzhDTofBybGVie5WL5vcyWY/ +jBA==
X-Gm-Message-State: ANhLgQ1CLLru+PzdVoowhLni8tD6+JCzVQwjmbyetkWwKlmOb9ak2QZl HNTJl1D9iAhmHwNT9g2RZJVDZ61RvvgV1NhvC3lsnw==
X-Google-Smtp-Source: =?utf-8?q?ADFU+vvu0HxgNFgWOQWNCRKvGGbfIfWZYaJ9CoFvRMU4?= =?utf-8?q?agZNGT2VCpFXqPMMCuweNMfu8IidjNy9fN17xgNqpwjK8Mk=3D?=
X-Received: by 2002:a81:1155:: with SMTP id 82mr4949779ywr.262.1583252049363; Tue, 03 Mar 2020 08:14:09 -0800 (PST)
MIME-Version: 1.0
References: <d3520549f06107de8939af24268f56f56683fbb0.camel@nic.cz> <CABCOCHRFQrXgGKB10B9MXbKa2vMfaY3eWaj5Sp4W0DPQ0F-pGQ@mail.gmail.com> =?utf-8?q?=3CVI1PR07MB40472B4BEFB581AEE4F7C158F0230=40VI1PR07MB4047=2Eeurpr?= =?utf-8?q?d07=2Eprod=2Eoutlook=2Ecom=3E?= =?utf-8?q?=3C20200107=2E143818=2E1928135118621633911=2Embj=40tail-f=2Ecom?= =?utf-8?q?=3E_=3CVI1PR07MB404773908BCA102EFBB6EE46F03F0=40VI1PR07MB4047=2Ee?= =?utf-8?q?urprd07=2Eprod=2Eoutlook=2Ecom=3E?= <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>
In-Reply-To: <c58da422-e0b0-75dd-0d94-96fd1ae12007@cisco.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Tue, 3 Mar 2020 08:13:58 -0800
Message-ID: <CABCOCHRJvVF7NNyyTupYq39DmJN=1xKwmQxMfzF0T-ss0hFM8g@mail.gmail.com>
To: Benoit Claise <bclaise@cisco.com>
Cc: Ladislav Lhotka <lhotka@nic.cz>, NETMOD WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fe24df059ff5976c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/VMMbHg3PEH3FkZxvSBQQBH-m9yc>
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: Tue, 03 Mar 2020 16:14:15 -0000

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>"m>";
>   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:
>> > > > > > > > > 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
>>
>>
>