Re: Let the market be judge (Re: accusations of cluelessness)
Mark Seery wrote: [..] The ethos of running code is all about establishing a proof that something works. I never said otherwise. Running code has been a useful means for reducing the solution space from which the IETF publishes. It has never been a hard and fast metric of good design. (Indeed, if anything the IETF's history has shown a number of protocol designs that were running code and yet still only waypoints towards better designs in the future.) But that's really not the point here. The role of an _engineering_ taskforce is to act like engineers, not a vanity press. Our output should be educated guidance to the wider community - created with diligence and offered with humility. We can do no more and should do no less. (Arguments that the IETF prevents deployment by preventing publication are a red-herring and should be discarded as such. The market has shown a remarkable affinity, at times, to protocols that have either never been fully published or published outside the IETF.) cheers, gja -- Grenville Armitage http://caia.swin.edu.au I come from a LAN downunder.
Re: Let the market be judge (Re: accusations of cluelessness)
* * But that's really not the point here. The role of an _engineering_ taskforce * is to act like engineers, not a vanity press. Our output should be educated * guidance to the wider community - created with diligence and offered with humility. * We can do no more and should do no less. Grenville, Nicely said!! I would like to see your motto inscribed over the IETF portals... We create with diligence and offer with humility. Bob Braden
Re: Let the market be judge (Re: accusations of cluelessness)
Bob Braden wrote: * * But that's really not the point here. The role of an _engineering_ taskforce * is to act like engineers, not a vanity press. Our output should be educated * guidance to the wider community - created with diligence and offered with humility. * We can do no more and should do no less. Grenville, Nicely said!! I would like to see your motto inscribed over the IETF portals... We create with diligence and offer with humility. Bob Braden Bob, I agree this is a good ethos, which I support, and in general, the IETF is trending back in this direction, the discussion over the last ~year of meatier meetings being one example of the trend in this direction; yours, Keith's and Grenville's expressions being others. The specific issue though in this case, IMO, was whether engineering was conflicting with pragmatics (WRT existing deployments) - happily, the OT thread appears to be flushing this out and moving on. Obviously, the long-lived tension will always be between under-engineering a solution and over-engineering a solution. As this subthread shows, discussing the philosophy doesn't advance the ball on any one particular technical issue very much, only skilled engineers arguing opposing views (a good thing) can do that. Best
Re: Let the market be judge (Re: accusations of cluelessness)
On Sun, 12 Oct 2003 08:02:09 PDT, Mark Seery [EMAIL PROTECTED] said: thing depending on your view). Put another way, if the criminal justice system had the same level of effectiveness at protecting physical assets, I wonder whether civilization as we know it would exist. If you want to take it in that direction, we have a case where the market decided that locks weren't needed on doors in a high-crime area of town. OK, so maybe the crime rate was still low when the door was installed - there's been a lot of delay and negligence in installing said locks. pgp0.pgp Description: PGP signature
Re: Let the market be judge (Re: accusations of cluelessness)
That is a fair point, but I would observe that there are plenty of more cases where locks were not sufficient. If there are no tradeoffs to actions/feedback loops, then agents in a system can not make optimization/fitness decisions and evolution does not occur. [EMAIL PROTECTED] wrote: On Sun, 12 Oct 2003 08:02:09 PDT, Mark Seery [EMAIL PROTECTED] said: thing depending on your view). Put another way, if the criminal justice system had the same level of effectiveness at protecting physical assets, I wonder whether civilization as we know it would exist. If you want to take it in that direction, we have a case where the market decided that locks weren't needed on doors in a high-crime area of town. OK, so maybe the crime rate was still low when the door was installed - there's been a lot of delay and negligence in installing said locks.
Re: Let the market be judge (Re: accusations of cluelessness)
snip the market has sight. market analysts have hind-sight. engineering is about fore-sight. therein lies a world of difference in roles and responsibilities. The fore-sight of any role is constrained by assumptions. An engineer who designs a building to withstand a collision with a 707 suddenly has a lot more hindsight (than fore-sight) when it is hit with a 767. So let's acknowledge there is no such thing as perfect fore-sight for any role, only better or worse given a set of assumptions. there is no perfect foresight. there is no perfect hindsight either. nor is the market either efficient or reliable at choosing good solutions. but we are probably better off using some combination of foresight, hindsight, and market forces than by excluding any of these or relying on any of these exclusively.
Re: Let the market be judge (Re: accusations of cluelessness)
Keith Moore wrote: snip the market has sight. market analysts have hind-sight. engineering is about fore-sight. therein lies a world of difference in roles and responsibilities. The fore-sight of any role is constrained by assumptions. An engineer who designs a building to withstand a collision with a 707 suddenly has a lot more hindsight (than fore-sight) when it is hit with a 767. So let's acknowledge there is no such thing as perfect fore-sight for any role, only better or worse given a set of assumptions. there is no perfect foresight. there is no perfect hindsight either. nor is the market either efficient or reliable at choosing good solutions. It appears the word market is overloaded with lots of social/political ideology so rather than go down that road, let me redirect the point by simply observing that running code allows the designer(s) to get feedback about a design and its implementation implications, which is the point about letting the market decide. Many can imagine a better design for some problem space, according to some fitness bias we have, but imagining a better design doesn't help unless it can be run and produce results, against the fitness bias the consumers of a solution have. There is nothing wrong with basing an implementation on previous experience and foresight, but there are many things which are more complex than what we can readily understand and therefore our foresight is limited - our implementation experience helps here. This is the age old debate about waterfall vs iteration - probably another dead end discussion point. but we are probably better off using some combination of foresight, hindsight, and market forces than by excluding any of these or relying on any of these exclusively. ack. so as usual, there are no absolutes and a fair amount of subjective judgement, which I guess is the reason why discussion occurs.
Re: Let the market be judge (Re: accusations of cluelessness)
there is no perfect foresight. there is no perfect hindsight either. nor is the market either efficient or reliable at choosing good solutions. It appears the word market is overloaded with lots of social/political ideology so rather than go down that road, let me redirect the point by simply observing that running code allows the designer(s) to get feedback about a design and its implementation implications, which is the point about letting the market decide. Within IETF, running code has usually meant interoperability tests of multiple implementations of a single protocol. These days we find we need to be more concerned about the interaction between protocols than we used to be. The notion that protocols can be examined in isolation no longer holds. So for instance: we expect non-TCP-based protocols to share bandwidth fairly with TCP-based protocols; and we expect all protocols to be reasonably secure because when even a single protocol is compromised it can disrupt operation of the network, other protocols, and hosts that weren't directly compromised. The market is not in a good position to evaluate these characteristics because many of these effects do not become visible to the market until the market has already substantially invested in a particular path. Indeed, the very discipline of engineering exists to minimize such catastrophes. If you make design decisions based on guesswork, that's guesswork; if you make design decisions based on analysis of how well a solution meets well-defined criteria, that's engineering. These days, a lot of people seem to be arguing that IETF shouldn't do engineering.
Re: Let the market be judge (Re: accusations of cluelessness)
Keith Moore wrote: snip These days, a lot of people seem to be arguing that IETF shouldn't do engineering. Hopefully not - not I for sure, I mean that would require a name change ;-) What I think exists is a difference of opinion about what the definition of engineering is. Another well-known institution seems also to be stuggling with this same question: *where numbers count for everything and hunches are scorned *http://www.cnn.com/2003/TECH/space/10/12/nasa.reformers.ap/index.html
Re: Let the market be judge (Re: accusations of cluelessness)
These days, a lot of people seem to be arguing that IETF shouldn't do engineering. What I think exists is a difference of opinion about what the definition of engineering is. another way to put it is - after ~17 years of IETF, we need to start defining what Internet Engineering means. Another well-known institution seems also to be stuggling with this same question: *where numbers count for everything and hunches are scorned ignoring hunches didn't cause the demise of Challenger and Columbia. ignoring hard data did. of course, paying attention to intuition might be useful in those inevitable (hopefully rare) cases where you do ignore hard data.
