Re: [YANG] mandatory & default

Martin Bjorklund wrote:
> 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.
> 

I disagree.

If I invoke an <edit-config> and set the leaf to this
default value, it is still not there?

If I invoke an <edit-config> and set the leaf to a
non-default value, it is clearly there.

Whether the manager or the agent sets the leaf to the default,
it is there from a NETCONF protocol PoV.

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

Nobody said anything about storing the value.
It is an implementation-specific matter as to how
an agent generates a reply to a <get-config> request.
The defaults do not have to be stored -- they can
be generated on the fly.

> 
>> 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
> 
> 

Andy

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