begin oe_protect.scr
Roy Culley <mrloy@xxxxxxxxx> espoused:
> begin risky.vbs
> <6099254.IYlMtA2Cua@xxxxxxxxxxxxxxx>,
> Roy Schestowitz <newsgroups@xxxxxxxxxxxxxxx> writes:
>> Wireless Wars Update
>>
>> ,----[Quote ]
>>| The IEEE itself shut down that task group last June to conduct an
>>| investigation, after charges of conflict of interest and favoritism
>>| on the part of the chair, as well as stacking the vote by some
>>| members, were leveled. The IEEE standards board conducted an
>>| investigation, and found "a lack of transparency, possible
>>| 'dominance,' and other irregularities in the Working Group."
>> `----
>
> At the risk of pissing off Mark, this is where I think the IETF and
> RFC's are excellent. Before a protocol (ie standard) can become an
> official RFC there must be 2 independant implementations. Almost
> invariably this has led to at least one open source implementation.
> The Internet wouldn't be what it is today without that requirement.
I don't disagree with your sentiments here, Roy. There's a lot to be
said for not basing a standard on English alone. You might have seen
some of my other postings where I have stated how completely broken I
think that method of specification is. State-machines are far better
specified in source.
The problem I have with the IETF is that whoever's there votes, whoever
isn't, doesn't, and several companies, particularly Cisco, have dominated
the IETF, so we've had a lot of RFCs which are either impossible to
actually make work, or make networking assumptions which can be proven
to be incorrect.
Let me give an example: let's say that we want a standard to provide
"deterministic forwarding and trunking behaviour" using IP. I set up
a couple of machines which demonstrate a protocol - who can check what
it really does? Real networking problems occur on networks with
thousands to hundreds of thousands or more nodes, not just two or three,
or even twenty or thirty, in a lab.
The result of this approach? We have RSVP, MPLS and a raft of other
protocols which can never work in anything but an environment built on
top of /another/ network which provices the required deterministic
behaviour.
>
> Organisations like the CCITT fail in this respect. CHILL is a classic
> example of something agreed by committee but full of compromises. The
> RFC method works because it is the implementers that decide how a
> standard should be. When I worked on real-time telecoms systems we
> were always happy when we had a contract with BT. Why? Because they
> translated CCITT specs into English. :-)
>
Hehe :-)
In many respects, the IETF is superior to the ITU (CCITT as was),
however, it's reason for existence was to provide US companies with
control over standards, whereas the ITU divides the control across the
world. This is why the voting method is about /who is present at the
time/. So, a small company in Europe, Middleast, Africa, Asia will
never get an RFC, because they will not be able to even get to a
meeting, demonstrate their wares, and persuade all the delegates who are
present to vote for them. Why? Because the relationships are already
built up. I have several years "prior" in various standards bodies, ITU
included, and I know very well that much decision making is about who's
spoken to whom over coffee, tea, beer, lunch, dinner, etc.
Personally, I think the most effective and evolved standards system I've
ever seen is sourceforge. If you like what's out there, or you think a
project is going the right way, but have something good to offer, you
can contribute code. If you don't like what's there, you can start your
own project off. The internet itself has provided the most fertile
ground for this approach, which will, in the end, replace much standards
activity.
--
| Mark Kent -- mark at ellandroad dot demon dot co dot uk |
Thank God a million billion times you live in Texas.
|
|
