Deprecating the Anycast Prefix for 6to4 Relay Routers
RFC 7526

Note: This ballot was opened for revision 05 and is now closed.

(Richard Barnes) Yes

Comment (2015-03-04)
No email
send info

(Ron Bonica) Yes

(Joel Jaeggli) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Stewart Bryant) No Objection

Comment (2011-06-20 for -)
No email
send info
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.

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Spencer Dawkins) No Objection

(Ralph Droms) No Objection

Comment (2011-06-22 for -)
No email
send info
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.

(Wesley Eddy) No Objection

Comment (2011-06-16 for -)
No email
send info
Should "transitioning" be "transition" in the abstract?

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

(Adrian Farrel) No Objection

Comment (2015-03-05)
No email
send info
Thank you for the progress with this document since I first balloted No Objection.

(Stephen Farrell) No Objection

Comment (2011-06-21 for -)
No email
send info
(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.)


(Brian Haberman) No Objection

Comment (2015-03-04)
No email
send info
I appreciate the difficulty in getting consensus on this document and applaud the diligence of the authors and chairs in finding that consensus.

(David Harrington) No Objection

(Russ Housley) No Objection

Comment (2011-06-22 for -)
No email
send info
  The authors have agreed to incorporate the editorial comments from the
  Gen-ART Review by Ben Campbell on 17-Jun-2011.

Barry Leiba No Objection

(Ted Lemon) No Objection

Comment (2015-02-19)
No email
send info
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.

(Kathleen Moriarty) No Objection

(Pete Resnick) (was No Record, Abstain, Discuss) No Objection

(Dan Romascanu) No Objection

Comment (2011-06-23 for -)
No email
send info
I support the procedural issue raised by Pete. 

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection

(Sean Turner) No Objection