Re: [netconf] Generic Capabilities model

[Balázs Lengyel <[e-mail]>]

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 <[e-mail]> On Behalf Of Andy Bierman
Sent: 2019. december 5., csütörtök 22:44
To: Benoit Claise <[e-mail]>
Cc: [e-mail]
Subject: Re: [netconf] Generic Capabilities model

 

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 <bclaise@cisco..com <mailto:[e-mail]> > 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:

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

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

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
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/netconf

 

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