Hi again Ed, Radhika et al As you had quite a bit of conversation during my out-of-office hours, I'll try to include all my comments on the discussion in this one mail. First of all, I do not understand Ed's comment about the HomeZone ID & VisitedZone ID not clashing with the meaning of zone. Surely these are meant to be some identifiers for certain zones. I did not, btw. propose the concepts Home Area and Visited Area, these terms are in my opinion not good terms and I just tried to illustrate my point with using them in the earlier mail. Thus I propose that we do not use them. What I was trying to say in the earlier mail is this: we have not agreed where the HLF and VLF (or AuF for that matter) should be placed in the architecture. The concept of HomeZone implies that each User has one zone which is his/her/its home, thus also implying that the HLF must be associated with the GK of that zone and no other GK (of course other GKs could have their own HLFs). Similarly each GK would have their own VLFs. When I introduced the concepts of Home Domain and Visited Domain, I was thinking about the HLF and VLF being functionalities that are used by all the GKs in the Domain, thus I would rather associate them with e.g. the BE than the GK. The point is that we have not defined or even really discussed the architecture yet, so let's not define terms that already point to a certain direction in the architectural decision. As for the Location Area (LA) concept, my contribution (APC-1659) did not actually present it as a subset of a zone. I tried to define it in such a way that I would not restrict the possible Network Points of Attachment that can belong to a LA. The result in the end was, I agree, quite complicated, allowing the LA to be either a subset, a superset (one LA includes NPoAs in many zones) or equal to a zone (LA = zone). I think we have to discuss further how the LA should be defined (complexity vs. scalability), but I do think that the concept is a valuable one and should be adopted. I also think that the two-step approach of first defining the functionalities for "pure" H.323 Mobility and only after that the functions needed for PLMN interworking may not be the best approach. I think that we need to consider the interworking case also when defining the pure H.323 case. This way we can take both cases into account, thus reducing unnecessary work in the second phase, i.e. the interworking phase. I'm not saying that we should define the interworking as a whole simultaneously with the pure H.323 mobility, but I would like to always consider the effects of our decisions to the interworking issue, when we are defining the pure H.323 case. Lastly, I read Ed's draft for Annex H and I just have one small comment. In the scope it says something about the fact that the NPoA can change. I think we agreed that it should have stated that the NPoA can change also during a call, thus allowing handovers. I would like to see this in there just to avoid having the same discussions again. I'm sorry that I didn't catch this one already in Red Bank. - Jaakko Sundquist ------------------------------------------------------- In a hole in the ground there lived a hobbit. Not a nasty, dirty, wet hole, filled with the ends of worms and an oozy smell, nor yet a dry, bare, sandy hole with nothing in it to sit down on or to eat: it was a hobbit-hole, and that means comfort. -------------------------------------------------------