Skip to main content

Deprecating the Anycast Prefix for 6to4 Relay Routers
RFC 7526

Yes

(Joel Jaeggli)
(Ron Bonica)

No Objection

(Alia Atlas)
(Barry Leiba)
(Benoît Claise)
(David Harrington)
(Gonzalo Camarillo)
(Jari Arkko)
(Kathleen Moriarty)
(Pete Resnick)
(Peter Saint-Andre)
(Robert Sparks)
(Sean Turner)
(Spencer Dawkins)

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

Joel Jaeggli Former IESG member
Yes
Yes ()

                            
Richard Barnes Former IESG member
Yes
Ron Bonica Former IESG member
Yes
Yes ()

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2015-03-05)
Thank you for the progress with this document since I first balloted No Objection.
Alia Atlas Former IESG member
No Objection
No Objection ()

                            
Barry Leiba Former IESG member
No Objection
No Objection ()

                            
Benoît Claise Former IESG member
No Objection
No Objection ()

                            
Brian Haberman Former IESG member
No Objection
No Objection (2015-03-04)
I appreciate the difficulty in getting consensus on this document and applaud the diligence of the authors and chairs in finding that consensus.
Dan Romascanu Former IESG member
No Objection
No Objection (2011-06-23)
I support the procedural issue raised by Pete. 
David Harrington Former IESG member
No Objection
No Objection ()

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection ()

                            
Jari Arkko Former IESG member
No Objection
No Objection ()

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection ()

                            
Pete Resnick Former IESG member
(was No Record, Abstain, Discuss) No Objection
No Objection ()

                            
Peter Saint-Andre Former IESG member
No Objection
No Objection ()

                            
Ralph Droms Former IESG member
No Objection
No Objection (2011-06-22)
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.
Robert Sparks Former IESG member
No Objection
No Objection ()

                            
Russ Housley Former IESG member
No Objection
No Objection (2011-06-22)
  The authors have agreed to incorporate the editorial comments from the
  Gen-ART Review by Ben Campbell on 17-Jun-2011.
Sean Turner Former IESG member
No Objection
No Objection ()

                            
Spencer Dawkins Former IESG member
No Objection
No Objection ()

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2011-06-21)
(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.)


Stewart Bryant Former IESG member
No Objection
No Objection (2011-06-20)
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.
Ted Lemon Former IESG member
No Objection
No Objection (2015-02-19)
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.
Wesley Eddy Former IESG member
No Objection
No Objection (2011-06-16)
Should "transitioning" be "transition" in the abstract?

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