Final minutes, IETF X.400 OPS WG meeting, Boston.

[Alf Hansen <[e-mail]>]

Megan,
Here they are.


The ietf-ops-wg,
I have done the modifications based on Stefs comments.

Cheers,
Alf H.


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



Minutes of the IETF OSI X.400 Operations Working Group
            24th IETF, Boston, Massachusetts
                     July 15, 1992

Reported by Allan Cargille

Minutes are reported in the order that the meeting occurred.  Agenda
item refers refer to the numbers from the published agenda of the
meeting.  They are out of order where the order of the agenda
was modified.  Two empty lines are used to separate agenda items.
The list of attendees was taken separately.  Action items are
identified with the note "[action]".


FIRST SESSION

1.  Welcome.  Alf Hansen chaired the meeting.  Allan Cargille
volunteered to take minutes [action].  The agenda was modified to discuss
working group status and the status of the Wisconsin NSF X.400 Project
and the Cosine MHS Project.  Agenda points 1, 2, 3, 5, 6, and 8 will
be discussed in the first working group session.  Reviewing the
documents will be moved to the second working group session.  Stef was
added to agenda point 5 to report on progress on U.S. ADMD and PRMD
naming & registration issues.


2.  New Charter.  Alf distributed the new charter before the meeting.
It was agreed that the proposed new time schedule for the documents
would be revised after discussion the documents.  [Note - this was not
done in the meeting, and should be done on the mailing list.  Action -
Alf]

Change control.  The IESG (and IAB?) agreed that change control for
RFC1327 (the latest version of mapping between X.400 and RFC822 mail)
was assigned to the RARE Working Group on Mail and Messaging.

Discussion:
    - is it OK for IETF RFCs to be assigned to another group?
    - how will people in the x400ops working group be able to
        participate in further revisions of this document?
    - how will this be publicized?

It was clarified that the RARE-MSG working group is an open working
group.  Members of the x400ops working group are welcome to join the
mailing list and participate in the group.  Here's how to join:

    Send a message to [e-mail] with the following text in
    the BODY of the message (NOT the subject).

    SUBSCRIBE WG-MSG Your-given-name Your-surname

    This will automatically subscribe you to the list.  An automatic
    reply will be sent back to you.

    The address of the mailing list itself is [e-mail], or 
    /S=wg-msg/O=rare/PRMD=surf/ADMD=400net/C=nl/.

There was also discussion about the number of mailing lists which deal
with X.400 issues.  Often messages are posted to multiple lists.  It
was recognized that having these multiple lists is a pain, but this
working group is unlikely to be able to change the situation.  It was
recommended that when an initial message is posted to multiple lists,
the message should clearly identify *one* list on which the follow-up
discussion should take place.


3.  Action items from last March 92 meeting:

a) John Sherburne (SPRINT) will work with Tony Genovese to figure out how US
can provide an MTA that has X.25 connectivity.

    - Tony reported that accepting ADMD = <single space> is a problem
      for Sprint.  He did not know if that is for technical, political,
      or financial reasons.  
      
      [action]  Tony continue to work on a WEP which is accessible
      over public X.25.

    - Ed Albrigo from the Corporation for Open System (C.O.S.) gave
      a report on their X.400 activities.  They are working on the
      following:

      1) Establishing direct network-layer connections to the Internet.
	   They plan to route both IP and CLNP.
      2) Establishing X.400 links which connect the OSINet X.400
           community to the GO-MHS community.
      3) They are planning to go to complete "electronic-only"
           communication with ten COS member companies by December
	   1992.

      Ed confirmed that COS will comply with current RFCs and
      recommendations for the GO-MHS community.

      It was clarified that COS uses X.25 in their private OSINet network,
      but that is a private network that is not connected to public X.25.

    - There was a discussion about connections to ATTmail.  Internet RFC822 
      mail users should be able to send mail to all ATTmail users.
      However, the ATTmail <--> Internet mail gateway produces bad
      addresses, so mail is often un-replyable.
      
b) Urs will ask the COSINE MHS Project Team to submit the address mapping
table procedures as a draft RFC.

    - Done

c) Stef - Start a discussion on X.400 OPS and WG1 lists about ADMD name in
the US.  See section 3.1.2. [of March 1992 minutes]

    - Not done.

    - Note that the rare-wg1 mailing list has been succeeded by the
      wg-msg list (see section 2 above).

      [action]  Stef start this discussion.
      [action]  Someone email Stef to start this discussion. [done]

      See related discussion of this in agenda item 5.

d) Alf will send the updated charter to the list.

    - Done

e) Claudio will produce a draft document that will propose a method for using
DNS to store X.400 to RFC 822 mapping and routing.

    - Done

f) Claudio will follow up the MAIL 11 mapping document.

    - Done

