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

From: "T.J. Kniveton" <[email-masked]>
Date: Fri, 30 Sep 2005 04:19:47 +0300

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.

-- 
Mip4 mailing list: [email-masked]
    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/