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).

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. Definitions

2.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, 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.

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 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.

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 2003


3.4 Collaboration Guidelines

3.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 to section 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 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 ([email protected]).

  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.

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.txt







Zinin                        Informational                      [Page 6]

RFC 3563             IETF - JTC1 Agreement on IS-IS            July 2003


5. 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, 2003

6. 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: [email protected]




























Zinin                        Informational                      [Page 7]

RFC 3563             IETF - JTC1 Agreement on IS-IS            July 2003


8.  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]


You are viewing proxied material from gopher.fnord.one. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.