Subject: RE: [Seamoby] few comments on CTP 04

From: [email-masked]
Date: Fri, 24 Oct 2003 18:05:04 +0300

Hi Julian,

I thought I replied earlier to this, but I guess I did not.

> after a quick review, these are my questions/comments concerning
> ctp-04..
> 
> 1. p4. 3 §
> 
> We call such an event as a Context Transfer Trigger
> 
> -> We call such en event a Context Transfer Trigger

Actually, it should be:

	We call such an event a Context Transfer Trigger
 
> 2. In the second scenario, nAR may itself generates a Context Transfer
> Request as a response to an internal trigger. 
> 
> The problem is that nAR "must" supply, the MN's previous IP address, the
> feature contexts to be transferred and a token authorizing the transfer.
> 
> So, I guess that either we offer a way to the nAR to retrieve this info
> from MN or the nAR can't generate a Context Transfer as a response to an
> internal trigger.
> 
> Do I miss something ?

I've removed the internal trigger part of the text, as you correctly noted
it would not be possible for the nAR to have the address of the previous
IP address.

> 3. At the last paragraph p5. we have "[1].* contexts ...the  [2]algorithm[3]"

Got it.

> 4. In § 2.3 Context Data Block, it is written:
> 
> "The Cxt-Type indicates the type of the feature context  messages itself
> (such as QoS Context Request, Qos Context Transfer etc,).."
> 
> can't it be deduce from CTAR/CTD/CTR ?

I think it wise to be explicit here.

> 5. In § 2.4.1 Context Transfer Activate Request 
> 
> While a MN sends a CTAR to pAR, the MN includes the nAR's address and its new IP address (if known).
> If these addresses are not known, what does MN include ? (his previous IP
> address or 0.0.0.0/0::0 ?)

The previous IP address.
 
> 6. I can't find "Context Transfer Framework for Seamless Mobility" :-(
> 
> Hope it helps :-)

It is expired, we need to remove it from the references.

Thanks for the comments,
John

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Julien Bournelle <[email-masked]>
Date: Wed, 29 Oct 2003 17:20:22 +0100

Hi,

> > address or 0.0.0.0/0::0 ?)

in the definition of CTD message (§ 2.5.3), the header contains a field
previous Co@ and a field new Co@ if it is a predictive CTD.

What do we do if this address is not known ?
 - previous address (already present)
 - null
 - add a flag in reserved
 - others ?

thanks,
-- 
[email-masked]