RE: Why Phil is right about <special-set> vs. <edit-config>

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Having implemented the SNMP engine for both agent and manager side
I can wholeheartedly support Andy's points 2 and 3 below as to why 
the SNMP SET command has been much much more complex than it needs
to be. It is one of the reasons why I am advocating these days
that in a MIB MODULE, oine adds a MODULE-COMPLIANCE that allows
to "not support" the createAndWait mechanism. But that is only
a small piece of the problem. 

Bert

> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
> Behalf Of Andy Bierman
> Sent: Tuesday, September 12, 2006 17:19
> To: Netconf (E-mail); Netconf Data Model Discussion
> Subject: Why Phil is right about <special-set> vs. <edit-config>
> 
> 
> Hi,
> 
> First, I am not going to say we need to stop using <edit-config>.
> I just going to point out a critical SNMP problem the XMLCONF design
> team really wanted to fix -- but didn't.
> 
> The root problem in NE management today is the relative expense
> and difficulty in adding new agent functionality into NE devices.
> 
> SNMP Set failed for 3 reasons:
>  1) Casting high-level procedures as a "100 bits of peek/poke data"
>     is an Unnatural Act that never had a chance of succeeding.
>  2) One generic "edit" PDU that can contain an arbitrary mix
>     of arbitrarily incomplete high-level operations (i.e. varbinds),
>     dispensed like gumballs, across an arbitrary number of Set PDUs.
>  3) In accordance with the Postel Principle, the agent needs to code
>     for complex (legal) Set PDUs the manager should never ever use.
> 
> NETCONF has better error reporting then SNMP, but the complexity
> of implementing <edit-config> in an optimal manner is non-trivial.
> 
> In contrast, none of the arbitrary mix-and-match "Gumball 
> API" problems
> exist with <special-set> RPCs.  The agent automation complexity is
> dramatically lower than for <edit-config>.  Agent callback chains
> can handle hard problems like resource reservation and rollback
> much easier as well.
> 
> The <special-set> approach is much better for managers,
> because an "object-oriented API" can easily be mapped to
> services or classes, and the set of methods defined for them.
> 
> The "fly in the ointment" is the startup config file
> (e.g., show running config).  This data-centric view
> of the configuration state is heavily used, and not going
> away any time soon.  The trick is finding the right mix
> of heuristics, mappings, and special RPCs, so both views
> of the NE device can be easily supported.
> 
> 
> 
> 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/>