Subject: [netmod] Confusion about mandatory

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 07 May 2009 14:04:33 -0400

While reading the YANG document again, I have managed to confuse myself 
about the effect of "Mandatory".

In the absence of choice:
I am left unsure as to whether the text in 7.6.4 on the non-choice 
effects of "mandatory" are clear, or correct.
Must there always be something that is not a "non-presence container" 
above the leaf in the tree?  Does the module or submodule count for this 
purpose?
Presumably, all intermediate containers between the leaf and the 
selected ancestor must also exist if the leaf is forced to exist?

In the presence of choice,
suppose that the only element of the choice is a non-presence container. 
  Presumably, if that non-presence container is created, because that is 
which branch of the choice is being taken, then the leaf must exist. 
(i.e. if the leaf has siblings in the container, but no other nodes 
exist in this case?)

Joel

---

From: Andy Bierman <[email-masked]>
Date: Fri, 08 May 2009 13:50:18 -0700

> selected ancestor must also exist if the leaf is forced to exist?

I see what you mean.
Sec. 7.6.4 para 2 does not account for a leaf defined
at the top-level of a [sub]module.  It only talks about
ancestor nodes, and there are none in this case.

> (i.e. if the leaf has siblings in the container, but no other nodes 

This has been a recent topic...
An empty NP-container MAY get deleted by the agent.

If mandatory is true on the choice, then this leads to
a error every time the manager explicitly creates the
empty NP container, but only if the agent deletes
the empty container.  If the agent keeps it, then
it will not be an error (just a no-op).

Lada raised this issue as well.
He is not comfortable with the garbage-in/garbage-out
explanation I came up with -- a choice with just
an NP container doesn't do anything.  It needs
child nodes, either direct or via augment, to
have any semantics.

It's the word 'MAY' above that is causing concern I think.
A manager does not know what the agent will do with
the empty NP container a-priori.

> Joel

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 08 May 2009 17:09:56 -0400

Andy, thanks for responding.
Comment below on the choice issue (and a little more on the general 
issue of no containing presence container):

Andy Bierman wrote:
> Joel M. Halpern wrote:
>> While reading the YANG document again, I have managed to confuse 
>> myself about the effect of "Mandatory".
>>

>> suppose that the only element of the choice is a non-presence 
>> container.  Presumably, if that non-presence container is created, 
>> because that is which branch of the choice is being taken, then the 
>> leaf must exist. (i.e. if the leaf has siblings in the container, but 
>> no other nodes exist in this case?)
>>
> 

Let us suppose that the choice is not itself mandatory.
And that one of the cases is a single NP container (X), which further 
inside has a mandatory leaf.
Presumably, the intent is that if X is created, the mandatory buried 
(possibly via other NP containers) inside it must be created.
But the description for the logic for when a Mandatory element must be 
created talks only about creation of a presence container, or about 
creation of a peer element in a case (within a choice.)  There is no 
peer in the case.  And there is no P-container.

In trying to understand this, I am pretty sure that the point of the 
condition was the converse.  If the containing choice is not exercising 
the case that has the mandatory element, then it does not need to be 
created.

And similarly, if the mandatory element is in a presence container then 
it only has to exist when the presence container itself exists.  (But 
intermediate NP containers do not mask this.)

The text however seems to not deal with the other cases that can occur 
(no NP between the mandatory leaf and the root, no peer in the case.)

I would not be surprised if this relates in part to assumptions about 
when presence needs to be used. But I am unable to deduce those 
assumptions from the text.

Joel

---

From: Andy Bierman <[email-masked]>
Date: Fri, 08 May 2009 14:41:35 -0700

> peer in the case.  And there is no P-container.

Apparently, implementing YANG is the only way
to overcome the confusion. ;-)

The NP-container becomes mandatory when it has
mandatory nodes defined within it.  There is a CLR
preventing augment from adding mandatory nodes.

