Subject: [Netconf] YANGLIB #5: how to list protocol-specific modules

From: Andy Bierman <[email-masked]>
Date: Tue, 10 Nov 2015 15:16:49 -0800

Hi,

This open issue needs to be resolved.
https://github.com/netconf-wg/yang-library/issues/5

There are 2 solution paths that have been suggested:

YLIB5-01: separate views for each protocol.
Each protocol would receive only the modules that are enabled
for that protocol.

YLIB5-02: add leaf-list to each module entry
NETCONF and RESTCONF identities can be defined right away.
Other protocols can define new identities on their own.

   leaf-list protocol {
      type identityref {
          base yang-protocol;
       }
   }

IMO both have drawbacks.
The server really tries to avoid protocol-dependent code.
The code that manages data does not care about protocols,
just internal representations of YANG data.

The leaf-list approach is a waste of bandwidth unless the
YANG library is actually shared by multiple protocols
within a single server instance.

So please discuss this issue on the mailing list and give your preference
for a solution, or suggest a new solution.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Nov 2015 08:51:49 +0100

I assume the differences mostly affects a few modules that are
specific to the protocol(s) being used. As such, I would think that
YLIB5-01 makes more sense since this solution does not pollute the
whole module list.

/js

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

-- 
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: Kent Watsen <[email-masked]>
Date: Wed, 11 Nov 2015 17:07:00 +0000

Is there a better example than ietf-netconf?    - I don’t think ietf-netconf is a valid example as it’s not listed in a NETCONF <hello> message - only it’s namespace is used, but that is quite different...

If it’s just this one example, then I prefer option #1.

Kent

From: Netconf <[email-masked]<mailto:[email-masked]>> on behalf of Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 10, 2015 at 6:16 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Netconf] YANGLIB #5: how to list protocol-specific modules

Hi,

   leaf-list protocol {
      type identityref {
          base yang-protocol;
       }
   }

IMO both have drawbacks.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 11 Nov 2015 09:25:30 -0800

On Wed, Nov 11, 2015 at 9:07 AM, Kent Watsen <[email-masked]> wrote:

>
> Is there a better example than ietf-netconf?    - I don’t think
> ietf-netconf is a valid example as it’s not listed in a NETCONF <hello>
> message - only it’s namespace is used, but that is quite different...
>
One problem with option #1 is that it excludes static content as an
implementation strategy.
I cannot just have a static representation of all the YANG modules.
Instead it has to
be dynamically rendered or output with special code, in order to examine
the protocol
of the client and filter out entries based on that.

Or I have a static representation for each protocol, which is kind of a
waste if the
difference is only 1 or 2 modules.

A variant of option #2 is a hard-wired leaf (e.g. bits) with "netconf" and
"restconf"
defined in the first release.

Kent

Andy

>
>
> From: Netconf <[email-masked]> on behalf of Andy Bierman <
> [email-masked]>
> To: "[email-masked]" <[email-masked]>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 11 Nov 2015 18:35:43 +0100 (CET)

> One problem with option #1 is that it excludes static content as an

Agreed.

> defined in the first release.

If you're worried about the bits-on-the-wire, maybe we can have a
leaf-list:

   leaf-list restricted-protocol { ... }

and if it is empty the module applies to all protocols.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Nov 2015 18:56:09 +0100

> and if it is empty the module applies to all protocols.

I guess I am more concerned about popularizing the idea that data
models may be protocol interface specific by providing explicit
support for this. But then, this won't stop people anyway - and we
already have yang patch and we leave it somewhat open how to use it
with NC. So perhaps having a leaf list and letting the market decide
whether protocol specific data models are a bug or a feature is the
way to go.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 11 Nov 2015 10:06:08 -0800

> > and if it is empty the module applies to all protocols.
This is a better option #2

> whether protocol specific data models are a bug or a feature is the

RPC operations in ietf-netconf are very protocol-specific.

I do not want to constrain vendors or cause extra complexity.
Whether the YANG module has protocol-specific content or not,
it is a separate decision for a vendor to support a data model in
a given protocol.

There may be more CLI content than NETCONF content implemented in the
server.
There may be more NETCONF content than RESTCONF content implemented
in the server.  There may be just a few modules that are supported by I2RS.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 12 Nov 2015 08:40:50 +0100

> defined in the first release.

I think the server can keep such a leaf internally and then take it into
account when serializing the data for a particular protocol.

I prefer #1. With respect to ietf-netconf, is there any reason why it needs
to be listed in yang-library even for NETCONF?

Lada

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 13 Nov 2015 09:18:40 -0800

> and if it is empty the module applies to all protocols.

If NETCONF and RESTCONF clients are somehow stepping on each other's
data, then how is either client supposed to know the other protocol
is enabled and active?

A per-protocol view does not allow any real diagnostics.

If there was a global leaf-list like /modules/yang-protocol

   leaf-list yang-protocol {
     type identityref {
         base yang-protocol;
     }
     description
       "Identifies a protocol that is utilizing YANG-based content,
        which can be found in this YANG library";
  }

If this object is combined with the restricted-protocol, then either client
can determine which protocols are supported for each module.

Andy