Mapping of Address and Port using Translation (MAP-T)
draft-ietf-softwire-map-t-08

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

(Ted Lemon) (was No Objection, Discuss, Yes, Discuss, Yes) Yes

Comment (2015-02-05)
No email
send info
The last call actually ended at midnight, I guess, so I'm dropping my discuss in advance of the telechat.

(Jari Arkko) No Objection

Comment (2014-10-30 for -06)
No email
send info
Several people, including a Gen-ART reviewer, have asked about the status designation. I think we have all read about the history of how we got here. I do not personally have an objection for upgrading the document (but of course that would require a new last call). Nor do I think the IESG or reviewers should have a strong opinion in the matter. However, I'd suggest that broad applicability and interest from the working group, in today's context, should be the deciding factor, if someone wants to make a change.

(Alia Atlas) No Objection

Comment (2015-01-21)
No email
send info
I do agree with Adrian's comments about clarifying how and what the experiment is.

(Benoît Claise) No Objection

Comment (2014-10-30 for -06)
No email
send info
Exactly like Adrian, I would like some more information on the Experimental status.
As examples:
   http://tools.ietf.org/html/rfc7360#section-1.3
   http://tools.ietf.org/html/rfc6614#section-1.3

I believe this should be common practice for experiemental RFCs. 
Re-reading RFC 3933, and I don't see this. 
Maybe an IESG statement ... ? 



Editorial from Victor K. (OPS-DIR review):
Section 7.1

Paragraph 2:
old text “.. a CE requires an the IPv6 prefix to be assigned to the CE”
new text “.. a CE requires an IPv6 prefix to be assigned to the CE.”

Section 7.2

Paragraph 3:
old text “.. no specific routes need to be  advertised externally for MAPto operate, neither in IPv6 nor IPv4 BGP.”
new text “.. no specific IPv6 or IPv4 routes need to be advertised externally outside the service provider’s network for MAP to operate.”

I added this version of the sentence since it makes more sense to me.  Also, you technically don’t need BGP on the ISP side (although I can’t a modern network which does not use it).

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

Comment (2015-01-29)
No email
send info
Thanks for bringing this back around through the process circuitry.
I have no objection to publication.

(Stephen Farrell) No Objection

Comment (2015-01-22)
No email
send info
- I support Pete's discuss about IPR - surely this has to
go around to IETF LC again for that?

Barry Leiba No Objection

Comment (2014-10-29 for -06)
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) No Objection

Comment (2014-10-29 for -06)
No email
send info
The security considerations look good, thank you.

(Pete Resnick) (was Discuss) No Objection

Comment (2015-02-03)
No email
send info
The document has undergone another Last Call regarding the IPR (which was previously declared on an earlier version of a document that had this specification as a part) and the IESG has discussed the change in status. I won't stand in the way of the document.

(Martin Stiemerling) No Objection

Comment (2014-10-29 for -06)
No email
send info
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?

(Richard Barnes) Abstain

Comment (2014-10-30 for -06)
No email
send info
For the same reasons as Brian.

Alissa Cooper Abstain

Comment (2015-02-04)
No email
send info
Agree with Brian.

(Brian Haberman) Abstain

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