Hi, Jaakko:

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

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.

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?

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).

I do not have enough time to provide all comments in writing. In brief, I have the following comments:

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?

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.

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.

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."

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.

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

Section 9:

Which contributions you are referring to?

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

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

Now I am providing comments per sections that you have arranged although I do not agree with the outlines.

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.

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.

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)?

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

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).

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

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.

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.

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.

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

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.

We have serious problems if we use LRQ messages like this. That is why, AT&T has provided a contribution APC-1769.

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

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).

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

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

Best regards,

Radhika R. Roy AT&T +1 732 420 1580 rrroy@att.com

-----Original Message----- From: Jaakko Sundquist [SMTP:jaakko.sundquist@NOKIA.COM] Sent: Monday, May 08, 2000 8:27 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: [H.323 Mobility:] A new editor's draft H.323 Annex H

Hi all,

I have uploaded the new editor's draft H.323 Annex H to the URL: ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/

I suggest that we go through the changes I have made in tomorrow's teleconference.

I'm sorry that I haven't responded to any messages recently, but working with the draft took a bit more of my time than I expected, so I simply haven't had the time. I will try to read all the messages through tomorrow and hopefully answer to some.

And now I'm off to watch Finland demolish the poor Norwegians in the ice-hockey world championships...

---

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