![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
> --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.