On Wed, Jan 8, 2020 at 5:44 AM Ladislav Lhotka <lho...@nic.cz
<mailto:lho...@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 <lho...@nic.cz
<mailto:lho...@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 <m...@tail-f.com <mailto:m...@tail-f.com>>
> > > Sent: Tuesday, January 7, 2020 2:38 PM
> > > To: Balázs Lengyel <balazs.leng...@ericsson.com
<mailto:balazs.leng...@ericsson.com>>
> > > Cc: a...@yumaworks.com <mailto:a...@yumaworks.com>;
lho...@nic.cz <mailto:lho...@nic.cz>; netmod@ietf.org
<mailto: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....@dmarc.ietf.org
<mailto:40ericsson....@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-boun...@ietf.org
<mailto:netmod-boun...@ietf.org>> On Behalf Of Andy Bierman
> > > > Sent: 2019. december 19., csütörtök 17:23
> > > > To: Ladislav Lhotka <lho...@nic.cz <mailto:lho...@nic.cz>>
> > > > Cc: NetMod WG <netmod@ietf.org <mailto: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
<lho...@nic.cz <mailto:lho...@nic.cz> <mailto:
> > > > lho...@nic.cz <mailto:lho...@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>
<mailto: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 <mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
