Re: [Tools-discuss] Last Call: <draft-sheffer-running-code-04.txt> (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC

Fred Baker <> Thu, 25 April 2013 22:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D20F21F9709; Thu, 25 Apr 2013 15:09:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -108
X-Spam-Status: No, score=-108 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yq1jBDFD3SyO; Thu, 25 Apr 2013 15:09:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F121921F9708; Thu, 25 Apr 2013 15:09:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2992; q=dns/txt; s=iport; t=1366927761; x=1368137361; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=EGLVCTNVS5Miv52c4j6BGILJgG/ElGFNTPCNfuunfyE=; b=LNWMJ4UYefrVLpiwNZLA+f9y//FTrULXkBEQK4AHZxUCj2RFoTozCKfZ vcIE219EaDjHfs0cQPMFUORStxSzE+1LjXpEspBKdWxwbVUyXJM4YrC0u qScHWo2uZoaKOvZAx7jNGXRj0aXS2EeXWRI+UquGEHA0F9CvIizOr7SYY A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAAGpeVGrRDoG/2dsb2JhbABHCoMGvmeBBBZ0gh8BAQEDATo/BQsLOwtXBhMUBYd1Bb5PigKDdxR1MwcWgldhA4kRjguRIoFYgVYc
X-IronPort-AV: E=Sophos;i="4.87,553,1363132800"; d="scan'208";a="76537596"
Received: from ([]) by with ESMTP; 25 Apr 2013 22:09:20 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r3PM9JkA027860 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Apr 2013 22:09:20 GMT
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Fred Baker <>
In-Reply-To: <>
Date: Thu, 25 Apr 2013 15:09:18 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
X-Mailer: Apple Mail (2.1503)
Cc: " Discussion" <>
Subject: Re: [Tools-discuss] Last Call: <draft-sheffer-running-code-04.txt> (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Tools Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Apr 2013 22:09:22 -0000

On Apr 12, 2013, at 2:57 PM, The IESG <> wrote:

> Abstract
>   This document describes a simple process that allows authors of
>   Internet-Drafts to record the status of known implementations by
>   including an Implementation Status section.  This will allow
>   reviewers and working groups to assign due consideration to documents
>   that have the benefit of running code, by considering the running
>   code as evidence of valuable experimentation and feedback that has
>   made the implemented protocols more mature.
>   The process in this document is offered as an experiment.  Authors of
>   Internet-Drafts are encouraged to consider using the process for
>   their documents, and working groups are invited to think about
>   applying the process to all of their protocol specifications.  The
>   authors of this document intend to collate experiences with this
>   experiment and to report them to the community.

I have read the draft. I like the concept. It applies primarily to protocols and procedures, as opposed to white papers. It, however, puts emphasis on the experience behind the usefulness of a protocol or procedure, which is good.

BTW, once upon a time we required implementation reports for routing protocols, which I thought was a good thing and am concerned about the loss of in recent times. That resulted in the publication of sets like RFCs 1245, 1246, and 1247, which told about the protocol, its operational characteristics, and the testing it went through (and by implication, the implementations done of it) on its way to RFC-dom.

In 2013, I personally would accomplish this a little differently, however. A section in an internet draft, which gets frozen when the draft is published, is perhaps useful for the working group and IESG review processes. On the other hand, it requires implementers to communicate with the draft author and the draft author to update the draft in response to their input, which can be a logistical mess. It ceases being useful once the draft is published. If a new implementation is done, there is no report. If and old one is abandoned, nobody knows. It is dated information, potentially true at a point in time but largely irrelevant two minutes later.

I would think we want something associated with the data tracker page - another web page, perhaps implemented as a wiki - that enables an implementer to identify himself and indicate the current status of the implementation. Ideally, that might be coupled with a ticket system in which issues are raised and closed, and comments are discussed. Ideally, this would continue into the life of an RFC, with implementations being identified ("The protocol in RFC 12345 is implemented in Andy Systems releases 22.70 and later") and associated with errata ("but we really wish that the parameter FOO had been specified").