Re: An IETF repository for working code in our protocols?

Vijay Gurbani <> Wed, 19 August 2020 19:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EE7623A0D9A for <>; Wed, 19 Aug 2020 12:49:09 -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 sakb9a2-eRHj for <>; Wed, 19 Aug 2020 12:49:08 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CDACC3A0D9C for <>; Wed, 19 Aug 2020 12:49:07 -0700 (PDT)
Received: by with SMTP id ba10so19101338edb.3 for <>; Wed, 19 Aug 2020 12:49:07 -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=PEglHK/JLJNaciOqporU9yUGxwXHae3Oh21q14ON4UA=; b=qrsj3DCwczkbF79mfqazKuyo+VjnGZBjYMZBRotmMIT8218R5XMJ8L355Xy38+IdJX EFH+tlrd+sfetNpqiZyQ837eJxNKq7E3FxHt74oduTz5Sd3H7V/2acjqh9Kc0bSFr9kq TNX+dD6Ey3x1yCrjWjRsrzJyQVExpdC8oaq6p7s79+Dxdne+jbkgEOMfYrae09hNt6PG H0qQf4BqKmvdVS1ynnYfJ8wflfe24EQhPMiKR+Jmc4ktQOh6ygN9q7dW/ROAyH9fVxQm QNMDjZHJ438DJwSyFpfiW+DDrVc4va3sMQFTEOcCerH0PmQTuCTV9OkzQbB31atQ6XfY p8wg==
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=PEglHK/JLJNaciOqporU9yUGxwXHae3Oh21q14ON4UA=; b=VVPcR+O9JWImXnH3QFR6TdG/DW+DZzKVjfZwn7LwsVq7QgxK6pDOaFVWzSxPQdQFlj hGYszBu78NuCKdB1hvttL5xmap/KI4Vi9HQyrYXEwZYwAl3banhrPbqEraJrV5pOc4Id +Gk4cjOA67PsWYk3Dz7EnT6fa/O+joW5rYC9MltZ89c4IoQ6VPtVHq09UKSgqKbn0uBl FJBLUS+hAfTiZvd7eM+t2O7OFzO3eUb7yr1d+Mh3DSnb87XdFvnzRChXXQvGDnk6mdDE 1oNCOAjGPKmBCvjpGDdZTGe8upXEhMp/8qa7js9gBrFk+cgPMMXQyJadDPfM423BuLBC FBOw==
X-Gm-Message-State: AOAM533NfdQJpMok3q2znRBq7qLxXanfAgbzx5a6c9BkheC/KEwcOls+ C+vcD2x7RJ8fmgHnGEODiA+AzBJ6Pm6Ve6+Rpcc=
X-Google-Smtp-Source: ABdhPJzDm/HbeG59IYJ080S8SxHGcwzkgZKpin8rv0VerFhxM/J2rYY2zFMRXm9yHxApZGqtx7raS7qQehB2wl//20k=
X-Received: by 2002:aa7:d411:: with SMTP id z17mr26374014edq.85.1597866546127; Wed, 19 Aug 2020 12:49:06 -0700 (PDT)
MIME-Version: 1.0
References: <> <056801d6763c$f0296b90$d07c42b0$> <> <058a01d6764d$889b0b30$99d12190$>
In-Reply-To: <058a01d6764d$889b0b30$99d12190$>
From: Vijay Gurbani <>
Date: Wed, 19 Aug 2020 14:47:37 -0500
Message-ID: <>
Subject: Re: An IETF repository for working code in our protocols?
Cc: Alissa Cooper <>, Martin Duke <>,
Content-Type: multipart/alternative; boundary="000000000000e1668705ad404bb8"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Working Group Chairs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Aug 2020 19:49:10 -0000

Dear Adrian: Thank you for the follow up.  More inline.

On Wed, Aug 19, 2020 at 12:24 PM Adrian Farrel <> wrote:

> We felt that archiving this information in the RFC may be misleading and
> also unfair, and so we suggested removing the implementation status section
> of the document before publication.
> Those are valid concerns, indeed.  However, I note that the entire RFC
> process is an iterative process itself.  When we release an RFC as a PS, we
> release it with the knowledge that there may be some design choices that
> could be revisited at a later stage.  Ergo, if an implementation tracks the
> RFC closely, the underlying assumption would be that the implementation may
> well be updated at some later time as the RFC moves through its states from
> Proposed to Draft to Internet Standard.  To be sure, I am not saying that
> we should simply archive any half-baked or incomplete implementation,
> rather rely on the knowledge of the authors of the I-D and the chairs, and
> perhaps even the IETF interoperability process for the RFC, to only archive
> those implementations that are worthy of being archived.
> AF> You capture an important aspect, but I was concerned about the other
> side of it. It one company has implemented at the time the RFC is
> published, but others have not yet then the RFC stands forever (or at least
> until it is replaced or updated) without mentioning all of the other
> companies that implemented just a week to late to be documented. That is
> not very fair on the new companies and a little misleading for readers of
> the RFC.

I understand your concern, and it is a valid one.  However, note that the
archival process for the code can be, and indeed should be, limited to the
code that has tracked the I-D.  The intent is to provide some bootstrap
code to implementers from the get go.  If someone chooses to wait until a
RFC has been released before they produce code, that is certainly their
prerogative.  But I hardly think that they can make a case that their
post-RFC implementation is now a candidate for archival.  That would be
stretching the idea too far and in directions it is not intended.  (One way
to tamp down on the unintended consequences.)

> With author hat back off, I’m slightly wary about the IETF becoming a
> venue for advertisements, so I would encourage people to be quite careful
> about how this sort of information is collected and maintained.
> I suspect that you imply advertisements as indicated by the domain name in
> an email address of the source code's author.
> AF> Ah, no. I meant (possibly as suggested by Joel) commercial
> advertisements (as in “promotional material”). In many cases,
> implementation is described as “Company X’s implementation of this
> specification” and includes product names and release numbers. We do want
> that information but we don’t want this to be used as a way of saying that
> Company X makes splendid boxes and Company Y produces rubbish.

I agree, we do not need "promotional material" of the sort you outline
above.  And we can include such exhortations in the process we define.
That said, I don't think that the RFCs we produce are touted as "Company
X's implementation of this specification", despite the author's affiliation
on the RFC masthead.  Thus I think that this particular concern may be
mitigated by the normal social mores that have evolved in the IETF to
accord more credence to individuals rather than their particular

> AF> In our RFC, we were looking at how information about running code may
> influence the standardisation process. You are looking at something
> slightly different, and that is a good thing. Engaging with Tommy on this
> sounds like a sound idea.

Yes, thank you for that note.  I appreciate it, especially coming from a
constituent who started to even think of defining this process!


- vijay