[Mip4] Comments on draft-sastry-mip4-string-extension-01
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Mip4] Comments on draft-sastry-mip4-string-extension-01



Hi,

I was asked to take a look at this draft. Well it expired 2 weeks ago, but hopefully this will be useful for the next rev.

General:
This document proposes a new extension to MIP4 to allow a text string to be sent from the HA or FA to the MN. The draft does not mandate that a string be handled in a certain way; this is left to implementors. The only requirement is that the string is "intended for the user of the Mobile Node."


My main question is how to guarantee interoperability. The draft says that the message can be displayed on a UI, logged, or handled any other way, as the implementor wishes. This obviously creates issues in terms of interoperability and reliability of the system.

It is easy to imagine displaying or logging a message when we have a traditional UI or syslog, and the message is the suggested registration failure or welcome/motd. In other circumstances it might be unpredictable what a message will cause. This is especially an issue when interoperating between one vendor's HA/FA and another's MN.

The Text field's definition says the text "is intended to be human readable, and MUST NOT affect operation of the protocol." However, I would assert that this is not the case at all -- what is the purpose of the text if no effect is desired? It suggests user intervention on failure, which would somehow have to affect the operation of the protocol (i.e. causing configuration changes) to be useful. To go even further, the example given shows a case where the HA would reject the Reg. Req. due to timestamp mismatch, and the MN's implementation would shield the user from the text message, sending another registration. How would this be possible unless the MN somehow parsed the text message on behalf of the user?

One final question: in the security considerations section, what is your interpretation of the difference for HA and FA, and what if a malicious node tries to insert the message after the M-H auth ext?

Editing:

Section 1, 2nd paragraph.
"it's" -> "its"
might want to insert a hyphen in "implementation dependent"

Section 4, 2nd paragraph.
"it's" -> "its"

recommend adding a pronoun, "a" or "the", before each occurrence of Home Agent and Foreign Agent. This is already done in the abstract, but the rest of the document lacks it.




Attachment: smime.p7s
Description: S/MIME cryptographic signature

-- 
Mip4 mailing list: Mip4 at ietf.org
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.