Mapping of Address and Port with Encapsulation (MAP-E)
draft-ietf-softwire-map-13

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

(Ted Lemon) Yes

(Jari Arkko) No Objection

(Richard Barnes) No Objection

(Benoît Claise) No Objection

Alissa Cooper No Objection

Comment (2014-10-29 for -11)
No email
send info
This is perhaps more a comment for the ADs, but it seems that the mechanism specified in this document provides a high degree of configurability in terms of the size of port sets without providing any guidance or explanation about the impact on application stability/breakage of choosing different set sizes. Is there a document somewhere in the softwire document suite that provides this background or advice to service providers about minimizing application impact when choosing port set sizes? RFC 6269 points out the problems, but doesn't provide any detail about how tuning the kinds of knobs available in this spec may affect applications one way or the other. If such a document does not exist, it seems like at least the deployment of the mechanism specified here, if not other variations that make use of restricted port sets, would benefit from it.

(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-12-01 for -12)
No email
send info
Thanks for addressing the SecDir review and adding in a reference to address dependent filtering in the Security Considerations section.

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection

Comment (2014-10-29 for -11)
No email
send info
[updated with one question at the end of the ballot] 

I am balloting no objection on the grounds that this document has been reviewed by the WG and the IETF community at large and apparently "passed" the last calls in terms of having rough consensus. 

However, the proposed solution looks personally to me like a big hack or in other words this document is creating a cross IP version protocol address translator (including using transport protocols).
Actually, the whole work of the softwire working group should be reconsidered from an architectural view. Is this really the long term solution to get the IP transition right or is this just creating the next headache in five years as something out of the networking layer and the transport layer is mixed together as an IPv6 address?

Adding another question:
RFC6346 A+P is used throughout the document and I believe an implementer has to read RFC6346 and understand the A+P sharing mechanism in order to get the implementation of this draft right. Or isn't any knowledge about RFC 6346 required?

(Brian Haberman) Abstain

Comment (2014-10-14 for -11)
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

(Alia Atlas) (was No Objection) No Record