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

Mirja Kuehlewind <> Thu, 10 September 2020 16:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19CD13A0138 for <>; Thu, 10 Sep 2020 09:40:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ny7soqG4VK8L for <>; Thu, 10 Sep 2020 09:40:42 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id BA1263A03ED for <>; Thu, 10 Sep 2020 09:40:34 -0700 (PDT)
Received: from ([2003:de:e745:9100:edaf:e830:8d14:9da]); authenticated by running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1kGPce-0007f9-8v; Thu, 10 Sep 2020 18:40:32 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Mirja Kuehlewind <>
In-Reply-To: <>
Date: Thu, 10 Sep 2020 18:40:31 +0200
Cc: Spencer Dawkins at IETF <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Vijay Gurbani <>
X-Mailer: Apple Mail (2.3608.
X-HE-SMSGID: 1kGPce-0007f9-8v
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 16:40:44 -0000

Hi Vijay,

Thanks for moving this discussion forward.

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.

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.


> On 9. Sep 2020, at 17:06, Vijay Gurbani <> wrote:
> On Tue, Sep 8, 2020 at 7:44 PM Spencer Dawkins at IETF <> wrote:
> Hi, Vijay,
> [...]
> ISTM that it's worth considering what's possible without revising RFC 7942. 
> Everyone may already know this, but the RFC Editor now has a way of inlining errata - for example, check *
> If we can figure out how to track "what's worth pointing to", perhaps the RFC editor could also inline pointers, rather than dorking with the RFC text itself. 
> Dear Spencer: Nice to hear from you, and thank you for your comment.
> I am all for considering what's possible without revising RFC 7942, no problem, as long as we can redirect the interested parties to the appropriate code archives.
> The work you cited that Adam has done on RFC 3261 for errata looks very neat.  This could be a potential way to proceed if IAB/IETF decided not to go the route of updating RFC 7942 or inserting some other text in the RFC-to-be.  Some issues to consider if we go the inlining route would be (a) how to aesthetically present the information on the RFC masthead, (b) what is the expectation when someone prints the RFC with such inling?  Will the inline text show up?  (In the case of RFC 3261 with inlined errata, I note that all expanded errata are printed, non expanded errata appear as green text in the generated PDF.  By "expanded" I mean that if I click on one of the errata, it expands into a rectangle at the appropriate place in the RFC, and that entire rectangle is then printed in the generated PDF.)
> Thanks,
> - vijay
> -- 
> Edm mailing list