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

Vijay Gurbani <vijay.gurbani@gmail.com> Sun, 06 September 2020 23:52 UTC

Return-Path: <vijay.gurbani@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 563703A0C82 for <edm@ietfa.amsl.com>; Sun, 6 Sep 2020 16:52:06 -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 PMPlDq5pr2zS for <edm@ietfa.amsl.com>; Sun, 6 Sep 2020 16:52:04 -0700 (PDT)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 2906D3A0C6C for <edm@iab.org>; Sun, 6 Sep 2020 16:52:04 -0700 (PDT)
Received: by mail-ed1-x533.google.com with SMTP id w1so11073190edr.3 for <edm@iab.org>; Sun, 06 Sep 2020 16:52:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=PtZLSVMT0an9cZM+8kUICGT6U1kBoxjBZ7xAw4ii82I=; b=kkryf+Ntx+csxFxAUhiL99UF54hz3Yef7i5UyK+qdcPNUJ/ffD9OCLdLUNVXaHffDN DDtdLtIkD8rhpr+Wp2Ms9ffVvGN3yL2bnf7s3Ae/oKK0QS0U2oo/utM8LYvZJLrWP7dF VJh9PErvWruUx1fIgie6Y1DDdVxA/PgLNp+lRbahbB0YjyFrY65h+5RmLnn/5R/FzT6o 44XOlMrt3AsJcqRNXniFlYySbl0ELJvvVLV7rZqCh3ygIpXS+7vCdpv9p8eCwwxI1SdZ ngjZuUzfG+bdE2Wmr09FlBhl3jx/feFIijDMy+/L2M0knjwtvrR3Bcy+p+9PNrbnnI/x P7ug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=PtZLSVMT0an9cZM+8kUICGT6U1kBoxjBZ7xAw4ii82I=; b=lnGMYaw+/6paa4Ko1L+oKk5epK3Gvz8d7ptHAMSmtpYdmaD3PN4d8MNn8cfAbsWf2W GEJ6sUMhEQ90Oeb+64PWGaOSGY4T3hj+S1oSociLFpD91S8+mbdPw7oBAVyvyls6DwqU zm5nhiDiW3mk6Tzmbux4oRft2roLpOpukG54k24sQTd+i07mf5aWBG1qrMldauoHO7Uy oisi7YjFC9WHFgkVXj8M3yKDgSTjmrzg9ICFkb/v6iWe9O8lki8QMGOn7xnCKhsZl82D tR5ZGIX63BVVwAdRRwmRnADjKLKqs1EPvU7uIaBa2pRZf9cuXdlneZQ3UPKUFDrUnJ/d AG3w==
X-Gm-Message-State: AOAM5336IWuuSH/JUJ4oEX7UvsWbOcezInk2p3MZdLIkBXEDd6byti1P XtzH3VblE2hqLPC3GHI5PTkQIh681mRz3yo9aXlhNaVI9TQ=
X-Google-Smtp-Source: ABdhPJzaf/nBWTIbcb3gfC+l50ncEUOml3dqy3fPZUJxvFg4uZhj3G1uSHcH2SFns6tYZfJIbcrecObXJ8w/BaQypT8=
X-Received: by 2002:aa7:de91:: with SMTP id j17mr19285638edv.85.1599436322026; Sun, 06 Sep 2020 16:52:02 -0700 (PDT)
MIME-Version: 1.0
From: Vijay Gurbani <vijay.gurbani@gmail.com>
Date: Sun, 6 Sep 2020 18:51:43 -0500
Message-ID: <CAMMTW_+Jynf2YeO3ZMmgrYnr-aeVCsWQoA6HLwW+Rm+T-33h0Q@mail.gmail.com>
To: edm@iab.org
Content-Type: multipart/alternative; boundary="000000000000d0b97405aeadc9b9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/edm/1AV0yGy5cetLjmP6aOu0xyD2kHE>
Subject: [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: Sun, 06 Sep 2020 23:52:06 -0000

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.

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