Subject: RE: objection to proposed change to "consensus"

From: "Gray, Eric" <[email-masked]>
Date: Thu, 5 Jan 2006 14:50:39 -0500

Sandy,

	What you say is correct, as far as it goes.  However,
the implication in the wording is that people disagreeing
with a proposal will post and people disagreeing with them
will not.  This is the case - as you suggest - when there 
is a clear "default outcome".

	In fact, contrary to what we observe in nature, change
is not the "default outcome" in most human organizations.
That is because - as a careful analysis of this discussion
over the years will disclose - there are as many ways to go
with a change as there are people prepared to make changes.

	Consequently, it is at least as valid to assume that 
- particularly when a proposal represents a departure from
status quo - that people may not be responding because they 
agree with the _objections_ already made and _also_ do not 
want to add to the general hub-bub.

	Consequently, if we see 10-20 people posting in favor 
of a _specific_ proposal and similar numbers posting against 
that same _specific_ proposal, then it is out of line for us 
to assume that any particular opinion is indicated by silence.

	Note that it is _very_ important to distinguish support
for a particular change from support for the idea that some
change is required.  For example, if you have well over 100 
people who all agree that change is required, and only 20 who
argue that no change is required, you have to evaluate the
agreement for a specific change (or at least a specific change
direction) rather than a general discontent with status quo.
If no more than 5 or 10 people agree to a specific proposal,
then the net effect is a consensus for the status quo (better
the devil you know).

	As one of the people arguing for status quo, I can tell
you that it is not that I am happy with it.  It is because I
do not see a reasonably well supported alternative to status
quo being proposed.

	In fact, a big part of the discussion right now stems 
from the fact that a lot of people have not really understood
exactly what the status quo is.  People who believe that they
cannot submit an ID containing complex graphics in some form 
other than text, clearly do not realize that this is not the
case.

	I like the quote about "coffee", by the way...

--
Eric

--> -----Original Message-----
--> From: Sandy Wills [mailto:[email-masked]] 
--> Sent: Thursday, January 05, 2006 12:48 PM
--> To: Gray, Eric
--> Cc: 'Yaakov Stein'; [email-masked]
--> Subject: Re: objection to proposed change to "consensus"
--> 
--> Gray, Eric wrote:
--> 
--> > "It is much more likely to hear from the very vocal 
--> people who are 
--> >  opposed to the change. That is, assuming 1000s of participants 
--> >  on the IETF discussion list, perhaps 20 expressed 'nays', even 
--> >  strong nays, could be considered a clear consensus in favor of 
--> >  change."
--> 
--> While I can't speak for everyone else, this seems correct 
--> to me.  "Do I 
--> have anything useful or enteresting to add?" and "Do I 
--> think that my 
--> input will change the output?" must both evaluate to "Yes" 
--> before I post 
--> to any discussion.  I occasionally post for humor or interest, but 
--> generally I follow the discussion and stay out of it unless 
--> I believe it 
--> to be going badly awry.
--> 
-->    To be blunt, do we want every question to be answered by several 
--> thousand AOL "Me too"'s?  The silent masses are silent because they 
--> don't have anything useful to add, and believe that an 
--> endless stream of 
--> agreements would do nothing useful except test our bandwidth.
--> 
-->    We do, on the other hand, chime in when necessary.  So, 
--> it is "good" 
--> and "right" and "fair" to assume that a public question 
--> with a default 
--> answer has concensus, if the only response is a minor 
--> negative one.  I, 
--> and I believe many others, will simply move on to the next 
--> post when we 
--> see the question, if we agree with the default answer.
--> 
-->    A simple mental experiment: If we have, say, 2000 
--> readers, and we 
--> post the question
--> 
-->    "Will the sun rise tomorrow?  We think yes."
--> 
-->   then we can expect a small number of disagreements, a 
--> small number of 
--> arguments from readers who didn't understand the question, a small 
--> number of AOL's, a small number of "Of course, you twit!  
--> Why are you 
--> wasting our time with this?" and nothing else.  The vast 
--> majority of the 
--> readers will not reply, because they agree with the default 
--> answer, and 
--> they have other things to do.
-->    If there is a reader who disagrees in his mind, but is 
--> constrained by 
--> cultural conditioning or natural manners from speaking out, 
--> how are we 
--> supposed to coax his "better way" from this reader?  We 
--> have already 
--> posited that he/she/it won't speak up.
-->    I submit that the IETF culture should, by policy, assume 
--> that anyone 
--> subscribed to an IETF list will speak out on any question 
--> if he/she/it 
--> thinks it right.
--> 
--> >     The current process requires weighing of voices, not weighing
--> > of the supposed opinions of the silent.
--> 
--> Yes, _but_ anyone who agrees will not argue.  You will only 
--> get argument 
--> from those who disagree with the post.  Unless you want to 
--> change the 
--> culture here to require an answer from every reader, on 
--> every question, 
--> thus adding significantly to our daily workload.  I'd rather not.
--> 
--> -- 
--> Unable to locate coffee.
--> Operator halted.
--> 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Sandy Wills <[email-masked]>
Date: Thu, 05 Jan 2006 15:34:26 -0500

