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

From: Kent Watsen <[email-masked]>
Date: Tue, 7 Jan 2020 13:04:44 +0000

Dear WG,

This is a fairly substantial update that defines a generic "ietf-system-capabilities’
module and a separate "ietf-notification-capabilities” module that augments into it.

We could start WGLC #2 now, but it would be good to get a few high-level reactions
from the WG before doing so.

Please provide comments as to if you believe the draft is ready for WGLC #2.

Thanks,
Kent // as shepherd

> On Jan 7, 2020, at 3:28 AM, [email-masked] wrote:
> 
> 
> A new version (-09) has been submitted for draft-ietf-netconf-notification-capabilities:
> https://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-capabilities-09.txt
> 
> 
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/
> 
> Diff from previous version:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-notification-capabilities-09
> 
> Please note that it may take a couple of minutes from the time of submission
> until the diff is available at tools.ietf.org.
> 
> IETF Secretariat.
>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 7 Jan 2020 16:38:01 +0000

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.

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
 - 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).

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?

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.

Thanks,
Rob

-----Original Message-----
From: netconf <[email-masked]> On Behalf Of Kent Watsen
Sent: 07 January 2020 13:05
To: NETCONF Working Group <[email-masked]>
Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt

Dear WG,

We could start WGLC #2 now, but it would be good to get a few high-level reactions from the WG before doing so.

Thanks,
Kent // as shepherd

> Please note that it may take a couple of minutes from the time of 
> submission until the diff is available at tools.ietf.org.
> 
> IETF Secretariat.
> 

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

---

From: Kent Watsen <[email-masked]>
Date: Wed, 8 Jan 2020 03:11:09 +0000

> On Jan 7, 2020, at 11:38 AM, Rob Wilton (rwilton) <[email-masked]> wrote:
> 
> Hi Kent, all,
> 

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

> - 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 o…

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 m…

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 7 Jan 2020 20:46:04 -0800

Hi,

I think the new system capabilities module is good enough.
The node-instance-identifier type allows a key to be missing, which
provides some entry reuse.

My concerns are with the notification capabilities module.

  - notification-support:  why is this an enumeration instead of bits?

