Subject: [netmod] Comments on draft-01

From: Balazs Lengyel <[email-masked]>
Date: Fri, 29 Aug 2008 15:06:35 +0200

Hello Martin,

 From draft-01:

When a module includes a submodule, it incorporates the contents of
    the submodule into the node hierarchy of the module.  When a
    submodule includes another submodule, the target submodule's
    definitions are made available to the current submodule.

What is the difference between:
"incorporates the contents of the submodule into the node hierarchy of the module" and
"the target submodule's definitions are made available to the current submodule"

If I put the root container into submodule1 and include that from submodule2 which of the two 
am I doing?

----------------------------------------------------------------------

7.5.2

    If the node with the must statement represents configuration data,
    any node referenced in the XPath expression MUST also represent
    configuration.

What is the sense of putting a must on status data? I can understand a use case for mixed state 
and config, but what is the use case for pure state based must.

On the other hand having a must on rpc parameters (a 3rd type of data beside config and state) 
seems also reasonable.

-------------------------------------------------------------------

7.8.3
I think putting "unique" on state data should be forbidden following the same logic as must. 
Actually min-max for state type lists/leaf-lists is also more an indication then a 
requirement/check.

------------------------------------------------------------------

7.9.3
"There MUST NOT be any mandatory nodes (Section 3.1) under the default case."

Doesn't that forbid the following? After all name is mandatory and is under the default case. 
Maybe add the word "directly".

choice foo {
   case aaa {
     ...
   }
   default {
     list bar {
       key id;
       leaf id;
       leaf name {
         mandatory true;
         type string;
       }
     }
   }
}

----------------------------------------------------------

7.13.2

"If a "config" or "must" statement is present for any node in the
    input tree, it is ignored."

Why did we disallow must? I see it perfectly reasonable to have restrictions between the 
parameters of the RPC.

-------------------------------------------------------

7.1`3.5
A reply example with data would be better

------------------------------------------------------

7.15

Can you augment an the following rpc ?

rpc shortCommand ;

I found this only in the change log.

-------------------------------------------------------

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

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 29 Aug 2008 15:26:07 +0200 (CEST)

> "incorporates the contents of the submodule into the node hierarchy

This is what happens when the module includes a submodule - all data
definitions, rpcs, notifications, etc gets "copied" / "incorporated"
into the module.

> "the target submodule's definitions are made available to the

This is what happens when a submodule includes a submodule.  It just
gives the submodule access to the definitions so that it can refer to
them.

On my TODO list is also adding the proposed clarification text from
Andy on submodules, but it is pending the outcome of yang-00755
(prefix on belongs-to).

> If I put the root container into submodule1 and include that from
> submodule2 which of the two am I doing? 

the latter.

> What is the sense of putting a must on status data? I can understand
> a use case for mixed state and config, but what is the use case for
> pure state based must.
> 
> On the other hand having a must on rpc parameters (a 3rd type of
> data beside config and state) seems also reasonable. 

There are a couple of statements that may or may not make sense in
different places.  must might not make sense in state data.  mandatory
is another example.   We need to work through all these, hopefully at
the interim.

> I think putting "unique" on state data should be forbidden following
> the same logic as must. Actually min-max for state type
> lists/leaf-lists is also more an indication then a
> requirement/check.

See above.

> Doesn't that forbid the following?

No.  See the reference (3.1) for a definition of the term "mandatory
node". 

> Why did we disallow must? I see it perfectly reasonable to have
> restrictions between the parameters of the RPC.

This is also one of the statements we have to decide if we want to
allow or not.

There is one in 4.2.9, which I now realize is wrong.  I'll fix it in
-02.

Yes, this is covered in the second paragraph of 7.13, and the normal
rules for augment (i.e. you can augment any existing node, and the rpc
statement creates the input and output nodes).

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 29 Aug 2008 15:56:31 +0200

> gives the submodule access to the definitions so that it can refer to
Sorry but I still don't see the real difference. Maybe some examples could help.

choice foo {
   case aaa {
     ...
   }
   default {
     list bar {
       key id;
       leaf id;
       leaf name {
         mandatory true;
         type string;
       }
     }
   }
}

name is mandatory as in 3.1:  "A leaf or choice node with a "mandatory" statement with the 
value "true".
name is under the default case.
The text does NOT say it has to be directly under default.
So I don't agree with you
"

> statement creates the input and output nodes).
"The "rpc" statement defines an rpc node in the schema tree.  Under
    the rpc node, an input node with the name "input", and an output node
    with the name "output" are also defined.  The nodes "input" and
    "output" are defined in the module's namespace."

"The "input" statement, which is optional, "

These don't really tell me that the input is there even if it is not included in the YAM. 
Please consider rewording later.

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 29 Aug 2008 16:11:27 +0200 (CEST)

Balazs Lengyel <[email-masked]> wrote:
> Doesn't that forbid the following? After all name is mandatory and
> is under the default case. Maybe add the word "directly". 

I'll add the word "directly", unless someone else objects.

> These don't really tell me that the input is there even if it is not

In this text:

     The "rpc" statement defines an rpc node in the schema tree.  Under
     the rpc node, an input node with the name "input", and an output node
     with the name "output" are also defined.

isn't it clear that there is an input node called "input"?

Note that the "input" statement no longer defines the input node, it
merely adds nodes under the existing input node.

> Please consider rewording later.

I'm open to suggestions to make the text better.

/martin