Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/mhsds/mhsds-minutes-94mar.txt

Text File | 1994-06-07 | 9KB | 229 lines

CURRENT_MEETING_REPORT_

Reported by Allan Cargille/University of Wisconsin

Minutes of MHS-DS Working Group (MHSDS)



Document Changes

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/RFC822
     Mapping.  CN=X.400 to RFC822 or CN=RFC822 to X.400.  The X.400 tree
     has C, ADMD, etc.  The RFC822 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 a
     directory from tables.  Replication is standard in the X.500
     1992/93 specification, and can support replicating entire subtrees.

  2. Bilateral versus multi-lateral agreements.  BilateralTable
     attribute is a sequence now.  Small editorial note:  Need to change
     the OID value in the 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).


Minimum profile was discussed.  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 profile was the minimum profile was for
RFC 987 in the COSINE MHS Community---it discouraged deployment of fully
functional gateways.

It was discussed whether or not to progress the current document.
However, a minimum profile should be a useful document, it should just
contain enough functionality as to be truly useful.  It was decided that
implementors will discuss and agree on a minimum profile (Kevin Jordan
and other implementors).

Terminology in minimum profile was also discussed.  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 it in a separate document because the routing document
is so complex.  Someone commented that if we do not clean up the current
language, the RFC Editor will insist on it when the document is
progressed anyway.



Review of Long Bud Status

The authors have made some changes.  Sylvain will produce a new draft by
the end of April.  The document will be progressed if agreement is
reached on the mailing list.

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


   o listOT - list Open Tree.  Written in DuaPerl

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

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

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


It was suggested that it would be nice if someone could rewrite these
tools in DuaPerl.  Volunteers were requested.

Is it a problem that domains with no MTA are listed?  Should they be
deleted?  The conclusion was that this seems okay.  Another problem is
that some MTAs are listed but they do not accept connections from any
other MTA.

In the US, MTAs are listed that do not exist.  This needs to be cleaned
up.  Someone should talk to them and get them to upgrade the service.
Perhaps some sites like Merit and MITRE will participate again?  This is
an action item for the Wisconsin project.  MTAs which do not exist any
more should be deleted from the open tree.


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


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

PingMTAs try to connect to all listed MTAs.

Some problems in using this were found:


   o Registered, but non-existent MTAs (remove)

   o Registered, but unmanaged MTAs - mostly US (remove)

   o Registered, but mostly unreachable domains (add routing
     information)

   o Missing authentication requirements (add them where truly needed)


Default routes need to be registered 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.

An open tree has been assumed 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.

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

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 Long Bud pilot.

What mandatory stacks that should be supported for each domain?  This
was not specified in the current draft.  Possible stacks are RFC 1006,
CLNS, X.25.  The decision was that initially RFC 1006 is the mandatory
stack, and other stacks may optionally be used.  This should be added to
the Long Bud draft.


Discussion - DSA Problems

   o Existing infrastructure is too unreliable for routing.
   o Need to establish more replication.
   o Need to establish more explicit backup DSAs.


There is a 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:


   o To start:  Pick two DSAs in the 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.


   o To expand:  Establish a more methodical, more scalable approach.
     This is an unsolved problem.


Peter Kirstein asked if anyone has investigated what the problems are
with the DSA reliability?  Is this published?  The answer is yes, once
per week to the DSA national managers and the OSIDS mailing 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 stated that a test can be done from anywhere in the
US, but it needs to be a national master.  There are three root-level
DSAs in the US, but availability is not good.

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


Attendees

Claudio Allocchio        [e-mail]
C. Allan Cargille        [e-mail]
Rong Chang               [e-mail]
Charles Combs            [e-mail]
Urs Eppenberger          [e-mail]
Tony Genovese            [e-mail]
Kevin Jordan             [e-mail]
Marko Kaittola           [e-mail]
Peter Kirstein           [e-mail]
Sylvain Langlois         [e-mail]
Linda Millington         [e-mail]
Francois Robitaille      [e-mail]
Jim Romaguera            [e-mail]
Einar Stefferud          [e-mail]
Peter Sylvester          [e-mail]