Re: [YANG] default values

[Balazs Lengyel <[e-mail]>]

Hello Lada,
I think (for Ericsson I know) we do NEED both i and ii; with all capital letters really. E.g. 
if we were just validating XML you could throw out
- default
- partly description
- reference
- revision
- contact
- organization

maybe more.

I don't see why the two aims are conflicting. Could you give me an example?

Balazs

However all this is needed

Ladislav Lhotka wrote:
> Hi Balasz,
> 
> in my view, the basic difference is this:
> 
> Do we want to use (YANG or other) data models
> (i) for validating XML documents in the NETCONF context, or
> (ii) for specifying behaviour of network devices and/or management
> software?
> 
> I am primarily interested in creating standard data models for (i) and
> concerned that pursuing (ii) might make the result unusable for (i).
> Note that the default statement makes sense only in (ii).
> 
> Lada
> 
> 
> Balazs Lengyel píše v Čt 17. 01. 2008 v 09:54 +0100:
>> Hello,
>> I think you are arguing about different things. As I understand your comments:
>> Statement 1) says: defaults are important, so if we do have an agreed default value, we should 
>> document it in a proper, formal way. (I fully support this.)
>> Statement 2) says: it is very difficult to agree on good default values so we should use 
>> extreme caution specifying "mandatory" defaults in standards. I can agree with that as well.
>> We can still to define recommended-only defaults in the description statement if the default is 
>> not obvious enough.
>>
>> The two statements do not contradict each other in my view.
>>
>> Also while it is difficult to define default values in standards, YANG and NETCONF will be used 
>> a lot to define proprietary data models as well. It is much easier to define defaults here, and 
>> yes we do want a formal definition of these defaults (actually we already have it in the 
>> Ericsson-DML.)
>>
>> Balazs
>>
>>
>> Ladislav Lhotka wrote:
>>> Jon Saperia píše v St 16. 01. 2008 v 11:54 -0500:
>>>
>>>> I understand your perspective but even  though I said what I said, if  
>>>> we were to go down this path, defaults can be helpful.  Any manager  
>>>> that attempts the configuration function will have to be pretty  
>>>> sophisticated because of the variability (even with standards) that  
>>>> will be sure to exist. That does not mean that they will not do bad  
>>>> things from time to time, but the market has a way of fixing things.
>>> I am not against specifying defaults (reasonably), I only don't like the
>>> fact that changing a default value implies a different data model. I
>>> understand the data model primarily as a means for checking whether a
>>> given document is valid or not and default values are irrelevant in this
>>> respect. It is already difficult to standardise the knobs and default
>>> values are yet another level.
>>>
>>> Lada
>>>
>>>> /jon

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: [phone]
Tel: [phone]     email: [e-mail]


_______________________________________________
YANG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/yang