Subject: [Netconf] review of draft-ietf-netconf-yang-library-03

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 5 Jan 2016 21:05:23 +0100

Hi,

here is my review of draft-ietf-netconf-yang-library-03.

a) p2: What are "YANG-based data abstractions"? Do we need this new
   term?  Why not simply say "a server that implements YANG data
   models"?

b) p3: I think it follows from the first bullet that it is illegal or
   impossible to implement two different revisions of a certain module
   within a single server.

c) p3: I suggest to delete sections titles 1.1.1 and 1.1.2 and 1.1.3 -
   I do not think they actually add value - its all about Terminology,
   so fits nicely into section 1.1.

d) p4: With c), I would turn 1.1.4 into 1.2 (since tree diagrams are
   not really terminology).

e) Should the YANG protocol identities be managed by IANA? We likely
   do not want to touch the YANG library for the next protocol to come
   and it might be confusing to have some identities registered in the
   YANG library model itself but others in different places. I know,
   technically this is all fine if we manage to properly keep track of
   things. An IANA managed module with these identity registrations
   might make that keeping track part a bit easier since there is a
   single place for all the IETF protocols transporting YANG data and
   using the YANG library. The obvious alternative is to allocate the
   identities in the protocol definitions but then we should do this
   for restconf already now. (The downside with this approach is that
   this identity registration in protocol documents likely causes a
   normative dependency on YANG library, which is not nice; the IANA
   option works around that.)

f) Should there be RFC editor instructions to replace the reference to
   draft-ietf-netconf-restconf in the restconf1.0 identity definition
   with the RESTCONF RFC number?  (BTW, I personally prefer to have a
   hyphen between the protocol name and the version number, i.e.,
   restconf-1.0 instead of restconf1.0.)

g) I prefer 'zero-length string' over 'empty string'.

h) Turn the leaf-list feature into a list feature { key name; leaf
  name } so that the feature list can be augmented in the future if
  ever needed?

i) Features can be defined in submodules, yet they are exposed in the
   YANG library as features of the enclosing module. Is this by
   intention? This should be technically OK but it is not a simple 1:1
   mapping of the definitions and hence my question whether this is by
   intention. And if it is by intention, perhaps clarify that this
   list includes all module features independently from where they are
   defined.

j) There are MUST statements concerning YANG 1.1 modules but there is
   not even a reference to YANG 1.1. I think a reference needs to be
   added to YANG 1.1 and it is likely a normative reference (which
   means YANG 1.1 and YANG Library have a circular dependency).

k) I am not sure I understand

             For YANG 1.0 modules, there SHOULD NOT be more than
             one module entry for a particular module name.";

   in the description of the 'implement' enum for the conformance
   leaf.

l) Is 'restricted-protocol' a good name for the leaf? It actually
   means 'not-supported-by-protocol' - is 'excluded-protocol' a better
   name? So essentially we have a set of modules and exceptions - if I
   have to add a protocol specific module, I need to add it to the
   global set and then setup proper exceptions. I assume the
   assumption here is that these are rare corner cases. Or should
   there also be the other alternative, an 'included-protocol' for
   adding things to the common set so both operations are available
   when needed?

m) Does it make sense to discuss somewhere a bit what a server is?
   There will be servers that support multiple protocols but use a
   common backend server. There will also be deployments where
   different protocols do not use a common backend; in this case the
   protocol servers would report rather different instantiations of
   the YANG library. Should there be text discussing this? Should
   there be advice that a YANG library retrieved via protocol X should
   not be assumed to work with protocol Y unless the module-set-id has
   been verified via protocol Y?

n) Should yang-protocol be turned into a list instead of a leaf-list
   to allow future augmentations?

o) Should we keep in mind that eventually modules are also configured
   into servers? That is, we are really defining the 'modules-state'
   tree and not the 'modules' tree (if we follow the foo and foo-state
   convention). [I expect to get grilled on this one.]

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 5 Jan 2016 19:44:40 -0800

