Subject: [netmod] choice/config

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 03 Mar 2009 14:23:37 +0100

Hi,

section 7.19.1 doesn't address the case when "config" is a substatement
of choice. This could be added as a second paragraph in this section:

As a substatement of "choice", the "config" statement applies to all
data nodes in all cases of the "choice" statement.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 04 Mar 2009 21:27:52 +0100 (CET)

> data nodes in all cases of the "choice" statement.

I assume that you think choice is not covered because a 'case' cannot
have a config statement?  The text says 

  If "config" is not specified, the default is the same as the parent
  node's (in the data model) "config" value.  

which implies that in:

  choice a {
    config false;
    case b {
      leaf c { ... }
    }
    ...
  }

node c's config value would be that of node b, but since node b is a
case node, which doesn't have a config property, thus we don't know
c's config value.

Another solution could be to state that a case node always inherits
its parent choice's config property.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 05 Mar 2009 08:09:55 +0100

>   node's (in the data model) "config" value.  

Shouldn't "data model" actually be "data tree"? If so, I don't think
'choice' belongs to the data tree. Also, the formulation in sec. 7.19.1
clearly doesn't apply to 'choice':

If "config" is "true", the definition represents configuration, and will
be part of the reply to a <get-config> request, and may be sent in a
<copy-config> or <edit-config> request. If "config" is "false", it
represents state data, and will be part of the reply to a <get>, but not
to a <get-config> request.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Mar 2009 08:37:21 +0100 (CET)

> to a <get-config> request.

How about this:

The "config" statement takes as an argument the string "true" or
"false".  If "config" is "true", the definition represents
configuration.  Data nodes representing configuration will be part of
the reply to a <get-config> request, and can be sent in a
<copy-config> or <edit-config> request.

If "config" is "false", the definition represents state data.  Data
nodes representing state data will be part of the reply to a <get>,
but not to a <get-config> request.

If "config" is not specified, the default is the same as the parent
schema node's "config" value.  If the parent node is a "case" node,
the value is the same as the "case" node's parent "choice" node.

If the top node does not specify a "config" statement, the default is
"true".

If a node has "config" "false", no node underneath it can have
"config" set to "true".

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 05 Mar 2009 08:49:49 +0100

> > to a <get-config> request.

Yes, this is much better, the previous text also implies that the
definition itself will be part of PDUs, which is a nonsense. It could be
made even easier if 'config' was also allowed with 'case'. Would it be a
problem?

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C