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

["Sharon Chisholm" <schishol@nortel.com>]

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'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. 

And why do we have <get> and <get-config> again? 

Sharon

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