Re: Running code, take 2

t.p. <daedulus@btconnect.com> Fri, 14 December 2012 11:17 UTC

Return-Path: <daedulus@btconnect.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC9821F875C for <ietf@ietfa.amsl.com>; Fri, 14 Dec 2012 03:17:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.849
X-Spam-Level:
X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zOzD5Ws-J+6 for <ietf@ietfa.amsl.com>; Fri, 14 Dec 2012 03:17:56 -0800 (PST)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id E752E21F874E for <ietf@ietf.org>; Fri, 14 Dec 2012 03:17:55 -0800 (PST)
Received: from mail155-co9-R.bigfish.com (10.236.132.232) by CO9EHSOBE028.bigfish.com (10.236.130.91) with Microsoft SMTP Server id 14.1.225.23; Fri, 14 Dec 2012 11:17:54 +0000
Received: from mail155-co9 (localhost [127.0.0.1]) by mail155-co9-R.bigfish.com (Postfix) with ESMTP id C8AE4800CB; Fri, 14 Dec 2012 11:17:54 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.253.197; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0710HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -22
X-BigFish: PS-22(zzbb2dI98dI9371I542Id87dh1432I4015Izz1de0h1202h1e76h1d1ah1d2ahzz17326ah8275bh8275dh1033ILz2dh2a8h5a9h668h839h946hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h304l1155h)
Received: from mail155-co9 (localhost.localdomain [127.0.0.1]) by mail155-co9 (MessageSwitch) id 1355483873286322_25833; Fri, 14 Dec 2012 11:17:53 +0000 (UTC)
Received: from CO9EHSMHS009.bigfish.com (unknown [10.236.132.243]) by mail155-co9.bigfish.com (Postfix) with ESMTP id 35B01200058; Fri, 14 Dec 2012 11:17:53 +0000 (UTC)
Received: from DBXPRD0710HT003.eurprd07.prod.outlook.com (157.56.253.197) by CO9EHSMHS009.bigfish.com (10.236.130.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 14 Dec 2012 11:17:53 +0000
Received: from DBXPRD0510HT005.eurprd05.prod.outlook.com (157.56.252.165) by pod51017.outlook.com (10.255.79.166) with Microsoft SMTP Server (TLS) id 14.16.245.2; Fri, 14 Dec 2012 11:17:47 +0000
Message-ID: <022b01cdd9ec$69abfa00$4001a8c0@gateway.2wire.net>
From: "t.p." <daedulus@btconnect.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>, adrian@olddog.co.uk
References: <50C8DB78.3080905@gmail.com> <50C9DED7.8060604@tana.it><006601cdd93c$6f9f7a00$4ede6e00$@olddog.co.uk> <50C9EBB3.5040901@gmail.com>
Subject: Re: Running code, take 2
Date: Fri, 14 Dec 2012 11:15:59 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.252.165]
X-OriginatorOrg: btconnect.com
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Dec 2012 11:17:57 -0000

----- Original Message -----
From: "Yaron Sheffer" <yaronf.ietf@gmail.com>
To: <adrian@olddog.co.uk>
Cc: <ietf@ietf.org>; "'Alessandro Vesely'" <vesely@tana.it>
Sent: Thursday, December 13, 2012 2:52 PM
> Hi Adrian,
>
> I would suggest to start with my proposal, because it requires zero
> implementation effort.

I am surprised at this.  Gathering information about implementations is
something that happens in some WGs and not in others, but it is always
the chair that is driving it, often as part of the write-up prior to
IETF Last Call.  This takes time, asking, chasing, clarifying, and
getting replies off-list because the implementor does not have
permission to reveal such matters to the world at large.

Since the WG Chair is a limited resource, and is on the critical path
for several actions in the progress of an I-D to RFC, asking them to do
more work can only delay the progress of RFC at large.  This is not a
zero sum game.

Tom Petch

>                             If this catches on, I see a lot of value
in your
> proposal.
>
> Please also note that the "implementation status" section (according
to
> my proposal) is not "frozen" when published as an RFC, rather it is
> deleted. RFCs are forever, and I think a point-in-time implementation
> status is not appropriate in an RFC.
>
> Thanks,
> Yaron
>
> On 12/13/2012 04:16 PM, Adrian Farrel wrote:
> > I'm interested in this idea.
> >
> > However, I note that an "implementation status" section of a
document is frozen
> > in time when a document goes to RFC.
> >
> > I wonder whether we could leverage our tools and do something
similar to IPR
> > disclosures. That is, provide a semi-formal web page where
implementation
> > details could be recorded and updated. These would then be
searchable and linked
> > to from the tools page for the I-D / RFC.
> >
> > They could record the document version that has been implemented,
and also allow
> > space for other notes.
> >
> > Adrian (Just thinking aloud)
> >
> >> -----Original Message-----
> >> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On
Behalf Of
> >> Alessandro Vesely
> >> Sent: 13 December 2012 13:58
> >> To: ietf@ietf.org
> >> Subject: Re: Running code, take 2
> >>
> >> On Wed 12/Dec/2012 20:31:04 +0100 Yaron Sheffer wrote:
> >>>
> >>> I have just published a draft that proposes an alternative to
> >>> Stephen's "fast track". My proposal simply allows authors to
document,
> >>> in a semi-standard way, whatever implementations exist for their
> >>> protocol, as well as their interoperability.
> >>>
> >>> http://www.ietf.org/id/draft-sheffer-running-code-00.txt
> >>>
> >>> [...]
> >>>
> >>> I am looking forward to comments and discussion on this list.
> >>
> >> As an occasional I-D reader, I'd appreciate "Implementation Status"
> >> sections, including IPR info.  I don't think anything forbids to
add
> >> such sections, if the authors wish.  I'd add a count of the number
of
> >> I-Ds that actually have it among the experiment's success criteria.
> >
>