[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt)
> Neither proposal allows for NV-storage of parameters
> which are not session-specific.
There is nothing in either proposal that limits the device from also
having static configuration for forwarding events to a standard syslog
server - these proposals are specific to forwarding events over a
NetConf session...
Kent
-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]
Sent: Thursday, June 22, 2006 11:21 AM
To: Kent Watsen
Cc: Sharon Chisholm; netconf@ops.ietf.org
Subject: Re: Verbs Again (was RE: draft-shafer-netconf-syslog-00.txt)
Kent Watsen wrote:
> 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
>
fine
> 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.
>
Neither proposal allows for NV-storage of parameters
which are not session-specific. This is a major problem.
> Kent
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 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/>