Subject: [netmod] tconfig

From: Andy Bierman <[email-masked]>
Date: Sun, 30 Aug 2009 00:43:35 -0700

Hi,

ops-nm: 2007-06-06
http://www.ietf.org/mail-archive/web/ops-nm/current/msg00105.html

netconf: 2007-06-08
http://www.ietf.org/mail-archive/web/netconf/current/msg02591.html

I guess I am irritable about this 'config/state' issue
because I brought up this exact issue at least 2 years
ago, and I was told I was wrong -- there are only 2 states.

I brought up the issue again with the YANG design team and
was told I was wrong again -- no, we only need a boolean.

I had something called 'transient config' in NCX, long before YANG.
IMO, it exactly describes the 3rd state (see 1st msg above).

Instead of config=true/false, NCX had config=config/tconfig/state.

Transient config can be set at any time by the client or the
server, but it is never saved in NV-storage.

Maybe the terminology needs work, but the mechanism exactly
says what Juergen wants -- to edit ifMtu but not save it
as part of the configuration.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 30 Aug 2009 20:35:53 +0200 (CEST)

> as part of the configuration.

I don't think this would solve the problem.  In the ifMtu case, the
problem is that even if no such leaf exists in the config, the device
will still operationally choose a proper value.  As another example,
if the "duplex" leaf is configured to the value 'auto', the
operationally choosen value might be 'half'.  This is not transient
config.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 31 Aug 2009 15:35:33 +0200

> will still operationally choose a proper value.  As another example,

This can still be understood in two different ways: either the server
sets only the operational value and the config parameter remains unset,
or it sets the config parameter and the operational one gets set to the
same value as a result if this.

The recent examples demonstrate various interactions between config and
operational parameters, e.g.

- IP address configured either manually (from a config item) or via DHCP
- use global value if local is not set (hold-time example)
- operational routing table is a union of static routes (config item)
  and routes obtained from routing protocols

These relations between config and operational items seem to be quite
important from the data modeling point of view - but can we express all
possible variants?

Lada

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 31 Aug 2009 16:41:13 +0200 (CEST)

> same value as a result if this.

IMO the latter would be very confusing.  You set 'duplex' to 'auto'
and you do a get-config, maybe for archival purposes.  If you get back
anything but 'auto', it would be incorrect.

> important from the data modeling point of view - but can we express all

It can be done today using standard techniques with duplicate objects
(ifMTU and ifMTU-oper etc).

An alternative could be to work on a more generic solution, but I
think this requires protocol support (<get-operational> or something),
and modelling support.  But I don't think this is a must-have for YANG
1.0.  We don't even know what such a solution would look like, so if
anything, we could encourage people to work on the problem, using
NETCONF and YANG extensions.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 31 Aug 2009 17:56:34 +0200

> anything but 'auto', it would be incorrect.

Maybe in this case, in other cases it may be appropriate, e.g. for
initial (static) IP address.

> (ifMTU and ifMTU-oper etc).

You can use leafref in YANG if they are directly coupled, but the more
complex scenarios cannot be easily captured, except in descriptions -
and I am not saying they should be, unless we have a really flexible way
to do it.

> NETCONF and YANG extensions.

I agree, and from my point of view current YANG is OK as a
domain-specific XML schema language - we can decide whether a given
configuration is valid according to a data model, whether two
configurations are equivalent given the set of declared defaults etc.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 31 Aug 2009 09:45:44 -0700

> configurations are equivalent given the set of declared defaults etc.

I also agree, but only if the definition of a default is confined
to the YANG default-stmt value, for all YANG modules advertised
in the module capabilities.

As long as every leaf instance is retrievable by the client somehow,
then the current draft is fine.  I can accept that the configuration
is just the leaf instances that do not have the YANG default-stmt
value.  If the current value of every leaf instance is retrievable
on every NETCONF server, then it is OK if the description statements
are needed to correlate the leaf instances.

Asking the server to deduce the value of any current leaf instance
value is the only non-starter still floating around at this time.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 31 Aug 2009 09:51:04 -0700

Hi,

> Asking the server to deduce the value of any current leaf instance
             ^^^^^^
> value is the only non-starter still floating around at this time.

oops -- I meant client (trying hard to avoid manager and agent!)

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 31 Aug 2009 20:34:47 +0200

> in the module capabilities.

Absolutely, and with-defaults draft should include YANG-specific
normative text.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 31 Aug 2009 12:52:25 -0700

> Absolutely, and with-defaults draft should include YANG-specific

yes, but I am not sure how deviations work with this definition
of a default.

I think there are only 2 implementations that include deviation-stmt
at this time, and we both implemented deviations as a patch.
Once the run-time schema tree is patched, does this count as the
new contract, including defaults?

That's what I was afraid of when I objected to deviations
so strongly in the first place.

standard says:

   leaf foo {
     type string;
   }

If the deviations add/replace/delete a default, does
that count as the new default, or does that count as
a server-created instance with a non-default value?
The deviations were not supposed to allow the contract
to be altered, just identify the ways the server
is non-compliant.

The schema language is the component that adds
semantics to the standard syntax.  We are making a big
departure from SNMP robustness principles by requiring
a client to have a complete and accurate set of schema
definitions and deviations, just to obtain a complete set of
operational data values from a particular server.

A human or a dumb 'MIB walker' could make use of the complete
output, especially in XML, because the object hierarchy is
clearly identified and (except for binary) the built-in content
is all readable.  This definition of 'all' includes YANG defaults.

I am also concerned that vendors will not advertise the
critical deviation modules for standard modules, because
that (by definition) means the vendor does not comply with
the standard.  The deviations for the vendor's own YANG modules
will be quite rare in comparison, since they have total
ownership of that content.

I am also concerned about the fact that revision statements
are purely optional to use (outside of standard modules).
Then, if the vendor changes a default over time, the client
has no clue which leaf-stmt to pick to decide if
a missing leaf has a default, and its true value.

(Still want to stake your job on those default-stmt values. operators?)

Andy