Movatterモバイル変換

Network Working Group                                           A. ZininRequest for Comments: 3563                                       AlcatelCategory: Informational                                        July 2003Cooperative Agreement Between the ISOC/IETF and ISO/IECJoint Technical Committee 1/Sub Committee 6 (JTC1/SC6) onIS-IS Routing Protocol DevelopmentStatus 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).1. Introduction   The IS-IS intra-domain routing protocols, originally developed in   ISO/IEC/JTC1/SC6, have been successfully deployed in the Internet for   several years.Zinin                        Informational                      [Page 1]

RFC 3563             IETF - JTC1 Agreement on IS-IS            July 2003   ISO/IEC/JTC1/SC6 is the JTC1 sub-committee which has responsibility   for maintenance of the IS-IS standard (ISO/IEC 10589).   The IS-IS Working Group of the IETF is chartered to develop   extensions to the IS-IS protocol to be used within the scope of the   Internet.   This addendum documents the agreed process for the future development   of IS-IS by both organizations.2. Definitions2.1 Core IS-IS Mechanisms   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]   b) Encapsulation of PDUs   c) Adjacency state machine and formation logic   d) DIS election algorithm   e) Initial LSP synchronization via CSNP exchange   f) Asynchronous LSP flooding (including DIS flooding behavior)   g) LSP database maintenance including LSP origination, aging, and      purging   h) Topology abstraction defined in [10589]2.2 Internet-specific IS-IS Extensions:   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, orZinin                        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.3. Agreement   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.3.1 Separation of IS-IS Work Scope   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 persection 2.2 of this document SHOULD be submitted for standardization   to JTC1 (seesection 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 insection 2.2 of this document.3.3 IS-IS Registries (IANA Considerations)3.3.1 IS-IS TLV Codepoint Registry   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.3.3.2 IETF-specific Registries   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.Zinin                        Informational                      [Page 4]

RFC 3563             IETF - JTC1 Agreement on IS-IS            July 20033.4 Collaboration Guidelines3.4.1 Learning About New Work   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.3.4.2 Submitting IETF Documents to JTC1   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 tosection 3.1 SHOULD 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:http://www.ietf.org/rfc/rfcNNNN.txt   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.3.4.3 Submitting JTC1 Documents to IETF   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].3.4.4 Mutual Document Review   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 anZinin                        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 (seesection 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.4. References   [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.   [ISISWG]    "IS-IS for IP Internets (isis), IETF WG charter",http://www.ietf.org/html.charters/isis-charter.html   [ISO]       "ISO Technical Committee details web-page",http://www.iso.org/iso/en/stdsdevelopment/tc/tclist/TechnicalCommitteeDetailPage.               TechnicalCommitteeDetail?COMMID=1   [JTC1]      "ISO/IEC JTC1 web-page"http://www.jtc1.org   [SC6]       "ISO/IEC JTC1/SC6 web-page"http://www.jtc1sc06.org   [IETF-ML]   "IETF Mailing Lists web-page",http://www.ietf.org/maillist.html   [ID-GUIDE]  "Guidelines to Authors of Internet-Drafts",http://www.ietf.org/ietf/1id-guidelines.txtZinin                        Informational                      [Page 6]

RFC 3563             IETF - JTC1 Agreement on IS-IS            July 20035. Signatures   Approved,                               Approved,   for ISO/IEC JTC1/SC6                    for the Internet Society   Original signed by                      Original signed by   Jack Houldsworth                        Harald Alvestrand   Date: March 3, 2003                     Date:  March 19, 20036. Security Considerations   This type of non-protocol document does not directly affect the   security of the Internet.7. Author's Address   Alex Zinin   Alcatel   EMail: zinin@psg.comZinin                        Informational                      [Page 7]

RFC 3563             IETF - JTC1 Agreement on IS-IS            July 20038.  Full Copyright Statement   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.Zinin                        Informational                      [Page 8]