Re: [YANG] mandatory & default

[Balazs Lengyel <[e-mail]>]

Hello,
Some basic statements for me:
1) the get-config results can or can not contain defaults based on the with-defaults parameter, 
so the content of get-config is not a deciding factor between the different "default" alternatives.
2) Storing the default values is an internal issue for the implementation, which is independent 
from the existence (or not) of a leaf in the conceptual database.

Balazs

Phil Shafer wrote:
> [replying to multiple Andy-grams]
> 
> Andy Bierman writes:
>> Whether the manager or the agent sets the leaf to the default,
>> it is there from a NETCONF protocol PoV.
> 
> NETCONF leaves all this to the data model, so there's no single
> NETCONF POV on this issue.  This is designed to support existing
> views of configuration issues, including defaults.
> 
>> 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.
> 
> If I'm using NETCONF to archive configurations, I don't
> want them littered with defaults.  Similar for if I'm
> viewing them in the equivalent of a mib browser.  I want
> to see the statements that someone has explicitly configured,
> not volumes of uninteresting defaults.
> 
> Part of putting these values into YANG modules is to allow
> interested parties (applications, developers) to know these values
> as they are helping the user create new instances.  To my mind, the
> "with-defaults" is useless for this scenario, since I want to know
> the defaults _before_ I make the config, not after.
> 
> The KISS view of config is used for CLIs because is keeps the
> noise to a minimum.  This need doesn't disappear when the
> config moves into the application/automation world.
> 
> 
>> Message-ID: <[e-mail]>
>> Date: Fri, 25 Jan 2008 16:06:53 -0800
>> From: Andy Bierman <[e-mail]>
>>
>> After a system reboot, does the agent 'remember' that mtu
>> was set to 1500 by the manager, so the initial <running/>
>> config from NV-storage after the next reboot has an mtu leaf
>> for eth1?
> 
> No, the system records as the configuration only those fields which
> are interesting.  For example in JUNOS, we define "interesting" as
> anything the user told us to do.  In IOS, they define "interesting"
> as any non-default values.  IMHO, you're trying to define interesting
> to include some very boring defaults.
> 
> 
>> Message-ID: <[e-mail]>
>> Date: Sat, 26 Jan 2008 07:01:57 -0800
>> From: Andy Bierman <[e-mail]>
>>
>> But here is where this CLI-based design is broken.
>> If a manager sends jumbo packets on eth1, they will not be accepted.
>> There is a maximum transmission unit size in effect on eth1,
>> but the manager is told there is none in the <get-config>.
> 
> The application can find all the information about "mtu", including
> its default value, in the metadata.  The application can show this
> default value to the user as they create a new interface, and the
> application can know that if there's an <mtu> in the interface, its
> there because someone wanted it, and that's it's not noise.
> 
>> The response "oh no, there is an MTU value in effect, just not in the config"
>> is really broken.  It's not state data, and it's not config data, but if
>> the manager does not know the value, it cannot reliably configure other
>> devices that send packets to 'eth1' on this agent.
> 
> Nope, it's not config data.  It's a default value.  The device
> doesn't need it to perform the job of configuration, which is
> defined in the NETCONF spec as:
> 
>    Configuration data is the set of writable data that is required to
>    transform a system from its initial default state into its current
>    state.
> 
> Default values aren't required in config data.  Or wanted.
> 
> If I've got 64,000 interfaces, I don't need to see this default
> value for each interface, let alone the hundred other knobs for
> each interface that have perfect reasonable and completely
> uninteresting default values.
> 
>> IMO, the mtu is clearly config data, and clearly in effect at
>> all times eth1 is accepting packets.  The config returned
>> in NETCONF PDUs should match.  Filtering out these defaults
>> is a separate issue from whether they exist or not.
> 
> The issue isn't filtering them out.  The issue is are defaults part
> of the configuration?  I understand the need for a mechanism for
> discovering them, both inline and in metadata, but I don't see any
> win in considering such noise as part of the configuration of a
> device.
> 
> We are working hard to make devices _more_ managable.  Adding a
> couple of orders of magnitude of noise into the configuration
> means:
> - performance issues (as my 1m config turns into 100m)
> - upgrade/downgrade issues (as defaults for unused features break
>   on software that doesn't support them, even if they are completely
>   unimportant)
> - readability issues (as adding noise makes the config less readable
>   and the purpose of using xml was human readability for debugging
>   and monitoring)
> 
> Inline defaults is broken, to lift your words, since it takes a
> complex problem and makes it more complex.  We should be simplifying,
> reducing, and giving better visibility into the important parts of
> configuration, not polluting them with noise.
> 
> Thanks,
>  Phil
> 
> 
> _______________________________________________
> YANG mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/yang

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