RE: Separation of protocol and information model

["Chen, Weijing" <Weijing_Chen@labs.sbc.com>]

> 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.
The protocol in WG I-D is too focusing on the second task.  It pretty much
ignores the first task.  That's why I said earlier that current WG protocol
is more of a file transfer protocol than a management protocol.
Configuration file transfer is important, but no more important making the
configuration right in the first place.  In the everyday life of operating
network, making the correct change of configuration is much harder than
shipping the change to device. 





--

Weijing Chen


> -----Original Message-----
> From: Phil Shafer [mailto:phil@juniper.net]
> Sent: Thursday, September 04, 2003 11:49 AM
> To: Allen, Keith
> Cc: 'Glenn Waters'; netconf@ops.ietf.org
> Subject: Re: Separation of protocol and information model
> 
> "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/>

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