Hi, Mark and Jaakko: I think that MD-102a is good one. It consists of 3 parts: 1. Use mobility 2. Terminal mobility 3. Service mobility The interesting thing is that services also overlap for items 1 and 2 indirectly. However, let me relate above items from the H.323 standard perspective. Item 3 as described in the contribution, it may fall into the category of H.323 supplementary services mobility, while items 1 and 2 will be H.323 (basic) call services. With respect to the "scope" of our present standardization effort of Annex H, the basic question is: How far do we want to go? The reason that I am saying so is that AT&T contribution D.353 provides another view of the services mobility. MD-102a (Siemens and Intel) also describes how many more items need to be addressed for the services mobility. You can easily imagine that the services mobility is one of the most important items that the service providers like to see happen in standard arena. So, my proposal for the interest of the rapid standardization effort is as follows: a. Phase 1: Items 1 and 2 b. Phase 2: Item 3 I like to see other members also provide comments on this. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Monday, July 24, 2000 4:14 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] Update to Service Definitions for Annex H - > a question Hi Marc et al, I just finished reading MD-102a and I have a couple of questions. First of all, though, I want to thank you guys for the excelent contribution, I really liked it. Actually I have just one thing that I don't quite understand. In section 5.1.2 you talk about the Authentication of a H.323 Mobile Terminal and say that it enables the verification of the authenticity of the terminal is context of the association it has with the Mobile User. You also explain this a bit further by adding that this is used to verify that the terminal can act on behalf of the authenticated User using it but you still state that the identity of the terminal is only relevant for the purposes of denying the usage of stolen terminals, etc. (black lists). So my question is that are you talking here about authenticating the terminal or are you referring to authenticating some sort of identifier that is used for the association between the terminal and the user? Your statement in item 3. about not needing to authenticate the user in subsequent terminal re-registrations would also seem to indicate the latter. Thus are you thinking of implementing a way to avoid the User authentication at least in Intra-zone location changes by introducing some sort of temporary local identifier for the terminal/user pair? I know that these are just requirements, but these statements seem to lead to that direction, if I have understood them correctly. The idea seems to be worth while to consider and we should discuss this further, but I don't quite see, how the terminal/user pair could really be authenticated, i.e. you can authenticate the User (by contacting the AuF) and you can authenticate the terminal (if proper cryptographic methods are specified also for the terminal), but how can you authenticate their association? Or am I just reading too much into this? Otherwise the contribution seems fine and I would suggest the addition of its contents to the draft Annex H. Let's have a bit of discussion before that, however. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist@nokia.com * ------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com