Subject: Re: [netmod] defaults - needed updates

From: "tom.petch" <[email-masked]>
Date: Tue, 2 Dec 2008 18:07:44 +0100

I haven't seen a follow up to this which seems a shame since it (re-)raises
something already much discussed but about which a consensus seems
hard to reach.  I refer to the section at the end (before the text repeats
itself) describing three incompatible views of config and defaults, and then
saying that YANG must accommodate them all.  This does seem to me to be rather
optimistic for YANG, where there are already murmurings about constraining the
options because it is so complex and yet, post interim, still wanting to be all
things to all (or at least three) men.

How this specific issue gets resolved I do not know. That it is unresolved - and
it has occurred several times on this list - seems a flaw in YANG, or perhaps in
the process of this WG.

For myself, the approach attributed to Mr Juniper (we are all of course here as
individuals) seems closest to sensible, that of Mr Cisco the least.

Tom Petch

----- Original Message -----
From: "Balazs Lengyel" <[email-masked]>
To: "NETMOD Working Group" <[email-masked]>
Sent: Wednesday, October 29, 2008 12:29 AM
Subject: [netmod] defaults - needed updates

> We agreed on the Reston interim on the following  about the handling
> of defaults
>
> Management agents report default data in different ways.
>     o  Report all: All default data is always reported.
>     o  Trim: Values are not reported if they match the default.
>     o  Explicit: Report values if they are explicitly set.
>
> We want to accommodate all in YANG.
>
> I got the task of proposing some specific additions to the draft. Here they
are with some explanation.
> Balazs
>
> ----------------------------------------------------------------
>
> Defaults potentially effect the following stuff:
>
> 1) concept of the default
> Solution:
> ==== ADD:
> Add to "7.6 The leaf Statement"
> "Leafs with a default value, may or may not exist in the conceptual datastore.
"
>
> 2) get-config/get reply content
> - Implement the Netconf with-defaults extension, this can
> force all default values to be returned. I will take the draft to NETCONF.
> ===== ADD:
> reference to the with-defaults draft.
>
> 3) evaluation of the must/when/unique constraints
> - "7.8.3 The list's unique Statement" must be extended:
> ===== ADD:
> "The unique constraint is conceptually evaluated on all nodes in the
> data tree, and all leafs with default values."
>
> must and when are already OK
> leafs with defaults are considered as existing during the evaluation
> of must/when
>
> 4) Are the must constraints on a default leafs evaluated
> Already OK
>
> 5) success of edit-config create/delete
> Different nodes might give different answers to an edit-config
> operation, but this is not crucial. Error on delete is
> not important. Instead of create: replace or merge can be used.
> The different behavior is a consequence of 1). It can be described as a
> capability in the with-defaults draft.
> (The manager has the option to just ignore the capability.)
>
> 6) Existence of np-containers
> Already OK
> Depends on whether default leafs exist. No additional text needed.
>
>
> 3 models of handling defaults:
>
> Juniper) defaults don't exist, but if you explicitly set a leaf
> to its default it exists. Configuration is what you have sent in
> edit-config.
>
> Cisco) defaults don't exist. if you explicitly set a leaf to its
> default it disappears. Configuration is everything without defaults.
>
> Ericsson) Defaults always exist. Configuration is what drives
> the device.
>
> We want to accomodate all in YANG.

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

---

From: Phil Shafer <[email-masked]>
Date: Tue, 2 Dec 2008 13:51:57 -0500

"tom.petch" writes:
>How this specific issue gets resolved I do not know. That it is
>unresolved - and it has occurred several times on this list - seems
>a flaw in YANG, or perhaps in the process of this WG.

The plan is to give wiggle room for servers to behave in their
native manner.  When the current (or incoming) value is identical
to the declared default, the server can ignore it.

For <get-config>, this means if the leaf was previously set to the
default value, the value need not be present in the reply, and if
the leaf was deleted (or never created) the default value is allowed
to appear in the reply.

For <edit-config>, this means if the value is equal to the default,
the server can avoid creating it.  It also means that create and
delete operations need to not give errors in circumstances where
defaults are involved.  Create operations should not fail if the
leaf exists but contains the default value, and delete operations
should not fail if the leaf does not exist, since if could have
been set to the default value.

These are odd rules, but seem to cover default-related behavior in
a way that allows all three default-handling models in a workable
compromise.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 02 Dec 2008 20:54:15 +0100 (CET)

Phil Shafer <[email-masked]> wrote:
> native manner. 

And I think that the draft now does that.  The missing piece of the
puzzle is the :with-defaults capability, which is worked on in the
NETCONF WG.  It is needed for the device to report to the manager how
it handles default values natively.

/martin

---

From: "tom.petch" <[email-masked]>
Date: Thu, 4 Dec 2008 18:50:30 +0100

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, December 02, 2008 8:54 PM
Subject: Re: [netmod] defaults - needed updates

> And I think that the draft now does that.

If declaring three incompatible approaches all part of the spec, then yes, you
are right.  But I think that your other post on 'assigned-by' and responses
thereto show that this metadata - config, mandatory, defaults etc - lacks
consensus and makes work on the :with-defaults capability somewhat speculative.

Tom Petch