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

[Andy Bierman <ietf@andybierman.com>]

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