Re: Should the RFC Editor publish an RFC in less than 2 months?
"Tom.Petch" <sisyphus@dial.pipex.com> Mon, 03 December 2007 12:02 UTC
Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzA0L-0007id-C2; Mon, 03 Dec 2007 07:02:29 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzA0J-0007dH-UC for ietf@ietf.org; Mon, 03 Dec 2007 07:02:27 -0500
Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzA0I-00085p-5K for ietf@ietf.org; Mon, 03 Dec 2007 07:02:27 -0500
Received: from pc6 (1Cust159.tnt3.lnd4.gbr.da.uu.net [62.188.132.159]) by astro.systems.pipex.net (Postfix) with SMTP id 56A74E0003D5; Mon, 3 Dec 2007 12:02:22 +0000 (GMT)
Message-ID: <039701c8359b$e7864ac0$0601a8c0@pc6>
From: "Tom.Petch" <sisyphus@dial.pipex.com>
To: Lixia Zhang <lixia@CS.UCLA.EDU>
References: <E1IxTPt-0006r4-ST@ietf.org><4751F44D.3050207@isode.com><E1Iye5A-0002sv-6J@megatron.ietf.org><D9AE99FE-731F-4F55-B646-B26A6C8A4485@nokia.com><7AC22E50348D3364BD9C2749@B50854F0A9192E8EC6CDA126><D1661755189D9C66DADD5ACD@[10.1.129.171]><fiur2s$64q$1@ger.gmane.org> <7C07FB6D-805E-4FF5-8F40-64BA444F065F@cs.ucla.edu>
Date: Mon, 03 Dec 2007 10:09:30 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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-Spam-Score: -101.0 (---------------------------------------------------)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Cc: ietf@ietf.org
Subject: Re: Should the RFC Editor publish an RFC in less than 2 months?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Tom.Petch" <sisyphus@dial.pipex.com>
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org
----- Original Message ----- From: "Lixia Zhang" <lixia@CS.UCLA.EDU> To: "Frank Ellermann" <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com> Cc: <ietf@ietf.org> Sent: Sunday, December 02, 2007 8:12 PM Subject: Re: Should the RFC Editor publish an RFC in less than 2 months? <snip> > > I'm late getting into this discussion, but also have the advantages > of seeing arguments on all side at once :-) > > it seems to me that the final decision on this issue would be a > tradeoff in a multi-dimension space: > - how much gain vendors/users may get from publishing an RFC at time=T > vs at (T + 2 months) > in particular if the publication is tagged with some provisional > clause. > - how strong is the desire of wanting the published RFCs to be stable > (i.e. minimizing the chances of reclassification, with an > understanding > that we cannot completely eliminate the chance) > - As pointed out above, what may be the legal complication, if there > is any, > in handling appeals against a published RFC, and remedy the situation > when an appeal succeeds. > > I too first thought that the process ought to be optimized for the > majority cases. I now realized that the optimization should be based > on the weighted percentages: > > (% of no-appeal cases) X (gains from publishing 2-month earlier) > > versus > > (% of appeal cases) X (chance of an appeal succeeded) > X (cost from any potential legal complications > and remedy) > The remedy here may also include the cost to those people who acted > on a published RFC in its first 2 months. > I agree completely. When I am involved in risk analysis, the really nasty cases are 'probability low, impact high' - will the first nuclear bomb set off a chain reaction which destroys the world? unlikely but somewhat devastating if so. I see the withdrawal of approval by the IESG as risk analysis; whether it happens 10% or 0.1% of the time, whether it happens on account of an appeal or because of some other reason is immaterial if the potential adverse impact is high enough. At the same time, I see the benefits of having the RFC now rather than in February as minimal; early adopters adopt early and are proud to announce in their marketing material that their product conforms to I-D draft-ietf-wg-enhanced-protocol. The date of the arrival of an RFC is irelevant to them. The I-Ds that concern me most are those that may have had little exposure, for which that lack of exposure means that potentially show-stopping issues have yet to emerge. So one compromise would be to allow quicker publication of those I-Ds that have had wide exposure, that have been discussed on an IETF mailing list, so that at IETF Last Call it is feasible to look at the mailing list archive to see what has arison, but keep the 60 day delay for individual submissions, or for I-Ds that do not get an IETF Last Call. Tom Petch > so the question to me is really: can we quantify the values of those > weight factors? > (as an academic I dont have a lot clue here) > ps No, in my experience of risk analysis - each participant uses their gut feeling and the chair declares rough consensus. > Lixia > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- Re: Should the RFC Editor publish an RFC in less … Eric Rescorla
- Should the RFC Editor publish an RFC in less than… IETF Chair
- Re: Should the RFC Editor publish an RFC in less … Brian E Carpenter
- Re: Should the RFC Editor publish an RFC in less … John C Klensin
- RE: Should the RFC Editor publish an RFC in less … Wassim Haddad
- Re: Should the RFC Editor publish an RFC in less … Ted Hardie
- Re: Should the RFC Editor publish an RFC in less … Brian E Carpenter
- Re: Should the RFC Editor publish an RFC in less … Leslie Daigle
- Re: Should the RFC Editor publish an RFC in less … Russ Housley
- Re: Should the RFC Editor publish an RFC in less … Cullen Jennings
- Re: Should the RFC Editor publish an RFC in less … Sam Hartman
- Re: Should the RFC Editor publish an RFC in less … Eric Rescorla
- Re: Should the RFC Editor publish an RFC in less … Tim Polk
- Re: Should the RFC Editor publish an RFC in less … Paul Hoffman
- Re: Should the RFC Editor publish an RFC in less … Sam Hartman
- Re: Should the RFC Editor publish an RFC in less … Sam Hartman
- Re: Should the RFC Editor publish an RFC in less … Frank Ellermann
- Re: Should the RFC Editor publish an RFC in less … Eric Rescorla
- Re: Should the RFC Editor publish an RFC in less … Tom.Petch
- Re: Should the RFC Editor publish an RFC in less … Harald Alvestrand
- Re: Should the RFC Editor publish an RFC in less … John C Klensin
- Re: Should the RFC Editor publish an RFC in less … Norbert Bollow
- Re: Should the RFC Editor publish an RFC in less … Iljitsch van Beijnum
- Re: Should the RFC Editor publish an RFC in less … Eric Rescorla
- Re: Should the RFC Editor publish an RFC in less … Dave Crocker
- Re: Should the RFC Editor publish an RFC in less … Alexey Melnikov
- Re: Should the RFC Editor publish an RFC in less … Jari Arkko
- Re: Should the RFC Editor publish an RFC in less … Sam Hartman
- Re: Should the RFC Editor publish an RFC in less … John C Klensin
- Re: Should the RFC Editor publish an RFC in less … Paul Hoffman
- Re: Should the RFC Editor publish an RFC in less … Sam Hartman
- Re: Should the RFC Editor publish an RFC in less … Harald Alvestrand
- Re: Should the RFC Editor publish an RFC in less … Brian E Carpenter
- Re: Should the RFC Editor publish an RFC in less … Bob Hinden
- Re: Should the RFC Editor publish an RFC in less … Frank Ellermann
- Re: Should the RFC Editor publish an RFC in less … John C Klensin
- Re: Should the RFC Editor publish an RFC in less … Spencer Dawkins
- Re: Should the RFC Editor publish an RFC in less … Magnus Westerlund
- Re: Should the RFC Editor publish an RFC in less … Frank Ellermann
- Re: Should the RFC Editor publish an RFC in less … John C Klensin
- Re: Should the RFC Editor publish an RFC in less … Alexey Melnikov
- Re: Should the RFC Editor publish an RFC in less … Jari Arkko
- Re: Should the RFC Editor publish an RFC in less … Russ Housley
- Re: Should the RFC Editor publish an RFC in less … Bob Hinden
- Re: Should the RFC Editor publish an RFC in less … Harald Tveit Alvestrand
- Re: Should the RFC Editor publish an RFC in less … John C Klensin
- Re: Should the RFC Editor publish an RFC in less … Frank Ellermann
- Re: Should the RFC Editor publish an RFC in less … Bob Hinden
- Re: Should the RFC Editor publish an RFC in less … Lixia Zhang
- Re: Should the RFC Editor publish an RFC in less … Frank Ellermann
- Re: Should the RFC Editor publish an RFC in less … Iljitsch van Beijnum
- Re: Should the RFC Editor publish an RFC in less … Frank Ellermann
- Re: Should the RFC Editor publish an RFC in less … Hallam-Baker, Phillip
- Re: Should the RFC Editor publish an RFC in less … Robert Elz
- OOXML (was Re: Should the RFC Editor...) Norbert Bollow
- Re: Should the RFC Editor publish an RFC in less … Norbert Bollow
- Re: Should the RFC Editor publish an RFC in less … Tom.Petch
- Re: Should the RFC Editor publish an RFC in less … Daniel Brown
- Re: Should the RFC Editor publish an RFC in less … Brian E Carpenter
- Re: Should the RFC Editor publish an RFC in less … Harald Tveit Alvestrand
- Re: Should the RFC Editor publish an RFC in less … Scott O. Bradner
- Re: Should the RFC Editor publish an RFC in less … Robert Elz
- RE: Should the RFC Editor publish an RFC in less … Tobias Gondrom
- Re: Should the RFC Editor publish an RFC in less … Frank Ellermann
- Re: Should the RFC Editor publish an RFC in less … Henrik Levkowetz
- Re: Should the RFC Editor publish an RFC in less … Loa Andersson
- Re: Should the RFC Editor publish an RFC in less … JP Vasseur
- Re: Should the RFC Editor publish an RFC in less … Russ Housley