g) Harald will follow up the International Character set document.

    - Done


5.  Status of X.400 Operations

a)  Allan Cargille discussed the status and future of the NSF X.400
Project.  The project has been running since August, 1990 and is now
toward the end of the initial grant.  The project has operated the
experimental PRMD "XNREN".  Fifteen to twenty sites have registered as
members of this PRMD, but only approximately five are currently
exchanging X.400 traffic.  The project has acted as a coordination
point for U.S. entries in the RFC987/1148/1327 mapping tables.  The
project also served as a beta site for several PP releases, and
developed and contributed software to support the Fujitsu dexNET 200
fax modem in PP.  The project is operating a primary MTA running PP 6.0
on a dedicated DecStation 3100/Ultrix.  Some sites, including
Wisconsin, are running the IBM/Wisconsin Argo X.400 software, which
includes a UA.  The project has also acted as a Well-Known Entry Point
(WEP) to the Cosine MHS Project (see below).  We are seeking an
extension of the grant to continue supporting a stable U.S. WEP and to
participate in the ongoing research work to develop a stable X.400
infrastructure.  Without continued funding, our project will end at the
end of this calendar year.

b)  Jim Romaguera presented an overview of the Cosine MHS Project at
SWITCH (Switzerland).  That project began in (January 1991?) and
continued work begun by the RARE MHS Project Team.  They coordinate the
academic and research X.400 service in Europe.  They have finished 80%
of their goals for the current project period, which ends at the end of
this calendar year.  The project supports international X.400
connections between all Western European countries, as well as Greece,
Slovenia, Lithuania, the United States, Canada, Australia, New Zealand,
South Africa, China, India, and the Republic of Korea.  Some countries have
multiple networks participating in the service.  Most European
participants have private connections to one or more commercial ADMDs.
Some are purchasing value-added services (such as fax gateways) from
ADMDs.  Several project participants have online services available
(via telnet or over X.25) to translate between X.400 and RFC822
addresses according to the current mapping rules.

The exact future of the project is unclear, but it is expected that
they will continue.  It is likely that the future project will be
coordinated by the RARE Operational Unit and will be contracted out.

The project team is still working on several projects.  They plan to
have a daily RFC1327 mapping table update tool operational by the end
of this year.  They are working on evaluating publicly available X.400
implementations.  They plan to produce a catalog of existing X.400
implementations.  They have done work on evaluating ADMDs and plan to
report on this (verifying connectivity, etc).  They plan to produce a
tutorial and overview on RFC1327.  They have done work on evaluating
international X.400 connections, and are working on tools to
automatically process a common statistics format.  They are also
working on a connectivity tool which will be based on sending mail to
echo servers and evaluating the results.  Lastly, they operate a file
server with lots of documents.  You can reach the fileserver via anonymous
ftp to host "nic.switch.ch".

Discussion:
    - it was recommended to refer to RFC1292 (a catalog of X.500
        implementations) for X.400 product evaluations.
    - will this information on implementations be released as an RFC?
    - there is a question of liability when producing such
        evaluations.
    - it was recommended that vender and user comments about
        implementations be placed in separate documents.

c)  Stef reported on the current work of the MHS-MD study group on
ADMD/PRMD naming.  

By way of review, Stef covered the history of connections between
the U.S. Internet and commercial email services.  Vint Cerf was the
founder of MCI Mail and then went to CNRI.  He concluded agreements on
behalf of the Internet with MCIMail, ATTmail, G.E. Information
Services, and CompuServe (and possible others) that are "sender keeps
all revenue" agreements.

There was also discussion about what internal protocols these
services use.  All operate gateways between RFC822 and their internal
protocol.  Several problems were discussed
    - if the service is using a poor or nonstandard gateway, then
	the addresses coming out of the gateway are messed up
    - people did not know of any connections between U.S. commercial
	ADMDs
    - there are no connections between the U.S. Internet X.400
        community and commercial ADMDs

Current MHS-MD status.  Commercial ADMDs have been arbitrarily
selecting their own names, and then arbitrarily naming PRMDs under
their ADMD.  There is strong feeling that these existing (ADMD, PRMD)
name pairs must be valid in the future.  Any new registration procedure
must support these existing names.  The group is also working on a
structure for a U.S. ADMD backbone, which does not mean a specific
ADMD.  Currently the string ADMD=USBB is being used to refer to such a
structure.  Stef cautioned us that the "USBB" name is just a
placeholder and is likely to change to some other (as yet undefined)
text string.  PRMD names could then be registered under this
"ADMD=USBB".  There are still unresolved questions about how the USBB
should be routed and supported.

