Re: Last Call: 'A Process Experiment in Normative Reference Handling' to Experimental RFC (draft-klensin-norm-ref)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Last Call: 'A Process Experiment in Normative Reference Handling' to Experimental RFC (draft-klensin-norm-ref)




> --On Monday, 12 June, 2006 12:20 +0200 Brian E Carpenter
> <brc at zurich.ibm.com> wrote:

> >...
> >>> The  real underlying  problem of  course  is the  the
> >>> multi-stage  standards process is just a relic from another
> >>> time, and makes no sense at all in the current environment.
> >>> Experiments in fine tuning the process are nothing but a
> >>> distraction.
> >>
> >> For the record, I completely agree with the above sentiments
> >> (and have so stated on the newtrk mailing list).
> >
> > I'd like to ask people who *don't* agree with the above
> > sentiments
> > (i.e. who support this experimental process change) to say so,
> > before
> > the Last Call ends in two days. (Obviously, people who *do*
> > agree are welcome
> > to say so too, but a problem with Last Calls is that it's very
> > hard to
> > judge whether silence means consent.)

> FWIW, I still think the approach in the draft is a good idea
> given that...

> (1) We have not been able to get consensus eliminating a
> multistep standard process.   For reasons explained elsewhere, I
> personally consider that eliminating that process would be a bad
> idea, but that is another discussion.   The present reality is
> that we don't have that consensus and that blocking incremental
> improvements within it is a strange form of "see if we can make
> things worse so as to build momentum for a more basic change".
> I don't believe in that style of doing things.

> (2) We have had repeated claims that the downref issue is a
> major cause of perceived IETF slowness in getting documents out
> and, especially, of getting documents to advanced maturity
> level.  I think that validating (or invalidating) those claims
> would be helpful as a goal in itself.  If it results in a
> significant number of documents being advanced, that would be a
> good thing.  If it results in few or no documents being
> advanced, then we know that particular aFrom ietf-bounces at ietf.org Mon Jun 12 12:06:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FpotX-0007Mo-IK; Mon, 12 Jun 2006 12:04:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FpotV-0007MH-IF; Mon, 12 Jun 2006 12:04:01 -0400
Received: from [206.117.180.234] (helo=mauve.mrochek.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FpotU-0008Fh-73; Mon, 12 Jun 2006 12:04:01 -0400
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com
	(PMDF V6.1-1 #35243) id <01M3J5VHLW7K00DRNY at mauve.mrochek.com>; Mon,
	12 Jun 2006 09:03:57 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1150128237;
	h=Date: 	 From:Subject:MIME-version:Content-type;
	b=R43y8NVZtcr0sVBwfGIgm7dzK
	Tf95EL+cXGS2ECTv5P1sJ7XIIaKUdx6QiqoYKLIghgBSO1ktOXkloa9n+hr3g==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
	id <01M3J4SSUJS00008CX at mauve.mrochek.com>; Mon,
	12 Jun 2006 09:03:56 -0700 (PDT)
To: John C Klensin <john-ietf at jck.com>
Message-id: <01M3J5VGVQCY0008CX at mauve.mrochek.com>
Date: Mon, 12 Jun 2006 09:02:22 -0700 (PDT)
From: Ned Freed <ned.freed at mrochek.com>
In-reply-to: "Your message dated Mon, 12 Jun 2006 07:57:48 -0400"
	<6CD3C9BDD061E5A425DD45CE at p3.JCK.COM>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <448D3FEC.4070105 at zurich.ibm.com>
	<6CD3C9BDD061E5A425DD45CE at p3.JCK.COM>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: iesg at ietf.org, ietf at ietf.org
Subject: Re: Last Call: 'A Process Experiment in Normative Reference
 Handling' to Experimental RFC (draft-klensin-norm-ref)
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Errors-To: ietf-bounces at ietf.org



> --On Monday, 12 June, 2006 12:20 +0200 Brian E Carpenter
> <brc at zurich.ibm.com> wrote:

> >...
> >>> The  real underlying  problem of  course  is the  the
> >>> multi-stage  standards process is just a relic from another
> >>> time, and makes no sense at all in the current environment.
> >>> Experiments in fine tuning the process are nothing but a
> >>> distraction.
> >>
> >> For the record, I completely agree with the above sentiments
> >> (and have so stated on the newtrk mailing list).
> >
> > I'd like to ask people who *don't* agree with the above
> > sentiments
> > (i.e. who support this experimental process change) to say so,
> > before
> > the Last Call ends in two days. (Obviously, people who *do*
> > agree are welcome
> > to say so too, but a problem with Last Calls is that it's very
> > hard to
> > judge whether silence means consent.)

> FWIW, I still think the approach in the draft is a good idea
> given that...

> (1) We have not been able to get consensus eliminating a
> multistep standard process.   For reasons explained elsewhere, I
> personally consider that eliminating that process would be a bad
> idea, but that is another discussion.   The present reality is
> that we don't have that consensus and that blocking incremental
> improvements within it is a strange form of "see if we can make
> things worse so as to build momentum for a more basic change".
> I don't believe in that style of doing things.

> (2) We have had repeated claims that the downref issue is a
> major cause of perceived IETF slowness in getting documents out
> and, especially, of getting documents to advanced maturity
> level.  I think that validating (or invalidating) those claims
> would be helpful as a goal in itself.  If it results in a
> significant number of documents being advanced, that would be a
> good thing.  If it results in few or no documents being
> advanced, then we know that particular argument is not a
> significant part of the picture, and that would, itself, be
> useful.

I agree with both of these points. One signs of a good experiment is that you
learn something from it no matter what the outcome. I see nothing but upside
here and fully support running this process experiment.

				Ned

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.