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

John C Klensin <john-ietf@jck.com> Sat, 20 July 2019 15:01 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C36D120285 for <ietf@ietfa.amsl.com>; Sat, 20 Jul 2019 08:01:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.104
X-Spam-Level:
X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-g-n2m4YoW4 for <ietf@ietfa.amsl.com>; Sat, 20 Jul 2019 08:01:47 -0700 (PDT)
Received: from bsa3.jck.com (unknown [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 056B5120274 for <ietf@ietf.org>; Sat, 20 Jul 2019 08:01:47 -0700 (PDT)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1hoqro-0001JU-MR; Sat, 20 Jul 2019 11:01:44 -0400
Date: Sat, 20 Jul 2019 11:01:39 -0400
From: John C Klensin <john-ietf@jck.com>
To: Warren Kumari <warren@kumari.net>
cc: john heasley <heas@shrubbery.net>, IETF Discuss <ietf@ietf.org>
Subject: Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.)
Message-ID: <9117005076ECB7DCAB5B2D0B@JcK-HP5.jck.com>
In-Reply-To: <CAHw9_iL-9D1EFZcXp6twK+WL137F5zArLcUrJw50Q-YL0PBpag@mail.gmail.com>
References: <F2D5DCCF-4051-444B-9522-9E11F9F93005@fugue.com> <869599E9-7571-4677-AB9A-961027549C54@network-heretics.com> <144ff436-a7a2-22f7-7b06-4d0b3bcfefac@joelhalpern.com> <20190719041456.GL33367@vurt.meerval.net> <254fc5f6-3576-a62f-b84f-a7c5d29b0055@joelhalpern.com> <a1561aa7-5f41-0e2a-1892-cfb587196ac0@gmail.com> <C3D53639-C2C0-42CE-9708-99294091E012@puck.nether.net> <a17a8648-14c8-1889-4ee3-86996ff6281e@gmail.com> <3B0C189A-D56B-430F-82FF-19DE0DC788DE@puck.nether.net> <BA80E73F53C26B9191294131@JcK-HP5.jck.com> <20190719190534.GG38674@shrubbery.net> <7FF2DA2F2DC64741DA8B5747@JcK-HP5.jck.com> <CAHw9_iL-9D1EFZcXp6twK+WL137F5zArLcUrJw50Q-YL0PBpag@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Z6_0qxDxWR-ecc4U3a2rQJTPKjY>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Jul 2019 15:01:57 -0000

Warren,

This is very helpful.  See inline below.

--On Saturday, 20 July, 2019 08:11 -0400 Warren Kumari
<warren@kumari.net> wrote:

>> But, as I understand it, that is precisely what these
>> proposals are about: allowing a WG to declare a piece of its
>> work as ready to go without review and validation by the rest
>> of the IETF.
> 
> Whoa, no no no - that's not the intent, but I think I now
> finally understand much more of the disconnect in this thread.
> 
> When Job initially presented his idea it seemed to me (and
> still seems to me) that this would solve a bunch of very real
> needs, and I started playing with some ideas on how we could
> implement something like this. Unsurprisingly I was viewing
> this though the lens of my own experiences, and I really
> didn't intend marking a draft in this way as carrying as much
> weight as people seems to think it would.

Another distinction may be important here. Let's assume that the
IETF reached consensus that a particular type of document should
be called a "Kitten".   We all understand what "kitten" means,
just as we understand that the LAMPS WG isn't about lighting
fixtures.  No problem.  Now, whether out of marketing needs or
simple misunderstanding (or even malice) someone outside reads
or is told "kitten document from the IETF" and hears (or wants
to hear) either "some sort of feline from the IETF" or just
"IETF document".  And then, if they are interested in promoting
the document, and are in an environment where lions are highly
respected, it is presented as "IETF Lion document" or, if they
are opposed to the specification or the IETF itself, "IETF
person-eating tiger".

Now, again, _we_ would never make that mistake.   But substitute
"Informational RFC" for "kitten" and then replay in your mind
every heated discussion we have had (at least since you started
participating) about the problems caused when people
accidentally or deliberately confuse "RFC" with "[IETF] Internet
Standard".  Think about the proposed remedies for that
preventing Informational or Experimental documents from being
numbered and designated as RFCs.  Or, only a year ago, the
proposal to stop identifying documents from non-IETF Streams as
RFCs and giving them RFC numbers.  

Some important philosophical issues about what we are actually
about (see my long note about comparisons to other standards
bodies and how they handle documents aside, the problem with
having multiple type of documents and finer categories is that,
to an outsider or with an incentive to misconstrue, none of it
makes any difference.  That should have been clear to us the
first time marketing materials showed up that said that an
Internet-Draft was an "IETF document" and implied it was an
Internet Standard.    If the IETF produces it, or any IETF
subgroup produces it, or it is posted using IETF facilities, we
have decades of experience that suggest it will be misconstrued.

The marketers make an easy target but, for example, note that
everyone who has put an I-D on a resume without clearly
identified as a draft, a work in progress, or an expired draft
is violating our official rules too.  Different incentives, same
outcome.  And the same risk to them that the marketers have of
being found out and never believed again... but that doesn't
seem to be enough of a deterrent.

It is likely that the more categories of documents "we" have,
the easier it is for someone who has incentives to do so to
create confusion.  

And _that_ is what at least some of us are worried about.  

> I suspect that much of this comes down to poor terminology,
> and people (me!) not reevaluating what the term means both to
> themselves others - I've been following the thread, but it was
> only when I chatted with some people here in Montreal that I
> finally realized that the term "stable" means much more
> "stable" to people than I was intending it to convey - I
> suspect that much of the disconnect here stems from this
> terminology issue -- the term "checkpoint" was suggested, and
> this is probably much closer to what I was intending.

While "checkpoint" or "snapshot" would be far better than
"stable", the problem above remains.  We would figure out what
it meant and, at least most of the time, would get that right.
People who suffered from either deep ignorance, laziness about
reading definitions or boilerplate, or some incentive to
mislead, would do their thing no matter what we called it.
> 
> I wasn't intending marking a draft to allow "a WG to declare a
> piece of its work as ready to go without review and validation
> by the rest of the IETF." - as I'd initially said, these would
> still be drafts, and the "It is inappropriate to use
> Internet-Drafts as reference material or to cite them other
> than as "work in progress."" type disclaimer should definitely
> still apply -- a marked draft (at least in my mind, obviously
> I communicated this all poorly) would have much much *much*
> less standing than a draft which had passed WGLC - which is
> still not "ready to go without review and validation by the
> rest of the IETF." but rather "ready to go *for* review and
> validation by the rest of the IETF. A "marked" draft would
> mainly allow external people to see a *snapshot* of what the
> WG has currently agreed to in a document -- from the
> "Operators and the IETF" survey
> (https://tools.ietf.org/html/draft-opsawg-operators-ietf-00#se
> ction-2.2.2) lots of external people want to follow what the
> IETF is doing, but don't have the time or stomach to follow
> all the discussions

Yep.  Got that (and appreciate it).  Some of the others arguing
for this have been less clear.  But, if we have ever had reason
to worry about whether a survey that is published as an
Informational RFC is construed as a formal recommendation from
the IETF about what should be done rather than what some think
should be done, then lowering that bar doesn't help.

But, taking that document as an example with the understanding
that I just glanced at it for the first time, it appears to be
an ISOC study.  If posting a summary for the information of a WG
is helpful then do it - that doesn't require or benefit from
special labels.  If ISOC wants to publish a summary, they are
more than capable of doing that -- they don't need Internet
Drafts of any subspecies.  If you put it out for IETF LC
tomorrow, some jerk might stand up and point out that the
international statistical community (including the other ISI,
which predates the one more familiar to most IETF participants
by about a century) has clear recommendations for information
that should be included when anything is portrayed as a "survey'
or "survey results" and this document doesn't meet them.  That
is not an IETF technical topic, but it is a place where a little
cross-discipline review could reduce the risk of IETF WGs, at
least in the ops area, getting a reputation for unprofessional
and sloppy work.   As long as it is just an internal working
draft, you get to say "we'll get to that later, even if the need
to get to it hadn't occurred to you.  But, as soon as you hang a
flat on it that says "others, outside the IETF and its document
development process, might want to pay attention to this",
you've launched yourself down a slippery slope.

Eliding the rest of your note to save space, one other
observation:  There are existing, fairly well-defined, rules for
naming of I-Ds. The IESG apparently eliminated any notion of
enforcing those rules long before you joined it.  Your example,
draft-opsawg-operators-ietf-00 violates them and no one seems to
care.  If I were to post a draft on Monday called
draft-satan-future-of-IETF, someone might get me for bad taste,
identity theft, or blasphemy. but there is no mechanism to take
it down.  If someone tried, I'm confident someone who defend my
right to express myself and compare it to other postings with
names that don't follow the rules.

So, independent of the details of the proposal and whether it is
a good idea, if you ever want I-D names to contain important
indicative information, I suggest that you, as an AD, do two
things:

(1) To the extent possible, clean up your act and the act in
your Area.  A draft from the OPSAWG, even one that is not being
considered for some sort of special status, should be posted as
draft-ietf-opsawg-...   Any documents named draft-opsawg-...
(whether add insult to injury by including "IETF" in the name)
such be superceded and taken down unless they posted by Joe (or
Mary) Oppsawg and are _not_ WG documents.  Start setting an
example.  Even then, start watching for that important future
IETF participant Alice Stable.  Perhaps she will be a newcomer
in Montreal.

(2) Work with the IESG to start enforcing the naming rules.  Fix
it so that anything that is not
  draft-ietf-<activeWG>-...
  draft-<recognized-body>-... (where <recognized body> is a very
short list that presumably included IAB, IESG, IRTF, and
probably not much more)
  draft-<author>-...  (where <author) is the surname of one of
the listed authors)

can be taken down at the request of anyone in the community
(saving setting an I-D Police role comparable to SAA ones,
although that is another possibility).  If the IESG has to be
involved in case-by-case decisions, it will fail and we will be
back to uncontrolled names.  This is just a quick idea, but I'd
suggest a complaint to the secretariat, notice by them to the
authors, 24 hours for the authors to explain why the name is
really legitimate, and then the I-D goes away or, if tooling and
time permit, is renamed more appropriately.   Modifying the
posting tool so that drafts with non-conforming names are harder
to even post would be another improvement.  

Not only would that improve the understandability of I-D names
within the collection, but it would make any idea of conveying
more information through those names at least a bit more
plausible.

best,
   john