[rfc-i] reject the past ( was Re: Fwd: New Version Notification for draft-flanagan-plaintext-00.txt)

George, Wes wesley.george at twcable.com
Thu Jun 26 10:44:16 PDT 2014


On 6/26/14, 11:43 AM, "Dave Crocker" <dhc at dcrocker.net> wrote:


>This nicely demonstrates a basic problem in these discussions, namely
>ignoring demonstrated utility over many years.
>
>It encourages embracing whatever shiny new capability attracts us now,
>rather than considering carefully the trade-offs between whatever
>benefits have been present in the long-standing capability, versus
>whatever is appealing about a new capability.
WG] I think that I have already responded to this, and Paul has done so
more succinctly.

>The process of producing useful RFCs breaks the workflow of most folk
>who are not already IETF geeks.

WG] and that's considered a good thing? ... Why, exactly?

#include <reference to IETF's existential debate about being unable to
attract {new, young, diverse, operator} participants>

But to clarify, by breaking workflow I mean that if I'm building a
document outside of the IETF, I fire up my document editor (Word, in this
case), and if I decide that I need a simple line-drawing diagram, I can
easily generate it within that document using Word's drawing and shape
tools, or for more complex stuff, fire up visio and directly incorporate
the result. For an I-D, I have to take that method of building a diagram,
find a way to then translate it to ASCII and incorporate it into the
document, because I would NEVER build an ASCII drawing unless I had to,
for reasons that I've already beaten to death in this thread. That extra
step takes longer, and for value that no one has actually been able to
articulate yet.

>We presume some benefits in the RFC model, so I guess I don't see your
>point.
WG] I can only assume that you're trying to be obtuse by equating the IETF
process to produce the actual useful, peer-reviewed, consensus-based
information to the use of the tools necessary to generate and host that
output today, because I'm certain that you know better. The tools are not
some sort of rite of passage or minimum height requirement to ride the
ride, and I reject the notion that they inherently add any value by being
user unfriendly.

>Interoperability often requires choosing a least common denominator.
WG] And in the interest of having an objective, fact-based discussion of
pros and cons, I've been asking for examples of what the lowest bar for
that least common denominator is in 2014, and not getting any.

>What you call 'wastes a lot of time' I tend to call 'forces a discipline
>in representing what is essential'.
>
>I was impressed in the very early days of laser printers -- there were
>just a few outside of PARC, as I recall -- to see a grad student produce
>a summary of his work, for his department review seminar, using many
>different fonts.  The document was so pretty, I almost missed the fact
>that it was nearly content free.  But of course, that was the point.
>
>Presentation restrictions often force us to do extra work at being clear
>and useful.

WG] Pretty arrogant to assume that use of some other tool that isn't as
hard to use will automatically result in inferior quality output, or that
we are so easily distracted by shiny things that we won't notice. Relying
on the tool as a gatekeeper to substitute for quality content or proper
review is just laziness, pure and simple. I want the tools to get out of
my way, and I want *people* reviewing my document to force discipline in
representing what is essential and ensure that I'm being clear and useful.
Otherwise the solution to IETF's quantity over quality problems is to
simply make the tooling increasingly harder until people work hard enough
to produce quality documents.

Wes George



This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.


More information about the rfc-interest mailing list