[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Sharon Chisholm wrote:

hi

If the working group gets too obsessed with architectural purity at the
expense of usability to the operators and management applications trying
to use an implementation of the protocol I think we are more in trouble.



I really disagree with this comment.
We spent about 5 years developing a set of standard operations
for the standard manipulation of NV-stored configuration data
models encoded in XML.  Instead of using it, some people
want to pretend that filtering parameters do not fall in
the category of NV-stored configuration data.



I've suggested previously the following criteria before deciding whether
it was appropriate to create a new verb:

1. Is it possible to perform this with existing verbs without exploiting
data model side efforts or being ridiculously complicated?
2. Is this operation a management operation and if so does it make sense
for a management protocol to provide this function natively?

I think the argument for this verb falls more out of the second
question. Providing it native in the protocol operation keeps it simple,
easy to use and highlights its importance over arbitrary bits of
configuration. 

I think you are missing the point.
Balazs and I are not saying that a verb to start
the delivery of notifications is a problem.
I totally agree with this approach, rather
than the SNMP MIB approach of turning the knob
to 'enabled' in the data model.  Let's get past this point, okay?

The problem is that many of the parameters
(especially the most complicated part -- the filters)
should be implemented as a read-create standard
data model using the existing <edit-config> operation,
and retrieval of these parameters and notification
state information should be done with the <get> operation.
And why do we have <get> and <get-config> again? 

To retrieve data



Sharon



Andy




-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Thursday, June 22, 2006 10:22 AM
To: Balazs Lengyel
Cc: Phil Shafer; netconf@ops.ietf.org
Subject: Re: draft-shafer-netconf-syslog-00.txt


Balazs Lengyel wrote:

...
3)
> I'm not prepared to be the first lamb on that altar. ;^) Someone has to be :-) otherwise NETCONF is dead already. 



Agreed.
What is especially depressing:

  1) Notification filtering and delivery is a well understood problem,
     traditionally handled with NV-stored configuration on the
     notification generator.

  2) This is a relatively simple configurable feature on a
     complex networking device such as a router.

  3) If the NETCONF WG cannot (or does not) use the
     NETCONF protocol to configure the NETCONF protocol,
     then nobody else will use it either.

  4) If something as basic as a filtering table and notification
     generation parameters are not appropriate for implementation as a
     standard data model (accessed with <edit-config> and <get-config>),
     then what is an appropriate use of the NETCONF protocol
     standard operations and standard data models?

  5) If you can define a representation of a 'feature' in a data model
     for monitoring, then you've already done most of the work for
     configuration.  Read-only vs. read-write is an artificial
     attribute.



Balazs



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





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