Steven,
I'm not sure what you mean by saying that a problem that is
highly complex should not be solved (or, at least, that we should
consider not solving it). That seems like a cop-out. Minimally,
every problem we've ever faced, we've tried to solve (where "we"
refers to us weak-kneed Homo Sapiens) - no matter how hard it was
to do so - and I like to think that is the right thing to do.
In fairness, I am reasonably sure that point 3 in RFC 1925
refers to making a complex solution work, even if a simpler answer
might be found, simply because enough people want that solution.
It does not - IMO - rule out solving complex problems using
as simple a solution as possible, however complex that might be.
--
Eric
--> -----Original Message-----
--> From: Steven M. Bellovin [mailto:smb(_at_)cs(_dot_)columbia(_dot_)edu]
--> Sent: Monday, June 05, 2006 8:21 PM
--> To: David Harrington
--> Cc: ietf(_at_)ietf(_dot_)org
--> Subject: Re: Best practice for data encoding?
-->
--> On Mon, 5 Jun 2006 20:07:24 -0400, "David Harrington"
--> <ietfdbh(_at_)comcast(_dot_)net> wrote:
-->
--> > Hi
--> >
--> > The security problems identified in
--> > http://www.cert.org/advisories/CA-2002-03.html "Multiple
--> > Vulnerabilities in Many Implementations of the Simple Network
--> > Management Protocol (SNMP)" are not caused by the
--> protocol choice to
--> > use ASN.1, but by vendors incorrectly implementing the
--> protocol (which
--> > was made worse by vendors using toolkits that had the problems).
--> >
--> > If "Multiple Vulnerabilities in Implementations" were
--> used to condemn
--> > the encoding methods of protocols that have been incorrectly
--> > implemented, then we would have to condemn an awful lot of IETF
--> > protocols as being very (security) bug prone:
--> >
-->
--> Works for me....
-->
--> More precisely -- when something is sufficiently complex,
--> it's inherently
--> bug-prone. That is indeed a good reason to push back on a
--> design. The
--> question to ask is whether the *problem* is inherently
--> complex -- when the
--> complexity of the solution significanlty exceeds the
--> inherent complexity of
--> the problem, you've probably made a mistake. When the
--> problem itself is
--> sufficiently complex, it's fair to ask if it should be
--> solved. Remember
--> point (3) of RFC 1925.
-->
--> I'll note that a number of the protocols you cite were
--> indeed criticized
--> *during the design process* as too complex. The objectors
--> were overruled.
-->
--> --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-->
--> _______________________________________________
--> Ietf mailing list
--> Ietf(_at_)ietf(_dot_)org
--> https://www1.ietf.org/mailman/listinfo/ietf
-->
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf