RFC 5615

H.248/MEGACO Registration Procedures

📅 published August 2009, from ietf

RFC 5615: H.248/MEGACO Registration Procedures 💖

Okay bestie, here's the tea. This is BCP 151 (so it's a Best Current Practice, not a protocol spec), published August 2009. The authors are C. Groves from NTEC Australia and Y. Lin from Huawei. It doesn't list any RFCs it obsoletes or updates in its header. What it does do is update the H.248/MEGACO IANA Package registration procedures 🎀

Abstract ✨

This doc updates the H.248/MEGACO IANA Package registration procedures so the Package registration process is better described, with a more formal review and feedback process. 🦋

Status of This Memo 📜

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

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, because they describe your rights and restrictions with respect to this document. 🫶

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 🧚

Okay so ever since H.248/MEGACO got started, a bunch of orgs have used its Package mechanism to let a certain function be controlled by H.248/MEGACO. The Package mechanism was basically introduced so that orgs who really know their stuff in a particular functional area could build a Package on that functionality all on their own. This was a vibe because neither the IETF MEGACO Working Group nor the ITU-T Study Group 16 knew everything about every area. 🍓 The approach has been super successful in terms of how many Packages exist and how wide-ranging they are. Still, some of these Packages were/are not fully aligned with H.248/MEGACO principles, and once a Package has been published and registered, fixing problems is a whole mess. 😭

The problems/inconsistencies happened partly because the Packages weren't fully reviewed by H.248/MEGACO experts. Honestly? The IANA H.248/MEGACO registration process never actually said an in-depth review had to happen. 💀

The current Package registration process was set up back when both ITU-T Study Group 16 and the IETF MEGACO Working Groups were active in H.248/MEGACO standardization, and they produced almost all the registered Packages. Packages got reviewed in the IETF MEGACO Working Group, and the WG chair was the IESG-appointed expert in charge of reviewing requests for H.248 Package registration. So H.248 Packages got an informal review before they were registered. But that has changed. 🔄

