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

From: John C Klensin <[email-masked]>
Date: Tue, 06 Jul 2010 14:54:06 -0400

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

--On Wednesday, June 30, 2010 18:52 +0300 Jari Arkko
<[email-masked]> 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

---

From: John C Klensin <[email-masked]>
Date: Tue, 06 Jul 2010 14:59:13 -0400

--On Wednesday, June 30, 2010 19:16 +0300 Jari Arkko
<[email-masked]> wrote:

> Dave,
> 
>> In pragmatic terms, as odd as it might seem, that is almost
>> explicitly  NOT what
>> the working is chartered to do.
>> 
>> "Full" standard is really about community acceptance, rather
>> than  being about improving the specifications.  For YAM, the
>> focus in  writing the charter was specifically NOT to make
>> any interesting  changes.  Anything that seems to call for
>> interesting changes is  required to /disqualify/ the
>> specification from further consideration...
> 
> My view of the standards ladder advancement in IETF is that it
> was always a mixture of recognizing community acceptance and
> deployment success, removing crud (unimplemented features),
> and yes, even some document improvement.
> 
> In any case, if you believe that the work was useful when the
> "Full" label was available, I presume that was because the
> label would communicate to the world that the document is very
> stable, widely deployed, and so on. Would the work be useful
> if there is just another label "Internet Standard" but you
> explained the status of the work in words in the beginning of
> the document?

Sure, except that the things that go into Maturity Level and
Requirement Level change more rapidly than, and independent of,
the specification and document quality of the protocol.   That
is why we don't put Maturity Level on the front page of RFCs but
leave it for indexes and other ways of reflecting metadata.   If
one combines that perspective with your suggestion, you just
invented what have come to be called "ISDs" (see
draft-klensin-isdbis, posted yesterday).  In this form, that
proposal (the non-grouping part) could be summarized as "explain
the status where appropriate; gradually do away with maturity
levels and maybe requirement levels as categories".