Subject: [netconf] Generic Capabilities model

From: Qin Wu <[email-masked]>
Date: Thu, 5 Dec 2019 03:56:27 +0000

Hi, Balazs:
In last IETF meeting, you offered a proposal in netmod session on notification capability change that was discussed in netmod session.
I think it is a good idea to define generic capabilities model in draft-ietf-netconf-notification-capabilities
https://datatracker.ietf.org/meeting/106/materials/slides-106-netmod-sessb-generic-model-for-server-capabilities-00
since we have other capabilities that need to be covered, one of example such capability is one that can be self-described in
draft-tao-netmod-yang-node-tags<https://tools.ietf.org/id/draft-tao-netmod-yang-node-tags-00.txt>.
With such new capability, should we augment from YANG Push model or should we augment from notification capability?
We see one downside of augmenting from YANG Push model, is it only can be used in the running time, it can not be used in the design time or
Implementation time.

So I think if one generic capability model can be defined, it will allow more flexibility to add new capability. However if we decide to take this approach,
Probably notification capabilities draft require substantial changes to the current model structure. But I think it worth to do so, in my personal view.

-Qin

---

From: Benoit Claise <[email-masked]>
Date: Thu, 5 Dec 2019 09:15:06 -0800

Hi Qin,

I would agree.
I believe it's important to have a generic solution. I can picture more 
augmentations.
The change is trivial IMO, i.e. modify the 
ietf-notification-capabilities model

  * Rename the top level container to system-capabilities
  * Add a container subscription-capabilities to the grouping
    subscription-capabilities to contain all subscription related
    capabilities
  * Invite others to augment the model with similar groupings for other
    capabilities.

Regards, Benoit.

> Hi, Balazs:
>
> In last IETF meeting, you offered a proposal in netmod session on 
> notification capability change that was discussed in netmod session.
>
> I think it is a good idea to define generic capabilities model in 
> draft-ietf-netconf-notification-capabilities
>
> since we have other capabilities that need to be covered, one of 
> example such capability is one that can be self-described in
>
> draft-tao-netmod-yang-node-tags 
> <https://tools.ietf.org/id/draft-tao-netmod-yang-node-tags-00.txt>.
>
> With such new capability, should we augment from YANG Push model or 
> should we augment from notification capability?
>
> We see one downside of augmenting from YANG Push model, is it only can 
> be used in the running time, it can not be used in the design time or
>
> Implementation time.
>
> So I think if one generic capability model can be defined, it will 
> allow more flexibility to add new capability. However if we decide to 
> take this approach,
>
> Probably notification capabilities draft require substantial changes 
> to the current model structure. But I think it worth to do so, in my 
> personal view.
>
> -Qin
>
>
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Thu, 5 Dec 2019 13:43:55 -0800

Hi,

I strongly support this generic capabilities work.
IMO this approach would make NMDA much easier for a client to support,
since the new /yang-library
would not be needed for this purpose.  Instead, a simple "nmda-operational"
capability could be used in this module
to easily identify which config=true nodes should be expected in
<operational>.

The complexity in /yang-library might be justified if new writable
datastores (like <ephemeral>) are
ever introduced, but not for solving the problem "what features does this
server support for the specified
data node (resource)"?

Andy

On Thu, Dec 5, 2019 at 9:15 AM Benoit Claise <[email-masked]> wrote:

> The change is trivial IMO, i.e. modify the ietf-notification-capabilities
> model
>
>    - Rename the top level container to system-capabilities
>    - Add a container subscription-capabilities to the grouping
>    subscription-capabilities to contain all subscription related capabilities
>    - Invite others to augment the model with similar groupings for other
>    capabilities.
>
> Regards, Benoit.
>
> Hi, Balazs:
>
> since we have other capabilities that need to be covered, one of example
> such capability is one that can be self-described in
>
> We see one downside of augmenting from YANG Push model, is it only can be
> used in the running time, it can not be used in the design time or
>
> Implementation time.
>
>
>
> So I think if one generic capability model can be defined, it will allow
> more flexibility to add new capability. However if we decide to take this
> approach,
>
> Probably notification capabilities draft require substantial changes to
> the current model structure. But I think it worth to do so, in my personal
> view.
>
>
>
> -Qin
>
> netconf mailing [email-masked]://www.ietf.org/mailman/listinfo/netconf
>
>

---

From: Balázs Lengyel <[email-masked]>
Date: Fri, 6 Dec 2019 13:53:05 +0000

Hello,

We will soon publish a new version of the notification-capabilities draft, that is prepared for augmentation, by other modules.

Regards Balazs

From: netconf <[email-masked]> On Behalf Of Andy Bierman
Sent: 2019. december 5., csütörtök 22:44
To: Benoit Claise <[email-masked]>
Cc: [email-masked]
Subject: Re: [netconf] Generic Capabilities model

Hi,

IMO this approach would make NMDA much easier for a client to support, since the new /yang-library

would not be needed for this purpose.  Instead, a simple "nmda-operational" capability could be used in this module

to easily identify which config=true nodes should be expected in <operational>.

The complexity in /yang-library might be justified if new writable datastores (like <ephemeral>) are

ever introduced, but not for solving the problem "what features does this server support for the specified

data node (resource)"?

Andy

On Thu, Dec 5, 2019 at 9:15 AM Benoit Claise <bclaise@cisco..com <mailto:[email-masked]> > wrote:

Hi Qin,

I would agree.
I believe it's important to have a generic solution. I can picture more augmentations.
The change is trivial IMO, i.e. modify the ietf-notification-capabilities model 

*	Rename the top level container to system-capabilities
*	Add a container subscription-capabilities to the grouping subscription-capabilities to contain all subscription related capabilities
*	Invite others to augment the model with similar groupings for other capabilities.  

Regards, Benoit.

Hi, Balazs:

 <https://tools.ietf.org/id/draft-tao-netmod-yang-node-tags-00.txt> draft-tao-netmod-yang-node-tags.

Implementation time.

-Qin

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

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

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 6 Dec 2019 18:46:16 +0000

+1 for the generic capabilities work.

From: netconf <[email-masked]> on behalf of 'Andy Bierman' <[email-masked]>
Date: Thursday, December 5, 2019 at 4:44 PM
To: "Benoit Claise (bclaise)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [netconf] Generic Capabilities model

Hi,

Andy

On Thu, Dec 5, 2019 at 9:15 AM Benoit Claise <bclaise@cisco..com<mailto:[email-masked]>> wrote:
Hi Qin,

I would agree.

Regards, Benoit.
Hi, Balazs:

-Qin

netconf mailing list

[email-masked]<mailto:[email-masked]>

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

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 6 Dec 2019 11:19:29 -0800

+1

Regards,
Jeff

> On Dec 6, 2019, at 10:46, Reshad Rahman (rrahman) <[email-masked]> wrote:
> 
> 
> On Thu, Dec 5, 2019 at 9:15 AM Benoit Claise <bclaise@cisco..com> wrote:
> Hi Qin,
> 
> I would agree.
> Rename the top level container to system-capabilities
> Add a container subscription-capabilities to the grouping subscription-capabilities to contain all subscription related capabilities
> Invite others to augment the model with similar groupings for other capabilities. 
> Regards, Benoit.
> 
> Hi, Balazs:
> draft-tao-netmod-yang-node-tags.