[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Why Phil is right about <special-set> vs. <edit-config>
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/>