Hi Radhika,

Find my comments embedded...

I hope that you have been enjoying the ice-hockey....

Yes, it was most enjoyable. Finland won 7-4.

I understand that the editor's draft is just a contribution for the upcoming tomorrow's conf call, not a draft for the Osaka meeting.

It is not yet the draft for the Osaka meeting. However, since the meeting is already in next week, I will not make too many changes to it.

I do not know which parts of your draft have been taken from the contributions that had been discussed and agreed. I have seen no reference to it. Or, have you made some educative guess from your side?

If you remember, we had a discussion about the way we will continue the Annex H work in the last teleconference. Since we have achieved almost nothing since the Geneva meeting I thought it would be a better idea if I produced a draft of the annex including my thoughts (of course taking into consideration the discussions that we have had) of how it should look like and you as well as anyone else could make your contributions against that. This idea also seemed to gain some support.

Let me explain.

You have two roles to play: First as an editor to reflect what has been agreed upon by the members based on contributions. Second, an individual from Nokia to agree or disagree.

An editor must provide the draft that will reflect what has been agreed by the members based on contributions. However, as an individual from a company an editor may have differences. These differences can be reflected in the draft in two ways: 1. As an editor's note and 2. Even as an individual from Nokia (assuming that subsequent contributions will clarify this).

Quote from the first page of the draft: "NOTE: None of the changes, that are made to this document after the previous acceptance of changes (i.e. all changes that are highlighted when the MS-Word highlight changes option is on), are accepted by the members of the mobility ad hoc group."

As I said above, I'm hoping that this kind of working method of me producing the draft annex and all of you making your contributions against that will make our progress faster. Unfortunately I was not able to bring the draft forward any earlier, which of course makes it harder (if not impossible) for you to make your contributions for the Osaka meeting against the draft directly. However, I do think that we can work in Osaka in a more systematic manner and perhaps even have some results.

Section 4:

I guess that you have one contribution showing these figures 2 through 7 (there is no reference - I see a similarity- am I correct?). We never discussed this contribution in any conference call. How come that you have included all figures from your contribution that has not been discussed and agreed?

These figures are the same as in my contribution MTD-011b, which was not discussed in the teleconference because of lack of time. MTD-011b was based on the earlier contribution MTD-011 and the discussions we had about it in the first teleconference after the Geneva meeting. I thought that it is very important that we clearly explain what is meant by a scenario and what kind of scenarios we might consider in the H.323 mobility work.

In fact, we discussed about your earlier contribution where we have agreed that we will start from all H.323 scenarios: First, intra-zone, inter-zone, and inter-domain scenarios.

This is exactly why the figures are there. They explain what is really meant by the all-H.323 scenario (and of course the other scenarios as well). I have also added a statement to the scope stating that we will initately focus on the all-H.323 scdenario. Furthermore, the concept of the scenario was (nor is) supposed to include any reference to Intra-zone, Inter-zone or Inter-domain (this is actually the reason, why I thought that the MTD-011 needed to be re-written, it lead to a confusion about the meaning of scenario), so I see that it really is necessary to clearly explain the scenario concept in order to avoid this kind of misunderstandings.

For inter-working between H.323 and non-mobile scenarios, there are many possible scenarios and we may not address in this document for now for the sake of time. So far I re-collect, this has been the decision. Section 4 does NOT reflect this.

Again, see the scope.

Section 7:

I like to see that there should be an editor's note that "Figure 8 will be revisited based on the extensions that will be made in H.323 to support mobility. This is just a place holder to provide references for the on-going discussion."

Of course the architecture figure can and probably will be refined as we continue the work. (I believe that at least Intel is going to propose some changes to it in Osaka). I do not think we need to put in any comments saying that. Furthermore, could you explain what you mean by saying that the figure is just a placeholder for the ongoing discussions? I regard this kind of an architectural figure as an integral part of this kind of specification.

Section 8:

Which contributions your are referring here that we have agreed? I would request that people MUST bring contributions to define virtual home and service execution environment before an editor put any texts in it.

