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 16:34 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 9AEDD3A17E1 for <netmod@ietfa.amsl.com>; Thu, 5 Mar 2020 08:34:42 -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 ukIE0BiqhI3Z for <netmod@ietfa.amsl.com>; Thu, 5 Mar 2020 08:34:38 -0800 (PST)
Received: from mail-yw1-xc2a.google.com (mail-yw1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (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 AF6A13A17E0 for <netmod@ietf.org>; Thu, 5 Mar 2020 08:34:38 -0800 (PST)
Received: by mail-yw1-xc2a.google.com with SMTP id 10so6170528ywv.5 for <netmod@ietf.org>; Thu, 05 Mar 2020 08:34:38 -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=rlAZezU4IRTk+sT3cr3AeEqLhgN2nYuWUW0ArxZcoX0=; b=lK37GNVHuSW1zWyeAuqx82LYNi82nRsrniZxtl0MPEOyd5XNTn+2uOHEoouD845IXq YDOpxXYHjtxGavyMioEc2ELjkHGTdyHeycoKdMIZn2j1Th8tfMNfJ3v8KtNQLj7pAZmT M9rkF2n8k6WCSPuW5MgmW9oIxgSNGKpAqdvNN/zRSKhU8jl14sIWfwBiJvVWXNtcNX+3 EwdqVVACfc4L1OoTUwULoaWy/8MecM6Yg8dSJHRCOn9K8CjPkhYNwZNIO+FA2mTPEMeM SjEJc7tyx4oKhxxbwGlQOo/dpy0GclIFRS9ln0wCJP/kaHG+UsMQDZ65QEbzHrdzFGN2 b6dQ==
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=rlAZezU4IRTk+sT3cr3AeEqLhgN2nYuWUW0ArxZcoX0=; b=ofbM6kCYzWiUj5txmVQEEBi1PrcyJ0ytA2pV5IWjlt2GkNd/7cAS2bzUMIXC46hEcx NfmrcoHerRxgckYAWpRIKSqeOzADmq25AdRHAnK1GDjeKjvuLH6JY6W89L+dVpcVM7HK r7s6LThXivFjqKN6WQqJ2ECIPXt2lJvPd/J8c3Dz++jd+j0oD/Ivv0ZGztHD5L7bxD8S mUh423F5i7hit9PZk2Mqzr1NO1NEt0PZBiOqZylP0ld7+KUuFHXruJhQtA1RZqyqOLxs COcP+JYtOdWLxufwz1Vp3k0v0ZpJ5pOquSeBfM0pS9aqCxHYQSyZx3U9qZwBpbh/snip TWkQ==
X-Gm-Message-State: ANhLgQ3dfBsBVdCorPRy73y/9Y9MlNuakmSvMZMcg/9rYXuSyiO/axI0 HGz4BFfCgorroKI58oAtax39cPAjNOLaZRBEnsEj2A==
X-Google-Smtp-Source: =?utf-8?q?ADFU+vuRkI/3CDNrOs7dhXNNO2db0eE2n4o48iIQJ2xQ?= =?utf-8?q?Cj4WEb47flk6EP3oWC5n0TPcE3ekakYYm+YT57XTrOeMgq4=3D?=
X-Received: by 2002:a81:bb4a:: with SMTP id a10mr9451529ywl.87.1583426077450; Thu, 05 Mar 2020 08:34:37 -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> =?utf-8?q?=3CCABCOCHRJvVF7NNyyTupYq39DmJN=3D1xKwmQxMfzF0T-ss0hFM8g=40mail?= =?utf-8?q?=2Egmail=2Ecom=3E_=3CDB7PR07MB4011F6397EDC5CE7723880F5F0E20=40DB7?= =?utf-8?q?PR07MB4011=2Eeurprd07=2Eprod=2Eoutlook=2Ecom=3E?= =?utf-8?q?=3CCABCOCHRARyZogky8STdmJSJZNOoKNERwNda4GS=3DDVp3K7kRxHA=40mail?= =?utf-8?q?=2Egmail=2Ecom=3E_=3CDB7PR07MB4011430C71ECD5EA62A78BF5F0E20=40DB7?= =?utf-8?q?PR07MB4011=2Eeurprd07=2Eprod=2Eoutlook=2Ecom=3E?=
In-Reply-To: =?utf-8?q?=3CDB7PR07MB4011430C71ECD5EA62A78BF5F0E20=40DB7PR07MB?= =?utf-8?q?4011=2Eeurprd07=2Eprod=2Eoutlook=2Ecom=3E?=
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 5 Mar 2020 08:34:26 -0800
Message-ID: <CABCOCHQx-XWD+v-waNkO8SpuEM79wuVCXJU+GCiwgbn5DF7fug@mail.gmail.com>
To: =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= <balazs.lengyel@ericsson.com>
Cc: Benoit Claise <bclaise@cisco.com>, NETMOD WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000dffb2005a01e1c1b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/vgsKvcCouSP3y6THBLmvh0y6Ftg>
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 16:34:43 -0000

On Thu, Mar 5, 2020 at 7:52 AM Balázs Lengyel <balazs.lengyel@ericsson.com>
wrote:

>
>
>
>
> *From:* Andy Bierman <andy@yumaworks.com>
> *Sent:* 2020. március 5., csütörtök 16:43
> *To:* Balázs Lengyel <balazs.lengyel@ericsson.com>
> *Cc:* Benoit Claise <bclaise@cisco.com>om>; 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, 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.
>
>
>
> Andy
>
>  BALAZS2: If the first 50 uses of an import don’t need an implemented
> import-module  but the 51stdoes, then finding this will be difficult,
> unless we formalize it somehow e.g. with a new statement, extension,
> standard text, whatever.
>


I am unclear on the procedures for this new procedure to be added to the
documentation of all YANG modules.

1) What does "implement" mean?
    Even in this case, implementation of a typedef is required.
    So does "implement" mean "implement data nodes"?
   How is "implement a leafref typedef" classified?

2) What is the module granularity?
   Is the same information repeated in each submodule?
   Does a submodule header document the implementation requirements
   just for that submodule?

3) What is the object granularity?
    Does the author search for every occurrence of the prefix and then
write a
    summary for that object? Does the author just stop when implementation
of
    a data node is required (making the boolean statement true)


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>"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:
> <%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
>
>
>
>