[Rfcplusplus] Issues with RFCPlusPlus

"Leslie Daigle" <ldaigle@thinkingcat.com> Mon, 16 July 2018 21:03 UTC

Return-Path: <ldaigle@thinkingcat.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 7AB871311CA for <rfcplusplus@ietfa.amsl.com>; Mon, 16 Jul 2018 14:03:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thinkingcat.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 dHQ9zwrHBbcS for <rfcplusplus@ietfa.amsl.com>; Mon, 16 Jul 2018 14:03:37 -0700 (PDT)
Received: from pdx1-sub0-mail-a17.g.dreamhost.com (smtp15.dreamhost.com [64.90.62.184]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E42713120E for <rfcplusplus@ietf.org>; Mon, 16 Jul 2018 14:03:37 -0700 (PDT)
Received: from pdx1-sub0-mail-a17.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a17.g.dreamhost.com (Postfix) with ESMTP id D22427FC5E; Mon, 16 Jul 2018 14:03:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h=from:to :subject:date:message-id:mime-version:content-type :content-transfer-encoding; s=thinkingcat.com; bh=facfaTp2QXHqcP SldGOqq8EbSMU=; b=PUzcYzv5FAmMZt3/1muulNOD+KPXoXFeen7m/Qr+D7RXXJ a8r0XypLho5inGJ1MZw1Dl0vkm846WDJFdT10zezGYUyuERDQNQYZXeVfLIiplOJ Afax+fctX7ltxYD+Mtyn5znaYFbMXcbqXYk9CSvQe/dBNGjASYyt7Vc5vvyJo=
Received: from [31.133.144.130] (dhcp-9082.meeting.ietf.org [31.133.144.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: leslie@oceanpurl.net) by pdx1-sub0-mail-a17.g.dreamhost.com (Postfix) with ESMTPSA id 233437FBF0; Mon, 16 Jul 2018 14:03:35 -0700 (PDT)
From: Leslie Daigle <ldaigle@thinkingcat.com>
To: rfcplusplus@ietf.org
Date: Mon, 16 Jul 2018 17:03:26 -0400
X-Mailer: MailMate (1.11.3r5509)
Message-ID: <B3733C22-FDAF-4D57-8883-255FD2A7B190@thinkingcat.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_96009F74-AE23-4AF5-AEE1-4212E891FB26_="
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfcplusplus/wr10V5UkQIFXz4QmL2jvvgIz69w>
Subject: [Rfcplusplus] Issues with RFCPlusPlus
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, 16 Jul 2018 21:03:48 -0000

As someone who has her name on a number of RFCs, not the least of which 
is RFC4844 (“The RFC Series and RFC Editor”), I wanted to share a 
few observations.  Sadly, I am not expecting to be able to make it to 
the BoF itself, as oddly-scheduled as it is, I have competing 
commitments.

Here are the things that I think are important to consider in discussing 
this topic, as presented:


1/ The numbers given illustrate that there is no real problem. 92% of 
the RFCs published are from the IETF, so at a maximum, 8% of the RFCs 
published are gaming for brand (the notional problem to be solved).

2/ If there is a real “branding” problem, then the legacy situation 
must be addressed as well.  Solution:  change the names of everything.  
No more RFCs, just some other name for IETF-flavoured documents, and a 
different other name for non-IETF documents.  If you can’t discuss 
this proposal seriously, then the real problem you are trying to address 
is IETF-domination, not label-branding conflation.

And, the RFC Series is not the IETF’s:  it is independent.

3/ The IAB is the shepherd of the RFC Series — explicitly so that 
non-IETF streams have a champion that isn’t the IESG.   Martin 
Thomson’s document does not reflect that posture.  There’s an 
opportunity for the IAB to review its responsibilities here.

4/ On a scale of “There are a few clouds on the horizon, perhaps I 
should pack an umbrella”, to “the entire IETF organization is in 
danger of imploding because years of navel-gazing, cliquish control of 
access to resources and alienating operators and new industry 
players”, it seems to me that this issue (if it’s even a problem) 
fits rather more to the start of the spectrum.

It would honestly be helpful if the IAB would expend its creative 
efforts on addressing the scope and focus, and, ah, architecture 
questions facing our work:  we have actual issues that are closer to the 
rougher end of the spectrum.

5/ Why is the ISOC Board Chair co-chairing this BoF?  (Hint:  there 
might be a reasonable answer, but many answers are in fact not in the 
least bit reasonable).


Leslie.

-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
ldaigle@thinkingcat.com
-------------------------------------------------------------------