Draft mhsds Toronto IETF minutes -- please review

Allan Cargille <cargille@cs.wisc.edu> Mon, 15 August 1994 21:57 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12695; 15 Aug 94 17:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12691; 15 Aug 94 17:57 EDT
Received: from mercury91.udev.cdc.com by CNRI.Reston.VA.US id aa18237; 15 Aug 94 17:57 EDT
Received: by mercury.udev.cdc.com; Mon, 15 Aug 94 16:42:23 -0500
X-From: cargille@cs.wisc.edu Mon Aug 15 16:42 CDT 1994
Received: from zeus.cdc.com by mercury.udev.cdc.com; Mon, 15 Aug 94 16:42:21 -0500
Received: from calypso.cs.wisc.edu by zeus.cdc.com; Mon, 15 Aug 94 16:42:03 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Allan Cargille <cargille@cs.wisc.edu>
Message-Id: <9408152141.AA09879@calypso.cs.wisc.edu>
Received: by calypso.cs.wisc.edu; Mon, 15 Aug 94 16:41:58 -0500
Subject: Draft mhsds Toronto IETF minutes -- please review
To: mhs-ds@mercury.udev.cdc.com
Date: Mon, 15 Aug 1994 16:41:57 -0500 (CDT)
Cc: minutes@CNRI.Reston.VA.US
Organization: Univ of Wisconsin
Phone: +1 608 262-5084
Fax: +1 608 262-9777
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 8757

Hello all,

Here are the draft minutes for the mhs-ds working group.  Please send
updates/corrections to Harald Alvestrand (Harald.T.Alvestrand@uninett.no).

I must take responsibility for the delay in getting the minutes out --
I was out of the office last week.




        Draft Minutes of MHS-DS Working Group
                 July 27, 1994

Minutes recorded by Allan Cargille (Allan.Cargille@cs.wisc.edu)

1.  INTRODUCTIONS:  See list of attendees (CNRI will append).

2.  SECRETARY:  Allan Cargille will put out first draft.  Harald A.
will be responsible for collecting comments and putting out the final

3.  DOCUMENT REVIEW:  Three of Steve's documents may be ready to submit
as proposed standard directly from this meeting:

    Representing Tables and Subtrees in the Directory

    Use of the Directory to support mapping between X.400 and RFC 822
	Addresses (draft-ietf-mhsds-supmapping-05.txt,ps)

    Representing the O/R Address hierarchy in the Directory

The fourth document is the largest:

    MHS use of Directory to support MHS Routing

There is also the document introducing the pilot project, edited by
Sylvain Langlois:
    Introducing Project Long Bud:  Internet Pilot Project for the
	Deployment of X.500 Directory Information in Support of X.400
	Routing (draft-ietf-mhsds-long-bud-intro-02.txt,ps).

There are two other documents which may need to be discussed:  a
"minimum profile" document (identifying which parts of the routing
document must be implemented for a "conformant" implementation), and a
"overview" document explaining the general intent and architecture of
the routing document.


(a) The first three documents are generally ready to go forward, with
editorial comments taken.  Steve will make the minor changes and submit
them as proposed standard by September 2nd.

(b) Steve reviewed the major changes to the routing document:
- editorial changes were made
- the document was upgraded to use 1993 ASN.1
- the language of the specification was changed to "may" for things
  that are optional, and "shall" for things that are mandatory
- it was clarified that searching is allowed at local levels

Steve had intended to add pseudocode to the document, but it has not
been done yet.  There was a discussion about whether it should be
included, or dropped so that the document could be forwarded.  It was
noted that the pseudocode could be split out into a separate document
or added when the document is progressed.  It was noted that it must be
clear whether the textual specification or the pseudocode is
authoritative in the event that they are not consistent.  Not having
pseudocode will not hold up the document at this level, but this might
be an issue when the spec goes to full standard.  John Klensin
encouraged the group not to let this issue hold up the document.  It
was decided to delete the pseudocode appendix and consider this for
future work.

John Klensin encouraged the group to get the documents out quickly at
this point, and noted that they can be revised in the future as they
progress on the standards track.

John clarified that the process to forward a document is to post it as
an Internet Draft, and send a note to the supervising Area Director
that there is consensus in the working group that the document should
be forwarded as _____ (proposed standard, informational, etc).

