CURRENT_MEETING_REPORT_
Reported by Alan Cargille/University of Wisconsin
Minutes of the X.400 Operations Working Group (X400OPS)
Executive Summary
o The Amsterdam minutes were not approved. They will be revised.
o The postmaster document will receive final editorial comments and
be submitted for consideration as a standards-track RFC.
o The management domains requirements document will receive final
editorial comments and be submitted for consideration as an
Informational RFC.
o A revised document on storing RFC 1327 mapping rules in the DNS
will be released within a few weeks. A new companion document
about how this should be administratively implemented and deployed
will be written by the next IETF or the meeting of the RARE Working
Group on messaging.
o The proposed CXII group will continue to be discussed on the cxii
list. If it cannot be finalized by the Seattle IETF, the group
will probably not be created.
o The work on ADMD IMX is viewed as a United States national issue
and should be developed in some US forum, not the IETF. The work
should be fed back into the IETF for comments and publication.
o A sister group to the IETF on operations may be created (the IOTF).
o The X400OPS Working Group will be terminated following this IETF.
Outstanding work items can be brought up on the X400OPS mailing
list. If worthwhile, a small focused working group will be created
to work on the new topic.
Thanks to Tony Genovese and Alf Hansen for chairing this group.
Goodbye, and thanks for all the fish!
Review of Action Items
This was difficult to do because action items were not summarized in
previous minutes. This section will be updated as the Amsterdam minutes
are revised.
Jim Romaguera conducted the review of the minutes from the last meeting.
They are were not approved. They had been submitted in a rush. Alf and
Tony apologized for incomplete minutes being published. Marko and Urs
had sent messages requesting changes to the minutes which were not made.
Marko's name was misspelled in Section 6. He was unhappy with the
proposed chairs in Section 10.
The Amsterdam minutes will be reviewed again on the list and revised.
Allan Cargille foolishly volunteered to edit the revised minutes.
Action items need to be identified, both those from the previous meeting
(Columbus) at the beginning of the document and those from Amsterdam in
the body. We can also check the X400OPS list archive for comments on
the minutes.
Postmaster Convention for X.400 Operations
Allan Cargille reviewed the key idea of the document. He removed the
section about supporting an easy way to reach the managers of an X.400
management domain (ADMD or PRMD) out of the document and plans to write
that up in a separate document (edit out the part about 84 and 88, just
say both are running and reference both standards). There was consensus
that the group will forward the document for consideration as a
standards-track RFC. Allan will revise the document and clean up the
references. He will then publish it as an Internet-Draft and ask for
comments for one week on the ops list. This final review is for
editorial comments only. Allan will make any necessary corrections and
forward the document to be published. Allan will have the revised
Internet-Draft out by November 8.
Operational Requirements for X.400 Management Domains
Alf made editorial changes to the document and cleaned up the
references. Few people have read the final version. The document is
available and key people are asked to review the document for editorial
changes: Tony, Urs, Jeroen, Harald, and Allan. We will close
discussion by November 15. People who read the document should let Alf
and Tony know that they have read it. Tony will buy a beverage for the
person who finds the most typos!
DNS support for RFC 1327 Mapping
Claudio has been working on a mechanism to store and look up RFC 1327
mappings using the DNS. The first proposal received some strong requests
for changes from the namedroppers mailing list (DNS experts) at the
March 1993 IETF. Claudio had also done work on storing X.400 routing and
MTA connection information in the DNS. This work has been suspended in
favor of using X.500 (the IETF MHSDS Working Group work).
Claudio has developed a second version of his proposal. The document
will be published as an Internet-Draft this coming week. He presented
the major changes of the new approach. The new approach defines a new
DNS resource record which allows a single DNS query for a lookup. Some
extensions are also included for eventual future use. The new approach
stores Table 2 (822 to X.400) and ``Gateway Table'' mappings in the
normal DNS domain tree. Table 1 (X.400 to 822) mappings will be stored
in a separate tree, rooted at the national level. This approach forces
coordination between the X.400 and DNS naming authorities. This will
require considerable work in explaining concepts and coordinating
things. Claudio said there is a need for an API specification.
Mapping coordination at the national level will be achieved in different
steps, according to the draft document on mapping authorities. It fits
into the regionalization process currently ongoing in the internet. It
allows a full authority delegation as a final result of the process. An
orderly transition is supported from centralized storage of the mapping
rules in Italy to using the new national mapping tree, because software
will support checking the national tree first and looking in the Italian
tree if nothing was found.
Mapping rule storage and control will proceed in three different steps:
1. The information is maintained centrally in Italy and servers
fallback to that location for lookups.
2. The national trees are implemented but things are centralized at
the national level.
3. The information is truly distributed in the national trees.
The document also makes it possible to define a DNS/x.500 interface to
make LONGBUD and DNS a unique schema for mapping distribution, with no
duplication and global accessibility.
There was general concern about an update problem with two distributed
mapping storage technologies (DNS and X.500). Urs said that the
technical work is done and is solid, and that we need to think about the
administrative work that is necessary to use this technology. The group
notes that this work has implications on the MHSDS Working Group.
Claudio will write a separate document about information and deployment
of this technology by the next RARE MSG or IETF meeting. Further
discussion of both documents will proceed in the RARE Working Group on
messaging.
Commercial X.400 Interconnection with Internet (CXII) Working Group
A proposed charter was included as input to this meeting. Tony Genovese
led this discussion. Tony's slides are on the ESnet file server (FTP to
ftp.es.net, the directory is pub/mhs/x400ops/houston).
o Since Amsterdam:
- There are two points of contention: chairs and technical
contributors.
- The chairs will be determined solely by the Area Directors.
- Technical leads are needed for document sets.
- There is already one volunteer co-chair, but another is still
needed.
- Technical leads for documents are needed.
- The working group will be in the Operations Area but Erik
Huizer (without his co-director) will serve as Area Director
for the group.
o Questions:
- Should the area be worked on? (SK - in general? Or in IETF?)
- Are there problems in this area? (agreement: YES)
- Which problems?
- Who wants to work on them?
- Will any commercial providers come in and participate? Erik
working to get EMA and EEMA participants, and may be able to
find a co-chair for the group from a commercial service.
o Attendee Input:
- Steve:
There is a report on EEMA work in this area. The issue was
raised in the EEMA PRMD operators group---requirement for X.400
to Internet working. X.400 mail users wish to communicate with
the Internet and vice-versa. It is not service provider
initiated, but user initiated by big customers. X.400 is real
and a large group is using it and is serious about using it.
There were two meetings with large attendance on
interconnecting. Jim Romaguera contracted to write a series of
reports for that group---were they circulated to the x400ops
list? There are two issues: technical and commercial. The
technical work is essentially completed. Real issues are
commercial ones. To make this fly a commercial model must be
built which will allow interoperation between these
communities. It is quite clear that if you do not find a
commercial model that will accommodate both worlds then we have
a serious problem. Commercial---pay for e-mail service.
Internet - pay for pipe, e-mail ``free.'' GOMHS using internet
model. Need to develop a viable commercial model. Users are
prepared to pay for services as long as charges are reasonable
(appropriate). IP providers and X.400 providers are competing
with each other. Have to formulate a connection in a way which
protects the operational interests of both parties. Have a
problem if you just expect the ADMDs to connect up for free.
Steve chairing small group of five people in EEMA---two
Internet providers and two commercial providers (DBP and
Mercury, UK) trying to put together a commercial proposal---a
small forum to try to make progress on this.
- Tony:
Concerned about EEMA putting out documents with no review
process, Internet input.
- Steve:
Feels a forum is needed which balances Internet and ADMDs, or
is heavy on ADMDs. In a group which is mostly research and
development the ADMDs will not be comfortable and progress will
not be made.
Model problem---ADMDs cannot talk to anyone who is
``responsible'' for the Internet mail service.
- Tony:
The real problem is that national mail services make agreements
but the agreements do not cover the whole Internet community,
just that specific community.
- Marko:
EEMA small forum is strictly commercial (IP and ADMD) and the
research and development community is not represented.
- Harald:
In the IETF, work is done by informal design teams, and working
groups are for review and discussion. Is it a good idea to
have the review process in this group (x400ops) or elsewhere in
the IETF for EEMA outputs?
- Erik:
Sees the need for work in the IETF forum. Sees need for EEMA
work. Not too happy with small EEMA team because both are
commercial providers (IP and ADMD). There is tradition and
experience in the IETF community. We have a community to serve
which needs to be connected to ADMD world. Need to get our own
perspectives right on how we think these services should be
operated. Need to start thinking about service levels, with
commercial perspective. Need to understand what the commercial
world wants, and whether our customers want that too, if we can
live up to it too, etc., if so, what are the requirements and
what do we have to do to get to that point? He does not see
necessary progress happening if EEMA output is not subject to
review and is imposed on the Internet community.
- Steve:
EEMA assumes CXII work will happen, and will liaison with the
group if it occurs.
- Erik:
No use to do CXII work unless we can get commercial
participation. Only has use if we do this in a real
collaborative effort with the ADMD community. Sees a real use
for that.
- Urs:
It seems like CXII is trying to find business arrangement
between service providers. This is not the IETF's business.
- Steve:
* Short discussion of problems
* Agreements that could be put in place
* How do you coordinate the whole thing
* Will never find one model that does everything---connects
whole Internet to entire X.400 service. Need to show how to
tie the pieces together. Connecting X.400 commercial
services to the Internet e-mail community (822 and X.400)
will include many pieces.
- Erik:
Let's focus. Identify the errors which are not covered by the
documents we have done yet, which are worthwhile covering:
mapping coordination, accounting, service levels, helpdesks,
levels of logging and trouble shooting, etc. There will not be
a BOF in Seattle if the list does not reach consensus by then.
Purpose of the first document is vague. The second and third
identify exact points that need to be covered. If there is
agreement, a meeting can be held in Seattle. Need to specify,
``This document is trying to address the following problems:
...''
- Allan C.:
Documenting various business models is highly appropriate.
Imposing one business model is not. Documenting them would be
very helpful. Others agreed with this.
A small group met for a follow-on CXII discussion. The results of this
meeting will be mailed to the cxii list.
US-ops
Allan Cargille led this discussion. He outlined two different issues
which fall under this agenda item:
o The work on ADMD IMX under C=US.
o The need for a forum for Internet-related issues which are specific
to the United States or North America.
There are questions about whether ADMD IMX should be viewed as a United
States issue or an Internet-wide issue. It can be viewed as an
Internet-wide solution which happens to be stuck under C=US due to the
X.400 country-centric addressing structure. For example, if C=WW
(worldwide) existed, we would prefer to register ADMD IMX under C=WW and
it would not be bound to the Unites States. Alternatively, it can be
viewed as the Unites States national solution to X.400 naming in the US
Internet, which is US-centric and should be developed in a United States
forum.
The second issue is that the IETF developed in the context of the US.
Therefore work on an issue which was Internet-related could be conducted
in the IETF, even if the work was US-centric. Now that the IETF has
developed its identity as an international organization,
Internet-related topics which are United States or North American in
scope do not have a valid forum. The problem was recognized by the
group, but addressing this problem is outside the scope of the X400OPS
Working Group.
o Attendee Input:
- Erik:
IMX work should not be in the IETF; the IESG agrees. They do
not want to solve US national issues. There is support in the
IAB for the development of a new international group, the IOTF
(Internet Operations Task Force). Someone is needed to drive
and chair it, and put structure in place. The structure is
still open---might have areas and regionals within areas. For
example, the X.400 area could have North American and European
groups. Area directors would ensure coordination between
groups. Someone is needed to work on this and pull it off.
Erik plans to talk to Vint on Thursday. Someone is needed with
impact in various organizations, who can get commitments from
organizations to send people. This person should have
visibility and support from funding agencies. Organizations
must also participate. The IESG and IAB are behind this idea.
Allan and Erik talk to Vint on Thursday? People recognize the
need for it. Erik would go for someone high up in operators
groups; a US person should lead this. Most likely the IOTF
will be established within six months or it will not proceed
any time soon. Initially it will probably meet in parallel
with IETFs; maybe not later.
Erik stated that IMX is not a good solution for the world, even
though it might be for the US.
- Alf:
Should each country write a similar document?
- Allan C.:
Would C=us; ADMD=IMX be used in other countries? Other people
all said no. This implies it is more of a national issue. The
forum is unclear; perhaps the budding IOTF would be a forum for
this work.
- Jeroen:
Engineering efforts should not be fragmented. IMX is not
operational so IOTF is not the right forum for that work.
- Erik:
The IMX document should be published as an Informational RFC.
It will not get IESG review. The Document should be reviewed
by X400OPS participants but will not be progressed as a working
group document.
Erik predicts future regionalization of the IETF. RARE will
become the European committee of ISOC. Some North American
group will also be created. There will still be overall ISOC
coordination.
- John K.:
Even if the IETF does not regionalize, the future will be much
more coordinated with different groups such as RARE, ISO
groups, etc.
What Next
Erik commented that the ops list should be kept open because of the
documents being progressed. He also noted that the RARE Working Group
on messaging could be used for some topics. If discussions raise
technical issues that merit IETF work, he would welcome a proposal for
that group (not just an extension of X400OPS but a focused group for 1/2
year or so to work on a specific issue.)
Urs pointed out that there is a specific list for RFC 1465 issues:
rfc1465@chx400.switch.ch.
Jeroen has copies of tutorial papers, and RARE can send more copies if
needed.
Allan sees the following as outstanding work items:
o A document on the long-range plan for X.400 in the Internet.
o Possible work on dynamic X.400 routing using the DNS. X.500 work
(mhsds/LONGBUD) is not materializing fast enough.
o X.400(88) in the GO-MHS community.
o A standard way to address the managers of an X.400 management
domain (PRMD or MD).
o A document on internal operations of ADMD IMX.
o A document on connections between ADMD IMX and ADMDs.
It appears that the IMX work will not be approved to be done in the
context of the IETF.
Steve was also concerned about mhsds delays. It is a very high priority
for specifications and for implementation. A global solution is needed
for scalable routing, he sees X.500 as the only viable solution.
Erik wants focused groups in future. The problem is that groups can
have beautiful ideas about what needs to be done, but there must be
volunteers to do the work. People are needed to chair the groups, write
the documents, and lead discussions.
Erik thanked Alf and Tony for chairing the group. The working group
will be terminated after this IETF.
Attendees
Claudio Allocchio Claudio.Allocchio@elettra.trieste.it
Harald Alvestrand Harald.T.Alvestrand@uninett.no
Vadim Antonov avg@icm1.icp.net
C. Allan Cargille allan.cargille@cs.wisc.edu
Urs Eppenberger eppenberger@switch.ch
Qin Fang qin_fang@unc.edu
Tony Genovese genovese@es.net
Alf Hansen Alf.Hansen@uninett.no
Jeroen Houttuin houttuin@rare.nl
Erik Huizer Erik.Huizer@SURFnet.nl
Barbara Jennings bjjenni@sandia.gov
Marko Kaittola Marko.Kaittola@funet.fi
Steve Kille S.Kille@isode.com
Jim Knowles jknowles@binky.arc.nasa.gov
Jian Li jian@rice.edu
Lars-Johan Liman liman@ebone.net
Karen Petraska-Veum karen.veum@gsfc.nasa.gov
Kenneth Rossen kenr@shl.com
Srinivas Sataluri sri@internic.net
Richard Schmalgemeier rgs@merit.edu
David Staudt dstaudt@nsf.gov
Panos Tsigaridas Tsigaridas@fokus.gmd.de
Brien Wheeler blw@mitre.org
Jackie Wilson Jackie.Wilson@msfc.nasa.gov
Russ Wright wright@lbl.gov