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@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of
> RJ Atkinson
> Sent: Friday, October 26, 2012 1:16 PM
> To: ietf@xxxxxxxx
> 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
>