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

Vijay Gurbani <> Thu, 20 August 2020 20:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 842303A13F7 for <>; Thu, 20 Aug 2020 13:30:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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] 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 hQkoDMeH0e1R for <>; Thu, 20 Aug 2020 13:30:11 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E35713A13F5 for <>; Thu, 20 Aug 2020 13:30:10 -0700 (PDT)
Received: by with SMTP id w2so2403845edv.7 for <>; Thu, 20 Aug 2020 13:30:10 -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=x7PBTcUo+sCuyLrLfEUWMhOmReuEmaHgrxA8qG3pDNE=; b=of7pGXtegyUbN6rthDr8dw2meJ8adyZTFeL2B01QMa/tMgUcWM4+++anAAbFQR/IGA c/2uXCO/2mwYzWTlUfT6e978tmY08ZaHKUqGZoeaFXd0UBwlWqMQK4GEYP19Mm3DIHDH eN45HJ0g4/1WplMOm76CFBSZ9YGMCwbRfb+VE7lXnFzR08t7ON8/p42tg5tjZJ21CzI8 5ylEeKjr9tUWonTtQAVqqYrJ9eKTziZ3hO/PqIYP1gZCSlZ3gqClD58W7j65+pkV+xmN /wlFnOi7sTdSO/XEvtJjkuCexqqUJhVKxEg3Z4YC2FXX7YAQRdzzT1SqQRqTC7hqHjGf xH+g==
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=x7PBTcUo+sCuyLrLfEUWMhOmReuEmaHgrxA8qG3pDNE=; b=nfvnp7u87GrT3kTqD/aX9ic1LDJ0nU5g8ZXWi9BxcCtFGIMI6tCZ95Ad9NbCgA+xCs f/WO/byTkv4QKmn1FvsxCKokF8EjW74J+xuJW7otmzD6ZCoYrV/mUeNTcQ+zO3pvNpdn a9g/aLFODqL/tigtzePCcdHZLooQRcdobT86Umq9isiffw83FBZKcMyiUZLbWUev8xdL Y6WHNYn1MJGH+vv+lEAQe28syS1C6k+BTctIfkDWBlX7jv2717H1v1IsmJcbvvXJTluM yktoRmggrPB004HmkyPX07o4TuUXYqh53LMtBILl7Wetkeb27hJdTEN8NOs+HdTPCbvN n18w==
X-Gm-Message-State: AOAM531zXdpNQeOpxqtlxCDhDsAqNm4a/sPlr5clh5ONMAoSIW41Xd6N VIdi2mhvtIEKmKCexzIAEkfC283QEqTafSJzq0g=
X-Google-Smtp-Source: ABdhPJwavDj7y7rHYLKRiAjUhFiJk5b3QYBSK4MwxFsllT+z68mprGnRL6iOI+p/13svfMmrIZgagZ41GfTTATfZlgQ=
X-Received: by 2002:aa7:d411:: with SMTP id z17mr316624edq.85.1597955409363; Thu, 20 Aug 2020 13:30:09 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Vijay Gurbani <>
Date: Thu, 20 Aug 2020 15:28:39 -0500
Message-ID: <>
Subject: Re: An IETF repository for working code in our protocols?
To: Melinda Shore <>
Cc: IETF WG Chairs <>
Content-Type: multipart/alternative; boundary="0000000000008ac59205ad54fc8b"
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: Thu, 20 Aug 2020 20:30:12 -0000

On Thu, Aug 20, 2020 at 1:51 PM Melinda Shore <>

> Hi, Vijay:
> I've been following this thread and to be honest I'm not 100%
> clear on the problem you're trying to solve, which makes it a
> little challenging to figure out whether or not this is the
> best solution to that problem.  I do share many of the same
> concerns that have been raised, particularly about what would
> be implied by having code included in a repository controlled
> by the IETF, but I think more clarity around perceived benefits
> would be helpful.

Dear Melinda: My apologies on not being clear in my initial email.

So the problem is simple: When we have high quality implementations for
certain protocols that we standardize, can we come up with a place to park
these implementations so they can be used by implementers to get a head

Why is this important?  We want to incentivize the larger RFC
implementation community (i.e., NOT us IETFers, but the legions of
developers working in corporations, academia, and individually) so they can
find these sample implementations easily and use them to bootstrap their
individual implementations.  This means putting a permanent link to the
known implementations in the RFC itself, instead of assuming that the
average developer will want to.  Developers that do not participate in the
IETF to the extent we do have a limited visibility to the organization and
its workings.  To them, the RFC is the main artifact.  Just like the RFC
lists errata, perhaps it could list links to starter code for those who
want to bootstrap themselves.  Reaching out to developers outside of those
of us who are already in the IETF is my biggest incentive.  They are the
ultimate consumers of what we produce.

As always, the devil is in the details, as we have been discussing in the
email thread.  There have been many pertinent and important observations
discussed on the mailing list; I will summarize some that I remember on the
top of my head.

1/ What about licensing issues?
2/ What about maintainability?
3/ Can we stop someone from claiming that "This is *THE* reference
implementation of RFC XXYY"?  And indeed, if someone claims this, what does
that mean?
4/ Can someone suggest that an implementation be added after the RFC has
been published?
5/ Can an implementation be used purely for advertising?
6/ Are the implementations maintained in perpetuity?  Or as long as the RFC
is active (i.e., not obsoleted)?
7/ Does IETF maintaining such a repository convey any authority?
8/ Can we be informed by other organizations (IEEE and ACM)  who have
tackled some of the same problems?

Hope this helps to some small degree.  Thanks!

- vijay