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

Vijay Gurbani <> Thu, 10 September 2020 17:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C81B3A0ADC for <>; Thu, 10 Sep 2020 10:49:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XEp9ZkA3VzJg for <>; Thu, 10 Sep 2020 10:49:52 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9166D3A0AE0 for <>; Thu, 10 Sep 2020 10:49:50 -0700 (PDT)
Received: by with SMTP id z23so9954266ejr.13 for <>; Thu, 10 Sep 2020 10:49:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Zjsry2zgn2E4H5FXmIybqxcmNc+OGo9WYbxOLGS38wY=; b=Ib0F/vDbfk6B6V1YJQYmCyVzcgmwmfNdW8f66XekLMdVmL4Yujjjj+FRvbjAvvTFp4 hL0km/ri79U0kbeog+oA8fRJ2fvEPhxzILzFNIK+sS+7GKCCmnDHZF5HW+ZXfSByC+jQ lg7xSSQa+8NYm6s3LBxFGPYIoISEtyllHUE2o8c5oij7tkw6APzW8OfKxu7C/E93dCnw YJlWaZYEGxhJ2V/dvJuUDGN3Wb8rhkuuV06vQjCFCH/XTE1AFLK/fi91Nlp94MlFCr4V 5I20E1PE8Vh8ihsGnozRfdLeDxsvMplPncNP/tDmJkY8qdcflmAwFTVkWYTE+I5HIBEo X2DA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Zjsry2zgn2E4H5FXmIybqxcmNc+OGo9WYbxOLGS38wY=; b=UVSAk+veH2y0Kwvi9Yuk5irrsWVsXCZhgzfd5PaaK20+W+WSP+EV16O9v4w+AiGPgW ga15yeBWAmUKEJkBxSNy017m2ll8WOeAVbp45xvJ0wi8PrrEI8XfmouBnxN6a86qJbTC XXcEwBQOu+G8cayRgraar1p2KlLIrjzTbhBozSur9aOs66iYgnI++3n+1XH9QExnTgF5 kTn6ls6A8bNHPNn+J/n1OQbpVmKB+ZaOUSoQ/IOWOSMn0Yc+TeLep1It69GiicPVagSd WLYD2Uiyyogtpa6eb/eLr39hfz7rjB9GRrpIeZp0M4T1Ihaq/+j/OWSewahdTvDdsybG xEkA==
X-Gm-Message-State: AOAM530EXNhgsvfl7fkbMw7epyd9NF+jYTwmnZjweUOCf4vQqwcCzx4T foouX72ETf6p/odfVo1wP/6y6yHF+Nh8a5h4epk=
X-Google-Smtp-Source: ABdhPJyaIbm5m9iyeoufA9OhKLuyROU8/t6PtI22BH54NnhtpRHZfrP1QqNZtSfBjOdkjx8nfZf5SGdtrS8qEwo1NE4=
X-Received: by 2002:a17:906:2962:: with SMTP id x2mr9845084ejd.188.1599760189032; Thu, 10 Sep 2020 10:49:49 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Vijay Gurbani <>
Date: Thu, 10 Sep 2020 12:49:28 -0500
Message-ID: <>
To: Mirja Kuehlewind <>
Cc: Spencer Dawkins at IETF <>,
Content-Type: multipart/alternative; boundary="000000000000cb101205aef93132"
Archived-At: <>
Subject: Re: [Edm] Some thoughts on Sep 1 meeting, Issue 1
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Sep 2020 17:49:54 -0000

On Thu, Sep 10, 2020 at 11:40 AM Mirja Kuehlewind <>

> 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

[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.


- vijay