draft mhsds minutes from Seattle IETF

[Allan Cargille <[e-mail]>]

Hello MHSDS folk,

Here are my edited notes from the mhsds meeting in Houston.  Kevin
Jordan will edit the final version, so please send corrections to him
([e-mail]).

Cheers,

allan

======================================================================

IETF MHS-DS Working Group meeting
Seattle, Washington
March 29, 1994

Draft version by Allan Cargille
Final Editing to be done by Kevin Jordan



Kevin Jordan summarized three major changes that have been made in the
documents:

1.  Use of directory to support mapping - especially missing address
components - for example, in Germany often the Organization attribute
is not used but OUs are used.

- There is a major change in where the mapping rules will be stored.
Now all rules will be stored under O=Internet, OU=X.400/RFC 822
Mapping.  CN=X.400 to RF822 or CN=RFC822 to X.400.  The X.400 tree has
C, ADMD, etc.  The 822 tree has top-level domain, 2nd domain, etc.

- This keeps all the information under one subtree and makes it
possible to easily replicate the whole subtree.  Experts do not expect
the mapping rules to grow much larger than the present size.  This also
makes it much easier to copy entire mapping rules into directory from
tables.  Replication is standard in the X.500 1992/93 spec, and can
supports replicating entire subtrees.

2.  Bilateral vs multi-lateral agreements.  BilateralTable attribute is
a sequence now.   Small editorial note -- Need to change OID value in
document to a new one (the old OID was used even though the definition
was changed).  This feature can now support multi-party agreements or
truly private agreements.

3.  Change to default routing failure action at country level (now it
is the same as for any other level).


Discussion -- minimum profile:  Is this valuable?  It contains errors.
Is this document necessary?  The minimum is so  small that it will hurt
things because not enough functionality is demanded of
implementations.  Another example of where a weak minimum profile was
the minimum profile for RFC987 in the COSINE MHS Community -- it
discouraged deployment of fully functional gateways.
    Decision - do not progress the current document.  However, a
minimum profile should be a useful document, it should just contain
enough functionality as to be truly useful.  Decision:  implementors
will discuss and agree on a minimum profile (Kevin Jordan and
implementors of other implementations).

Discussion -- terminology in minimum profile:  The issue of the
terminology used in the document was raised:  "may", "should", and
"shall" in regard to exactly what is mandatory, suggested, and
optional.  This could be specified in the routing document, but it is
simpler to keep in a separate document because the routing document is
so complex.  Someone commented that if we do not clean up the current
language then the RFC editor will insist on it when the document is
progressed anyway.  Action - Kevin Jordan discuss with implementors,
discuss on list.


Review of Long Bud status.

- Authors have made some changes. Action - produce new draft by end of
April - Sylvain (editor).  Progress if agreement is reached on the
list.

- Some tools are available on anonymous ftp from ftp.css.cdc.com in
pub/mhs-ds/long-bud/software

listOT - list Open Tree - written in Duaperl

pingMTAs - finds MTAs and tests connections to them.  The current
version Uses CDC products in the tool.  Kevin will try to make the
necessary components publicly available.  Perhaps PP has the necessary
functionality already available.  same kinds of tools available.
Written in DuaPerl.

upload-2.0 - accepts routing/mapping tables in RFC1465 format, creates
corresponding information in the Open Tree.  Needs to be updated for
new version of the specs.  Written in C and awk.

getRouting - opposite of upload above, downloads tables from
directory.  Written in C.

Comment - It would be nice if someone could rewrite these tools in
DuaPerl -- any volunteers?

<Kevin showed a few slides containing output of tools>

Question - domains with no MTA listed, is this a problem?  Should they
be deleted?  Conclusion was that this seems OK.  Another problem is
that some MTAs are listed but they do not accept connections from any
other MTA.

Problem - In the US, MTAs are listed that don't exist.  Need to be
cleaned up.  Should talk to them, get them to upgrade service.  Perhaps
some sites like Merit and Mitre will participate again?  Action item
for Wisconsin project.  MTAs which do not exist any more should be
deleted from the open tree.

 US/ATTMAIL/CDC, ESNET - are mastered at CDC
 US/TELEMAIL/arc (NASA) - is mastered at NASA

Question - Can all sites see the same thing?  Yes, this is just a list
of info from the directory.  PingMTA tool may see different results
based on connection permissions, or they can also be affected by
timeouts, chains, referrals, etc.

PingMTAs - tries to connect to all listed MTAs.

Some problems found using this:
 - registered, but non-existent MTAs (remove) 
 - registered, but unmanaged MTAs - mostly US (remove) 
 - registered, but mostly unreachable domains (add routing info) 
 - missing authentication requirements (add them where truly needed)

Need to register default routes to make all existing domains in the
GO-MHS community routable via the X.500 Directory.  Base initial routes
upon RARE tables where necessary; use authentication requirements where
needed.

Question - we have assumed an open tree where MTAs will accept
connections from any calling MTA.  Is this a valid model?  Each MD must
list an MTA which will be openly accessible from any calling MTA.  This
approach is simpler.

An alternate approach would be to reflect the current GO-MHS community
in the directory with Multilateral agreements.  Each ADMD, PRMD, O, OU
lists an MTA.

Discussion:  why would people operate "closed" MTAs?  Urs reported that
SWITCH blocks out unknown MTAs because incoming connections can ship
you anything they want, and routing this mail can cost them money (over
expensive links, or to costly commercial destinations).

After discussion, the group strongly reaffirmed that open tree MTAs
should be willing to accept connections from anyone.  It is also noted
that it is technically possible to establish a closed community with
MTA information at one location in the tree in the current draft of the
routing specification, but this approach will not be taken in the
LONGBUD pilot.

Question - what mandatory stacks that should be supported for each
domain?  This was not specified in the current draft.  Possible stacks
are RFC1006, CLNS, X.25.  The decision was that initially RFC1006 is
the mandatory stack, and other stacks may optionally be used.  This
should be added to the Longbud draft.


Discussion - DSA problems:

 - existing infrastructure is too unreliable for routing.
 - need to establish more replication.
 - need to establish more explicit backup DSAs.

Problem with top-level servers, especially the US server.  It is
unavailable often, perhaps due to crashing.  There is a need for a more
reliable US top-level X.500 server.

In light of this problem, Kevin proposed the following replication
strategy:

To Start:  - pick 2 DSAs in US and two in Europe:  CDC?  InterNIC?
NASA?  France (Sylvain), SWITCH, or ULCC (Linda).  (ULCC runs a
worldwide root server.)

 - Each DSA has complete replica of top levels.
 - Each MHS-DS entry must have at least one backup DSA attribute.
 - backupDSA attribute should reference DSA on other side of ocean.
 - Each core DSA will accept request for bilateral replication
  agreements from any DSA manager that asks.

To Expand:
 - establish a more methodical, more scalable approach.  This is an
   unsolved problem.

Question - Peter Kirstein - has anyone investigated what the problems
are with the DSA reliability?  Is this published?  Answer - Yes,
once/week to DSA national managers and osi-ds list.  Probes are only
from NeXor, which may make the data suspect because there may be
problems with transatlantic lines or timeouts.  It would also be good
for someone to do probes in the US - can CDC do these?  Or another
site?  Peter K - can test from anywhere in US, but it needs to be
national master.  There are 3 root-level DSAs in the US, but
availability is not good.

Linda - ULCC does measurements of DSA reliability - there is a problem with
the US master DSA.  European DSAs are more reliable.

The meeting was wrapped up.