Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.)

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

--On Saturday, 20 July, 2019 10:17 -0400 Warren Kumari
<[e-mail]> wrote:

> On Sat, Jul 20, 2019 at 9:00 AM Christopher Morrow
> <[e-mail]> wrote:
>> 
>> On Sat, Jul 20, 2019 at 8:51 AM Keith Moore
>> <[e-mail]> wrote:
>> > I believe your statement of intent.  But I think it's fair
>> > to realize that there is already tremendous pressure to
>> > deploy implementations before they've been formally
>> > approved, and there's a danger that any kind of
>> > distinguished "mark" will have the (unintended) effect of
>> > promoting deployment of the marked version of a protocol.
>> 
>> regardless of 'published or not' folk will always push for
>> the early implementation of FOO before it has been 'ratified'.
>> it's pretty clear that this happens, and that nothing about
>> this discussion is going to change that.
>> 
> 
> *I* think that we really want early implementations of FOO
> before it has been ratified - without this we don't have the
> "running code" part of "rough consensus and running code.
> I think the trouble comes in when there are *deployments* of
> FOO before it has been ratified....

Exactly.  And, at the risk of singing an old song, that was
exactly what Proposed Standard was supposed to be about.

So, with the understanding that I'm not optimistic about this
for the reasons I gave earlier and a quarter-century of history,
consider an alternate proposal: Return Proposed Standard to its
original intended status.  Try to make it clear that anyone
deploying a new specification at Proposed Standard is a fool and
deliberately misleading customers about stability and the
future.  Make it lots easier and faster to get one through the
system, e.g., by forbidding or ignoring editorial nit-picking
during IETF LC and, as BCP9 clearly allowed, simply documenting
known omissions and areas of uncertainty and moving on.  Let
Proposed Standards be close enough to preliminary engineering
specifications that there are real incentives to advance (and
carefully finish end edit) documents after implementation and
implementability have been proven.   The main review should be
"is this clear and precise enough to implement for test
purposes, with or without judicious application of the
robustness principle" (one thing we should learn from
implementation, interoperability testing, and running code more
generally is a list of things that need to be documented more
precisely but that, again, was part of the original idea).
Increase RFC Production Center staffing and resources for
editorial cleanups to make documents clear, but use different
criteria for deciding whether a document is "good enough" to
publication to Proposed Standards and Internet Standards.
Narrow AUTH48 for Proposed Standards to a "speak now; explain to
the RFC Editor, IESG, and the community why you need more time;
or just hold your piece"... and, if you are the one author who
has not signed off where others have, note that you will be
dropped to a Contributor by editorial action if you don't
respond within that window.    Identify ADs who are holding
things up and where to the community and future nomcoms, even
explicitly considering it grounds for recall if any one AD is
consistently out of line.  

Would it work?  I obviously have my doubts.  Would it have
chances of working at least as good as trying to devise an
entirely new system and convincing people to understand exactly
what it is about?  IMO, probably yes or at least sooner.   Would
it be equally fast as a WG simply attaching a stamp of approval
to one of its documents?  Probably not quite, but keep in mind
that, once a WG decides a document is ready for publication,
nothing in BCP 9 requires shepherd reports, extensive IESG )or
even AD) review and evaluation, more than two weeks of IETF LC
for WG documents, and then an extensive IESG review and debate
afterwards.  If a document takes more than a month between when
the WG decides it is ready for community review before it is the
hands of the RFC Editor, there is either something substantively
wrong with it, the WG didn't do its job (reflecting badly on WG
leadership and the responsible AD), or we are dealing with
impediments that the community and/or the IESG set up,
presumably in the name of closer attempts at perfection.   If we
think that is a problem, let's fix it, rather than looking for
new terminology that just kicks assorted cans down the road or
that avoids timely review outside the developing WG (again, IETF
LC on WG documents is nominally only two weeks -- that is not
where the problem lies).   And, if all of that means we have too
many WGs and two many work efforts going to be consistent with
quality, let's do some serious prioritizing and change that.

best,
   john