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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "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.

This Internet-Draft will expire on March 1, 2004.

Copyright Notice

Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

The IAB has the responsibility to select an organization to undertake the delegated functions of the Protocol Parameter registry for each IETF protocol parameter. This document describes the selection criteria that are applicable to this task, and also describes the terms and conditions that are to be associated with this delegation of function.

1. Introduction

Within the charter of the IAB , it is noted that:

"The IAB must approve the appointment of an organization to act as IANA on behalf of the IETF." [2]Carpenter, B., Charter of the Internet Architecture Board, May 2000.

In the context of this role, this "IANA" function is more precisely described as a collection of protocol parameter registries [3]Huston, G., Defining the Role and Function of IETF Protocol Parameter Registry Operators, June 2003..

This document is intended to provide guidance to the IAB in selecting protocol parameter registry operators in terms of the applicable selection criteria, and the terms and conditions of delegation of the function.

2. General Selection Criteria

• Capable of undertaking defined roles and responsibilities
  • The most essential criteria to be used is that the registry operator be demonstrably capable of performing all of the roles and responsibilities of a Protocol Parameter Registry operator, as described in the document "Defining the Role and Function of IETF Protocol Parameter Registry Operators" [3]Huston, G., Defining the Role and Function of IETF Protocol Parameter Registry Operators, June 2003..
• Capable of operating the service in a timely manner
  • The operator should be able to resource the function such that all registrations that conform to the associated registration criteria are to published in a timely fashion.
• Contact and Services
  • The operator will be required to operate the registry using English as the service language. All information is to be published in English, and all service transactions should be undertaken using English by default.
• Enter into a Services Agremeement
  • The operator shall be capable of entering into a binding formal services agreement with the IETF-nominated contracting entity for a fixed term.

3. Terms and Conditions

Intellectual property rights and the registry operator

Any intellectual property rights of the IETF Protocol Parameter assignment information, including the IETF Protocol Parameter registry and its contents, are to be held by the IETF and ISOC, and all IETF Protocol Parameter registry publications relating to assignment information are to be published under the terms of Section 10 of RFC2026, and are to include the copyright notice as documented in Section 10.4 (C) of RFC2026 [1]Bradner, S., The Internet Standards Process -- Revision 3, October 1996..

Provide publication of registry contents on a freely available basis

All assigned values are to be published and made available free of any charges and free of any constraints relating to further redistribution, with the caveat that the assignment information may not be modified in any redistributed copy.

Not to sell or otherwise commercially exploit the registry data.

Operate Publically

All registry operations are to be performed publically. The registry operator must publish, on a timely basis a record of all correspondance relating to the operation of the registry, including all details of the parties that communicate to the registry, and publish all information obtained as part of th registry operation. The registry operator may not recieve information of a private or limited disclosure nature as part of its registry operation functions.

Not to withold any data from the IETF

All information collected as part of the registry opertion, including details of contacts, all correspondance, documents, and all other information collected by the registry operator in the course of operating the registry are to be made available to the IETF on demand and in any case at the expiration of the services agreement. The information shall be made available free of any charge to the IETF.

Data Escrow ands Backup

Provide access to the IETF or a nominated agent to provide a reliable backup copy of all registry data in an agreed format on a continual basis. The data includes all registry contents and an archive of all registry-related email and records of contacts.

Service Initialisation

At the beginning of operations, the operator shall take over from its predecessor (if such exists) all current, backed up and escrowed data as well as records of operations in progress at that time. The operator shall take all reasonable steps to prevent discontuity of service.

Service Termination

At the termination of the service agreement pass all data, including archives of all email and all information obtained as part of the operation of the registry to the IETF or its nominated sucessor registry operator. This shall include all current, backed up and escrowed data as well as records of operations in progress at that time. The operator shall take all reasonable steps to prevent discontuity of service.

4. Agreement Template

Intended Use:

This agreement template shall be used by the Internet Engineering Task Force ("IETF") as the basis for an agreement between the IETF and an IETF Protocol Registry Operator ("Operator"). Its intent is exclusively to define the technical work to be carried out by the Operator on behalf of the IETF.

Non-Exclusive:

The Operator is not bound to provide such services exclusively to the IETF, and may provide similar services to other organisations with respect to protocols not within IETF's scope (i.e. registries not created by IETF or IRTF action); nothing in this agreement limits the Operator's ability to do so.

Period:

This MOU will remain in effect for a period of three years from the date of execution of this agreement, unless either modified or cancelled by mutual consent of the IETF and the Operator, or cancelled by either party with at least 6 months notice.

Definition of Terms

The following definitions of terms and abbreviations chall apply in this agreement.

ICANN

Internet Corporation for Assigned Names and Numbers, a California non-profit corporation.

IETF

the Internet Engineering Task Force, the unincorporated association operating under such name that creates Internet Standards and related documents.

IAB

the Internet Architecture Board, an oversight committee of the IETF. The IAB is chartered to designate IETF Protocol parameter Registry Operators on behalf of the IETF.

IESG

the Internet Engineering Steering Group, a management committee of the IETF.

IRTF

the Internet Research Task Force, an unincorporated association also overseen by the IAB.

IRSG

the Internet Research Steering group, a management committee of the IRTF.

RFC

"Request For Comments", the archival document series of the IETF, also used by the IRTF and by third parties.

ISOC

the Internet Society, a not-for-profit corporation that supports the IETF.

Work Items:

The Operator agrees that during the term of this MOU it shall comply with the following requirements:

1. The Operator will assign and register Internet protocol parameters only as directed by the IESG, using criteria and procedures specified in RFCs, including Proposed, Draft and full Internet Standards and Best Current Practice documents, and any other RFC that calls for Protocol Parameter assignment.
2. If in doubt or in case of a technical dispute, the Operator will seek and follow technical guidance exclusively from the IESG. Where appropriate the IESG will appoint an expert to advise the Operator.
3. The Operator will work with the IETF to develop any missing criteria and procedures over time, which the Operator will adopt when so instructed by the IESG.
4. In the event of technical dispute between the Operator and the IESG, both will seek guidance from the IAB whose decision shall be final.
5. The Operator shall make available to the public, on-line and free of charge, information about each current assignment, including contact details for the assignee.
6. The Operator shall provide on-line facilities for the public to request Internet protocol parameter assignments and shall either execute such assignments, or deny them for non-conformance with applicable technical requirements, in a timely manner. There shall be no charge for assignments without the consent of the IAB. Requests shall only be denied on legitimate technical grounds.
7. For protocols within the IETF scope (i.e., registries created by IETF action), appeals against such denials may be made to the IESG and subsequently to the IAB.
8. The IESG may invite the Operator to have non-voting liaison seats on appropriate IETF committees as determined by the IESG, and may participate in all IETF discussions concerning technical requirements for protocol parameter assignment through such liaisons.
9. At the invitation of the IESG, the Operator shall review documents in IETF Last Call to identify any issues of concern to the Operator, and shall raise these issues with the IESG.

Certain of the protocol parameters that may be assigned to the Operator will be relevant to the IRTF, rather than IETF. With respect to these protocol parameters, the Operator will comply with the procedures set forth in the Section titled "Work Items", with the understanding that IRTF and IRSG shall be substituted for IETF and IESG, respectively, in such procedures. In the event of any question as to whether a particular protocol parameter relates principally to IETF or IRTF, the IAB shall have the authority to answer such question in its discretion.

General Provisions:

This agreement does not constitute any of the parties as a partner, joint venturer, agent, principal or franchisee of any other party. The waiver of any provision of this Agreement on any occasion shall not constitute a waiver for purposes of any other occasion. Neither party may transfer or assign any interest, right or obligation arising under this Agreement without the prior written consent of each other party to this Agreement.

5 References

Author's Address

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

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

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.

Acknowledgment

Funding for the RFC Editor function is currently provided by the Internet Society.