Re: [YANG] mandatory & default

Hi,

Andy Bierman <ietf@andybierman.com> wrote:
> Hi,
> 
> I don't think every vendor deals with agent-created defaults in the
> same way, and there is zero chance every implementation will converge
> on one interpretation.

Don't you think that we must have one, clear definition of how to
handle this?  How can anything else ever be interoperable?

> The important thing to consider is:
>    what is important for standards-based configuration?
> 
> Here is the bottom line:
> 
>   - RFC 4741 requires that *all* config database objects be returned
>     in a <get-config> without any filters

Ok.

>   - All data nodes that exist in the configuration have some value
>     (consider the value for 'empty' to be present/not-present)

Ok.

>   - An extension is needed (e.g., with-defaults=false) to change the
>     behavior of RFC 4741 wrt/ returning a subset of all nodes without
>     any filter defined

Or, if you, for a moment, try to view thing from the other side, you
need an extension with-defaults=true to actually get the default
values, since they are not stored in the configuration data store.

> Phil seems to be arguing that nodes that contain the agent-specified
> default value are not really there.

Right, since they are not there in his implementation.  Why would you
store stuff that's not even needed to store?  That's just a waste of
resources.

> Yet, if the manager
> sets a node explicitly to the default value, it is there.
> IMO, this is rather confusing, and broken.

I think it makes perfect sense.  If you set it, it's there.  IMO it's
more confusing if you set it and it's sometimes _not_ there (b/c it
happened to be the default).  NOTE: I'm NOT saying that this is the
*only* way to do defaults, I'm just saying that this defintion is
consistent.

> The idea of tracking down stacks of offline vendor documentation
> to determine the theoretical values of these 'default nodes',

Did anyone suggest that?  The default value is part of the data model,
and you should be able to get the data model through schema discovery.
There are lots of other information you need from the data model
that's not in the instance document, like type, config true/false,
relationships etc.

> instead of
> simply asking the agent for the real values, is a non-starter.

I don't agree.  I do agree that being able to get defaults from the
box is useful, that's why the with-defaults extension is good.

/martin

_______________________________________________
YANG mailing list
YANG@ietf.org
https://www1.ietf.org/mailman/listinfo/yang