Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture
RFC 7596

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

(Ted Lemon) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Richard Barnes) No Objection

(Benoît Claise) (was Discuss) No Objection

Comment (2014-11-20)
No email
send info
Thanks

Alissa Cooper No Objection

Comment (2014-10-29 for -11)
No email
send info
= Section 4 =
"The solution specified in this document allows the assignment of
   either a full or a shared IPv4 address requesting CPEs."
   
I think this sentence is missing a word -- maybe "to" requesting CPEs?

= Section 5.2 =
"The lwB4 is responsible for performing ALG functions (e.g., SIP,
   FTP), and other NAPT traversal mechanisms (e.g., UPnP, NAPT-PMP,
   manual binding configuration, PCP) for the internal hosts."

I would suggest adding "if necessary" at the end of this sentence. At least for SIP, we have IETF guidance (in BCP 127) recommending that SIP ALG functionality be disabled by default.

= Section 9 =
It seems like the mechanism specified in this draft basically trades off the user's security (in the case where contiguous ports are used) in favor of efficiency/cost savings for the service provider. It seems like that should be stated more clearly -- at best there is no benefit of this solution to the user, and at worst it increases the attack potential. Or is there a place in the softwire document suite where this is explained more generally for other mechanisms that also use contiguous ports in port sets?

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

Comment (2014-10-30 for -11)
No email
send info
I don't have any specific objection to this document. I agree with others that there are too many options and potential solutions being published. While there is a good chance that the market will decide and winnow this down to just a very few practical solutions, I believe the IETF (and specifically the Softwire working group) is letting down the industry. Vendors will be unclear which solutions to implement and operators are unlikely to give early direction. This will result in multiple implementations that either do not interoperate or that increase the net cost of equipment. And in the end, who pays?

I wish more effort had gone into reducing the options.

Barry Leiba No Objection

Comment (2014-10-29 for -11)
No email
send info
I've had a quick look, and nothing stands out.  I trust my distinguished colleagues from Vermont and Maryland to duke it out.

(Kathleen Moriarty) (was Discuss) No Objection

Comment (2014-11-06 for -11)
No email
send info
The proposed changes address the discuss points raised int he SecDir review, thank you.

http://www.ietf.org/mail-archive/web/secdir/current/msg05163.html

(Pete Resnick) No Objection

(Brian Haberman) Abstain

Comment (2014-10-14 for -10)
No email
send info
I find it a dis-service to the community for the softwire WG to put forth multiple solutions that solve essentially the same problem (https://mailarchive.ietf.org/arch/msg/ietf/jcscmIHmAQSvXLAlLLvfhnC2P8A).  I believe the confusion caused by a myriad of solutions in this space, regardless of whether they are Standards Track or Experimental, will adversely impact vendors, operators, and end-users.  My only hope is that this confusion will speed up the transition to IPv6-only operations within the affected networks.

(Joel Jaeggli) Abstain