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?
- multilateral agreements Kevin E. Jordan
- Re: multilateral agreements Harald T. Alvestrand