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

[Andy Bierman <ietf@andybierman.com>]

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/>