Re: [Rfcplusplus] Would notes be dropped [Was: Outlining the experiment]

Alissa Cooper <alissa@cooperw.in> Wed, 11 July 2018 01:57 UTC

Return-Path: <alissa@cooperw.in>
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 C12E1130DFB for <rfcplusplus@ietfa.amsl.com>; Tue, 10 Jul 2018 18:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=qK9lmwfJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZKP2OVHu
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 3tF1OgzEgqth for <rfcplusplus@ietfa.amsl.com>; Tue, 10 Jul 2018 18:57:09 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1677130DE8 for <rfcplusplus@ietf.org>; Tue, 10 Jul 2018 18:57:08 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1B21021AF5; Tue, 10 Jul 2018 21:57:08 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 10 Jul 2018 21:57:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=RtDJLmgRsey1iEW2wMjlASo0YY3Zd JQ1djEs3UHxo1g=; b=qK9lmwfJBaMagwkjJznOZ59+iGXq/Pk4F2XBPVvVJCk9Z qkfF7Wpm3Tiq+AMoboJeUgZ9f6lJPBmUGkF3KSmBUet8K7FTc6LffXqNLaxNN8Gv W84gSAxymGCJ5rheqANjJGO62nsOzvSUyital7EwtOaO4BaV6eU+A8ySlST4zQrV fk6fp7nA3mcTKHOJGnv9ukBHJX1TgTad0mweq0VzwbgX3fJUpGGQR1EyXge2WDNt jHSyCq0PkwNjpmsD9eje/+Mi6xIsX0zJj6aE6LKIM/JTgjszh6em2nBLbpLShrpC sZoBM6zHrpwoPTNTcneSsA2ptUSamU4OC9mEdjGWw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=RtDJLm gRsey1iEW2wMjlASo0YY3ZdJQ1djEs3UHxo1g=; b=ZKP2OVHuQSCEX6ZveOanUG CokI0c43nueY1mQgC0oKoHVbbs3O9WHEu5S5dl9RYBPhzh39s3G8O7hdvtqXukPY XRZzPsUYsNAoPiZoV4GGJa2uTLLB9BlKzapiMDNrvG83WdA71MWdbktN6JEjAvHf Nf/buVo8s+ova+DZYbYXb9eXJIQR7rsXc7ha2UKaDXwZOVKul+oWM3l8s+rmTAZA 8zplqJonAtVF+N0osXwFT0BqQK6mKNy/jkStdM8F8fXqBfS8mSsjDeunYwPcBjYP UnenVsaWyfPSA68Mf4oRBek0XNahVHYOAtSqO+B7de3FBYrE6ZCFoJBrxASuaQFw ==
X-ME-Proxy: <xmx:82NFW4V6BmsQxFM3FXhC3tHoUsij8OW34SNKVADAZbz4UK5cwJUjgw> <xmx:82NFWzFI3xFljYlBy_k8pvYIaGCnNO6rXMWf8Snck02jW5aPLHVRSA> <xmx:82NFW6bNA9tJWrV7Kq84ndhPhSyDzlU6nuRtP7R8CRChY2ugJtbPOA> <xmx:82NFW6H_E0JInTJsTV46xZjAQElILACNzRY_zKMydhfQvdXLAwiN1A> <xmx:82NFW41giNq305OE76vbPoNnLq0V1pfBuFXe4JmkzKZ0Z0O8dRHuBg> <xmx:9GNFWx1tHZaAJ_jQXe8_9Vyd8bBh6om3Ru3DWOA4N8xh_cTKEZqAcw>
X-ME-Sender: <xms:82NFW39UGe5y6lJoX8KJq7S3LFGSHxBQijdK7gV-vlXa6rql6TeyfQ>
Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.82]) by mail.messagingengine.com (Postfix) with ESMTPA id 8E96D10268; Tue, 10 Jul 2018 21:57:07 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <03e201d41785$5cb85320$1628f960$@olddog.co.uk>
Date: Tue, 10 Jul 2018 21:57:04 -0400
Cc: rfcplusplus@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <010FCCF0-A8B0-4909-8086-68A13F30C55E@cooperw.in>
References: <027c01d4136c$8c86b0a0$a59411e0$@olddog.co.uk> <C6B739D8-81E9-4432-BCFA-987AFA934340@cooperw.in> <03e201d41785$5cb85320$1628f960$@olddog.co.uk>
To: Adrian Farrel <adrian@olddog.co.uk>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfcplusplus/1DB3QH57264Cr0hv7SjctSIThw4>
Subject: Re: [Rfcplusplus] Would notes be dropped [Was: Outlining the experiment]
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: Wed, 11 Jul 2018 01:57:11 -0000

Hi Adrian,

> On Jul 9, 2018, at 9:04 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
> 
> [snip]
> 
>>> Now, it might be thought (this is possibly a branding thing) that the further from 
>>> looking like an IETF consensus document the less we have to care about the 
>>> "protocol conflict problem", but I would argue that the less input the IESG has,
>>> the more we have to worry. Thus, were an alternative venue for publishing
>>> competing specifications to be developed, I would claim that this is harmful
>>> to the RFC brand and to both the IETF's brand and raison d'être. 
>> 
>> I’m not following this. If someone cares about how the Internet works, then
>> having a poorly designed specification that risks the Internet’s stability published
>> in any venue is a problem. That doesn’t mean the IESG or any individual 
>> participant is necessarily going to be able to address that problem, but it’s still a
>> problem. Having that specification labeled with “RFC” means the IESG and the 
>> IETF face the potential additional problem of having the specification confused
>> for an IETF consensus output.
> 
> I'm trying to avoid looping the discussion or coming to any early conclusions on the right answer, but I will push again on this...
> 
> I believe I read you as saying that the IESG would not, as a matter of course, read or consider FOO9002 on its way to publication if that publication is out of the IETF Stream. They would not expect to be notified of the progress of that work towards publication.  In some cases, the IESG might become aware of the work and have comments that they wish to send to the publish body (such as, through a liaison statement). While the IESG might have some hope of being listened to, they would have no expectation of that, and would, in particular, not request the inclusion of an "IESG Note" in any such document.

Actually when I wrote the above I was thinking about it in the present tense. Documents get published in other venues today — other SDOs, web sites, journals, etc. Those specifications might risk the Internet’s stability. That is less than ideal, but the ability of the IESG and the IETF community to prevent it is limited. I think one difference between such a document and the exact same document being published with an RFC number is that the chance of the RFC being confused for an IETF consensus output is greater than the chance of the non-RFC being confused for an IETF consensus output. So I wasn’t commenting about a hypothetical change of series identifier, but rather the difference between documents in other venues (where “venue” means something outside the scope of the current RFC series) and RFCs in the current RFC series.

I do have an opinion on IESG notes and conflict reviews if the stream identifiers were to change but it’s not my opinion that matters here so I’ll keep it to myself. :)

Alissa

> 
> That was the clarity I was hoping for.
> 
> My point about branding was manifold:
> - The IETF would like to remain *the* source for documents that describe and define the Internet. Any action that weakens that (such as by giving another venue or publication) is unfortunate.
> - The IESG would like to remain authoritative evaluators and commentators on the merit and consensus of Internet standards
> - "RFC" as a label may cause confusion as to the source of the work, but buys the ability to influence the content by review and input.
> 
>> Alternative venues for publishing competing specifications already exist (e.g.,
>> https://url.spec.whatwg.org/) They may or may not be harmful to the Internet,
>> but I don’t see how they’re specifically harmful to the RFC brand. They’re certainly
>> not more harmful to the RFC brand than competing specifications labeled “RFC."
> 
> It needs to be noted that the non-IETF stream sources of RFCs constitute "venues" for publication. The proposal on the table opens the gap between those venues and the IETF. That might or might not be a good thing, but it is important to understand the implications.
> 
> Adrian
>