Eureka.
So, we are closer then I thought. This is good to news. So, the current
proposal has two approaches:
1) Provide the filters as parameters
2) Provide a pointer to the named profile which is a chunk of XML Schema
and you think that 1)is rubbish and much prefer 2).
My main problem with 2) is that it opens things up for over-engineering
and it also makes the network element the authoritative source of the
subscription parameters while I really want the netconf client to be. It
also has some garbage collection issues.
-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]
Sent: Thursday, June 22, 2006 11:20 AM
To: Chisholm, Sharon [CAR:ZZ00:EXCH]
Cc: netconf@ops.ietf.org
Subject: 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/>