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

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

OK. For both.

Regards Balazs

 

From: Rob Wilton (rwilton) <[e-mail]> 
Sent: 2020. január 10., péntek 17:08
To: Kent Watsen <[e-mail]>; Balázs Lengyel
<[e-mail]>
Cc: [e-mail]
Subject: RE: [netconf] New Version Notification -
draft-ietf-netconf-notification-capabilities-09.txt

 

Hi Kent, Balazs,

 

Yes, I think that this would work, but might also need to change the rule
from matching the capabilities from the longest node path, to the order that
the entries are in the list.  E.g. the capabilities are decided by the first
entry in the list that matches the given path.  The existing longest node
path behaviour can effectively be implemented by ordering the more specific
node paths before the less specific node paths.

 

Would that be acceptable?

 

I would also suggest giving the choice and the leaf a separate name below.

 

Thanks,

Rob

 

 

From: Kent Watsen <[e-mail] <mailto:[e-mail]> > 
Sent: 10 January 2020 15:35
To: Balázs Lengyel <[e-mail]
<mailto:[e-mail]> >
Cc: Rob Wilton (rwilton) <[e-mail] <mailto:[e-mail]> >;
[e-mail] <mailto:[e-mail]> 
Subject: Re: [netconf] New Version Notification -
draft-ietf-netconf-notification-capabilities-09.txt

 

 

Hi Balazs,






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)

 

 

Yes, this is inline with what I had in mind but, since this was my
suggestion, I was hoping that Rob or others would reply.

 

Kent // contributor