home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / osix400 / osix400-minutes-90dec.txt < prev    next >
Text File  |  1993-02-17  |  13KB  |  354 lines

  1.  
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6.  
  7. Reported by Judy Messing/MITRE
  8.  
  9. OSI X.400 Minutes
  10.  
  11. Agenda
  12.  
  13.  
  14.    o Review of Draft Proposal for the use of the Internet DNS to
  15.      maintain RFC 987/RFC 1148 Address Mapping Tables
  16.    o X.400 Deployment Issues
  17.    o XNREN Discussion
  18.    o Announcement of new Working Group
  19.    o Operational Issues Discussion
  20.  
  21.       -  PRMD Organization
  22.       -  Originator/Recipient Name Assignment
  23.       -  Address Mapping
  24.  
  25.  
  26. The meeting was convened by Robert Hagens, Working Group Chair.
  27.  
  28.  
  29. The revised ``Draft Proposal for the Use of the Internet DNS to Maintain
  30. RFC 987/RFC 1148 Address Mapping Tables'' (by Cole and Hagens) had been
  31. circulated on many mailing lists prior to the meeting.  This proposal
  32. describes how the DNS could be used to store, retreive, and maintain the
  33. mappings between RFC 822 domain names and X.400 O/R addresses.  The
  34. first order of business was the review of this draft proposal.
  35.  
  36.  
  37. The following issues were discussed and resoved during the review:
  38.  
  39.  
  40.   1. Placement of TO-X400 and TO-822 resource records in the DNS tree
  41.      (Section 4).  It was decided that both records should be placed
  42.      under the same DNS root.  This should be done in both the
  43.      transitional and experimental phase of using the DNS for the
  44.      mapping tables.  A suggestion was made to demonstrate this
  45.      placement more clearly in the document by a drawing of the domain
  46.      name hierarchy.
  47.  
  48.                                    1
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.    Steve Kille noted that placing the two records under the same root
  56.    provide a good facility for management of the mappings,
  57.    distribution of zones of the DNS, and for zone transfers.  Placing
  58.    the records under the same root will result in a routing
  59.    performance loss because it requires lookups in two trees.
  60. 2. Determination of name for T0-X400 and T0-822 root (Section 4).
  61.    Hagens suggested the root name ORMAP.ORG. Steve Kille suggested a
  62.    new top level domain .TABLE. Then the root name would be
  63.    ORMAP.TABLE. The consensus was to request a new top level domain
  64.    .TABLE. If this request was not granted, the records should be
  65.    placed in ORMAP.ORG.
  66. 3. Structure of O/R Address in Domain Name Syntax (Section 4.1):  Alf
  67.    Hansen proposed three alternative solutions:
  68.  
  69.      o The syntax given in Appendix F of RFCs 987 and 1148.
  70.      o An algorithmic, more human readable, syntax replacing blank
  71.        attributes with a hyphen.
  72.      o An algorithmic, more human readable, syntax dropping blank
  73.        attributes.
  74.  
  75.    Steve Kille remarked that the text syntax of RFCs 987 and 1148 are
  76.    now being used in other environments and strongly argued for
  77.    remaining aligned with that syntax.  This syntax is also used in
  78.    the DNS standard.  The consensus was to keep the syntax aligned
  79.    with the RFCs and to refer to RFC 1148 in the draft standard when
  80.    discussing the structure of the O/R addresses.  The RARE printable
  81.    format will be used in text examples.  In section 4.3, Step 2 of
  82.    the example, the wildcard count of 5 is a typo.  This will be
  83.    changed to 6.
  84. 4. Error Recovery (Section 4.4):  A discussion on the appropriate
  85.    action for the mapping algorithm based upon the DNS response code
  86.    resulted in a recommendation that this section be rewritten.  The
  87.    new section on Error Recovery will reflect the way RFC 1148 handles
  88.    the case where a hit is not found in the mapping lookup table.
  89. 5. RFC 1148 Issues:  The draft will reference RFC 1148 as the primary
  90.    address mapping document.  RFC 987 will be referenced as a
  91.    secondary document.
  92. 6. Proposed Resource Records (Section 3):  Hagens reported that the
  93.    types assigned to the new Resource Records defined in the document
  94.    are incorrect, but that real values would be assigned when the
  95.    draft is issued.
  96. 7. DNS Address Class (Section 6):  Discussion was held on whether the
  97.    new Resource Records should be assigned to the Internet address
  98.    class, IN, or the ISO address class, ISO. Suggestions for the
  99.    assigned address class were to omit it, use a wildcard, add a new
  100.    class called ``mapping'', or use IN. The question was raised as to
  101.  
  102.  
  103.                                  2
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.      whether the DNS implementations actually accepted an address class
  111.      other than IN. The decision was that IN would be acceptable, but
  112.      that Hagens would coordinate the address class assignment with Paul
  113.      Mockapetris.
  114.   8. Transition Phase (Section 5.3.2):  The consensus was to remove this
  115.      section from the proposed draft and expand it into a separate
  116.      document.  The current proposed draft and the new transition
  117.      document will reference each other.
  118.   9. Coordination and Administration (Section 5):  The proposed draft
  119.      spoke of the master copy of the mapping database as the copy stored
  120.      in the DNS namespace.  Steve Kille pointed out that there is a
  121.      global use of the mapping database and that it could be stored in
  122.      three forms:  table form, DNS form, or X.500 form.  At his
  123.      suggestion, the Working Group agreed that the proposed draft should
  124.      define a model on the global use of the mapping table and the
  125.      proposed transition document define the details of how the model
  126.      would be actualized.
  127.      The model is based on country.  As a national issue, each country
  128.      decides whether its master copy of the mapping database is stored
  129.      in the DNS, a table, or an X.500 directory.  If a country changes
  130.      from one master to another, it takes responsibility for moving from
  131.      its original master to its new master.  Procedures to follow when a
  132.      country chooses to transition from one master to another must be
  133.      developed.  Currently the RARE project is mastered in tables.  Each
  134.      country maintains its own tables and the RARE Working Group
  135.      maintains the global mapping table.  The United States will be
  136.      mastered in the DNS. At this time RARE is responsible for maintain
  137.      the mapping tables and the University of Wisconsin is responsible
  138.      for maintaining the DNS mapping records.
  139.  
  140.  
  141.  
  142. Discussion of XNREN PRMD
  143.  
  144.  
  145. Alf Hansen gave a presentation on the XNREN, the Wisconsin Internet
  146. X.400 pilot project PRMD. He made the following points:
  147.  
  148.  
  149.  
  150.    o XNREN is experimental in nature.
  151.    o XNREN is a production-quality service-oriented PRMD.
  152.    o XNREN can be joined by any organization willing to operate a local
  153.      X.400 service and contribute to a better understanding of
  154.      operational issues.
  155.  
  156.  
  157.  
  158.                                    3
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165. The Wisconsin pilot project will offer ARGO X.400 code to non-commercial
  166. private organizations.  Currently there are two X.400 implementations in
  167. XNREN: the University College London PP and Wisconsin ARGO X.400.  The
  168. pilot project is focusing on short term operational problems.  NSF has
  169. funded it for two years.  Participating organizations must agree to the
  170. following:
  171.  
  172.  
  173.  
  174.    o Register their organizations and organizational units with the
  175.      ad-hoc XNREN Naming authority.
  176.    o Appoint a MHS site manager.
  177.    o Operate any RFC987 gateway according to agreed upon rules.
  178.    o Define X.400/RFC822 address mappings.
  179.    o Use commonly agreed upon mappings.
  180.    o Use locally defined mappings.
  181.    o Route traffic external to XNREN according to specified rules.
  182.  
  183.  
  184.  
  185. The XNREN pilot is a member of the International RD Service.  It
  186. provides connectivity to Internet mail and, under the leadership of the
  187. Corporation for National Research Initiatives, plans to establish
  188. contact with the national ADMDs with the goal of negotiating
  189. interconnection agreements and experimental exchange of messages.  The
  190. XNREN PRMD is also interested in exchanging experiences and establishing
  191. connectivity with other Internet PRMDs.  XNREN will offer the following
  192. services:
  193.  
  194.  
  195.  
  196.    o Assist participants in the pilot in setting up their X.400 service.
  197.    o Produce informational material about service developments.
  198.    o Take an active role on X.400-related mailing lists.
  199.    o Allow testing of new software and procedures in XNREN.
  200.    o Incorporate X.400 technical innovations into experiments.
  201.    o Use the X.400 infrastructure to experiment.
  202.  
  203.  
  204.  
  205. Contact XNREN at:
  206.  
  207.  
  208.  
  209.      postmaster@cs.wisc.edu
  210.      or
  211.      X400-project-team@cs.wisc.edu.
  212.  
  213.                                    4
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220. MERIT is operating an X.400 gateway to Internet for SprintMail.  Mark
  221. Knopper expressed interest in directly routing to XNREN.
  222.  
  223.  
  224. New Working Group Announced
  225.  
  226.  
  227. Rob Hagens announced the formation of the X.400 Operations Working
  228. Group.  Its goal is to insure interoperability between Internet PRMDs.
  229. The first task of the group will be to draft a document that specifies
  230. requirement/conventions of Internet PRMDs.  Membership in this Working
  231. Group will be limited to people with planning, deployment, and
  232. operational responsibilities.  The Working Group will address the
  233. following issues:
  234.  
  235.  
  236.  
  237.    o Basic Assumptions
  238.    o Connectivity
  239.       -  Stack Choice
  240.       -  Degree of interconnection
  241.    o Routing
  242.       -  Necessity of well-known entry point
  243.       -  Policy on transit traffic
  244.       -  How to connect to ADMDs
  245.    o Collective representation of PRMDs
  246.       -  Internationally
  247.       -  Interacting with public carriers
  248.    o Forum for addressing mapping coordination
  249.    o 1984/1988 issues
  250.    o X.500 issues
  251.  
  252.  
  253. The group discussed the necessity of forming a new Working Group.  Steve
  254. Kille wondered if the work was not within the scope of this Working
  255. Group.  Hagens said that the new Working Group was operational and
  256. motivated toward concrete progress.  He also said that if the current
  257. Working Group had completed its agenda, it could be dissolved.  The
  258. first meeting of the X.400 Operations Working Group will be February
  259. 4-6, 1991 at NASA-Ames.
  260.  
  261.  
  262. Operational Issues Discussion:  PRMD Organization
  263.  
  264. Rob Hagens announced that a preliminary meeting of X.400 operational
  265. people had been held on November 28 at the University of Wisconsin.  The
  266. following general assumptions had evolved for the Internet PRMDs:
  267.  
  268.  
  269.  
  270.                                    5
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.    o PRMDs can be directly connected to each other.
  278.    o PRMDs will not all be directly interconnected.
  279.    o PRMDs must have unique names in the US.
  280.    o A PRMD can be a naming authority for its organizations.
  281.    o A PRMD can be connected to 0 or more ADMDs.
  282.    o X.400 addresses should reflect organizational structure.
  283.  
  284.  
  285.  
  286. Address Mapping
  287.  
  288. Alf Hansen presented two proposed methods of address mapping when a user
  289. of an X.400 system wants to send mail to a user of an RFC 822 system and
  290. vice versa.  One solution consists of mapping the elements of the
  291. receiver's mail system address into elements of the sender mail system
  292. address structure.  The receiver address then looks like a valid address
  293. of the sending mail system.  In the second solution, the receiver's
  294. address is left in the syntax of his mail system.  For the X.400 to RFC
  295. 822 case, the recipients address is placed in a Domain Defined Attribute
  296. and the Organization indicates the community the address refers to,
  297. e.g., Internet or RFC822.  In the RFC 822 to X.400 case, the recipient
  298. address is placed in quotes in the left-hand side term of the domain
  299. name; the community it placed on the right-hand side of the @ sign.  The
  300. group discussed the mapping issues, but no decision was made.  Steve
  301. Kille warned that if the chosen solution generates X.400 addresses than
  302. messages with those addresses must be able to be delivered.
  303.  
  304.  
  305. 1988 X.400
  306.  
  307.  
  308. Steve Kille suggested that the Working Group name 1988 X.400 as the
  309. Internet supported standard.  He pointed out that 1988 X.400 supported
  310. directory, security, distribution lists and the message store.  Kille
  311. said one defect of 1988 X.400 was that it did not allow a 1984 X.400
  312. user to address an arbitrary 1988 user.  However, he said he had a
  313. simple proposal that he intended to specify to correct this problem.  In
  314. the discussion, it was pointed out that GOSIP does not specify 1988
  315. X.400 until GOSIP Version 3, which is two years away.
  316.  
  317.  
  318. The final discussion of the meeting centered on determining if there was
  319. any interest in writing a MIB for X.400 and X.500.
  320.  
  321.  
  322. Attendees
  323.  
  324. David Brent              brent@CDNnet.ca
  325. Lida Carrier             lida@apple.com
  326.  
  327.                                    6
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334. Robert Cooney            cooney@wnyose.nardac-dc.navy.mil
  335. Curtis Cox               zk0001@nhis.navy.mil
  336. Robert Hagens            hagens@cs.wisc.edu
  337. Alf Hansen               Alf.Hansen@pilot.cs.wisc.edu
  338. Steve Kille              S.Kille@cs.ucl.ac.uk
  339. Mark Knopper             mak@merit.edu
  340. Walter Lazear            lazear@gateway.mitre.org
  341. John Linn                linn@zendia.enet.dec.com
  342. Judy Messing             messing@gateway.mitre.org
  343. Tim Seaver               tas@mcnc.org
  344. Theresa Senn             tcs@cray.com
  345. Harvey Shapiro           shapiro@wnyose.nardac-dc.navy.mil
  346. Linda Winkler            b32357@anlvm.ctd.anl.gov
  347. Dan Wintringham          danw@osc.edu
  348. Russ Wright              wright@lbl.gov
  349. Peter Yee                yee@ames.arc.nasa.gov
  350.  
  351.  
  352.  
  353.                                    7
  354.