> with a change as there are people prepared to make changes.

    I think that there is also a very strong element of emotional 
attachment to any system or solution, from those people who had a hand 
in creating it (Certainly, I'm just as guilty of this as the next guy!). 
  Any job is harder if you have to change your tools every time you get 
used to them.
    It's also true that some people will object to anything in front of 
them, simply because it was done by someone else.
    We also have the "religious" responses, both pro and con, where 
someone either approves (or disapproves) of it simply because of the 
source.  We've all seen "It's gotta be good, Jon Postel wrote it", as 
well as "I'll cut my wrists before I use MS software"

    It appears that, if we want to judge solution-quality by mob volume, 
we need to find some way to separate the emotional responses from the 
reasoned responses.  Unfortunately, I don't have one handy.

> do not see a reasonably well supported alternative to status

...And we are back to what has been said many times already.  "Do we 
want to change? Answer yes/no" and "What do we want to change to?" are 
_not_ completely separable.  You admit that you aren't happy about the 
status quo, but will still answer "No" to the first question because you 
don't trust us as a community to come up with a sane answer to the 
second question.

    The only quick and easy solution I see would be a multiple-choice 
question, perhaps on a web site, with options like:

   A) The world is perfect.  Change nothing.
   B) I hate our system, but don't trust you bozos.  Change nothing.
   C) Change to cunieform-and-clay, for everything.
   D) Change to marble for ID submission, and MS Word '95 for RFC 
publication.
   etc, etc, etc.

   I choose to _NOT_ volunteer to write and host this website.

> 	I like the quote about "coffee", by the way...

Thanks!  While it's not original with me, I certainly still remember the 
pain involved with the source "Unable to locate COMMAND.COM - Processor 
halted"

-- 
Unable to locate coffee.
Operator halted.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 09 Jan 2006 11:55:04 -0500

>>>>> "Sandy" == Sandy Wills <[email-masked]> writes:

    Sandy> Gray, Eric wrote:
    >> Sandy, In fact, contrary to what we observe in nature, change
    >> is not the "default outcome" in most human organizations.  That
    >> is because - as a careful analysis of this discussion over the
    >> years will disclose - there are as many ways to go with a
    >> change as there are people prepared to make changes.

    Sandy>     I think that there is also a very strong element of
    Sandy> emotional attachment to any system or solution, from those
    Sandy> people who had a hand in creating it (Certainly, I'm just
    Sandy> as guilty of this as the next guy!). Any job is harder if
    Sandy> you have to change your tools every time you get used to
    Sandy> them.  

I think that's a valuable thing to consider in consensus building.
"This makes me retool how I do things; it works well today," is
actually a valid input to a discussion.

    Sandy> It's also true that some people will object to
    Sandy> anything in front of them, simply because it was done by
    Sandy> someone else.  

I'm having a hard time arguing that this is a good thing.

    Sandy> We also have the "religious" responses, both
    Sandy> pro and con, where someone either approves (or disapproves)
    Sandy> of it simply because of the source.  We've all seen "It's
    Sandy> gotta be good, Jon Postel wrote it", as well as "I'll cut
    Sandy> my wrists before I use MS software"

I think these are valuable inputs as well.  There are people involved;
whether these people are happy, whether they will continue to work,
are important factors.  Of course there are religious arguments on the
other side: "I want my architectural diagrams; they work well in the
ITU and I want them here," is on the same level as "I won't use MS
software."

