Network Working Group                                         Alex Zinin
Internet Draft                                                   Alcatel
Expiration Date: April 2003                                 October 2002
File name: draft-zinin-ietf-jtc1-aggr-00.txt

       Draft of agreement betweenA new Request for Comments is now available in online RFC libraries.

        RFC 3563

        Title:      Cooperative Agreement Between the ISOC/IETF and
                    ISO/IEC JTC1/SC6 Joint Technical Committee 1/Sub
                    Committee 6 (JTC1/SC6) on IS-IS protocol development

                   draft-zinin-ietf-jtc1-aggr-00.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet Drafts are working documents of the Internet Engineering
   Task Force (IETF), its Areas, and its Working Groups. Note that other
   groups may also distribute working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months. Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time. It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract Routing Protocols
        Author(s):  A. Zinin
        Status:     Informational
        Date:       July 2003
        Mailbox:    zinin@psg.com
        Pages:      8
        Characters: 14974
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-zinin-ietf-jtc1-aggr-01.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3563.txt

This document contains a proposed 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.

   Please send any comments on this document to the IESG (iesg@ietf.org)

Document Header

   Title: Draft Addendum 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:  XXXX

This addendum records the agreed collaborative process memo provides information 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.

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

2. Definitions

 2.1 Core IS-IS Mechanisms

   Core IS-S 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 community.  It does
not specify an Internet standard TLVs

     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)   Standard topology abstraction

 2.2 Internet-specific IS-IS Extensions:

   Internet-specific IS-IS Extensions are extensions to the IS-IS proto-
   col that are within the work scope of the IETF (including, but not
   limited to IPv4 or IPv6 unicast and multicast routing, MPLS, MPLS TE,
   GMPLS, or any other routing technology that the IETF decides to work
   on in future), 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

     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 in the text above introduction of new TLVs or sub-TLVs
   without modifying the algorithms of the Core Mechanisms in a way
   affecting interoperability with non-IP or dual implementations of IS-
   IS is not considered to be a modification to the Core IS-IS Mecha-
   nisms.

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 kind.  Distribution of this agreement.

     MUST       Equivalent to "SHALL"

     SHALL NOT  This phrase
memo is used to indicate commitment to NOT
                perform a specific action

     MAY unlimited.

This term announcement 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 sent to the IETF standards process)
   standardize any Internet-specific IS-IS Extensions.

   Any IS-IS Extensions produced within list and the IETF that require standard-
   ization, but cannot be identified as Internet-specific per section
   2.2 of this document SHOULD RFC-DIST list.
Requests to be submitted for standardization added to JTC1
   (see section 3.3.2). IETF SHALL NOT publish documents describing such
   IS-IS extensions other than as Informational RFCs.

   IS-IS extensions submitted or deleted from the IETF to JTC1 will distribution list
should be processed
   under the JTC1 fast track procedure. To ensure the quality of such
   submissions, IETF SHALL apply sent to them the procedures for Proposed
   Standard submission according IETF-REQUEST@IETF.ORG.  Requests to [RFC2026] (even though these docu-
   ments will not be published as standards-track IETF RFCs).

 3.1 Requirements for IS-IS-specific IETF documents

   All IS-IS-related IETF draft documents intended to be published as
   IETF standards track RFCs MUST include a section explaining why they
   qualify
added to be considered as Internet-specific IS-IS Extensions
   described in section 2.2 of this document.

 3.2 IS-IS Registries (IANA Considerations)

  3.2.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 or deleted 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 is requested to create and maintain a registry for IS-IS TLV
   codepoints. The range of values is 0-255. Initial state of the reg-
   istry RFC-DIST distribution list should
be synchronized with [ISIS-TLVS]. Allocation of values
   in the registry has sent 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 aris-
   ing within JTC1 constituencies to the IANA registry process.

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

 3.3 Collaboration Guidelines

  3.3.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 RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via appointed SC6 / IETF liaison representatives.

  3.3.2 Submitting IETF Documents to JTC1

   As a class A liaison organisation to JTC1, the Internet Society FTP or EMAIL 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 obtained by one
   of the IETF ISIS WG chairs, or an IETF Routing Area director, sending
an e-mail EMAIL message to rfc-info@RFC-EDITOR.ORG with the secretariat of ISO JTC 1 specifying the num-
   ber of the Informational RFC containing the specification (the docu-
   ment 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 message body
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for the fast-track document.

  3.3.3 Submitting JTC1 Documents to IETF

   It is possible special distribution should be addressed to make JTC1 standards specifications available for
   informational purposes of the IETF community by submitting either the text
author of the specification as an Internet Draft and requesting the RFC Edi-
   tor to publish the document as an Informational RFC. See sections
   4.2.2 and 7 of [RFC2026] for more information. Guidelines for Inter-
   net Draft preparation are given in [ID-GUIDE].

  3.3.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 e-
   mail to the working group mailing list), the ISIS WG chairs, the IETF
   Routing Area directors, question, 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 mes-
   sage to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the IETF ISIS WG mailing list requesting the comments.

4. References

[10589]
     ISO, "Intermediate system to Intermediate system routeing informa-
     tion exchange protocol RFC itself, all RFCs are for use in conjunction with the Protocol
unlimited distribution.echo
Submissions for
     providing the Connectionless-mode Network Service (ISO 8473)",
     ISO/IEC 10589:1992.

[RFC2026]
     S. Bradner, "The Internet Standards Process -- Revision 3", RFC
     2026, BCP 9, October 1996.

[ISIS-TLVS]
     draft-ietf-isis-wg-tlv-codepoints-01.txt

[ISISWG]
     "IS-IS Requests 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/ TechnicalCom-
     mitteeDetailPage.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 Comments should be sent to Authors of Internet-Drafts",
     http://www.ietf.org/ietf/1id-guidelines.txt

5. Signatures

    Approved,                               Approved,

    for ISO/IEC JTC1/SC6
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for the Internet Society

    Original signed by                      Original signed by

    _____________________                   _______________________

    XXXX                                    XXXX

    Date:  _________                        Date:  ___________

6. Security Considerations

   This type of non-protocol document does not directly affect the secu-
   rity of the Internet.

7. Author's address

   Alex Zinin
   Alcatel
   E-mail: zinin@psg.com further information.