>    term?  Why not simply say "a server that implements YANG data

OK

>    impossible to implement two different revisions of a certain module

No -- this text should be clarified.
It is meant to convey that the name "foo" cannot represent
2 different module names.  It does not mean there can
only be 1 entry in the module list for each module name.

>    so fits nicely into section 1.1.

OK

> OK

>    option works around that.)

IMO, IANA has enough to do. This is just another YANG identity.
Vendors and other SDOs should not need to register identityrefs with IANA
to use their protocol with the YANG library.

>    restconf-1.0 instead of restconf1.0.)

IMO the current strings are OK, but I don't care if the WG wants to change
them

> g) I prefer 'zero-length string' over 'empty string'.
OK

>   name } so that the feature list can be augmented in the future if
IMO this is overkill.  Other tables can use a leafref to this leaf-list
instead

>    list includes all module features independently from where they are

YANG features apply to the module.
Submodules do not partition the module namespace.
There can only be 1 "foo" feature in a the module and it doesn't matter
what submodule
contains it.  All submodules must be included into the main module in YANG
1.1
Any include statements in a submodule get ignored in YANG 1.1. The
confusion remains
in the YANG statements, but it is clarified in the draft.

>    means YANG 1.1 and YANG Library have a circular dependency).
maybe these MUST statements should be moved to YANG 1.1

>    in the description of the 'implement' enum for the conformance

This rule of "implement 1 revision" did not apply to YANG 1.0
so it is just a SHOULD NOT.  IMO it would be OK to move YANG
conformance text to YANG 1.1

>    adding things to the common set so both operations are available

If a YANG protocol uses the library at all, it is listed in yang-protocol.

If any module entry in the library does not apply to this protocol,
then the exception entry is needed in each unsupported module.

>    been verified via protocol Y?

IMO so -- this draft defines a library, not a server.

The module-set-id is an opaque string with no semantics at all.

IMO there is no reason to discuss implementation details.

>    to allow future augmentations?

no -- use a leafref to point to the leaf-list

>    convention). [I expect to get grilled on this one.]
that is why module is defined in a grouping that can be used in a
config=true container

> /js

Andy

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 06 Jan 2016 08:39:03 +0100

> only be 1 entry in the module list for each module name.

I don't understand:

1. Could there ever be two revisions of a module of the "implement"
   type?

2. If there are multiple revisions of a module of the "import" type,
   then I think it breaks the main purpose of having such modules in the
   list - if such a module is imported without revision, how can a
   client determine which revision the server actually uses?

...

> then the exception entry is needed in each unsupported module.

IMO yang-library shouldn't deal with this protocol stuff at all (and
bother IANA with it or whatever). If a module is protocol-specific, then
it shouldn't be included in yang-library information sent to other
protocols.

I believe it is also a security issue - why should clients of all
protocols know modules that are used by other protocols?

BTW, the term yang-library is perhaps somewhat unfortunate. Most people
would think it is a software library, and there are already several YANG
libraries being worked on.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 6 Jan 2016 10:16:11 -0800

> 1. Could there ever be two revisions of a module of the "implement"
This is not explicitly prohibited in YANG 1.0 and we cannot
make any rules now for YANG 1.0, just YANG 1.1.

>    client determine which revision the server actually uses?

The most recent revision listed in the library is used for YANG 1.1.

We cannot fix this issue for YANG 1.0, just YANG 1.1.

> I think people can read the description-stmts and know the difference
between a YANG library and a software library.

I don't agree it is a risk to list the protocols using YANG modules on the
device.

I don't mind removing all mention of protocols.
If a client attempts to use a module that is not supported
by a protocol, they will get an error back.
This is not really important data.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 6 Jan 2016 19:45:14 +0100

> On 06 Jan 2016, at 19:16, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

YANG 1.0 has had no yang-libary so there are no backward compatibility concerns affecting this document.

> The most recent revision listed in the library is used for YANG 1.1.

