Context Transfer Protocol draft-ietf-seamoby-ctp-03.txt john.loughney@nokia IETF 57

1. Context Transfer Protocol draft-ietf-seamoby-ctp-03.txt john.loughney@nokia.com IETF 57 17 July 2003

2. Major issues • Issue Tracker at: • http://danforsberg.info:8080/draft-ietf-seamoby-ctp/index • 28 total issues • 10 issues listed as closed • 2 purely editorial • 4 marked as rejects • 11 open issues to be resolved

3. Closed Issues 1 Editorial removal of inter / intra domain from draft 2 Technical CTAR response needed 3 Technical Specifying IPsec between ARs 4 Editorial Change doc type to experimental 6 Editorial Editorial text from Basavaraj Patil 7 Editorial Editorial comments on section 1 8 Editorial Need to define technology & link to the terminology draft 10 Technical Support for ESP 15 Technical CTAR relay 16 Editorial Removal of Appendix A

4. Possible Rejects 17 Technical Clarifying text needed on deployment restrictions • At present, I am not sure if this is really needed, but better introductory material could help. • Technical How to identify MN's with private addresses • Probably not needed right yet, further detail needed when going to standards track. • Technical Authorization Token is obtained by truncating the results of the HMAC_SHA1 computation to retain only the leading 32 bits  Probably good enough for experimental 24 Technical Interoperability with other Handover Protocols  Save for future documentation

5. Text To Add 9 Editorial Specify IP Version 11 Technical CTAR format and use 13 Editorial Generic message header 14 Editorial Optional fields and alignment • Technical Description of Message Fields 19 Technical Error codes have not been defined in the document. • Technical Use of C & R flags & Address format 28 Technical Context Data Block header doesn't have a length field  All these need message & parameter type definitions, which I will propose (after vacation) on the mailing list. 23 Editorial What happens to the context at the pAR after transfer is complete? • Need to specify timer behavior to expire context.

6. Discussion Needed 5 Editorial Text needed about how a MN knows to initiate CT • Another thing that puzzled me is how does a MN know if there is any context that exists at an AR? I can understand the cases for HC and QoS wherein the MN may have made specific requests to the AR. Are there other instances as well? Otherwise the MN really has no reason to be sending the CTAR. For example there may be context created at the AR simply as a result of the MN being authenticated. However the MN really has no idea about it and when it moves to a new AR, the same authorization context may be useful. But how does the MN know to initiate CT? Since it has no clue in the first place of the existence of any context.  Text needed • Technical Use of MN's new care-of address • If MN's new care-of address is included in CTAR or CTD before it is assigned on the MN, nAR must defend new CoA (at least for IPv6 DAD) until MN claims it. Should this requirement be stated? Or can the new CoA only be used in CTAR or CTD if it is already assigned to the MN? If so, then it should be clearly stated. • Discussion needed

7. Next Steps • Vacation • After vacation, start working on adding parameter types & message fields, etc. • Proposals sent to the mailing list. • Probably another review needed, sometime at the end of September.