standard.pictel.com is unavailable

Patrick Luthi patrickl at PICTEL.COM
Thu Sep 7 17:01:21 EDT 2000


Hi all,
Of course we can organize a telephone conference, but if we have to return
to proposals that did not receive support earlier, there should really be a
new, relevant, technical aspect or support from other companies that
justifies bringing them up again. So far a proposal was made to discuss Mr.
Roy's contributions once again on the conference call. Please send me and
Paul Reddy an email if you want to participate on the conference call.

We should not be hindered in our work, but should now proceed quickly with
constructive contributions over the reflector in order to enhance and
complete the Annex H for the November meeting. These should add to the areas
of Annex H not yet covered or point out problems. It is understandable that
huge contributions, especially if they rewrite much of the current Annex H
draft, will of course be much slower to review, difficult to understand and
_therefore_ much more likely to be rejected.

BTW: I also completely agree with all 4 points made by the Annex H Editor,
Mr. Jaakko Sundquist in his earlier message on this thread.

Best Regards
Markku Korpi
chair of H.323 Mobility adhoc group
Siemens Information and Communication Networks
----- Original Message -----
From: "Reddy, Paul K" <paul.k.reddy at INTEL.COM>
To: <ITU-SG16 at mailbag.cps.intel.com>
Sent: Thursday, September 07, 2000 7:20 PM
Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of Q.
13/1 6


> Hi Radhika,
>
> We as ITU-T SG16 Q13/Q14 group agreed on the H.323 Annex H Terms of
> Reference, which includes scope of H.323 Annex H. Now, you are proposing a
> different scope for H.323 Annex H on this reflector.
>
> I propose that we plan to have H.323 Mobility Adhoc group conference call
> discussion on your proposal instead of exchanging emails on this open
> reflector and come to some consensus on your proposal and then take a
> contribution to SG16 Q13/Q14 Rapporteurs meeting in Geneva. We as H.323
> Mobility Adhoc group choose Mr. Markku Korpi as Chairman of the Adhoc
group,
> I request  Mr. Korpi to setup a conference call to discuss your proposal.
>
> I am willing to sponsor the Conference Call Bridge, I propose that we can
> have conference call on Monday September 11, 2000 from 7:00 AM to 9:00 AM
> (Pacific Standard Time). Please let me know your availability all other
> members who wants to participate, so that I can make the Conference call
> bridge arrangements.
>
> regards,
> Paul
>
>
> Paul K. Reddy
> Intel Corporation
> Office Phone# +1 (503)-264-9896
> Mobile Phone# +1 (503)-807-9564
> Email: paul.k.reddy at intel.com
>
>
> -----Original Message-----
> From: Roy, Radhika R, ALCOO [mailto:rrroy at att.com]
> Sent: Thursday, September 07, 2000 7:38 AM
> To: ITU-SG16 at mailbag.cps.intel.com
> Subject: Re: H.323 Mobility: Enterprise vs. Mobile Carrier - Mandate of
> Q. 13/1 6
>
>
> Hi, Everyone (including all Rapporteurs and WP2 Chairman):
>
> Again, it speaks for itself as it has been mentioned earlier.
>
> As if, few folks want to create their own charter, push the boundaries of
> each question so that they are the ONLY people who can decide what need to
> be addressed in each question no matter what happens to other questions in
a
> given WP or SG or across the whole ITU-T.
>
> They are the people who are afraid of seeing the BIG picture of the ITU-T
> how one question relates to others to achieve a very narrow goal. Some of
> these people even participated in the joint meeting of SG16 and SG11 to
see
> how SG11 is addressing the HLF, VLF, AuF, etc. for mobility so that no
> duplicate work is done elsewhere. Now they are turning their back. Why?
>
> Is the norm of the ITU process?
>
> It appears that some people do not need address any technical points, as
if,
> they create their own mandate.
>
> It may create a good discussion in the upcoming SG16 meeting in the
plenary
> and general session.
>
> Again, the proposal for H.323 Annex H has been repeated as follows:
>
> 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.
>
> Let us focus on the charter and mandate of Q.13/16: This is item 1 only.
>
> Hope that the WP2 Chairman will have time to review the whole thing with
> true satisfaction in the light of all questions of all SGs within the ITU.
>
> Best regards,
> Radhika R. Roy
> AT&T
> rrroy at att.com
> +1 732 420 1580
>
> -----Original Message-----
> From: Jaakko Sundquist [mailto:jaakko.sundquist at nokia.com]
> Sent: Thursday, September 07, 2000 5:11 AM
> To: ITU-SG16 at MAILBAG.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 at INTEL.COM]
> > Sent: 07. September 2000 1:41
> > To: ITU-SG16 at 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 at intel.com
> >
> >
> >
> > -----Original Message-----
> > From: Roy, Radhika R, ALCOO [mailto:rrroy at ATT.COM]
> > Sent: Wednesday, September 06, 2000 9:33 AM
> > To: ITU-SG16 at 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 at NOKIA.COM]
> > Sent: Wednesday, September 06, 2000 8:08 AM
> > To: ITU-SG16 at 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 at nokia.com *
> > ------------------------------------------------
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv at mailbag.intel.com
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv at mailbag.intel.com
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv at mailbag.intel.com
> >
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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