RE: few comments on CTP 04

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