Dual-Stack Mobile IPv4
draft-ietf-mip4-dsmipv4-10
Yes
(Jari Arkko)
(Mark Townsley)
No Objection
(Chris Newman)
(Cullen Jennings)
(Dan Romascanu)
(David Ward)
(Jon Peterson)
(Lars Eggert)
(Lisa Dusseault)
(Pasi Eronen)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Tim Polk)
Note: This ballot was opened for revision 10 and is now closed.
Jari Arkko Former IESG member
Yes
Yes
()
Unknown
Mark Townsley Former IESG member
Yes
Yes
()
Unknown
Chris Newman Former IESG member
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Ward Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
(2008-12-04)
Unknown
I don't have the time to wrap my head about this question so I am going to ask directly instead. I hope I can get an answer. Does this MIP4 extension deal with the case when there is a v4<->v6 address family translator between the MN and the FN or HA? Can this operate in such an environment without an application level gateway that support MIP4?
Pasi Eronen Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
No Objection
No Objection
(2008-12-03)
Unknown
This is an updated comment: Issue #1 is the new issue; Issue #2 has been addressed in email for the authors already. Issue #1 The IPv6 Prefix Reply Extension is defined as a skippable extension. As I understand the protocol, this extension will only appear if the client included the IPv6 Prefix Request Extension in a previous message, so I would expect the client to always support this extension. In fact, if the client does not support the extension, it seems to be some kind of error condition. Is there an advantage to using a skippable extension for the prefix reply? Issue #2 The text in section 4.5, list item 2) apparently assumes that the code value in the registration reply header is set to an accept code, but this isn't stated. Perhaps it is obvious, given the text in 4.2, but it might bear repeating here. If the mobile node receives a registration reply header with a code value set to a reject code, would it also follow the procedures in list item 1)?