H.248/MEGACO Registration Procedures
draft-groves-megaco-pkgereg-04

Network Working Group                                       C. Groves 
Internet Draft                                          NTEC Australia 
Intended status: BCP                                           Y. Lin 
Expires: November 2009                                         Huawei 
                                                          May 25, 2009 
                                                            
 
                                      
                   H.248/MEGACO Registration Procedures 
                    draft-groves-megaco-pkgereg-04.txt 

Status of this Memo 

   This Internet-Draft is submitted to IETF in full conformance with the 
   provisions of BCP 78 and 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/1id-abstracts.html 

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

   This Internet-Draft will expire on October 25, 2009. 

Copyright Notice 

   Copyright (c) 2009 IETF Trust and the persons identified as the 
   document authors.  All rights reserved. 

   This document is subject to BCP 78 and the IETF Trust's Legal 
   Provisions Relating to IETF Documents in effect on the date of 
   publication of this document (http://trustee.ietf.org/license-info). 
   Please review these documents carefully, as they describe your 
   rights and restrictions with respect to this document. 
    

    
 
 
 
Groves                Expires November 25, 2009               [Page 1] 


Internet-Draft     Package Registration Procedures            May 2009 
    

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. 

Table of Contents 

   1. Introduction ................................................. 2 
   2. Conventions used in this document ............................ 4 
   3. Formal Syntax ................................................ 4 
   4. Security Considerations ...................................... 4 
   5. IESG Expert Reviewer Considerations .......................... 5 
      5.1. Appointment of the IESG H.248/MEGACO Expert ............. 5 
      5.2. Package Registration Procedure .......................... 6 
      5.3. Error Code Registration Procedure ....................... 8 
      5.4. ServiceChange Reason Registration Procedure ............. 9 
      5.5. Profile Name Registration Procedure ..................... 9 
   6. IANA Considerations ......................................... 10 
      6.1. New IANA Package Registration .......................... 10 
      6.2. IANA Error Code Registration ........................... 11 
      6.3. IANA ServiceChange Reason Registration ................. 11 
      6.4. IANA Profile Name Registration ......................... 12 
   7. References .................................................. 13 
      7.1. Normative References ................................... 13 
      7.2. Informative References ................................. 13 
   8. Acknowledgments ............................................. 13 
   Authors' Addresses ............................................. 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. 

 
 
Groves                Expires November 25, 2009               [Page 2] 


Internet-Draft     Package Registration Procedures            May 2009 
    

   Once a Package has been published and registered it is problematic to 
   rectify any issues.  

   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 
   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 
 
 
Groves                Expires November 25, 2009               [Page 3] 


Internet-Draft     Package Registration Procedures            May 2009 
    

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

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

4. Security Considerations 

   Updating the IANA H.248/MEGACO package registration procedures has no 
   additional security implications. Security for the H.248/MEGACO 
   protocol over IP transports is discussed in H.248.1 section 10 
   [H.248amm1].  

   As of this date there have been no recorded security issues arising 
   out of the registration or use of packages. Whilst packages may 
   define extra procedures and code points these are done within the 
 
 
Groves                Expires November 25, 2009               [Page 4] 


Internet-Draft     Package Registration Procedures            May 2009 
    

   framework of the core H.248.1 specification. It is not possible to 
   update the H.248.1 core protocol through a package specification. The 
   use of the H.248.1 core protocol is agreed between a MGC and a MG. 
   H.248 ServiceChange procedures establish a H.248 control association 
   between the MGC and MG. To establish an association there must be a 
   level of trust between the MGC and MG. In the context of this control 
   (and trust) association the elements 
   (properties/signals/events/statistics) from the Packages are conveyed 
   between the MGC and MG. An MGC or MG will only act upon elements that 
   it knows. If it does not understand a PackageID or package element 
   then an error response is returned only in the context of the control 
   association.  
    
   If a malicious Package Specification is implemented in a MGC or MG it 
   would be unlikely to cause problems. As H.248 is a master slave 
   protocol, if the malicious package was implemented in the MGC and not 
   the MG there would be no action because the MG would not understand 
   the PackageID (and elements). If the malicious package was 
   implemented on the MG there would be no effect because the MGC would 
   never command the MG to use it. If the malicious package was 
   implemented in both the MGC and MG then there's a wider non-H.248 
   issue that someone has managed to install software on both the MGC 
   and the MG. It is highly unlikely for such a person to ask IANA for a 
   PackageID when they could use any one they want. 

   Therefore it is in this respect that updates to the IANA H.248/MEGACO 
   package registration procedures are deemed to have no additional 
   security impacts. 

   Requesters and the Expert reviewer should ensure that the package 
   does not introduce any additional security issues. Requesters for 
   public packages for a particular standards development organization 
   must be authorized by that organization to request a Package 
   registration.  

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

5.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 
 
 
Groves                Expires November 25, 2009               [Page 5] 


Internet-Draft     Package Registration Procedures            May 2009 
    

   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. 

5.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. It will be reviewed to see that any potential security 
   issues are addressed. 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 
   suitable, the IESG appointed Expert shall issue a statement 
   indicating approval, copied to IANA. 

 
 
Groves                Expires November 25, 2009               [Page 6] 


Internet-Draft     Package Registration Procedures            May 2009 
    

   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, and an email 
   and postal addresses for that contact. 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 document does not have to be publicly available at the time 
   of the registration request, however the document shall be provided 
   and available for review by the IESG appointed Expert. Once approved 
   by a standards body the package SHOULD be made publicly available 
   however the package MAY remain not public.  

   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. 

   5) Package names are allocated on a first come-first served basis if 
   all other conditions are met. 

 
 
