home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
x400ops
/
x400ops-minutes-92jul.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
24KB
|
535 lines
Editor's Note: Minutes received 8/12
CURRENT_MEETING_REPORT_
Reported by Allan Cargille/UWisc
Minutes of the X.400 Operations Working Group (X400OPS)
First Session
Alf Hansen Chaired the meeting. Allan Cargille volunteered to take
Minutes. The Agenda was modified to discuss Working Group status and
the status of the Wisconsin NSF X.400 Project and the Cosine MHS
Project.
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 of the documents. Note: this was not done in the meeting,
and should be done on the mailing list. Action - Alf
Other issues discussed during the first session included:
o 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.
This prompted the following discussions:
- 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 MAILSERVER@RARE.NL 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 wg-msg@rare.nl, or
/S=wg-msg/O=rare/PRMD=surf/ADMD=400net/C=nl/.
o 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
1
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.
o 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 (COS) 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 U.S. 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).
2
[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
o 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 percent 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
3
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.
4
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
5
approved in the future, this paper could evolve into an RFC.
The Working Group 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.]
o Future U.S. Internet X.400 organization - not discussed beyond the
above information.
Second Session
o Continuation of Connections to ADMDs Discussion. - 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 and 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 (cont'd) section courtesy of Jim R.]
o Document Review - in general, detailed comments are not included if
a new version of the document will be released.
a. ``X.400 use of extended character sets'' (Harald Alvestrand).
6
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.
b. ``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.
c. ``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].
d. ``Using the Internet DNS to maintain RFC987/RFC1148 Address
Mapping Tables and X.400 Routing Informations'' (Allocchio, Bonito,
7
& 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.
e. 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 (dave@sabre.bellcore.com), himself
(huizer@surfnet.nl) and CC the IESG Secretary Greg Vaudreuil
(gvaudre@nri.reston.va.us). [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.
o Major Operation Problem - not discussed.
o Review of Action Items - deferred to mailing list, due to time.
See below.
o 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
Allan Cargille Distribute draft Minutes. - Done.
8
Alf Hansen Revise timetable for documents on new Charter by
discussion on the list.
Update Operational Requirements document and
release as an Internet Draft.
Tony Genovese Continue to work on a WEP which is accessible
over public X.25.
Einar Stefferud Start discussion on mailing lists about U.S. ADMD
naming issues. - Done.
Write an Internet Draft proposing to create
ADMD=Internet.
Someone Email Stef to start this discussion. - Done.
Jim Romaguera (NetConsult AG) Generate draft document that
addresses the issue of ADMDs and how they are
connected to the R&D world.
Harald Alvestrand Update document on extended character sets and
release as an Internet Draft.
Panos Tsigaridas Provide a set of detailed ``short term'' change
requests to Urs' routing document.
Urs Eppenberger 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.
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.
Produce new document explaining how the X.400 DNS
tables should be used and distribute to x400ops
list.
Erik Huizer Distribute information on the procedure for
progressing a document in the IETF OSI area to
all area mailing lists.
Create a mailing list for IETF OSI area Working
Group Chairs.
Distribute working group meeting schedule for OSI
area for next IETF meeting.
Attendees
9
Ed Albrigo ealbrigo@cos.com
Claudio Allocchio c.allocchio@elettra.trieste.it
Harald Alvestrand Harald.Alvestrand@delab.sintef.no
C. Allan Cargille cargille@cs.wisc.edu
Chris Chiotasso chris@artel.com
Cyrus Chow cchow@orion.arc.nasa.gov
Alan Clegg abc@concert.net
Curtis Cox ccox@wnyose.nctsw.navy.mil
Richard desJardins desjardi@boa.gsfc.nasa.gov
Tom Easterday tom@cic.net
Urs Eppenberger eppenberger@switch.ch
Tom Farinelli tcf@tyco.ncsc.mil
Osten Franberg euaokf@eua.ericsson.se
Jisoo Geiter geiter@gateway.mitre.org
Tony Genovese genovese@nersc.gov
Arlene Getchell getchell@nersc.gov
Alf Hansen Alf.Hansen@delab.sintef.no
Steve Hardcastle-Kille s.kille@isode.com
Erik Huizer huizer@surfnet.nl
Takashi Ikemoto tikemoto@xerox.com
Kevin Jordan kej@udev.cdc.com
Mark Knopper mak@merit.edu
Jim Romaguera romaguera@cosine-mhs.switch.ch
Einar Stefferud stef@nma.com
Panos-Gavriil Tsigaridas tsigaridas@fokus.berlin.gmd.dbp.de
Linda Winkler lwinkler@anl.gov
Steven Winnett swinnett@bbn.com
Russ Wright wright@lbl.gov
10