Re: Running code, take 2

Yaron Sheffer <> Fri, 14 December 2012 08:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 54B6821F86C4 for <>; Fri, 14 Dec 2012 00:49:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.432
X-Spam-Status: No, score=-103.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Kml8VXZ6wh35 for <>; Fri, 14 Dec 2012 00:49:37 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3A98D21F86C3 for <>; Fri, 14 Dec 2012 00:49:37 -0800 (PST)
Received: by with SMTP id w11so1497595bku.31 for <>; Fri, 14 Dec 2012 00:49:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ofiv1hr/fksmZwFHoEtgwJOhx/TIPRMRPuDAOTv/Eb8=; b=PZdLvDEI1DAHIvS7Wu3NjV8er26AcPZCojY9pFKozLXy0HR6xXvB0CL+79MYWMguUN 3LARFIK7YT8lmv7Pcbi0Gfk2ea4sXRvSfFK5ios1xEZMs5VOqsLrm3dth+B/6DSqtSjh fmKs64wDiv3qEpYpl8IM/OlPZ1gMQAcbGviInsnbfs+bepcz9Df8N25LOlftBKKUyB+c BwoXl4QLIKVHsC0tROP7ALQNpfvz35XN80PCLlg4j1D63TYL6f/Q8DIP0fS9PAAxlnYF T6dbbUo4/m1O/u0HwiiCWHe1ktSyY8fgzQk2zT3HOdnVUK8czItZDXu7SSIj5W5C7hBP 5Lgg==
Received: by with SMTP id g21mr2323885bkw.97.1355474976293; Fri, 14 Dec 2012 00:49:36 -0800 (PST)
Received: from [] ( []) by with ESMTPS id o9sm3503643bko.15.2012. (version=SSLv3 cipher=OTHER); Fri, 14 Dec 2012 00:49:35 -0800 (PST)
Message-ID: <>
Date: Fri, 14 Dec 2012 10:49:30 +0200
From: Yaron Sheffer <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: John C Klensin <>
Subject: Re: Running code, take 2
References: <> <> <006601cdd93c$6f9f7a00$4ede6e00$> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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 08:49:38 -0000

Hi John,

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.

Formally, we don't want non-permanent stuff in RFCs. And realistically, 
even if we had an implementation wiki, it is unlikely to be kept up to 
date once the RFC is published.

Regarding the "experiment" question: I fully agree that there's nothing 
preventing us from adopting this proposal (or a variant of it, or 
Stephen's proposal) today.

The value in a 3933 experiment is in the Summary Report, otherwise I 
agree it's a waste of time. At the end of the period we will have a 
little bit of data to understand whether we have traction for this idea, 
and whether we should make it IETF-wide, allow it to quietly die or 
explicitly advise against it.


On 12/14/2012 12:47 AM, John C Klensin wrote:
> --On Thursday, December 13, 2012 23:51 +0200 Yaron Sheffer
> <> wrote:
>> Hi Randy,
>> the RPKI report is very impressive and probably very useful.
>> But:
>> - Other areas (e.g. the Security Area, where I'm coming form)
>> may not have this tradition.
> If it is important, nothing prevents establishing it.
>> - For "smaller" protocols the gain does not justify the effort
>> of writing a separate implementation report. A section in the
>> base document is much simpler to maintain.
> I'm not at all clear why it is more effort to write a separate
> report.  But, assuming it is, I am aware of nothing in any IETF
> or RFC Editor procedure that prohibits including a discussion of
> implementation experience in a standards track RFC.
>> - And as I noted earlier on this thread, a wiki is a good
>> alternative, provided everyone reading the base draft is
>> referred to the "implementation status" wiki. They should not
>> have to guess that one exists, or to search for it.
> That is a more complicated problem because the RFC Editor is
> somewhat reluctant (for good reasons, IMO) to accept references
> to web pages whose permanency is not assured.  There are,
> however, lots of other ways by which one could imagine creating
> and maintaining such pointers.  For example, if you could
> convince the community that this was important, and likely to be
> done often enough, you might lobby the IESG to negotiate an
> additional sentence in the "Status" section of standards track
> RFCs that provided a stable pointer to an index of
> implementation reports.
> My concern remains that we not create new formal procedures to
> do (or even experiment with) things that can be done under
> existing rules either for the whole IETF or on an area by area
> or even document by document basis,  Let me suggest, as
> co-author of the "process experiment" doc, that it was intended
> to deal to allow experiments that would otherwise be in
> violation of existing procedures.  As far as I can see, that
> situation doesn't apply with either of these proposals.  And,
> given the number of experiments carried out with reference to
> RFC 3933 that did not result in useful and formal reports back
> to the community, I'm unconvinced that formally identifying any
> particular exercise in identifying implementations or handling
> some specifications with implementations differently in the IESG
> review process than other specifications will increase the odds
> of  the results being examined carefully and critically enough
> to generate a report and, through it, permanently change
> behavior.  YMMD but, if either of these ideas are interesting,
> persuade a friendly AD to try it on whatever scale makes sense,
> and then let the rest of us know how it worked out for you.
> Since no existing rules would thereby be violated, IETF
> consensus is not required for such an exercise... or any number
> of such exercises.
> best,
>     john