I do not think that chapter 8 is even nearly complete, but since we have had quite a lot of discussion going on around the concept of Virtual Home Environment (especially with Ericsson), I wanted to add something that would explain the difference between these two distinct concepts. I would really appreciate, if someone would bring in contributions to refine this chapter.

Did you submit an outline of your draft to be approved?

No, for the reasons stated in the beginning of this message. Furthermore, I do not think that I have changed very much of the outline that has been agreed. You can, of course, suggest a different kind of outline.

Section 9:

Which contributions you are referring to?

I have tried to gather the issues that I think we have more or less agreed on in our discussions with regards to this chapter. I have made some new names for certain concepts and for some parts I have made my own suggestions (mainly the information flows). I have not taken any of the contributions as a basis for this chapter, because we haven't agreed on very large parts of any contribution.

Did you have any outlines for this section that need to be approved?

My understanding has been that we agreed that the mobility management will include: A. Intra-Zone, B. Inter-Zone, and C. Inter-Domain.

In each case it will have the following:

1.  GK discovery
   

2.  Registration
   

3.  Location update
   

4.  Call establishment
   

I think this is exactly what I have done. The problem with the terms Intra-zone, Inter-zone and Inter-domain is that I do not know what you exactly mean by them. In the previous H.323 standards the division has been easy, because there is always a call involved and the division is made based on the relative locations of the participants of the call. In Annex H, however, it is often needed to contact e.g. different domains even though the call might actually be an Intra-zone call. I have introduced the ideas of Location updating procedures and related to that the Intra/Inter-zone/domain location changes as well as Call related MM procedures that can be divided into Intra(Inter-zone/domain call cases to clarify the categorization.

AT&T and Alctel contributions are there and these contributions were discussed. The outlines should follow these procedures to follow the text consistently.

These contributions were discussed, but I do not remember having an agreement on almost anything in those contributions. The only thing we almost agreed on in the AT&T contribution was the figure illustrating the zone, its relation to the funtional entities and the NPoAs. This figure has been used as a "model" for the figures 10 - 13 in the draft annex.

Section 9.1.1:

Like home domain, AT&T contribution has provided the detail description of home GK/zone from a user point. Accordingly, home network address (network point attachment) has been explained. In a given zone, a mobile may move from one NpoA to another. Like foreign (or visited/visiting/target) domain, AT&T contribution has also explained the foreign (or visited/visiting/target) network address (or NpoA). The subsequent emails have also been sent explaining the things.

With regards to the home GK, I am considering that it may be a good concept to introduce for some purposes (mainly because of GK discovery issues and the Virtual Home Environment concept), but I have not yet introduced in the draft, because I want to have a clearer picture of how the concept would be used. I certainly do not like the idea of always having to contact the home GK in order to be able to use the H.323 services, nor do I like having to contact the HLF through the (home) GK. In other words I am willing to add the concept as soon as we have agreed on the semantics of it. I still do not see the merit of the home NPoA concept, I do not think it adds anything that could not be achieved by using e.g. mobile IP.

I would expect, like visiting/visited domain, the concept of visiting/visited/target network address should be taken as a part of it. Without this, the mobility management will almost be MEANINGLESS because the trivial mobility management keeping some addresses in a database like VLFs/HLFs do not help the service providers and the mobility management through re-registration is already there in H.323, and no new standard work is needed for extending the so called VLFs and HLFs databases.

I do not think it is meaningless to define an organized way of keeping track of the Users' location in the network. That in my opinion is NOT present in H.323. It does not mean that these mobility management features have to be overly complicated, in fact I would prefer as simple (or trivial) solution as possible. If and when we get this trivial issue settled we can perhaps add more features to the Mobility Management.

Figure 11 shows that the inter-zone mobility management is maintained using the single HLF. Which contributions you are referring to? Did we agree on this concept? AT&T contribution shows that it is an unacceptable proposition if we consider that there is a single HLF (as the protocol is "hard-wired" for a centralized HLF configuration)?

As I have stated in some earlier emails to the list, I do think that it is necessary to regard that only one logical HLF holds the location information of a particular User. This database could be distributed in some way unknown to the H.323 system and we could even define a method for enabling the HLF to have multiple network addresses (i.e. multiple "locations" in the network where it could be accessed), but I do not think that we should try to define a way to distribute the HLF database in the network (and that I think is what you are suggesting by having multple alternative HLFs for a User).

Figure 12 shows that a single VLF is communicating with multiple HLFs. Which contributions do you refer to?

I have always assumed this as a possibility, but you are right, it has not been exactly stated in any contribution before, so I guess I am contributing it now. It is of course possible to have the VLF only be in contact with one HLF, if that is what we want.

Figure 13 shows that HLFs are communicating between the domains? Did you not see that we are NOT in sink with this approach because the questions have been raised that this approach might be "breaking" the H.323 standard? AT&T has also provided contributions regarding this (I guess that Alcatel's contribution also agrees with AT&T's contribution in this regard).

When the Hinter reference point was added to the architecture figure, I thought that we made the assumption that Inter-domain communications between the VLFs and HLFs are possible. If we want to remove that possibility, I'm more than happy to agree. In fact I remember even making a contribution (sometime in the autumn) suggesting that BEs are used in the Inter-domain communications.

Are you "pushing" for some something (or am I missing something)? If it is so, please bring contributions, we will be pleased to discuss.

As stated earlier, I'm just trying to make some progress.

Section 9.2:

Use of GRQ messages for the GK discovery is NOT new in H.323. It is already a standard. A reference to the existing H.323 standard is enough.

Section 9.2 does include more than just saying that GRQs are used.

However, the fundamental question has been that GRQ messages are NOT efficient for the GK discovery in the cellular environment. AT&T contributions have provided an alternative solution using the MGA message for the GK discovery.

So, the use of GRQ messages are INEFFICIENT for the GK discovery. So, it is NOT acceptable in the highly mobile environment.

Actually, personally I quite like your idea of the MGA message (or something similar), but it seemed to create quite a lot of opposition, when we discussed it over the phone (I think there were claims that in fact the MGA would NOT be a more efficient method), so I did not add it. This is something that I think we need to discuss in Osaka.

Section 9.5:

Again, I like to know which contributions you are referring to?

Figures 15, 16, 17, 18, and 19 show that, as if, the protocol is "hard-wired" for the centralized HLF configuration. AT&T contributions do not assume this. We have NOT accepted this notion.

I admit that these information flows are based on my own thoughts and I am not assuming that the whole group agrees to those without any discussion. So, you should make your contributions against the ones I have added (which you have already done, but we haven't yet had enough time to discuss them).

So, the basic question: Why do you want to include the material where there are no contributions and no agreement?

As said, to fasten our work...

There are fundamental flows the way you have shown all information flows. Let me cite few examples:

You have shown that LRQ messages are sent from the GK to the VLF and/or HLF. Why do you think so? Did you not see that we have NOT even agreed with this in the last conference call and via emails? AT&T contributions have used NEW mobility management messages.

I really did not assume that the "Location_req" imaginary message would be confused with the LRQ, but apparently I need to make that more clear. In other words the Location_req is not the same as LRQ.

Considering the comments provided above, all texts provided in your contribution need a COMPLETE re-writing of the document.

I'm sure there is a lot to be done, but at least now we have some clearer ground for our discussions in Osaka.

I understand the difficulty with the job as an editor. I appreciate your efforts. However, there are some norms that an editor has to follow: Contributions and Agreement made. If editors have their opinions, they can bring separate company contributions (NOT as Rapporteur contributions).

I think I understand what the job of the editor is. I'm just trying to direct our work so that in some reasonable amount of time we might actually achieve something. If you ask me, we (as the unofficial mobility ad hoc group) have not agreed on ANYTHING since the Geneva that could be put to the annex. I also have received some feedback from other members of the group suggesting this kind of a work method and I thought it might be a better way to go forward than the way we have previously worked.

Hope to discuss the same in tomorrow's conf call.

I am also curious to know which the team won the ice-hockey.....

The Hentunen-Kapanen-Lind attacking line was quite superb...

- Jaakko

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com