RE: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt)

["Hector Trevino \(htrevino\)" <htrevino@cisco.com>]

Andy,

I'm finally catching up on e-mail. Looking at the discussions and the
agenda for Montreal I was wondering if the data modeling discussion
towards the end of the agenda is only wrt notifications or a more
general discussion?


"- Data Model and XSD Issues

  - Data model design
  - XSD correctness
  - Need for 'min-access' and 'max-access"

thanks
Hector





 

> -----Original Message-----
> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Wednesday, June 28, 2006 10:36 AM
> To: Phil Shafer
> Cc: Sharon Chisholm; netconf@ops.ietf.org
> Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt)
> 
> Phil Shafer wrote:
> > Andy Bierman writes:
> >> This is no different than standard MIB modules.
> > 
> > We _have_ to be different than the process that made 
> standard MIBs if 
> > we want to be usable for configuration.  We can't follow 
> the same path 
> > and expect that folks will use ours just because it's in 
> XML.  There 
> > has to be more.
> > 
> >> IETF WGs have managed for years to define standard MIB 
> objects, even 
> >> though proprietary MIB objects also exist.
> > 
> > If you see this as successful (for configuration), why are we here?
> 
> 
> SNMP has problems as an API for configuration that NETCONF 
> addresses fairly well.  However, the basic concept of a WG 
> reaching consensus on the syntax and semantics of individual 
> standard knobs for standard protocols is still valid.
> 
> 
> > 
> >> There are many people (including myself) who believe that standard 
> >> configuration data models are a critical component to a complete 
> >> standards based solution for network configuration.
> > 
> > I completely agree that standard configuration data models are 
> > critical, but I do not agree that they are trivial.  I 
> think this is 
> > the next big hurdle for this working group.  The question 
> on the floor 
> > is whether we should stop other work until we have a real 
> meta-model 
> > for configuration and a way of specifying standard data models that 
> > will work in the real world.  If so, let's stop talking about 
> > notifications and get our butts in gear on modeling.
> > 
> > Me, I don't want to wait for it.  I want to see usable capabilities 
> > for doing operational tasks that applications need in order 
> to manage 
> > devices.  Things like file transfer, call-home, software 
> installation, 
> > reboot, and system status.  I think we can progress in 
> these areas in 
> > parallel.
> > 
> > But if the concensus if that we can't, we should stop talking about 
> > other topics while we work on modeling.
> > 
> 
> I know we should be working on data modeling instead of 
> notifications but we aren't.  That is still no excuse for not 
> using the standard <edit-config> and <get> operations.
> 
> I don't think data organization should be that hard, and we 
> don't have to organize the entire world right now.
> We just have to organize the netconf protocol data.
> 
> I use the following organization (which can be nested and repeat)
> 
>   <application-name  xmlns="owner-namespace">
>     <parameter-set-name>
>       <parameter-name>
>     </parameter-set-name>
>     <monitor-set-name>
>        <mon-object-name>
>     </monitor-set-name>
>   </application-name>
> 
> 
> E.g.;
> 
>   <netconf xmlns="netconf-data">
>     <notification-config>
>       ....
>     </notification-config>
>     <notification-mon>
>       ...
>     </notification-mon>
>   </netconf>
> 
> (read-only data can be defined in a parameter set, but the 
> monitor set is supposed to be used instead for data sets that 
> are all read-only)
> 
> Something simple like this should be good enough to get us started.
> 
> 
> > Thanks,
> >  Phil
> > 
> > 
> 
> Andy
> 
> --
> 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/>