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

From: "Durham, David" <[email-masked]>
Date: Fri, 28 Mar 2003 10:10:41 -0800

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 11:49:36 -0800

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