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

From: Balázs Lengyel <[email-masked]>
Date: Fri, 3 Jan 2020 09:12:29 +0000

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 <[email-masked]> On Behalf Of Andy Bierman
Sent: 2019. december 19., csütörtök 17:23
To: Ladislav Lhotka <[email-masked]>
Cc: NetMod WG <[email-masked]>
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 <[email-masked] <mailto:[email-masked]> > 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
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 07 Jan 2020 14:38:18 +0100 (CET)

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

---

From: Balázs Lengyel <[email-masked]>
Date: Tue, 7 Jan 2020 14:29:56 +0000

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

-----Original Message-----
From: Martin Bjorklund <[email-masked]> 
Sent: Tuesday, January 7, 2020 2:38 PM
To: Balázs Lengyel <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
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=[email-masked]> wrote:
> > > I don't see how YANG syntax defines this. If a module imports 
> > > ietf-netconf- acm, it could be because
> > > 
> > > It it the YANG library that specifies whether a module is 
> > > implemented or not, but the "import" statement itself doesn't tell you anything.
> > > 
> > 
> 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).
> 
>  
> 
> to achieve some functionality X, all these conditions need to be met"..
> 
> > 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

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 08 Jan 2020 10:11:49 +0100

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.

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.

Lada

> 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
> 
> 
> > *	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
> > *	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: Andy Bierman <[email-masked]>
Date: Wed, 8 Jan 2020 04:49:52 -0800

> meaning of the import statement.
It adds a lot of extra work but more importantly the import-stmt is the
wrong place
to document such a complex and unrelated issue as server conformance
requirements.

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

Andy

> > Subject: Re: [netmod] Text in import to indicate whether a module is
> needed as
> > import-only or as implemented
> >
> > Hi
> >
> > > *   I also think that adding this text is in most cases easy and it
> does not
> > > need updates later.
> > > *   Imported YAMs do not need to be implemented if only the following
> are
> > > used
> > >
> > > *   Types
> > > *   Features
> > > *   extensions
> > >
> > > *   Ambiguous if
> > >
> > > *   groupings are used
> > > On Thu, Dec 19, 2019 at 8:00 AM Ladislav Lhotka <[email-masked]
> <mailto:
> > > [email-masked]> > wrote:
> > >
> > > > > implemented or not, but the "import" statement itself doesn't tell
> you
> > > > > anything.
> > > > >
> > > >

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 08 Jan 2020 14:43:52 +0100

On Wed, 2020-01-08 at 04:49 -0800, Andy Bierman wrote:
> 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. 

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.

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

So maybe what is really overloaded are the namespace prefixes: they are used for
addressing YANG modules, schema nodes and instances (in XPath). 

Lada

> Not even a typedef is easy to classify  (e.g., leafref requires implementation
> of a data node).
> in real need of improvement. Likewise, the import-stmt is also in need of some
> improvement
> > > > *   I also think that adding this text is in most cases easy and it does
> > not
> > > > need updates later.
> > > > needed. (E.g. notification-capabilities does not formally need YANG-
> > > > Push 
> > to
> > > > needed as import-only or as implemented
> > > > 
> > > >  
> > > > 
> > > >  
> > > > 
> > > >  
> > > >

---

From: Andy Bierman <[email-masked]>
Date: Wed, 8 Jan 2020 10:41:20 -0800

On Wed, Jan 8, 2020 at 5:44 AM Ladislav Lhotka <[email-masked]> wrote:

> > > 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
> wrong

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.

> > > "overloaded" with two different purposes, one of which effectively
> requires
> > > that
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

Andy

> the
> > > > import's description.  If you think it is important to state this,
> the
> > > best
> > > > > Actually I really just want to know what is acceptable to the
> group, so
> > > I
> > > > > can proceed
> > > > > *   Imported parts are included in Xpath (augment, when, must,
> require-
> > > > > instance)
> > > > >
> > > > > be implemented, however there is no sense in defining capabilities
> if
> > > YANG-
> > > > > > > - it just uses a typedef, such as "node-instance-identifier",
> and
> > > then
> > > > > 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
> > > > >
> > > > >
> > > > >
> > > > >
> [email-masked]