Stef proposed that the U.S. Internet declare itself as an ADMD.  This
could be justified because at present, all the other ADMDs are
self-declared as well.  Stef argued that there is currently no regulation
of US X.400 service providers, so each ADMD is more or less making up
their own rules as they proceed.  Many people are making lots of
assumptions.  One has been that the INTERNET does not qualify to be an
ADMD, and the that other ADMDs would block its attempt to assert that it
is an ADMD.


Discussion:
    - the issue of connecting to the U.S. ADMDs is not an issue of
	naming, it is an issue of service agreements and charging.
	The routing can be worked out.
    - connections over X.25 will probably be necessary to connect to
        the commercial ADMDs, although many US carriers are moving to 
        offer IP service, and to interconnect with the INTERNET.
    - the Internet ADMD could offer to provide RFC1327 gateway
        services to the commercial ADMDs.  That way the gateways would
	be operated according to existing agreements and
	recommendations and would generate "good" addresses.
    - if the Internet succeeds in defining itself as an ADMD, then the 
        other C=US ADMD service providers can no longer use the excuse 
        that they "cannot pass ADMD-ADMD traffic via the INTERNET PRMD".
    - if the commercial services were interested, the Internet ADMD
        could play a role as a relay between them.  [Note - this would
	not necessarily require commercial traffic to flow across the
	research Internet.]

There was a proposal to decide on the matter at this meeting.  There
was heated argument that the issue had not been discussed before the
meeting, and should be discussed more in a wider forum and on the
mailing list.  It was agreed that Stef would write an internet draft
proposing to create an ADMD=Internet [action].  If approved in the
future, this paper could evolve into an RFC.

The WG recommended that each country should write an Internet Draft
describing the national solution for X.400 addressing of Internet
addresses.  Stef's draft could be used as a template for other
countries' Internet Drafts. The result will in the end be (if the
drafts are approved) a series of RFCs.  [This paragraph supplied by Alf
Hansen.]


8.  Future U.S. Internet X.400 organization - not discussed beyond the
above information.


SECOND SESSION


5(c) cont'd - connections to ADMDs.  Steve H-K. proposed generating a
document that addresses the issue of ADMDs and how they are connected
to the R&D world (or "Internet" to coin a phrase).  The contents of this
document should be something like:

    - ADMDs presently connected to the Internet (or R&D world, same
	thing, as I'm talking about the global Internet).
    - policy restrictions on such connections ie. are they available
	for free & for anyone on the Internet, can R&D people relay via
	a connected ADMD to 3rd party ADMDs , etc.
    - whether the ADMDs are using RFC 1327 gateways & the global
	mapping tables
    - which PRMDs these ADMDs support - ADMD connectivity between
	themselves.  - anything else that fits in to the above context.

Goals are to 
    - stimulate ADMDs to deploy well run ADMD to Internet connections,
	preferably by using R&D operated gateways.
    - document the PRMDs reachable via ADMDs & of course the ADMD's
	connectivity to other ADMDs.

Jim Romaguera (wearing the hat of NetConsult AG, not the Cosine MHS
Project Team) volunteered to write a draft document [action].

[notes in this 5(c)(cont'd) section courtesy of Jim R.]


4.  Document Review - in general, detailed comments are not included
if a new version of the document will be released.

b) "X.400 use of extended character sets"  (Harald Alvestrand).
Discussion.  Harald will update the document and release the updated
version as an Internet draft [action].  The draft will be discussed at
the upcoming RARE Character Set and RARE Messaging meetings.  These
comments will be presented at the next IETF meeting, and the document
will be finalized.

c) "Operational Requirements for X.400 Management Domains in the 
GO-MHS Community" (Hansen/Hagens).  Comments were taken on the
document.  The document will be revised and a new Internet Draft will
be released [action].

There was discussion about what kind of RFC this document should be
released as.  People felt that it should be a requirement that X.400
domains should support the "postmaster" address in the same manner as
RFC822 domains do.  It was proposed that a very short RFC be drafted
which explains the need for supporting "postmaster" addresses.  This
short postmaster RFC will then be advanced in the standards track.
Allan Cargille volunteered to write the RFC [action].  It will use the
recommendations from the recent Cosine MHS Managers meeting as a
starting point.  It was pointed out that to support the introduction of
X.400(88), both S=Postmaster and CN=Postmaster must be supported.

The revised Hansen/Hagens paper cannot be progressed as an RFC until
the Eppenberger routing paper and Cargille Postmaster paper are also
ready to be submitted, because it references those documents.  The
document may also have to be modified based on the group's
recommendations for C=us/ADMD=Internet.

d) "Routing coordination for X.400 MHS services within a multi protocol
/ multi network environment" (Urs Eppenberger).  Changes to this
document were discussed in light of a recent submission by Panos
Tsigaridas, "MHS Information Exchange Format (MHS-IEF).  Panos' paper
recommended using the same basic information and routing algorithm as
the Eppenberger document, but providing a syntax and structure so that
this information could be easily placed into X.500 under well-known
places.  Further information already stored in X.500 could easily be
extracted by tools and translated into the proposed text format.  These
text tables could then by exchanged the "old-fashioned" way (E-mail).

