Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/x400ops/x400ops-minutes-93nov.txt

Text File | 1994-02-08 | 21KB | 498 lines

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:
[e-mail].

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        [e-mail]
Harald Alvestrand        [e-mail]
Vadim Antonov            [e-mail]
C. Allan Cargille        [e-mail]
Urs Eppenberger          [e-mail]
Qin Fang                 [e-mail]
Tony Genovese            [e-mail]
Alf Hansen               [e-mail]
Jeroen Houttuin          [e-mail]
Erik Huizer              [e-mail]
Barbara Jennings         [e-mail]
Marko Kaittola           [e-mail]
Steve Kille              [e-mail]
Jim Knowles              [e-mail]
Jian Li                  [e-mail]
Lars-Johan Liman         [e-mail]
Karen Petraska-Veum      [e-mail]
Kenneth Rossen           [e-mail]
Srinivas Sataluri        [e-mail]
Richard Schmalgemeier    [e-mail]
David Staudt             [e-mail]
Panos Tsigaridas         [e-mail]
Brien Wheeler            [e-mail]
Jackie Wilson            [e-mail]
Russ Wright              [e-mail]