Subject: [Netconf] LL review of yang-library-03

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 17 Dec 2015 16:47:24 +0100

Hi,

I reviewed the draft and found several issues:

    - The purpose of "yang-protocol" and "restricted-protocol" is
      unclear from the text. I know it from the mailing list
      discussion, but I think this solution is not good. What if a
      device runs, e.g., multiple RESTCONF servers on different ports,
      each with a specific data model? IMO the best solution is to
      have yang-library information specific for each protocol server
      instance. The "*-protocol" leafs than wouldn't be needed.
      
    - The name "conformance" seems to be a misnomer: the leaf gives
      information about how the module is used by the server. What
      about "role"?

    - The descriptions of the enums "implement" and "import" are
      confusing and maybe incorrect. In my view, a server must include
      in the yang-library all implemented modules, and then those that
      are (at least once) imported without revision. Those that are
      only imported by revision should not be in yang-library at
      all. IMO *all* modules must appear in yang-library no more than
      once - otherwise, how a client could determine which revision
      (of several listed) was used for a particular import without
      revision?
      
    - "implement" should also mean implementing identities defined in
      the module.

    - Once upon a time, there was a discussion in XML circles about
      pros and cons of "xsd:schemaLocation". Some of the
      considerations also apply to the "schema" leaf. I think the
      client should either already have the modules/revisions listed
      in yang-library, or be able to get them from a well-known and
      reliable location. The schema provided by the device should not
      be used as authoritative because otherwise vendors might be
      tempted to serve clients with "improved" versions that pretend
      to be standard.

Lada

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 17 Dec 2015 17:26:04 +0100

> I reviewed the draft and found several issues:

I forgot to include one more thing:

    - It might be useful to have a standard algorithm for computing
      "module-set-id". For example, in large deployments comprising
      essentially identical devices, it could save the client many
      round-trips if the same "module-set-id" means the same
      yang-library content on all devices.

Lada

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Dec 2015 14:40:42 -0800

>       instance. The "*-protocol" leafs than wouldn't be needed.

This approach appears simple, but it requires the server
to implement dynamic content for this module instead of static content.
It also prevents the operator from knowing what other protocols might
be clashing with their client.

I think the YANG description-stmts for these leaf-lists are clear.

Each virtual server has its own YANG library that covers the protocols
used just on that virtual server.

>       information about how the module is used by the server. What

Role is rather generic. How about conformance-role?

>       (of several listed) was used for a particular import without

I disagree.
The YANG library needs to list all the modules.
A client must be able to predetermine the module set.
Otherwise the client has to parse the YANG module
and analyze all the imports (and imports in the imported modules, until
the end of the dependency chain)

What problem are you solving by leaving out modules and forcing the client
to
parse all the modules instead?

>     - "implement" should also mean implementing identities defined in

One does not implement identities.
Only leaf or leaf-list of type identityref can be implemented.
YANG conformance is incapable of specifying the set of identities
that a server MUST support (except the description-stmt).
This module is not intended to fix all the deficiencies of YANG conformance.

>       tempted to serve clients with "improved" versions that pretend

I don't see how the YANG library affects this issue.
A vendor can put whatever URL they want in this leaf.
It is optional, so they don't have to support schema retrieval at all.

> Lada

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Dec 2015 14:46:19 -0800

>       yang-library content on all devices.

Yeah, that is one of the motivations for my YANG Packages draft.
I would rather rely on an explicit YANG identifier assignment to classify
the server capabilities, than a hash or other algorithm that is not
guaranteed to be unique.

The module-set-id is just a caching helper for NETCONF
(which does not support ETags like RESTCONF).

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 18 Dec 2015 09:47:34 +0100

> be clashing with their client.

This assumes there is a single server process and each protocol is just
an interface to it. But there can also be separate server processes,
each with its own configuration. So at least sec. 2.1.2 should talk
about "server instance" and not about "managed device".

