[要約] RFC 5615は、H.248/MEGACOプロトコルの登録手順に関する要約です。このRFCの目的は、H.248/MEGACOプロトコルの登録プロセスを明確化し、プロトコルの拡張性と相互運用性を向上させることです。
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/メガコ登録手順
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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研究グループも、すべての分野で詳細な知識を持っていないという事実を認めました。このアプローチは、生成されたパッケージの数と範囲で成功していますが、場合によっては、これらのパッケージは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.
現在のH.248/Megacoパッケージ登録プロセスは、ITU-T研究グループ16とIETF 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開発が通常、ITU-T研究グループ16の質問3を通じて発生していることです（IETF Megacoメーリングリストに関するメールディスカッションにもかかわらず）。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研究グループ質問報告者にレビューのためにパッケージを送信することをお勧めします（研究グループ16のITU-T質問3の質問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段階のプロセスです。パッケージが最初に登録されると、「In Progress（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 Reason」、および「プロファイル名」登録手順は、完全性と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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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:
テキストエンコードされたパッケージIDは、h.248.1 [h248amm1]付録Bでエンコードする「パッケージネーム」に準拠するものとします。
Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2009 IETF TrustおよびCodeの著者として特定された人。全著作権所有。
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 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.
注：パッケージ名の最初の文字として数字は許可されていません。
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または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ではなくMGCに悪意のあるパッケージが実装されている場合、MGがPackageID（および要素）を理解しないため、アクションはありません。MGに悪意のあるパッケージがMGに実装された場合、MGCがMGを使用するように命令しないため、効果はありません。MGCとMGの両方に悪意のあるパッケージが実装されている場合、誰かがMGCとMGの両方にソフトウェアをインストールすることができたという点で、より広い非H.248の問題があります。そのような人が、彼らが望むものを使うことができるときにianaに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が登録を実行する前に、専門家のレビュー担当者によるレビューが必要です。プライベートパッケージは、同じレベルのレビューを必要としません。以下のセクションでは、専門家のレビューに関する考慮事項の概要を説明します。
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/メガコ開発に関与することをお勧めします。そのため、IESGの専門家の特定を、H.248サブシリーズの推奨事項を担当するITU-T質問/研究グループと相談することをお勧めします（執筆時点での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 Memailsリストに電子メールを送信します）。パッケージが適切であるとみなされる場合、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) エラー番号と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 Reason依頼者は、ServiceChangeの理由を登録するためにIANAにリクエストを送信するものとします。以下の考慮事項に対処するドキュメントは、[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) 理由数と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にServiceChangeの理由を登録するようアドバイスします。
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).
「エラーコード」、「ServiceChange Reason」、および「プロファイル名」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、バイナリIDとしても知られています）
2. Text Name (identity used for Text Encoding, see Section 3 for the syntax)
2. テキスト名（テキストエンコーディングに使用されるID、構文についてはセクション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).
ServiceChangeの理由登録の要求に応じて、IANAは受信した情報（つまり、ServiceChangeの理由テキストと必要な仕様）を、レビューのために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. ServiceChange理由番号
2. ServiceChange Reason Text String
2. ServiceChange Reason Text String
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: 1. Profile Name
IESGに任命された専門家から指示された場合、IANAは以下の「H.248/Megacoパッケージ」レジストリに次の情報を登録するものとします。
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の増強」、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] International Telecommunication Union、「Gateway Control Protocol：Version 3」、Amendment 1からITU-T勧告H.248.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。、「Gateway Control Protocolバージョン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
Yangbo Lin Huawei Technologies Co., Ltd. Shenzhen, Guangdong P. R. China
Yangbo Lin Huawei Technologies Co.、Ltd。Shenzhen、Guangdong P. R. China
EMail: linyangbo@huawei.com