Note that related to religious arguments may be more practical issues
as well.

    Sandy>     It appears that, if we want to judge solution-quality
    Sandy> by mob volume, we need to find some way to separate the
    Sandy> emotional responses from the reasoned responses.

I disagree that discarding the emotional responses is appropriate.

--Sam

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 09 Jan 2006 18:17:32 +0000

>ITU and I want them here," is on the same level as "I won't use MS

Sam

I disagree that the use of diagrams is a religious issue. Diagrams
are a very simple way to put specification and context together
in a compact notation such that it is easy to move from key point
to key point in a non-linear way. They provide visual hyperlinking.

Here is a good way to judge the value of a diagram:

Look at a diagram presented in an IETF WG session and ask the
questions : does this diagram make the draft easier to understand?
If the answer is yes, then the diagram should probably be in the
draft.

The problem is that it is frequently impossible to translate the
clarity of the graphics used in the presentation to the technology
of ASCII art.

- Stewart

---

From: John C Klensin <[email-masked]>
Date: Mon, 09 Jan 2006 14:02:59 -0500

--On Monday, 09 January, 2006 18:17 +0000 Stewart Bryant
<[email-masked]> wrote:

>> I think these are valuable inputs as well.  There are people
>> involved; whether these people are happy, whether they will
>> continue to work, are important factors.  Of course there are
>> religious arguments on the other side: "I want my
>> architectural diagrams; they work well in the ITU and I want
>> them here," is on the same level as "I won't use MS software."

> in a compact notation such that it is easy to move from key
> point to key point in a non-linear way. They provide visual
> hyperlinking.

Stewart, 

While I agree that diagrams are not simply a religious issue, I
think that there are many cases in which the use of diagrams,
especially complex ones, leaves people with the impression that
they have understood something when, in fact, they do not.  Ed
Tufte's work, among many others, has provided repeated
graphical, and often humorous, illustrations of that point.
Part of that issue overlaps the resistance to WG sessions that
are dominated by PowerPoint presentations every time that
discussion breaks out, although some of that discussion is
driven by what are clearly religious issues.

This brings us back to one on the early comments in these
threads -- that the need to describe a complex concept in text
or in ASCII art imposes a discipline that is actually quite
useful.  I agree with you that there are some things that cannot
be thus described with a sensible amount of effort, but it has
seemed to me that it would be helpful, from a document quality
standpoint, to examine each case and to try to strive for the
minimum diagram complexity that is actually necessary.

I get even more concerned when it is suggested that not only are
diagrams are needed, but that color documents may be needed.
While things are easier than they were a decade or two ago, the
need to transmit and render color images imposes costs in both
printing facilities and transmission sizes of documents that I,
at least, would prefer to avoid unless necessity can be
demonstrated.  Sam can, and I hope will, speak for himself, but
my experience working with programmers with visual difficulties
some years ago suggests that while monochrome line art --whether
conveniently expressible in ASCII or not-- can often be made
comprehensible with sufficient effort, either continuous-tone
materials or line-art drawings that depend on color are fairly
close to impossible.

> If the answer is yes, then the diagram should probably be in
> the draft.

I think that criterion leads down a slippery slope toward
documents that are collections of PowerPoint images.   The
understanding of a document in a WG session can be improved by
an oral presentation with selected bullet points on slides, too,
but that doesn't automatically make the case that either that
the bullet points ought to be precisely the section headings of
the document or that the slides should be included with the text.

> The problem is that it is frequently impossible to translate
> the clarity of the graphics used in the presentation to the
> technology of ASCII art.

Assuming we agree on that, can we figure out some criteria or
guidelines for keeping graphics to the minimum complexity needed
to express ideas, for being sure that graphics are accompanied
by good  explanations whenever possible, and generally for
preventing people from going hog-wild with complex colored
illustrations?   It seems to me that, if possible, we also need
to find ways to be sure that any normative graphics that appear
in I-Ds can be edited with tools that are easily accessible on
all relevant platforms.

Most of the above of course are probably best taken as input to,
or evaluation criteria for, precisely the sort of experiment
that Sam suggests.

    john

---

From: Scott W Brim <[email-masked]>
Date: Mon, 09 Jan 2006 14:33:36 -0500