If module A imports C with revision YYYY-MM-DD, and B imports C without revision, then with this rule it wouldn't be possible for a server implementor to choose any revision less than YYYY-MM-DD to be used with B. I think this restriction isn't necessary. Listing module revisions that are imported always with revision is redundant.

I would propose that no more that one revision of each module be listed in yang-library, and those of "import" type will be used exclusively for resolving imports without revision. 

> I don't agree it is a risk to list the protocols using YANG modules on the device.
> 

I think this would be better. A similar error could be a consequence of NACM rules.

In any case, returning protocol-specific (and also user-specific) yang-library contents should IMO be possible.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 6 Jan 2016 10:52:11 -0800

On Wed, Jan 6, 2016 at 10:45 AM, Ladislav Lhotka <[email-masked]> wrote:

> If module A imports C with revision YYYY-MM-DD, and B imports C without
> revision, then with this rule it wouldn't be possible for a server
> implementor to choose any revision less than YYYY-MM-DD to be used with B.
> I think this restriction isn't necessary. Listing module revisions that are
> imported always with revision is redundant.
>
> I would propose that no more that one revision of each module be listed in
> yang-library, and those of "import" type will be used exclusively for
> resolving imports without revision.
>
>

The WG has already discussed this issue several times.
The YANG library lists all the YANG modules being used.
The client needs to be able to retrieve this list without
needing to parse the modules to find this information.

For YANG 1.1 the rules are clearly specified.

Andy

> In any case, returning protocol-specific (and also user-specific)
> yang-library contents should IMO be possible.
>
> Lada
>
> >
> >
> >
> >
> >
> > Lada
> >
> >
> > Andy
> >
> > >
> > >
> > >

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 6 Jan 2016 20:10:15 +0100

> On 06 Jan 2016, at 19:52, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

My position here is exactly the resolution accepted for Y45 (Y45-04), and I think we should stick to it.

> For YANG 1.1 the rules are clearly specified.

Exactly, and this is what 6020bis says:

   If a server implements a module A that imports a module C without
   specifying the revision date of module C, and the server does not
   implement C (e.g., if C only defines some typedefs), the server MUST
   list module C in the "/modules/module" list from "ietf-yang-library"
   [I-D.ietf-netconf-yang-library], and it MUST set the leaf
   "conformance" to "import" for this module.

It doesn't say that modules imported with revision must be listed.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 6 Jan 2016 11:16:52 -0800

On Wed, Jan 6, 2016 at 11:10 AM, Ladislav Lhotka <[email-masked]> wrote:

> > I would propose that no more that one revision of each module be listed
> in yang-library, and those of "import" type will be used exclusively for

This has nothing to do with Y45.
The YANG library lists all the YANG modules.
That is what is operationally useful.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 6 Jan 2016 20:34:47 +0100

> On 06 Jan 2016, at 20:16, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

Come on, so what is Y45 about? 6020bis explicitly refers to yang-library draft, so there is a strong connection.

> That is what is operationally useful.

How do you measure operational usefulness? All protocols could easily work even if modules imported with revision aren't listed.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 6 Jan 2016 11:49:11 -0800

On Wed, Jan 6, 2016 at 11:34 AM, Ladislav Lhotka <[email-masked]> wrote:

> > > If module A imports C with revision YYYY-MM-DD, and B imports C
> without revision, then with this rule it wouldn't be possible for a server
> > > I would propose that no more that one revision of each module be
> listed in yang-library, and those of "import" type will be used exclusively
> for resolving imports without revision.
> > >
> > >
> > >

Y45 does not have anything to say about how YANG modules should
be retrieved for parsing.

> How do you measure operational usefulness? All protocols could easily work
> even if modules imported with revision aren't listed.
>
>

It is useful to get the list of modules and then retrieve them.
This is much simpler than parsing YANG modules and retrieving
them as import-stmts are parsed. Your implementation strategy
requires the YANG compiler to be tightly coupled to the retrieval
of YANG modules.

Andy

