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

From: Andy Bierman <[email-masked]>
Date: Tue, 8 Dec 2015 12:48:56 -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...
>
>
Actually it is listed in the <hello>, except that nobody actually
implements it
since the information is already sent in the original capability URIs
(e.g. :candidate capability checked, not candidate feature).

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

I still prefer 2 because the server data should be protocol-neutral,
and clashes between protocols cannot be identified if 1 protocol
cannot see what is enabled for other protocols.

We already implement RESTCONF, NETCONF, and ietf-yang-library together.
Some modules like the library itself will always be enabled for  all
protocols,
but other modules may depend on the protocol or the vendor or the operator.

> Kent

Andy

>
>
> From: Netconf <[email-masked]> on behalf of Andy Bierman <
> [email-masked]>
> Date: Tuesday, November 10, 2015 at 6:16 PM
> To: "[email-masked]" <[email-masked]>
> Subject: [Netconf] YANGLIB #5: how to list protocol-specific modules
>
> 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: Kent Watsen <[email-masked]>
Date: Tue, 8 Dec 2015 22:52:24 +0000

Hi Andy,

#2 is fine also, especially with Martin’s "restricted-protocal" enhancement.

K.

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, December 8, 2015 at 3:48 PM
To: Kent Watsen <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] YANGLIB #5: how to list protocol-specific modules

On Wed, Nov 11, 2015 at 9:07 AM, Kent Watsen <[email-masked]<mailto:[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...

Actually it is listed in the <hello>, except that nobody actually implements it
since the information is already sent in the original capability URIs
(e.g. :candidate capability checked, not candidate feature).

We already implement RESTCONF, NETCONF, and ietf-yang-library together.
Some modules like the library itself will always be enabled for  all protocols,
but other modules may depend on the protocol or the vendor or the operator.

Kent

Andy

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