On 01/09/2006 14:02 PM, John C Klensin allegedly wrote:
> they have understood something when, in fact, they do not.  

> the need to describe a complex concept in text
> useful. 

Yup, although we've seen plenty of cases where people understand text
differently as well.

I think I'm beginning to like TeX again.

---

From: Ned Freed <[email-masked]>
Date: Mon, 09 Jan 2006 17:16:18 -0800 (PST)

> graphical, and often humorous, illustrations of that point.

That's an interesting way of looking at it that I hadn't considered before.
Tufte's work is for the most part focused on elaboration of the best techniques
for presenting things visually - lessons that few us seem to heed. But it also
provides a catalog of how and sometimes even why things go wrong, as well as
providing ample evidence of how surprisingly hard it is to get this stuff
right.

> driven by what are clearly religious issues.

I guess, although I find Tufte's monograph on PowerPoint to be pretty
levelheaded but a savage indictment nevertheless.

> minimum diagram complexity that is actually necessary.

Not to sound trite, but whether or not a diagram works to advantage is highly
dependent on the visual aspects of the thing being diagrammed. And sometimes
finding those aspects (or not finding them, as the case may be) requires some
effort.

For example, one time I drew out a state diagram for SMTP (which is
surprisingly complex, BTW) with the intention of asking you to include it in
821bis (now 2821). I don't recall if I ever showed it to you or not, but it's a
case where a diagram hurts rather than helps. But you have to draw it and
fiddle with it in order to see it.

The TCP state diagram, OTOH, is one where a diagram really helps. At least
part of this is due to the fact that there are symmetries in the state
flow that most easily observed in a diagram - they'd be hard to see in text.

Another example is the teletex state machine (T.101 or something like that -
I'm not going to bother to search for it) is so complex that the state diagram
fills at least two pages and still leaves out some details. It seems likely
that no amount of graphical or prose ingenuity would be sufficient to tame this
particular beast. The authors of the specification that includes appear to have
tried (and IMO failed).

In any case, while I think better diagrams would be helpful, I am concerned
that if we make them cheap and easy we will actually lower the quality of
our specifications, not raise it.

> materials or line-art drawings that depend on color are fairly

It is incredibly easy to misuse color coding - in fact we have a good example
in our own current processes. These days the RFC Editor makes available
differences listings showing the changes been the draft and the final RFC.
These listings show deleted stuff in struck out red letters and added stuff in
dark green. This scheme may sound fine, but it isn't: Try finding an added
commas or single letter change inside of a big block of black text. That one
bit of green simply vanishes unless you look really, really close. And
sometimes a comma  can change the meaning of something quite dramatically. (I
addressed this problem personally by regenerating the differences using my own
tools that make more appropriate color choices.)

I have to say I still find it amazing given the prevalence of red-green color
blindness how much material on the web and how many applications blunder badly
in their use of red and green signals. 

> documents that are collections of PowerPoint images.

I'm afraid I have to agree.

> ...

> in I-Ds can be edited with tools that are easily accessible on

These are precisely the issues that have to be addressed. I'd love to have
the ability to include better diagrams, but not if it means compromising
on any of these points.

> or evaluation criteria for, precisely the sort of experiment

I agree, but with one important caveat: Some aspects of this problem cannot
possibly be tested by any short-lived experiment. The most obvious example is
format longevity and stability: Microsoft Word as a format might be
sufficiently stable for the duraction of such an experiment, but that says
little if anything about the stability of the format for a couple of decades.
Like it or not, the only thing we have to go on in this space is past
experience.

				Ned

---

From: Sam Hartman <[email-masked]>
Date: Tue, 10 Jan 2006 12:33:57 -0500

>>>>> "Stewart" == Stewart Bryant <[email-masked]> writes:

    >> religious arguments on the other side: "I want my architectural
    >> diagrams; they work well in the ITU and I want them here," is
    >> on the same level as "I won't use MS software."
    >> 
    >> 

    Stewart> Sam

    Stewart> I disagree that the use of diagrams is a religious
    Stewart> issue. Diagrams are a very simple way to 

I think the discussion has reached an all time low.  We're arguing
about whether something is a religious issue or not.

I think I'll add one more reason to why I think it is important to
consider religious issues: that way,you don't have to argue about
whether something is religious.

--Sam