GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5615

Network Working Group C. Groves Request for Comments: 5615 NTEC Australia BCP: 151 Y. Lin Category: Best Current Practice Huawei

                                                           August 2009
               H.248/MEGACO Registration Procedures

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.

Status of This Memo

 This document specifies an Internet Best Current Practices for the
 Internet Community, and requests discussion and suggestions for
 improvements.  Distribution of this memo is unlimited.

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 & Lin Best Current Practice [Page 1] RFC 5615 H.248/MEGACO Registration Procedures August 2009

Table of Contents

 1. Introduction ....................................................2
 2. Conventions Used in This Document ...............................4
 3. Formal Syntax ...................................................4
 4. Security Considerations .........................................5
 5. IESG Expert Reviewer Considerations .............................6
    5.1. Appointment of the IESG H.248/MEGACO Expert ................6
    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 .......................10
 6. IANA Considerations ............................................11
    6.1. New IANA Package Registration .............................11
    6.2. IANA Error Code Registration ..............................12
    6.3. IANA ServiceChange Reason Registration ....................12
    6.4. IANA Profile Name Registration ............................12
 7. References .....................................................13
    7.1. Normative References ......................................13
    7.2. Informative References ....................................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 introduced, in
 part, 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.
 The introduction of problems/inconsistencies was caused, in part, 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 the ITU-T Study Group 16 and the IETF MEGACO Working Groups were
 both active in H.248/MEGACO 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

Groves & Lin Best Current Practice [Page 2] RFC 5615 H.248/MEGACO Registration Procedures August 2009

 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 (notwithstanding 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 will 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 of
 Recommendations (ITU-T 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.  Wherever possible, this review will
 be done in conjunction with other H.248/MEGACO experts (e.g., in
 ITU-T 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".  However, if the Package has not been provided for review or
 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 to 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

Groves & Lin Best Current Practice [Page 3] RFC 5615 H.248/MEGACO Registration Procedures August 2009

 with the considerations documented in [H248amm1] and with [RFC3525]
 (with the exception of Profile Names, which did not appear in the
 [RFC3525] 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 [RFC5234].
 Text-encoded PackageIDs shall conform to the "PackageName" encoding
 in H.248.1 [H248amm1] Annex B, which is repeated below for
 convenience:
 Copyright (c) 2009 IETF Trust and the persons identified as authors
 of the code.  All rights reserved.
 Redistribution and use in source and binary forms, with or without
 modification, are permitted provided that the following conditions
 are met:
  1. Redistributions of source code must retain the above copyright

notice, this list of conditions and the following disclaimer.

  1. Redistributions in binary form must reproduce the above copyright

notice, this list of conditions and the following disclaimer in

   the documentation and/or other materials provided with the
   distribution.
  1. Neither the name of Internet Society, IETF or IETF Trust, nor the

names of specific contributors, may be used to endorse or promote

   products derived from this software without specific prior
   written permission.
 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
 A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT
 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY

Groves & Lin Best Current Practice [Page 4] RFC 5615 H.248/MEGACO Registration Procedures August 2009

 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
   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
 [H248amm1].
 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
 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 upon between a Media
 Gateway Controller (MGC) and a Media Gateway (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 an 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 in 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.

Groves & Lin Best Current Practice [Page 5] RFC 5615 H.248/MEGACO Registration Procedures August 2009

 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
 H.248/MEGACO development.  As such, it is recommended that
 identification of the IESG expert be done in consultation with the
 ITU-T Question/Study Group responsible for the H.248 sub-series of
 Recommendations (ITU-T 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 [H248amm1], "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 (ITU-T 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.

Groves & Lin Best Current Practice [Page 6] RFC 5615 H.248/MEGACO Registration Procedures August 2009

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

Groves & Lin Best Current Practice [Page 7] RFC 5615 H.248/MEGACO Registration Procedures August 2009

    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 a non-
       disclosure agreement (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.
 Status - "In Progress" indicates that the Package has not been fully
 reviewed and approved and, 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 organization), 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.

Groves & Lin Best Current Practice [Page 8] RFC 5615 H.248/MEGACO Registration Procedures August 2009

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

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 a register ServiceChange
 Reason with IANA:
 1) A reason number and a one-phrase (80-character maximum) unique
    string are registered for each reason.

Groves & Lin Best Current Practice [Page 9] RFC 5615 H.248/MEGACO Registration Procedures August 2009

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

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:
 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 and email and postal address 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 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 Profile Name.

Groves & Lin Best Current Practice [Page 10] RFC 5615 H.248/MEGACO Registration Procedures August 2009

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 ServiceChange
 Reason information in the H.248/MEGACO 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 the [RFC3525] 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 5.2).
 After the review, when instructed by the IESG-appointed expert, the
 IANA shall register the following information in the "H.248/MEGACO
 Packages" registry as described below:
 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
 will be entered, replacing the previous version in the registry.

Groves & Lin Best Current Practice [Page 11] RFC 5615 H.248/MEGACO Registration Procedures August 2009

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 and required
 specification) to the IESG-appointed expert for review (see Section
 5.3).
 When instructed by the IESG-appointed expert, the IANA shall register
 the following information in the "H.248/MEGACO 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 a ServiceChange Reason registration, the IANA
 shall forward the received information (i.e., the ServiceChange
 Reason text and required specification) to the IESG-appointed expert
 for review (see Section 5.4).
 When instructed by the IESG-appointed expert, the IANA shall register
 the following information in the "H.248/MEGACO Packages" registry as
 described below:
 1. ServiceChange Reason Number
 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 received information to the IESG-appointed expert for review
 (see Section 5.5).
 When instructed by the IESG-appointed expert, the IANA shall register
 the following information in the "H.248/MEGACO Packages" registry as
 described below:

Groves & Lin Best Current Practice [Page 12] RFC 5615 H.248/MEGACO Registration Procedures August 2009

 1. Profile Name
 2. Version
 3. Reference/Contact

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., Ed., and P. Overell, "Augmented BNF for
            Syntax Specifications: ABNF", STD 68, 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., Ed., Pantaleo, M., Ed., Anderson, T., Ed., and
            T. Taylor, Ed., "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 H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 5226,
            May 2008.

Groves & Lin Best Current Practice [Page 13] RFC 5615 H.248/MEGACO Registration Procedures August 2009

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 & Lin Best Current Practice [Page 14]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5615.txt · Last modified: 2009/08/11 22:09 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki