Hi Everyone,
I have to get any clear ideas for many issues especially when we talk about the things like "DIAMETER", clearing house, mobility, and other things not to speak about scalability of proposed solutions in the context large-scale networks (also be applicable for all packet networks conectionless and/or connection oriented in any combination).
So, any pre-conceived solutions based on some high-level statements are not good enough to build confidence that those solutions will provide the right solutions.
As a first step, my proposal is as follows:
1. Define the requirements for the clearing house function in the context of our overall solutions 2. What mobility problems we are going to address? There are many aspects of mobility problems: some of them may be related to the network, and may be independent of H.323, while others might have impact on H.323 especially for the GK when addressing, BW/QOS, and other functions are concerned. 3. What is "DIAMETER" ? I have seen few sentences in the last Cannes conf in the context of the H.323. It does not tell me anything. I scanned the IETF's contributions, and I am yet to understand how this is applicable in the context of inter-GK communications. A full contribution is supposed to be made before we understand what is the impact of this solution in the context of H.323. (My understandin is that it has taken a significant amount of time to go from "RADIUS" to "DIAMETER" by the IETF. Do we want to draw a conclusion by seeing a 2-page contribution and few minutes of conf call?) 4. The kind of architectural solutions that we might have to consider for inter-GK communications (it is not a trivial task).
I hope that we can minimize our confusions during the conference call if we can clarify the above things over emails or writing contributions between now and the next conf call so that all of us understand what we talking about.
Let us remember: if we create a standard, we have to do it RIGHT.
Thanks, Radhika R. Roy AT&T, USA (732) 949 8657 rrroy@att.com
From: Jim Toga[SMTP:jim.toga@INTEL.COM] Sent: Thursday, July 09, 1998 12:22 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Annex G Conference Call
Orit (and others),
If you've been around Intel much you know that when a meeting ends a certain time - it ends at exactly that time. |:-o Sorry about the abrupt cutoff, they gave us the 5min warning and then started the stop-watch.....
I agree entirely with the sentiments below. The only problem being solved at this point is the address resolution (broken record here...).
We should definitely move forward on a more general purpose solution to solve accounting/billing, resource usage etc... (which may someday be better than the simple message extentions that we're developing here).
At first blush, Diameter looks like it might have promise but it needs a number of things all of which will require more time than is reasonable to wait for inter-domain 323 address resolution.
- It needs a IETF WG home (currently an 'individual' contribution?)
- It needs further development for application extentions to enable all
of the services we described (and will come up with) 3) It needs to get on the standards track and move through it to RFC status.
I think we would all look forward to some concrete remarks on making the current syntax less vague.
With respect to NAI, that works well for DN related naming but what do we do about PSTN resolves?....(e.g calling to PSTN from IP)
At 11:34 AM 7/9/98 -0400, you wrote:
Hello again! What happened to the Conference Call? Was it my fault? Did I talk too much (sorry about that)? My last words were (I am not sure you could hear) there are two
things to do: 1. Intel's proposal can be adopted (as "an interim" solution for specific "address resolution" problem) , but in order to be interoperable and useful it should be, in my opinion, more tide: - less flexible syntax - defined push mechanism Jim, do you mind send to you some concrete remarks? What do you think about using NAI instead? 2. In parallel, I believe, we have start working towards the more complete solution, starting from the "architectural" definition and things that we want to accomplish "as far as we can see now".
Orit Levin RADVision Inc., 575 Corporate Drive - Suite 420 Mahwah, NJ 07430 Tel: 201-529-4300 (230) Fax: 201-529-3516
<<<<
*** +1-503-264-8816(voice) Intel - Hillsboro, OR.
*** mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 ***