Subject: [netmod] RFC 8342 : Query about NMDA Origin for Non-presence containers

From: Rohit R Ranade <[email-masked]>
Date: Thu, 27 Sep 2018 08:40:10 +0000

Hi All,

Section 5.3.4:
"The
   origin applies to all configuration nodes except non-presence
   containers.  "

In ietf-origin YANG module:
     md:annotation origin {
       type origin-ref;
       description
         "The 'origin' annotation can be present on any configuration
          data node in the operational state datastore.  It specifies
          from where the node originated.  If not specified for a given
          configuration data node, then the origin is the same as the
          origin of its parent node in the data tree.  The origin for
          any top-level configuration data nodes must be specified.";
     }

C.1.  System Example:
The root node "system", is config-true and a non-presence container, and in the example, does not have the  "origin" meta-data attribute

Keeping all the above points in mind, which is the correct way ? Whether the top-level configuration node should contain the "origin" attribute for Non-presence containers ?

With Regards,
Rohit R Ranade

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 27 Sep 2018 10:51:56 +0200

> Keeping all the above points in mind, which is the correct way ? Whether the top-level configuration node should contain the "origin" attribute for Non-presence containers ?

Let me first clarify the difference between 'a node carrying an origin
annotation' and 'an origin annotation applying to a node':

- Any node can 'carry an origin annotation' (but it may not apply to
  the node). If a node does not 'carry an origin annotation', then the
  parent node is inspected whether it carries an origin annotation.

- An origin annotation applys to a node if it is a node to which an
  origin annotation can be applied. Since non-presence containers have
  meaning by themself, the origin annotation does not apply to
  non-presence containers (but they may still 'carry an origin
  annotation'.

Given the requirement stated in the definition md:annotation origin,
it seems that the "system" top-level container should have an origin
annotation. (One can debate whether this requirement is too strict
since in the example an origin annotation of the "system" top-level
container would not apply to anything since all the nodes below
"system" have explicit origin annotations.)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Rohit R Ranade <[email-masked]>
Date: Thu, 27 Sep 2018 09:11:41 +0000

Please find inline.

Rohit R Ranade

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: 27 September 2018 14:22
To: Rohit R Ranade <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] RFC 8342 : Query about NMDA Origin for Non-presence containers

On Thu, Sep 27, 2018 at 08:40:10AM +0000, Rohit R Ranade wrote:
> The root node "system", is config-true and a non-presence container, 
> and in the example, does not have the  "origin" meta-data attribute
> 
> 

Let me first clarify the difference between 'a node carrying an origin annotation' and 'an origin annotation applying to a node':

Given the requirement stated in the definition md:annotation origin, it seems that the "system" top-level container should have an origin annotation. (One can debate whether this requirement is too strict since in the example an origin annotation of the "system" top-level container would not apply to anything since all the nodes below "system" have explicit origin annotations.)
[Rohit R Ranade] So how to decide the origin annotation for top-level non-presence container. Consider the case of "nacm" root node of ietf-netconf-acm module which is a container. 
Consider that "enable-nacm" came via "intended" origin, and "read-default" came via "default" origin.
      +--rw nacm
         +--rw enable-nacm?            boolean
         +--rw read-default?           action-type
         +--rw write-default?          action-type
         +--rw exec-default?           action-type
[Rohit R Ranade] So how to decide the origin for the container, when its child may have mixed origin ?
/js

---

From: Robert Wilton <[email-masked]>
Date: Thu, 27 Sep 2018 10:49:10 +0100

Hi Rohit,

Please see inline ...

> Given the requirement stated in the definition md:annotation origin, it seems that the "system" top-level container should have an origin annotation. (One can debate whether this requirement is too…
Give the two statements above from Juergen then for a top level np 
container, the server may return any origin value that it wishes, as 
long as the correct origin is returned (either implicitly or explicitly) 
for all descendant nodes that are not np-containers.

One choice would to always set all top level np containers to origin 
"unknown".

An alternative choice is, if there are no configured (with presence) 
children then set it to "default", but as soon as there is at least one 
configured (with presence) child set it to "intended".

The specification allows any value, and neither choice impart any 
additional useful information to the client, so choose whichever is most 
convenient to implement ...

Thanks,
Rob

---

From: Rohit R Ranade <[email-masked]>
Date: Thu, 27 Sep 2018 11:17:16 +0000

Instead of choosing the origin for non-presence container as "unknown" or any other origin, I would prefer if the rule in annotation definition " The origin for any top-level configuration data nodes must be specified." can be relaxed.

With Regards,
Rohit R Ranade

-----Original Message-----
From: Robert Wilton [mailto:[email-masked]] 
Sent: 27 September 2018 15:19
To: Rohit R Ranade <[email-masked]>; Juergen Schoenwaelder <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] RFC 8342 : Query about NMDA Origin for Non-presence containers

Hi Rohit,

Please see inline ...

On 27/09/2018 10:11, Rohit R Ranade wrote:
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]]
Give the two statements above from Juergen then for a top level np container, the server may return any origin value that it wishes, as long as the correct origin is returned (either implicitly or explicitly) for all descendant nodes that are not np-containers.

One choice would to always set all top level np containers to origin "unknown".

An alternative choice is, if there are no configured (with presence) children then set it to "default", but as soon as there is at least one configured (with presence) child set it to "intended".

The specification allows any value, and neither choice impart any additional useful information to the client, so choose whichever is most convenient to implement ...

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 27 Sep 2018 13:21:17 +0200

> [Rohit R Ranade] So how to decide the origin for the container, when its child may have mixed origin ?

Up to the implementation. An implementation may set origin=default on
nacm and then origin=intended on enable-nacm. This would mean
origin=default for read-default, write-default, exec-default.  It is a
matter of how much effort an implementation wants to spend to reduce
the total number of origin annotations that are needed. There might
also be rather dumb implementations that set origin on every node.

/js