Network Working S.E. Hardcastle-Kille
Group ISODE Consortium
INTERNET-DRAFT July 1992
Expires: January 1993
A simple profile for MHS use of Directory
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months.
Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet Drafts
as reference material or to cite them other than as a "working draft"
or "work in progress."
Please check the I-D abstract listing contained in each Internet Draft
directory to learn the current status of this or any other Internet
Draft.
Abstract
The document ``MHS Use of Directory to support MHS Routing'' describes
a comprehensive approach to MHS use of directory to support routing
[HK92]. This document defines a strict subset of this document, which
is intended to solve the most pressing problems. It also defines a
practical first step for implementation, such that this subset can be
deployed prior to fuller implementation.
This document does not repeat information in the other document.
Duplication would only lead to the possibility of inconsistency.
WARNING: This document must be read in the contex of the document it
profiles. It is meaningless as a standalone document.
This draft document will be submitted to the RFC editor as a protocol
standard. Distribution of this memo is unlimited. Please send
comments to the author or to the discussion group
<mhs-ds@mercury.udev.cdc.com>.
INTERNET--DRAFT Profile for MHS use of Directory July 1992
1 Service Goals
The following goals are identified:
o No routing table configuration for simple MTAs in a PRMD (WEPs and
gateways may do manual things).
o Single entry configuration for most sites.
o Do not replace function that is working reasonably well using
existing approaches.
o Ignore issues which are not yet operational concerns. These can
be handled by the full specification in due course.
2 Approach
The approach to routing is to use the single routing tree associated
with the open community. MTAs will reference this tree. Simple MTAs
need only do this, plus ad hoc configuration to route to a suitable
MTA with a fuller manual configuration (e.g., a WEP). This document
goes through section by section, referencing the full document, noting
what support is needed.
3 Profile
3.1 General Table Handling
Support for subtrees, but not flat tables is needed.
3.2 O/R Address Hierarchy
Support for all attributes is needed, except:
mHSX121
mHSDomainDefinedAttribute
Expires: January 1993 Page 1
INTERNET--DRAFT Profile for MHS use of Directory July 1992
3.3 Local Addresses
This is supported.
3.4 MTA Naming
All MTAs are named within the O/R Address tree. The attributes which
must be supported are:
responderAuthenticationRequirements
transportCommunity
remotePresentationAddress
3.5 Routing Trees
Only the single open community routing tree is used. A variant on
this profile might relax this restriction, perhaps to support a small
number of routing trees.
3.6 Routing Information
The following attributes are used:
o authoritativeAddress
o mTAInfo
Routing action is always the default.
3.7 Indirect Connectivity
This is not used.
Expires: January 1993 Page 2
INTERNET--DRAFT Profile for MHS use of Directory July 1992
3.8 Protocol Mismatches
The transport community approach is used.
3.9 Supported Protocols
This approach is used, but only P1(88) and P1(84) are considered.
3.10 Capability Restrictions
These are not handled.
3.11 Pulling Messages
This is not done.
3.12 Authentication
For 1988 usage, the distinguished name is used to identify the remote
MTA. For 1984 usage, no authentication is done.
Authentication will be by network address. Password will always be a
single space.
The attribute must be supported, but only the
responderAuthenticationRequirements attribute is used. For MTAs
following this specification, the following values must be set if
bilateral-agreement-needed is false.
mta-name-present true
aet-present true
aet-valid true
network-address true
simple-authentication false
strong-authentication false
Expires: January 1993 Page 3
INTERNET--DRAFT Profile for MHS use of Directory July 1992
If bilateral-agreement-needed is true, there are no restrictions on
value. Where a WEP uses this scheme, information on the bilateral
agreement will be determined locally (by private means).
The remotePresentationAddress attribute will always be present.
3.13 Policy
Policy will not be used.
3.14 Protocol Extensions
These will not be used.
3.15 Format Conversion
All issues relating to format conversion will be ignored.
3.16 RFC 822 Support
There is no support for RFC 822 or RFC 822/X.400 mappings by use of
directory.
3.17 Distribution Lists
This will be supported.
3.18 Redirects
Not supported.
3.19 Bad Addresses
The mechanisms will not be supported.
Expires: January 1993 Page 4
INTERNET--DRAFT Profile for MHS use of Directory July 1992
References
[HK92] S.E. Hardcastle-Kille. MHS use of the directory to support MHS
routing, April 1992. Internet Draft.
4 Security Considerations
Security considerations are not discussed in this INTERNET--DRAFT .
5 Author's Address
Steve Hardcastle-Kille
ISODE Consortium
PO Box 505
London
SW11 1DX
England
Phone: +44-71-223-4062
EMail: S.Kille@ISODE.COM
DN: CN=Steve Hardcastle-Kille,
O=ISODE Consortium, C=GB
UFN: S. Hardcastle-Kille, ISODE Consortium, GB
Expires: January 1993 Page 5