ietf-mailsig
[Top] [All Lists]

RE: Ways to proceed

2004-10-14 10:43:03


While it is justified that equal opportunity not be given to all,
as only 4-5 max people are actually effective. But it is not justified
that these 4-5 effective people make the decision. You justify
exclusion and equal opportunity in same breath.

I do agree that functioning at IETF slows down, if not totally prevent,
acceptance of new ideas, equal opportunity to new comers or those who
are not part of cliques. But what you suggest does not sound any better
to me. 

Having audio confernces with 80+ people is going to be a chaos, without 
being able to relate voice to a face/ID. In an email or chat format at 
least you can tell who is saying what, helping in organization of the
ideas as a team. There will be a log to go back to, which is more effective
and less expensive than recording audio conferences and distributing them.

Just my thoughts on the issue.

Atul


-----Original Message-----
From: ext Hallam-Baker, Phillip [mailto:pbaker(_at_)verisign(_dot_)com]
Sent: Thursday, October 14, 2004 12:59 PM
To: 'George Gross'; Hallam-Baker, Phillip
Cc: Sharma Atul (Nokia-ES/Boston); william(_at_)elan(_dot_)net;
ietf-mailsig(_at_)imc(_dot_)org
Subject: RE: Ways to proceed



Hi Phillip,

On Thu, 14 Oct 2004, Hallam-Baker, Phillip wrote:

For the WS-Security WG we started off with 80 people on the calls.

not relevant. By their nature, teleconferance calls have 
the following
non-starter characteristics:

1) they are inherently exclusionary, as there is a finite number of
teleconference participants who must show up at the 
scheduled time, in
contrast to the e-mail process that is 7x24 and scales to 
any size of
group.

And the IETF meetings would be what then?

Getting the job done is inherently exclusionary. Only four or five
people maximum can be effective editors on a spec, the rest can
only really comment if the job is going to be finished.


2) teleconferences generally prevent and/or inhibit 
anonymonity, you must
identify yourself to participate in the call. For some conference
services, who ever runs the call can retrieve call 
originations from the
teleconference billing data.

There is not and has never been a requirement for IETF process
to be anonymous. Suggesting that this should be a requirement
is just silly.


3) it is problematic whether there will be a publically visible and
*accurate* record of the proceedings stored at an archive web 
address. it
entirely depends on the minutes taker's capacity to hear, 
capture to text,
and identify who said what. then post the results for 
review/comment.

That is why in every business meeting the first order of business
is always to review the minutes of the last meeting.

The Victorians managed to make the process work.


4) it places at a disadvantage those participants who have 
English as a
Second Language, or reside in disparate time zones from the 
majority.

The proceedings of the IETF have always been in English, and
all the specs are in English. If you are not fluent in English
you are going to be unable to make more than a limited
contribution.


5) it incurs a recurrent economic and time scheduling expense to
organize/participate.

Rubbish.

In some cases, working groups may delegate subsets of their 
work to design
teams that work offline from the main group and then report 
their findings
in an Internet Draft. However, it is not clear to me that 
process does not
have some of the same exclusionary characteristics found in the
teleconference proceedings. at what point does the design 
team have too
many cooks? who decided team membership eligibility?

You point out the inherent weakness of the IETF scheme. The
ineffectiveness of the mailing list discussions means that
the real decisions get pushed out to a cabal and the rest
of the group feel alienated and in the case of MARID went on
to wreck the proposal.


The IETF is run in exactly the way that most engineers would 
like to work, free from deadlines, accountability and with
infinite scope to achieve technical perfection. The results 
are pretty predictable.







<Prev in Thread] Current Thread [Next in Thread>