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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Wed, 09 September 2020 00:44 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
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 C900B3A0C57 for <edm@ietfa.amsl.com>; Tue, 8 Sep 2020 17:44:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jE36ZU8Ueo33 for <edm@ietfa.amsl.com>; Tue, 8 Sep 2020 17:44:39 -0700 (PDT)
Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59303A0C51 for <edm@iab.org>; Tue, 8 Sep 2020 17:44:39 -0700 (PDT)
Received: by mail-yb1-xb2a.google.com with SMTP id x10so631931ybj.13 for <edm@iab.org>; Tue, 08 Sep 2020 17:44:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h0MWkcacLE0SmuU9W6vqDxDxmc0aPH80myoQd8bVk9s=; b=YkQkyRS1+OJNpfxRSXqKLsVoTgqDcevCtsYh8OdIWAeDU0/4ZfO6sEyUtf5QPI4uDF zuEvvzp1JBtj2dszzDda+KUOXIvXQjAL0SLx+vRabpSr0SCG+dwdbUF0rFzJP24a9V/V dqrfibTeKdBn+q6bV8ku2ibnAZ0yY4Y50eIZ4LbYC5y2pj1mZ/tw0C34futzDV2TldX+ gx0xSlleZIpqMm8wwUetxUi+Vmty6ZnA51y6j14Ssr1OZEYFNMogTTYfJaPTfAqdMai0 BHx/RskXI43fhzovsnEOw/iTcrsr6cKIATo2zgQzwgsM4hvXdPhkzjBjcOXsIpgALUfA sgaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h0MWkcacLE0SmuU9W6vqDxDxmc0aPH80myoQd8bVk9s=; b=nu8DEkBk5awvIvQyEV9tcpIm3lkoeftQUe2Xf92s8kvNS3JA5jmVce1XaEbXH6vJO1 01dULXeVOF36ytgdVxc1ht3Uy+bi3NPMEkVgjFq1B1y95KQrtwZkvgKJuavbBW0EVsK/ c5w1J4cEJguRQkukwLG8sgFdfQG7474F8Ni8pJUhbE70Shynw1tuu/uI0j2lxlfOVOlJ qdGHAqANG0G2FSHTyfEXaTAxHHNlfsVRO95SZXSmepZ5k27C2LTl3D4NY/Fu/JtehfIX STIFbDssUJAqEWs7EsLIvjoYhRk9Wl+6HcY06lT8seiimKVwVwXrd4NTXt276tGe0t0s 9upg==
X-Gm-Message-State: AOAM533uZjOynKHC7EXeVG6NGqIS1joGc/Tk2ALpyApPIh6QDfhxM2iN Lz1rdMFE56s5girLDB7WuAfJGKBWetVxFWKGgTg=
X-Google-Smtp-Source: ABdhPJxDpfC+qIXoKiEpu412wuWHxsLKSIivdivZMaRgto//WLjj1ps0gxaP0fskDenrUSQPUqQQMRumv4BHvp+2hIk=
X-Received: by 2002:a25:2649:: with SMTP id m70mr2293672ybm.380.1599612278753; Tue, 08 Sep 2020 17:44:38 -0700 (PDT)
MIME-Version: 1.0
References: <CAMMTW_+Jynf2YeO3ZMmgrYnr-aeVCsWQoA6HLwW+Rm+T-33h0Q@mail.gmail.com>
In-Reply-To: <CAMMTW_+Jynf2YeO3ZMmgrYnr-aeVCsWQoA6HLwW+Rm+T-33h0Q@mail.gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Tue, 8 Sep 2020 19:44:12 -0500
Message-ID: <CAKKJt-fhyheu5Gvnh-dp2kDOcmJyPBYWWhs2e+6GgceJ0H82Vg@mail.gmail.com>
To: Vijay Gurbani <vijay.gurbani@gmail.com>
Cc: edm@iab.org
Content-Type: multipart/alternative; boundary="000000000000a74eb105aed6c12e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/edm/ku3cd5xTla7tbtohVYWWW7-XTIg>
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: Wed, 09 Sep 2020 00:44:42 -0000

Hi, Vijay,

On Sun, Sep 6, 2020 at 6:52 PM Vijay Gurbani <vijay.gurbani@gmail.com>
wrote:

