draft-ietf-v6ops-6to4-advisory dependency on draft-ietf-v6ops-6to4-to-historic

"C. M. Heard" <heard@pobox.com> Wed, 06 July 2011 02:22 UTC

Return-Path: <heard@pobox.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 79BF421F8812 for <ietf@ietfa.amsl.com>; Tue, 5 Jul 2011 19:22:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.442
X-Spam-Level:
X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wda-Gunu8wxA for <ietf@ietfa.amsl.com>; Tue, 5 Jul 2011 19:22:56 -0700 (PDT)
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80BCA21F881A for <ietf@ietf.org>; Tue, 5 Jul 2011 19:22:47 -0700 (PDT)
Received: (qmail 11496 invoked from network); 5 Jul 2011 19:22:46 -0700
Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 5 Jul 2011 19:22:46 -0700
Date: Tue, 05 Jul 2011 19:22:46 -0700
From: "C. M. Heard" <heard@pobox.com>
X-X-Sender: heard@shell4.bayarea.net
To: IETF <ietf@ietf.org>
Subject: draft-ietf-v6ops-6to4-advisory dependency on draft-ietf-v6ops-6to4-to-historic
In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F3508430@EMBX01-WF.jnpr.net>
Message-ID: <Pine.LNX.4.64.1107051859520.2828@shell4.bayarea.net>
References: <20110705144429.DDFE218C10A@mercury.lcs.mit.edu> <13205C286662DE4387D9AF3AC30EF456D3F3508430@EMBX01-WF.jnpr.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
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: Wed, 06 Jul 2011 02:22:57 -0000

Greetings,

I note that draft-ietf-v6ops-6to4-advisory-02, now approved for 
publication and in the RFC Editor's queue, has a minor dependency on 
draft-ietf-v6ops-6to4-to-historic, specifically at the end of 
Section 1 (bottom of p. 3):


  "A companion document [I-D.ietf-v6ops-6to4-to-historic] proposes 
   to reclassify 6to4 as Historic.  However, this will not remove 
   the millions of existing hosts and customer premises equipments 
   that implement 6to4.  Hence, the advice in this document remains 
   necessary."

That may need to be changed (e.g., in AUTH48), depending on the 
outcome of the pending appeal against draft-ietf-v6ops-6to4-to-historic.  

//cmh

On Tue, 5 Jul 2011, Ronald Bonica wrote:
> Noel,
> 
> I didn't say that I was going to push 
> draft-ietf-v6ops-6to4-to-historic through without running the 
> process. I said that draft-ietf-v6ops-6to4-to-historic has made it 
> all the way past IESG approval. There is an appeal on the table 
> (at the WG level) questioning whether 
> draft-ietf-v6ops-6to4-to-historic ever had WG consensus. We will 
> run the appeal process. If the WG chairs cannot justify WG 
> consensus, draft-ietf-v6ops-6to4-to-historic stops dead in its 
> tracks. If they can justify WG consensus, the appellant can 
> escalate the appeal to the IESG (and to the IAB after that). If 
> the appeal succeeds at any level, 
> draft-ietf-v6ops-6to4-to-historic is not published.
> 
>                                                                Ron
> 
> 
> -----Original Message-----
> From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] 
> Sent: Tuesday, July 05, 2011 10:44 AM
> To: ietf@ietf.org; v6ops@ietf.org
> Cc: jnc@mercury.lcs.mit.edu
> Subject: RE: draft-ietf-v6ops-6to4-to-historic
> 
>     > From: Ronald Bonica <rbonica@juniper.net>
> 
>     >>> I think that I get it. There is no IETF consensus regarding the
>     >>> compromise proposed below. ...
> 
>     >> But there is no rough consensus to do that either.
> 
>     > That is the claim of an appeal on the table. Let's run the appeal
>     > process and figure out whether that claim is valid.
> 
> Sorry, this makes no sense.
> 
> You can't go ahead with draft-ietf-v6ops-6to4-to-historic if there is no
> basic consensus in the IETF as a whole to do so - and your previous
> declaration (on Saturday) basically accepted that there was no such basic
> consensus (otherwise why withdraw the ID).
> 
> So now there is going to be a reversal, and the document is going to go ahead
> - i.e. you must now be taking the position that there _is_ basic consensus in
> the IETF (without which you could not proceed the ID).
> 
> The effect of this sort of thing on the reputation of I* should be obvious
> to all.
> 
> 	Noel
>