suggest:

     typedef notification-support {
        type bits {
          bit notifications-for-config-changes-supported {
            description "The publisher is capable of sending
              notifications for config=true nodes, but not
              for config=false nodes for the relevant scope
              and subscription type." ;
          }
          bit notifications-for-state-changes-supported {
            description "The publisher is capable of sending
              notifications for config=false nodes, but not
              for config=true nodes for the relevant scope
              and subscription type." ;
          }
        }

   - can the names be shorter (config-changes, state-changes)?
    these names seem redundant and verbose

  - update-period
    this object seems implementation-specific.
    The description should be less normative and use 2119 language

            A periodic subscription to the selected data nodes must
            specify a value that is at least as large or greater than
            this

      Suggest:  s/must/SHOULD/

  - supported-update-period
    - this is very implementation-specific, especially as a leaf-list
instead of a
      leaf with a range
    - also has 'must' language that is inappropriate; s/must/SHOULD/

 - max-objects-per-update
   - extremely implementation-specific; Does this assume a server generates
updates
     by counting objects and stopping when this value is reached?
   - the text is not clear if it means objects or object instances? Do
child nodes count
     as instances? IMO this object should be removed or changes to max.
bytes per update
     (also implementation-specific)

 - supported-excluded-change-type
   - this union has overlapping enumeration implied values
    suggest assigning value -2; and value -1; to none and all enums

Andy

On Tue, Jan 7, 2020 at 5:04 AM Kent Watsen <[email-masked]> wrote:

> > A new version (-09) has been submitted for
> draft-ietf-netconf-notification-capabilities:
> >
> submission

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 8 Jan 2020 16:19:38 +0000

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 <[email-masked]> On Behalf Of Kent Watsen
Sent: 2020. január 8., szerda 4:11
To: Rob Wilton (rwilton) <[email-masked]>
Cc: NETCONF Working Group <[email-masked]>
Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt

How so?

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 09 Jan 2020 12:44:18 +0100 (CET)

Hi,

I think this document is heading in the right direction.  However, I
think we need to clarify how these "system capabilities" are different
from NETCONF and RESTCONF capabilities.  Also define the terms
"system capability" and perhaps "protocol capability" (to make the
distinction clear).  Then use "system capability" instead of just
"capability" in the doc.

It says:

       System capabilities may include capabilities of a
       NETCONF or RESTCONF server or a notification publisher.

I think that this is not correct; they describe the capabilities of a
server (where the term "server" is as defined in RFC 8342).

The document says that system capabilities can be specified "on
system/publisher level, datastore level or for specific data nodes".

[edit: s;/publisher;; since it is now more general than notifs]

But you don't actually specify anything on the datastore level; this
is done by doing a normal data node capability for the root node.
This is not explicitly stated but kind of implied.  I suggest that
this is either removed, or made explicit.

/martin

---

From: Balázs Lengyel <[email-masked]>
Date: Thu, 9 Jan 2020 16:57:47 +0000

-----Original Message-----
From: netconf <[email-masked]> On Behalf Of Martin Bjorklund
Sent: 2020. január 9., csütörtök 12:44
To: [email-masked]
Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt

Hi,

I think this document is heading in the right direction.  However, I think we need to clarify how these "system capabilities" are different from NETCONF and RESTCONF capabilities.  Also define the terms "system capability" and perhaps "protocol capability" (to make the distinction clear).  Then use "system capability" instead of just "capability" in the doc.

BALAZS: What would be your definition?
I wanted to use a term that is as broad as possible because:
- we can leave the definition of specific capabilities to other RFCs, so there is no need to be too specific here
- it is not just NETCONF and RESTCONF. We are already working on draft-ietf-netconf-https-notif which brings in HTTP; we might have capabilities that define e.g. the logging file sizes or really anything. We do not want to restrict the possibilities now. Later we may decide that logging file sizes belong here or maybe not.
I am at loss how to define system capabilities: "Any capability of the system implementing the server or the publisher."  Does that really add any information?

It says:

I think that this is not correct; they describe the capabilities of a server (where the term "server" is as defined in RFC 8342).

BALAZS: We do want to ALSO include publisher capabilities. E.g. The minimum (reporting) period or the maximum-number of changes per  notification is not a capability of the server. It is the capability of the publisher. Do you want to remove the words "RESTCONF or NETCONF" ?

The document says that system capabilities can be specified "on system/publisher level, datastore level or for specific data nodes".

But you don't actually specify anything on the datastore level; this is done by doing a normal data node capability for the root node.
This is not explicitly stated but kind of implied.  I suggest that this is either removed, or made explicit.

BALAZS: It is stated in the module:
"The special value '/' denotes all data nodes   in the datastore."
I will also add a sentence:
OLD:
Capability values can be specified on system/publisher level,
   datastore level or for specific data nodes (and their contained sub-
   tree) of a specific datastore.  Capability values on a smaller, more
   specific part of the system's data always override more generic
   values.
NEW:
Capability values can be specified on system/publisher level,
   datastore level (BY SELECTING ALL NODES IN THE DATASTORE) or for specific data nodes (and their contained sub-
   tree) of a specific datastore.  Capability values on a smaller, more
   specific part of the system's data always override more generic
   values.
/martin

Kent Watsen <[email-masked]> wrote:
> We could start WGLC #2 now, but it would be good to get a few 
> high-level reactions from the WG before doing so.
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 9 Jan 2020 09:14:34 -0800

On Thu, Jan 9, 2020 at 3:54 AM Martin Bjorklund <[email-masked]> wrote:

> Andy Bierman <[email-masked]> wrote:
> > Hi,
> >
> +1 for bits and the suggested shorter names
>
>
>
> >   - update-period
> I don't think either is correct.  This leaf informs the client what an
> acceptable 'period' value is.  A client that sends a shorter period
> will get a 'period-unsupported' error back, as defined in RFC 8641.
> Perhaps rephrase the sentence to:
>
>   A request for a periodic subscription to the selected data nodes
>   with a smaller period than what this leaf specifies will result in
>   a 'period-unsupported' error.
>
>
>
I agree this is better.

> See above.
> I agree that this is implementation-specific, and a byte-count as
> well.  It assumes that the implementation uses very static
> datastructures.   But I think it can be ok - an implementation that
> doesn't have such static limits will not instantiate this leaf.
>
>
Then there should be text in the description-stmt that this leaf will not
be instantiated if the server implementation does not restrict an update
to a specific number of objects.

What about the supported-update-period leaf-list?
If a server allows any centi-second value from 1 sec to 1 hour then this
will
be a leaf-list with 5900 instances in it.  Since there is no reason to
limit the upper-bound
(e.g., client wants 1 statistics update per day) this leaf-list will likely
have millions
of instances in it.

IMO this leaf-list should be removed. The minimum-update-period is
sufficient.

Andy

> high-level
> > > reactions
> > > Please provide comments as to if you believe the draft is ready for
> WGLC
> > > #2.
> > >
> > > Thanks,
> > > Kent // as shepherd
> > >
> > >

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 09 Jan 2020 12:54:07 +0100 (CET)

See above.

/martin

---

From: Balázs Lengyel <[email-masked]>
Date: Fri, 10 Jan 2020 11:50:54 +0000

Thanks for the comments. See below. Balazs

From: netconf <[email-masked]> On Behalf Of Andy Bierman
Sent: 2020. január 8., szerda 5:46
To: Kent Watsen <[email-masked]>
Cc: NETCONF Working Group <[email-masked]>
Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt

Hi,

The node-instance-identifier type allows a key to be missing, which provides some entry reuse.

suggest:

        type bits {

BALAZS:  OK changed to bits and shorter names

  - update-period

      Suggest:  s/must/SHOULD/

BALAZS: OK changed to SHOULD. This is a requirement on the client so I though it is not an RFC2119 must or should

    - this is very implementation-specific, especially as a leaf-list instead of a

      leaf with a range

BALAZS: OK changed to SHOULD. 

This is not implementation specific. E.g. the standard   3GPP TS 28.622 specifies that the system should declare a set of specific values (Not intervals) that are supported

 - max-objects-per-update

   - extremely implementation-specific; Does this assume a server generates updates

   - the text is not clear if it means objects or object instances? Do child nodes count

     as instances? IMO this object should be removed or changes to max. bytes per update

BALAZS: RFC8641 defines:

     identity update-too-big {

       description

         "Periodic or on-change push update data trees exceed a maximum

          size limit.  Hints on the estimated size of what was too big

          may be returned as supplemental information.";

     }

This is the related capability. If you can get back a too-big error, then you should have a capability declaring what TOO-big means.

Bytes are risky. If the value of a string is updated from a single character to a 2 characters the subscription might become invalid 

as we have more bytes now. Also it is impossible to calculate the number of bytes as it depends on future instance data content.

You could say the same way that if we count data nodes, if a leaf-list gets one more entries the subscription could become invalid.

Still IMHO the best solution is to count the number of “data nodes”. I will change the description.

Also if the node can not a meaningful value it is free to omit the leaf.

BALAZS: OOPS, will be corrected.

Andy

On Tue, Jan 7, 2020 at 5:04 AM Kent Watsen <[email-masked] <mailto:[email-masked]> > wrote:

Dear WG,

Please provide comments as to if you believe the draft is ready for WGLC #2..

Thanks,
Kent // as shepherd

> On Jan 7, 2020, at 3:28 AM, [email-masked] <mailto:[email-masked]>  wrote:
> 
> 
> until the diff is available at tools.ietf.org <http://tools.ietf.org> .
> 
> IETF Secretariat.
> 

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

---

From: Balázs Lengyel <[email-masked]>
Date: Fri, 10 Jan 2020 12:16:09 +0000

See BALAZS2 below.

From: netconf <[email-masked]> On Behalf Of Andy Bierman
Sent: 2020. január 9., csütörtök 18:15
To: Martin Bjorklund <[email-masked]>
Cc: Netconf <[email-masked]>
Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt

On Thu, Jan 9, 2020 at 3:54 AM Martin Bjorklund <[email-masked] <mailto:[email-masked]> > wrote:

 

I agree this is better.

BALAZS2: OK

See above.

BALAZS2: We have the following text in the sys-cap module description. I hope that is OK:

“If no entries are found in the previous steps the

     publisher is not capable of providing a value because

     it is unknown, the capability is changing for some reason,

     there is no specified limit etc. In this case the

     system's behavior is unspecified. “

This is actually a general issue, that sometimes it is not possible to provide a meaningful value for a capability.

If a server allows any centi-second value from 1 sec to 1 hour then this will

be a leaf-list with 5900 instances in it..  Since there is no reason to limit the upper-bound

(e.g., client wants 1 statistics update per day) this leaf-list will likely have millions

of instances in it.

IMO this leaf-list should be removed. The minimum-update-period is sufficient.

BALAZS2: There are implementations and standards that use specific values not ranges.

/martin

Andy

---

From: Kent Watsen <[email-masked]>
Date: Fri, 10 Jan 2020 15:35:03 +0000

Hi Balazs,

> (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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 10 Jan 2020 07:47:40 -0800

On Fri, Jan 10, 2020 at 4:16 AM Balázs Lengyel <[email-masked]>
wrote:

> *See BALAZS2 below.*
>
>
>
> *From:* netconf <[email-masked]> *On Behalf Of *Andy Bierman
> *Sent:* 2020. január 9., csütörtök 18:15
> *To:* Martin Bjorklund <[email-masked]>
> *Cc:* Netconf <[email-masked]>
> *Subject:* Re: [netconf] New Version Notification -
> draft-ietf-netconf-notification-capabilities-09.txt
>
>
>
>
>
>
>
> This is actually a general issue, that sometimes it is not possible to
> provide a meaningful value for a capability.
>
>
>

The YANG-Push standard simply specifies "centiseconds" as the type.
There is no mention in RFC 8641 of anything related to supporting a subset
of this data type.
The YANG syntax for "centiseconds" allows for 4 billion distinct values:

           typedef centiseconds {

       type uint32;
       description
         "A period of time, measured in units of 0.01 seconds.";
     }

IMO this object could be added via augment by a vendor or other SDO.

It has no relevance to the YANG-Push standard.

Andy

---

From: Balázs Lengyel <[email-masked]>
Date: Fri, 10 Jan 2020 16:07:08 +0000

From: Andy Bierman <[email-masked]> 
Sent: 2020. január 10., péntek 16:48

On Fri, Jan 10, 2020 at 4:16 AM Balázs Lengyel <[email-masked] <mailto:[email-masked]> > wrote:

See BALAZS2 below. 

See above.

of instances in it.

There is no mention in RFC 8641 of anything related to supporting a subset of this data type.

           typedef centiseconds {

       type uint32;
       description

BALAZS3: RFC8641 defines: period centiseconds derived from uint32.
However it does not say anything about whether an application should/shall support
-        The full uint32 range 
-        Just some interval(s)
-        Zero to a minimum value
-        A specific set of values
I could argue the same way that a set of specific values is enough, minimum is not needed and is not specified in RFC8641
IMHO 3GPP is an important user  community, so if they are using specific values, we should allow for that in our model.
I see value in allowing both a minimum value and specific values. Does it harm anyone to allow both?

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 10 Jan 2020 16:07:31 +0000

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 <[email-masked]>
Sent: 10 January 2020 15:35
To: Balázs Lengyel <[email-masked]>
Cc: Rob Wilton (rwilton) <[email-masked]>; [email-masked]
Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt

Hi Balazs,

Kent // contributor

---

From: Andy Bierman <[email-masked]>
Date: Fri, 10 Jan 2020 08:44:25 -0800

On Fri, Jan 10, 2020 at 8:07 AM Balázs Lengyel <[email-masked]>
wrote:

>
>
>
>
> *From:* Andy Bierman <[email-masked]>
> *Sent:* 2020. január 10., péntek 16:48
>
> On Fri, Jan 10, 2020 at 4:16 AM Balázs Lengyel <
> [email-masked]> wrote:
>
> *See BALAZS2 below. *
>
>
>
RFC 7950 specifies the server requirements for typedefs, and the built-in
type uint32
The YANG-Push data-def-stmts make no mention of any different
interpretation of this data type.

> IMHO 3GPP is an important user  community, so if they are using specific values, we should allow for that in our model.

It is one thing for a client to configure a subset of values and quite
another
for a server to only accept a subset of the specified values.
YANG Push is not constrained to a subset of the centiseconds data type.

> I see value in allowing both a minimum value and specific values. Does it harm anyone to allow both?
It doesn't belong in the module for YANG-Push.
IMO you need to use a deviation to replace the data type because your
implementation
that only accepts a subset of centiseconds is non-compliant.  A client
should not have to
go read some unrelated capabilities objects to find out how a server
deviates from the spec.

BTW, the module names a top-level container called
'notification-capabilities' but none
of the contents are for generic notifications. They are all for YANG-Push.

Andy

---

From: Balázs Lengyel <[email-masked]>
Date: Tue, 14 Jan 2020 11:55:05 +0000

OK. For both.

Regards Balazs

From: Rob Wilton (rwilton) <[email-masked]> 
Sent: 2020. január 10., péntek 17:08
To: Kent Watsen <[email-masked]>; Balázs Lengyel
<[email-masked]>
Cc: [email-masked]
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.

Thanks,

Rob

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

Hi Balazs,

OLD:

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

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 21 Jan 2020 16:43:39 +0000

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

OK. For both.
Regards Balazs

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

Hi Kent, Balazs,

Thanks,
Rob

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

Hi Balazs,

Kent // contributor

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 22 Jan 2020 14:42:58 +0000

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) <[email-masked]>
Sent: 21 January 2020 16:44
To: Balázs Lengyel <balazs.lengyel=[email-masked]>; Rob Wilton (rwilton) <[email-masked]>; Kent Watsen <[email-masked]>
Cc: [email-masked]
Subject: Re: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt

Hi,

Regards,
Reshad.

OK. For both.
Regards Balazs

Hi Kent, Balazs,

Thanks,
Rob

Hi Balazs,

Kent // contributor

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 24 Jan 2020 21:31:28 +0000

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)" <[email-masked]>
Date: Wednesday, January 22, 2020 at 9:42 AM
To: "Reshad Rahman (rrahman)" <[email-masked]>, Balázs Lengyel <balazs.lengyel=[email-masked]>, Kent Watsen <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [netconf] New Version Notification - draft-ietf-netconf-notification-capabilities-09.txt

Hi Reshad,

Thanks,
Rob

Hi,

Regards,
Reshad.

OK. For both.
Regards Balazs

Hi Kent, Balazs,

Thanks,
Rob

Hi Balazs,

Kent // contributor