Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt

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

Hello Rob, Kent,
Would the following be acceptable?
OLD:
      list per-node-capabilities {
        key "node-selector";
        leaf node-selector {
          type nacm:node-instance-identifier;
NEW:
      list per-node-capabilities {
        choice node-selector {
       	 leaf node-selector {   type nacm:node-instance-identifier;  }
      }

Later you can augment in an Xpath filter or a string with '*' and '?' wildcards or whatever you want.
(The list does not need a key as it is config=false)
Regards Balazs

-----Original Message-----
From: netconf <[e-mail]> On Behalf Of Kent Watsen
Sent: 2020. január 8., szerda 4:11
To: Rob Wilton (rwilton) <[e-mail]>
Cc: NETCONF Working Group <[e-mail]>
Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt



> On Jan 7, 2020, at 11:38 AM, Rob Wilton (rwilton) <[e-mail]> wrote:
> 
> Hi Kent, all,
> 
> My main concern with this more general model is whether this model has the right structure to generically model device capabilities.
> 
> It is often the case that hardware capabilities might differ by the linecard type that has been inserted (which can change dynamically), and/or the type of interface.

The base “system-capabilities” is augmentable.   An augment can be defined someday to provide that behavior?


> As it stands, I don't think that the current model can describe capabilities for this class of devices:
> - per datastore capabilities are not granular enough

How so?


> - per datanode capabilities are too granular (e.g. you would end up with separate capabilities for each interface, and even then they can only describe the interfaces that exist, or might exist).

Your xpath selector would resolve this, as would a templates (I think).  Maybe we could view this copy/paste-based approach as good enough for the short term?


> Possibly, having a xpath selector to identify the set of nodes that the capabilities apply to might be flexible enough, but this would greatly increase complexity.  Perhaps something like a union of a node selector and xpath selector could work?

Perhaps the “node-selector” could be put into a ‘choice’ with it being the only descendent, for now, thus enabling a future extension to define a fancier selector?


> I don't want to slow work down, but I do question whether we are rushing to a generic capability solution that won't be sufficient for many devices out there.  Hence part of me wonders whether it might be better to get the original notification capabilities draft finished (as a time to market solution), and then look at the generic capabilities requirements/solution with a bit less time pressure.

The response from previous WGLC was that folks wanted the more generic solution now.


FWIW, when I did this in a past life, I had a get-hardware-inventory RPC, an offline a hardware-catalog, and an ability to set (either relative or absolute) capabilities (we called them “features”) based on the hardware present.  Key to the solution was being able to pull the inventory from a live device and, in lieu of that, to model/simulate the inventory a device might have (for pre-provisioning).

Kent // contributor


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