Re: [Uri-review] draft-larmouth-oid-iri-01 editorials

Alfred Hönes <ah@TR-Sys.de> Sun, 11 October 2009 21:07 UTC

Return-Path: <A.Hoenes@TR-Sys.de>
X-Original-To: uri-review@core3.amsl.com
Delivered-To: uri-review@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E107A3A687A for <uri-review@core3.amsl.com>; Sun, 11 Oct 2009 14:07:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.851
X-Spam-Level: ***
X-Spam-Status: No, score=3.851 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWGLKTmMMVjy for <uri-review@core3.amsl.com>; Sun, 11 Oct 2009 14:07:34 -0700 (PDT)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id B8A473A6828 for <uri-review@ietf.org>; Sun, 11 Oct 2009 14:07:33 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA215095204; Sun, 11 Oct 2009 23:06:44 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id XAA16667; Sun, 11 Oct 2009 23:06:38 +0200 (MESZ)
From: Alfred Hönes <ah@TR-Sys.de>
Message-Id: <200910112106.XAA16667@TR-Sys.de>
To: blueroofmusic@gmail.com
Date: Sun, 11 Oct 2009 23:06:38 +0200
In-Reply-To: <e395be80910111241y26d96dd0p3bca125a9bf6691f@mail.gmail.com> from Ira McDonald at Oct "11, " 2009 "03:41:52" pm
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 7bit
Cc: uri-review@ietf.org, draft-larmouth-oid-iri@cabernet.tools.IETF.ORG
Subject: Re: [Uri-review] draft-larmouth-oid-iri-01 editorials
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uri-review>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Oct 2009 21:07:36 -0000

Ira,

I wouldn't be so pessimistic as you said below.
(For details, see below.)

As I already have pointed out, for documents of this kind
Proposed Standard might only take a small amount of time
in excess of what will be needed for Informational,
(albeight the AD might even omit IETF LC for Informational).

> Hi John,
>
> This is an informal answer - your mileage will certainly vary...
>
> To publish as an RFC, an appropriate IETF Area Director
> (Applications??) has to briefly review the document (1 month)
> and start an IETF Last Call (1 month).
>
> Then, the IETF AD has to take the document to the IESG
> for approval as an Informational RFC (several months).
>
> Then the RFC Editor has to publish it (four to twelve months).

That's not true (currently).  To be fair to the RFC Editor staff:
Most documents without 'built-in' road blockers (in particular
Normative References to documents not yet approved, not yet
finalized, or even not yet written at all!) or awaiting completion
of IANA processing, currently can be observed to arrive in the
final Author's review stage (AUTH48 state in the RFC Editor Queue)
very quickly.
Things got much worse for the Independent Submission stream due
to Copyright issues with the IETF Trust after RFC 5378, but that
should be entirely out of scope here.

Details:

Looking at the RFC-Ed Queue at this moment, you can see that *all*
Informational drafts on the IETF stream delivered to the RFC Editor
and not blocked by missing references or IANA processing already
have arrived in the final RFC Editor review stage (RFC-EDITOR state),
or in AUTH48.
Standards Track documents are similar, but due to larger volume
and size at average, and due to much more older documents having
become unblocked recently by new arrivals and thus consuming cycles,
a single document (arrived at the RFC Editor on Sep 25) is in
editorial processing among them.
Currently, the duration of final review by the authors (and if there
were nontrivial changes, by the AD) has much more influence on the
time needed from IESG approval to RFC publication -- 33 RFCs-to-be
from the IETF stream are in AUTH48 currently.
(Note that the figures at http://www.RFC-Editor.ORG/CurrQstats.txt
include ISR documents etc.; I have discounted for these above.
This summary is a snapshot apparently taken before the most recent
queue changes on Friday.)

So, including final author review, 2 months would perhaps be more
realistical, not 4..12.

>
> That is to say, a pretty long time.

Pretty long anyway, but not so much as you fear.


Attempts to increase the numbers of hours per day (in order to
give the IESG et al. more working cycles) have not arrived at
IETF consensus in the past, and would have collided with the
firm opinion of other SDOs anyway.  :-)

>
> Cheers,
> - Ira
>

Kind regards,
  Alfred.