Re: Why we don't want to actually replace 2026

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 17 September 2013 20:33 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E495B11E8563 for <ietf@ietfa.amsl.com>; Tue, 17 Sep 2013 13:33:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erk8Aqy25kR8 for <ietf@ietfa.amsl.com>; Tue, 17 Sep 2013 13:33:58 -0700 (PDT)
Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 74A0011E8196 for <ietf@ietf.org>; Tue, 17 Sep 2013 13:33:58 -0700 (PDT)
Received: by mail-pa0-f43.google.com with SMTP id hz10so7317039pad.30 for <ietf@ietf.org>; Tue, 17 Sep 2013 13:33:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=aNb6nHfOV5XSDEYvk4Uq7NqAL6YcauvDkylj5B0Tp34=; b=WfDyheLyPnjNGA0DLbavug5AcLS1J3e94vOZZd2woFouQMbnX9mqyKuKQ3R3knB45F I+c4+4i2ZDu7sV4STwGXPCXU2ycLC/zMiyZ+zv4NQnI1CRWKXYloH5Ntm7oc9vjiZhds 2/RC7P39ZtulFhwr5BiyvAYSq13+GLzSXrwCFOIBMFri1a0xorszM+xcWFTZ54qQS1dV B6Ddx8FlsCHLn1WlhMkzQmEEjiQ/jBoQh3sDv65PWENNMJIy4x7fP5lAv5JbUU/gNlL1 wqIYQ+iluKNsJg4sg48DpjOaFzKzntJ5ngma6ZUlZyYI755fBYB4h+KxGVq4rQ39xSLY xg5g==
X-Received: by 10.68.204.136 with SMTP id ky8mr3783869pbc.192.1379450038155; Tue, 17 Sep 2013 13:33:58 -0700 (PDT)
Received: from [192.168.178.20] (97.192.69.111.dynamic.snap.net.nz. [111.69.192.97]) by mx.google.com with ESMTPSA id os4sm40289136pbb.25.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Sep 2013 13:33:57 -0700 (PDT)
Message-ID: <5238BCB5.6020605@gmail.com>
Date: Wed, 18 Sep 2013 08:33:57 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: S Moonesamy <sm+ietf@elandsys.com>
Subject: Re: Why we don't want to actually replace 2026
References: <B8F661D1-1C45-4A4B-9EFE-C7E32A7654E7@NLnetLabs.nl> <9B5010D3-EA47-49AD-B9D0-08148B7428FC@piuha.net> <CAC4RtVDXVqZkCi1stmuoxawUVDi6+uG-bXWp36CM6-bsqNjiew@mail.gmail.com> <EC75AB54-8B11-42B9-8049-F70D09DB1775@NLnetLabs.nl> <CAC4RtVDj3tBChrJBiBiD6uwOtGRJHLDYeh62XbERrHp0i1Fmfg@mail.gmail.com> <CAPv4CP-DXq0=FX9nFDCo0HXvWKNRTJ+8ay=m7J=JyRxJciN-vw@mail.gmail.c om> <522761EB.2000002@gmail.com> <13BBB594-4510-4903-917B-67D39F60E2BD@NLnetLabs.nl> <A87B7462DC459B3D64373984@JcK-HP8200.jck.com> <6A29D567-0C5A-4CB4-ABDF-450D52D2C642@NLnetLabs.nl> <24CA51F99F2393948000F42F@JcK-HP8200.jck.com> <6.2.5.6.2.20130916214804.0d7f5370@elandnews.com>
In-Reply-To: <6.2.5.6.2.20130916214804.0d7f5370@elandnews.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: John C Klensin <john-ietf@jck.com>, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 17 Sep 2013 20:33:59 -0000

On 17/09/2013 17:49, S Moonesamy wrote:
> Hi John,
> At 08:31 16-09-2013, John C Klensin wrote:
>> By the way, while I understand all of the reasons why we don't
>> want to actually replace 2026 (and agree with most of them),
>> things are getting to the point that it takes far too much
>> energy to actually figure out what the rules are.  Perhaps it is
>> time for someone to create an unofficial redlined version of
>> 2026 that incorporates all of the changes and put it up on the
>> web somewhere.   I think we would want a clear introduction and
> 
> I posted draft-moonesamy-stds-process-00 (expired) [1] in 2010.  I have
> to update the draft as it does not take into account the two-track
> change.  I would not post a revision on the web as the IETF Trust might
> not like it.  In my opinion it might be related to the original
> negotiating position of CNRI.

For some years I've maintained http://www.ietf.org/about/process-docs.html
"to assist IETF participants in navigating the labyrinth." It
does carefully avoid red-lining or commentary, and I think it also
shows the complexity that we have created.

   Brian

> 
> Regards,
> S. Moonesamy
> 
> 1. http://tools.ietf.org/html/draft-moonesamy-stds-process-00 
>