Action:  Allan get final comments on routing document to Steve ASAP.

Action:  If time allows, Steve will send a revised copy to the design
team (WG Chairs, John Klensin, Allan Cargille) before September 2nd.
Either way, the document will be forwarded as a proposed standard by
Sept 2nd.

(c) The Long Bud introduction document was discussed.  Allan Cargille
had significant editorial comments and felt that the document was not
ready to go forward in the present form.  It was decided that Sylvain
will work with Allan to incorporate relevant comments, and then he will
submit it as an Informational RFC by September 2nd (recommending no
final call from the IESG).

(d) [My notes are not conclusive on the status of the minimum profile
document.  I believe that either the document has been dropped, or it
is on hold pending work by Kevin Jordan and Julian Onions, who have
implemented it.  Can any one clarify this?]

(e) Allan Cargille still plans to write an overview document, given
time and energy.  If anyone else wants to work on this, they should let
Allan know.  Allan hopes to write something by September.


Kevin Jordan presented the following information:

DSA CN=Long Bud, C=us contains information on
    C=us, ADMD=attmail
    C=us, ADMD=telemail
    C=us, ADMD=<space>

DSA CN=Ornate Hawk Eagle, C=gb contains information on
    c=gb, ADMD=<space>

These "Core" DSAs have full replication of US, GB, and BE information
at the ADMD and PRMD levels, to increase reliability.  They are using
slaveDSA attributes for backup.  Germany has also expressed interest in
participating in replication.

"Core" DSAs will also be brought up by the InterNIC (US) and Sylvain in

Reliability issues in the project are improving, due to the use of the
core DSAs.

People need to start verifying/policing MTA information in the tree --
we need correct, complete information for proper routing.  All
information also needs to be robust.  Kevin has a tool which he will
run regularly and publish the results on the mhsds list.  Important
issue:  some MTAS are not accepting connections from other open tree

Question - is anyone taking responsibility for uploading GOMHS
information into the tree?  Discussion - there was a call for tender
for this tool in UK, but it is unclear if it will be funded.

Question - what GOMHS mtas will relay between the GOMHS community and
open tree MTAs?

John Klensin invited the group to consider whether there is a business
case for commercial ADMDs to participate in this experiment.  ADMDs are
financially driven -- what would they gain?  Is there a long-term
benefit for ADMDs to participate?  Discussion - they can register in
the open tree, and list information needed for customers or other ADMDs
to connect or purchase services.  Services can be restricted based on
routing policies.  The argument for ADMDs to participate in the open
tree is that customers receive more mail, and therefore send more mail
(generating more chargeable traffic).  It was also noted that they are
already receiving this traffic from the Internet community, it is just
travelling via SMTP rather than X.400 - so this is not a policy change,
just a protocol change.

Question - how should the group publicize this project to PRMD
operators and get them to participate?  Answer - Start with GOMHS
community for PRMD participants.

Action:  Kevin will annotate report and identify incomplete or
incorrect data in various countries.  He said he can modify tool to
identify the responsible managers.


- 3 documents are shelved:  DL's, content conversion, 822 support.
- There are 3 possible new documents:  minimum profile, overview, and
    pseudocode specification

Discussion:  the distribution list document is important from a
commercial perspective - some RFPs want this.  It could improve X.400
support for lists.  Discussion:  The doc adds to X.402.  Perhaps that
means it should be handled in an ISO process, not IETF.  IETF tends to
work on things related to internet operations, not part of core
X.400/X.500 functionality.  John indicated that the group would need to
give extremely powerful arguments to get approval for such work in the
IETF community.  Is there an alternate home for this work?

Steve felt DLs and content conversion are critical to work on and he
has to work on them.  He would prefer to do the work in the IETF, but
otherwise will do it elsewhere.  He felt the 822 is elegant and would
round out the other standards, but is not critical.  It was noted that
the 822 document would take a lot of work to update and is not popular
in the IETF.  However, it would also add functionality.  The document
would need to be updated to incorporate MIME.

John indicated that there is pressure to shut this working group down.
He prefers tightly focused proposals directly related to X.400/500 ON
THE INTERNET.  Perhaps another group should be created to work on

Decision:  John and Steve will take this offline.


All documents to be forwarded should be published by September 2nd.
Chairs mail the Area Director (John) to forward them.