[H.323 Mobility:] A new H.323 Annex H Draft

Jaakko Sundquist jaakko.sundquist at NOKIA.COM
Mon Jul 10 03:16:04 EDT 2000

Hi Radhika et al,

Let's try to start a bit of discussion...

> It is nice to see that you and Mr. Kumar had a communication
> related to GRQ
> and you have included in the contribution.

Yes, actually Mr. Kumar raised this point already in Osaka, but it seems to
have been kind of lost in the conversations. At least I did not quite grasp
this issue at that time. It does seem a perfectly valid point though (if
someone has a counter-argument, please inform us).

> I wonder what happened to the emails that I sent to the SG16
> email "public"
> reflector related to MGA message! I have not seen any counter
> arguments
> related to this in the email reflector. I like to see that
> MGA message is
> also included (with both unicast and multicast option as suit the
> implementation).

Your emails did arrive, or at least I saw them. The reflector seems to have
been quite quiet recently, perhaps some people are having their holidays (I
did, before I had time to comment on your emails).
As for the MGA issue. I think we had a quite good discussion on that in
Osaka and it seemed to me that really no one  else was in favor of the idea.
Most people, including myself, came to the conclusion that the MGA scheme
would be less efficient instead of being more efficient than multicasting
GRQs. Thus far I haven't seen anything that would convince me otherwise (I
don't remember exactly, what you said in your last email about the MGA, but
I did read it and did not find any new arguments in favor of the MGA).
Furthermore, I think that having two alternate multicasting schemes for
gatekeeper discovery would only lead to difficulties both in making an
explicit and robust annex as well as in implementation of the mobile H.323
system described in the annex.

> I would also appreciate that you should start discussing in the email
> reflector before any further update is made in the document
> so that we can
> participate in the process for updating the document. The
> discussion can be
> formulated as follows:
> 1. What you want to propose and why
> 2. Pros and cons of the proposals
> 3. Invite comments from the members
> 4. Update the document based on item 3

As you mentioned, I have tried to do steps 1 and 2 in the emails I have sent
to the reflector. The idea behind this approach of me sending a draft (or
editor's draft, if you will) every once in a while is step 3. By sending a
whole new draft, I'm trying to force people to react to the changes. Step 4
will naturally be done after the discussions about the changes.
You said that you will produce your comments on the new draft soon, good,
that is precisely want I wanted (step 3). I hope others will do the same.


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

More information about the sg16-avd mailing list