Hi, Jaakko:
Thanks for providing your thoughts known to all of us. I appreciate this
because you taken a step to make a progress assuming that this will help
us. I have no problems to work in this fashion if everyone agrees with this
process.
The only thing that I have to do is to bring contributions with reference to
the draft that you have provided. I can say clearly where things to be
added, modified, and/or deleted. You can also include texts from the
contributions showing agreement (and differences with editor's notes) in the
Rapporteur contribution.
I completely agree with you that we need to make a rapid progress. If
everyone agrees with the process that you have taken, I will bring
contributions accordingly so that you can clearly see where things (what
text, figures, etc.) need to be added, modified, and/or deleted.
Best regards,
Radhika R. Roy
> -----Original Message-----
> From: Jaakko Sundquist [SMTP:jaakko.sundquist@nokia.com]
> Sent: Tuesday, May 09, 2000 8:10 AM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: [H.323 Mobility:] A new editor's draft H.323 Annex H
>
> 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(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
