Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status
draft-ietf-v6ops-natpt-to-historic-00
Yes
(Brian Carpenter)
(Cullen Jennings)
(David Kessens)
(Jari Arkko)
(Ross Callon)
No Objection
(Dan Romascanu)
(Mark Townsley)
(Ted Hardie)
Note: This ballot was opened for revision 00 and is now closed.
Brian Carpenter Former IESG member
Yes
Yes
()
Unknown
Cullen Jennings Former IESG member
Yes
Yes
()
Unknown
David Kessens Former IESG member
(was Discuss, Yes)
Yes
Yes
()
Unknown
Jari Arkko Former IESG member
Yes
Yes
()
Unknown
Lars Eggert Former IESG member
Yes
Yes
(2007-03-07)
Unknown
INTRODUCTION, paragraph 1: > Updates: 2766 (if approved) s/Updates/Obsoletes/ (easily done with an RFC Editor Note)
Ross Callon Former IESG member
Yes
Yes
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
(2007-03-08)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2007-03-07)
Unknown
s/IPSEC/IPsec/
Ted Hardie Former IESG member
No Objection
No Objection
()
Unknown