> > > > >> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/
> >
> > > > >>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 6 Jan 2016 21:10:18 +0100

> On 06 Jan 2016, at 20:49, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

This is an implementation detail. The problem I have with listing imported modules multiple times is that it effectively annihilates the idea of Y45-04, which is that "import" modules in yang-library are used for resolving imports without revision.

An alternative would be to add another flag to yang-library ("default-revision"?) saying "this is the revision that is to be used for imports without revision".

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 8 Jan 2016 09:55:31 +0100

> to use their protocol with the YANG library.

The question was about how we organize the registration of protocol
identities within the IETF. It does not matter how busy IANA is. If
the direction is that it does not matter where these identities are
defined, why do we define the RESTCONF identity here instead of the
RESTCONF document (and thereby creating another dependency)?

> IMO the current strings are OK, but I don't care if the WG wants to change

What about the suggested RFC editor instruction? Or can we get rid of
the dependency altogether, see above?

> IMO this is overkill.  Other tables can use a leafref to this leaf-list

I am just asking to double check because I had to turn leaf-lists into
lists in other contexts...
 
> in the YANG statements, but it is clarified in the draft.

OK. So this seems to be by intention. I think it might help
implementors to indicate in the description statement that it does not
matter whether the features are defined in the module or any included
submodule, e.g.

             "List of YANG feature names from this module that are
              supported by the server, regardless whether they are
	      defined in the module or any included submodule.";
 
> maybe these MUST statements should be moved to YANG 1.1

Can you send a proposal what should be moved where to the NETMOD WG
list so we can track this and resolve this?

> IMO there is no reason to discuss implementation details.

I think it is important to define the 'scope' of the content of the
yang-library since the model allows to report information for
different protocols. Hence, client implementors may assume that the
yang library content received via protocol X also applies to protocol
Y. This may be true for some deployments but not in general. The more
I think about it, I tend to think that exposing information for
multiple protocols including differences is not a good idea. While
certain implementations use a common backend, this is just one out of
many implementation and deployment options. While the current module
may provide an efficiency gain for implementations with a common
backend (which is IMHO minor), I think it is way cleaner from the
client's perspective to simply get yang library content specific to
the protocol used to access the yang library data model.

> no -- use a leafref to point to the leaf-list

See above. I am just double checking that we are sure we will never
need additional information in place.

> that is why module is defined in a grouping that can be used in a

I expected a response like this. ;-)

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 08 Jan 2016 10:38:37 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> > > > without revision, then with this rule it wouldn't be possible for a
> > > > server implementor to choose any revision less than YYYY-MM-DD to be
> > > > used with B. I think this restriction isn't necessary. Listing module
> > > > revisions that are imported always with revision is redundant.
> > > >
> > > > listed in yang-library, and those of "import" type will be used
> > > > exclusively for resolving imports without revision.
> > > >
> > > >
> > > >
> > Come on, so what is Y45 about? 6020bis explicitly refers to
> > yang-library draft, so there is a strong connection.
> > 
> > 
> > How do you measure operational usefulness? All protocols could easily
> > work even if modules imported with revision aren't listed.
> > 
> > 
> > 
> This is an implementation detail. The problem I have with listing
> imported modules multiple times is that it effectively annihilates the
> idea of Y45-04, which is that "import" modules in yang-library are
> used for resolving imports without revision.

I agree with Lada.  It is clear that Y45-04 - for which we have
(rough?) consensus - does NOT "advertise" modules that are only
imported by revision.

However, I also agree w/ Andy that listing all modules is useful, b/c
a client can easily get the complete, consistent, set of modules that
the server implements.

This said, we have in the past discussed two solutions to this
problem.  One is what you propose below, to indicate the
default-revision with a new leaf, and the other is to make the latest
advertised revision be the (implicit) default revision.

I thought we agreed on the latter, but the current text makes this a
SHOULD.  So I think that either we make this a MUST (simpler), or add
a new leaf (more flexible, and possibly more clear).

