Re: FW: FW: FW: RFC3535 question/clarification

[Phil Shafer <phil@juniper.net>]

"Wijnen, Bert (Bert)" writes:
>And my naive
>assumption was that a device knows internally what got configured
>manually and what not. But perhaps I was wrong...

FWIW, our box doesn't track the source of parameter values.  The
configuration database only contains user-provided (explicit) values.
At commit time, these values are passed to the software modules
that manage interfaces, which plug the values into the appropriate
structures.  The software modules do not retain explicit knowledge
of whether this mtu value was set via a default or set explicitly.

But the real question is a bit different.  In Vienna, someone pointed
out that if the 'get-state' rpc can only return state, the device will
have to avoid returning data that was explicitly configured.  This
seemed like a waste, since (a) normal operational 'show' commands
display this information, (b) removing the explicitly configured bits
makes it important to have an (expensive) mechanism to rejoin the 
config to the state, and (c) most devices do not track the source
of operational information. So we talked about renaming 'get-state'
to 'get-all' to make it plain that the information returned is not
constrainted to configuration data.

For example, returning the bgp peer information without indicating
whether the peer is internal or external is fairly useless.

So the choices are:
(a) force devices to track the source of parameters
(b) s/get-state/get-all/
(c) caveat that get-state can return parameters that are explicitly configured

I'm for (c), but I can appreciate the confusion it will cause. I'm
not sure (b) is any less confusing.

This is all driven by the need to separate configuration data from
non-configuration data. And deciding whether there is any worth to
separating non-configuration data from configuration data. Given
that devices tend to have 'show configuration' and 'show <anything-else>'
I'm assuming that there's no value in reverse separation.

Thanks,
 Phil

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>