Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status
RFC 4966
Yes
No Objection
Note: This ballot was opened for revision 00 and is now closed.
Lars Eggert Yes
INTRODUCTION, paragraph 1: > Updates: 2766 (if approved) s/Updates/Obsoletes/ (easily done with an RFC Editor Note)
(Brian Carpenter; former steering group member) Yes
(Cullen Jennings; former steering group member) Yes
(David Kessens; former steering group member) (was Discuss, Yes) Yes
(Jari Arkko; former steering group member) Yes
(Ross Callon; former steering group member) Yes
(Dan Romascanu; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
Section 8. It appears that alternatives to NAT-PT exist to cover the circumstances where NAT-PT has been suggested as a solution, such as the use of tunneling and header compression in 3GPP scenarios. Can someone please provide a referenence in this section to where Header compression is a solution for IPv4/IPv6 translation. It appears very strange to me. I can understand if it is used to reduce the impact of the tunneling in regards to MTU and bit-rate issues. But mentioning header compression in the conclusion out of the blue seems strange. Maybe removing the mentioning of header compression is an alternative to providing a reference.
(Mark Townsley; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
s/IPSEC/IPsec/
(Ted Hardie; former steering group member) No Objection