home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / mhsds / mhsds-minutes-92may.txt < prev    next >
Text File  |  1993-02-17  |  9KB  |  244 lines
  1.  
  2. INTERIM_MEETING_REPORT_
  3.  
  4.  
  5. Reported by Kevin Jordan/CDC
  6.  
  7. Minutes of the MHS-DS Working Group (MHSDS)
  8.  
  9. May 11, 1992
  10.  
  11. The following documents written by Steve Hardcastle-Kille are to undergo
  12. serious reviewing by the MHS-DS Group:
  13.  
  14.  
  15.   1. Representing Tables and Subtrees in the Directory
  16.   2. Representing the O/R Address hierarchy in the Directory Information Tree
  17.   3. MHS use of Directory to support MHS Routing
  18.   4. Use of the Directory to support mapping between X.400 and RFC 822 Addresses
  19.   5. MHS use of the Directory to support distribution lists
  20.   6. A simple profile for MHS use of Directory
  21.   7. Use of the Directory to support routing for RFC 822 and related protocols
  22.  
  23.  
  24. Classification by Harald Tveit Alvestrand
  25.  
  26.   1. Non controversial
  27.   2. Simple
  28.   3. This is the principal document.  You need to understand 1 and 2 first.
  29.   4. Simple use of 1 and 2
  30.   5. Simple 'repairing' of an X.400(88) bug
  31.   6. Terse.  You must understand 1, 2 and 3 first!  It tells you what
  32.      you need to implement as a minimum.
  33.   7. Terse.  This document is about applying the algorithms of 3 to
  34.      Internet-like networks.
  35.  
  36.  
  37. In addition, document 3 currently covers issues related to content
  38. conversion.  Harald has recommended that this be removed from document 3
  39. into a new document (8).
  40.  
  41. Harald also gave a short tutorial on the documents.  (This does not
  42. replace a serious reading of the documents by everybody but helps
  43. understanding the overall concept.)
  44.  
  45. Parallel efforts in ISO
  46.  
  47.                                    1
  48.  
  49.  
  50.  
  51.  
  52.  
  53. There exists also a proposal from Robert Willmoet, UK, distributed
  54. within OSI. It has a different concept.  Steve Hardcastle-Kille intends
  55. to forward his proposal also to ISO and CCITT. There is not much hope to
  56. get a stamp by CCITT since the proposal allows to bypass the ADMD
  57. infrastructure.  There is at least some hope to get it accepted within
  58. ISO.
  59.  
  60. Secretary's note:  (I learned in the mean time that DEC will release a
  61. X.400(88) SW with X.500 usage for MHS routing and mapping (Dec 1992).  I
  62. do not know the methods they use but it is probably different from
  63. Steve's and Robert's proposals.  I even do not know how the mapping
  64. works:  DEC, RFC987, RFC1148, RFC1327...)
  65.  
  66. Security
  67.  
  68. There is the still unsolved problem of the need of bilateral agreements
  69. to make the X.400 service a little bit more secure than SMTP. (There is
  70. the possibility of strong authentication in the applications.)  It is
  71. proposed to spend some time on inserting more security functions into
  72. Steves documents.  The hooks are already built in (see doc 3, chapter
  73. 20).
  74.  
  75. PAP: The researchers in the internet are happy with what they have now.
  76. With any new solution we should take the industrial community into
  77. account.  Authentication is an important topic there.
  78.  
  79. Questions and Answers
  80.  
  81. A part of the discussions was based on questions put forth by the
  82. meeting participants, and answers were provided mainly by those who have
  83. read Steve's papers.
  84.  
  85. Will people implement it?  Yes, Control Data and the ISODE Consortium
  86. will lead to two implementations.  Other commercial suppliers know that
  87. they must sort out the routing problem, so there might be a chance to
  88. get more implementations.  A solution for the EAN software depends on
  89. funding.
  90.  
  91. Will it work and be fast enough?  Probably.
  92.  
  93. Will people keep the data up to date?  Yes, as soon as it is needed for
  94. proper operation.
  95.  
  96. What happens with an email address containing ADMD=`single space'?  This
  97. is solved.  See doc 2 fig 1.
  98.  
  99. How to use trees?  How many trees are needed?  This is very open.
  100. Practical experience will show what is reasonable.  Doc 3 drafts several
  101. solutions.  Users will probably also start to set up private subtrees,
  102. on a service provider level as within networks, or even within
  103. universities where they do not want to publish user information in the
  104. public tree.
  105.  
  106.  
  107.                                    2
  108.  
  109.  
  110.  
  111.  
  112.  
  113. How to control access to the trees?  What info should go to the open
  114. tree?  Even UA information can be stored in the open tree.  It is
  115. possible to set ACLs such that UA/user information is hidden.  The
  116. routing algorithm will select routing information from higher up in the
  117. tree.
  118.  
  119. What is the behaviour of the algorithm, if it gets errors back on
  120. queries?  This may happen due to ACLs set, or unavailable DSAs,...  We
  121. need a list of possible failure reasons and a definition of the
  122. appropriate behaviour of the algorithm.
  123.  
  124. Where to locate the open tree?  Discussion lead to the proposal to put
  125. the routing tree under @O=x400routing.  This gives independence from the
  126. owners of the country entries.
  127.  
  128. How to optimise access to the DIT? Attribute inheritance was found a
  129. good solution to optimise DIT access.  Reading an attribute at the end
  130. of the DIT will then also give back the routing info stored higher up.
  131. Attribute inheritance is not defined in X.500 yet.
  132.  
  133. How does a network without DSA access send mail to the DSA-documented
  134. world/MTAs?  Such a network will have to have an agreement with an MTA
  135. which has access to DSAs.  At a first glance this seems feasible.  In
  136. addition, it will probably be necessary to develop tools which extract
  137. routing information from the directory and generate static tables like
  138. the tables currently used by the RARE X.400 community.  These tools will
  139. allow existing X.400 implementations to migrate toward direct usage of
  140. X.500 over time.
  141.  
  142. How does routing through body type converters work?  It is proposed to
  143. take this item out of the documents until the problems are better
  144. understood.
  145.  
  146. A pilot
  147.  
  148. Alf Hansen proposes to start a pilot project to check if the ideas
  149. really work.  A very simple implementation will be included in the next
  150. public release of PP. The pilot should take into consideration:
  151.  
  152.  
  153.    o The co-ordination of the MTA managers which start to use it
  154.    o Mechanisms for loading the directory information tree with existing
  155.      data
  156.    o Strategies for transition from current table-based routing and
  157.      mapping methods to Directory-based methods
  158.    o Implementation and distribution of tools to support MTAs in both
  159.      worlds, i.e., both Directory and table-based MTA's
  160.    o Time frame - date mentioned:  spring 1993
  161.    o The co-ordination could also be done in the COSINE-MHS framework.
  162.      This should then be included in the follow-up contract for the
  163.  
  164.                                    3
  165.  
  166.  
  167.  
  168.  
  169.  
  170.      organisation which wants to provide these services in 1993.
  171.  
  172.  
  173. The distribution list (all of the following addresses should work)
  174.  
  175.  
  176.    o mhs-ds@mercury.udev.cdc.com
  177.    o S=mhs-ds;OU=mercury;O=udev;P=CDC;A=ATTmail;C=US
  178.    o S=mhs-ds;OU=mercury;OU=oss;OU=arh;O=cpg;P=CDC;A=ATTmail;C=US
  179.  
  180.  
  181. will be used for the co-ordination of the pilot in a first stage.
  182.  
  183. Next Meeting
  184.  
  185. The next meeting of the MHS-DS Working Group will take place at the IETF
  186. meeting in Boston, Massachusetts.  Scheduled sessions are, Monday, July
  187. 13th at 4:00pm and Tuesday, July 14th at 9:30am.
  188.  
  189. Everybody is invited to attend this meeting.  Further discussion will
  190. also take place on the distribution list (see above).  Send request for
  191. registration to the list to:
  192.  
  193.  
  194.    o mhs-ds-request@mercury.udev.cdc.com
  195.    o S=mhs-ds-request;OU=mercury;O=udev;P=CDC;A=ATTmail;C=us
  196.    o
  197.      S=mhs-ds-request;OU=mercury;OU=oss;OU=arh;O=cpg;P=CDC;A=ATTmail;C=US
  198.  
  199.  
  200. Attendees
  201.  
  202. Harald Alvestrand        harald.alvestrand@delab.sintef.no
  203. Denis Buffenoir          denis.buffenoir.inria.fr
  204. Jim Craigie              craigie@jntg.ac.uk
  205. Havard Eidnes            havard.eidnes@runit.sintef.no
  206. Urs Eppenberger          eppenberger@switch.ch
  207. Andrew Findlay           Andrew.Findlay@brunel.ac.uk
  208. Ole Frendved Hansen      ole.frendved.hansen@uni-c.dk
  209. David Goodman            d.goodman@cs.ucl.ac.uk
  210. Alf Hansen               Alf.Hansen@delab.sintef.no
  211. Erik Huizer              huizer@surfnet.nl
  212. Wolfgang Jaretzki        jaretzki@dfn.dbp.de
  213. Kevin Jordan             kej@udev.cdc.com
  214. Peter Kaufmann           kaufmann@dfn.dbp.de
  215. Bruno Koechlin           bruno.koechlin@inria.fr
  216. Erik Lawaetz             uniel@uts.uni-c.dk
  217. Jean-Paul Le Guigner     leguigner@cicb.fr
  218. Thomas Lenggenhager      lenggenhager@switch.ch
  219. Damanjit Mahl            damanjit.mahl@brunel.ac.uk
  220. Michael Mueller          mueller@z1wnsv.gmd.de
  221. Hector Nunez             h.nunez@cs.ucl.ac.uk
  222.  
  223.  
  224.                                    4
  225.  
  226.  
  227.  
  228.  
  229.  
  230. Paul-Andre Pays          paul-andre.pays@inria.fr
  231. Catherine Pierre-Radenac catherine.pierre-radenac@inria.fr
  232. Colin Robbins            c.robbins@xtel.co.uk
  233. Jim Romaguera            romaguera@cosine-mhs.switch.ch
  234. Marjo Rottschaefer       marjo.rottschaefer@surfnet.nl
  235. Peter Sylvester          sylvester@gmd.de
  236. Katy Treca               treca@urec.fr
  237. Panos Tsigaridas         tsigaridas@fokus.berlin.gmd.dbp.de
  238. Ton Verschuren           ton.verschuren@surfnet.nl
  239. Peter Yee                yee@ames.arc.nasa.gov
  240.  
  241.  
  242.  
  243.                                    5
  244.