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

Andy Bierman <andy@yumaworks.com> Mon, 02 March 2020 17:52 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 284B73A0DA6 for <netmod@ietfa.amsl.com>; Mon, 2 Mar 2020 09:52:49 -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 EEtfneI6ub1v for <netmod@ietfa.amsl.com>; Mon, 2 Mar 2020 09:52:45 -0800 (PST)
Received: from mail-yw1-xc2f.google.com (mail-yw1-xc2f.google.com [IPv6:2607:f8b0:4864:20::c2f]) (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 AF8DA3A0DA8 for <netmod@ietf.org>; Mon, 2 Mar 2020 09:52:45 -0800 (PST)
Received: by mail-yw1-xc2f.google.com with SMTP id h6so594947ywc.8 for <netmod@ietf.org>; Mon, 02 Mar 2020 09:52:45 -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=FLEQlWUYWjk+uoCzmSzoNjpq1g1W1YTFYmkeykZK08s=; b=o3/PLbIeMs61z1ZLll8BMvFI3/be/XLltBHsLMSUFZ1rW9Kny/I/alaMBM2CIieqbB PJKxQO73egQdkV6OtfEhwz3MFWbxdHI1RfHUxBt3vIWp9rUApq4proFLZkjrYJGOH42U wJ2Or/UFIXuo7v1v5UCw1Ew2yRn2r7g60ZGamJtgRLYmfut03ZJ98HKKl6A//SCStCrg HaAf+D2yMu2aMbUQJOKyAFOf0mb4WDqFxMJanv9r/UpWwYlju0sbJb+TvvxM0tQ19LPj obNfMiLsNsGosVbV/oKhjhEpPG9ADJZz2IY6MjNbhrd8eYjWFxUM/XjPrnli3pxKL5yr CyhA==
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=FLEQlWUYWjk+uoCzmSzoNjpq1g1W1YTFYmkeykZK08s=; b=LEqo7SVk6DsJr1zZZ+fYGq8vEDx5v9fjQiw4i+E1BMFBScMMCEKgBDbWhFxDOQAUQq TgqmAE/Xd8fSraBLxRervfjO/a+qGms0CO9C8hLBteJ1ik8Kw79v7eU5DJmCMgL+JXkP zHda0crar6ZH5BA8odhzLc9psX9hBTf2cxL4CEqmyR2Nfe8zDPBOf7anq49bb0Fd45vN DC4ZLAITmdKtQX8FZtkoqM43tO9G1iDOFImKb00XV2v0g7kGKgFK1W/4shyFtSitPU4X gpr50bk2MVyWWGPQW4Yiqq2Y094xPRGPSPM/q4vS5bBPqr93DXgnBuuEFax5fg0j+mQq +qHg==
X-Gm-Message-State: ANhLgQ3eyJvSpP6ucRWTmCfecwEZKija9rAytWSW4FFfrzSsKNoHxctj 2fRS5hCzcvlr6IGWdaLoo1G+F835CO6q3W5mJywWbzMF
X-Google-Smtp-Source: =?utf-8?q?ADFU+vs8c68+RpO1VhfqH7vc66N+uyDmXBVrdP3x1t50?= =?utf-8?q?CSPH/s1K3SjPV0bmndr+v7D16Zn3b04uaKgJZwFeTcTO93Q=3D?=
X-Received: by 2002:a81:3ccf:: with SMTP id j198mr501531ywa.83.1583171564617; Mon, 02 Mar 2020 09:52:44 -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>
In-Reply-To: <940da771-440b-6e42-eaf7-12bc5626441a@cisco.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Mon, 2 Mar 2020 09:52:33 -0800
Message-ID: <CABCOCHTcp=3cG1ed_3H-XtZdTUOj8O4hEq0sPjdf9d9B3yURsg@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="000000000000ba55c1059fe2da44"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Iw0yKnWB2rDqJrSR_KILj0uXunU>
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: Mon, 02 Mar 2020 17:52:49 -0000

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


> 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 listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>
>
>