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

["Reshad Rahman (rrahman)" <[e-mail]>]

Hi Rob and Balazs,

I agree that the previous mechanism was error prone in that different client implementations could come to different results depending on their interpretation/implementation of the criteria below.

It is a moot point now, but I believe the criteria should have been best-match and not longest-match. Now the publisher can be more explicit about this.

Regards,
Reshad.

From: "Rob Wilton (rwilton)" <[e-mail]>
Date: Wednesday, January 22, 2020 at 9:42 AM
To: "Reshad Rahman (rrahman)" <[e-mail]>, Balázs Lengyel <balazs.lengyel=[e-mail]>, Kent Watsen <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: RE: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt

Hi Reshad,

In rev-9, in the YANG module description, there is a hierarchy of which capabilities apply, basically the longest match wins:

      If a capability is specified on multiple levels, the
      specification on a more specific level overrides more
      generic capability specifications; thus
      - a system level specification is overridden by any
      other specification
      - a datastore level specification (with a node-selector '/') is
      overridden by a specification with a more specific node-selector.
      - a specification for a specific datastore and node-selector
      is overridden by a specification for the same datastore with
      a node-selector that describes more levels of containing lists
      and containers.
      It is not allowed to have multiple node selectors which
      - are defined for the same datastore AND
      - have the same number of containment levels AND
      - select an overlapping set of nodes.

But as soon as you allow more complex specifications (e.g. perhaps Xpath to select the set of nodes that a capability applies to) then working out which entry is the longest match is very hard, if not impossible.  Hence moving to an ordered list (as per the -10 draft) ensures that the capabilities are always deterministic.

Thanks,
Rob


From: Reshad Rahman (rrahman) <[e-mail]>
Sent: 21 January 2020 16:44
To: Balázs Lengyel <balazs.lengyel=[e-mail]>; Rob Wilton (rwilton) <[e-mail]>; Kent Watsen <[e-mail]>
Cc: [e-mail]
Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt

Hi,

Regarding the change below (which was added in rev-10) to match by order, was this done just to make life easier for the client (the publisher is deciding what’s the best match) or is there another motivation? I think this is a good change, but curious as to the reason.

Regards,
Reshad.

From: netconf <[e-mail]> on behalf of Balázs Lengyel <balazs.lengyel=[e-mail]>
Date: Tuesday, January 14, 2020 at 6:55 AM
To: "Rob Wilton (rwilton)" <[e-mail]>, Kent Watsen <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt

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