Cisco's Mobile IPv4 Host Configuration Extensions
Note: This ballot was opened for revision 04 and is now closed.
(Margaret Cullen) Yes
(Brian Carpenter) No Objection
Comment (2005-09-14 for -** No value found for 'p.get_dochistory.rev' **)
Gen-ART review comments from Elwyn Davies: The document is generally in good shape but needs a small number of clarifications: - It should be made explicit which extensions are allowed in registration requests and which in registration replies. - The sub-type fields in s3 should be explicitly stated to contain an integer from 0 to 255. - The Home Network Prefix extension would be better named Home Network Prefix Length extension. - In s3.1: It would be worth stating that other values of the selector are reserved... presumably some form of flag word was intended originally but this is now presumably moot. Questions about the DHCP Client ID Extension: - Regarding the summary in s2: If the Client ID is *really* used to obtain the IP address for the mobile node, this can only be done while the node is at home. If the mobile node is booting up on a foreign network it needs to find its IP address by some other means than DHCP. What is actually implemented here? Is the home agent to query the DHCP server and obtain the client ID and pass it on? Is the mobile node supposed to know what its Client ID is and pass it through the Home Agent which can use it on behalf of the mobile node? - In s3.5, it should be made clear if this is expected to be in a registration request or a registration reply (or either). - [Aside] There has been some discussion in the wg as to what information should be obtained through this sort of request. Much of it could be obtained through DHCP once the mobile node is told the address of the DHCP server. And there is no particular need for the home agent to know the DHCP Client ID as far as I can see. <snip> Editorial: s3.8: s/atmost/at most/ s5: s/information/informational/
(Bill Fenner) No Objection
(Ted Hardie) No Objection
(Russ Housley) (was No Record, Discuss) No Objection
I propose an alternate IESG note: This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information. This RFC does not offer any security mechanisms to provide data origin authentication and integrity, yet these security services are vitally important in this context.