Hi, Philip,
Our mileages probably vary ("welcome to the IETF, variable mileage is
how we know we're here!"), but ...
In the working group chair training, we point out that the most
important thing working group chairs do, and the only responsibility
they can't delegate, is declaration of working group consensus.
Call me a dreamer, but if there's one voice (which may or may not be
from another planet) in a working group, the chair's responsibility is
to decide if this is one of the hopefully rare cases where one voice
SHOULD derail apparent consensus, and if it's not - to say so!
I understand the apparent advantage of saying, "well, if X says it's a
good idea, X is from a large ISP, so they are probably right", but
this doesn't prevent the second-order problem that large companies
(ISPs or not) have a range of employee IQs, and if you defer to one of
the low-order IQs because they work for Y, you may STILL end up in a
bad place. I've seen this bad place personally.
I would hope that we evaluate ideas based on the message in most
cases, and not on the messenger. If that's not what we do in most
cases, I THINK this is a pretty fundamental change in how the IETF
works.
Spencer
From: "Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx>
To: "IETF General Discussion Mailing List" <ietf@xxxxxxxx>
Sent: Wednesday, August 03, 2005 2:55 AM
Subject: RE: I'm not the microphone police, but ...
There are cases where it is useful for a group to be able to take
notice
of first hand experience that comes from employment.
For example I am currently reading a somewhat sureal thread in which
an
individual who clearly has no experience or understanding of running
network operations for a large ISP (million plus customers) is
lecturing
folk on the lack of scalability of a protocol proposed by and already
deployed by several ISPs of that type of scale.
Another issue that frequently comes up is that people will assert that
a
proposal to make a new use of DNS will increase load on the system and
thus risk bringing down core DNS and thus the Internet. Except in
cases
where the protocol is catastrophically bad and unnecessarily wasteful
of
resources these dire predictions have never yet proved true, nor are
they likely to - most load on the core DNS is due to attacks and
baddly
configured DNS systems. Even if the load on the core DNS were to
increase the point of the infrastructure is to serve the needs of
users,
not the other way around.
The point I am trying to make here is that we are not dealing with a
domain that is entirely academic theory. There are cases where
operational experience is significant and affiliation can carry
significance.
If I hear several major infrastructure providers say that they have
examined a proposal and the resource requirements do not cause them
concern as far as their operations go I think it is reasonable to give
such a statement considerable weight unless there are very good
reasons
to think otherwise.
Likewise I would take a concern raised by several major infrastructure
providers that a proposal did have unacceptable resource requirements
very seriously, although I would want to see some documentation and
explanation of the claim.
We do not need to give a veto to major infrastructure providers but
there has to be a mechanism that allows companies to raise issues on
the
record from time to time when they choose. If only to avoid the need
to
argue at interminable length why a 'scalability issue' is nothing of
the
sort.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf