And a third reason (although this reason relates to the SMI more than the SNMP protocol) is that XML has hierarchical structured data whereas in SNMP the tables are flat.
Regards, /gww
> -----Original Message-----
> From: Andy Bierman [mailto:abierman@cisco.com]
> Sent: Thursday, September 04, 2003 16:47
> To: Jeff Johnson
> Cc: netconf@ops.ietf.org
> Subject: RE: Separation of protocol and information model
>
> Hi Jeff,
>
> >> From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de]
> >> >>>>> Chen, Weijing writes:
> >>
> >> Chen> What is exact the problem with SNMP? If it is the problem of
> >> Chen> RowStatus and StorageType, then why throw out the other good
> >> Chen> part of SNMP like separation of protocol operation and data
> >> Chen> model? Like old proverb said, don't throw baby out with dirty
> >> Chen> water.
> >>
> >> SNMP problems are well documented. Read the latest issues of the
> >> Simple Times or read the failed EOS and SMIng WG mail archives as well
> >> as the SNMPv3 archives to understand what is broken and to get a
> >> feeling why the SNMP community is too deadlocked to fix this stuff
> >> in order to make it work for configuration.
> >
> >Forgive me for speaking out from the sidelines, especially since I
> >haven't read the two drafts in detail, but my question is how does
> >netconf solve the SNMP problems? From my perspective, one of the
> >hardest problems an snmp implementation had to solve was the fact that
> >in an SNMP set PDU you could get varbinds from a number of different
> >mibs, and it was difficult to meet the "as if simultaneous" rule. This
> >problem doesn't become any easier just because you use a different
> >transport to deliver the data.
>
> There are two aspects of netconf that deal with this:
>
> 1) There is no createAndWait. An <edit-config> operation
> that creates a new section of the config has to be complete
> (explicit + default values == complete). In this case,
> the transport does make a difference because it's TCP
> instead of UDP. The transport does the fragmentation
> instead of the application.
>
> 2) There is no "as if simultaneous" rule. It is understood
> that set operations are applied sequentially. Some
> devices will have the ability to rollback the device
> config if an error occurs, but this is not a mandatory feature.
>
>
> >/jeff
>
> 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/>