CURRENT MEETING REPORT Minutes of the RFC1006bis/ISO TP over IPv6 BOF (RFC100) Reported by Robert Watson, DEC The "RFC1006bis/ISO TP over IPv6" BOF met on Friday 8th December 1995 at the 34th IETF held in Dallas. The session was chaired by Keith Sklower, Berkeley. This BOF was the second on this subject and was attended by about 15 people. Agenda o Status of CLNP Tunnel over IPv6 o Status of TP4 over IPv6 work o Review of ITOT draft (Pouffary & Young) Status of CLNP Tunnel over IPv6 The chairman reported that CLNP tunneling specification will be included in the IPv6 Tunnel specification from the IPNG Working Group. No further work on this item will be done in the BOF. Status of TP4 over IPv6 work The chairman reported that, as it is not clear who will be implementing this, the TP4 over IPv6 will be published as is, and moved to Experimental RFC status. Action: Keith Sklower/Berkeley. Review of ITOT draft (Pouffary & Young) Yanick Pouffary introduced ITOT by explaining that this is the abbreviation being given to the ISO Transport over TCP/IP specification. A short summary of the draft was given (see slides) highlighting the enhancement since RFC1006. Transport Class 0 is a direct replacement for the functions of RFC1006, and is suitable for all current users of this standard. Transport Class 2 is being proposed for use by application stacks, some of which may not be running over OSI Session, and which require additional features, such as independence of Normal and Expedited data and graceful Transport disconnect. Graceful Disconnect A concern was raised as to whether graceful disconnect could be achieved at the transport level by sending a Disconnect-Request following the last Data. It was pointed that this draft allows for both "Abort" and "Graceful" disconnect, and that the draft details how the Disconnect-Request should be handled in each case. The support for "Graceful" disconnect is needed to allow the applicability of this draft to be extended to applications running over upper layer stacks other than OSI Session. Address Representation The draft includes a section on Address representation. The applicability of including this text in the draft was discussed. After some discussion, and based on the view that it was generally unhelpful to reproduce large sections of one specification in another, it was decided the section in this draft about Network Address Encoding will be reduced. It will include only specific details of the differences between an ITOT NSAPA and one for IPv6. The definition for NSAPA in IPv6 is described in the "IPV6 Addresses inside an NSAPA" experimental RFC. In practice the only difference between the two is the specification of an N-Selector in the ITOT draft. For the other details, the above experiemental RFC will be cross-referenced. Use of X.500 The ITOT draft also contains a section on use of X.500 and interpretation of access points. It was the concensus of the BOF that these sections should be removed to a separate draft which ITOT will cross reference. Discussion of Open Issues in ITOT Draft Protocol Version Number: The rational for maintaining protocol version V3 is given in detail in the draft. No objections have been raised on the mailing list, and after some discussion in this BOF it was agreed that this was the best solution, and meets the needs for interoperability with older RFC1006 implementations, and does not prevent correct class negotiation. Example: In the case where an application specifically requires the services of Class 2, and due to lack of support for Class 2 or failure to negotiate correctly at the responder, a Connect-Confirm for Class 0 is received, then the source should handle this response as defined in the ISO spec. The option of using different port numbers to identify old and new implementations was rejected as it would break any old RFC1006 users who have chosen not to use Well-Known port 102. US GOSIP TSAP Format: It was agreed that as US GOSIP is no longer relevent. The reference in RFC1006 to use of US Gosip complient TSAPs should be dropped from ITOT. After some investigation, no implementation has been found which required this condition. Multiplexing: There was a concensus that due to performance concerns, Multiplexing of multiple ISO Transport connections over a single TCP connection should not be allowed. This will be explicitly stated in the ITOT draft. Expedited data: The history of this issue, as raised at the last IETF and further discussed on the mailing list was given. A possible solution (resulting from some pre-BOF discussions) was presented. This solution (based on a mechanism borrowed from the ISO TP4 specification), allows expedited data to be Acked, when request using the "Request for an ACK" bit. This solution has been detailed on the mailing list and appeared to meet all the concerns in this area. A new issue, relating to the splitting and recombining of the normal and expedited data channels in process-context UNIX implementations was discussed. UNIX Kernel implementations have no problem to allow expedited data channels to be established at any time during the life of a connection and associated with the existing 'Normal' channel. With UNIX process context implementations this would not be possible due to difficulties in associating the new 'Expedited' channel with the existing 'Normal' channel. A solution was proposed and discussed. In essense, this solution ensures that a second channel, to be used for expedited data, is established from the responder back to the initiator of an ITOT connection, before the responder confirms the initial connection request. This second channel would be maintained throughout the life of the connection and would be used for expediated data in both directions. This proposal will be written up and sent to the list for discussion. Note: Following the formal close of the BOF, a further short discussion on this issue took place which will also be passed onto the list. The discussion was to clarify whether there was a need to always establish the second connection at set-up time when expedited data is requested, or only that the initiator should be prepared for this eventuality. In the latter case, it would depend on the responder implementation to decided if it had to set up the expediated data channel at call setup time, or could support this being done later. Conclusion The Chairman requested details of what existing implementations use expedited data and independence of channels. It was noted that DECnet file copy makes use of this mechanism to carry interrupt data, and that DECnet is one of the application stacks, not based on OSI Session, which runs over RFC1859 and would plan to use ITOT once defined. Yanick Pouffary will revise the ITOT draft in accordance with the comments in this BOF and will detail the proposed solution for the new issues raised. There will be further discussion on the mailing list and every effort will be made to reach consensus by the end of January 1996. At that stage the decision on whether to form a working group or finalise the draft would be made in time for the next IETF meeting.