Subject: Process for Process Change (Was Diagrams ((Was RFCs should be distributed in XML))

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Thu, 17 Nov 2005 07:34:21 -0600

This is the nth time we've had this discussion RE ASCII art in IETF, but
without a process for process change, no change could be made even if we
all agreed, which we never do of course.  While the discussion may be
enlightening and entertaining, in the end it does nothing but waste
cycles, there can be no forward motion without a way to change the
process.

IMO the ASCII art issue is an important case in point where it would be
good to actually resolve the issue.

Can we develop a process for process change where a proposal like 'allow
I-Ds/RFCs to be posted in Word' can be resolved?

Here's a possible approach:

1. submit a proposal to the IESG for a process change (in the form of an
I-D)
2. the IESG decides by majority vote whether or not to take up the
proposal
3. if #2 is yes, arguments are made for and against by anyone (in the
form of an I-D)
4. after a specified period, IESG votes on the proposal
5. the majority decision of the IESG is binding

But how do we implement *any* such proposal for a process change
process, do we need a process for that??

Jerry

P.S. Some good arguments have already been made on both sides of the
ASCII art issue.  I, like many others, use Word, etc. editors capable of
sophisticated graphics, and have to struggle to convert to ASCII art in
I-Ds.  IMO this is a  ridiculous waste of time and loss of information!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Lars-Erik Jonsson (LU/EAB)
Sent: Tuesday, November 15, 2005 9:19 AM
To: Gray, Eric; Stewart Bryant
Cc: [email-masked]
Subject: RE: Diagrams (Was RFCs should be distributed in XML)

Very well stated!!!

The ASCII-requirement is (apart from being a compact, generic, free,
non-complex, document format) indirectly forcing people to really
make diagrams simple, i.e. not put too much crap (complexity) in one
single figure.

After having had to read documents from other organisations people
often cite as "SDO's", I am personally convinced that the good sides
of using ASCII completely outweights the potential negative aspects.

/L-E

> Stewart,
> 
> 	I suspect most people prefer reading documents that contain
> diagrams, but anything that limits the complexity of a diagram -
> especially for documents most often read on a computer screen - is
> a feature, rather than a bug.
> 
> 	If a diagram is included to communicate (rather than obscure) 
> an idea, then readers should be able to correlate descriptive text 
> to the diagram - either because the diagram is simple enough that
> it is not necessary to keep referring to it, or because the entire
> description can be viewed while looking at the diagram.
> 
> 	Sometimes language limitations are a good thing, when they
> are tied to specific ways of presenting information.
> 
> --
> Eric

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

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Nov 2005 13:35:26 -0500

We do have a process for process change.  We can approve a BCP using
the procedure outlined in RFC 2026.

When we can get a strong consensus behind a process change, that
procedure works reasonably well.

There are other cases where it doesn't work well.  Some of us think
that's OK; some of us don't.

--Sam

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 17 Nov 2005 14:11:50 -0800

> that's OK; some of us don't.

And, in addition - the intention for 
ftp://ftp.rfc-editor.org/in-notes/rfc3933.txt (at least from one of the 
authors) was that it could be used for process change experiments, so we 
don't have to debate process change suggestions endlessly as thought 
exercises before we can try something new.

Spencer