Re: Last Call: <draft-ietf-v6ops-ra-guard-implementation-04.txt> (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice

RJ Atkinson <rja.lists@gmail.com> Fri, 26 October 2012 17:15 UTC

Return-Path: <rja.lists@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 178EE21F863C for <ietf@ietfa.amsl.com>; Fri, 26 Oct 2012 10:15:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.196
X-Spam-Level:
X-Spam-Status: No, score=-3.196 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1]
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 x6BfhvbKeYn4 for <ietf@ietfa.amsl.com>; Fri, 26 Oct 2012 10:15:43 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 573F421F8634 for <ietf@ietf.org>; Fri, 26 Oct 2012 10:15:43 -0700 (PDT)
Received: by mail-vb0-f44.google.com with SMTP id fc26so3602850vbb.31 for <ietf@ietf.org>; Fri, 26 Oct 2012 10:15:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=KTzuJ3keLhEyGohw/K9xabkkjQXRZiCrQt9KMeo6JfM=; b=livuazgISVbTVtCkmP5AagR2HiIgPkWD/QNClS5qKQtqmOoia/8P729mchepdz5k/R xvuIufULKKUdlJd6pyYppy2hAc4vhcHAluFZ1UShjskDqiirVy8wzhhBmZrIOKtlbLgR 3clhLsMODQionVMqqQUSVwzzWcyL8QuvoSTS2Dj+XPYWBIviIO4azTR5ioDxMkipNaZM GraiEu1f8Y4jKuRpQMoFkCnyW7jEpcXhsCeHJZ6e1Ytku0yMS9J0U8jfVoMvd7UD/FMk WmCeMh5njH+eOqiNfflylUa1JzAJFuTIhPPXzYvuSq1WrOWmpqY27sM/Vftob/j9Y01s aN2Q==
Received: by 10.220.221.203 with SMTP id id11mr19894191vcb.42.1351271742810; Fri, 26 Oct 2012 10:15:42 -0700 (PDT)
Received: from [10.30.20.14] (pool-74-110-100-136.nrflva.fios.verizon.net. [74.110.100.136]) by mx.google.com with ESMTPS id o13sm1097848vde.21.2012.10.26.10.15.41 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Oct 2012 10:15:42 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1283)
Subject: Re: Last Call: <draft-ietf-v6ops-ra-guard-implementation-04.txt> (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice
From: RJ Atkinson <rja.lists@gmail.com>
In-Reply-To: <20121026160427.30056.5891.idtracker@ietfa.amsl.com>
Date: Fri, 26 Oct 2012 13:15:40 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <2164CBA8-3B59-4A83-A170-B68D118B44FC@gmail.com>
References: <20121026160427.30056.5891.idtracker@ietfa.amsl.com>
To: ietf@ietf.org
X-Mailer: Apple Mail (2.1283)
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: Fri, 26 Oct 2012 17:15:44 -0000

On 26  Oct 2012, at 12:04 , The IESG wrote:
> The IESG has received a request from the IPv6 Operations WG (v6ops)
> to consider the following document:
> - 'Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)'
>  <draft-ietf-v6ops-ra-guard-implementation-04.txt>
> as Best Current Practice
> 
> The IESG plans to make a decision in the next few weeks,
> and solicits final comments on this action. 



Starting IETF Last Call seems premature for this document.
(Perhaps there was some slip of the keyboard somewhere ??)


1) Conflicts with active work items of the IPv6 WG

This I-D has the effect of over-riding parts of the 
standards-track IPv6 specifications (e.g. by making 
currently valid/legal (if unusual) IPv6 packets illegal 
and instructing RA-Guard implementations to drop such
currently valid/legal IPv6 packets).

My understanding is that the 2 proposals to update the 
IPv6 specifications (directly related to this document) 
are current work items of the IETF 6MAN WG, but (as near 
as I can tell) those documents have not even begun 
WG Last Call within the IPv6 WG.



2) Previously agreed document edits are not present
   in the document version referenced by the IESG
   announcement.

Prior discussion with the document author, both on the
v6ops mailing list (e.g. various notes in June 2012, e.g.,
<http://www.ietf.org/mail-archive/web/v6ops/current/msg13258.html>) 
and also off-list, indicated that he had agreed to move the 
relevant IPv6 protocol update documents from "Informative" 
references to "Normative" references, specifically the 
draft-ietf-6man-* versions of these 2 references of the 
IESG cited document:

   [I-D.gont-6man-oversized-header-chain]
              Gont, F. and V. Manral, "Security and Interoperability
              Implications of Oversized IPv6 Header Chains",
              draft-gont-6man-oversized-header-chain-01 (work in
              progress), April 2012.

   [I-D.gont-6man-nd-extension-headers]
              Gont, F., "Security Implications of the Use of IPv6
              Extension Headers with IPv6 Neighbor Discovery",
              draft-gont-6man-nd-extension-headers-02 (work in
              progress), January 2012.



3) Email from document author indicates this document
   will be updated soon.

Separately, overnight private email from the author (received 
by me prior to my receipt of this IESG announcement) indicates 
that an update to draft-ietf-v6ops-ra-guard-implementation is
imminent.  The pending update apparently resolves issue (2)
above.


So it seems to me that this document is not yet ready for
IETF Last Call.  Instead, it seems to me that the pending I-D 
update needs to occur, a (hopefully quick) review of that 
revision within IETF v6ops WG then needs to occur, and (ideally 
in parallel) IETF 6MAN WG review (and ideally approval) of the 
proposed changes to the IPv6 specifications needs to occur.


LAST)

In the (one hopes unlikely) event that the 6MAN WG is NOT
comfortable with the 2 directly-related proposed IPv6 
specification updates, then this document ought not be 
published on the IETF standards-track, on grounds that 
it specifies packet dropping behaviour inconsistent with 
the extant IPv6 specifications.


Yours,

Ran Atkinson