Re: Running code, take 2
t.p. <daedulus@btconnect.com> Fri, 14 December 2012 11:24 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 16CA321F8549 for <ietf@ietfa.amsl.com>; Fri, 14 Dec 2012 03:24:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level:
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 hv3HRYPf9oSx for <ietf@ietfa.amsl.com>; Fri, 14 Dec 2012 03:24:39 -0800 (PST)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 7723021F853D for <ietf@ietf.org>; Fri, 14 Dec 2012 03:24:33 -0800 (PST)
Received: from mail31-ch1-R.bigfish.com (10.43.68.232) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Fri, 14 Dec 2012 11:24:32 +0000
Received: from mail31-ch1 (localhost [127.0.0.1]) by mail31-ch1-R.bigfish.com (Postfix) with ESMTP id 6DA5C605D3; Fri, 14 Dec 2012 11:24:32 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.253.85; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -24
X-BigFish: PS-24(zzbb2dI98dI9371Ic89bh936eI542Id87dh1432I4015I62a3Izz1de0h1202h1e76h1d1ah1d2ahzz17326ah8275bh8275dh1033ILz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h304l1155h)
Received: from mail31-ch1 (localhost.localdomain [127.0.0.1]) by mail31-ch1 (MessageSwitch) id 1355484269624956_16861; Fri, 14 Dec 2012 11:24:29 +0000 (UTC)
Received: from CH1EHSMHS001.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.251]) by mail31-ch1.bigfish.com (Postfix) with ESMTP id 92E1B4C0042; Fri, 14 Dec 2012 11:24:29 +0000 (UTC)
Received: from DB3PRD0710HT001.eurprd07.prod.outlook.com (157.56.253.85) by CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 14 Dec 2012 11:24:29 +0000
Received: from DBXPRD0510HT005.eurprd05.prod.outlook.com (157.56.252.165) by pod51017.outlook.com (10.255.75.36) with Microsoft SMTP Server (TLS) id 14.16.245.2; Fri, 14 Dec 2012 11:24:27 +0000
Message-ID: <023301cdd9ed$58110780$4001a8c0@gateway.2wire.net>
From: "t.p." <daedulus@btconnect.com>
To: Marc Blanchet <marc.blanchet@viagenie.ca>
References: <50C8DB78.3080905@gmail.com> <50C9DED7.8060604@tana.it><006601cdd93c$6f9f7a00$4ede6e00$@olddog.co.uk><50C9EBB3.5040901@gmail.com><B73F381B-93E7-4158-B5C5-D1F88994E7DF@viagenie.ca><50C9ED7B.2010009@gmail.com><6404EADF-2DA7-42FF-B6DC-596B0163687B@viagenie.ca><009401cdd944$02fe0da0$08fa28e0$@olddog.co.uk><50C9F2C2.1020004@pi.nu> <D20F60AB-3E90-4342-B13C-7572118EF014@viagenie.ca>
Subject: Re: Running code, take 2
Date: Fri, 14 Dec 2012 11:22:39 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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]
Content-Transfer-Encoding: quoted-printable
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:24:40 -0000
----- Original Message ----- From: "Marc Blanchet" <marc.blanchet@viagenie.ca> To: "Loa Andersson" <loa@pi.nu> Cc: <ietf@ietf.org> Sent: Thursday, December 13, 2012 3:39 PM Le 2012-12-13 à 10:22, Loa Andersson a écrit : > Folks, > > I agree that understanding the implementation status of a draft > sometimes is essential, but not for all drafts and not always. > Today wg chairs do this type of info collection at the shepherd > write-up. > > Have anyone thought about how much work goes into compiling this type > of information. There are vendors that by policy decided not to disclose > implementation information, before the implementation is done and the > document has become an RFC. > > Most of the time it is possible to to get some understanding, with a > promise not to make the info public and only use it for a rather > cryptic statement in the shepherd write-up - "we know of existing or > intended implementations of this draft". > > A second, rather new problem, is that for some drafts the IANA > assignment is the singular most important part of the ID. We have heard > vendors say "We'll wait for the IANA assignment until we implement!" > right. but that does not preclude doing the proposal. What you are saying is that maybe the info (in draft, wiki, tracker) may not be complete since some may not disclose. But the available information would be valuable. <tp> And could be very misleading, because it is incomplete and people will draw unwarranted inferences from the information that has been made public. They will likely not understand the nuances of different implementors having different policies about when to make such details public, whether for commercial reasons, IPR reasons or whatever. Nor may they realise that an I-D is a work in progress, so an implementation at an early stage may be really bad news if there is a later change to the technical details (something of which happened with MPLS-TP OAM, with an ITU-T approach predating an IETF one). Tom Petch </tp> Marc. > /Loa > > > On 2012-12-13 16:10, Adrian Farrel wrote: >> How about... >> >> Start with Yaron's proposal to include in the I-D. This is easy as a starting >> point. Duplicate documentation in wiki may be useful and provide a place to >> track text for inclusion in the next revision. >> >> When/if inclusion in the I-D gets messy, replace text in I-D with pointer to >> wiki. >> >> When/if experiment looks like a success, replace all above with data tracker >> tool and allow it to persist for RFCs. >> >> Adrian >> >>> -----Original Message----- >>> From: Marc Blanchet [mailto:marc.blanchet@viagenie.ca] >>> Sent: 13 December 2012 15:05 >>> To: Yaron Sheffer >>> Cc: adrian@olddog.co.uk; ietf@ietf.org; 'Alessandro Vesely' >>> Subject: Re: Running code, take 2 >>> >>> >>> Le 2012-12-13 à 10:00, Yaron Sheffer a écrit : >>> >>>> Hi Marc, >>>> >>>> I think it's critical that a person reading a draft (e.g. going to >>> http://tools.ietf.org/html/draft-blanchet-iab-internetoverport443-01) will >> have a >>> direct way to check out on the implementation status. >>>> >>>> This is trivial if it's a section in the document. It's simple if it's >> linked from the >>> Tools page. Otherwise, e.g. if you put it on the wiki, only IETF insiders will >> be >>> aware of it. >>>> >>> >>> sure. Let me restart: >>> - I like Adrian proposal: instead of in RFC, put it online within our site >>> - but you wrote: requires implementation effort. >>> - I replied: well, phase 1 (of put it online within our site) can be done with >> almost >>> zero implementation effort. phase 2 requires some work (I'd say not that big) >> for >>> implementation/tools. >>> >>> Regards, Marc. >>> >>>> Thanks, >>>> Yaron >>>> >>>> On 12/13/2012 04:55 PM, Marc Blanchet wrote: >>>>> >>>>> Le 2012-12-13 à 09:52, Yaron Sheffer a écrit : >>>>> >>>>>> Hi Adrian, >>>>>> >>>>>> I would suggest to start with my proposal, because it requires zero >>> implementation effort. >>>>> >>>>> disagree. phase 1: use IETF wiki. phase 2: develop an widget within data >>> tracker. >>>>> >>>>> Marc. >>>>> >>>>> >>>>>> 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. >>>>>>> >>>>> >> > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13
- 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