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

Text File | 1994-11-01 | 8KB | 205 lines

CURRENT_MEETING_REPORT_

Reported by C. Allan Cargille/University of Wisconsin

Minutes of MHS-DS Working Group (MHSDS)


Document Review

After editorial corrections, the following three documents will be ready
to move forward:


   o ``Representing Tables and Subtrees in the Directory''
     (draft-ietf-mhsds-subtrees-05)

   o ``Use of the Directory to support mapping between X.400 and RFC 822
     Addresses''
     (draft-ietf-mhsds-supmapping-05)

   o ``Representing the O/R Address hierarchy in the Directory''
     (draft-ietf-mhsds-infotree-05)


Steve will make the minor changes and submit them for recommendation as
Proposed Standards by 2 September.


``MHS use of Directory to support MHS Routing''

Steve reviewed the major changes to the routing document
(draft-ietf-mhsds-routdirectory-05):


   o Editorial changes were made.

   o The document was upgraded to use 1993 ASN.1.

   o The language of the specification was changed to ``may'' for things
     that are optional, and ``shall'' for things that are mandatory.

   o 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 specification 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, and
noted that they can be revised in the future as they progress on the
standards track.

Allan will get final comments on the document to Steve as soon as
possible.  If time allows, Steve will send a revised copy to the design
team (working group chairs, John Klensin and Allan Cargille) before 2
September.  Either way, the document will be forwarded as a Proposed
Standard by that time.



``Introducing Project Long Bud:  Internet Pilot Project for the
Deployment of X.500 Directory Information in Support of X.400 Routing''

Allan Cargille had significant editorial comments on the document
(draft-ietf-mhsds-long-bud-intro-02) and felt that it 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 2 September (recommending no Last Call from
the IESG).



Additional Documents

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
an ``overview'' document (explaining the general intent and architecture
of the routing document).

The status of the minimum profile document is not clear.  It has either
been dropped, or it is on hold pending work by Kevin Jordan and Julian
Onions, who have implemented it.

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.



Update on Current Pilot

Kevin Jordan presented the following information:


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

   o 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 (France).  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.  An important issue is that
some MTAs are not accepting connections from other open tree MTAs.

It is unknown if anyone is taking responsibility for uploading GOMHS
information into the tree.  There was a call for tender for this tool in
the UK, but it is unclear if it will be funded.

The group discussed which 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?  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 traveling via SMTP
rather than X.400, so this is not a policy change, just a protocol
change.

The group discussed how this project should be publicized to PRMD
operators and get them to participate.  It was suggested to start with
the GOMHS community for PRMD participants.  Kevin will annotate a report
and identify incomplete or incorrect data in various countries.  He said
he can modify a tool to identify the responsible managers.



Future Work


Three documents have been shelved:


   o ``MHS use of the Directory to support distribution lists''
     (draft-ietf-mhsds-mhsuse)

   o ``MHS use of Directory to support MHS Content Conversion''
     (draft-ietf-mhsds-convert)

   o ``Use of the Directory to support routing for RFC 822 and related
     protocols''
     (draft-ietf-mhsds-822dir)


There are three possible new documents:  minimum profile, overview, and
pseudocode specification

The distribution list document is important from a commercial
perspective---some RFPs want this.  It could improve X.400 support for
lists.  The document adds to X.402.  Perhaps that means it should be
handled in an ISO process, not the IETF. The 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 distribution lists 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/X.500 on
the Internet.  Perhaps another group should be created to work on this?
John and Steve will take this off-line.


Summary and Close

All documents to be forwarded should be published by 2 September.  The
chairs will send them to the area director to forward.