Subject: RE: [midcom] On SNMPv3, clarification, invitation for discussion

From: "Durham, David" <[email-masked]>
Date: Fri, 28 Mar 2003 12:05:21 -0800

Binary maybe, lexigraphically ordered oids with BER encoding definitely
not. Where is real data from real deployments that shows snmp will in
fact handle thousands of transactions? Isn't the lack of such success
stories exactly why the IETF is turning away from snmp for config???

-Dave

> -----Original Message-----
> From: Eliot Lear [mailto:[email-masked]]
> Sent: Friday, March 28, 2003 11:50 AM
> To: Durham, David
> Cc: Jonathan Rosenberg; [email-masked]; [email-masked]
> Subject: Re: [midcom] On SNMPv3, clarification, invitation for
discussion
> 
> Guys,
> 
> Look- my sole point is that the target audience for XML-CONF is
> different.  My concern would be performance related, and nothing more.
> If you need to handle hundreds or thousands of transactions per second
> on the MIDCOM agent, you may find a binary protocol to be more to your
> liking, rather than having to parse out the XML.
> 
> Eliot
> 
> 
> Durham, David wrote:
> > I agree. There is nothing technically preventing XMLConf from doing
> > small dynamic transactions. In fact, I argue that XMLConf would be
> > superior over SNMP for such transactions. Do the math:
> >
> > * snmp's unreliable transport means get followed by set followed by
get.
> > Several round trip latencies incurred by each snmp get set get
exchange.
> > RTT becomes the most significant bottleneck for snmp. Pray there's
no
> > packet loss.
> > * snmp's udp transport has no flow control, fairly easy to perform
DoS
> > attack either on purpose or quite accidentally.
> > * snmpv3 has a very complicated user security model. Few people
using it
> > to date. Many operators today typically run snmpv1 over VLANs or
VPNs.
> > * A complete Oid is exchanged with every attribute being
communicated
> > making each snmp BER transaction just as big if not bigger than
> > equivalent XML encoded data.
> > * BER encoding rules sufficiently complex that recently many snmp
> > deployments have been found susceptible to buffer overflow attacks
> > allowing attackers to crash systems or launch worms. We can only
assume
> > all the holes have now been plugged.
> > * Rowstatus is the best transactional mechanism snmp has. Need I say
> > more? Okay, I will: get rowstatus, set rowstatus, check rowstatus,
get
> > first attribute, set first attribute, get first attribute, get
second
> > <time passes>, unset rowstatus, check row status... Phew. Again,
pray
> > there is no packet loss.
> > * With snmp you'll have to force fit your data into pdu's sized for
MTU.
> > Certain kinds of certs and keys make this a difficult proposition.
> > * MIB data model requires MIB specialists to read & write. Meanwhile
> > there is a large number of people familiar with either XML or its
> > supporting tools.
> > * XML self-documenting. Schema & data are communicated with same
> > transport.
> > * snmp lacks several critical base data types such as Integer64
readily
> > supported by XMLSchema.
> > * lex-next ordering makes implementations complex or requires copy
of
> > intermediate snmp data structures that are independently ordered.
> > * No transactional model, either for small and dynamic transactions
or
> > large and static ones.
> > * snmp has multi-manager transactional complexities that must be
handled
> > at the data model level.
> > * snmp midcom implementations need to handle attributes arriving in
any
> > order, possibly across multiple packets.
> >
> > I can go on an on the con's of snmp here. One con on XMLConf is that
> > it's just starting. However, XML is not new. This wg can get started
> > immediately writing XMLSchema models for middle boxes.
> >
> > -Dave
> >
> >
> >>-----Original Message-----
> >>From: Jonathan Rosenberg [mailto:[email-masked]]
> >>Sent: Friday, March 28, 2003 9:02 AM
> >>To: [email-masked]
> >>Cc: Eliot Lear; [email-masked]
> >>Subject: Re: [midcom] On SNMPv3, clarification, invitation for
> >
> > discussion
> >
> >>Pyda,
> >>
> >>This is a pretty substantial claim. Can you provide details on why
> >
> > this
> >
> >>is true?
> >>
> >>-Jonathan R.
> >>
> >>Pyda Srisuresh wrote:
> >>
> >>>I agree. I believe, XMLCONF is useful for one-time
> >>
> >>configuration/retrieval.
> >>
> >>>SNMP is still desirable for
> >>>dynamic transactions.
> >>>
> >>>cheers,
> >>>suresh
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: [email-masked] [mailto:[email-masked]]On
Behalf
> >
> > Of
> >
> >>>>Eliot Lear
> >>>>Sent: Monday, March 24, 2003 3:57 PM
> >>>>To: Melinda Shore
> >>>>Cc: [email-masked]
> >>>>Subject: Re: [midcom] On SNMPv3, clarification, invitation for
> >>>>discussion
> >>>>
> >>>>
> >>>>Melinda,
> >>>>
> >>>>Two more additions to your valid comments.
> >>>>
> >>>>XMLCONF has an intended audience: configuration and retrieval of
> >
> > static
> >
> >>>>information within devices.  This may be slightly imprecise, but
let
> >
> > me
> >
> >>>>tell you what we *don't* think XMLCONF is good for: exchange of
> >
> > protocol
> >
> >>>>state information.  We wouldn't want to replace BGP with XMLCONF,
> >
> > for
> >
> >>>>example.
> >>>>
> >>>>I believe midcom comes a lot closer to a state exchange protocol,
> >
> > such
> >
> >>>>as BGP, then it does to the screen scraping that we are attempting
> >
> > to
> >
> >>>>address with NET-CONF.  Certainly this holds true for STUN, and
> >
> > that's a
> >
> >>>>good hint, IMHO.
> >>>>
> >>>>ALSO.  To repeat what Bert, Andy, and others have said, while the
> >>>>requirement has been relaxed, there is nothing stopping anyone
from
> >>>>writing a MIB or specification with writable objects.  You simply
> >
> > aren't
> >
> >>>>REQUIRED to do so.
> >>>>
> >>>>If this group believes that SNMP with writable objects is the
right
> >
> > way
> >
> >>>>to go, I say go for it.
> >>>>
> >>>>Eliot
> >>>>
> >>>>_______________________________________________
> >>>>midcom mailing list
> >>>>[email-masked]
> >>>>https://www1.ietf.org/mailman/listinfo/midcom
> >>>
> >>>
> >>>_______________________________________________
> >>>midcom mailing list
> >>>[email-masked]
> >>>https://www1.ietf.org/mailman/listinfo/midcom
> >>>
> >>
> >>--
> >>Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> >>Chief Scientist                             Parsippany, NJ
07054-2711
> >>dynamicsoft
> >>[email-masked]                     FAX:   (973) 952-5050
> >>http://www.jdrosen.net                      PHONE: (973) 952-5000
> >>http://www.dynamicsoft.com
> >>
> >>_______________________________________________
> >>midcom mailing list
> >>[email-masked]
> >>https://www1.ietf.org/mailman/listinfo/midcom
> >
> >
> >

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Eliot Lear <[email-masked]>
Date: Fri, 28 Mar 2003 12:44:19 -0800

> stories exactly why the IETF is turning away from snmp for config???

Indeed.  XMLCONF is born out of a lack of success with SNMP configuration.

However if you are concerned about performance then you might want to 
ponder the cost of XML encoding into the equation.  I'm not answering 
the question, I'm just suggesting that you ask it when considering your 
protocol choices (that and the fact that there isn't even a WG yet might 
lead you to some reservations as well, as Melinda mentioned).

Eliot