Right now the IETF MEGACO Working Group is disbanded, and new H.248/MEGACO development usually happens through Question 3 of ITU-T Study Group 16 (even though there's still email discussion on the IETF MEGACO mailing list). This shift to ITU-T-defined Recommendations is discussed in [RFC5125]. 📚

So it makes sense to update the H.248/Package definition and the IANA registration rules to add a formal review step before the Package registration process is completed and, ideally, before the Package is published. ✨ This process will only apply to public Packages. 🌈

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, so you can solicit feedback on the quality of your 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 get the status of "In Progress (IP)". This lets Package developers request a PackageID before the document is fully approved. Once the document is approved, a change of status to "Final" may be requested. The new procedure adds a step: the IESG-appointed expert is consulted before any change of status happens. If the Package has been reviewed and is acceptable, the status may be changed to "Final". However, if the Package hasn't been provided for review or has outstanding comments, the status SHALL remain at "IP". 🚦

The goal of the updated text is to define a process that gives Packages a timely technical review, so H.248/MEGACO Packages are good quality and duplication is kept to a minimum. 🎯

The "Error Code", "ServiceChange Reason", and "Profile Name" registration procedures have been included for completeness and to make the role of the IESG reviewer explicit. These procedures line up with the considerations documented in [H248amm1] and with [RFC3525] (except for 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: 🍬

Here's the license block that comes with that repeated material. It's legal text, so I've kept it word-for-word: 📜

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

And here's the grammar itself, the main event 🤩

  PackageName   = NAME

  NAME       = ALPHA *63(ALPHA / DIGIT / "_")

Note: A digit is not allowed as the first character of a Package name. 🙈

5. IESG Expert Reviewer Considerations ✨

okay so, for public registered Packages, Error Codes, ServiceChangeReasons, and Profile Names, an Expert Reviewer is required to look at them before IANA registers anything 👀 Private Packages don't need the same level of review 💅 The sections below are the expert-review checklist, bestie.

5.1. Appointment of the IESG H.248/MEGACO Expert

The IESG is still the one in charge of allocating the H.248/MEGACO expert 👑 It's recommended that this person stays involved in ongoing H.248/MEGACO development, so it's giving continuity 🔥 That's why identifying the IESG expert should be done in consultation with the ITU-T Question/Study Group that handles 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 check their work against H.248.1 Section 12 [H248amm1], "Package Definition", and to use the "Package Definition Template" from H.248.1 Appendix II 📝

The process for registering a public Package is deemed to be "specification required" as per [RFC5226] 📋 So once the initial checks happen, Package requesters for public Packages that are still under development shall send the Package text to IANA 💌 They're also encouraged to send it to the ITU-T Question/Study Group that handles the H.248 sub-series of Recommendations (ITU-T Q.3/16 at the time of writing) for review 🫶 Updated contact info lives in the latest version of the H.248 Sub-series Implementors' Guide 📖 This should happen as soon as practicable after the rough draft of the definition is done, and at least before the Package is approved, so it stays consistent with H.248 methodologies and Package-design principles ✨

For private Packages, a specification isn't required, but it's encouraged 🤍

Package requesters are encouraged to request registration as early as practicable in the design process, so they can reserve a binary ID 🦋 Binary IDs shall be published in the document that defines the Package 📄

Once the initial or final request for a Package registration reaches IANA, it gets forwarded to the IESG-appointed expert for review 🔍 During the review, the Package and its details get checked against the Package template for completeness, and against protocol syntax and procedures ✅ It also gets compared to existing work to make sure it doesn't duplicate existing functionality 👯 And it gets checked to see that any potential security issues are addressed 🔐 The Expert Reviewer then works toward resolving any issues with the Package requester 🤝 The IESG-appointed expert may finish the review in consultation with other H.248 experts (that's currently Question 3 of ITU-T Study Group 16, and the 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 make sure the following considerations are met before registering a Package with IANA:

  1. A unique string name, a unique serial number, and a version number are registered for each Package 🏷️ The string name is used as the PackageID for text encoding, and 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 they aren't requested, assigned by IANA.
  2. The Package requester shall provide a contact name, an email address, and a 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, and that document 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 for 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 doesn't 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 it's approved by a standards body, the Package SHOULD be made publicly available, but the Package MAY remain not public 🫣

For private Packages, a contact email address for the Package registration shall be provided 📧

  1. Packages registered by anyone other than recognized standards bodies shall have a minimum Package name length of 8 characters 📏
  2. Package names are allocated on a first-come, first-served basis if all other conditions are met 🏃‍♀️

Status is a big deal 🥹 "In Progress" means the Package hasn't been fully reviewed and approved yet, so it may contain errors or might not be consistent with H.248 principles 🚧 "Final" means it's been reviewed, approved, and stable 💎 New Packages shall be registered with a status of "IP" 🆕 Once the Package has been finalized (meaning approved according to the procedures of the Package requester's organization), they should contact IANA to update the status to "Final" 🎀

Once the IESG-appointed expert decides the registration is appropriate, they will tell IANA to register the Package 💅

IANA will assign a serial number to each Package that meets the conditions of registration, in consecutive order of registration 🔢 The exception is an update to an existing Package, which keeps the serial number of the Package it's updating 🔁

5.3. Error Code Registration Procedure

Error Code requesters shall send a request to IANA to register the Error Code 📮 Documentation addressing the considerations below shall be provided (that's specification required as per [RFC5226]) 📑 Then IANA shall 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 string (80-character maximum) 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 clear enough to tell the error apart 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 an error number (or their successors or assigns) can modify that definition. If the modification changes the Error Code number, the Error Code name, or the error string, the Error Code modifier shall send a request to IANA to register the update. That request gets treated as a new Error Code request, which involves an Expert Review 🔄

Once the IESG-appointed expert decides the registration is appropriate, they will tell IANA to register the Error Code 🥳

5.4. ServiceChange Reason Registration Procedure

ServiceChange Reason requesters shall send a request to IANA to register the ServiceChange Reason 💌 Documentation addressing the considerations below shall be provided (again, specification required as per [RFC5226]) 📑 Then IANA shall forward the request to the IESG-appointed expert for review 🔍

The following considerations shall be met to register a ServiceChange Reason with IANA:

  1. A reason number and a one-phrase (80-character maximum) unique string are 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 clear enough to tell the reason apart 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 decides the registration is appropriate, they will tell IANA to register the ServiceChange Reason 💖

5.5. Profile Name Registration Procedure

Profile Name requesters shall send a request to IANA to register the Profile Name 📬 Documentation addressing the considerations below shall be provided 📑 Then IANA shall 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 a version number are registered for each profile. The version may be omitted when the Profile Name contains a wildcard 🃏
  2. A contact name, an email address, and a postal address for that contact shall be specified. The contact information shall be updated by the defining organization as necessary 📮
  3. Profiles registered by anyone other than recognized standards bodies shall have a minimum Profile Name length of 6 characters 📏
  4. Profile Names with a wildcard * on the end of their names shall be accepted if the first 6 characters are fully specified. It's assumed that the organization issued the Profile Name will manage the namespace behind the wildcard 🧸 IANA shall not issue other profile names within the name* range 🚫

All Profile Names are first-come, first-served if all other conditions are met 🏁

Once the IESG-appointed expert decides the registration is appropriate, they will tell IANA to register the Profile Name 🎀

6. IANA Considerations 🌈

This document describes an updated Package registration procedure. [RFC5226] was considered when making the updates 💅 This document doesn't change 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 are included for completeness 🫶 They line up with the considerations documented in H.248.1 [H248amm1] and with [RFC3525] (except for Profile Names, which didn't appear in the [RFC3525] version) 🦋

6.1. New IANA Package Registration ✨

okay so bestie, when someone asks for an initial or final Package registration, the IANA shall forward the received info (aka the Package text, which needs specification required as per [RFC5226]) to the IESG-appointed expert for review (see Section 5.2) 🧐

Once the IESG-appointed expert gives the green light, the IANA shall register the following info in the "H.248/MEGACO Packages" registry 📋

  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 keep the tabulation of public and private Packages current and publicly available 🌸 Packages get listed in increasing order of serial number, and the latest Package version replaces the previous one in the registry. No old versions hanging around, periodt 💅

6.2. IANA Error Code Registration

when someone requests an Error Code registration, the IANA shall forward the received info (the Error Code text and required specification) to the IESG-appointed expert for review (see Section 5.3) 🔍

When the IESG-appointed expert says it's a go, the IANA shall register this in the "H.248/MEGACO Packages" registry 🦋

  1. Error Code Number
  2. Error Code Text String
  3. Reference

6.3. IANA ServiceChange Reason Registration

same energy for ServiceChange Reasons 💖 The IANA shall forward the received info (the ServiceChange Reason text and required specification) to the IESG-appointed expert for review (see Section 5.4) 🧚

After the IESG-appointed expert instructs it, the IANA shall register this in the "H.248/MEGACO Packages" registry ✨

  1. ServiceChange Reason Number
  2. ServiceChange Reason Text String
  3. Reference

6.4. IANA Profile Name Registration

for Profile Names, the IANA shall forward the received info to the IESG-appointed expert for review (see Section 5.5) 🎀

When the IESG-appointed expert instructs it, the IANA shall register the following info in the "H.248/MEGACO Packages" registry 🌈

  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.

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
📦 where this page comes from