So I managed to send this to the list anyways, although I only meant it for
Mr. Reddy. Sorry for the quite pointless mails...
-Jaakko
> -----Original Message-----
> From: EXT Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM]
> Sent: 07. September 2000 12:11
> To: ITU-SG16(a)mailbag.cps.intel.com
> Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier -
> Mandate of
> Q. 13/1 6
>
>
> I guess you mean that you agree with all 4 points, not just the fourth
> point, right (i.e. I guess there's a typo)?
>
> -Jaakko
>
> p.s. I didn't want to send this to the list...
>
> > -----Original Message-----
> > From: EXT Reddy, Paul K [mailto:paul.k.reddy@INTEL.COM]
> > Sent: 07. September 2000 1:41
> > To: ITU-SG16(a)mailbag.cps.intel.com
> > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier -
> > Mandate of
> > Q. 13/1 6
> >
> >
> > Hi Everyone,
> >
> > I agree with Mr. Jaakko Sundquist, Editor of H.323 Annex H,
> > who made 4 point in this email.
> >
> > regards,
> > Paul Reddy
> > Editor of H.246 Annex E.1, Annex E.2
> >
> > Paul K. Reddy
> > Roaming Services Capability Manager
> > Mobile Data Services Area of Opportunity
> > Applications and Services Lab
> > Intel's Architecture Labs
> > Intel Corporation
> > Office Phone# +1 (503)-264-9896
> > Mobile Phone# +1 (503)-807-9564
> > Email: paul.k.reddy(a)intel.com
> >
> >
> >
> > -----Original Message-----
> > From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM]
> > Sent: Wednesday, September 06, 2000 9:33 AM
> > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier -
> > Mandate of
> > Q. 13/1 6
> >
> >
> > Hi, Everyone (including all Rapporteurs and WP 2 Chairman):
> >
> > Again, it is interesting to see how a very narrow view can
> > create serious
> > problems not only for a simple Annex, but also for the whole
> > question, for
> > the whole study group, and for all other study groups of the ITU-T.
> >
> > Time and again, it has been said that let us work within the
> > mandate of
> > Q.13/16 first and contributions had been made to clarify
> those points.
> > Everything has been ignored just because few folks want to do
> > something
> > almost working like a close group without seeing the BIG
> > picture of all
> > questions of all SGs of the ITU-T. In fact, some joint
> > meetings were also
> > initiated between SG16 and SG11 to see how the HLFs, VLFs,
> > and AuFs related
> > protocols are being addressed elsewhere.
> >
> > Still, they are pushing the same thing just because few folks
> > brought some
> > contributions. Objections were put via contributions, emails,
> > and verbal
> > discussions. Even there is not a single editorial note in
> the document
> > related to those things.
> >
> > A simple example will reveal the fact. We have discussed that
> > there are
> > serious problems to use GRQ messages to discover the GKs in mobile
> > environment. Many contributions, emails, and verbal
> > explanations have been
> > provided. If you look into the present H.323 Annex H
> > write-up, you will see
> > that, as if, GRQ is the "Nirvana" for discovering the GK in mobile
> > environment. Not a single word has been used even as an
> editorial note
> > whether some members have raised the questions that there are
> > problems need
> > to be addressed for GRQs. The way the GRQ section has been
> > written, it is a
> > generic one and is nothing do with mobility. Rather, it suits
> > to be added in
> > the base H.323 spec. Many more examples can be given for each
> > technical
> > issue.
> >
> > This Annex has NOT done its first important task how to
> > extend the H.323
> > signaling messages (RAS, Q.931, Annex G) to solve the
> > mobility problems for
> > the H.323 entities (Terminals, GKs, BEs, GWs). In fact, it is
> > the mandate of
> > Q.13/16. Contributions are there, but everything has been ignored.
> >
> > Rather, Annex H has focused in some areas for which it has
> NOT got the
> > mandate: Communications between VLFs <-> HLFs, VLFs <-> AuFs,
> > HLF <-> AuFs,
> > etc. These work items are not the charter of Q.13./16 alone.
> > These are the
> > areas for the joint work with all other questions of all SGs
> > that deal with
> > mobility. (In another example, even if H.320, H.321, or H.324
> > wants to be
> > used by mobile users, they can also use HLFs, VLFs, AuFs,
> > etc. Similarly,
> > all other mobile applications of all other SGs can also use
> > these HLFs,
> > VLFs, AuFs, etc. Take the case of AuF, it can also be used by
> > the fixed
> > user. There is nothing fency about this.)
> >
> > (More importantly, these additional entities have raised
> > serious concerns:
> > How does a GK/BE play a role in the overall process while
> > "wild" suggestions
> > have been made to use the Annex G protocol as well? It has created a
> > "dangerous" mechanism to "by-pass" the very need of GKs/BEs.
> > In fact, some
> > members have boasted that they even do not see any need to go
> > via GKs or BEs
> > anymore so far mobility is concerned. As if, a "bomb " is
> > about to be placed
> > to break the very foundation of H.323 in the name of
> > extending of H.323 for
> > mobility.)
> >
> > More can be written for each technical issue, if needed. If
> > one likes to see
> > some of those points, please see the contributions that were
> > submitted in
> > the last Q.13/16 Portland meeting.
> >
> > Again, I am repeating the proposal for H.323 Annex H:
> >
> > 1. First, finish the extension of the existing H.323 base
> > specs, and H.225.0
> > (RAS, Q.931, Annex G)to support mobility among the H.323 entities:
> > Terminals, GKs, BEs, and GWs. (see the contributions that are
> > being made so
> > far).
> >
> > 2. Second, develop a clear mandate whether the backend
> > protocols like VLF
> > <-> HLF, VLF <-> AuF, HLF <-> AuF, etc. are the charter of
> > Q.13/16 only, or
> > these protocols need to be worked with other SGs. (see the
> > contributions
> > that are being made so far).
> >
> > 3. Third, any protocols that re being used between VLF <->
> > HLF, VLF <-> AuF,
> > HLF <-> AuF, etc. MUST not be termed as H.225.0 Annex G or
> > its extension
> > because these are separate protocols and serve completely
> > different purposes
> > although may useful properties (e.g., hopcount, etc.) of the Annex G
> > protocol can be used for these protocols.
> >
> > It is very important to note that only item 1 is within the
> charter of
> > Q.13/16 (H.323). All other items need to be addressed in the
> > light of all
> > mobility works of all questions of all SGs of the ITU by the
> > working party
> > chair and others.
> >
> > (My personal view is this: Let H.323 Annex H be scoped for
> > item 1 only for
> > now as a first step. It will also take a good amount of time
> > to finish it.
> > People are waiting to see that this happens first.
> >
> > To include other items, it may take a long time to have
> > stable texts working
> > with all SGs. This will then constitue the second step.)
> >
> > Best regards,
> > Radhika R. Roy
> > AT&T
> >
> > -----Original Message-----
> > From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM]
> > Sent: Wednesday, September 06, 2000 8:08 AM
> > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier -
> > Mandate of
> > Q. 13/1 6
> >
> >
> > Mr. Roy & other parties interested in H.323 Annex H,
> >
> > I found your posting addressing such general level issues
> > that I think it is
> > better to write a whole new mail as a response instead of
> > responding to your
> > claims and comments point by point...
> >
> > First of all you question the mandate of Annex H and its
> > relation to the
> > H.323 protocols. I find it very odd that you, without any
> > real arguments to
> > support for it, restrict the H.323 recommendations and thus
> > also Annex H to
> > handle ONLY the H.323 entities that have been defined prior
> > to Annex H. The
> > first real work that we got done for Annex H was to identify the
> > functionalities that were (are) needed for Mobility
> > Management and that were
> > missing from H.323. This is how we (in an ad hoc meeting in
> > Red Bank, in
> > which you yourself was also present) came up with the four new H.323
> > (functional) entities: HLF, VLF, AuF and IWF. Thus we have
> > defined NEW H.323
> > entities that were NOT present prior to Annex H. If it is
> > illegal for us to
> > define new H.323 entities (as you seem to claim), I can't see
> > how the Border
> > Element ever got defined, since it was not defined prior to
> > the H.225 Annex
> > G.
> >
> > Second, you seem to have defined the HLF, VLF and AuF as
> > back-end services.
> > This is NOT how I see them. I see back-end services as
> > services that are NOT
> > defined in the H.323 series recommendations, but that may be used by
> > gatekeepers. In other words, back-end services or the
> > functionalities they
> > provide do NOT have any real definition in H.323, nor is it
> illegal to
> > define new entities to H.323 that provide same kind of
> > functionalities that
> > could be achieved by using some back-end service. The
> > back-end services that
> > are used in some implementations of the H.323 system can
> > undoubtedly be used
> > for similar purposes as the new functional entities of Annex
> > H are, but this
> > does not make the new entities back-end services.
> > Furthermore, the whole
> > point (or mandate) of Annex H is to make recommendations that
> > allow for
> > different manufacturer's equipment to be used in different
> > parts of the
> > (mobility enhanced) H.323 system and still allow the
> > users/terminals to move
> > around in the network. Thus, in my opinion, it is one of the
> > most important
> > issues of Annex H to define, how the HLF, VLF and AuF
> > communicate with each
> > other. By just stating that they are back-end services we
> > would in essence
> > NOT define this, since back-end services are NOT defined in H.323.
> >
> > Third, the protocol(s) that are used between the HLF, VLF and
> > AuF are still
> > and open issue. The reason, why the H.225 Annex G protocol is
> > used in the
> > present draft is that it is the only protocol that has been
> seriously
> > mentioned for this purpose. (Not only by the editor, but in various
> > contributions as well, although the editor takes full
> > responsibility of the
> > current text in the draft.) It has been identified that the
> > H.225 Annex H
> > protocol already has the functionality for locating a User
> > with a certain
> > aliasAddress. Really roughly said, this functionality is
> "half" of the
> > functionality that is needed for Mobility Management, the
> > other half being
> > the location updating procedures (which are not really
> > addressed by the
> > protocol yet). This is why the protocol is being considered
> > for the Annex H
> > usage. However, I would really like to see contributions
> > suggesting other
> > (preferably existing) protocols as well. Intel's contribution
> > APC-1902, was
> > the first one of this kind. These contributions should,
> however, state
> > clearly how the suggested protocols should be used, if there is any
> > ambiguity. I.e. just stating: "Use Mobile IP" is not enough
> > (I'm not trying
> > to refer to the APC-1902 with this comment), but information
> > flows for the
> > needed Mobility Management procedures should be presented
> > (these include at
> > least the location updating procedures, call establishment
> > procedures, call
> > termination procedures and unregistration procedures).
> >
> > Fourth, the needed enhancements of the RAS, Q.931, etc.
> > protocols will be
> > provided by finishing the information flows on chapter 10. I
> > admit that not
> > much of this has yet been done, but on the other hand, at
> > least so far I
> > have found that there is not too much that has to be done
> > with respect to
> > these protocols. (There will probably be certain message
> > fields that will be
> > mandatory for Mobile Terminals that are optional in H.323
> > normally, etc.,
> > but I don't see a need for too many new message fields or messages.)
> >
> > Last, but not least, we a really in a hurry, if we want to
> > get the Annex H
> > determined in November. This is why I suggest that the
> > interested parties
> > provide the contributions describing the usage of other
> > protocols as the
> > Mobility Management protocols of Annex H as soon as possible.
> > Also it would
> > be very nice, if these contributions were made modeling the
> > chapter 10 of
> > the current draft, so that incorporating them to the annex
> > would be as fast
> > as possible.
> >
> > I'm still a bit in the middle of the process of digesting the
> > information I
> > have gotten about the Annex H work in Portland, but I'll try
> > to send a mail
> > summarizing (what I think is) our current situation later this week
> > (probably on Friday). I will also make a "cleaner" version of
> > the TD-42a as
> > the "starting point" for our interim work before Geneva (this
> > new draft will
> > not contain any other than editorial changes compared to TD-42a).
> >
> > ------------------------------------------------
> > Jaakko Sundquist *
> > +358 50 3598281 * Audere est Facere!
> > jaakko.sundquist(a)nokia.com *
> > ------------------------------------------------
> >
> >
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 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
> >
> >
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 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
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
