Re: Separation of protocol and information model

[Phil Shafer <phil@juniper.net>]

"Allen, Keith" writes:
>The first point is an important one and has not been discussed yet.  The
>fact that <running> and <users> are separate means that a management system
>implementer cannot tell from a device's XML schema what is part of the
>running configuration and what is part of the backup or other
>configurations.

The assumptions is that the configuration contents are consistent
regardless of where the configuration resides. Any configuration
data set must follow the same syntax and semantics. What utility
does distinquishing the language of configuration based on where
the data set lives provide?

>Does it make sense to retrieve <users> from the target
><backup>?

If <backup/> is a place where you store configuration, yes.

>Granted, most people would probably realize that <users> should
>not be part of a backup configuration but other elements may not be so
>clear.

Now I'm confused. Why aren't users part of the backup configuration?

>The second point means that if a device implementer does not want to have a
><running> element in their schema, they need not.

Can you explain the purpose of not having a <running/> configuration?

>So, a device
>could have <running>, <backup>, <every-other-Thursday>, whatever.

Sure, I could make an <every-other-Thursday/> target and announce
it via a capability. Any application that understands the contract
spelled out in the capability definition and wants my device to
behave accordingly can freely specify the <every-other-Thursday/>
target (without understanding the device's data model).

To me, the issue is the ability to keep the data-model knowledge
in the config generation/translation code module, while letting the
config propagtion, activation, and recovery code modules driven
from the expressed capabilities of the device.  Moving operations
into the data model makes this division impossible and reduces
the protocol to nothingness.

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