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

From: "Gray, Eric" <[email-masked]>
Date: Thu, 5 Jan 2006 16:12:56 -0500

Sandy,

	My point - as may be clearer in other posts - is that 
the first question "do we want change" is a no-op at best.
Change is natural and inevitable whether we want it or not.
The first useful question is - paraphrasing what Brian said 
- what do we need that we do not already have?

	All of us have "needs" that are not satisfied by what
we have - hence the inevitability of change.  But it is not
useful, nor realistic, for any of us to assume that everyone
else is going to drop what they're doing to help us satisfy
our individual "needs."  So the question becomes "Is there a 
common subset of our collective individual needs that a large
subset of affected people agree on, that cannot be satisfied 
by what we have now?"

	IMO, that is the question we keep coming back to...

--
Eric

--> -----Original Message-----
--> From: Sandy Wills [mailto:[email-masked]] 
--> Sent: Thursday, January 05, 2006 3:34 PM
--> To: Gray, Eric
--> Cc: [email-masked]
--> Subject: Re: objection to proposed change to "consensus"
--> 
--> 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.
--> 
-->     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.
--> 
--> > 	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.
--> 
--> ...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.
--> 

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

---

From: "Gray, Eric" <[email-masked]>
Date: Fri, 6 Jan 2006 13:20:45 -0500

Spencer,

--> 
--> It shouldn't be a vote (we don't vote - I know you know this, because
you 
--> put "vote" in quotes), but if we had some way to let people say "you
know,
--> I just don't care", that would help, too.
--> 

I agree, and it could also be very useful should we ever start
to realize that it is important to gauge who is paying attention
as well as who is subscribed.

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

---

From: "Gray, Eric" <[email-masked]>
Date: Fri, 6 Jan 2006 19:43:15 -0500

Bob,

	State Diagrams is a bad example.  State machines can, and
should always be, described definitively in text.  State machine
diagrams must be derived from textual description.  Consequently,
if we want to create a document with a pictorial representation,
that document could contain normative references to a document
containing a textual description and not the other way around.

	Being able to put both in the same document and have that
document be authoritative would be a plus, provided we could be
sure that everyone could read that document.

	Perhaps a better example might be complex functional block
diagrams.  Or mathematical expressions as someone else pointed
out earlier.

	If your point is that there are things that are painfully
hard to represent in text, obviously that is true - although we
have had several people argue that this is a good thing, most
of the time.

--
Eric

--> -----Original Message-----
--> From: [email-masked] [mailto:[email-masked]] 
--> On Behalf Of Bob Braden
--> Sent: Friday, January 06, 2006 1:57 PM
--> To: [email-masked]
--> Cc: [email-masked]
--> Subject: RE: objection to proposed change to "consensus"
--> 
--> 
-->   *> 
-->   *> --> 
-->   *> -->     "I think we have reached substantial agreement 
--> on the following 
-->   *> --> statement:  ASCII text was good enough for my 
--> Grandfather, and it's 
-->   *> --> going to be good enough for my grandchildren.  
--> Please reply to this
-->   *> --> CfC if you object."
-->   *> --> 
-->   *> 
--> 
--> "Are we all in favor of Motherhood and Apple Pie?"  "Well, mostly."
--> 
--> No one (well, the IETF is a big tent, so that's probably 
--> too strong...
--> almost no one) questions the desirability of a better format for
--> publishing RFCs than pure ASCII text.  This has been the subject of
--> repeated discussions over the last 20 years.  Will the same 
--> discussion
--> be taking place 20 years from now?  I, for one, certainly hope not.
--> 
--> However, simply wishing we had a better solution is not enough.  We
--> need to have such a reasonable solution in hand before we agree to
--> adopt it.  We believe we want vendor neutrality, ubiquity, 
--> convenience,
--> searchability, editability, etc..  The obvious, simple 
--> suggestions have
--> all failed on one criterion or another, and ASCII has 
--> continued to be
--> the best (if flawed) compromise.
--> 
--> For many years, PS and PDF files have been allowed as 
--> secondary formats
--> for RFCs.  (You can find them by searching rfc-index.txt for the
--> strings 'PS=' and 'PDF=', respectively).  This provision does not
--> handle things like state diagrams, which are presumably 
--> normative.  In
--> practice, creating the PS/PDF forms has been a major pain, 
--> because the
--> documentswere created by the authors using a wide variety of
--> different editors and tools.
--> 
--> On the other hand, it does appear that the availability of ASCII
--> support as a common denominator is decreasing over time.  
--> As has been
--> observed, some software vendors seem to go out of their way to make
--> simple ASCII hard to use.  So there is increasing pressure to find
--> a (truly) better solution.
--> 
--> Bob Braden
--> 
--> _______________________________________________
--> Ietf mailing list
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/ietf
-->