H323 Mobility: About the work plan

Roy, Radhika R, ALARC rrroy at ATT.COM
Wed Nov 10 10:50:03 EST 1999


Hi, Jaakko and All:

Please see my reply provided below. I believe that we are in full agreement.

Best regards,
Radhika

> -----Original Message-----
> From: Jaakko Sundquist [SMTP:jaakko.sundquist at NOKIA.COM]
> Sent: Wednesday, November 10, 1999 9:54 AM
> To:   ITU-SG16 at MAILBAG.INTEL.COM
> Subject:      H323Mobility: About the work plan
>
> Hi Radhika & others,
>
> Radhika has sent several messages indicating that he would like to see
> complete mobility solutions from Nokia as well as others. We do not think
> that this is a good way to define the Annex H at this point. Furthermore,
> we
> think that this kind of approach is in conflict with what was agreed as
> the
> work plan in the Red Bank meeting. In our opinion we all agreed that the
> next step is to finish the functional requirements and define the
> functional
> architecture including the reference points and descriptions of the
> functional entities.
        [Roy, Radhika R]  I guess that we are talking about the same thing.
We are definitely defining the functional requirements as agreed in the Red
Bank meeting. When people do not understand a functional requirement from
conceptual point of view, the logical step is to see whether that functional
requirement is supported by a solution. That does not mean that we should
not include a function as "a place holder" to move forward because our final
goal is to find a solution. You are welcomed to bring your proposals
anytime.

> If we all were to present our complete solutions (which I really doubt
> that
> all interested parties would be prepared to do), it would lead to several
> very long contributions, say one from each of the following: AT&T,
> Motorola,
> Nokia, Ericsson, Siemens and Intel. Each of these contributions would
> probably be in excess to 50 pages and very probably there would be great
> differences between them. In order for us to be discussing the matter
> based
> on these contributions would require that everyone has fully analyzed each
> of the contributions in such a way that possible weaknesses and/or clear
> errors are found. This would require such an enormous workload that in
> practice it would not be done and we would end up arguing about the matter
> with quite limited knowledge of each other's ideas and in the end we would
> probably produce some kind of lame compromise full of errors that have to
> be
> corrected afterwards.
        [Roy, Radhika R]  Our final goal is to create standards to provide a
solution. Companies are taking pains to bring contributions to provide a
complete solution. We have no choice other than going through each proposal
with due respect. We have to find pros and cons for each contribution. Then,
we have to make a consensus decision based on technical merits.

> Now, this does not mean that we shouldn't present example cases
> (procedures)
> based on the proposed architectural models, etc. Our view is that this
> kind
> of examples are both illustrative and necessary for understanding how the
> system might work. However, we think that we do not need detailed message
> definitions or even all the message sequences at this phase, the general
> information flows are quite enough for examining the behavior of the
> proposed architectures. In fact, we think that the next logical step in
> the
> Annex H standardization process would be the definition of the information
> flows (i.e. what kind of information must be sent) between the functional
> entities. After this kind of analysis has been made, it is much easier to
> make the message and message field definitions (e.g. ASN.1) as well as the
> message sequences in a way that is acceptable by at least the most of us.
        [Roy, Radhika R]  Definitely, I agree with you. That is why we are
providing comments on your proposal. You are always welcomed to put forward
your proposals anytime you like unless you are not satisfied with all other
alternative proposals. If you think that more architectural examples are
needed to understand your points, please do so. Again, our final goal is to
create standards to find a solution.

> Nokia will present an architecture proposition in the near future,
> hopefully
> by the beginning of next week.
        [Roy, Radhika R]  Beautiful. In this way, we will be able to get
more insights for the problems for which all of us is looking for a
solution.

> - Jaakko Sundquist
> -------------------------------------------------------
>      In a hole in the ground there lived a hobbit.
>  Not a nasty, dirty, wet hole, filled with the ends of
>      worms and an oozy smell, nor yet a dry, bare,
> sandy hole with nothing in it to sit down on or to eat:
>      it was a hobbit-hole, and that means comfort.
> -------------------------------------------------------



More information about the sg16-avd mailing list