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. > > >
- Running code, take 2 Yaron Sheffer
- Re: Running code, take 2 Alessandro Vesely
- RE: Running code, take 2 Adrian Farrel
- Re: Running code, take 2 Marc Blanchet
- Re: Running code, take 2 Yaron Sheffer
- Re: Running code, take 2 Yaron Sheffer
- Re: Running code, take 2 Marc Blanchet
- Re: Running code, take 2 Yaron Sheffer
- Re: Running code, take 2 Marc Blanchet
- RE: Running code, take 2 Adrian Farrel
- Re: Running code, take 2 Yaron Sheffer
- RE: Running code, take 2 Adrian Farrel
- Re: Running code, take 2 Marc Blanchet
- Re: Running code, take 2 Loa Andersson
- Re: Running code, take 2 Marc Blanchet
- RE: Running code, take 2 Yaron Sheffer
- Re: Running code, take 2 Ted Hardie
- Re: Running code, take 2 Loa Andersson
- Re: Running code, take 2 Melinda Shore
- Re: Running code, take 2 Randy Bush
- Re: Running code, take 2 Melinda Shore
- Re: Running code, take 2 Randy Bush
- Re: Running code, take 2 Yaron Sheffer
- Re: Running code, take 2 John C Klensin
- Re: Running code, take 2 Randy Bush
- Re: Running code, take 2 Melinda Shore
- Re: Running code, take 2 John C Klensin
- Re: Running code, take 2 Yaron Sheffer
- Re: Running code, take 2 t.p.
- Re: Running code, take 2 t.p.
- Re: Running code, take 2 Randy Bush
- Re: Running code, take 2 Randy Bush
- Re: Running code, take 2 Alessandro Vesely
- Re: Running code, take 2 Yaron Sheffer
- Re: Running code, take 2 Riccardo Bernardini
- Re: Running code, take 2 Stephen Farrell
- Re: Running code, take 2 Yaron Sheffer
- The notion of "fast tracking" drafts (was: Re: Ru… John C Klensin
- Re: Running code, take 2 John C Klensin
- Re: The notion of "fast tracking" drafts Stephen Farrell
- Re: Running code, take 2 Yaron Sheffer
- Re: Running code, take 2 John C Klensin
- Re: The notion of "fast tracking" drafts Keith Moore
- Re: The notion of "fast tracking" drafts John C Klensin
- Re: The notion of "fast tracking" drafts Stephen Farrell
- Re: The notion of "fast tracking" drafts Keith Moore
- Re: The notion of "fast tracking" drafts Stephen Farrell