Deprecating the Anycast Prefix for 6to4 Relay Routers
draft-ietf-v6ops-6to4-to-historic-11
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
()
Unknown
Richard Barnes Former IESG member
Yes
Yes
(2015-03-04)
Unknown
For additional color, see: https://labs.ripe.net/Members/rbarnes/world-ipv6-day-asymmetric-6to4-measurements
Ron Bonica Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2015-03-05)
Unknown
Thank you for the progress with this document since I first balloted No Objection.
Alia Atlas Former IESG member
No Objection
No Objection
()
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
()
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
()
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(2015-03-04)
Unknown
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)
Unknown
I support the procedural issue raised by Pete.
David Harrington Former IESG member
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
()
Unknown
Pete Resnick Former IESG member
(was No Record, Abstain, Discuss)
No Objection
No Objection
()
Unknown
Peter Saint-Andre Former IESG member
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
(2011-06-22)
Unknown
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
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2011-06-22)
Unknown
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
()
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
()
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2011-06-21)
Unknown
(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)
Unknown
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)
Unknown
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)
Unknown
Should "transitioning" be "transition" in the abstract? Note, this is informational and uses 2119 language in section 4.