Subject: [netmod] default NP container question

From: Andy Bierman <[email-masked]>
Date: Wed, 5 Dec 2012 14:50:17 -0800

Hi,

I am not sure which RFC should or does say what to do:

container npcon {
   leaf a { type int32; default 42; }
   leaf b { type string; }
}

If you do a <get-config> in normal mode, the 'npcon' container
is not returned.

If you do a <get-config> with-defaults=report-all, the 'npcon' container
is returned:

 npcon {
    a 42
 }

So what happens if you do a create operation on /npcon?

Is this OK or is it a 'data-exists' error?

What about a delete operation on /npcon?

Is this OK or a 'data-missing' error?

Currently, yuma is doing something wrong -- returning both
data-exists on a create and data-missing error on a delete.

What are the correct responses?

thanks,
Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 06 Dec 2012 08:34:43 +0100 (CET)

> I am not sure which RFC should or does say what to do:

6020 _should_.  But it is fuzzy.

> So what happens if you do a create operation on /npcon?

First of all, operationally this is not very useful, since there is no
semantics attached to the presence of such a container.

> Is this OK or is it a 'data-exists' error?

In my implementation this is a data-exists error.  But I can imagine
that an implementation that auto-deletes empty NP-containers would
allow this create (but then probably auto-delete it right away??)

> Is this OK or a 'data-missing' error?

In my implementation the effect is that everything below this NP
container is deleted.  Then if you do a create on the NP container
right after the delete you will still get the data-exists error.

> What are the correct responses?

Unclear.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 6 Dec 2012 07:25:10 -0800

> semantics attached to the presence of such a container.
The code doesn't know which nodes are useful or not,

> allow this create (but then probably auto-delete it right away??)
I think it should be based on what the server returns as its with-defaults
basic mode.  In my case, the create should succeed and the delete should
fail,
because the basic mode does not return the NP container.  It is only
returned
as a default for report-all or report-all-tagged.

> right after the delete you will still get the data-exists error.

So you return the NP containers in 'plain' retrieval requests?
If so this is consistent.

> > What are the correct responses?

Clearly one should fail (create or delete) but not both.

Andy

---

From: "Muthumayan Madhayyan (muthu)" <[email-masked]>
Date: Sun, 9 Dec 2012 16:51:37 +0000

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, December 5, 2012 2:50 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [netmod] default NP container question

Hi,

container npcon {

I read this to mean that if the container npcon gets created, then the leaf 'a' is automatically created with value 42.  If the leaf npcon/b gets created, then both npcon and npcon/a are created.

This is fine.  So, I presume there was never an attempt to create npcon.

 npcon {
    a 42
 }

Is this correct ? Do we really need to return npcon/a when there was no attempt to create npcon in the first place ?

Shouldn't  create on /npcon should be allowed ONLY for containers with 'presence' statement -OR– if a container has immediate descendant leaf nodes with default values (like npcon), the container should automatically become  'presence' containers ?  Creation of the container then makes semantic sense, because creation of npcon automatically creates npcon/a=42.

Deletion of /npcon can result in deletion of all descendant nodes and the container itself  (like Martin had mentioned).

thanks,
Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 9 Dec 2012 09:23:29 -0800

Hi,

NP containers are transparent in some ways.
Since they are just containment nodes, their child nodes
can impact their properties.  A default leaf in an NP-container
causes the NP-container to be a default.
A mandatory child node causes the NP-container to be mandatory.

Yuma doesn't actually handle default NP containers at all (just YumaPro).
After fixing the code, IMO the correct answer is that a create succeeds and
a delete fails on a default NP-container. A delete on a real NP-container
can be immediately replaced by the server.  I agree with Martin that it
is OK for the server to create NP containers and the client needs to check
the with-defaults to use create/delete.  The client can always use
merge/remove
instead and ignore defaults.

Remember that with-defaults=report-all adds nodes in the reply that are
missing
from the server -- these are the defaults in use because no node exists.
The server basic-mode for defaults handling determines if a node exists or
not.

Andy

On Sun, Dec 9, 2012 at 8:51 AM, Muthumayan Madhayyan (muthu) <
[email-masked]> wrote:

>
>
>   From: Andy Bierman <[email-masked]>
> To: "[email-masked]" <[email-masked]>
>  I read this to mean that if the container npcon gets created, then the
> leaf 'a' is automatically created with value 42.  If the leaf npcon/b gets
> created, then both npcon and npcon/a are created.
>
>
>  Is this correct ? Do we really need to return npcon/a when there was no
> attempt to create npcon in the first place ?
>
>
>  Shouldn't  create on /npcon should be allowed ONLY for containers with
> 'presence' statement -OR– if a container has immediate descendant leaf
> nodes with default values (like npcon), the container should automatically
> become  'presence' containers ?  Creation of the container then makes
> semantic sense, because creation of npcon automatically creates npcon/a=42.
>
>
>  Deletion of /npcon can result in deletion of all descendant nodes and
> the container itself  (like Martin had mentioned).
>
>

---

From: "Muthumayan Madhayyan (muthu)" <[email-masked]>
Date: Sun, 9 Dec 2012 18:16:29 +0000

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Sunday, December 9, 2012 9:23 AM
To: Muthumayan M <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] default NP container question

Hi,

I was under the impression that the default settings and mandatory nodes exist only if the immediate parent-node exists.
What happens if the parent node for the container is a list ?  On what basis would the server create a  'default list' ?

the with-defaults to use create/delete.  The client can always use merge/remove

Remember that with-defaults=report-all adds nodes in the reply that are missing
from the server -- these are the defaults in use because no node exists.
The server basic-mode for defaults handling determines if a node exists or not.

Andy

On Sun, Dec 9, 2012 at 8:51 AM, Muthumayan Madhayyan (muthu) <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

container npcon {

 npcon {
    a 42
 }

thanks,
Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 9 Dec 2012 14:54:36 -0800

On Sun, Dec 9, 2012 at 10:16 AM, Muthumayan Madhayyan (muthu) <
[email-masked]> wrote:

> To: Muthumayan M <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
>  I was under the impression that the default settings and mandatory nodes
> exist only if the immediate parent-node exists.
> What happens if the parent node for the container is a list ?  On what
> basis would the server create a  'default list' ?
>
>
Just an NP-container.

Sec 7.5.7 has this text:

   A NETCONF server that replies to a <get> or <get-config> request MAY
   choose not to send a container element if the container node does not
   have the "presence" statement and no child nodes exist.  Thus, a
   client that receives an <rpc-reply> for a <get> or <get-config>
   request, must be prepared to handle the case that a container node
   without a "presence" statement is not present in the XML.

I cannot find any text that says the server MAY create NP containers.
There is text that says an NP container carries no meaning in the data
model.

Andy