[Rfcplusplus] Conversation as metaphor

Ted Hardie <ted.ietf@gmail.com> Mon, 09 July 2018 15:24 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: rfcplusplus@ietfa.amsl.com
Delivered-To: rfcplusplus@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B156130DF4 for <rfcplusplus@ietfa.amsl.com>; Mon, 9 Jul 2018 08:24:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 V9KD90WyjAgi for <rfcplusplus@ietfa.amsl.com>; Mon, 9 Jul 2018 08:24:41 -0700 (PDT)
Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1059126DBF for <rfcplusplus@ietf.org>; Mon, 9 Jul 2018 08:24:41 -0700 (PDT)
Received: by mail-oi0-x229.google.com with SMTP id v8-v6so36621787oie.5 for <rfcplusplus@ietf.org>; Mon, 09 Jul 2018 08:24:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Q77FNNzKxvYSFh/LiZszYbswf3gaHFNdKYTWpF8XzAY=; b=So8vstduLivsCALPqFq72CRVObcDWksmjnhT1C7qEdds8IyD56QERhVDxwU2z0GjJi DuchTnWtXQt6VpTwKbVURkwWIJPSIfA5DuHxpupN1ukE8kooa59d614w8Z6Yvlpj4O/Z Q14iU3CuPicLErm3EG2KfXPjqLvQdHgcKITXuJqJ3AgSPiDAHNMqqvNZownhbZpPh7Zl d2RTUMC/eWp4GnNi2LVDzovKboHhDAoSX9pyqYdt7OnSHxi8Ge1oAwreXYGeRx2dGAWx wUxDVsUE3bl1tveEJucC2RLXI7uV8yzufjk6ck9+Cqui8L9RFZXjs3Hqn89s8xmtv5AE Ocyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Q77FNNzKxvYSFh/LiZszYbswf3gaHFNdKYTWpF8XzAY=; b=rQgIdbst68Cc3eCga0WtRiIK7fYuMx5W5CNFoHpVboKs9vBuqnP69IGa+ML27DWH8B uyzJXcKc3AedvbxM/6mhCsZZsSM05mqaUqImX+/t6g9EzKVTd+2aQZFHI/FD8VQCUVD2 4MaCXW0HL/jHqgiOHTKrY3UuwBC9vGoc8ylpP+kU52BkKDGZic3BhkVv7eGPmmaF89h9 OweRwvrmfRR1yI6gkjSoviqjEm+K40KGmJ0voNv8cXyeaxCrUfmXG3ilhYz9rB6llxRL AepMmkHZLlKKNq6rlfY070aHmadxc+qsuk8nbC17MG6pM/ALj+kzJJwzspLhsnw+y92Y XxGA==
X-Gm-Message-State: APt69E1qDCVTxEUuivHOBp5ZF3284eCXfQBwzgf66BCv06U7SIl/OijE f22vOfBYDwFkSvk3C4KwpPtwLAEAhwuLpWZ6V9oRJA==
X-Google-Smtp-Source: AAOMgpcpkOLB+nyGB+n07l5VIniO95lpvKJPoGBRZNw+zA9PHPS5htF4/WMPzCERXkLvVjM7leSvDYBG0ySP9JOFIKQ=
X-Received: by 2002:aca:3c45:: with SMTP id j66-v6mr21712043oia.118.1531149880562; Mon, 09 Jul 2018 08:24:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:66d9:0:0:0:0:0 with HTTP; Mon, 9 Jul 2018 08:24:10 -0700 (PDT)
From: Ted Hardie <ted.ietf@gmail.com>
Date: Mon, 09 Jul 2018 08:24:10 -0700
Message-ID: <CA+9kkMBVC82qy0hbUbQKm=OsFPsaJUPndtVaxd782au6Qy0w6Q@mail.gmail.com>
To: rfcplusplus@ietf.org
Content-Type: multipart/alternative; boundary="000000000000bac6c30570929c1f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfcplusplus/amqn97zXcs5xr4OLRBO-1-nThGE>
Subject: [Rfcplusplus] Conversation as metaphor
X-BeenThere: rfcplusplus@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: For discussion of the RFC++ BoF proposal and related ideas <rfcplusplus.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rfcplusplus>, <mailto:rfcplusplus-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfcplusplus/>
List-Post: <mailto:rfcplusplus@ietf.org>
List-Help: <mailto:rfcplusplus-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rfcplusplus>, <mailto:rfcplusplus-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Jul 2018 15:24:44 -0000

In a different thread, Eric made a statement about the RFC Series being in
conversation with other publications:

The RFC series (and also I-Ds) have an important role to play here, but it
> also exists in conversation with a lot of other publication venues, and I
> think that's healthy.
>

While I agree with him, I think the metaphor of "conversation" is even more
useful in describing both the current series and the question before us.
>From my personal perspective, the primary reason we use "RFC" as a series
identifier is to identify a specific set of technical documents as part of
a common "conversation".  The adoption of the term and series by the IETF
was a signal about the conversation their documents were to be part of;
choosing a different document  series (like ANSI, ISO, or minting a new
one) would have sent a signal about a different technical community with
whom the IETF was in dialog.

When the idea of different streams and stream managers gelled, we kept the
same series identifier for all of them.  I think, personally, we did that
because we wanted to be clear that all of the documents continued to be
part of a larger conversation about the development of Internet
technologies.

One way to understand the problem motivating this BoF is also through the
metaphor of conversation: many outside the community simply don't recognize
that there are multiple voices inside that conversation.  They see all of
the documents as utterances by a single, somewhat nebulous group.  That can
cause problems.  Among those named earlier were the academic community's
failure to value the output of the IRTF; vendors or customers not
distinguishing consensus output from proprietary alternatives; and even a
few efforts to get rejected ideas to appear to have been accepted ones.

The question before us could be cast as:  is it more important now to
highlight the different voices that the streams and statuses currently
convey, so that others understand them as disctinct?

As Eric points out, there are other ways to maintain a conversation among
different groups than to make their output part of a single series.  There
are also other ways we could try to make sure that we highlight that
distinction more fully (using STD numbers for all IETF standards documents,
for example, from proposed standard onward).  But I think this is the core
of the tension, shorn of discussion of brand or history:  how to we get to
the right balance of maintaining the conversation while improving the
understanding that these are individual voices within it?

My thoughts as individual,

regards,

Ted