doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc5615.txt b/doc/rfc/rfc5615.txt
new file mode 100644
index 0000000..8d80692
--- /dev/null
+++ b/doc/rfc/rfc5615.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+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:
+
+   - Redistributions of source code must retain the above copyright
+     notice, this list of conditions and the following disclaimer.
+
+   - 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.
+
+   - 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]
+