CURRENT_MEETING_REPORT_ Reported by Robert Hagens/University of Wisconsin AGENDA o General Meeting o Updates - BSD 4.4 - New Revision RFC 1069 - Echo RFC - GOSIP Comments o OSI at Interop 89 o Results of the MITRE congestion avoidance experiments o State of the OSIIWG -- accomplishments and future work MINUTES The meeting was convened by co-chairmen Ross Callon and Rob Hagens. An attendance list will be published with the Proceedings of the IETF. A series of brief status updates on the following topics were presented: o BSD 4.4: An ISODE/BSD interface has been constructed and tested. Alpha copies have been distributed to a small number of sites. Work is still in progress fixing bugs, testing, etc. o New revision of RFC 1069. The newest version of RFC 1069, compatible with the GOSIP V2 (if the OSIIWG comments are accepted) has been prepared. Its submission to the RFC editor will be delayed until GOSIP V2 is released. o The ECHO RFC has been released as an Internet Draft. This RFC specifies how to implement an ECHO facility with ISO 8473. The WG reviewed the document and found (with 2 minor editing changes) it ready to be sent to the RFC editor. o There is no official word from NIST regarding the OSIIWG GOSIP V2 comments. A representitive of the OSIIWG will attend the next GOSIP Advanced Requirements Committee meeting. o GSA has a contract to administer ICD 0005 (although NIST still maintains authority). The DCA use of 0006 is unknown. NIST currently supports the use of 0005 by the entire Internet. Policies for the use of 0005 have not yet been established. Those with strong interests in future policy should contact: Mr. Gerard F. Mulvenna Technology Building, Room B-217 National Institute of Standards and Technology Gaithersburg, MD 20899 Dave Katz presented his OSI experiences at Interop, 89. Rick Wilder presented preliminary results of the MITRE congestion avoidance experiments. Following this, the state of the OSIIWG was discussed. A list of new working groups that need to be formed was presented. This list includes the reorganization of the OSIIWG into the OSI-General WG. Note: the OSI-RA group may be split into two separate groups, one to produce NSAP administration guidelines, and the other to follow upper layer registration policy. Finally, the list of current and future work of the OSI Area was presented: IETF OSIIWG STATUS/Callon and Hagens Agreements and future work of the IETF OSIIWG DRAFT 1. Physical Layer (a) Accomplishments and Agreements o None identified. (b) Future Work o None identified. 2. Link Layer (a) Accomplishments and Agreements o None identified. (b) Future Work o Distinguishing packets on the wire o HDLC o X.25 3. Network Layer (a) Accomplishments and Agreements i. Data transfer oISO 8473/use as specified ii. Routing oISO 9542/use as specified oIntra-domain routing/use ANSI IS-IS as presented as draft proposal use ANSI IS-IS as presented as draft proposal. oInter-domain routing use static tables. iii.ISO 8473 Echo A draft RFC has been prepared. It describes an echo function that is realized by defining a new network selector that indicates an echo entity. This is backward compatable with existing 8473 packets. iv. NSAP address format oRFC 1069 RFC 1069 has been updated to align with the GOSIP V2 NSAP address format. oNSAP Selectors OSIIWG comments on GOSIP V2 recommend that GOSIP V2 should not specify the format of the NSAP selector value. (b) Future Work i. ISO 8473 Echo Initiate a new ANSI X3S3.3 work item to propose a CLNP echo function to ISO. This echo function is realized by defining a new protocol type field. This is not backward compatable with existing 8473 packets. ii. NSAP address format oNSAP Administration Design and write procedures for administering NSAP address heirarchies. oICD Usage Determine whether the Internet should register under ICD 0005 or ICD 0006 or both. Coordinate with any previous NIST/GSA agreements, or motivate new agreements. iii.CO/CL We should track the CO/CL interworking status in X3S3.3. 4. Transport Layer (a) Accomplishments and Agreements Recommend that GOSIP V2 mandate NIST agreements regarding congestion recovery algorithms and related retransmission timer algorithms. (b) Future Work None identified. 5. Session Layer (a) Accomplishments and Agreements None identified. (b) Future Work None identified. 6. Presentation Layer (a) Accomplishments and Agreements None identified. (b) Future Work None identified. 7. Application Layer (a) X.400 i. Accomplishments and Agreements oPRMD name The intended use of "NREN" as a PRMD name is to identify a management domain within which every registered Internet entity has a default X.400 Address. This address would be based upon the Internet domain name. We expect some or all currently registered entities to decide for them- selves whether they wish to use the default or register another name in another way. This default provides a useful and helpful option without constraining any individual entity to keep what the default provides for them. ii. Future Work A.GOSIP V2 Work with the GOSIP user's group to rewrite the X.400 ORAddress section. B.822 <-> X.400 gateway operation o Table Maintenance o Locating a Gateway o ORAddress Structure C.X.400 operation o Default naming o Taxonomy of issues Write a memo which describes the needs of X.400 addressing, X.400/RFC 822 address mapping, and utilization of an X.500 directory service. (In Progress). (b) Registration and Naming i. Accomplishments and Agreements: See "NREN". ii. Future Work oNSAP administration See NSAP administration under Network Layer. oNSAP and ORAddress relationships Explore the relationship between NSAP addresses and X.400 ORAddresses. Should the NSAP address field "oganization" under ICD 0005 be used in the X.400 ORAddress "organization" field to reduce administration complexity? oEstablishing Ownership Identify necessary steps we must take to assert that the name "NREN" belongs to the FRICC. (c) Directory Services i. Accomplishments and Agreements None. ii. Future Work A.X.500 and Internet DNS Explore coexistence/interactions between X.500 and the Internet DNS B.Missing Pieces Locate missing pieces required by a production system (format of objects, choice of dis- tinguished names, etc.) C.Requirements of a dual protocol internet o Application Gateways Identification of application gateways needed for communication between heterogenous, pure stack hosts. In addition, support for the deci- sion to gateway (i.e., forward as X.400 message or translate into RFC 822). o Stack Choice Identification of optimal protocol stack choice for dual hosts (based upon the destination sys- tem). (d) VTP i. Accomplishments and Agreements None ii. Future Work Look for problems with Telnet/VTP interaction. (e) FTAM i. Accomplishments and Agreements None ii. Future Work Look for problems with FTAM/FTP interaction. (f) Network Management i. Accomplishments and Agreements None ii. Future Work oCMIP oOSI MIB 8. General Future Work (a) Mixed Stack GOSIP prohibits a mixed stack approach. Do mixed stacks have enought merit that they should be allowed? (b) Mixed Technology Can OSI problems be solved with internet technol- ogy? Will the Internet incorporate OSI technology? For example, can X.400 routing utilize the DNS, in the absense of X.500? (c) Document Review o GOSIP o ANSI specifications o FRICC Multi-Protocol Implementation Plan