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

[Rohit R Ranade <[e-mail]>]

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:[e-mail]] 
Sent: 27 September 2018 15:19
To: Rohit R Ranade <[e-mail]>; Juergen Schoenwaelder <[e-mail]>
Cc: [e-mail]
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:
> Please find inline.
>
> Rohit R Ranade
>
>
> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[e-mail]]
> Sent: 27 September 2018 14:22
> To: Rohit R Ranade <[e-mail]>
> Cc: [e-mail]
> 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:
>> 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 ?
>>
> 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.)
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


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