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

[Benoit Claise <[e-mail]>]

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?

Regards, Benoit
>
>
> On Wed, Jan 8, 2020 at 5:44 AM Ladislav Lhotka <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     On Wed, 2020-01-08 at 04:49 -0800, Andy Bierman wrote:
>     >
>     > On Wed, Jan 8, 2020 at 1:11 AM Ladislav Lhotka <[e-mail]
>     <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>>
>     > > > Sent: Tuesday, January 7, 2020 2:38 PM
>     > > > To: Balázs Lengyel <[e-mail]
>     <mailto:[e-mail]>>
>     > > > Cc: [e-mail] <mailto:[e-mail]>;
>     [e-mail] <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>
>     > > > 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=[e-mail]
>     <mailto:[e-mail]>> 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 <[e-mail]
>     <mailto:[e-mail]>> On Behalf Of Andy Bierman
>     > > > > Sent: 2019. december 19., csütörtök 17:23
>     > > > > To: Ladislav Lhotka <[e-mail] <mailto:[e-mail]>>
>     > > > > Cc: NetMod WG <[e-mail] <mailto:[e-mail]>>
>     > > > > 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
>     <[e-mail] <mailto:[e-mail]> <mailto:
>     > > > > [e-mail] <mailto:[e-mail]>> > 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
>     > > > > [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     > > > > https://www.ietf.org/mailman/listinfo/netmod
>     > > > >
>     -- 
>     Ladislav Lhotka
>     Head, CZ.NIC Labs
>     PGP Key ID: 0xB8F92B08A9F76C67
>
>     _______________________________________________
>     netmod mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/netmod
>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod