Dear Mr. Roy,
I would like to respectively respond to a number of your points but before I do, I'd like to make a few general comments.
1) In general, I agree with many of the concepts and directions that you endorse - I see these has helping the long-term market as a whole. Although I have to admit I'm somewhat perplexed at your logic and explanations in other points.
2) There is a clear, immediate, and pressing market need for a standards based solution to allow Gatekeepers to communicate between each other in standard fashion. If this work is not completed in the ITU-T in a timely manner - it might be completed either by vendors independently, thus fragmenting the market, or as a defacto-standard set by a group of vendors. My personal preference is to have an open and contributory ITU-T based process, for the solution.
3) I fail to understand the methodology by which you contribute to this work. You have on occasion, offered critizisms and vague alternatives to the ongoing work without any tangible technical issues. Vague statements about "contributions from AT&T to be released...in the September ITU-T meeting" do not progress this work in a timely or cooperative fashion. For example, I would be interested to hear what specific aspects of Diameter you see as appropriate or inappropriate to the issues at hand.
I have made interspersed comments to support and question your text below.
Best Regards, jimt.
at At 01:35 PM 8/5/98 -0400, you wrote:
Hi Everyone:
We are in receipt of the revised Annex-G sent by Glenn Freundlich via email. It appears that the present Annex G write-up and email are yet to reflect the true essence that had been discussed in the conference calls as well as communicated via emails (copies of the emails including Santo Wiryamen's are also enclosed). The specific points are mentioned below:
The modified title of Annex G is very restrictive, and is NOTacceptable. The title of the Annex G should remain as it was before - "Gatekeeper-to-Gatekeeper Communications". (The communication between administrative domain will only be one of the customized scenarios for communications between the gatekeepers. It is a complete surprise to see such a major change has been made all on a sudden).
Although I disagree that it is "very restrictive", I do agree that the Annex should remain titled as it formally was. My undstanding that this change was agreed to in Cannes but simply hadn't been completed by the editor (GlenF).
This is separate from the point that the _first issue_ being solved is 'Communications _between_ Administrative Domains'. Perhaps we can all wait for the upcoming contribution from ATT on 'Communications _within_ Administrative Domains' and until that time it is for further study.
Section 1.1 (Scope). The scope of Annex G should be"Inter-gatekeeper communications that will include inter-gatekeeper communications within a given domain as well as communications between the (administrative) domains". (So, the present objective that restricts for dealing communications between the administrative domains only is NOT acceptable).
We have had numerous (lengthy, repetitive) discussions on this terminology. The intent was to not overlap or otherwise confuse IP 'Domains' with the terms here; they are different. (although a specific implementation may choose to make the them equivilent). Inter-gatekeeper communications is just that - communications that occurs between gatekeepers. There are no implications as to the applicability of any protocol in one environment over another. This is not to say that specific protocol elements won't be enhanced over time, as deficiencies are discovered with practical experience.
The point behind your (Roy) last issue (limiting it to inter-administrative domains) was that the annex would not _start out_ by mandating what protocol a vendor/service supplier/administrator uses in the privacy of their own network. This is not to say that they can't use the standard protocol.
Section 1.1 (Scope). It has been mentioned that "It should also beunderstood that Annex G does not mandate a specific system architecture within an administrative domain". This should NOT be a mandatory in the standard. Rather, we can keep this as an option depending on the choice of the implementation schemes. That is, the standard MUST provide all the options to reveal about the protocols, organization or architecture within a given administrative domain leaving no room for proprietary implementations schemes.
I really don't understand what you're saying here. Are you stating that we must mandate a particular architecture within an administrative domain (enterprise)? Or are you saying that we provide an exhaustive list of all the possible architecutures. Are vendors supposed going to be in violation of the _protocol_ if they don't arrange their internal network to match one of the pictures?
I will reiterate from the Cannes meeting report (APC-1425)
" Mr. Roy's position is that the architecture inside the domain should be known outside the domain. He was encouraged to bring in a contribution explaining how the lack of knowledge of the intra-domain architecture would affect services or other technical matters."
I believe you were the only one that held this position.
In view of the above limitations of the present Annex G write-up (Title and Section 1.1), the following have been proposed:
The title of Annex G should remain as it was before: "Annex G -Gatekeeper-to-Gatekeeper Communications."
Agreed.
Scope of Annex G should be divided into two parts: A.Inter-Gatekeeper Communications Within a Domain, and B. Inter-Gatekeeper Communications Between Domains.
Agreed, as long as we change 'Domain' to 'Administrative Domain'
A domain has to be defined further. For example, a domain mayconsist of multiple zones.
There are currently a number of zones running within Intel's _administrative_ domain (sec 1.2 in Annex G) . Can you explain why this needs to be defined further?
Inter-gatekeeper communications between the multiple zones of agiven domain has to be standardized as it has been outlined in Santo Wiryamen's email and APC-1385 (more contributions from AT&T [to be released after internal review in the Spetember'98 ITU-T SG 16 meeting] for inter-gatekeeper communications in a given domain that will use non-hierarchical model will be submitted. All other companies are also encouraged to submit contributions in this area. Annex G will be expanded as soon as those contributions are received).
There have been a number of contributions in this area (APCs 1382, 1385, 1402, 1407, 1414, 1422, TD-14 and many emails on this list) by many interested participants. These have all been with the goal of reaching stable text for September.
A single administrator will also be able to create multiple domainsfor its own internal communications for scalability or other purposes for the large H.323 network. Then, this communication between such domains is known as "Inter-Gatekeeper Communications Between Domains".
We have not defined an 'internal' domain (other than one that completely overlaps with the same characteristics in the IP world) so I don't know that this is. I certainly agree that administrators will want to (under some cases) carve up and distribute communications/operations within their network. We should facilitate that with a protocol - but I fail to see how anything that has been proposed/discussed precludes this. As an example, the fact that NAT firewalls exist doesn't mean that everyone _must_ use private addressing within their corporation. Nor does it mean that they _must_ use public addressing. In either case it does not affect communications or functionality between corporations.
If a domain belongs to a single administrator, and communicationsbetween such administrative domains need to happen, then the communication between such administrative domains is termed as "Inter-Gatekeeper Communications Between Administrative Domains".
Yes, and this is the first and most pressing issue to solve.
The inter-gatekeeper communications between (administrative) domainscan also be non-hierarchical, hierarchical, and hybrid (non-hierarchical + hierarchical). However, present contributions have been provided only for hierarchical models, and non-hierarchical and hybrid models will be addressed as soon as contributions will be received in these areas.
You have stated this before, and it has been refuted (both on email and on the phone calls). Please present a specific example in which the message information cannot be exchange to cover this model. I maybe dense, but I don't understand what a 'hybrid' gatekeeper communications is. I would hope that the communications are the same; the difference is that the flow is either lateral (peer-peer, non-hierachical) or vertical (parent-child, hierachical) at any particular point.
Specific comments related to Section 1.2:
Definitions for "H.323 network", "zone" and "domain" should also beincluded (in addition to "Administrative Domain" and "Border Element").
'H.323 network' - is not used anywhere.... (IP network?) Zone - is defined in the H.323 document Domain - see above comments ( your comments to sec 1.2)
Specific comments related to Section 1.3:
The title of this section should be changed to "HierarchicalInter-Gatekeeper Communications Between Administrative Domains". The write-up should be modified to take into account all the comments given above.
Specific comments related to Sections 1.5, 1.5.1, 1.5.2, 1.5.2.1-1.5.2.7:
These sections are general enough to be used in the context of azone. In fact, it is a very good one. These items are very useful for communications between the zones within a given domain. AT&T contribution that is expected be submitted (yet to obtain clearance) may also propose to use these message sets for inter-zone communications in a given domain.
In view of the above comments, it is proposed that the outline of Annex G should be modified as follows:
- Annex G - Gatekeeper-to-Gatekeeper Communications
1.1 Scope 1.2 Definitions 1.3 Inter-Gatekeeper Communications Within a Given Domains 1.3.1 Requirements 1.3.1 Non-Hierarchical (Distributive) 1.3.2 Hierarchical (Centralized) 1.3.3 Hybrid (Non-Hierarchical + Hierarchical) 1.4 Inter-Gatekeeper Communications Between (Administrative) Domains 1.4.1 Requirements 1.4.1 Non-Hierarchical 1.4.2 Hierarchical* 1.4.3 Hybrid (Non-Hierarchical + Hierarchical) 1.5 References 1.6 Protocols
(* The present write-up addresses this model only. The other models will be addressed as soon as contributions will be brought in those areas).
If anyone has any questions, please let me know.
Sincerely,
Radhika R. Roy AT&T Holmdel, NJ 07733, USA Tel: (732) 949 8657 Fax: (732) 949 8569 Rrroy@att.com
***************************************************** *** +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 *** *****************************************************