Public IPv4-over-IPv6 Access Network
RFC 7040

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

(Ted Lemon) Yes

(Jari Arkko) No Objection

Comment (2013-05-29 for -09)
No email
send info
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.

(Richard Barnes) No Objection

(Gonzalo Camarillo) No Objection

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

Comment (2013-05-26 for -09)
No email
send info
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"

(Stephen Farrell) No Objection

Comment (2013-05-30 for -09)
No email
send info
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?

(Joel Jaeggli) No Objection

Comment (2013-05-27 for -09)
No email
send info
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

Barry Leiba No Objection

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection

Comment (2013-05-28 for -09)
No email
send info
The draft must clearly state in the title and abstract that it is about CERNET's approach, as mentioned in Sean Turner's comments!

(Sean Turner) (was Discuss) No Objection

(Stewart Bryant) (was Discuss) Abstain

Comment (2013-08-29)
No email
send info
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.

(Brian Haberman) (was Discuss) Abstain

Comment (2013-08-22)
No email
send info
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.