Re: [yam] Referencing 1652bis and update to RFC 5321/5322

[John C Klensin <[e-mail]>]

(sorry for the delay responding to this -- got lost in the
mailbox)

--On Wednesday, June 30, 2010 18:52 +0300 Jari Arkko
<[e-mail]> wrote:

>...
>> if the IESG does, then YAM is pretty
>> worthless even though the documents themselves (again, like
>> almost all other documents the IETF has produced) could be
>> improved.

> I do not believe the IESG is saying that everyone should be
> using errata from now on. There is certainly some frustration
> in the community and sometimes in some of my fellow ADs about
> the time it takes to produce an RFC, and that does sometimes
> lead people to not bother with doing it, relying on Internet
> drafts, errata, common sense, their own memories or their code
> base to reflect what the true protocol behaviour should be. I
> still think its better to publish RFCs. (And for the record, I
> do not believe it is that hard.)

I don't believe it is that hard either.  More important, I
believe that, if it is that hard, it is largely something we are
doing to ourselves, not something the process requires.

In particular, I think there is a tradeoff spectrum between
"insist that WGs /authors/ editors produce reasonable text" and
"expect the RFC Editor to edit" (which includes expecting them
to have the skills to do that work and giving them the time to
apply those skills).  I don't see "the IESG, or individual ADs,
take on the role of editors or editorial nit-pickers" as
occupying a point along that spectrum and I'm inclined to
believe that particular type of IESG intervention is a waste of
time that makes publishing RFCs harder, less pleasant, and more
time-consuming than it ought to be.

Now, doing things well might call for some process changes, not
to what 2026 (and related documents) require, but to how the
IESG has chosen to do things.  Perhaps (especially at Proposed
or whatever the entry level is called) the IESG should be
approving documents on technical content and principle (e.g.,
"no known technical defects"), handing them off to the RFC
Editor, and then doing a final check (either by the IESG or the
sponsoring AD) to be sure the RFC Editor has done its job.   The
purpose of that check would be to check, not edit: if the
conclusion that the RFC Editor's edits were not sufficient, then
the solution would be to fix the RFC Editor, not to start
editing in the IESG.  The highly-skilled RFC Editor staff would,
I'm sure, adapt quickly and, if one examined the calendar time
from handoff to the IESG or end of Last Call to RFC publication,
I think it would get shorter even though proportionately more
time would be spend in the RFC Editor and less in the IESG.

But this isn't what we are doing.  Instead, we are making it
very painful --possibly approximating "as painful as possible"--
to progress things via the "issue revised document as RFC" path.
Whether that path is labeled "Step 3 - Full Standard" or
"recycle at "Step 2 - IESG-awarded Standard with Gold Star" may
make less difference than appears at first glance.  But there is
one big difference (although not one really required by 2026):
To move something to Full Standard typically requires that we
revise and reissue the full document (remember that 5321 is only
a bit under 100 pages, so there is lots of opportunity for
nit-picking and other ways to waste time (or, if you prefer,
attempt to achieve documentary perfection)).  Without that
motivation for re-doing the entire, long, document, a far
shorter document could be issued that addressed _only_ the
substantive specification issues and did so purely as
corrections/ clarifications to the base document.  

Maybe that would be a good thing, especially if our concern is
about protocol quality and clarity rather than documents that
can get the blessings of editorial nit-pickers and stylists from
all directions and perspectives.  Before deciding, I'd encourage
you to review the concerns and issues that held 5321 itself up
in the IESG for many weeks.  If I recall, all of them (including
the "example" discussion) were about style and presentation --
not about protocol quality or clarity of the description.

     john