A sibling (or top-level) NP-container springs
into existence if it contains child nodes which
are default leafs or default cases.
The mandatory property of child nodes within an
NP-container is inherited, but it is not inherited
for P-containers.  The mandatory-stmt is not
allowed for containers, so this is always inherited
for NP-containers. P-containers must always be created
explicitly by the manager (although I think default-case
should be allowed for empty P-containers).

Two of the biggest sources of confusion in YANG are
choices and containers.

    * choice and case exist only in the schema tree,
      never in the XML, so they are transparent
      wrt/ naming, but they affect the actual XML that
      can be present (by grouping properties of siblings),
      which is confusing

    * NP containers exist in the XML, but unlike choice/case,
      they are transparent wrt/ YANG properties, which is confusing

> the case that has the mandatory element, then it does not need to be 

Yes. I think the section on choice-stmt says that somewhere.
Only 1 case is 'visible' at a time.  Unselected cases
are completely ignored. Selecting a new case deletes
all the members of the old case.

The when-stmt XPath expression can change everything of course.
It is especially interesting if false 'when nodes' exist in
the choice and the order nodes are created may impact the
XPath evaluation results (but I digress...)

> assumptions from the text.

I agree the text could be more clear about all
the aspects of the mandatory property.  Maybe
some examples would help.

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 08 May 2009 18:23:46 -0400

After this discussion, I am pretty sure that the text in 7.6.4 about the 
effect of the leaf's mandatory statement is at best misleading, and 
possibly just flat wrong.

As written, if there is no P-container or choice ancestor, there is no 
time when the leaf must exist.
Also as written, if the nearest choice or P-container ancestor is a 
choice in which the specific case leading to this leaf does not have 
"any other node from the case" defined (presumably meaning any one other 
than the one leading to the leaf?)

The following is probably not the right text, but is intended to capture 
what I think is intended:

If we call leaf's closest ancestor with is no a non-presence container 
the "relevant parent", then if the relevant parent exists, or any 
container between the leaf and the relevant parent exists, the leaf must 
exist.  In the absence of a relevant parent, the existence of any 
container between the leaf and the root means that the leaf must exist.
Further, if the relevant parent is a choice, then the leaf must exist if 
either the container in the case containing the leaf exists, or if any 
other  node in the same case with that container exists.

Joel

Andy Bierman wrote:
>>>> leaf must exist. (i.e. if the leaf has siblings in the container, 
>>>> but no other nodes exist in this case?)
>>>>
>>>
>> condition was the converse.  If the containing choice is not 
>> exercising the case that has the mandatory element, then it does not 
>> need to be created.
> 
>> And similarly, if the mandatory element is in a presence container 
>> then it only has to exist when the presence container itself exists.  
>> (But intermediate NP containers do not mask this.)
>>

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 10 May 2009 21:31:31 +0200 (CEST)

Hi Joel,

I will reply to your first and last emails in one go:

"Joel M. Halpern" <[email-masked]> wrote:
> above the leaf in the tree?  Does the module or submodule count for
> this purpose?

No you are right.  Text is missing about this case - if the mandatory
leaf is on the top-level (or it only has np-containers above itself)
then it must always exist.

> no other nodes exist in this case?)

Let's look at an example:

  choice x {
      container a {
          leaf b { mandatory true; ... }
          leaf c { mandatory false; ... }
          leaf d { mandatory false; ... }
      }
      ...
  }

The mandatory node 'a/b' MUST exist if any of 'a/c' or 'a/d' exists.

As Andy wrote, an np-container is transparent to the leafs, so if we
modify the example a bit:

  choice x {
      container a {
          leaf b { mandatory true; ... }
          container cc {
              leaf c { mandatory false; ... }
          }
          container dd {
              leaf d { mandatory false; ... }
          }
      }
      ...
  }

Now 'a/b' MUST exist if any of 'a/cc/c' or 'a/dd/d' exists.

> time when the leaf must exist.

Yes, this must be fixed.

> "any other node from the case" defined (presumably meaning any one
> other than the one leading to the leaf?)

I don't understand this concern.  I think a 'then' clause is missing
from your 'if' above...

> The following is probably not the right text, but is intended to
> capture what I think is intended:
> 
> container between the leaf and the relevant parent exists, the leaf
> must exist.

s/or any container between the leaf and the relevant parent exists//

...since such a container by definition must be a np-container, and
they are transparent.

> In the absence of a relevant parent, the existence of any

Again, since such a container must be a np-container, this should be:

  In the absence of a relevant parent, the leaf must exist.

> Further, if the relevant parent is a choice, then the leaf must exist
> if either the container in the case containing the leaf exists, or if
> any other node in the same case with that container exists.

I believe the text in 7.6.4 is correct in this case:

  If this ancestor is a case node, the leaf MUST exist if any other
  node from the case exists.

So, I believe the only fix we need is the text about the leaf on the
top-level.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 10 May 2009 12:41:20 -0700

> Now 'a/b' MUST exist if any of 'a/cc/c' or 'a/dd/d' exists.

I implemented this differently.
According to the draft -- I think.

If /a exists, then all the child nodes
of /a will be 'instance-checked'.

That way, if /a is given in a create request,
it will fail because /a/b is missing.
This corner-case has nothing to do with the
siblings of 'b'.

....

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 10 May 2009 22:00:51 +0200 (CEST)

> of /a will be 'instance-checked'.

It seems we may have some inconsistencies in the draft.  If so they
must be fixed.

Which text in the draft leads to the conclusion that if 'a' exists
then 'a/b' MUST exist?  (I think 7.6.4 is clear in this regard)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 10 May 2009 13:58:29 -0700

> then 'a/b' MUST exist?  (I think 7.6.4 is clear in this regard)

What difference does it make if /a is a P or NP container?
If the manager explicitly creates /a then it is responsible
for doing it correctly.

What if leaf b were the only child of /a?
What if the other leafs are added by augment
and all unrelated to 'b', and all optional?

It is better the flag /a/b as a missing node
that just silently delete /a.  The agent needs
to convey "there is a way to configure the /a subtree,
but that isn't it."

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 10 May 2009 23:21:14 +0200 (CEST)

> What difference does it make if /a is a P or NP container?

It makes all the difference!  By definition an NP container has no
semantic meaning.

I will ask the question again - is there any text in the draft that
leads to the conclusion that if 'a' exists then 'a/b' MUST exist?

> and all unrelated to 'b', and all optional?

Then if the client creates one of these augmented nodes, it would have
to create 'a/b'.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 10 May 2009 14:45:10 -0700

> leads to the conclusion that if 'a' exists then 'a/b' MUST exist?

3.1.  Mandatory nodes

    A mandatory node is one of:

    o  A leaf or choice node with a "mandatory" statement with the value
       "true".

I think the text in other sections (like 7.6) about
P containers only is wrong.

> Then if the client creates one of these augmented nodes, it would have

What if 'b' is the only child?
What if there are only mandatory leafs?

   container a {
     leaf b { mandatory true; type string; }
   }

Containers are not transparent in the XML like choices
and cases.  If the manager creates a container node,
whether it is a P or NP container, then all of the
tests for mandatory (mandatory-stmt, min-elements, etc.)
need to be checked for all the nodes defined within
the container.

What if a data modeler wants to add a layer of hierarchy
in the XML just because they want it, (i.e., NP container)
and they have 50 mandatory leafs to put in it,
but no optional leafs?  The agent cannot issue
an error for any missing leafs until (and if)
one of the leafs is created?  This seems very
confusing to the manager.

I do not understand why there should be any
difference between the mandatory tests for
descendants of P vs. NP containers, once
the manager has created an instance of the container.
These P/NP containers are complicated enough already.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 11 May 2009 09:04:23 +0200 (CEST)

> >>>>> Now 'a/b' MUST exist if any of 'a/cc/c' or 'a/dd/d' exists.