> An alternative would be to add another flag to yang-library
> ("default-revision"?) saying "this is the revision that is to be used
> for imports without revision".

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 8 Jan 2016 11:00:13 +0100

> On 08 Jan 2016, at 10:38, Martin Bjorklund <[email-masked]> wrote:
> 

Yes, I agree.

> advertised revision be the (implicit) default revision.

Consider this situation: module A imports B without revision, so an implementor chooses rev. X of B. Then later module C needs to be added, but it imports B with revision Y > X. If revision Y appears in yang-library, then it forces module A to be upgraded to use revision Y, too. This may IMO be a problem. 

> a new leaf (more flexible, and possibly more clear).

I'd prefer the latter.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 08 Jan 2016 11:06:33 +0100 (CET)

> RESTCONF document (and thereby creating another dependency)?

I think the idea was to define a new module, let's say
iana-yang-protocols (in this document), which defines the identities
"yang-protocol", "netconf-1.0", "netconf-1.1", and "restconf-1.0".

This IANA policy would be "RFC Required" or maybe "Standards Action",
so vendors and other SDOs would NOT ask IANA to add to the registry.

The purpose of this registry would be to have a single definition for
IETF-defined YANG protocols.

Juergen, did I get this right?

> > IMO the current strings are OK, but I don't care if the WG wants to change

I prefer the hyphened version; "netconf-1.1" etc.

> the dependency altogether, see above?

We would just move the dependency to another module, defined in the
same document.  So the RFC editor instruction should be added in either
case.

> list so we can track this and resolve this?

There are two MUST statements in yang library related to YANG 1.1.

The first one is:

      For YANG 1.1 modules, there MUST NOT be more than one
      module entry with conformance 'implement' for a
      particular module name.

This one is not necessary, since 6020bis says:

    A server MUST NOT implement more than one revision of a module.

The second one is:

      For YANG 1.1 modules that use the import statement
      without specifying a revision date, the implemented
      revision of the imported module MUST be used.
      If the imported module is not implemented, then
      the most recent revision of the imported module
      used by the server (and contained in the module list)
      MUST be used.

The fate of this paragraph depends on whether we add a
'defualt-revision' leaf or not.

> the protocol used to access the yang library data model.

I don't have a strong opinion, but I do agree that it is easier for
the client to not have to do any filtering in order to figure out
which modules applies to the protocol in use.  Also, I don't think it
is a big deal for a multi-protocol server to have multiple
instantiations of this list.

> I expected a response like this. ;-)

It is even explicitly stated in the description of the grouping.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 8 Jan 2016 11:35:05 +0100

> Juergen, did I get this right?

Yes. Andy seems to think this is overkill (this is how I read his IANA
is to busy claim). My take is that an IANA module is a clean way of
achieving a loose coupling - even if it is some effort to set it up.

> It is even explicitly stated in the description of the grouping.

The question really was not about the grouping but more whether
/modules should be /modules-state but yeah I expected that people
won't get excited about such a proposal...

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 08 Jan 2016 12:22:11 +0100 (CET)

> achieving a loose coupling - even if it is some effort to set it up.

I agree with you, but I can also see that this might be an issue if
this pattern is common, which it seems to be.  If all modules that
want to provide extensibility via identities also define an IANA
module, it might be problem.  The nice thing w/ identities is that a
central registry isn't needed.

In this particular case, the "issue" is that there is no natural place to put
"netconf-1.0" and "netconf-1.1".

But then, if we agree to let each protocol have it's own instatiation
of /modules, the entire problem goes away.

> won't get excited about such a proposal...

Aha, ok.  I don't have a strong opinion on this one.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 12 Jan 2016 12:53:12 +0100 (CET)

> >> On 06 Jan 2016, at 20:49, Andy Bierman <[email-masked]> wrote:

[...]

> Consider this situation: module A imports B without revision, so an
> implementor chooses rev. X of B. Then later module C needs to be
> added, but it imports B with revision Y > X. If revision Y
> appears in yang-library, then it forces module A to be upgraded
> to use revision Y, too. This may IMO be a problem.  
> 
> > 

