Subject: [netmod] defaults - needed updates

From: Balazs Lengyel <[email-masked]>
Date: Wed, 29 Oct 2008 00:29:13 +0100

Hello,
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.

We agreed on the Reston interim on the following  about the handling 
of defaults

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.

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

Defaults potentially effect the following stuff:

1) concept of the default
Solution: 
- 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.

3) evaluation of the must/when/unique constraints
- "7.8.3 The lists's unique Statement" must be extended:
"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. Intead of create: replace or merge can be used.  
The different behaviour 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-contrainers
Already OK 
Depends on whether default leafs exist. No additional text needed.

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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 29 Oct 2008 12:55:13 +0100 (CET)

Hi,

> "Leafs with a default value, may or may not exist in the conceptual

I think this makes sense.

> reference to the with-defaults draft.

Do you want to force servers implementing YANG to also implement
:with-defaults?  Or simply mention the problem and add a reference to
a solution (:with-defaults)?

> data tree, and all leafs with default values."

How about this:

OLD:
  In a valid configuration, the combined values of all the leaf
  instances specified in the string MUST be unique within all list entry
  instances. 

NEW:
  In a valid configuration, the combined values of all the leaf
  instances specified in the string, including leafs with default
  values, MUST be unique within all list entry instances.

> (The manager has the option to just ignore the capability.)

I think this one falls out from 1) above.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 29 Oct 2008 14:01:01 +0100

> a solution (:with-defaults)?
BALAZS: Just recommend the implementation and add reference.
>   values, MUST be unique within all list entry instances.
BALAZS: OK
> I think this one falls out from 1) above.
BALAZS: OK