home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 92jul / area.osi.92jul.txt < prev    next >
Text File  |  1993-02-17  |  17KB  |  476 lines

  1.  
  2. OSI Integration Area
  3.  
  4. Director(s):
  5.  
  6.  
  7.    o David M. Piscitello:  dave@sabre.bellcore.com
  8.    o Erik Huizer:  Erik.Huizer@surfnet.nl
  9.  
  10.  
  11. Area Summary reported by Dave Piscitello/Bellcore and Erik
  12. Huizer/SURFnet
  13.  
  14. The OSI area contains the following working groups:
  15.  
  16.  
  17. NOOP                   Network Osi Operations
  18. MPSNMP                 SNMP over a Multi-protocol Innternet
  19. OSI-DS                 OSI Directory Services
  20. MHS-DS                 Message Handling Service Usage of Directory
  21.                        Services
  22. X.400OPS               X.400 Operations
  23. MIMEMHS                MIME to MHS Mapping
  24. ODA                    Office Documentation Architecture
  25.  
  26.  
  27. The OSI General Working Group has been disbanded.
  28.  
  29. Related working groups:
  30.  
  31.  
  32. DISI        Directory Information Services Infrastructure Working Group
  33.             (report under User Services area)
  34.  
  35.  
  36. BOFs in the OSI Integration Area held in Boston.
  37.  
  38.  
  39. SWIP        Shared Whois Information Project
  40. UDI         Universal Document Identifiers
  41.  
  42.  
  43. Related BOF:
  44.  
  45.                                    1
  46.  
  47.  
  48.  
  49.  
  50.  
  51. NIR              Networked Information Retrieval BOF (report under User
  52.                  Services area)
  53.  
  54.  
  55.  
  56. Shared Whois Information Project BOF (SWIP)
  57.  
  58. This BOF was organised by Merit to discuss the possibilities for using
  59. X.500 to set up a shared whois like service between the Major network
  60. coordination centers (currently there are 3:  Ripe NCC, GSI- NIC, Merit)
  61. in the Internet.  This is meant for easy access and exchange of network
  62. management data.  Which ip address belongs to who, what point of
  63. contact, etc.
  64.  
  65. The goals of the SWIP BOF were to a) present the idea and project that
  66. Merit had conceived of to converge the network data stored by GSI-NIC,
  67. RIPE, and Merit.  b) get general agreement on the idea and the method
  68. being used c) define requirements for a shared whois database d) get
  69. consensus on the need for a distributed whois database of networks and a
  70. consensus that the platform be X.500.
  71.  
  72. Most of these goals were achieved.  There was a very clear consensus
  73. from the attendees that a distributed whois database of networks should
  74. be implemented, should be done in X.500, and that it should be done
  75. ``right''.  It was further decided that Merit should proceed with their
  76. X.500 project to converge the network data currently available from
  77. RIPE, GSI-NIC, and Merit, and for them to put into place a procedure to
  78. keep the data converged until the distributed whois database is in place
  79. and working.  There is an action item to combine the two X.500
  80. architectural models presented in the bof pertaining to a distributed
  81. model for network data.
  82.  
  83. Universal Document Identifiers BOF (UDI)
  84.  
  85. This Group discussed naming issues intended to support the discovery and
  86. access of resources in an Internet environment.  It was agreed that the
  87. term ``Uniform Resource Locator'' (URL) would be used to refer to
  88. standardized identifiers which specify location information for
  89. resources.  The discussion of other aspects of the naming problem was
  90. deferred until a later meeting.
  91.  
  92. A document written by Tim Berners-Lee (timbl@info.cern.ch) proposing a
  93. standard for URLs was discussed and the syntax and general content of
  94. the document was accepted with some revisions.  The revised document
  95. will be made available from info.cern.ch and circulated to the list
  96. below for further discussion.
  97.  
  98. The Group decided to draw up a charter and form an IETF working group on
  99. this issue.  The mailing list for discussion of URL design issues will
  100. be ``ietf-url@merit.edu''.  This list will be archived on the anonymous
  101. FTP archive on ``merit.edu''.
  102.  
  103. MHS-DS Working Group (MHSDS)
  104.  
  105.                                    2
  106.  
  107.  
  108.  
  109.  
  110.  
  111. The MHS-DS Working Group met at JENC-3 in Innsbruck, Austria in May.  A
  112. small group of technical experts met once to discuss editorial and
  113. technical revisions to the set of seven Internet Drafts being written by
  114. the Group.  In addition, an open meeting of MHS-DS was held to present
  115. general concepts to a broad cross section of the European R&D community.
  116. An open discussion followed, and valuable comments were contributed to
  117. the Internet Drafts.
  118.  
  119. The focus of the third meeting of MHS-DS (Boston) was on editing the
  120. seven Internet Drafts (listed below).  We went through the documents,
  121. page by page, and contributed both simple editorial changes as well as
  122. some recommendations for minor technical revisions.  As a result, three
  123. of the documents will be progressed as Experimental Standards, and the
  124. other four will be cycled through another round of review after they are
  125. revised.  In addition, two new documents will be produced:  a general
  126. overview of the whole set, and a document which focuses upon the subject
  127. of Content Conversion.
  128.  
  129. The document status follows:
  130.  
  131.  
  132.   1. Representing Tables and Subtrees in the Directory
  133.      status:  revise and progress as Experimental Standard
  134.   2. Representing the O/R Address Hierarchy in the Directory Information
  135.      Tree
  136.      status:  revise and progress as Experimental Standard
  137.   3. MHS use of Directory to support MHS Routing
  138.      status:  revise and cycle as an Internet Draft
  139.   4. Use of the Directory to support mapping between X.400 and RFC 822
  140.      Addresses
  141.      status:  revise and progress as Experimental Standard
  142.   5. MHS use of the Directory to support distribution lists
  143.      status:  revise and cycle as an Internet Draft.
  144.   6. A simple profile for MHS use of Directory
  145.      status:  revise and cycle as an Internet Draft (depends upon 3)
  146.   7. Use of the Directory to support routing for RFC 822 and related
  147.      protocols
  148.      status:  revise and cycle as an Internet Draft.
  149.  
  150.  
  151. New documents to be produced:
  152.  
  153.  
  154.   1. Overview of Document Set.
  155.   2. MHS use of the Directory to support Content Conversion.
  156.  
  157.  
  158. As a final note:  The MHS-DS Charter will be revised to add the two new
  159. documents and also to add the following two features:
  160.  
  161.  
  162.                                    3
  163.  
  164.  
  165.  
  166.  
  167.  
  168.   1. MHS-DS will coordinate piloting of MHS use of the Directory.
  169.   2. MHS-DS will specify requirements for tools which facilitate
  170.      interworking between X.500-capable MTA's and MTA's which are not
  171.      X.500-capable.
  172.  
  173.  
  174. MIME-MHS Interworking Working Group (MIMEMHS)
  175.  
  176. There have been two papers produced since the last meeting:
  177.  
  178.  
  179.   1. X.400/MIME body equivalence Harald Tveit Alvestrand, Steven
  180.      Thompson.
  181.   2. Mapping between X.400 and RFC-822 Message Bodies, Harald Alvestrand
  182.      et al.
  183.  
  184.  
  185. Several mappings have been defined, and for those without a clear
  186. X.400(88) equivalent there is a trapdoor/catchall External bodypart
  187. defined in X.400:  EBP-mime-body-part.  In the other direction the
  188. trapdoor in MIME is a new Mime subtype:  application/x400-bp.  The
  189. issues are:
  190.  
  191.  
  192.    o How to get vendors to register OIDs as well as the equivalent MIME
  193.      subtype with the IANA.
  194.  
  195.    o How to manage IANA registration of different versions of BPs like
  196.      WP5.0 and WP5.1.
  197.  
  198.    o How to handle mapping in X.400(84)?
  199.  
  200.       -  Simplest case single BP IA5.
  201.       -  T.61 strings in header vs RFC 1327 needs resolving.
  202.       -  Three-party mail issue (mime-X.400(88)-X.400(84)).
  203.  
  204.  
  205.    o Automatic OID assignment for registered subtypes.
  206.    o Appendix with OIDs defined.
  207.    o Security:  viruses will be gatewayed too, not solved in this paper.
  208.    o Criticality of header extensions.
  209.  
  210.  
  211. The issues will be resolved by E-mail in the next couple of months.
  212. Both documents will be forwarded as Proposed Standard RFCs.
  213.  
  214. Network OSI Operations Working Group (NOOP)
  215.  
  216. The Group reviewed the status of RFC 1139, CLNP ping, and agreed to, (a)
  217. eliminate the short-term solution, and (b) align/revise the long-term,
  218. solution to match the ISO PDAM expected from ISO next week.  A new RFC
  219.  
  220.                                    4
  221.  
  222.  
  223.  
  224.  
  225.  
  226. will be produced.  Since this is an integral part of the tools RFC, NOOP
  227. expects to process this rapidly.
  228.  
  229. Work continues on the OSI Tools RFC. The Group also reviewed a list from
  230. RARE identifying the ten most desirable Managed Objects from the CLNP
  231. MIB, and reacted favorably to the selection of OSI connectionless
  232. transport as a means of mapping SNMP onto OSI.
  233.  
  234. The Working Group reviewed the ISO Transport MIB submitted by Russ
  235. Blaesing.  Following a discussion of what and how many managed objects
  236. would be useful for network operations, Dave Piscitello agreed to
  237. evaluate this MIB against MIB-II, TCP Group.  He will post the results
  238. of this comparison to NOOP mailing list.  NOOP will then discuss what
  239. MOs are required for operations, and will make this set known to
  240. vendors.
  241.  
  242. The Working Group received a presentation of TUBA from Ross Callon; of
  243. Interop '92 spring experiences from Rich Colella; and of X Window System
  244. over OSI and the ``skinny OSI stack'' from Jim Quigley.
  245.  
  246. OSI Directory Services Working Group (OSIDS)
  247.  
  248. Discussion topics:
  249.  
  250.  
  251.    o The latest1992 CCITT X.500 version is dated 25-12-1992 (The
  252.      Christmas paper).
  253.  
  254.    o RFC-1279 (Representing DNS in the Directory) has been revised.
  255.  
  256.    o OIW established a new specification:  IGOS (industry and Government
  257.      OSI Specification), it requires a.o.  many X.500 1992 extensions.
  258.  
  259.    o NADF split the Naming Schema document into two docs:
  260.  
  261.       -  Naming schema set-up for countries.
  262.       -  Specific case for the US.
  263.  
  264.  
  265.    o NADF security paper, protection by passwords, weak credentials.
  266.      There is a defect in the replay of passwords in simple auth.
  267.      (fixed in 1992 version?)
  268.  
  269.    o There is a road-map paper indicating all NADF publications.
  270.  
  271.    o None of (12) vendors in NADF was supporting strong auth, none had
  272.      timelines for 1992 extensions.
  273.  
  274.  
  275. Documents discussed:
  276.  
  277.  
  278.  
  279.                                    5
  280.  
  281.  
  282.  
  283.  
  284.  
  285.    o Naming guidelines for Directory pilots paper to be progressed to an
  286.      Informational RFC.
  287.  
  288.    o A string representation of distinguished names to Proposed
  289.      Standard.
  290.  
  291.    o User Friendly Naming to Experimental RFC.
  292.  
  293.    o Strategy Document.  Those who read it (ca 60document.  The document
  294.      will be redistributed after processing minor comments and then
  295.      submitted to IESG/IAB for policy approval, and subsequent
  296.      publishing as an Informational RFC.
  297.  
  298.    o IP address information in the Directory.  The paper was discussed
  299.      and several major changes were suggested.  Work ongoing.
  300.  
  301.      Pilots:
  302.  
  303.       -  QOS no progress yet.
  304.       -  JPEG ongoing.
  305.       -  DIT counting.
  306.       -  Char set ongoing.
  307.  
  308.      A Schema group has not yet been set up.  A suggestion was made to
  309.      ask the IANA to take this on.
  310.  
  311.    o Discussion on DUA and DSA metrics papers.  Meant to set metrics for
  312.      comparing DSAs and DUAs (functionality, capacity etc.)  The papers
  313.      will be used to describe existing implementations and
  314.      results/comments on the paper will be reported back into the next
  315.      meeting.  Papers will then be revised and put forward as
  316.      informational RFCs.
  317.  
  318.    o Two papers on a lightweight access protocol for the directory were
  319.      discussed.  Minor comments were given, after these have been worked
  320.      into the paper it will be submitted to the IESG for publication as
  321.      Proposed Standard.
  322.  
  323.    o DSA naming.  This paper was discussed.  The paper is seen as being
  324.      still too much oriented towards one single implementation, to be
  325.      publishable as an RFC. Therefore the Working Group will drop the
  326.      issue until other manufacturers have commented or supplied their
  327.      solution to DSA naming and knowledge distribution.
  328.  
  329.  
  330. Next meeting at November IETF.
  331.  
  332. Office Document Architecture Working Group (ODA)
  333.  
  334. Progress of products:  Six products now known to the Group, most of them
  335. not yet with full vendor support.
  336.  
  337.                                    6
  338.  
  339.  
  340.  
  341.  
  342.  
  343. Progress on pilots:  Few groups put up some of products.  Use is mostly
  344. internal and limited.
  345.  
  346. Expectations:  Over next year the int.  profile FDD 26 is being ratified
  347. and will probably lead to new products and pilots.  However in the next
  348. six months little progress is expected, so the IETF ODA Working Group
  349. will not meet in November 92, but will sleep until new activity pops up.
  350.  
  351. SNMP over a Multi-protocol Internet Working Group (MPSNMP)
  352.  
  353. The Group met and reviewed three Internet Drafts.
  354.  
  355.  
  356.    o SNMP over OSI (CL Transport Service)
  357.    o SNMP over Appletalk
  358.    o SNMP over IPX
  359.  
  360.  
  361. All three were aligned with respect to the treatment and assignment of
  362. Object Identifiers for the transportDomain All three have at least one
  363. implementation presently.  It was agreed that all three would have
  364. essentially the same boilerplate recommendation with respect to multiple
  365. transport implementations; i.e., that agents are only required to
  366. implement *one* transport mapping of SNMP, and managers were expected to
  367. implement as many as necessary to allow communication to all agents
  368. within a network.  Implementations are encouraged to implement UDP.
  369.  
  370. All three documents require minor rewrites; they will all be posted for
  371. a two week last call before recommending to the IESG that they be moved
  372. to Proposed RFCs.
  373.  
  374. A fourth document describing ``how to write a transport mappings'' was
  375. aligned with the three Internet Drafts; this will be revised and
  376. submitted as an FYI RFC.
  377.  
  378. With no further work to consider, the Working Group agreed to disband.
  379.  
  380. X.400 Operations Working Group (X400OPS)
  381.  
  382. Status report on the pilots (XNREN and Cosine MHS) was given.  The
  383. amount of usage as well as the amount of connected MTAs is growing
  384. steadily.
  385.  
  386. Work on daily update tool for outing and mapping tables is still ongoing
  387. and expected to be ready by the end of 1992.
  388.  
  389. Connectivity issues:
  390.  
  391.  
  392.    o Internet-X.400 to public X.400;
  393.  
  394.    o RFC-822 to public X.400; Various unstandardised gateways from
  395.  
  396.                                    7
  397.  
  398.  
  399.  
  400.  
  401.  
  402.      commercial service providers (e.g., AT&T, MCI, IBM) to the Internet
  403.      were discussed.  These gateways cause problems like address
  404.      mangling.
  405.  
  406.    o In the US rather than ADMD=<space> they have proposed an ADMD=usbb,
  407.      to register nationwide-multiple-carrier PRMDs.  So if a prmd
  408.      subscribes to e.g., ADMD=attmail, they can choose to do so under
  409.      ADMD=attmail or request from AT&T to do it under ADMD=usbb.
  410.  
  411.  
  412. Documents
  413.  
  414.  
  415.    o Proposed in this text is to use the X.400/88 GeneralText option to
  416.      use extended character sets.  This option is not really in
  417.      X.400/88, but only in the ISO version, however it is an extended
  418.      bodypart and thus can be used without modifications.  The paper
  419.      further describes the ISO 8859 character sets that should be used.
  420.      NOTE: o.a.  the Dutch ligature ij is missing!!  Jammerlijk maar
  421.      geen ramp.
  422.      Paper will be revised to the comments made and discussed with char
  423.      set experts (e.g., RARE wg-char), and then it will be put forward
  424.      to RARE wg-mhs and the November IETf meeting.
  425.  
  426.    o Coordination Procedures for RFC 1327 gateways by Cosine MHS The
  427.      paper documents current procedures for reference and with the
  428.      purpose of making it more globally known.  There is no information
  429.      in the paper on how the tables should be formatted and what can and
  430.      cannot go in.  This will be a separate paper.  However this paper
  431.      should still contain some general indications.  The paper will be
  432.      adapted to the comments and then put forward as informational RFC.
  433.  
  434.    o Operational requirements....  - Rob Hagens/Alf Hansen Minor
  435.      comments were made to this document.  It will be published as an
  436.      Experimental Standard RFC.
  437.  
  438.    o Routing coordination for X.400 Urs Eppenberger The document is
  439.      almost finished.  However a new perspective has been brought in by
  440.      GMD (Panos G.) to allow for more X.500 oriented syntaxes in the
  441.      document.  Panos, Steve Hardcastle-Kille and Urs will discuss this
  442.      off-line.  Time pressure is high.  To be progressed to Experimental
  443.      Standard RFC soon.
  444.  
  445.    o Using DNS to maintain RFC987 mapping tables - Claudio Allocchio
  446.      This paper shows the various issues that have come forward out of
  447.      the Trieste experiments with the use of DNS. The paper provides an
  448.      independent way to distribute the table WITHOUT distributing
  449.      necessarily the authority.  It is proposed that the various
  450.      alternatives will be put forward to the IETF DNS Group for advise,
  451.      and that following that the paper will be progressed to an
  452.      Experimental RFC
  453.  
  454.  
  455.                                    8
  456.  
  457.  
  458.  
  459.  
  460.  
  461.    o Mapping between X.400 and Mail-11 - Claudio Allocchio There was
  462.      unfortunately no time to discuss this paper.  There is one
  463.      implementation around, discussion will be done by E-mail.
  464.  
  465.    o New document:  Grandfathering of ADMD=internet in the US, to be
  466.      produced.
  467.  
  468.    o New document:  The use of s=postmaster in X.400, to be produced.
  469.  
  470.  
  471. Next meeting at November IETF.
  472.  
  473.  
  474.  
  475.                                    9
  476.