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@xxxxxxxxxxxxxxx] --> Sent: Monday, June 05, 2006 8:21 PM --> To: David Harrington --> Cc: ietf@xxxxxxxx --> Subject: Re: Best practice for data encoding? --> --> On Mon, 5 Jun 2006 20:07:24 -0400, "David Harrington" --> <ietfdbh@xxxxxxxxxxx> 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@xxxxxxxx --> https://www1.ietf.org/mailman/listinfo/ietf --> _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf