Re: [Edm] Some thoughts on Sep 1 meeting, Issue 1

Mirja Kuehlewind <ietf@kuehlewind.net> Thu, 10 September 2020 18:33 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: edm@ietfa.amsl.com
Delivered-To: edm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56D83A0BE6 for <edm@ietfa.amsl.com>; Thu, 10 Sep 2020 11:33:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 p8-wqWXWrvFd for <edm@ietfa.amsl.com>; Thu, 10 Sep 2020 11:33:10 -0700 (PDT)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A85B53A0C17 for <edm@iab.org>; Thu, 10 Sep 2020 11:33:10 -0700 (PDT)
Received: from p200300dee7459100edafe8308d1409da.dip0.t-ipconnect.de ([2003:de:e745:9100:edaf:e830:8d14:9da]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1kGRNc-0003T5-2c; Thu, 10 Sep 2020 20:33:08 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: <CAMMTW_KN5obhgkqxaqsPEs+OcTZVSYh6bDFHm0VDo4R3kuKCYQ@mail.gmail.com>
Date: Thu, 10 Sep 2020 20:33:07 +0200
Cc: edm@iab.org, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <68D31D1A-334A-4577-AB93-37D4DD5B369B@kuehlewind.net>
References: <CAMMTW_+Jynf2YeO3ZMmgrYnr-aeVCsWQoA6HLwW+Rm+T-33h0Q@mail.gmail.com> <CAKKJt-fhyheu5Gvnh-dp2kDOcmJyPBYWWhs2e+6GgceJ0H82Vg@mail.gmail.com> <CAMMTW_JCADUmG+Zq6503nfvgqr-8LhKyx7SkCYjCogOezzmxZw@mail.gmail.com> <36021C1E-670B-4357-9155-9B23B368B665@kuehlewind.net> <CAMMTW_KN5obhgkqxaqsPEs+OcTZVSYh6bDFHm0VDo4R3kuKCYQ@mail.gmail.com>
To: Vijay Gurbani <vijay.gurbani@gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1599762790;d953f7dd;
X-HE-SMSGID: 1kGRNc-0003T5-2c
Archived-At: <https://mailarchive.ietf.org/arch/msg/edm/UnW6SIWczICuITeT3Z8_dbxFxVY>
Subject: Re: [Edm] Some thoughts on Sep 1 meeting, Issue 1
X-BeenThere: edm@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" <edm.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/edm>, <mailto:edm-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/edm/>
List-Post: <mailto:edm@iab.org>
List-Help: <mailto:edm-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/edm>, <mailto:edm-request@iab.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Sep 2020 18:33:13 -0000

Just very quickly some points. Having read all RFCs that we have published in the four years of my AD time I can tell you that RFC7942 is used form time to time. However, it also addresses a different problem then what you ask for, namely how do people in the wg know about existing implementations. QUIC decides to use another tool for this purpose; I guess for several reason, one being that many implementors in QUIC who have been new to the IETF are actually more familiar with GitHub than any IETF procedures. My expectation is that note you mentioned for QUIC will be removed before publication as RFC.


> On 10. Sep 2020, at 19:49, Vijay Gurbani <vijay.gurbani@gmail.com> wrote:
> 
> On Thu, Sep 10, 2020 at 11:40 AM Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
> Hi Vijay,
> 
> Thanks for moving this discussion forward.
> 
> Dear Mirja: Thank you for your time and your comments.  More inline. 
>  
> To focus on the formal bits for a second: RFC7942 doesn’t actually require that the section is removed. This says "Authors are requested to” but I guess it’s for the authors/wg to decide. Also this is an IETF-consensus document which I think was AD-sponsored. So the way to update it is “simply” to write a bis-draft and bring it to gendisptach these days.
> 
> I agree that RFC 7942 only "requests" not "mandates" that the section be removed.  However, the practical effect of this request is that most authors will simply ask for the section to be removed.  That was the case in a particular draft that I was reviewing for Gen-Art (which actually resulted in the thread I opened up on the WG Chairs list).  Furthermore, to be frank, before I reviwed the draft in question for Gen-ART, I was not even aware of RFC 7942.  Certainly, it is fairly new (having been minted in 2016), but none of the I-Ds or RFCs I have read post-2016 even mention an Implementation Status section.  
> 
> It certainly does not portend well that we are not eating our own dog food.  I looked at two active WGs --- quic and httpbis --- to see if an RFC 7942 section is present in any of the active I-Ds.  Of the 24 I-Ds in these groups, I could not find such a section [1].  Apologies, I am not picking on these groups, just trying to get some objective data points by looking at a couple of active WGs.  The irony is that the base protocol document for QUIC [2] has a "Note to Readers" section that provides the very information --- where to find the GitHub repository --- that we are seeking to institutionalise.  I am not sure what will happen to this note when QUIC becomes an RFC.
>  
> More to the actually point: I understand your motivation about people only knowing RFCs but none of the IETF process but I’m not sure putting this information in an RFC is the right tool. I bed it’s actually not very hard to find some suitable code on GitHub these days, especially as you said if this is about larger projects (which in the best case are actively maintained). For smaller code snippets we often put pseudo code in the document of appendix. So that’s another option.
> 
> I understand and respect your view that putting this information in an RFC is not the right thing to do.  I am trying to convince you that it is, and I hope that I succeed in some measure.  
> 
> The proposal we are considering --- i.e., putting some text in RFCs to guide legions of implementers not familiar with "IETF arcana" --- is already being used loosely as I pointed out above for QUIC.  It seems to me that we can do better by institutionalising it in some manner that RFC 7942 did not. Perhaps as you suggest, the answer is to simply write a RFC 7942-bis draft.  If you think this is an avenue we should explore, I am happy to spin up a rfc7942-bis  so to provide more structure to the conversation.
> 
> [1] I will like to point out that of the 24 I-Ds, not all deal with specific protocol/algorithmic issues, so please account for that reality. 
> [2] https://www.ietf.org/id/draft-ietf-quic-transport-30.txt
> 
> Thanks,
> 
> - vijay
> -- 
> Edm mailing list
> Edm@iab.org
> https://www.iab.org/mailman/listinfo/edm