The desire to support X.500 must be weighed against the fact that this
new document format is needed immediately and in fact is already being
introduced in the Cosine MHS Project.  Changing the document format
would introduce delays due to discussion and take longer to become
operational.  It was agreed that Urs, Panos, and Steve H-K. would meet
to see if minimal changes could be made to the Eppenberger document
which would make it easier to store the information in X.500.  Steve
reported that they agreed that Panos would propose a set of detailed
"short term" change requests to Urs's document [action].  A revised
document should be sent out, which should be approved via email and
then submitted as an experimental RFC [action].

e) "Using the Internet DNS to maintain RFC987/RFC1148 Address Mapping
Tables and X.400 Routing Informations" (Allocchio, Bonito, &
Giordano).  All three tables will be stored under the domain
".x400.arpa".  Change control will still be centralized -- the tables
will still be collected and managed by the Cosine MHS Project Team.
The use of the DNS tables will be described in a separate document
[action].  Mapping conventions are used to represent the RFC1327 table
entries in a format that is legal for the DNS.  Claudio will produce a
new version of the document, and distribute it to the DNS and x400ops
mailing lists [action].  If consensus is reached, the document will be
submitted as an Experimental RFC.

f) OSI area procedures.  Erik Huizer requested that to progress a
document in the OSI area as an Internet Draft, people should send email
to Dave Piscitello ([e-mail]), himself
([e-mail]) and CC the IESG Secretary Greg Vaudreuil
([e-mail]).  [Note - this information should probably
be sent to all the OSI area working groups. [action]]   Erik also
reported the following procedures for IETF OSI working groups
[actions]:

    - he will create a mailing list for these working group chairs
    - he will distribute each message to him from higher IETF people
	to working group chairs (chairpersons)

There was also discussion about what classes of RFCs there are.  RFCs
*not* on the standards track can be classified as "Informational" or
"Experimental".  RFCs on the standards track proceed from "Proposed
Standard" to "Draft Standard" to "Standard".  [Note - is this
documented in an RFC?]   It was also pointed out that RFCs cannot
reference Internet Drafts, but they may reference any class of RFC.


7.  Major Operation Problem - not discussed.


9.  Review of Action Items - deferred to mailing list, due to time.
    See below.


10. Any Other Business, and plan for next meeting - Erik Huizer (OSI
Area Co-Director) proposed to resume the "old" meeting schedule for
the OSI area at the next IETF.  Other than that, the next meeting
schedule not discussed.  Erik will distribute this new schedule
[action].

We decided to have the next x400ops meeting at the next IETF
meeting in Washington DC, U.S.A., during the week Nov. 16-20, 1992.


REVISED SUMMARY OF ACTION ITEMS:

1.  [done] Allan Cargille - distribute draft minutes.

2.  Alf Hansen - revise timetable for documents on new charter by
    discussion on the list.

3.  Tony Genovese - continue to work on a WEP which is accessible over
    public X.25.

4.  [done] Stef (Einar Stefferud) - start discussion on mailing lists about
    U.S.  ADMD naming issues.

5.  [done] Someone - email Stef to start this discussion.

6.  Stef - write an internet draft proposing to create ADMD=Internet.

7.  Jim Romaguera (NetConsult AG) - generate draft document that addresses
    the issue of ADMDs and how they are connected to the R&D world.

8.  Harald Alvestrand - update document on extended character sets and
    release as an Internet Draft.

9.  Alf - update Operational Requirements document and release as an
    Internet Draft.

10.  Allan - write draft document about postmaster addresses
     and release as an Internet Draft.

11.  Panos Tsigaridas - provide a set of detailed "short term" change
     requests to Urs' routing document.

12.  Urs - release revised version of routing coordination document
     (if there are any changes).  Hopefully get consensus on mailing
     list about the document and submit as an RFC.

13.  Claudio Allocchio - produce new version of the X.400 DNS paper and
     distribute it to the x400ops and DNS mailing lists.  If consensus
     is reached, submit document as Experimental RFC.

14.  Claudio - produce new document explaining how the X.400 DNS
     tables should be used and distribute to x400ops list.
    
15.  Erik Huizer - distribute information on the procedure for progressing
     a document in the IETF OSI area to all area mailing lists.

16.  Erik - create a mailing list for IETF OSI area working group chairs.
    
17.  Erik - distribute working group meeting schedule for OSI area for
     next IETF meeting.