home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / mhsds / mhsds-minutes-93jul.txt < prev    next >
Text File  |  1993-09-22  |  14KB  |  328 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Keven Jordan/Control Data Systems
  5.  
  6. Minutes of MHS-DS Working Group (MHSDS)
  7.  
  8.  
  9. Introductions and Administrivia
  10.  
  11. The meeting opened with participant introductions and statements of
  12. interests in MHS-DS and Project Long Bud.  The minutes from the Columbus
  13. IETF were then approved.  It was pointed out that the MHSDS Working
  14. Group is now under the new Service Applications Area with Dave Crocker
  15. as the SAP Area Director.
  16.  
  17.  
  18. Action Items
  19.  
  20.    o Eight Internet-Drafts were updated by Steve Kille.
  21.  
  22.    o Three of the Internet-Drafts were recommended to be progressed as
  23.      Proposed Standards, after some minor editorial changes:
  24.      ``Representing the O/R Address hierarchy in the Directory
  25.      Information Tree''
  26.      ``Representing Tables and Subtrees in the Directory''
  27.      ``Use of the Directory to support mapping between X.400 and RFC 822
  28.      Addresses''
  29.  
  30.    o The Internet-Draft, ``MHS use of Directory to support MHS
  31.      Routing,'' was recommended to be published as an Experimental RFC
  32.      after minor editorial changes.
  33.      Although there are some minor editorial and technical errors, no
  34.      substantive errors exist in this document.  This document now needs
  35.      some higher degree of visibility.  Two independent implementations
  36.      already exist and provide proof of the basic concepts.  Project
  37.      Long Bud will show if the concepts scale well by deploying MHS-DS
  38.      in the Internet.  The working draft is stable enough to be
  39.      published as an RFC. The Experimental status is initially
  40.      appropriate since Long Bud feedback might result in important
  41.      changes.  The final goal is to place the routing document onto the
  42.      standards track.
  43.  
  44.    o The ``Simple Profile'' document is a facilitating document and it
  45.      should be dropped once the pilot is further along and
  46.      implementations become more mature.  Most of the content of this
  47.      document can be merged into the routing document, specifying some
  48.      of the functionality as mandatory and some as optional.  This has
  49.      been done for other Internet protocol specifications.
  50.  
  51.    o It was suggested that an acronym be created for the document set
  52.      (e.g.  MIME), as RFC numbers change, but the acronym would continue
  53.      to be meaningful.
  54.  
  55.  
  56.    o Summary of documents and the working group's recommendations for
  57.      progression:
  58.  
  59.       -  draft-ietf-mhsds-infotree-03, ``Representing the O/R Address
  60.          hierarchy in the Directory Information Tree,'' progress as
  61.          Proposed Internet Standard.
  62.  
  63.       -  draft-ietf-mhsds-subtrees-03, ``Representing Tables and
  64.          Subtrees in the Directory,'' progress as Proposed Internet
  65.          Standard.
  66.  
  67.       -  draft-ietf-mhsds-supmapping-03, ``Use of the Directory to
  68.          support mapping between X.400 and RFC 822 Addresses,'' progress
  69.          as Proposed Internet Standard.
  70.  
  71.       -  draft-ietf-mhsds-routdirectory-03, ``MHS use of Directory to
  72.          support MHS Routing,'' progress as Experimental Specification.
  73.  
  74.       -  draft-ietf-mhsds-822dir-03, ``Use of the Directory to support
  75.          routing for RFC 822 and related,'' needs more review and
  76.          discussion.
  77.  
  78.       -  draft-ietf-mhsds-convert-01, ``MHS use of Directory to support
  79.          MHS Content Conversion,'' needs more review and discussion.
  80.  
  81.       -  draft-ietf-mhsds-mhsprofile-03, ``A simple profile for MHS use
  82.          of Directory,'' informational document to be dropped
  83.          eventually.
  84.  
  85.       -  draft-ietf-mhsds-long-bud-intro-00, ``Introducing Project Long
  86.          Bud,'' to be edited and reposted as an Internet-Draft.  Will be
  87.          progressed as an Informational RFC as soon as possible.
  88.  
  89.  
  90. Summary of Actions from Last Meeting
  91.  
  92.    o Kevin Jordan to write an Internet-Draft providing an overview of
  93.      the main set of MHS-DS RFCs.  Status:  not done, but some progress
  94.      has finally been made.
  95.  
  96.    o Harald Alvestrand to write pseudo code for the routing document.
  97.      Status:  not done.
  98.  
  99.    o Steve Kille to update the document set and repost as
  100.      Internet-Drafts.  Status:  done.
  101.  
  102.    o Jim Romaguera to coordinate the writing of Project Long Bud
  103.      definition and participation document(s).  Status:  done.  The
  104.      ``Introduction to Project Long Bud'' document was written and
  105.      submitted as an Internet-Draft.  Sylvain Langlois is the principal
  106.      editor.
  107.  
  108.    o Urs Eppenberger to write specifications for a tool which can be
  109.      used to browse and verify X.500 routing and address mapping
  110.      information.  Status:  not done.  This tool is desirable but Urs
  111.      can not commit the time to write its specification.
  112.  
  113.    o Panos Tsigaridas to write specifications for, and begin
  114.      implementation of, tools for synchronizing X.500 directory
  115.      information with GO-MHS routing and mapping tables.  Status:  done.
  116.      A beta version of a tool for reading information from the directory
  117.      and generating GO-MHS tables can be found on the MHS-DS file
  118.      server.
  119.  
  120.    o Kevin Jordan and Long Bud Design Team to prepare an informal MHS-DS
  121.      demonstration at IETF in Amsterdam.  Status:  done.  Kevin
  122.      demonstrated live MHS-DS technology and tools in the public
  123.      terminal room of the RAI Conference Center.
  124.  
  125.  
  126. Long Bud Report
  127.  
  128.    o The meeting participants reviewed the extent of MHS-DS information
  129.      available in the Internet DIT.
  130.  
  131.    o All of the US MTA and organizational information provided in the
  132.      routing documents available from the University of Wisconsin has
  133.      been added under c=US. However, it seems that most of the MTAs
  134.      registered under PRMD=XNREN no longer exist; most do not respond to
  135.      connection requests.  Perhaps the overall state of PRMD=XNREN needs
  136.      to be reviewed.
  137.  
  138.    o Countries in the DIT having MHS-DS routing entries include:  the
  139.      United States (US), Great Britain (GB), Denmark (DK), Germany (DE),
  140.      Switzerland (CH), Spain (ES), Portugal (PT) and France (FR).
  141.  
  142.  
  143. Review of ``Introduction to Project Long Bud''
  144.  
  145.    o A question was asked concerning whether Long Bud participants
  146.      should use static tables as the primary source of routing
  147.      information and fall back on X.500, or whether X.500 should be the
  148.      primary source of routing information with fall-back to static
  149.      tables.  The group concluded that the real aim of Project Long Bud
  150.      is to prove the MHS-DS technology.  Therefore, participants should
  151.      use the Open Community Routing Tree in the X.500 DIT as the primary
  152.      source of routing information.  This tree, possibly combined with
  153.      private routing trees, can also provide default routes to the rest
  154.      of the GO-MHS community to provide full connectivity.
  155.  
  156.    o It was explained that a routing entry within the DIT could point to
  157.      a relay MTA that knows about the WEPs, and the WEPs can reach
  158.      everyone.
  159.  
  160.    o Initially, Long Bud participants probably should not configure WEPs
  161.      as Long Bud MTAs, as Long Bud is a pilot project whose purpose is
  162.      ``proof of concept.''  Consequently, it is experimental in nature,
  163.      and WEPs should be providing a reliable, production-level service.
  164.  
  165.    o The `Benefits' section of the Long Bud Internet-Draft should not be
  166.      the last section in the document.  It should be moved to the
  167.      beginning because it is one of the most important aspects of the
  168.      document.
  169.  
  170.    o The Long Bud Internet-Draft will be updated to document the
  171.      existence of the Project Long Bud `Status Report'.
  172.  
  173.    o If a country or ADMD cannot establish its own entry in the DIT then
  174.      a skeletal entry will be added and managed until the rightful owner
  175.      asks to administer its own entry.  Some people questioned whether
  176.      this could really be done, in general, for country entries.
  177.  
  178.    o The `Open Tree' must be populated with entries for MTAs that are
  179.      willing to accept calls from any other MTAs in the Long Bud
  180.      community.
  181.  
  182.    o Policy - People who are responsible for parts of the DIT must take
  183.      responsibility for managing the data and for providing a good
  184.      quality of service.
  185.  
  186.    o The Long Bud Internet-Draft will be updated and redistributed by
  187.      the middle of August.
  188.  
  189.    o The MHS-DS file-server will be updated to include all Long Bud
  190.      documentation and public domain tools.
  191.  
  192.    o It was suggested that MHS-DS object class and attribute definitions
  193.      for Quipu oidtable files be included on the file server.
  194.  
  195.  
  196. Implementations and Tools
  197.  
  198. The current status of MHS-DS implementations and tools was reviewed.
  199. The Long Bud Status Report will provide details.  The Status Report will
  200. also be updated periodically to reflect the current status.
  201.  
  202.  
  203. DIT QOS
  204.  
  205. Reliability of the DSAs:
  206.  
  207.  
  208.    o MHS-DS requires the Internet DSA network to provide a good quality
  209.      of service.
  210.  
  211.    o The current QOS provided by the Internet DSA network is marginal at
  212.      best.  The US root-level DSAs seem to be particularly problematic,
  213.      especially the DSAs which hold the top-level US domains under
  214.      O=Internet.
  215.  
  216.    o These problems might be solved by moving responsibility for
  217.      top-level information to an organization which is funded well
  218.      enough to provide good QOS. InterNIC probably qualifies, and has
  219.      expressed an interest in providing this service.
  220.  
  221.  
  222. Updated MHS-DS Internet-Drafts
  223.  
  224. Steve Kille briefly described what changes had been made to the MHS-DS
  225. Internet-Drafts since the previous revisions.  Most of the changes were
  226. editorial in nature.  A very few were more substantial.  For example:
  227.  
  228.  
  229.    o Diagram change in the routing document.
  230.  
  231.    o The representation for personal name was changed.  An RDN with
  232.      multiple AVAs is now used instead of the RFC 1327 representation
  233.      used previously.
  234.  
  235.    o O/R address syntax has been aligned to ISO syntax.
  236.  
  237.  
  238. Some issues were raised on the routing document:
  239.  
  240.  
  241.    o The need for shared bilateral tables was introduced as a new
  242.      concept.  It was recommended that the bilateralTable attribute be
  243.      changed to a sequence of DNs.  This would allow a community of
  244.      MTAs, e.g.  the GO-MHS community, to share a potentially large
  245.      table of information about MTAs.  This could be used, for example,
  246.      to establish a basis for deciding whether or not a connection
  247.      request should be accepted or rejected.  If an MTA outside of the
  248.      community attempts to create a connection to an MTA within the
  249.      community, the internal MTA could reject the connection after
  250.      discovering that the caller is not registered in the shared
  251.      bilateral table.
  252.      In addition to using the shared table, some MTAs might also have a
  253.      need for maintaining a bilateral table which records agreements
  254.      which are truly bilateral.
  255.      Thus, there appears to be a legitimate need for defining the
  256.      bilateralTable attribute as a sequence of DNs.  It was decided that
  257.      this should be discussed further on the mailing list.
  258.  
  259.    o `Next Tree First' routing failure action when the top of a private
  260.      routing tree is reached needs further discussion.  This change
  261.      needs to be discussed off-line.  Steve, Harald, Kevin and Julian
  262.      (in absentia) will discuss this.
  263.  
  264.    o It was pointed out that an `Initiator Calling Address' attribute
  265.      may be needed.  This will be discussed further on the mailing list.
  266.  
  267.  
  268.  
  269. Tutorial BOF
  270.  
  271. A tutorial BOF was scheduled for late in the afternoon.  Thanks to Kevin
  272. for giving the tutorial on such short notice.  It was well received.
  273.  
  274.  
  275.  
  276. Planning for the Next Meeting
  277.  
  278.    o MHS-DS will schedule two time slots at the Houston IETF meeting.
  279.  
  280.    o Four of the Internet-Drafts should have been progressed as RFCs by
  281.      then.
  282.  
  283.    o Progress on Long Bud will be reviewed.
  284.  
  285.    o A new revision of the ``Introduction to Project Long Bud''
  286.      Internet-Draft will have been distributed, and its disposition will
  287.      be discussed.
  288.  
  289.    o The remaining four MHS-DS Internet-Drafts will be discussed.
  290.  
  291.  
  292. Attendees
  293.  
  294. Harald Alvestrand        Harald.Alvestrand@uninett.no
  295. Per Andersson            pa@cdg.chalmers.se
  296. Piet Bovenga             p.bovenga@uci.kun.nl
  297. C. Allan Cargille        allan.cargille@cs.wisc.edu
  298. Robert Cooney            cooney@wnyose.nctsw.navy.mil
  299. David Crocker            dcrocker@mordor.stanford.edu
  300. Urs Eppenberger          eppenberger@switch.ch
  301. Tony Genovese            genovese@es.net
  302. Jan Hansen               Jan.Hansen@teknologi.agderforskning.no
  303. Steven Horowitz          witz@chipcom.com
  304. Jeroen Houttuin          houttuin@rare.nl
  305. Erik Huizer              Erik.Huizer@SURFnet.nl
  306. Ola Johansson            ojn@tip.net
  307. Kevin Jordan             Kevin.E.Jordan@cdc.com
  308. Peter Jurg               jurg@surfnet.nl
  309. Anders Karlsson          sak@cdg.chalmers.se
  310. Steve Kille              S.Kille@isode.com
  311. Paul Klarenberg          klarenberg@netconsult.ch
  312. Bruno Koechlin           Bruno.Koechlin@inria.fr
  313. Arnold Krechel           krechel@gmd.de
  314. Sylvain Langlois         Sylvain.Langlois@exp.edf.fr
  315. Erik Lawaetz             erik.lawaetz@uni-c.dk
  316. Paul Lustgarten          Paul.Lustgarten@att.com
  317. Ignacio Martinez         martinez@rediris.es
  318. Linda Millington         l.millington@noc.ulcc.ac.uk
  319. Paul-Andre Pays          pays@faugeres.inria.fr
  320. Catherine Pierre-Radenac catherine.pierre-radenac@inria.fr
  321. Jim Romaguera            romaguera@netconsult.ch
  322. Marjo Rottschaefer
  323. Panos-Gavriil Tsigaridas Tsigaridas@fokus.gmd.de
  324. Eftimios Tsigros         tsigros@helios.iihe.rtt.be
  325. Paul Vetter
  326. Peter Yee                yee@atlas.arc.nasa.gov
  327. Steve Zeber              zeber@stc.nato.int
  328.