Subject: RE: [mobile-ip] AD question on the "I" bit in draft-ietf-mobileip -reg-revok-04.txt

From: "Kuntal Chowdhury" <[email-masked]>
Date: Thu, 2 Jan 2003 13:55:37 -0600

> Steven M. Glass wrote:
>
>      We had rejected the 'I' bit set to '0' in the FA's revocation 
> message to indicate "I won't notify the mobile node".  What 
> if the FA's 
> local policy is to always inform the MN, how would it convey that to 
> the HA using the above table (you'd need either two-bits, or worse an 
> ack-ack)!
> 
> 
If the FA's local policy is to always inform the MN, then the FA will
either set the I-bit to 1 if it can notify the MN, or it will set the I
-bit to 0 if it cannot notify the MN. 
Also, the logic (i.e. I = 0 for FA revocation) is proposed in your table 
as well, so I didn't understand your comment "We had rejected....".

> > If we have more than one bit, then it will be easy for a mobility
> > agent to specify the exact reason for not notifying an MN 
> to the other 
> > mobility agent (e.g. local policy, link already 
> disconnected, movement 
> > detected etc.). Otherwise, one of the mobility agent will 
> not know why 
> > the MN was not notified.
> 
>      Yes, we'd have to add an 'information' field (note, it's NOT an 
> error).  We thought through this at one point, too.  My take on this, 
> though, is the reason for this is beyond the scope of mobile ip, 
> because this is the end of the mobile ip session.  Returning 
> errors are 
> good for re-synchronizing, whatever, but in the case of 
> revocation the 
> binding is over, so the reason for dropping is beyond the control of 
> the agent receiving the revocation notice.  The reason for such a 
> revocation could be obtained from e.g. AAA, as it would be part of 
> accounting, etc, records, and an agent should likely use that 
> mechanism 
> to obtain this information (that is from AAA's perspective 
> Mobile IP is 
> another service; when your telnet session drops, you don't 
> get notified 
> to the specifics, it's just reset).  My first thought was it would be 
> useful, too, but thinking about it longer I developed this opinion.  
> There are few parallels between why the FA revokes, and why the HA 
> revokes, so the 'information' space is almost entirely disjoint, and 
> where it isn't such reasons supersede the agents. e.g. AAA related 
> (something else telling the agents to revoke).
> 
>                                Cheers,
>                                    Steve
> 
> 
I think having a code field in the revocation message will help to 
let the mobility agents convey/know why the I-bit was set to 0.

The code filed can be 1 octet long:

Code			Reason
1			Local policy prohibits notification
2			Link already disconnected.
3			MN did not respond.
4			MN's movement detected.
5			other...

Regards,
Kuntal

---

From: "Steven M. Glass" <[email-masked]>
Date: Thu, 02 Jan 2003 19:57:41 -0500

> > (something else telling the agents to revoke).

     I guess we're going to have to hash this out...

> let the mobility agents convey/know why the I-bit was set to 0.

     Do you mean if the FA revokes, the HA revokes, or for both (I'm 
presuming you feel such a field would be useful for both)?  Looking at 

> 1                       Local policy prohibits notification

     This is one that's probably useful for both sides (note, though, 
this may already have been found out via the SA the agents share, but 
certainly could be found out through AAA - yes, if it's revealable, but 
if it isn't this code is not useful to the sender, so we have to add 
"code 255 - reason unrevealed" which is clearly useless).

> 2                       Link already disconnected.

     This would be a code only the FA would be sending.  Why does the HA 
care that the FA's freed a link?

> 3                       MN did not respond.

     Respond to what?  How exactly should the MN respond?  How is it 
even involved in revocation?

> 4                       MN's movement detected.

     This is a code only the HA would be sending.  Does it matter to the 
FA that the MN moved, or just went away?

     I don't see why any of these matter to the agent receiving the 
code.  I agree it may be good for accounting reasons, but it's better 
to convey that through AAA.  Note that the *revoking* agent is likely 
to be the one updating its AAA server, which will then be informing the 
other domain's AAA server.  Telling the agent seems unnecessary.

                                Cheers,
                                    Steve