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