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
