multilateral agreements

"Kevin E. Jordan" <Kevin.E.Jordan@cdc.com> Thu, 03 March 1994 15:19 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03986; 3 Mar 94 10:19 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03982; 3 Mar 94 10:19 EST
Received: from [129.179.91.44] by CNRI.Reston.VA.US id aa08685; 3 Mar 94 10:19 EST
Received: from mercury91.udev.cdc.com by sequoia.udev.cdc.com; Thu, 3 Mar 94 09:04:16 +0600
Received: by mercury.udev.cdc.com; Thu, 3 Mar 94 09:03:00 -0600
X-From: kej@mercury.udev.cdc.com Thu Mar 3 09:03 CST 1994
Received: from localhost by mercury.udev.cdc.com; Thu, 3 Mar 94 09:02:59 -0600
To: mhs-ds@mercury.udev.cdc.com
Subject: multilateral agreements
Date: Thu, 03 Mar 1994 09:02:58 -0600
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Kevin E. Jordan" <Kevin.E.Jordan@cdc.com>
Message-Id: <2d75fc2347f9002@mercury.udev.cdc.com>

At our meeting in Amsterdam, some members expressed a need for supporting
the concept of "Multilateral" MTA agreements in addition to the "Bilateral"
agreements which are currently supported.  At that time, we talked about
possibly changing the syntax of the current bilateralTable attribute to a
SEQUENCE of distinguished names.  Currently, this attribute is a simple,
single distiguished name which points to a table of bilateral agreements.

The multilateral agreement concept is considered necessary in order to support
large communities of MTA's which share a need to know about each other and which
will not accept connections from MTA's outside of the community.  An example
of this type of community is the RARE community of X.400 MTA's.  With the
current scheme, each of these MTA's would need to maintain its own bilateral
table which contains a copy of what is in every other MTA's bilateral table.
If an MTA had private bilateral agreements, these would be added to its
table.  This creates a situation where all of the members of the community will
need to exchange bilateral information on a regular basis in order to maximize
the probability that all of the separate bilateral tables are synchronized.
Doesn't this sound a lot like distributing RARE routing tables?

It would be better if this common multilateral information could be registered
in a single table in the directory where all MTA's in the community could
reference it.  This would eliminate the need to synchronize separately
maintained bilateral tables.  However, it will also be necessary to continue to
support registration of information which is truly bilateral.

Rather than changing the syntax of the existing bilateralTable attribute,
I propose that we add a new multilateralTables attribute whose syntax is
defined as a SEQUENCE OF distinguished names.  This would be a new attribute
of the mTA object class.  When creating or accepting connections, an MTA would
first check its bilateralTable, if one is defined, for information related to
the peer called/calling MTA, and then it would check the tables defined in
the multilateralTables attribute, if defined.  The tables defined in the
multilateralTables attribute would be checked in the order they occur in the
SEQUENCE.

Comments?