[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt)
I agree with Sharon on this. There are clear differences between
session-specific and device-wide parameters. There is the obvious bit
about session-specific parameters being cleared when the session drops;
but more importantly is that no two sessions (i.e. applications) should
be aware of what any other session/app is up to - this principle is
violated if session-specific params are NV-stored
Also, while Andy is correct that session-specific filters do require
more parsing, validating, and setup - this overhead is dwarfed by the
device actually forwarding the notifications to the client over the
course of the session
BTW, Phil's proposal is good wrt all this in that it uses device-wide
streams (i.e. topics) on which session-specific filters can be applied.
Kent
-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Thursday, June 22, 2006 9:36 AM
To: Sharon Chisholm
Cc: netconf@ops.ietf.org
Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt)
Sharon Chisholm wrote:
> 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.
Forcing every manager application to come up with the correct
filtering parameters every time a new session is started is
extremely inefficient for both the manager and the agent.
Using sharable, NV-stored parameters on the agent, configured by
the authoritative manager, applications are not forced to
maintain the possibly massive set of notification filters on their
own.
It is very inefficient for the agent to parse, validate, setup
and store all the filtering parameters, every time a session
that wants notifications starts up, and duplicated for every session.
IMO, these inefficiencies dwarf the task of removing
NV-stored filters on the agent that are no longer of interest
to any management application.
>
> Sharon
Andy
>
> -----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/>
>
>
--
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/>