Network Working Group A. Zinin Request for Comments: 3563 Alcatel Category: Informational July 2003
Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol Development
Status of this Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document contains the text of the agreement signed between ISOC/IETF and ISO/IEC JTC1/SC6 regarding cooperative development of the IS-IS routing protocol. The agreement includes definitions of the related work scopes for the two organizations, request for creation and maintenance of an IS-IS registry by IANA, as well as collaboration guidelines.
Document Header
Annexe 1 to Cooperative Agreement Between the Internet Society and the International Organization for Standardization / International Electrotechnical Commission / Joint Technical Committee 1 / Sub Committee 6 (ISO/IEC JTC1/SC6): IS-IS Routing Protocols
Date: 2003-01-28
This annexe records the agreed collaborative process for the further development and standardisation of the Intermediate System to Intermediate System (IS-IS) intra-domain routing protocol (ISO/IEC 10589).
Core IS-IS Mechanisms are subsystems with associated algorithms, data structures, and PDU formats as specified in (ISO/IEC 10589), constituting the core of the IS-IS protocol and including the following elements:
a) Framework of PDU formats, including TLVs defined in [10589]
Internet-specific IS-IS Extensions are extensions to the IS-IS protocol that are within the work scope of the IETF including any routing or packet forwarding technology that the IETF decides to work on in the future (such as IPv4 or IPv6 unicast and multicast routing, MPLS, MPLS Traffic Engineering, or Generalized MPLS), and:
a) do not modify the Core IS-IS Mechanisms and do not change operation of non-IP or affect compatibility with non-IP and dual implementations of IS-IS, or
Zinin Informational [Page 2]
RFC 3563 IETF - JTC1 Agreement on IS-IS July 2003
b) add supplementary mechanisms to the Core IS-IS Mechanisms, are not generally applicable to non-IP implementations of IS-IS, and do not change operation of non-IP or affect compatibility with non-IP and dual implementations of IS-IS, or
c) are de facto implementation agreements that are not generally applicable to non-IP implementations of IS-IS.
Note that the introduction of new TLVs or sub-TLVs that do not modify the algorithms of the Core Mechanisms in a way that would affect interoperability with non-IP or dual implementations of IS-IS is not considered to be a modification to the Core IS-IS Mechanisms.
The following conventions are used in the rest of this document.
SHALL This term is used to indicate commitment to follow a specific element of this agreement.
MUST Equivalent to "SHALL"
SHALL NOT This phrase is used to indicate commitment to NOT perform a specific action
MAY This term is used to indicate the right to perform a specific action
SHOULD This term is used to indicate that following a specific element of this agreement is encouraged, however there may exist circumstances in which a decision may be made not to do so.
JTC1 SHALL NOT and IETF MAY (subject to the IETF standards process) standardize any Internet-specific IS-IS Extensions.
Any IS-IS Extensions produced within the IETF that require standardization, but cannot be identified as Internet-specific per section 2.2 of this document SHOULD be submitted for standardization to JTC1 (see section 3.3.2). IETF SHALL NOT publish documents describing such IS-IS extensions other than as Informational RFCs.
Zinin Informational [Page 3]
RFC 3563 IETF - JTC1 Agreement on IS-IS July 2003
IS-IS extensions submitted from the IETF to JTC1 will be processed under the JTC1 fast track procedure. To ensure the quality of such submissions, IETF SHALL apply to them the procedures for Proposed Standard submission according to [RFC2026] (even though these documents will not be published as standards-track IETF RFCs).
In the situations where it is not clear from the provisions of this document whether a specific protocol extension should be standardized within the IETF or within JTC1, the decisions will be made on a case- by-case basis and will be based on the agreement between the two organizations reached via a discussion between the IETF Routing Area Directors or the IETF liaison to JTC1/SC6 (who will reflect the IETF consensus on the matter), and the JTC1/SC6 secretariat.
3.2 Requirements for IS-IS-specific IETF documents
All IS-IS-related IETF documents intended to be published as IETF standards track RFCs MUST include a section explaining why they qualify to be considered as Internet-specific IS-IS Extensions described in section 2.2 of this document.
Until JTC1 provides the registry service for IS-IS, IANA is requested to temporarily maintain such a registry as described below. Upon notification from JTC1, the registry management authority (i.e., value allocation) will be transferred to JTC1. IANA MAY still retain the registry for informational purposes and keep updating it based on information provided by JTC1.
IANA has created and currently maintains a registry for IS-IS TLV codepoints. The range of values is 0-255. Initial state of the registry should be synchronized with [RFC3359]. Allocation of values in the registry has to be approved by the designated expert assigned by the IESG. IETF SHALL keep JTC1/SC6 informed of TLV codepoint values allocated, and JTC1/SC6 SHALL refer allocation requests arising within JTC1 constituencies to the IANA registry process.
IETF MAY request IANA to maintain IS-IS-related registries if those are required to maintain name spaces internal to Internet-specific IS-IS extensions.
IETF SHALL inform the chairman and secretariat of ISO JTC 1/SC 6 about new IS-IS-related work items.
JTC1/SC6 SHALL inform the IETF Routing Area directors and ISIS WG chairs about new IS-IS-related work items. Communication MAY be enacted directly using electronic mail, or may be conducted via appointed SC6 / IETF liaison representatives.
As a class A liaison organisation to JTC1, the Internet Society may submit existing standards for adoption as International Standards of the ISO, using the Fast-Track procedure.
IS-IS extensions developed by IETF and intended for standardization in JTC1 according to section 3.1SHOULD therefore be submitted by one of the IETF ISIS WG chairs, or an IETF Routing Area director, sending an email message to the secretariat of ISO JTC 1 specifying the number of the Informational RFC containing the specification (the document MUST have been published as an RFC at the time of submission) and requesting fast-track processing by JTC1. The full text of the specification is then available using the following URL:
where "NNNN" is the number of the RFC being submitted. The IETF SHOULD also recommend that JTC1 assign the document to JTC1/SC6, and SHOULD also submit to JTC1 the name of an individual who is prepared to serve as project editor for the fast-track document.
It is possible to make JTC1 standards specifications available for informational purposes of the IETF community by submitting the text of the specification as an Internet Draft and requesting the RFC Editor to publish the document as an Informational RFC. See sections 4.2.2 and 7 of [RFC2026] for more information. Guidelines for Internet Draft preparation are given in [ID-GUIDE].
Members of ISO JTC 1/SC 6 are welcome to review any IS-IS-related IETF document (all IETF documents are publicly available at the IETF web site) and submit their comments to the ISIS WG (by sending an
Zinin Informational [Page 5]
RFC 3563 IETF - JTC1 Agreement on IS-IS July 2003
email to the working group mailing list), the ISIS WG chairs (see [ISISWG] for more information), the IETF Routing Area directors, or the IESG (iesg@ietf.org).
JTC1 is encouraged to request an IETF review of IS-IS-related work performed by JTC 1/SC 6 by submitting the text of the document as an informational Internet Draft (see section 3.3.2) and sending a message to the IETF ISIS WG mailing list requesting the comments.
The IETF MAY request JTC1 to circulate provided comments among the National Bodies and Liaison Organizations involved in the discussion of the work under review.
[10589] ISO, "Intermediate system to Intermediate system routing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:1992.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC3359] Przygienda, T., "Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System", RFC 3359, August 2002.
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.