Re: Running code, take 2

Riccardo Bernardini <> Fri, 14 December 2012 13:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 29D9C21F85A7 for <>; Fri, 14 Dec 2012 05:07:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VRIs80fgN+MT for <>; Fri, 14 Dec 2012 05:07:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 39B1B21F8623 for <>; Fri, 14 Dec 2012 05:07:04 -0800 (PST)
Received: by with SMTP id d3so2735460lah.31 for <>; Fri, 14 Dec 2012 05:07:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=fbjTb5PvPSTE7LQPU8Ig0Ez8sYsCQpL8IGfuXZni6N0=; b=rHRF/AB1LwWt0jPrlDZvwiScg9wOBs3ytTihFuJrWoKOnXSzZYTPj36rvIt9Wxsnu6 8zZfLn9C7sSYHXzuUaZLPlA6AJMktp20hl4FWbJMWlyx90euouM7gcbu9H1bRKQMb0Ii GiaHmsm9Z58feZPqw3CwaFUzHAOiAPaxaTqDExrLl5DAYFy9IbWPpyFqUTCKCDOZ6S14 e5D0xhyE182usNHh0JtCkd5k2NNnKYo36jzPohMVR+yVbjE+e2ELdp9EBSfXgDrG90nZ TjxuibBEZ2vx62wNUn/f68G9cTwhTeos8fLsVVvjmO/lywpkR2LOJAr4a8//H8sR3iEj QSZA==
MIME-Version: 1.0
Received: by with SMTP id f14mr2294969lbd.126.1355490423164; Fri, 14 Dec 2012 05:07:03 -0800 (PST)
Received: by with HTTP; Fri, 14 Dec 2012 05:07:02 -0800 (PST)
In-Reply-To: <>
References: <> <> <006601cdd93c$6f9f7a00$4ede6e00$> <> <> <> <> <> <> <>
Date: Fri, 14 Dec 2012 14:07:02 +0100
Message-ID: <>
Subject: Re: Running code, take 2
From: Riccardo Bernardini <>
To: IETF Discussion <>
Content-Type: text/plain; charset="ISO-8859-1"
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Dec 2012 13:07:05 -0000

On Fri, Dec 14, 2012 at 1:36 PM, Alessandro Vesely <> wrote:
> On Fri 14/Dec/2012 09:49:30 +0100 Yaron Sheffer wrote:
>> to clarify, my proposal only applies to Internet Drafts, and clearly
>> states that the implementation section should be removed from the
>> document before it is published as RFC.
> One place where an Implementation Status may help is IETF LCs:  People
> are asked to comment on I-Ds whose development they didn't track, on
> topics they may have only a working knowledge of.  Code licensing and
> IPR details could quickly convey whether a given standardization
> process is being gamed, for example.
>> Formally, we don't want non-permanent stuff in RFCs.
> We have the Errata and the Outcomes, AFAIK.  The Errata is freely
> writable, somewhat impractical, and doesn't address this purpose.
>> And realistically, even if we had an implementation wiki, it is
>> unlikely to be kept up to date once the RFC is published.
> The Outcomes /is/ a wiki,
> No wonder it's not updated:  It is difficult to find it from the
> relevant RFCs (let alone specific sections thereof), and it is not
> freely writable.  Anyway, it addresses only a small subset of the
> Implementation Status.
> While we need no formal procedure to write the Implementation Status
> section of an I-D, we probably need to specify how the content of that
> section can be used to set off the wiki page for the new RFC,
> and how that wiki should work.  Would that help running code?

This just came to my mind... Why not doing a little step more and
making the wiki page a kind of "directory" to available
implementations?  Maybe each entry could have a "license type" field
(e.g. open source, commercial, ...) and "compliant flag" assuming
values like "fully compliant," "partially compliant," "unknown,"
"what kind of weed did they smoke before coding this?!?" :-)  If the
protocol allows it, the compliant flag could be assigned on the basis
of running a suitable set of test vectors (possibly described in the
RFC), otherwise it could be assigned after a community discussion
(maybe inside the WG that produced the protocol, it still existing).

This kind of "implementation directory" could be useful not only to
the IETF, but also to people who needs to implement a protocol and
would prefer to use something ready.  A new entry in the directory
could be written by anyone (or proposed via e-mail).  The author that
writes the entry cannot set the compliant field which will be
"unknown" by default.  If there is some evidence that the
implementation is compliant (e.g., the software is used inside a
widely used browser and it did not cause any meltdown so far:-), the
status could be set to "probably compliant." The upgrade to "fully
compliant" would require running tests and/or community discussion.

Finally, I would also add to the implementation page a reference to
any available test vectors (if the protocol allow them).  I find thme
are quite useful during the implementation phase.