Network Working Group C. Groves
Request for Comments: 5615 NTEC Australia
BCP: 151 Y. Lin
Category: Best Current Practice Huawei
August 2009
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
H.248/MEGACO注册程序
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.
本文件更新了H.248/MEGACO IANA软件包注册程序，以便更好地描述软件包注册流程，并提供更正式的审查和反馈流程。
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.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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 ....................................................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
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.
自H.248/MEGACO最初开发以来，许多组织已利用H.248/MEGACO协议包机制，以允许H.248/MEGACO控制某些功能。引入H.248/MEGACO软件包机制的部分目的是让对某一特定功能领域有深入了解的组织能够独立编制关于该功能的软件包。这承认了这样一个事实，即IETF MEGACO工作组和ITU-T研究组16都不具备所有领域的深入知识。虽然这种方法在生产的包装数量和范围上都取得了成功，但在某些情况下，这些包装与H.248/MEGACO原则并不完全一致。发布和注册包后，纠正任何问题都是有问题的。
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.
引入问题/不一致的部分原因是，H.248/MEGACO专家没有对这些包进行全面审查。事实上，IANA H.248/MEGACO注册程序实际上并未规定应进行深入审查。
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
当前的H.248/MEGACO软件包注册过程是在ITU-T研究组16和IETF MEGACO工作组都积极参与H.248/MEGACO标准化并生产几乎所有注册软件包时定义的。在IETF MEGACO工作组中审查了文件包，工作组主席由IESG任命
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.
负责审查H.248包装注册申请的专家。这意味着H.248软件包在注册之前要经过非正式审查。然而，这种情况已经改变。
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].
目前的情况是，IETF MEGACO工作组解散，新的H.248/MEGACO开发通常通过ITU-T研究组16的问题3进行（尽管IETF MEGACO邮件列表上有电子邮件讨论）。[RFC5125]中讨论了向ITU-T定义建议的转变。
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.
鉴于这种情况，应更新H.248/Package定义和IANA注册规则，以便在Package注册过程完成之前，理想情况下，在Package发布之前，引入正式审查步骤。此过程仅适用于公共包。
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).
作为软件包开发过程的一部分，鼓励软件包开发人员将其软件包发送给负责H.248子系列建议的ITU-T研究组问题报告员进行审查（撰写本文时，研究组16的ITU-T问题3）。在IANA注册软件包时，软件包开发人员需要发送一份软件包副本，供IESG指定的专家审查。建议在相关集团最终批准之前对包装进行登记，以征求对其包装质量的反馈意见。在可能的情况下，将与其他H.248/MEGACO专家（例如，在ITU-T Q.3/16和/或MEGACO邮件列表中）一起进行审查。
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".
现有IANA软件包注册过程分为两步。当包首次注册时，它们会收到“正在进行（IP）”的状态。这允许包开发人员在文档完全批准之前请求PackageID。文件批准后，可能会要求将状态更改为“最终”。新程序引入了一个步骤，即在改变身份之前咨询IESG指定的专家。如果包装已审核且可接受，则状态可能更改为“最终”。但是，如果未提供包供审查或有未完成的意见，则状态应保持为“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.
更新文本的目标是定义一个过程，该过程提供对包的及时技术审查，以确保H.248/MEGACO包具有良好的质量，并最大限度地减少重复。
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
“错误代码”、“服务更改原因”和“配置文件名称”注册程序已包括在内，以确保完整性，并明确IESG审核人的角色。这些程序是一致的
with the considerations documented in [H248amm1] and with [RFC3525] (with the exception of Profile Names, which did not appear in the [RFC3525] version).
根据[H248amm1]和[RFC3525]中记录的注意事项（配置文件名称除外，该名称未出现在[RFC3525]版本中）。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The following syntax specification uses the Augmented Backus-Naur Form (BNF) as described in [RFC5234].
以下语法规范使用[RFC5234]中所述的增广巴科斯诺尔形式（BNF）。
Text-encoded PackageIDs shall conform to the "PackageName" encoding in H.248.1 [H248amm1] Annex B, which is repeated below for convenience:
文本编码的PackageID应符合H.248.1[H248amm1]附录B中的“PackageName”编码，为方便起见，该编码重复如下：
Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.
版权所有（c）2009 IETF信托基金和被确定为代码作者的人员。版权所有。
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.
- 未经事先书面许可，不得使用互联网协会、IETF或IETF Trust的名称或特定贡献者的名称来认可或推广源自本软件的产品。
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.
责任理论，无论是合同、严格责任还是因使用本软件而产生的侵权行为（包括疏忽或其他），即使已告知可能发生此类损害。
PackageName = NAME
PackageName = NAME
NAME = ALPHA *63(ALPHA / DIGIT / "_")
NAME = ALPHA *63(ALPHA / DIGIT / "_")
Note: A digit is not allowed as the first character of a Package name.
注意：不允许将数字作为包名称的第一个字符。
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].
更新IANA H.248/MEGACO软件包注册程序没有额外的安全问题。H.248.1第10节[H248amm1]讨论了H.248/MEGACO协议IP传输的安全性。
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.
截至该日期，未记录因软件包的注册或使用而产生的安全问题。虽然软件包可以定义额外的程序和代码点，但这些都是在核心H.248.1规范的框架内完成的。不可能通过包规范更新H.248.1核心协议。媒体网关控制器（MGC）和媒体网关（MG）之间同意使用H.248.1核心协议。H.248服务变更程序在MGC和MG之间建立了H.248控制关联。要建立关联，MGC和MG之间必须有一定程度的信任。在这种控制（和信任）关联的上下文中，来自包的元素（属性/信号/事件/统计信息）在MGC和MG之间传输。MGC或MG仅对其知道的元素起作用。如果它不理解PackageID或Package元素，则仅在控件关联的上下文中返回错误响应。
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.
如果在MGC或MG中实现恶意包规范，则不太可能导致问题。由于H.248是一个主从协议，如果恶意软件包是在MGC中实现的，而不是在MG中实现的，则不会有任何操作，因为MG不会理解PackageID（和元素）。如果恶意软件包是在MG上实现的，则不会产生任何效果，因为MGC永远不会命令MG使用它。如果恶意软件包同时在MGC和MG中实施，则存在一个更广泛的非H.248问题，即有人成功地在MGC和MG上安装了软件。当这样的人可以使用任何他们想要的软件包时，他们向IANA索要软件包ID的可能性很小。
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.
因此，在这方面，IANA H.248/MEGACO软件包注册程序的更新被认为没有额外的安全影响。
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.
请求者和专家审阅者应确保包不会引入任何额外的安全问题。特定标准开发组织的公共包请求者必须获得该组织的授权才能请求包注册。
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.
对于公开注册的软件包、错误代码、ServiceChangeReasons和配置文件名称，IANA执行注册之前需要由专家审查员进行审查。私有包不需要相同级别的审查。以下各节概述了专家审查的考虑事项。
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).
IESG仍应负责分配H.248/MEGACO专家。建议此人参与正在进行的H.248/MEGACO开发。因此，建议与负责H.248子系列建议的ITU-T问题/研究小组协商确定IESG专家（编写本报告时为ITU-T Q.3/16）。
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.
鼓励包请求者根据H.248.1第12节[H248amm1]“包定义”审查其工作，并鼓励使用H.248.1附录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.
根据[RFC5226]，注册公共包的过程被视为“需要规范”。因此，一旦进行初始检查，开发中的公共包的包请求者应将包文本发送给IANA。还鼓励他们将该文件包发送给负责H.248子系列建议（编写本报告时为ITU-T Q.3/16）的ITU-T问题/研究小组进行审查。更新的联系信息可在最新版本的H.248子系列实施者指南中找到。这应在定义初稿完成后，至少在包批准之前尽快进行，以确保包符合H.248方法和包设计原则。
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.
鼓励包请求者在设计过程中尽早申请注册，以保留二进制ID。二进制ID应在定义包的文件中公布。
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.
IANA收到包裹注册的初始或最终请求后，将转发给IESG指定的专家进行审查。在审查期间，输入包和详细信息将与包模板进行比较，以确保完整性，并与协议语法和程序进行比较。它将与现有的工作进行比较，以确保它不会重复现有的功能。将对其进行审查，以确保解决任何潜在的安全问题。然后，专家评审员将致力于解决与包请求者之间的任何问题。IESG指定的专家可与其他H.248专家协商完成审查（即目前ITU-T研究组16的问题3，并通过电子邮件发送至IETF MEGACO电子邮件列表）。如果认为该包合适，IESG指定的专家应发布一份声明，表明批准，并抄送IANA。
The IESG Expert Reviewer will ensure the following considerations are met to register a Package with the IANA:
IESG专家评审员将确保在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.
1) 为每个包注册唯一的字符串名称、唯一的序列号和版本号。字符串名称用作文本编码的PackageID。序列号用作二进制编码的PackageID。公共软件包的序列号必须在0x0001到0x7fff之间。私人软件包的序列号必须在0x8000到0xffff之间。保留序列号0。唯一字符串名称和唯一序列号可以由包请求者请求，如果未请求，则由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.
2) 包裹请求者应提供联系人姓名以及该联系人的电子邮件和邮政地址。必要时，定义组织应更新联系信息。
3) The public Package requester shall provide a reference to a document that describes the Package, which should be public:
3) 公共包请求者应提供对描述包的文件的参考，该文件应为公共文件：
a) The document shall specify the version of the Package that it describes.
a) 文件应规定其所描述的文件包版本。
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.
b) 如果文档是公共的，它应该位于公共web服务器上，并且应该有一个稳定的URL。网站应提供提供评论的机制，并应返回适当的回复。
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.
c) 如果文件未公开，则必须在申请时提供给IESG指定的专家审查（无需保密协议（NDA））。
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.
注：该文件不必在注册申请时公开提供；但是，应提供该文件，供IESG指定的专家审查。一旦获得标准机构的批准，该包应公开，但该包可能不公开。
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.
4) 由非公认标准机构注册的包装应至少具有8个字符的包装名称长度。
5) Package names are allocated on a first-come, first-served basis if all other conditions are met.
5) 如果满足所有其他条件，则按照先到先得的原则分配包名。
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".
状态-“进行中”表示该程序包未经全面审查和批准，因此可能包含错误或不符合H.248原则。“最终”表示该包已经过审查和批准，并且是稳定的。新包装的注册状态应为“IP”。一旦文件包最终确定（即，根据文件包申请人组织的程序批准），他们应联系IANA，以便将状态更新为“最终”。
Once the IESG-appointed expert has determined that the registration is appropriate, they will advise the IANA to register the Package.
一旦IESG指定的专家确定注册是适当的，他们将建议IANA注册该软件包。
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.
IANA将按照注册的连续顺序为符合注册条件的每个包分配一个序列号（现有包的更新除外，该更新保留其正在更新的包的序列号）。
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.
错误代码请求者应向IANA发送注册错误代码的请求。应提供说明以下注意事项的文件（即[RFC5226]要求的规范）。IANA随后应将请求转发给IESG指定的专家进行审查。
The following considerations shall be met to register an Error Code with IANA:
在IANA注册错误代码时，应满足以下注意事项：
1) An error number and a one-line (80-character maximum) string are registered for each error.
1) 为每个错误注册一个错误号和一行（最多80个字符）字符串。
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.
2) 应在公开文件中完整描述检测到错误的条件。描述应足够清晰，以区分错误与所有其他现有错误代码。
3) The document should be available on a public web server and should have a stable URL.
3) 文档应该在公共web服务器上可用，并且应该有一个稳定的URL。
4) Error numbers registered by recognized standards bodies shall have 3- or 4-character error numbers.
4) 由公认标准机构登记的错误号应具有3个或4个字符的错误号。
5) Error numbers registered by all other organizations or individuals shall have 4-character error numbers.
5) 所有其他组织或个人登记的错误号应具有4个字符的错误号。
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.
6) 只有最初定义错误号的组织或个人（或其继任者或受让人）才能修改错误号定义。如果修改导致错误代码编号、错误代码名称或错误字符串发生变化，则错误代码修改人应向IANA发送注册更新的请求。该请求应视为新的错误代码请求，这将涉及专家审查。
Once the IESG-appointed expert has determined that the registration is appropriate, they will advise the IANA to register the Error Code.
一旦IESG指定的专家确定注册是适当的，他们将建议IANA注册错误代码。
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.
ServiceChange原因请求者应向IANA发送请求，以注册ServiceChange原因。应提供说明以下注意事项的文件（即[RFC5226]要求的规范）。IANA随后应将请求转发给IESG指定的专家进行审查。
The following considerations shall be met to a register ServiceChange Reason with IANA:
在IANA注册服务变更原因时，应满足以下考虑：
1) A reason number and a one-phrase (80-character maximum) unique string are registered for each reason.
1) 为每个原因注册一个原因编号和一个短语（最多80个字符）唯一字符串。
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.
2) 使用原因的条件的完整说明应包含在公开文件中。说明应足够清晰，以区分原因与所有其他现有服务变更原因。
3) The document should be available on a public web server and should have a stable URL.
3) 文档应该在公共web服务器上可用，并且应该有一个稳定的URL。
Once the IESG-appointed expert has determined that the registration is appropriate, they will advise IANA to register the ServiceChange Reason.
一旦IESG指定的专家确定注册是适当的，他们将建议IANA注册服务变更原因。
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.
配置文件名称请求者应向IANA发送注册配置文件名称的请求。应提供说明以下注意事项的文件。IANA随后应将请求转发给IESG指定的专家进行审查。
The following considerations shall be met to register a profile with IANA:
在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.
1) 为每个配置文件注册一个唯一的字符串名称和版本号（当配置文件名称包含通配符时，可以省略版本）。
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.
2) 应指定联系人姓名以及该联系人的电子邮件和邮政地址。必要时，定义组织应更新联系信息。
3) Profiles registered by other than recognized standards bodies shall have a minimum Profile Name length of 6 characters.
3) 由非公认标准机构注册的配置文件应至少具有6个字符的配置文件名称长度。
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.
4) 如果完全指定了前6个字符，则应接受名称末尾包含通配符“*”的配置文件名称。假定使用概要文件名称发布的组织将管理与通配符关联的命名空间。IANA不得发布“名称*”范围内的其他配置文件名称。
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.
一旦IESG指定的专家确定注册合适，他们将建议IANA注册档案名称。
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.
本文档描述了更新的包注册程序。[RFC5226]在进行更新时已被考虑。本文档不会更改H.248/MEGACO软件包注册表中的表格软件包、错误代码和ServiceChange原因信息。
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).
为完整起见，已包括“错误代码”、“服务更改原因”和“配置文件名称”IANA注意事项。这些注意事项与H.248.1[H248amm1]和[RFC3525]中记录的注意事项一致（除了[RFC3525]版本中未出现的配置文件名称）。
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).
在申请初始或最终包注册时，IANA应将收到的信息（即包文本（根据[RFC5226]要求的规范））转发给IESG指定的专家审查（见第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:
审查后，在IESG指定专家的指示下，IANA应在“H.248/MEGACO软件包”注册表中注册以下信息，如下所述：
1. Serial Number (identity used for Binary Encoding, also known as Binary ID)
1. 序列号（用于二进制编码的标识，也称为二进制ID）
2. Text Name (identity used for Text Encoding, see Section 3 for the syntax)
2. 文本名称（用于文本编码的标识，语法见第3节）
3. Package version
3. 软件包版本
4. Extension information - Binary ID and Package version
4. 扩展信息-二进制ID和包版本
5. Status* - IP ("In Progress") or Final
5. 状态*-IP（“进行中”）或最终
6. Package name, Reference, and Contact information
6. 包名称、引用和联系信息
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.
IANA将保持公共和私人包裹列表的货币和公共可用性。包裹将按序列号的递增顺序列出。将输入最新的软件包版本，以替换注册表中以前的版本。
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).
在请求错误代码注册时，IANA应将收到的信息（即错误代码文本和要求的规范）转发给IESG指定的专家进行审查（见第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:
当IESG指定专家指示时，IANA应在“H.248/MEGACO软件包”注册表中注册以下信息，如下所述：
1. Error Code Number
1. 错误代码
2. Error Code Text String
2. 错误代码文本字符串
3. Reference
3. 参考
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).
在请求服务变更原因登记时，IANA应将收到的信息（即服务变更原因文本和所需规范）转发给IESG指定的专家进行审查（见第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:
当IESG指定专家指示时，IANA应在“H.248/MEGACO软件包”注册表中注册以下信息，如下所述：
1. ServiceChange Reason Number
1. 服务更改原因编号
2. ServiceChange Reason Text String
2. ServiceChange原因文本字符串
3. Reference
3. 参考
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).
在申请档案名称注册时，IANA应将收到的信息转发给IESG指定的专家进行审查（见第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:
当IESG指定专家指示时，IANA应在“H.248/MEGACO软件包”注册表中注册以下信息，如下所述：
1. Profile Name
1. 配置文件名
2. Version
2. 版本
3. Reference/Contact
3. 参考/联系
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[H248amm1] International Telecommunication Union, "Gateway control protocol: Version 3", Amendment 1 to ITU-T Recommendation H.248.1, April 2008.
[H248amm1]国际电信联盟，“网关控制协议：第3版”，ITU-T建议H.248.1修正案1，2008年4月。
[RFC3525] Groves, C., Ed., Pantaleo, M., Ed., Anderson, T., Ed., and T. Taylor, Ed., "Gateway Control Protocol Version 1", RFC 3525, June 2003.
[RFC3525]Groves，C.，Ed.，Pantaleo，M.，Ed.，Anderson，T.，Ed.，和T.Taylor，Ed.，“网关控制协议版本1”，RFC 35252003年6月。
[RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", RFC 5125, February 2008.
[RFC5125]Taylor，T.，“将RFC 3525重新分类为历史”，RFC 51252008年2月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
Authors' Addresses
作者地址
Christian Groves NTEC Australia Newport, Victoria Australia
澳大利亚维多利亚州新港克里斯蒂安格罗夫斯NTEC酒店
EMail: Christian.Groves@nteczone.com
EMail: Christian.Groves@nteczone.com
Yangbo Lin Huawei Technologies Co., Ltd. Shenzhen, Guangdong P. R. China
杨伯林华为技术有限公司中国广东深圳
EMail: linyangbo@huawei.com
EMail: linyangbo@huawei.com