We need to decide what to do with this one.

The problem:

  If module A is imported w/o revision by another module that the
  server implements, the server MUST somehow inform the client which
  revision of A is used.

Solution 1:

  Reported implicitly - the server lists all revisions of A that it
  uses, and the most recent one is the one that is used to resolve
  import w/o revision.

Solution 2:

  Reported explicitly - the server lists all revisions of A that it
  uses, and the the one that is used to resolve import w/o revision is
  marked by setting a leaf "default-revision".

The current draft has 1 (but it needs to be clarified).  Lada prefers
2.  What do others think?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 Jan 2016 13:30:38 +0100

> The current draft has 1 (but it needs to be clarified).  Lada prefers

The assumption seems to be that all imports without a revision for a
certain module resolve to a particular revision of that module. Are we
all find with this?

    If yes, the question is whether the assumption holds that the
    revision of a module used to resolve imports without a revision is
    always the most recent revision.

        If yes, we do can hardwire this and we do not have to report this
	via an explicit leaf.

	If not, we need a leaf "default-revision".

    If not, then we have a bigger problem to solve.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 12 Jan 2016 14:09:54 +0100

> On 12 Jan 2016, at 13:30, Juergen Schoenwaelder <[email-masked]> wrote:
> 

For the sake of (ever) finishing YANG 1.1, I'd prefer to accept this limitation for now - it is IMO still an improvement compared to 1.0.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 12 Jan 2016 14:30:33 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> 
> > On 12 Jan 2016, at 13:30, Juergen Schoenwaelder
> > <[email-masked]> wrote:
> > 
> For the sake of (ever) finishing YANG 1.1, I'd prefer to accept this
> limitation for now - it is IMO still an improvement compared to 1.0.

+1

And in order to solve this completely generically, the server would
have to report the complete set of (modulename,revision) of all
imported modules (recursively) *for every module*.

For example:

  module a { ... import x; }
  module b { ... import x; }
  module x { ... import y; }

The server might report:

  a: (x,rev1), (y,rev2)
  b: (x,rev1), (y,rev3)

This gets very complicated.

> >        If yes, we do can hardwire this and we do not have to report this

FWIW, this is what our code (and pyang) does.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 12 Jan 2016 14:31:58 +0100

> On 12 Jan 2016, at 14:30, Martin Bjorklund <[email-masked]> wrote:
> 

What about my example? Do you think it is a non-issue?

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 12 Jan 2016 14:40:50 +0100 (CET)

> What about my example? Do you think it is a non-issue?

I am just saying that it is a non-issue in our code.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 30 Jan 2016 19:50:13 -0800

On Fri, Jan 8, 2016 at 3:22 AM, Martin Bjorklund <[email-masked]> wrote:

> ....

We should try to have some naming consistency, so it appears we should
reserve /modules for configuration and use /modules-state for reporting.
This will be more consistent with /interfaces-state.

A more interesting issue is how we might solve module configuration.
This may be too proprietary. E.g, our server can load "bundles" or modules
and
there are other implementation-specific parameters. So the opstate is not
a mirror of the config at all.

There is a chicken and egg problem, because the server needs to load some
modules
like ietf-yang-library or ietf-netconf, before it processes config input
against those modules.
Some module config cannot be part of the running config. It needs to be in
a 'bootstrap config'.

There is an architectural problem because the library is not allowed to
contain
modules the server knows about, but are not currently being used at all.  A
separate
/found-modules tree is needed to report the modules available for loading
at run-time.
It gets really wasteful to have 2 or 3 copies of every module entry.
The goal is to support a configuration model like Apache
mods-available/mods-enabled.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 31 Jan 2016 20:30:02 +0100 (CET)

> reserve /modules for configuration and use /modules-state for reporting.

Ok.  It makes sense.  Are there any objections to changing the
top-level container name to "modules-state"?

/martin