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.
この文書では、より良いパッケージの登録プロセスを記述するために、より正式なレビューとフィードバックのプロセスを提供するために、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.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
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と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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
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 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.
ITU-T研究グループ16とIETF MEGACOワーキンググループは、両方のH.248 / MEGACO標準化に積極的だったし、ほぼすべての登録済みのパッケージを作成する場合、現在のH.248 / MEGACOパッケージの登録プロセスが定義されました。パッケージは、IETF MEGACO作業部会で検討し、作業部会の議長は、H.248パッケージの登録のための要求の審査を担当するIESG任命専門家でした。これは、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の開発は、一般的に（IETF MEGACOメーリングリストのメールの議論にもかかわらず）ITU-T研究グループ16の質問3を介して行われていることです。 ITU-T勧告に定義され、この動きは、[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.
このような状況を考えると、パッケージが公開される前に、H.248 /パッケージの定義とIANA登録規則は、理想的には、パッケージの登録プロセスが完了する前に、正式なレビューのステップを導入するように更新していることが適当です。このプロセスは、唯一の公共のパッケージに適用されます。
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研究グループ質問報告者にレビューのために彼らのパッケージを送信することが奨励されている（ITU-T研究グループ16の質問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パッケージの登録プロセスは、2段階のプロセスです。パッケージが最初に登録されている場合、彼らは「進行（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 with the considerations documented in [H248amm1] and with [RFC3525] (with the exception of Profile Names, which did not appear in the [RFC3525] version).
「エラーコード」、「のServiceChange理由」、および「プロファイル名」の登録手続きは、完全を期すために含まれているとIESG投稿者の明示的な役割をするために。これらの手順は、[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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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:
テキストエンコードPackageIDsは、便宜上、以下繰り返される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トラストの名称、また具体的な貢献者の名前はどちらも、特定の書面による事前の許可なしに、本ソフトウェアから派生した製品を推薦または促進するために使用することができます。
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
このソフトウェアは、著作権所有者によって提供され、貢献者AS IS 'AND明示または黙示の保証、含むがこれらに限定されないが、特定目的に対する適合性の黙示の保証を放棄されています。 NO EVENTの著作権所有者または貢献者は、以下を含むいかなる直接的、間接的、偶発的、特別、懲罰的、または間接的損害（についても責任を負いあってもよいが、代替商品またはサービスの調達、これらに限定されないものとし、使用、データ、または利益の損失; OR事業の中断）が原因で生じたいかなるON
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パッケージの登録手続きを更新すると、追加のセキュリティに影響を与えません。 IP上H.248 / MEGACOプロトコルのセキュリティは、H.248.1部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.
この日付の時点で、パッケージの登録や使用に起因するいかなる記録のセキュリティ上の問題は存在していません。パッケージは、追加の手順とコードポイントを定義することができる一方、これらは、コアH.248.1仕様の枠組み内で行われます。パッケージの仕様によってH.248.1コアプロトコルを更新することはできません。 H.248.1コアプロトコルを使用することは、メディアゲートウェイコントローラ（MGC）と、メディアゲートウェイ（MG）との間で合意されています。 H.248のServiceChange手順はMGCとMG間のH.248制御アソシエーションを確立します。関連付けを確立するために、MGCとMG間の信頼のレベルがなければなりません。この制御（及び信頼）関連のコンテキストでは、パッケージからの要素（特性/信号/イベント/統計）はMGCとMGとの間に搬送されます。 MGCまたはMGは、それが知っている要素に作用します。それはのPackageIDまたはパッケージの要素を理解していない場合は、エラー応答が唯一の制御関連のコンテキストで返されます。
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の両方にソフトウェアをインストールするために管理していますがあります。それは、彼らが望むすべてのものを使用することができたときのPackageIDのためにIANAを依頼するような人のための可能性はほとんどありません。
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.
IANAが登録を行う前に、公共の登録パッケージ、エラーコード、ServiceChangeReasons、およびプロファイル名については、専門家レビューによる審査が必要とされます。プライベートパッケージは、レビューの同じレベルを必要としません。以下のセクションでは、エキスパートレビューのための考慮事項の概要を説明します。
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の開発に関与することをお勧めします。このように、IESGの専門家の識別は執筆時の勧告（ITU-T Q.3 / 16のH.248サブシリーズを担当するITU-T質問/研究会と協議して行うことをお勧めします）。
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の専門家（すなわち、現在IETF MEGACOの電子メールリストにITU-T研究グループ16の3と電子メールでの質問）と協議の審査を完了することができます。パッケージが適切と思われる場合は、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として使用されます。公開パッケージは0x7FFFの範囲には0x0001にシリアル番号を指定する必要があります。プライベートのパッケージは、0xFFFFの範囲には0x8000にシリアル番号を指定する必要があります。シリアル番号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）は、それがアプリケーションの時）（非開示契約（NDAを必要とせずに）IESG任命専門家によるレビューのために利用できるようにする必要があります。
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理由リクエスタはのServiceChange理由を登録するIANAに要求を送信しなければなりません。以下の考慮事項に対処する文書は、（[RFC5226]に従って必要即ち、仕様）を備えなければなりません。 IANAは、レビューのためにIESGが任命し、専門家に要求を転送しなければなりません。
The following considerations shall be met to a register ServiceChange Reason with IANA:
次の考慮事項は、IANAでレジスタのServiceChange理由に満たさなければなりません。
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）理由が使用される条件の完全な説明は、公開文書に含まれなければなりません。説明は、他のすべての既存のServiceChange理由から理由を区別するために十分に明確でなければなりません。
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が任命し、専門家は登録が適切であると判断したら、彼らはのServiceChange理由を登録するには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.
最初の6つの文字が完全に指定されている場合4）自分の名前の末尾にワイルドカード「*」を含むプロファイル名を受け入れなければなりません。プロファイル名で発行された組織は、ワイルドカードに関連付けられた名前空間を管理することが想定されます。 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).
「エラーコード」、「のServiceChange理由」、および「プロファイル名」IANAの考慮事項は、完全性のために含まれています。これらの考慮事項は、[H248amm1] H.248.1に記載考慮して、および（[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、またバイナリIDとして知られています）
2. Text Name (identity used for Text Encoding, see Section 3 for the syntax)
2.テキスト名前（テキストエンコーディングのために使用されるID、構文については、第3節を参照してください）
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パッケージ」のレジストリに以下の情報を登録しなければなりません。
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).
ServiceChange理由登録の要求では、IANA（セクション5.4を参照）レビューのためのIESGが任命し、専門家に受信した情報（すなわち、のServiceChange理由テキストや要求仕様）を送付します。
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パッケージ」のレジストリに以下の情報を登録しなければなりません。
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（セクション5.5を参照）レビューのためにIESGが任命し、専門家に受信した情報を送付します。
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パッケージ」のレジストリに以下の情報を登録しなければなりません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.
"構文仕様のための増大しているBNF：ABNF" [RFC5234]クロッカー、D.、エド、およびP. Overell、。、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]グローブス、C.、エド。、パンタレオ、M.、エド。、アンダーソン、T.、エド。、およびT.テイラー、エド。、 "ゲートウェイコントロールプロトコルバージョン1"、RFC 3525、2003年6月。
[RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", RFC 5125, February 2008.
[RFC5125]テイラー、T.、 "歴史的にRFC 3525の再分類"、RFC 5125、2008年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
メールアドレス：Christian.Groves@nteczone.com
Yangbo Lin Huawei Technologies Co., Ltd. Shenzhen, Guangdong P. R. China
ボー林HU技術の共同のA陽。、（株）Sは、GU Gケース洞P. R.中国真であります
EMail: linyangbo@huawei.com
メールアドレス：linyangbo@huawei.com