Re: [YANG] mandatory & default

["tom.petch" <[e-mail]>]

----- Original Message -----
From: "Andy Bierman" <[e-mail]>
To: "Phil Shafer" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, January 28, 2008 5:10 AM
Subject: Re: [YANG] mandatory & default


> Phil Shafer wrote:
> > [replying to multiple Andy-grams]
> >
>
> We strongly disagree on the interpretation of RFC 4741
> and whether a node with a default value really exists or not.
>
> It is very fragile SW design to assume the agent is using the exact default
> that was tracked down in the documentation.
>
> It is up to the operator whether knowing that a node
> is actually supported, and knowing the exact value set by the agent,
> is a waste of space or important debugging information.
>

I am very much with Andy (and Randy) on this one.  Knowing all the parameters
that affect how a box functions is vital; it may be the only way to work out why
it is not working as the operator thinks it should be.

I would say that having access to both the full and the specified configuration
is a MUST.  If forced to choose which had to be implemented, I would go for the
full configuration every time.  Computers can simply and reliably remove the
extra information, they cannot (as) reliably insert the supposed defaults as
known on the device.

Tom Petch

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



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