Skip to main content

Public IPv4-over-IPv6 Access Network
draft-ietf-softwire-public-4over6-10

Yes

(Ted Lemon)

No Objection

(Barry Leiba)
(Gonzalo Camarillo)
(Pete Resnick)
(Richard Barnes)
(Sean Turner)
(Spencer Dawkins)

Abstain


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

Ted Lemon Former IESG member
Yes
Yes (for -09) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2013-05-26 for -09) Unknown
I have no objection to the publication of this document although I am not overly enthusiastic. I would like to hear the discussion of Brian's Discuss.

I think section 12 is probably "Contributors"
Barry Leiba Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (2013-05-29 for -09) Unknown
Elwyn Davies' brought up what I thought was an important question that deserves some discussion. Section 3 mentions DS-Lite. I think it would be useful to clarify the relationship of this work to DS-Lite.

I agree with Stewart Bryant's suggestion on editing document abstract/title. Similar issue was brought up by Elwyn. However, I do think that publishing this document is very useful, as long as the status of the mechanism is clear from at least the abstract.

I can also highly recommend other parts of Elwyn Davies' Gen-ART review from May 25th as something that the authors should take into account.
Joel Jaeggli Former IESG member
No Objection
No Objection (2013-05-27 for -09) Unknown
If this had come from v6ops I'd ask the question of whether it was competing with work from softwire. It clearly isn't or at least not in the sense that it's a submarine.

I am ok with the working group putting it's stamp on one thing a way to deploy something while expressing a preference for another in a seperate document
Martin Stiemerling Former IESG member
No Objection
No Objection (2013-05-28 for -09) Unknown
The draft must clearly state in the title and abstract that it is about CERNET's approach, as mentioned in Sean Turner's comments!
Pete Resnick Former IESG member
No Objection
No Objection () Unknown

                            
Richard Barnes Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Sean Turner Former IESG member
(was Discuss) No Objection
No Objection (2013-08-22) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2013-05-30 for -09) Unknown
title: it does seem like a good idea  to rename this
to be the "CNGI/CERNNET2 Public IPv4 over IPv6 Access
Network" or something similar. So I agree with the
other disucsses/comments on this point.

abstract: end uses don't really care about IPv4 but do
care about Internet connectivity.

abstract: ICP - unexpanded acronyms in the abstract
aren't a good idea reslly

section 1: "Full IPv4 addresses" is not clear to
me, it could mean public/non-bogon addresses or e.g.
a Class C.

section 10: I'm not clear on the consequences
of filtering in the BR based on source IPv6 address.
Wouldn't that possibly cause problems with
multi-homing etc?
Brian Haberman Former IESG member
(was Discuss) Abstain
Abstain (2013-08-22) Unknown
What does it mean for the IETF to publish a WG consensus-based, Informational document that describes how some entity deployed a service?  Why is such a publication not being vectored to the ISE?  This is especially relevant given that this document essentially competes with an active softwire WG document (draft-ietf-softwire-unified-cpe) targeted for PS.
Stewart Bryant Former IESG member
(was Discuss) Abstain
Abstain (2013-08-29) Unknown
I am not convinced that it is wise for a WG to publish an Informational RFC describing a solution that has been deployed, but is not recommended for further deployment, ahead of that WG publishing the RFC that describes its recommended solution. However, I am persuaded that in this particular case in not harmful, and hence I abstain.