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

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Tue, 4 Oct 2005 13:50:47 -0700

Hi TJ. 

> > The message is purely informational on the MN.  And how this 
> > information is conveyed to a user is implementation dependent.
> 
> OK, I understand the basic goal.. But I haven't seen many 
> examples of protocol extensions designed to simply carry 
> user-oriented informational messages about a low-layer 
> protocol. Is there something here that couldn't be achieved by SNMP?
> 

RADIUS is pretty popular.  An excerpt from RFC 2138:

   "If desired, the server MAY include a text message in the
Access-Reject
   which MAY be displayed by the client to the user."

The text message is in direct correlation for the response to the
client.  Not sure why we need an out-of-band messaging and external
protocol to achieve what's needed.  And such scheme is not without
precedence.

> >
> > Sorry if this example is confusing.  The timestamp mismatch 
> is part of 
> > normal Mobile IPv4 operation to synchronize the timestamp 
> between the 
> > MN and HA.  So actually, the MN sending another registration is in 
> > response to the error code received and has nothing to do with the 
> > informational message.  Maybe we should come up with a different 
> > example instead.
> > Maybe along the line that HA sends a registration deny with 
> a message 
> > "Prepaid quota reached.  Please contact www.paymore.com to update 
> > balance."
> 
> Right. My point was simply that you described how a MN could 
> suppress the informational message if it could "figure out" 
> and fix what the problem was without user intervention (here, 
> based on the error code). But since the message is 
> informational, the MN has no idea that the message intended 
> for the user was that the prepaid quota had run out! Maybe it 
> was an unrelated informational message.
> 

MN deals with error code, users deal with message.  The message is
directly related to the error code in terms that the cause is explained.
There are many causes of why a registration may be administratively
denied.  A user may be able to take some action to fix the problem so
the MN can register successfully.

> I do understand your goal, if it is that informational 
> messages should only be displayed if (1) an error condition 
> exists that the MN can't figure out how to rectify with 
> another attempt, or (2) the registration was successful. But 
> then it should be stated as such.
> 

The message is not restricted to successful or denied registration
reply.  For example, a message saying "Welcome to FooBar.com" may be in
the initial successful registration reply.  An MN may have multiple HAs
in different domains and these messages can be logged to easily identify
the registration sessions.  So it's better to leave the flexibility of
the use of the message extension.

Thanks for bringing up further clarifications.  We may need to massage
some of them into the next version.

Kent

-- 
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/