I think it is sensitive information: why should every client of every
protocol know all management protocols available on the device?

Other state data are often dynamically generated, so I don't think it's
such a big problem - each client will just receive the data it is
entitled to work with.

> I think the YANG description-stmts for these leaf-lists are clear.

Well, the description of "yang-protocol" is:

          "Identifies a protocol that is using modules described
           in this library.  There SHOULD be one instance of
           this object for each protocol for each YANG-based
           protocol using this library.";

This is IMO totally unclear. What does "protocol" mean? Is it a protocol
interacting with the same server process, or any protocol on any virtual
server? Is this "yang-protocol" leaf-list related somehow to the
"restricted-protocol" leaf-list?

It would be OK to have this info as a part of netconf-monitoring or
similar regular state data - also because appropriate access
restrictions can be applied. Yang-library is a critical structure, so it
should IMO contain only the information that's necessary but nothing else.

> Role is rather generic. How about conformance-role?

OK.

> parse all the modules instead?

I think I already described the problem. Let's say three revisions of
ietf-inet-types are listed in yang-library, and some module imports
ietf-inet-types without revision. How can the client tell which revision
should be used for this import?

> One does not implement identities.

Are modules that contain only identities (iana-if-type) listed as
"implement" or "import"?

> It is optional, so they don't have to support schema retrieval at all.

If is it only auxiliary information, it doesn't IMO belong to
yang-library. It is already available in ietf-netconf-monitoring so
there is no need to duplicate it.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 18 Dec 2015 16:16:31 +0100 (CET)

> > be clashing with their client.

Yes.  But actually the current model doesn't prevent someone from
using different instances of ietf-yang-library for different
protocols.

> "restricted-protocol" leaf-list?

I think that restricted-protocol could as well be a leafref into
yang-protocol.

> Are modules that contain only identities (iana-if-type) listed as

"import", since "implement":

               Indicates that the server implements one or more
               protocol-accessible objects defined in the YANG module
               identified in this entry.  This includes deviation
               statements defined in the module.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 18 Dec 2015 07:36:05 -0800

> I think that restricted-protocol could as well be a leafref into

OK

>                statements defined in the module.

I recently implemented iana-crypt-hash in our server.
This has 3 YANG features that can be advertised.
It seems strange to advertise that this module is just imported,
and yet features are implemented.

We currently return conformance 'true' and all 3 features:

   module  iana-crypt-hash 2014-08-06 {
        name iana-crypt-hash
        revision 2014-08-06
        namespace urn:ietf:params:xml:ns:yang:iana-crypt-hash
        schema http://localhost/restconf/yang/iana-crypt-hash/2014-08-06
        conformance true
        feature crypt-hash-md5
        feature crypt-hash-sha-256
        feature crypt-hash-sha-512
      }

I proposed an RPC called "get-allowed-identities" in 2014
https://tools.ietf.org/html/draft-bierman-netmod-yang-conformance-04

Even though YANG 1.1 allows if-feature in an identity, this does not
solve the iana-if-type problem.  It would be useful for the client app
to know what identities are relevant for a given leaf.  Using 100s or 1000s
of YANG identities would be unmanageable.

There should be some way in a YANG module to say that an identity-stmt
value is required for a particular identityref, but not in this draft.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 18 Dec 2015 16:38:05 +0100

> On 18 Dec 2015, at 16:16, Martin Bjorklund <[email-masked]> wrote:
> 

But then yang-protocol and restricted-protocol are useless.

> I think that restricted-protocol could as well be a leafref into

Right, but currently the relationship is not even indicated in the descriptions.

> "import", since "implement":

Hmm, this seems to be at odds with 6020bis, sec. 9.10.2:

   Valid values for an identityref are any identities derived from all
   the identityref's base identities.  On a particular server, the valid
   values are further restricted to the set of identities defined in the
   modules implemented by the server.

Lada