[...]

> What if 'b' is the only child?

Then the mandatory statement has no real effect.

> What if there are only mandatory leafs?

Then all of them must exist.

> These P/NP containers are complicated enough already.

This only happens when there is a np container directly under a case,
and the client tries to create only this node.  We discuessed this
earlier in another thread in some detail.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 11 May 2009 02:29:12 -0700

> Then all of them must exist.

but according to your CLR,
the agent is NOT ALLOWED to report any error
about the missing leafs until one of them is entered.
This seems rather broken from an operational POV.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 11 May 2009 02:56:32 -0700

> earlier in another thread in some detail.

I think it happens anytime an empty NP container
gets created.

I think I see your concern, and wonder if it
an implementation detail or needs to be mentioned
in the draft.

This affects the 'commit-test' (or edit-config on running).
If the internal code removes empty NP containers before
checking for missing instances, then the error for the
missing '/a/b' leaf will never get generated.  If the
agent chooses to keep NP containers around, then the
missing leafs are an issue.

The current rule allows the empty NP container to hang around
without any impact on the validity of the data model.
I'm not sure I like this approach better than
simply requiring the agent to remove empty NP containers.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 11 May 2009 12:24:06 +0200 (CEST)

> I think it happens anytime an empty NP container

But if it's not under a case, then it's either on the top-level, or
under a list or p-container.  A typical example to illustrate:

   list server {
      key id;
      leaf id { ... }
      container address {
          leaf ip { mandatory true; ... }
          leaf port { mandatory true; ... }
      ...
   }

Now, when a server instance gets created, values for address/ip and
address/port MUST be provided, regardless of whether 'address' gets
created empty or not.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 11 May 2009 11:40:51 +0200 (CEST)

> about the missing leafs until one of them is entered.

I should have written:

  Then all of them must exist if any one exist.

/martin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 May 2009 11:47:09 -0400

Let me try restating with an example, both to indicate what I think the 
point is, and what I think the problem is.
(Apologies if I get the syntax slightly wrong.  Also sorry for the length)

Suppose we have two container definitions, which appear may appear in 
various places.

container a {
     container b {
          .....
         leaf c { mandatory; type int; description ...}
     }
     container d {
         ...
         leaf e { content, not mandatory ...}
     }
}

container ax {
     container bx {
         presence
         ...
         leaf cx { mandatory; type int; description ...}
     }
     container dx {
         ...
         leaf ex { content, not mandatory ...}
     }
}

Now, if a is in the top level of a module, and a user  attempts to do a 
create operation on a/d/e, it seems to me that the point of c being 
mandatory is that a/b/c has to also be created (by the user) at the same 
time.

Conversely, if ax is in the top level of a module, and a user attempts 
to create ax/dx/ex, the fact that bx is a presence container means that 
ax/bx/cd does not need to be created at that time.  ax/bx/cx needs to be 
created either when the user want sot create it explicitly, or when the 
user wants to create some sibling of cx in bx.

The problem that far is that the document simply does not talk about 
what happens when there is no parent presence container.  And it does 
not suffice to treat the module as a presence container that is created 
whenever anything in it is created, because that would mean that if a 
above is defined in the top level of the module, that defining anything 
else (outside of a) that is also in the module would trigger the 
requirement that a/b/c be created by the user.

In a choice,
there is a similar, but not identical problem.

choice f {
     case g:
          insert container a here
          with no other siblings

     case h:
          some other options
}

As written, since a has no siblings in g, if the user goes to create 
a/d/e, there is no requirement that a/b/c must be created at the same 
time.  But if a had other siblings in the choice, creating one of them 
would trigger a requirement for the user to also create a/b/c.  The 
given requirement makes sense.  It is the exclusion of the first 
requirement that I can not understand.
(One way of looking at this case is that if the non-presence container 
had not been used, b/c would have siblings (d) in the case, so that the 
creation of d/e would have triggered the check for b/c.)

To phrase this differently, the mental model I have starts from
a non-presence container is conceptually created whenever any element 
inside it is created.  As a corollary, if we determine that a 
non-presence container is being created, any of its parent containers 
are also being created.
Mandatory checking is triggered by creation of the environment in which 
the mandatory element is defined.  However, this environment is 
constrained by the closest choice or presence container.
So when a container (presence or non-presence, list, choice case ...) is 
created, the mandatory checker checks if there are any mandatory 
elements in scope, where scope is everything inside that container that 
is not shielded by a suitable other container (list, case, presence.)

There may well be an argument that the cases I am describing represent 
bad design.  But I think we still have to understand what the tag means 
in those cases.

Yours,
with unfortunate excess verbosity,
Joel

---

From: Andy Bierman <[email-masked]>
Date: Mon, 11 May 2009 09:41:12 -0700

>         leaf ex { content, not mandatory ...}

I do not think it is a 'feature' that containers
behave differently in so many contexts.

What if your container 'b' (or other sub-tree)
was derived from a uses-stmt?  The mandatory
property of node 'b/c' was written without any
knowledge of container 'd'.

    grouping B {
      container b {
         leaf c { mandatory true; ... }
      }
    }

    container a {
      uses B;
      container d { ... }
    }

There is no intent by the data modeler to couple
the existence of leaf 'c' with leaf 'e', but that
is exactly what an NP container does.  Only the
NP container (dx) gives the expected behavior.

That means container 'b' will become mandatory (or not)
depending on the siblings and any ancestors of the uses-stmt.

There should really only be two type of containment
that need to be considered within a NETCONF database:

    1 - XML nodes associated with a top-level data node
    2 - XML nodes associated with a child of a top-level data node

In case (1) there is clearly no intent to couple
the existence semantics for any sibling nodes.
Just the opposite in case (2).

Only lists and containers can have any child nodes.
Anyxml nodes do no count.  Lists and P-containers behave
as expected, but not NP-containers.

Does this mean everybody will define containers as P-containers
just to be safe? Or will data modelers just get it wrong,
and complain when "sometimes it works and sometimes it doesn't"?

 >... [ skipping 2nd half for now]

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 11 May 2009 10:19:48 -0700

Andy Bierman wrote:
> Joel M. Halpern wrote:
>> Let me try restating with an example, both to indicate what I think 
>> the point is, and what I think the problem is.

s/NP container (dx)/P container (dx)/

> Just the opposite in case (2).

There is no intent in case 1 to couple
nodes from other YANG modules.  Within
a single YANG module, it may be the intent
(e.g., a top-level choice creates associated
sibling nodes at the top-level).

>> Now, if a is in the top level of a module, and a user  attempts to do 
>> a create operation on a/d/e, it seems to me that the point of c being 
>> mandatory is that a/b/c has to also be created (by the user) at the 
>> same time.
>>
>> to create ax/dx/ex, the fact that bx is a presence container means 
>> that ax/bx/cd does not need to be created at that time.  ax/bx/cx 
>> needs to be created either when the user want sot create it 
>> explicitly, or when the user wants to create some sibling of cx in bx.
>>
>> not suffice to treat the module as a presence container that is 
>> created whenever anything in it is created, because that would mean 
>> that if a above is defined in the top level of the module, that 
>> defining anything else (outside of a) that is also in the module would 
>> trigger the requirement that a/b/c be created by the user.
>>

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 11 May 2009 21:19:37 +0200 (CEST)

"Joel M. Halpern" <[email-masked]> wrote:
> Let me try restating with an example, both to indicate what I think the point
> is, and what I think the problem is.
> Suppose we have two container definitions, which appear may appear in various
> places.
> 
> container a {
>      container b {
>           .....
> Now, if a is in the top level of a module, and a user attempts to do a create
> operation on a/d/e, it seems to me that the point of c being mandatory is that
> a/b/c has to also be created (by the user) at the same time.

Actually, if a is in the top level, the effect of having a/b/c as
mandatory is the same as if c was a mandatory leaf on the top level -
an agent that implements this module will require that a/b/c always
exists.

> Conversely, if ax is in the top level of a module, and a user attempts to
> create ax/dx/ex, the fact that bx is a presence container means that ax/bx/cd
> does not need to be created at that time.  ax/bx/cx needs to be created either
> when the user want sot create it explicitly, or when the user wants to create
> some sibling of cx in bx.
> 
> The problem that far is that the document simply does not talk about what
> happens when there is no parent presence container.

Yes, as I said in my earlier email, I agree that this is a problem
that must be addressed.

> As written, since a has no siblings in g, if the user goes to create a/d/e,
> there is no requirement that a/b/c must be created at the same time.

The intention is that a/b/c must be created in this case.  Following
7.6.4, the closest ancestor node to f/g/a/b/c in the schema tree which
is not a p-container is f/g (the case node).  Then 7.6.4 says 

And in this case the nodes f/g/a, f/g/a/d and f/g/a/d/e exist, so it
follows that f/g/a/b/c also must exist.

> a non-presence container is conceptually created whenever any element inside it
> is created.

Yes, and further that np containers are really transparent - you get
the same effect by removing all np containers (modulo the object's
names of course).

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 11 May 2009 14:11:19 -0700

> an agent that implements this module will require that a/b/c always

OK (agreed) -- and if a/b/c is inside:

   - case: then it is mandatory when its case is selected
     (one of its siblings in the case is present)

   - list: will be mandatory in any list with a key,
     since 'a' is a sibling of the key(s)
     (what about a list without any keys, read-only?)

   - P-container: will be mandatory if the P container
     is created by the manager

   - NP-container: logic transferred up one layer,
     not decided here? Or is 'a' mandatory if
     it has any siblings created in the NP-container,
     regardless of the existence of its parent NP container?

still confused...

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 11 May 2009 23:39:29 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> >> various
> >> create

Yes.

>      since 'a' is a sibling of the key(s)

Yes.

>      (what about a list without any keys, read-only?)

They a/b/c must be present in a (idealized) <get> reply.  (see Section
8)

>      is created by the manager

Yes.

>    - NP-container: logic transferred up one layer,

Yes.

>      regardless of the existence of its parent NP container?

If a has siblings created, their common parent will also be created
(so yes, this implies that if any sibling to a is created then a/b/c
must also be created).

(But I still prefer not to think of this as 'a' being mandatory - it
is a/b/c that is mandatory, and from this it follows that a and b also
will be created. )

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 11 May 2009 17:01:41 -0700

> (so yes, this implies that if any sibling to a is created then a/b/c

yes, of course;
I should have said 'not just the existence of the parent'.

> is a/b/c that is mandatory, and from this it follows that a and b also

OK

So what was the original answer given to Phil when
he complained that leaving empty NP containers
in the config database was not OK, and they MUST
be removed?

That is, only empty P (not NP) containers should take up
space is a valid config because they have 1 bit of semantics,
whereas an NP-container has 0 bits.

That seems like a good idea to me.
(I don't know what edits would be needed however.)

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 11 May 2009 21:57:17 -0400

(Leaving the text below, after my response, if someone wants the full 
context.)

With regard to the case where the non-presence container is in the top 
level,
a) What you assert about the mandatory leaf always being mandatory is 
not at all what the document says.  (I am not sure whether your later 
comment about the text needing clarification was intended to say that.)

b) It is not particularly obvious to me that making that leaf always 
mandatory is in any way related to what people would expect.  But at 
least if we write it clearly, folks will know what to do.  (If they 
don't want it always mandatory, make the top level container a presence 
container.)

With regard to the choice/case issue, your udnerstanding of the text 
from the document:
    If this ancestor is a case node, the leaf MUST exist if any other
    node from the case exists.
that this applies to sibling inside the container, as well as to 
siblings at the case, agrees with what I think is the behavior we want.
However, it is not the meaning I get from the face of the words.  I was 
looking for other nodes, other than the one containing the leaf, in the 
case.  If we agree on the meaning, please improve the words.

Thank you,
Joel M. Halpern

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 12 May 2009 14:29:28 +0200 (CEST)

"Joel M. Halpern" <[email-masked]> wrote:
> With regard to the case where the non-presence container is in the top level,
> a) What you assert about the mandatory leaf always being mandatory is not at
> all what the document says.  (I am not sure whether your later comment about
> the text needing clarification was intended to say that.)

It was.  See below.

> b) It is not particularly obvious to me that making that leaf always mandatory
> is in any way related to what people would expect.  But at least if we write it
> clearly, folks will know what to do.  (If they don't want it always mandatory,
> make the top level container a presence container.)

For the rationale, consider this example with two mandatory leafs:

  leaf ip {
      mandatory true;
      type inet:ip-address;
  }
  leaf port {
      mandatory true;
      type inet:port-number;
  }

When their relevant parent node is created, they must also be
created.

Now, suppose I want this behavior, but for organizational reasons, I
want to wrap these leafs in a container:

  container address {
      leaf ip {
          mandatory true;
          type inet:ip-address;
      }
      leaf port {
          mandatory true;
          type inet:port-number;
      }
  }

The semantics are the same - whenever the relevant parent node is
created, the two leafs must be created.

The same rules should apply to top-level nodes - if I have:

  module system {
      ...
      leaf sys-name {
          mandatory true;
          type string:
      }
      ...
  }

The leaf 'sys-name' must exist in a server which implements the
'system' module.

With an organizational wrapper container:

  module system {
      ...
      container sys {
          leaf name {
              mandatory true;
              type string:
          }
          ...
      }
      ...
  }

The leaf /sys/name must always exist.

I suggest the following change to 7.6.4:

OLD:

   If "mandatory" is "true", the behavior of the constraint depends on
   the type of the leaf's closest ancestor node in the schema tree which
   is not a presence container (see Section 7.5.1):

   o  If this ancestor is a case node, the leaf MUST exist if any other
      node from the case exists.

   o  Otherwise, the leaf MUST exist if the ancestor node exists.

NEW:

   If "mandatory" is "true", the behavior of the constraint depends on
   the type of the leaf's closest ancestor node in the schema tree which
   is not a presence container (see Section 7.5.1):

   o  If no such ancestor exists, the leaf MUST exist.

   o  Otherwise, if this ancestor is a case node, the leaf MUST exist
      if any other node from the case exists.

   o  Otherwise, the leaf MUST exist if the ancestor node exists.

> With regard to the choice/case issue, your udnerstanding of the text from the
> document:
> that this applies to sibling inside the container, as well as to siblings at
> the case, agrees with what I think is the behavior we want.
> However, it is not the meaning I get from the face of the words.  I was looking
> for other nodes, other than the one containing the leaf, in the case.  If we
> agree on the meaning, please improve the words.

Can we just remove the word 'other' and get:

   o  Otherwise, if this ancestor is a case node, the leaf MUST exist
      if any node from the case exists.

/martin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 12 May 2009 11:03:02 -0400

The combined set of changes below work for me.

Thank you,
Joel

PS: Thinking about it over night, making a leaf which is marked 
mandatory and in the module itself via non-presence containers mandatory 
is actually quite reasonable.  Your example makes sense to me.  Thanks.

---

From: WashamFan <[email-masked]>
Date: Wed, 13 May 2009 09:28:13 +0800

>     is not a presence container (see Section 7.5.1):
                  ^^^^^^
I assume it was a typo, it should have been "non-presence" instead, right?

washam

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 13 May 2009 08:41:25 +0200 (CEST)

> I assume it was a typo, it should have been "non-presence" instead, right?

Yes, typo.  I copy&pasted from the published draft, but in my sources
I have your fix.  It should be "non-presence".

/martin