Groves                Expires November 25, 2009               [Page 7] 


Internet-Draft     Package Registration Procedures            May 2009 
    

   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. 

    

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

   5) Error numbers registered by all other organizations or individuals 
   shall have 4-character error numbers. 

 
 
Groves                Expires November 25, 2009               [Page 8] 


Internet-Draft     Package Registration Procedures            May 2009 
    

   6) Only the organization or individual that originally defined it (or 
   their successors or assigns) can modify an error number definition. 
   If the modification leads to a change in the error code number, error 
   code name or error string the Error Code modifier shall send a 
   request to IANA to register the update. This request shall be treated 
   as a new error code request which will involve an Expert review. 

   Once the IESG Appointed Expert has determined that the registration 
   is appropriate they will advise the IANA to register the Package. 

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

5.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 November 25, 2009               [Page 9] 


Internet-Draft     Package Registration Procedures            May 2009 
    

   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. 

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

6.1. New IANA Package Registration 

   On the request for an initial or final Package registration the IANA 
   shall forward the 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 November 25, 2009              [Page 10] 


Internet-Draft     Package Registration Procedures            May 2009 
    

   1. Serial Number (Identity used for Binary Encoding, also known as 
      Binary ID)  

   2. Text Name (Identity used for Text Encoding, 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.  The latest Package version is 
   entered, replacing the previous version in the registry. 

6.2. IANA Error Code Registration 

   On the request for an Error Code registration, the IANA shall forward 
   the 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 

6.3. IANA ServiceChange Reason Registration 

   On the request for an Error Code registration, the IANA shall forward 
   the received information (i.e. the Service Change Reason text and 
   required specification) 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 
 
 
Groves                Expires November 25, 2009              [Page 11] 


Internet-Draft     Package Registration Procedures            May 2009 
    

   2. ServiceChange Reason Text String 

   3. Reference      

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

 
 
Groves                Expires November 25, 2009              [Page 12] 


Internet-Draft     Package Registration Procedures            May 2009 
    

 

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. 

8. Acknowledgments 

   This document was prepared using 2-Word-v2.0.template.dot. 

    

Authors' Addresses 

   Christian Groves 
   NTEC Australia  
   Newport, Victoria 
   Australia 
      
   Email: Christian.Groves@nteczone.com 
 

 
 
Groves                Expires November 25, 2009              [Page 13] 


Internet-Draft     Package Registration Procedures            May 2009 
    

   Yangbo Lin 
   Huawei Technologies Co., Ltd. 
   Shenzhen, Guangdong 
   P. R. China  
    
   Email: linyangbo@huawei.com 
 

 
 
Groves                Expires November 25, 2009              [Page 14]