--On Wednesday, August 31, 2011 08:02 -0400 Keith Moore
<moore@xxxxxxxxxxxxxxxxxxxx> wrote:
>> I think the existing Discuss criteria already says very
>> clearly that editorial comments cannot be blocking DISCUSSes.
>
> So nobody has the job of making sure that the documents are
> well-written in clear English?
Keith, I don't think either Jari or I were saying anything
remotely close to that.
Think about it this way, moving away from the language in 2026
and back to the much-earlier assumptions on which that language,
and the multiple-stage standards process, were based. With the
understanding that these are oversimplifications, we can have
three types of documents:
(1) Complete spec, so complete and so clear that someone
with reasonable familiarity with the technology but no
contact with the authors, anyone who participated the
relevant WG, or the WG mailing list can produce an
implementation that will interoperate with other
implementations --both those produced with the same
level of knowledge and those produced by, or in
coordination with, the authors.
(2) Specs that are good and clear enough to act as aids
to memory and documentation about agreement so that
someone who participated in the WG and who can ask
questions of a WG mailing list and/or the authors can
produce an interoperable implementation.
(3) A spec that just outlines an idea for others to try
out.
Because I want to avoid losing the distinction, I would point
out that only the first is really suitable for use in a
procurement spec (although people often accept the second and
sometimes the third).
>From a standardization standpoint, we should consider the third
as potentially appropriate for Experimental, especially if the
purpose of the experiment is to help understand what the details
should be. We've been trying to hold everything (even, in many
cases, experimental documents) up until we get to that first
criterion, but, if one looks at long-term history and reads
between the lines, only DS and above actually require
documentation at that level. We ought to, IMO, be permitting
publication of PS documents at the second level as long as there
are no _obvious_ ambiguities that cannot be figured out (the
same way) by people of good will acting in good faith and with
help from WG lists and as long as there are no other "known
[technical] defects".
I suggest that we have called that second category "Proposed
Standard" and then interpreted that term in ways that have
caused us harm. It is closer to what ISO has called a "Type II
Technical Report" (known in internal jargon as a "pre-standard"
or "sub-standard") and what IEEE calls (or used to call) a
"Draft Standard for Trial Use" -- a document that represents
consensus about the idea and about publication, including
publication as a standard when it is mature enough, and good
enough to form a basis for experimentation and serious
evaluation, but not expected to meet criterion (1) above.
>From that particular narrow perspective, if one wants PS
documents published quickly rather than killing them and the
standards process through delays and nit-picking that are almost
irrelevant to the technical content of the specification, then
we either need to make some really major changes in how we do
things or we need to be willing to publish things that,
explicitly or implicitly contain notes like "the following
paragraph is horribly written and barely intelligible and will
need to be fixed up for DS but, right now, everyone involved
knows what it means". Insisting that all PS documents be
"well-written in clear English" may actually be our enemy.
That doesn't mean they shouldn't be. And it would be perfectly
reasonable for some WGs and authors to decide the situation is
"do the work now (and accept the added delay) or do it later, so
better now". But we should not be trying to force every PS
document to meet such a standard... at least if we want to get
them out quickly and have them treated as interim steps rather
than final products.
>> Besides, we pay the RFC Editor a large amount of money every
>> year to do the editing. Documents need to be clear enough to
>> be understood, but the RFC editor can handle most of the
>> editorial problems.
>
> If the document is edited for clarity after final review,
> that's really a botch in the process. It means that the
> review doesn't apply to the version of the document being
> published. Of course the RFC Editor's resources shouldn't be
> used for documents that aren't otherwise deemed worthy of
> publication, and you'd like to avoid the RFC Editor having to
> do multiple reviews, so I admit that this is tricky to solve.
Yes. See my previous note.
>> (That being said, I've seen documents that were sent back
>> because they really were not understandable. Obviously there
>> is some bar under which you should not go, or the document
>> cannot advance at all. This happens more in WG stages than in
>> the IESG. But if you can't communicate your idea clearly then
>> I think it should be up to you to hire co-workers/editors to
>> help clarify your idea... not the IETF's problem, IMHO.)
>
> If writing clear specifications isn't the IETF's problem, I'm
> not sure what is.
Well, see previous note. But also remember that people evaluate
where to get work done based on what it "costs". And SDOs like
ISO (and ISO/IEC JTC1) and ITU-T bundle professional editing,
pre-approval-review, into the system for "free".
john
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf