Re: draft-housley-two-maturity-levels

Phillip Hallam-Baker <hallam@gmail.com> Wed, 27 October 2010 00:37 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C12B3A68F8 for <ietf@core3.amsl.com>; Tue, 26 Oct 2010 17:37:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.308
X-Spam-Level:
X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 Rx2KW0gIKRMq for <ietf@core3.amsl.com>; Tue, 26 Oct 2010 17:37:42 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id A72FC3A680F for <ietf@ietf.org>; Tue, 26 Oct 2010 17:37:41 -0700 (PDT)
Received: by gya6 with SMTP id 6so47483gya.31 for <ietf@ietf.org>; Tue, 26 Oct 2010 17:39:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=+UQKAJLt+JKJEhit9K3/s1Ix0tRMZnBNVTTAQeUr9gA=; b=v5ExIhhA1PHbHXtFU7QBb16kVaOEVYgVTjUo7jQ1V+gqLT5KSZR4U8OWuunMpQjbJx 4LLiBU5qoQPndwj4J78EFuGpgC+XHfkIwlYlnH460iG5QoHnVhxyLNa12NPUfCCtW6tf JiwnDJCmKdBZB12MsE/bryieIPvIYdJrogkeQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AMSMRwDrwn75ODZcCnT/3RePTqGxvm2gf3YmVYT8qjA2555TFXdivY/ChPWbCOIIcL LpSFUwI4LjUINe4MPJ8IDLNIXdgtLO/PCIqbplDL38QAaDX1f1VV7VZZwi+LOCh/BryC HPMkPYMn+adw3+29ev5VX1Q0/N7BZiB2Bu22A=
MIME-Version: 1.0
Received: by 10.101.82.10 with SMTP id j10mr7291069anl.245.1288139969433; Tue, 26 Oct 2010 17:39:29 -0700 (PDT)
Received: by 10.100.41.14 with HTTP; Tue, 26 Oct 2010 17:39:29 -0700 (PDT)
In-Reply-To: <046401cb756b$e79f5340$b6ddf9c0$@net>
References: <20101026115954.13D815B23A6@newdev.eecs.harvard.edu> <03b201cb754f$f1b1f930$d515eb90$@net> <20101026231042.GR82074@verdi> <046401cb756b$e79f5340$b6ddf9c0$@net>
Date: Tue, 26 Oct 2010 20:39:29 -0400
Message-ID: <AANLkTimkw2YmSfowWUJN8sd5J-OK8yUHNiYEKf+XjAVW@mail.gmail.com>
Subject: Re: draft-housley-two-maturity-levels
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Tony Hain <alh-ietf@tndh.net>
Content-Type: multipart/alternative; boundary="001636ed73174c90d704938e75e9"
Cc: John Leslie <john@jlc.net>, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 27 Oct 2010 00:37:46 -0000

If it is still possible to get code points issued on an Informational or
Experimental RFC and the bar for those documents is not raised, I don't see
the problem.


Original  ->  Current ->  2 step

Proposed -> Informational / Experimental ->Informational / Experimental
Draft -> Proposed -> Proposed
Standard -> Draft -> Standard

Almost none of the STD documents would qualify for DRAFT status these days
and some would not make Proposed without radical changes.

All we are talking about here really is acknowledging that what the IETF
labels 'DRAFT' standard are in practice full standards.


As for what the IESG should do. Looking at the comments made on KEYPROV,
there were some editing changes that really didn't take a great deal of time
to process and there were some substantive issues that could not have been
changed after the PROPOSED RFC issued.

If someone is suggesting use of a particular identifier space or consistency
with another specification, those are changes I want to see made as soon as
possible. I do not want to have a process where we can get to PROPOSED
really quickly but then have to make major changes to advance to DRAFT
because the IESG is giving the type of feedback that would have been useful
in the previous iteration.

What I would suggest as a means of speeding up the process is for the IAB to
get back into the business of doing architecture and write up a style book
for some of the engineering choices. A lot of the discussions we had in
KEYPROV recapitulated earlier discussions I have had in every XML based
protocol I have worked on. In several cases there are four approaches, all
of which have some drawback that I may or may not remember. Most really
don't have a good answer and it would be as well just to pick one and move
on rather than have the same conversation yet again.


On Tue, Oct 26, 2010 at 8:14 PM, Tony Hain <alh-ietf@tndh.net> wrote:

> I will let James speak to most of your points, but I did talk to him as he
> exited that session, and he was very clear at that point this was the AD
> for
> that WG not the chair, and there was no misunderstanding.
>
> While I trust this is not an official policy, I look at that event as a
> leading indicator for the general IESG 'we are here to protect the
> Internet'
> attitude. We all know that most people stop at PS, because it is not worth
> the effort to do anything more, particularly after the effort to get the
> first step. That feeds the perception (if not the reality) of the need for
> the first PS doc to be perfect. The IESG doesn't do itself any favors by
> perpetuating the perception that the first step has to be perfect, and
> while
> I know there have been personal efforts to minimize the blockage the IESG
> presents, outside indicators show those have been insufficient. The core
> issue is that IESG appears to believe its role is to protect the world,
> rather than manage the process of document creation and drive toward some
> degree of architectural consistency. Note: driving toward a goal does not
> mean preventing progress until the goal has been achieved.
>
> As I suggested in the earlier note, the IESG as a group should really step
> back and only get involved in the step for full Internet Standard, where it
> actually means that the IETF as a whole has considered this document as
> representing a consensus standard, rather than agreeing at PS 'this is a
> document we all intend to work on'. Doing that means the sponsoring AD has
> to take on more of the role of verifying the WG is progressing toward the
> architectural goal, and seeking out cross-Area review, but that approach
> will allow incremental progress where the current approach does not.
>
> Yes, the cost for the RFC Editor goes up when we relax the bottleneck the
> IESG currently represents, but that is the price of progress. Also, the
> external confusion about RFC vs. STD goes up as there are more PS docs, but
> the counter to that is that if we can focus the IESG on getting documents
> from PS to IS there will be a broader array of more relevant documents at
> IS
> to reference.
>
> Tony
>
>
> > -----Original Message-----
> > From: John Leslie [mailto:john@jlc.net]
> > Sent: Tuesday, October 26, 2010 4:11 PM
> > To: Tony Hain
> > Cc: ietf@ietf.org
> > Subject: Re: draft-housley-two-maturity-levels
> >
> > Tony Hain <alh-ietf@tndh.net> wrote:
> > >
> > > Did you miss James Polk's comment yesterday? The IESG is already
> > changing
> > > their ways!! They now require 2 independent implementations for a
> > personal
> > > I-D to become a WG draft.
> >
> >    Though I'd rather steer clear of this fray, I must question this.
> >
> >    I'm quite certain the IESG doesn't have such a blanket policy.
> >
> >    The reported incident _may_ be accurate, but such a requirement
> > would have come from the WG Chair, not the responsible AD, least of
> > all some other AD. I'd be very surprised if this incident turns out
> > to be anything more than a WGC (who may _also_ be an AD) requiring
> > implementation reports for a single I-D proposed for adoption.
> >
> >    I'd also be surprised if there doesn't turn out to be some
> > mis-communication of what was requested and why.
> >
> >    We do, alas, sometimes misunderstand a policy statement and start
> > voluntarily following it in cases where the actual policy wouldn't
> > apply. That is IMHO a measurable part of why the path to PS takes so
> > long. :^(
> >
> > --
> > John Leslie <john@jlc.net>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
Website: http://hallambaker.com/