Three files for the September SG16 meeting

Sakae OKUBO okubo at
Thu Aug 6 04:37:47 EDT 1998

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

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:
>1.      The modified title of Annex G is very restrictive, and is NOT
>acceptable. 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.

>2.      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

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

>3.      Section 1.1 (Scope). It has been mentioned that "It should also be
>understood 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

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:
>1.      The title of Annex G should remain as it was before: "Annex G -
>Gatekeeper-to-Gatekeeper Communications."


>2.      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'

>3.      A domain has to be defined further. For example, a domain may
>consist 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?

>4.      Inter-gatekeeper communications between the multiple zones of a
>given 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.

>5.      A single administrator will also be able to create multiple domains
>for 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.

>6.      If a domain belongs to a single administrator, and communications
>between 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.

>7.      The inter-gatekeeper communications between (administrative) domains
>can 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:
>1.      Definitions for "H.323 network", "zone" and "domain" should also be
>included (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:
>1.      The title of this section should be changed to "Hierarchical
>Inter-Gatekeeper Communications Between Administrative Domains". The
>write-up should be modified to take into account all the comments given
>Specific comments related to Sections 1.5, 1.5.1, 1.5.2,
>1.      These sections are general enough to be used in the context of a
>zone. 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:
>1. 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.
>Radhika R. Roy
>Holmdel, NJ 07733, USA
>Tel: (732) 949 8657
>Fax: (732) 949 8569
>Rrroy at

***  +1-503-264-8816(voice)              Intel - Hillsboro, OR.
***  mailto:jim.toga at         mailto:james.toga at ***
***  PGP keyID 36 07 86 49 7D 74 DF 57  50 CB BA 32 08 9C 7C 41 ***

More information about the sg16-avd mailing list