> Dear Tommy, Mirja, all: Thank you for organizing the virtual meeting on
> Tue, Sep 1.
>
> As the instigator of the IETF WG Chairs list thread on archiving
> implementations [1], I have some thoughts, but unfortunately due to a
> conflict with meetings on my calendar, I had to leave early before the
> second half of the meeting on last Tue when this issue was discussed.
> Thank you for considering this thread of enough interest to put it on the
> EDM agenda.
>
> My main question in the IETF Working Group Chair thread was simple: How do
> the larger set of R&D folks who use the protocols we create find relevant
> code and other accoutrements that are of interest to them without wading
> into the IETF arcana?  (As a definition, "IETF arcana" is the collective
> knowledge we, on this list, have gathered from participating in the
> organization for a sustained period.  We know what a datatracker is, what
> the difference between an individual submission versus a WG submission is,
> we know where Wikis related to WG pages are, we know what WG deliverables
> are, etc.  This collected knowledge is not readily available to the many
> people who want to use our protocols, and it is not clear to me that this
> knowledge would be of use to them unless they want to participate in the
> IETF to the extent that we do.  They need to implement a standardized
> protocol, for the most part, that is their primary concern.)
>
> What is the most visible output of the IETF?  Perhaps unarguably, it is an
> RFC.  Even someone who has at best, a foggy idea of what the IETF is, knows
> what a RFC does.  When I talk to developers at companies and students at
> universities, if they have heard of IETF at all, it is mostly through
> knowing that some organization called IETF produces these things called
> RFCs.  That's it. Perhaps for them that is enough.  And if you buy that
> argument, then the corollary is that we should do everything that we can to
> make sure that the implementers have all of the information they need to
> implement the protocol from the RFC itself.
>
> The primary artifact of the protocol is the code that implements it.  Not
> all code is equal.  Some, like a SIP server, a QUIC implementation, a HTTP
> Server, a TLS implementation are complex and it is a foregone conclusion
> that we can simply park some code in an archive that implements such
> complex protocols.  However, we also produce routing protocols, hashing
> functions, best practices on how to handle dual IP stacks, ALTO entities
> that use HTTP and JSON to converse with each other, and so on.  Such code
> is small, perhaps modular, stand-alone and often can easily be made
> available in a repository much more readily than complex systems like QUIC,
> SIP, TLS, or HTTP.
>
> For the more complex protocols and their implementations, wikis and GitHub
> repositories that point the new implementer to the community of interest is
> sufficient.  For the less complex protocols that do not need a large
> community of interest, a simple code archival mechanism appears to be
> reasonable.  To the extent that the archive should be IETF owned, it makes
> sense to home the archive under ietf.org, as some of the IETF wikis are.
>
> So, the next question is how to let the implementer know of these
> resources when they read a RFC or an I-D?  RFC 7942 is an excellent start.
> It suggests having an Implementation Section in an I-D, but requests the
> removal of such a section from an RFC-to-be.  This implementation section
> can be used to document the datatrackers, wikis, and GitHub repositories
> for the more complex code and a link to the archival area for the less
> complex code.  (I realize that IETF does not have authority over links like
> GitHub that are not under the ietf.org administrative domain, but perhaps
> for large projects, it is adequate that they stay in repositories like
> GitHub.) Perhaps RFC 7942 can be updated so that the Implementation Section
> is not removed when the I-D becomes an RFC, and perhaps verbiage can be
> added to it during the update that essentially says "caveat emptor", but in
> more words and with appropriate constraints.  But the basic concern of
> making an RFC self contained such that it has links to implementations is
> adequately accomplished by an updated RFC 7492.
>

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
https://www.rfc-editor.org/rfc/inline-errata/rfc3261.html. *

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.

Best,

Spencer

* I believe Adam Roach did the heavy lifting on proving this was feasible
when he was on the IESG. I'm not sure where the actual code used today came
from, but I do want to give credit when I can.


> Thank you for reading so far, and thank you again for considering this of
> enough interest to put it on the EDM agenda.  I look forward to your
> thoughts on this.
>
> [1] A quick recap and restatement of the need for a stable archival area
> controlled by the IETF is in
> https://mailarchive.ietf.org/arch/msg/wgchairs/He68KsKijRg2FAIpxRFi5MyJGis/
>  That link contains other links to the original thread for those of you who
> want to catch up with the discussion.
>
> Cheers,
>
> - vijay
> --
> Edm mailing list
> Edm@iab.org
> https://www.iab.org/mailman/listinfo/edm
>