> These are not mutually exclusive, and the last point is more > dubious than the first two. While deployment is a necessary > condition for success, so is technical soundness. Our > broader purpose is not just to create new protocols - it's to > keep the Internet working well. Technical soundness can be dealt with in Darwinian terms. Design by committee tends to wreck as much as it improves. Your concern is to avoid mistakes, my concern is the paralysis that affects the standards process. I don't worry very much about mistakes because most are self correcting, people do not usually implement broken specs. If the standards process is responsive you can discover the mistakes quickly and move on. > On the contrary, there are very many occasions where the way > to understand the solution space to a problem is to involve a > large number of people with varied concerns related to that > problem. If I want folk with varied concerns I talk to users, not engineers. > You don't want so many people involved in the > actual design - but you do want them in on the problem > definition and to provide feedback to design proposals. > I've seen very few occasions where a design that was done in > isolation > - even by very intelligent people - held up well on the Internet. That's is a good point but why do you think that an elite engineering forum would be a sensible place to achieve that? > IETF's imprimatur does have an effect, in the sense that if there's a > perceived need for a solution to some problem an IETF > document is more > likely to be seen as _the_ solution than a competing solution > from, say, a vendor. Only once deployment has reached the critical mass point. The market already understands the open standards issue to the point of obsession. But the issue is really one of change control. The first question people ask is 'does this work for me', not 'is it a standard'. It takes so long to obtain the IETF imprimartaur that the success question is settled by the time the imprimataur is received. Perhaps HTTP will be recognized as a standard sometime, but I doubt it. It should take the IESG what, five seconds to agree that HTTP is a standard? To give a concrete example, does anyone believe that CSV+IETF imprimataur has a hope of displacing SPF/Sender-ID with no imprimataur? > > The real point of a working group process is to establish the > > coalition of support you need to get the work deployed. > > I strongly disagree. And treating this as the real point of > a WG is a good way to produce garbage. What is really needed > is a balance - get the right people on board to produce a > good solution that meets a wide variety of needs, AND who > will help get the result deployed. That's not the same set of > people, but often there is some overlap. I don't have any problem with either group you mention. The problem in a WG is when you get visited by rock throwers or zealots who have a completely different agenda, or some other group that wants to get their standard deployed by making it a precondition for a spec that has a lot of public momentum. We still have WGs being told that they have to support BEEP, despite the fact that it is inadequately engineered as a web services transport, has been decisively rejected by the market as a web services transport and is based on obsolete technology. SACRED was bounced into making BEEP their transport despite the fact that the spec only makes sense as an adjunct to SAML and XKMS which are SOAP based. The RID spec was made worse by the insistence on support for BEEP. Why is a 'standards' organization enforcing this Not Invented Here attitude? If you look at what every Web Services platform supports, both commercial and FOSS the only conclusion that is possible is that BEEP should be moved out of standards track and considered obsolete. The SOAP work won because it is supported by a much wider coalition of vendors and developers. It established the necessary support. BEEP was fast tracked through IETF in a transparent attempt to try to pre-empt SOAP. It is a failure because the WG did not have any of the Web Services platform developers participating. > People will say to > themselves, if the FemtoSoft or TransCo guy is that opposed to this > proposal, it doesn't have a chance of being deployed, so I'm > going to withhold my support also. I've seen it happen lots > of times. I'm > very opposed to giving FemtoSoft and TransCo more votes than > anyone else but I don't have a problem with individuals > considering that certain contributors input carries more > weight than others. Which is the same process I see. Yes there are occasions in which you get a company that has some evil vendor scheme going on, I have not seen many cases where this has succeeded. But I have seen many cases where a group of rock throwers or zealots have decided to visit a group with the sole purpose of 'sticking it' to some vendor they dislike for some reason. > > In my book people who actually write code and deploy code have a > > rather bigger say in the typical decision than those who do not. If > > someone makes a proposal and the authors of the six major > > implementations and all the ISPs in the room vote against > it then in > > my view the proposal isn't happening regardless of what the > > 'consensus' might be. > > And in all my IETF experience I've never seen anyone declare > consensus > when the authors of six major implementations and all of the ISPs in > the room were opposed to it. We have both seen cases where the chair has refuse to acknowledge the need to change a spec in order to support real world constraints that affect key stakeholders. IPSEC should have supported NAT from day one. IPSEC makes a dreadful, lousy VPN protocol because it does not support NAT properly. But it was only after several years of complaints and a revolt by the vendors that anything was done about this. I remember very clearly Steve Bellovin saying to the IPSEC WG that the IPSEC proposal as then defined would not support NAT well but that some folk would consider that to be desirable. Five years ago you were one of the people who argued that it would be better not to deploy DNSSEC than make the changes I was proposing. You were successful in sticking it to a vendor you dislike. And the Internet is the worse as a result. If my advice had been taken then DNSSEC would be deployed now and people would be adopting it to avoid the DNS based phishing attacks that are taking place. > When chairs do abuse their positions, there's a process for > that. I do think that we have too many cases where chairs > are also document authors so that there is an almost inherent > conflict of interest. The process is to complain to the unelected AD who may not be too happy challenging a WG chair who is also an AD and whose support he might need. > > Why can't we elect the WG chairs? Why can't we elect the ADs? > > Say for the purpose of argument you're running a business, or > maybe a large non-profit organization. Would you let your > employees elect > their managers? Do you think that would be a good way of > choosing people who would carry out the organization's > strategic goals? I don't consider the ADs managers. In OASIS, Apache, most FOSS projects we elect the oversight boards, in W3C we elect most of the oversight board and it is pretty clear that any director that succeeds TBL is almost certain to lose the appointment privs that the director currently has. The IETF is the only institution I have ever encountered that has such a deficit of accountability. Even the US universities have moved to having student representatives on most boards. > The last thing that iETF needs is to let organizations buy votes by > having their employees become members or sending them to meetings. There are about 1000 people who qualify for Nomcon. To influence a vote a company would need at least 300 people and plan their approach a year ahead. The cost of each vote is 2 * ($600 + airfare + 1 weeks pay + overhead). That's at least $5000 per vote if they send secretaries along, $10K for an engineer. So to have an effect it would cost about $3 million. I don't think that vote packing would work here. The only time I have seen it in other standards orgs is when patents have been involved and someone is trying to get a patent embedded in a standard. I see that as a function of weak IP controls. > I could see a place for voting in some things - like choosing > people who decide or oversee how the organization's money is > spent, and > maybe in choosing ombudsmen who would help in dispute > resolution. I don't think voting has a place in IETF's > technical decision-making. I don't think that you vote over whether the earth is round or flat. But it is useful sometimes to have a vote to say that it is not worth discussing the round/flat issue any further. My problem with WG processes is where you have the flat earth faction coming back to the table again and again to argue the case long after the time has passed. If a group of loosers get together in a room they will produce lossage. I don't worry about that because lossage has a short lifespan. Even in the security area the evidence of SSL 2.0 and WEP demonstrate conclusively that it is much better to deploy a broken spec than wait for perfection. Mistakes are bad but if the D-Team do manage to get something out into the market and used the A-Team will be along soon enough to fix it. > If you had tried to identify the parties whose buyin were > needed to deploy IPsec and IPv6 you'd have gotten it wrong. My first meeting might not have the right people at the table but my third always has. > In both of those cases a big part of the reason for the delay > is that the people developing the protocols didn't understand > their target market. (this may still be the case to a large > degree) And it's not because the presumed-to-be major > players weren't involved, it's because the participants > didn't fully understand and anticipate how the Internet was > changing. Voting wouldn't solve that problem. The major players are not the vendors, they are the backbone carriers and the ISPs. > > The way the system works in OASIS is that there is a con call every > > week or two weeks and members of the group have to attend the con > > calls to maintain voting rights. > > That's a really lousy way to ensure broad input and a really > good way to make sure that the group works in isolation and > produces irrelevant output. SAML was produced in less than a year and has been considerably more successful than most IETF specs produced in that period. Actually the process has the reverse effect. People attend WG meetings to keep their voting rights. Instead of four people carrying the WG there are 40 or more. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf