ietf
[Top] [All Lists]

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

2012-10-26 13:03:19
Ran,

I agree that the references to I-D.gont-6man-oversized-header-chain and 
gont-6man-nd-extension-headers should both be NORMATIVE, and not INFORMATIVE. 
Sorry for having missed this.

If Fernando were to post an updated version that makes this change, would it 
address all of your issues? If Fernando did this, it should address 6man's 
concerns because even if draft-ietf-v6ops-ra-guard-implementation were 
approved, it couldn't be published until the other two drafts are also approved.

                                          Ron


-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
RJ Atkinson
Sent: Friday, October 26, 2012 1:16 PM
To: ietf(_at_)ietf(_dot_)org
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


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