Deprecating the Anycast Prefix for 6to4 Relay Routers
draft-ietf-v6ops-6to4-to-historic-11

Thank you for the progress with this document since I first balloted No Objection.

I appreciate the difficulty in getting consensus on this document and applaud the diligence of the authors and chairs in finding that consensus.

I support the procedural issue raised by Pete. 

I've reviewed the IETF last call discussion for this document, and
come to my own conclusion about consensus of community support for
publication of this document.  Based on my conclusion, I will vote "No
Objection." 

Like Stewart, I would like the responsible AD to provide a summary of
the issues raised in the IETF last call, some indication of whether
those issues will result in any changes to the document and a
consensus call on the discussion.

  The authors have agreed to incorporate the editorial comments from the
  Gen-ART Review by Ben Campbell on 17-Jun-2011.

(1) Why repeat stuff from draft-ietf-v6ops-6to4-advisory?  I think
just referring to that document would be better since it gives a
fuller and better explanation. That could lead to just removing
section 3 entirely I think.

(2) I have no strong opinion as to whether deprecating the
domain and addresses in section 5 is right or wrong. However, I do
think that since draft-ietf-v6ops-6to4-advisory does have what look
like some very useful recommendations about these, that a reference
to that document in the IANA considerations section would be
good since the current text there looks like its saying "turn all
that off please" and I don't think that's what you're trying to say. 

Maybe something like: 

"Note however that [I-D.ietf-v6ops-6to4-advisory] recommends that 
various actors take various actions related to these addresses. The 
reader is encouraged to follow those recommendations and is not 
encouraged to simply turn off these addresses." 

If putting that in the IANA considerations section is wrong,  then 
I think correcting the impression elsewhere would be good, maybe 
with something like:

"Despite what you might think from reading the IANA considerations
section of this document, we are not recommending that people turn 
off the addresses deprecated there. The IANA considerations section
is simply a set of instructions to IANA. Please consult  
[I-D.ietf-v6ops-6to4-advisory] for the actual set of actions 
recommended."

(I'm sure the phrase "turn off" in the suggested text above is wrong,
but that should be easily corrected and it may need to also say 
something about the domain as well, I don't know.)

Looking at the IETF LC discussion it's clear
that consensus to proceed is pretty rough.
However I think that on ballance the rough is 
probably in favour of publication.

Given the above, I think that the responsible AD
needs to provide a more extensive review of
the consensus issues in  the announcement
text than is currently proposed.

Given the extended dialogue that the proto statement
indicates took place I am supprised that there is not
greater discussion of the alternatives and rational
for picking this approach provided in the text of
the draft.

I am somewhat discouraged that this document doesn't make stronger recommendations, and question whether the consensus process was really run correctly.   I think that there was a fair amount of content-free posturing during the discussion, and that this held more sway over the eventual outcome than was really appropriate.

That said, I appreciate the efforts of the authors, working group chairs and AD to come to a resolution of the process, and I think this document is better than no document, so I am balloting No Objection.

Should "transitioning" be "transition" in the abstract?

Note, this is informational and uses 2119 language in section 4.