Network Working Group C. Groves Internet Draft NTEC Australia Intended status: BCP Y. Lin Expires: January 2009 Huawei July 29, 2008 H.248/MEGACO Registration Procedures draft-groves-megaco-pkgereg-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 January 29, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document updates the H.248/MEGACO IANA Package Registration procedures in order to better describe the Package registration process and to provide a more formal review and feedback process. Groves Expires January 29, 2009 [Page 1] Internet-Draft Package Registration Procedures July 2008 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Table of Contents 1. Introduction ........................................... 2 2. Formal Syntax ......................................... 4 3. Security Considerations ................................ 4 4. IESG Expert Reviewer Considerations .................... 4 4.1. Appointment of the IESG H.248/MEGACO Expert ....... 5 4.2. Package Registration Procedure .................... 5 4.3. Error Code Registration Procedure ................. 7 4.4. ServiceChange Reason Registration Procedure ....... 8 4.5. Profile Name Registration Procedure ............... 8 5. IANA Considerations .................................... 9 5.1. New IANA Package Registration ..................... 9 5.2. IANA Error Code Registration ..................... 10 5.3. IANA ServiceChange Reason Registration ........... 10 5.4. IANA Profile Name Registration ................... 11 6. Acknowledgments ....................................... 11 7. References ............................................ 12 7.1. Normative References ............................. 12 7.2. Informative References............................ 12 Authors' Addresses ....................................... 12 Intellectual Property Statement .......................... 13 Disclaimer of Validity ................................... 13 1. Introduction Since the initial development of H.248/MEGACO a number of organizations have made use of the H.248/MEGACO protocol Package mechanism in order to allow a certain function to be controlled by H.248/MEGACO. The H.248/MEGACO package mechanism was in part introduced to allow organizations who had an in depth knowledge in a particular functional area to independently produce a package on this functionality. This acknowledged the fact that neither the IETF MEGACO Working Group nor the ITU-T Study Group 16 possessed in depth knowledge in all areas. Whilst this approach has been successful in the number and range of packages produced, in some cases these Packages were/are not fully aligned with H.248/MEGACO principles. Once a Package has been published and registered it is problematic to rectify any issues. Groves Expires January 29, 2009 [Page 2] Internet-Draft Package Registration Procedures July 2008 The introduction of problems/inconsistencies was in part caused by the fact that the Packages were not fully reviewed by H.248/MEGACO experts. In fact the IANA H.248/MEGACO registration process did not actually specify that an in depth review should take place. The current H.248/MEGACO Package registration process was defined when ITU-T Study Group 16 and the IETF Megaco Working Groups were both active in Megaco/H.248 standardization and produced nearly all the registered Packages. Packages were reviewed in the IETF MEGACO Working Group and the Working Group chair was the IESG appointed expert in charge of the review of the requests for H.248 Package registration. This meant that H.248 Packages underwent an informal review before being registered. However this has changed. The current situation is that now the IETF Megaco working group is disbanded and new H.248/MEGACO development typically occurs through Question 3 of ITU-T Study Group 16 (not withstanding email discussion on the IETF MEGACO mailing list). This move to ITU-T defined Recommendations is discussed in [RFC5125]. Given this situation, it is appropriate that the H.248/Package Package definition and IANA registration rules are updated to introduce a formal review step before the Package registration process is completed and ideally before the Package is published. This process would only be applicable to public Packages. As part of the Package development process Package developers are encouraged to send their Package for review to the ITU-T Study Group Question Rapporteur responsible for the H.248 sub-series (Question 3 of Study Group 16 at the time of writing). When registering the Package with IANA, package developers are required to send a copy of the package for review by the IESG appointed expert. It is recommended to register the Package before final approval by the group in question in order to solicit feedback on the quality of their Package. Where ever possible this review will be done in conjunction with other H.248/MEGACO experts (e.g. in Q.3/16 and/or the MEGACO mailing list). The existing IANA Package registration process is a two step process. When Packages are first registered they receive the status of "In Progress (IP)". This allows Package developers to request a PackageID before the document is fully approved. When the document is approved then a change of status to "Final", may be requested. The new procedure introduces the step that the IESG appointed expert is consulted before a change of status is made. If the Package has been reviewed and is acceptable then the status may be changed to "Final". Groves Expires January 29, 2009 [Page 3] Internet-Draft Package Registration Procedures July 2008 However if the package has not been provided for review or it has outstanding comments then the status SHALL remain at "IP". The goal of the updated text is to define a process that provides a timely technical review of packages to ensure that H.248/MEGACO packages are of good quality and minimize duplication. The "Error Code", "ServiceChange Reason" and "Profile Name" registration procedures have been included for completeness and to make explicit the role of the IESG reviewer. These procedures align with the considerations documented in [H.248amm1] and with [RFC3525] (with the exception of Profile Names which did not appear in this version). 2. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-5234 [RFC5234]. Text encoded PackageIDs shall conform to the "PackageName" encoding in H.248.1 [H248amm1] Annex B. Repeated below for convienience: PackageName = NAME NAME = ALPHA *63(ALPHA / DIGIT / "_") Note: A digit is not allowed as the first character of a package name. 3. Security Considerations Updating the IANA H.248/MEGACO package registration procedures has no additional security implications. Security for the H.248/MEGACO protocol is discussed in H.248.1 section 10 [H.248amm1]. Requesters for public packages for a particular standards development organization must be authorized by that organization to request a Package registration. 4. IESG Expert Reviewer Considerations For public registered Packages, Error Codes, ServiceChangeReasons and Profile Names review by an Expert reviewer is required before IANA performs a registration. Private Packages do not require the same level of review. The sections below outline the considerations for Expert review. Groves Expires January 29, 2009 [Page 4] Internet-Draft Package Registration Procedures July 2008 4.1. Appointment of the IESG H.248/MEGACO Expert The IESG shall remain responsible for allocating the H.248/MEGACO expert. It is recommended that this person be involved in ongoing H.248/MEGACO development. As such it is recommended that identification of the IESG expert be done in consultation with the ITU-T Study Group/Question responsible for the H.248 sub-series of Recommendations, Q.3/16 at the time of writing. 4.2. Package Registration Procedure Package requesters are encouraged to review their work against H.248.1 section 12 [H.248amm1] "Package Definition" and are encouraged to use the "Package Definition Template" provided in H.248.1 Appendix II. The process for registering a public Package is deemed to be "specification required" as per [RFC5226]. As such once the initial checks occur Package requesters for public packages under development shall send the package text to IANA. They are also encouraged to send the package to the ITU-T Question/Study Group responsible for the H.248 sub-series of Recommendations (Q.3/16 at the time of writing) for review. Updated contact information can be found in the latest version of the H.248 Sub-series Implementors' Guide. This should occur as soon as practicable after the rough draft of the definition is completed and at least before the package is approved in order to ensure the package is consistent with H.248 methodologies and package design principles. In order to register private packages, a specification is not required but is encouraged. Package requesters are encouraged to request registration as early as practicable in the design process, to reserve a binary ID. Binary IDs shall be published in the document defining the package. Once the initial or final request for a Package registration is received by IANA it will be forwarded to the IESG appointed Expert for review. During the review the input package and details will be compared to the Package template for completeness, as well as being compared against protocol syntax and procedures. It will be compared against existing work to see that it does not duplicate existing functionality. The Expert reviewer will then work towards a resolution of any issues with the Package requester. The IESG appointed Expert may complete the review in consultation with other H.248 experts (i.e. Currently Question 3 of ITU-T Study Group 16 and via email to IETF Megaco email list). If the package is deemed Groves Expires January 29, 2009 [Page 5] Internet-Draft Package Registration Procedures July 2008 suitable, the IESG appointed Expert shall issue a statement indicating approval, copied to IANA. The IESG Expert Reviewer will ensure the following considerations are met to register a package with the IANA: 1) A unique string name, unique serial number and version number is registered for each package. The string name is used as the PackageID for text encoding. The serial number is used as the PackageID for binary encoding. Public packages MUST be given serial numbers in the range 0x0001 to 0x7fff. Private packages MUST be given serial numbers in the range 0x8000 to 0xffff. Serial number 0 is reserved. The unique string name and unique serial number MAY either be requested by the package requester or if not requested, assigned by the IANA. 2) The package requester shall provide a contact name, email and postal addresses for that contact shall be specified. The contact information shall be updated by the defining organization as necessary. 3) The public package requester shall provide a reference to a document that describes the package, which should be public: a) The document shall specify the version of the package that it describes. b) If the document is public, it should be located on a public web server and should have a stable URL. The site should provide a mechanism to provide comments and appropriate responses should be returned. c) If the document is not public, it must be made available for review by the IESG appointed Expert (without requiring an NDA) at the time of the application. Note: The documenting text does not have to be publicly available at the time of the registration request, however the text shall be provided available for review by the IESG appointed Expert at the time of application. For private packages a contact email address for the package registration shall be provided. 4) Packages registered by other than recognized standards bodies shall have a minimum package name length of 8 characters. Groves Expires January 29, 2009 [Page 6] Internet-Draft Package Registration Procedures July 2008 5) Package names are allocated on a first come-first served if all other conditions are met. Status - "In Progress" indicates that the package has not been fully reviewed and approved therefore may contain errors or may not be consistent with H.248 principles. "Final" indicates that the Package has been reviewed and approved and is stable. New packages shall be registered with a status of "IP". Once the Package has been finalized (i.e. approved according to the procedures of the Package Requester's Organisation)they should contact IANA in order to update the status to "Final". Once the IESG Appointed Expert has determined that the registration is appropriate they will advise the IANA to register the Package. The IANA will assign a serial number to each package meeting the conditions of registration (except for an update of an existing package, which retains the serial number of the package it is updating), in consecutive order of registration. 4.3. Error Code Registration Procedure Error Code requesters shall send a request to the IANA to register the error code. Documentation addressing the considerations below shall be provided (i.e. Specification required as per [RFC5226]). The IANA shall then forward the request to the IESG appointed Expert for review. The following considerations shall be met to register an error code with IANA: 1) An error number and a one-line (80-character maximum) string are registered for each error. 2) A complete description of the conditions under which the error is detected shall be included in a publicly available document. The description shall be sufficiently clear to differentiate the error from all other existing error codes. 3) The document should be available on a public web server and should have a stable URL. 4) Error numbers registered by recognized standards bodies shall have 3- or 4-character error numbers. Groves Expires January 29, 2009 [Page 7] Internet-Draft Package Registration Procedures July 2008 5) Error numbers registered by all other organizations or individuals shall have 4-character error numbers. 6) An error number shall not be redefined nor modified except by the organization or individual that originally defined it, or their successors or assigns. Once the IESG Appointed Expert has determined that the registration is appropriate they will advise the IANA to register the Package. 4.4. ServiceChange Reason Registration Procedure ServiceChange Reason requesters shall send a request to the IANA to register the ServiceChange Reason. Documentation addressing the considerations below shall be provided (i.e. Specification required as per [RFC5226]). The IANA shall then forward the request to the IESG appointed Expert for review. The following considerations shall be met to register ServiceChange reason with IANA: 1) A one-phrase, 80-character maximum, unique reason code is registered for each reason. 2) A complete description of the conditions under which the reason is used shall be included in a publicly available document. The description shall be sufficiently clear to differentiate the reason from all other existing reasons. 3) The document should be available on a public web server and should have a stable URL. Once the IESG Appointed Expert has determined that the registration is appropriate they will advise IANA to register the Package. 4.5. Profile Name Registration Procedure Profile Name requesters shall send a request to the IANA to register the Profile Name. Documentation addressing the considerations below shall be provided. The IANA shall then forward the request to the IESG appointed Expert for review. The following considerations shall be met to register a profile with IANA: Groves Expires January 29, 2009 [Page 8] Internet-Draft Package Registration Procedures July 2008 1) A unique string name and version number (version may be omitted when the profile name contains a wildcard) is registered for each profile. 2) A contact name, email and postal addresses for that contact shall be specified. The contact information shall be updated by the defining organization as necessary. 3) Profiles registered by other than recognized standards bodies shall have a minimum profile name length of 6 characters. 4) Profile names containing a wildcard "*" on the end of their names shall be accepted if the first 6 characters are fully specified. It is assumed that the organization that was issued with the profile name will manage the namespace associated with the wildcard. IANA shall not issue other profiles names within "name*" range. All other profile names are first come-first served if all other conditions are met. Once the IESG Appointed Expert has determined that the registration is appropriate they will advise IANA to register the Package. 5. IANA Considerations This document describes an updated package registration procedure. [RFC5226] has been considered in making the updates. This document does not alter the tabular package, error code and service change reason information in the Megaco/H.248 Packages registry. The "Error Code", "ServiceChange Reason" and "Profile Name" IANA considerations have been included for completeness. These considerations align with the considerations documented in H.248.1 [H248amm1] and with [RFC3525] (with the exception of Profile Names which did not appear in this version). 5.1. New IANA Package Registration On the request for an initial or final Package registration the IANA shall forward to received information (i.e. the Package Text (Specification required as per [RFC5226]) to the IESG appointed expert for review (See section 4.2). After the review when instructed by the IESG appointed Expert the IANA shall register the following information in the "Megaco/H.248 Packages" registry as described below: Groves Expires January 29, 2009 [Page 9] Internet-Draft Package Registration Procedures July 2008 1. Binary ID (or serial number) 2. Text ID - See section 3 for the syntax. 3. Package version 4. Extension information - Binary ID and package version 5. Status* - IP ("In Progress") or Final. 6. Package name, Reference and Contact information IANA will maintain the currency and public availability of the tabulation of public and private packages. Packages will be listed in increasing order of serial number. Updates to packages will be listed in increasing order of version number. 5.2. IANA Error Code Registration On the request for an Error Code registration, the IANA shall forward to received information (i.e. the Error Code text (Specification required) to the IESG appointed expert for review (See section 4.3). When instructed by the IESG appointed Expert the IANA shall register the following information in the "Megaco/H.248 Packages" registry as described below: 1. Error Code Number 2. Error Code Text String 3. Reference 5.3. IANA ServiceChange Reason Registration On the request for an Error Code registration, the IANA shall forward to received information (i.e. the Service Change Reason text (Specification required) to the IESG appointed expert for review (See section 4.4). When instructed by the IESG appointed Expert the IANA shall register the following information in the "Megaco/H.248 Packages" registry as described below: 1. ServiceChange Reason Number 2. ServiceChange Reason Text String Groves Expires January 29, 2009 [Page 10] Internet-Draft Package Registration Procedures July 2008 3. Reference 5.4. IANA Profile Name Registration On the request for a Profile Name registration, the IANA shall forward to received request to the IESG appointed expert for review (See section 4.5). When instructed by the IESG appointed Expert the IANA shall register the following information in the "Megaco/H.248 Packages" registry as described below: 1. Profile Name 2. Version 3. Reference/Contact 6. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Groves Expires January 29, 2009 [Page 11] Internet-Draft Package Registration Procedures July 2008 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5234] Crocker, D. and Overell, P., "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008. [H248amm1] International Telecommunication Union, "Gateway control protocol: Version 3", Amendment 1 to ITU-T Recommendation H.248.1, April 2008. 7.2. Informative References [RFC3525] Groves C., Pantaleo M., Anderson T. and Taylor T., "Gateway Control Protocol Version 1", RFC 3525, June 2003. [RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", RFC 5125, February 2008. [RFC5226] Narten, T. and Alvestrand, H., "Guidelines for Writing an IANA Considerations Section in RFCs", BCP26, RFC 5226, May 2008. Authors' Addresses Christian Groves NTEC Australia Newport, Victoria Australia Email: Christian.Groves@nteczone.com Yangbo Lin Huawei Technologies Co., Ltd. Shenzhen, Guangdong P. R. China Email: linyangbo@huawei.com Groves Expires January 29, 2009 [Page 12] Internet-Draft Package Registration Procedures July 2008 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Groves Expires January 29, 2009 [Page 13]