[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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