[要約] RFC 8396は、電話番号の管理、注文、配布、公開、登録に関する問題の説明、ユースケース、フレームワークを提供しています。このRFCの目的は、効果的な電話番号の管理と利用を促進することです。
Internet Engineering Task Force (IETF) J. Peterson
Request for Comments: 8396 NeuStar, Inc.
Category: Informational T. McGarry
ISSN: 2070-1721 July 2018
Managing, Ordering, Distributing, Exposing, and Registering Telephone Numbers (MODERN): Problem Statement, Use Cases, and Framework
電話番号の管理、注文、配布、公開、および登録（現代）：問題の説明、使用例、およびフレームワーク
Abstract
概要
The functions of the Public Switched Telephone Network (PSTN) are rapidly migrating to the Internet. This is generating new requirements for many traditional elements of the PSTN, including Telephone Numbers (TNs). TNs no longer serve simply as telephone routing addresses: they are now identifiers that may be used by Internet-based services for a variety of purposes including session establishment, identity verification, and service enablement. This problem statement examines how the existing tools for allocating and managing telephone numbers do not align with the use cases of the Internet environment and proposes a framework for Internet-based services relying on TNs.
公衆交換電話網（PSTN）の機能は、急速にインターネットに移行しています。これにより、電話番号（TN）を含むPSTNの多くの従来の要素に対する新しい要件が生成されます。 TNは、単に電話ルーティングアドレスとして機能しなくなりました。これらは現在、セッションの確立、IDの検証、サービスの有効化など、さまざまな目的でインターネットベースのサービスで使用できる識別子になっています。この問題の説明では、電話番号の割り当てと管理のための既存のツールがインターネット環境のユースケースとどのように一致しないかを調べ、TNに依存するインターネットベースのサービスのフレームワークを提案します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8396.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8396で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Actors . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Data Types . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Data Management Architectures . . . . . . . . . . . . . . 8
3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Acquisition . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. Acquiring TNs from Registrar . . . . . . . . . . . . 12
4.1.2. Acquiring TNs from CSPs . . . . . . . . . . . . . . . 13
4.2. Management . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Management of Administrative Data . . . . . . . . . . 14
4.2.1.1. Managing Data at a Registrar . . . . . . . . . . 14
4.2.1.2. Managing Data at a CSP . . . . . . . . . . . . . 15
4.2.2. Management of Service Data . . . . . . . . . . . . . 15
4.2.2.1. CSP to Other CSPs . . . . . . . . . . . . . . . . 16
4.2.2.2. User to CSP . . . . . . . . . . . . . . . . . . . 16
4.2.3. Managing Change . . . . . . . . . . . . . . . . . . . 16
4.2.3.1. Changing the CSP for an Existing Service . . . . 16
4.2.3.2. Terminating a Service . . . . . . . . . . . . . . 17
4.3. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.1. Retrieval of Public Data . . . . . . . . . . . . . . 18
4.3.2. Retrieval of Semi-restricted Administrative Data . . 18
4.3.3. Retrieval of Semi-restricted Service Data . . . . . . 19
4.3.4. Retrieval of Restricted Data . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. Informative References . . . . . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
The challenges of utilizing Telephone Numbers (TNs) on the Internet have been known for some time. Internet telephony provided the first use case for routing telephone numbers on the Internet in a manner similar to how calls are routed in the Public Switched Telephone Network (PSTN). As the Internet had no service for discovering the endpoints associated with telephone numbers, ENUM [RFC6116] created a DNS-based mechanism for translating TNs into URIs, as used by protocols such as SIP [RFC3261]. The resulting database was designed to function in a manner similar to the systems that route calls in the PSTN. Originally, it was envisioned that ENUM would be deployed as a global hierarchical service; however, in practice, it has only been deployed piecemeal by various parties. Most notably, ENUM is used as an internal network function and is rarely used between service provider networks. The original ENUM concept of a single root, e164.arpa, proved to be politically and practically challenging, and less centralized models have thus flourished. Subsequently, the Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS) framework [RFC6461] showed ways that service providers might provision information about TNs at an ENUM service or similar Internet-based directory. These technologies have also generally tried to preserve the features and architecture familiar to the PSTN numbering environment.
インターネットで電話番号（TN）を利用する際の課題は、以前から知られています。インターネットテレフォニーは、公衆交換電話網（PSTN）で通話をルーティングする方法と同様の方法で、インターネット上で電話番号をルーティングする最初の使用例を提供しました。インターネットには電話番号に関連付けられたエンドポイントを検出するサービスがないため、ENUM [RFC6116]は、SIP [RFC3261]などのプロトコルで使用されるように、TNをURIに変換するDNSベースのメカニズムを作成しました。結果のデータベースは、PSTNで通話をルーティングするシステムと同様の方法で機能するように設計されました。もともと、ENUMはグローバル階層サービスとして展開されることが想定されていました。ただし、実際には、さまざまな関係者によって段階的に導入されています。特に、ENUMは内部ネットワーク機能として使用され、サービスプロバイダーネットワーク間ではほとんど使用されません。単一のルートe164.arpaの元のENUMコンセプトは、政治的にも実際的にも困難であることが証明されたため、集中化されていないモデルが栄えてきました。その後、Inter- / Intra-NetworK SIP（DRINKS）フレームワークの到達可能性に関するデータ[RFC6461]は、サービスプロバイダーがENUMサービスまたは同様のインターネットベースのディレクトリでTNに関する情報をプロビジョニングする方法を示しました。これらのテクノロジーは、一般に、PSTN番号付け環境に馴染みのある機能とアーキテクチャを維持することも試みています。
Over time, Internet telephony has encompassed functions that differ substantially from traditional PSTN routing and management, especially as non-traditional providers have begun to utilize numbering resources. An increasing number of enterprises, over-the-top Voice over IP (VoIP) providers, text messaging services, and related non-carrier services have become heavy users of telephone numbers. An enterprise, for example, can deploy an IP Private Branch Exchange (PBX) that receives a block of telephone numbers from a carrier and then, in turn, distributes those numbers to new IP telephones when they associate with the PBX. Internet services offer users portals where they can allocate new telephone numbers on the fly, assign multiple "alias" telephone numbers to a single line service, implement various mobility or find-me-follow-me applications, and so on. Peer-to-peer telephone networks have encouraged experiments with distributed databases for telephone number routing and even allocation.
時間の経過とともに、インターネットテレフォニーは、特に非従来型のプロバイダーが番号付けリソースを利用し始めたため、従来のPSTNルーティングおよび管理とは大幅に異なる機能を包含してきました。ますます多くの企業、オーバーザトップのVoice over IP（VoIP）プロバイダー、テキストメッセージングサービス、および関連する非キャリアサービスが電話番号のヘビーユーザーになっています。たとえば、企業はIP構内交換機（PBX）を展開して、キャリアから電話番号のブロックを受信し、それらがPBXに関連付けられたときに、それらの番号を新しいIP電話に配布することができます。インターネットサービスは、新しい電話番号をその場で割り当てたり、複数の「エイリアス」電話番号を単一の回線サービスに割り当てたり、さまざまなモビリティアプリケーションやfind-me-follow-meアプリケーションを実装したりできるユーザーポータルを提供します。ピアツーピア電話ネットワークは、電話番号のルーティングや割り当てさえも行う分散データベースの実験を奨励しています。
This dynamic control over telephone numbers has few precedents in the traditional PSTN outside of number portability. Number portability allows the capability of a user to choose and change their service provider while retaining their TN; it has been implemented in many countries either for all telephony services or for subsets (e.g., mobile). However, TN administration processes rooted in PSTN technology and policies made number porting fraught with problems and delays. Originally, processes were built to associate a specific TN to a specific service provider and never change it. With number portability, the industry had to build new infrastructure and new administrative functions and processes to change the association of the TN from one service provider to another. Thanks to the increasing sophistication of consumer mobile devices as Internet endpoints as well as telephones, users now associate TNs with many Internet applications other than telephony. This has generated new interest in models similar to those in place for administering freephone (non-geographic, toll-free numbers) services in the United States, where a user purchases a number through a sort of number registrar and controls its administration (such as routing) on their own, typically using Internet services to directly make changes to the service associated with telephone numbers.
電話番号に対するこの動的な制御は、番号の移植性以外の従来のPSTNでの前例がほとんどありません。番号の移植性により、ユーザーはTNを維持しながらサービスプロバイダーを選択および変更できます。多くの国で、すべてのテレフォニーサービスまたはサブセット（モバイルなど）に対して実装されています。ただし、PSTNテクノロジに根ざしたTN管理プロセスとポリシーにより、番号の移植は問題と遅延でいっぱいになりました。もともと、プロセスは、特定のTNを特定のサービスプロバイダーに関連付け、決して変更しないように構築されていました。番号の移植性により、業界はTNの関連付けをサービスプロバイダー間で変更するために、新しいインフラストラクチャと新しい管理機能およびプロセスを構築する必要がありました。インターネットエンドポイントや電話としての消費者向けモバイルデバイスの高度化により、ユーザーは現在、テレフォニー以外の多くのインターネットアプリケーションにTNを関連付けています。これは、ユーザーが一種の番号登録機関を通じて番号を購入し、その管理を制御する米国のフリー電話（非地理的、フリーダイヤル番号）サービスの管理と同様のモデルに新たな関心を生み出しましたルーティング）それ自体で、通常はインターネットサービスを使用して、電話番号に関連付けられたサービスに直接変更を加えます。
Most TNs today are assigned to specific geographies, at both an international level and within national numbering plans. Numbering practices today are tightly coupled with the manner that service providers interconnect as well as with how TNs are routed and administered: the PSTN was carefully designed to delegate switching intelligence geographically. In interexchange carrier routing in North America, for example, calls to a particular TN are often handed off to the terminating service provider close to the geography where that TN is assigned. But the overwhelming success of mobile telephones has increasingly eroded the connection between numbers and regions. Furthermore, the topology of IP networks is not anchored to geography in the same way that the telephone network is. In an Internet environment, establishing a network architecture for routing TNs could depend little on geography, relying instead on network topologies or other architectural features. Adapting TNs to the Internet requires more security, richer datasets, and more complex query and response capabilities than previous efforts have provided.
今日のほとんどのTNは、国際レベルと国内の番号計画内の両方で、特定の地域に割り当てられています。今日の番号付けの実践は、サービスプロバイダーが相互に接続する方法や、TNがルーティングおよび管理される方法と密接に結び付いています。PSTNは、スイッチングインテリジェンスを地理的に委任するように慎重に設計されました。たとえば、北米のインターチェンジキャリアルーティングでは、特定のTNへのコールは、そのTNが割り当てられている地域に近い終端サービスプロバイダーにハンドオフされることがよくあります。しかし、携帯電話の圧倒的な成功は、数と地域の間のつながりをますます侵食してきました。さらに、IPネットワークのトポロジは、電話ネットワークのように地理に固定されていません。インターネット環境では、TNをルーティングするためのネットワークアーキテクチャの確立は、地理にほとんど依存せず、代わりにネットワークトポロジやその他のアーキテクチャ機能に依存します。 TNをインターネットに適合させるには、これまでの取り組みよりも多くのセキュリティ、より豊富なデータセット、およびより複雑なクエリと応答機能が必要です。
This document attempts to create a common understanding of the problem statement related to allocating, managing, and resolving TNs in an IP environment, which is the focus of the IETF Managing, Ordering, Distributing, Exposing, and Registering telephone Numbers (MODERN) Working Group. It outlines a framework and lists motivating use cases for creating IP-based mechanisms for TNs. It is important to acknowledge at the outset that there are various evolving international and national policies and processes related to TNs, and any solutions need to be flexible enough to account for variations in policy and requirements.
このドキュメントは、IP環境でのTNの割り当て、管理、および解決に関連する問題ステートメントについて、IETFによる電話番号の管理、注文、配布、公開、および登録（MODERN）ワーキンググループの焦点である一般的な理解を深めることを目的としています。 。それはフレームワークの概要を説明し、TNのIPベースのメカニズムを作成するための動機付けのユースケースをリストします。最初に、TNに関連してさまざまな国際的および国内的なポリシーとプロセスがあり、どのソリューションもポリシーと要件の変動に対応できる十分な柔軟性を備えている必要があることを認識することが重要です。
This section provides definitions for actors, data types, and data management architectures as they are discussed in this document. Different numbering spaces may instantiate these roles and concepts differently: practices that apply to non-geographic freephone numbers, for example, may not apply to geographic numbers, and practices that exist under one Numbering Authority may not be permitted under another. The purpose of this framework is to identify the characteristics of protocol tools that will satisfy the diverse requirements for telephone number acquisition, management, and retrieval on the Internet.
このセクションでは、アクター、データ型、およびデータ管理アーキテクチャの定義について説明します。ナンバリングスペースが異なると、これらの役割と概念のインスタンス化が異なる場合があります。たとえば、非地理的なフリーダイヤル番号に適用されるプラクティスは、地理的な番号には適用されない場合があり、1つのナンバリング機関の下に存在するプラクティスは、別の場合には許可されない場合があります。このフレームワークの目的は、電話番号の取得、管理、およびインターネット上での検索に関するさまざまな要件を満たすプロトコルツールの特性を識別することです。
The following roles of actors are defined in this document.
このドキュメントでは、俳優の次の役割が定義されています。
Numbering Authority: A regulatory body within a region that manages that region's TNs. The Numbering Authority decides national numbering policy for the nation, region, or other domain for which it has authority, including what TNs can be allocated, which are reserved, and which entities may obtain TNs.
採番機関：地域内のTNを管理する地域内の規制機関。 Numbering Authorityは、割り当て可能なTN、予約済みのTN、およびTNを取得できるエンティティなど、権限を持つ国、地域、またはその他のドメインの国内番号ポリシーを決定します。
Registry: An entity that administers the allocation of TNs based on a Numbering Authority's policies. Numbering Authorities can act as the Registries themselves, or they can outsource the function to other entities. Traditional registries are single entities with sole authority and responsibility for specific numbering resources, though distributed registries (see Section 2.3) are also in the scope of this framework.
レジストリ：採番機関のポリシーに基づいてTNの割り当てを管理するエンティティ。採番機関はレジストリ自体として機能することも、他のエンティティに機能を外部委託することもできます。従来のレジストリーは、特定の番号付けリソースに対する唯一の権限と責任を持つ単一のエンティティーですが、分散レジストリー（セクション2.3を参照）もこのフレームワークの範囲内です。
Credential Authority: An entity that distributes credentials, such as certificates that attest the authority of assignees (defined below) and delegates. This document assumes that one or more Credential Authorities may be trusted by actors in any given regulatory environment; policies for establishing such trust anchors are outside the scope of this document.
Credential Authority：譲受人（以下に定義）と委任者の権限を証明する証明書など、資格情報を配布するエンティティ。このドキュメントでは、1つまたは複数の資格証明機関が、所定の規制環境のアクターによって信頼されている可能性があることを前提としています。このようなトラストアンカーを確立するためのポリシーは、このドキュメントの範囲外です。
Registrar: An entity that distributes the telephone numbers administered by a Registry; typically, there are many Registrars that can distribute numbers from a single Registry, though Registrars may serve multiple Registries as well. A Registrar has business relationships with number assignees and collects administrative information from them.
レジストラ：レジストリによって管理される電話番号を配布するエンティティ。通常、1つのレジストリから番号を配布できるレジストラは多数ありますが、レジストラは複数のレジストリにも対応する場合があります。レジストラは、番号割り当て先とのビジネス関係を持ち、それらから管理情報を収集します。
Communication Service Provider (CSP): A provider of communication service where those services can be identified by TNs. This includes both traditional telephone carriers or enterprises as well as service providers with no presence on the PSTN who use TNs. This framework does not assume that any single CSP provides all the communication service related to a particular TN.
通信サービスプロバイダー（CSP）：TNによってそれらのサービスを識別できる通信サービスのプロバイダー。これには、従来の電話キャリアまたは企業、およびTNを使用するPSTNに存在しないサービスプロバイダーの両方が含まれます。このフレームワークは、単一のCSPが特定のTNに関連するすべての通信サービスを提供するとは想定していません。
Service Enabler: An entity that works with CSPs to enable communication service to a User: perhaps a vendor, a service bureau, or a third-party integrator.
Service Enabler：CSPと連携してユーザーへの通信サービスを有効にするエンティティ：おそらくベンダー、サービスビューロー、またはサードパーティのインテグレーター。
User: An individual reachable through a communication service: usually a customer of a Communication Service Provider.
ユーザー：通信サービスを通じて到達可能な個人：通常は通信サービスプロバイダーの顧客。
Government Entity: An entity that, due to legal powers deriving from national policy, has privileged access to information about number administration under certain conditions.
政府機関：国の政策に由来する法的権限のために、特定の条件下での数の管理に関する情報への特権的なアクセス権を持つエンティティ。
Note that an individual, organization, or other entity may act in one or more of the roles above; for example, a company may be a CSP and also a Registrar. Although Numbering Authorities are listed as actors, they are unlikely to actually participate in the protocol flows themselves; however, in some situations, a Numbering Authority and Registry may be the same administrative entity.
個人、組織、またはその他のエンティティが上記の1つ以上の役割を果たしている可能性があることに注意してください。たとえば、企業はCSPであり、レジストラでもあります。番号付け機関はアクターとしてリストされていますが、プロトコルフロー自体に実際に参加することはほとんどありません。ただし、状況によっては、番号付け機関とレジストリが同じ管理エンティティである場合があります。
All actors that are recipients of numbering resources, be they a CSP, Service Enabler, or User, can also be said to have a relationship to a Registry of either an assignee or delegate.
ナンバリングリソースの受信者であるすべてのアクターは、それらがCSP、Service Enabler、またはUserであっても、譲受人またはデリゲートのいずれかのレジストリと関係があると言うこともできます。
Assignee: An actor that is assigned a TN directly by a Registrar; an assignee always has a direct relationship with a Registrar.
担当者：レジストラによって直接TNが割り当てられているアクター。譲受人は常にレジストラと直接的な関係を持っています。
Delegate: An actor that is delegated a TN from an assignee or another delegate who does not necessarily have a direct relationship with a Registrar. Delegates may delegate one or more of their TN assignment(s) to one or more subdelegates from further downstream.
代理人：担当者または必ずしもレジストラと直接の関係を持たない別の代理人からTNを委任されたアクター。デリゲートは、さらに下流から1つ以上のTN割り当てを1つ以上のサブデリゲートに委任できます。
As an example, consider a case where a Numbering Authority also acts as a Registry, and it issues blocks of 10,000 TNs to CSPs that, in this case, also act as Registrars. CSP/Registrars would then be responsible for distributing numbering resources to Users and other CSPs. In this case, an enterprise deploying IP PBXs also acts as a CSP, and it acquires number blocks for its enterprise seats in chunks of 100 from a CSP acting as a Registrar with whom the enterprise has a business relationship. The enterprise is, in this case, the assignee, as it receives numbering resources directly from a Registrar. As it doles out individual numbers to its Users, the enterprise delegates its own numbering resources to those Users and their communication endpoints. The overall ecosystem might look as follows.
例として、採番機関がレジストリとしても機能し、CSPに対して10,000 TNのブロックを発行する場合を考えます。この場合、レジストラとしても機能します。 CSP /レジストラは、ユーザーと他のCSPに番号付けリソースを配布する責任があります。この場合、IP PBXを展開している企業はCSPとしても機能し、企業とビジネス関係を持つレジストラとして機能するCSPから、エンタープライズシートの番号ブロックを100のチャンクで取得します。企業は、レジストラから直接番号付けリソースを受け取るため、この場合は譲受人です。個々の番号をユーザーに委託する際、企業は独自の番号付けリソースをそれらのユーザーとその通信エンドポイントに委任します。全体的なエコシステムは次のようになります。
+---------+
|Numbering|
|Authority|Registry
+----+----+
|
V 10,000 TNs
+---------+
| CSP |Registrar
+----+----+
|
V 100 TNs
+---------+
| PBX |Assignee
+---------+
|
V 1 TN
+---------+
| User |Delegate
+---------+
Figure 1: Chain of Number Assignment
図1：番号割り当てのチェーン
The following data types are defined in this document.
このドキュメントでは、次のデータ型が定義されています。
Administrative Data: Assignment data related to the TN and the relevant actors; it includes TN status (assigned, unassigned, etc.), contact data for the assignee or delegate, and typically does not require real-time access as this data is not required for ordinary call or session establishment.
管理データ：TNおよび関連するアクターに関連する割り当てデータ。これには、TNステータス（割り当て済み、未割り当てなど）、譲受人または代理人の連絡先データが含まれます。通常、このデータは通常の通話やセッションの確立には必要ないため、リアルタイムアクセスは必要ありません。
Service Data: Data necessary to enable service for the TN; it includes addressing data and service features. Since this data is necessary to complete calls, it must be obtained in real time.
サービスデータ：TNのサービスを有効にするために必要なデータ。これには、アドレス指定データとサービス機能が含まれます。このデータは通話を完了するために必要なので、リアルタイムで取得する必要があります。
Administrative and service data can fit into three access categories:
管理データとサービスデータは、次の3つのアクセスカテゴリに分類できます。
Public: Anyone can access public data. Such data might include a list of which numbering resources (unallocated number ranges) are available for acquisition from the Registry.
パブリック：誰でもパブリックデータにアクセスできます。このようなデータには、レジストリから取得できる番号付けリソース（未割り当ての番号範囲）のリストが含まれる場合があります。
Semi-restricted: Only a subset of actors can access semi-restricted data. For example, CSPs may be able to access other CSP's service data in some closed environment.
準制限：アクターのサブセットのみが準制限データにアクセスできます。たとえば、CSPは、一部の閉じた環境で他のCSPのサービスデータにアクセスできる場合があります。
Restricted: Only a small subset of actors can access restricted data. For example, a Government Entity may be able access contact information for a User.
制限付き：アクターのごく一部のみが制限付きデータにアクセスできます。たとえば、政府機関はユーザーの連絡先情報にアクセスできる場合があります。
While it might appear there are really only two categories, public and restricted (based on the requestor), the distinction between semi-restricted and restricted is helpful for the use cases below.
実際には、パブリックと制限（要求者に基づく）の2つのカテゴリしかないように見えるかもしれませんが、準制限と制限の区別は、以下の使用例に役立ちます。
This framework generally assumes that administrative and service data is maintained by CSPs, Registrars, and Registries. The terms "registrar" and "registry" are familiar from DNS operations, and indeed the DNS provides an obvious inspiration for the relationships between those entities described here. Protocols for transferring names between registries and registrars have been standardized in the DNS space for some time (see [RFC3375]). Similarly, the division between service data acquired by resolving names with the DNS protocol versus administrative data about names acquired through WHOIS [RFC3912] is directly analogous to the distinction between service and administrative data described in Section 2.2. The major difference between the data management architecture of the DNS and this framework is that the distinction between the CSP and User, due to historical policies of the telephone network, will often not exactly correspond to the distinction between a name service and a registrant in the DNS world -- a User in the telephone network is today at least rarely in a direct relationship with a Registrar comparable to that of a DNS registrant.
このフレームワークは、一般に、管理データとサービスデータがCSP、レジストラ、およびレジストリによって維持されることを前提としています。 「レジストラ」および「レジストリ」という用語はDNSの操作でよく知られており、実際にDNSは、ここで説明するエンティティ間の関係に明らかなインスピレーションを与えます。レジストリとレジストラの間で名前を転送するためのプロトコルは、しばらくの間DNS空間で標準化されています（[RFC3375]を参照）。同様に、DNSプロトコルで名前を解決して取得したサービスデータとWHOIS [RFC3912]を通じて取得した名前に関する管理データの区分は、セクション2.2で説明したサービスと管理データの区別に直接類似しています。 DNSのデータ管理アーキテクチャとこのフレームワークの主な違いは、電話ネットワークの歴史的なポリシーにより、CSPとユーザーの区別は、多くの場合、ネームサービスと登録者の区別に正確に対応していないことです。 DNSの世界-今日、電話ネットワークのユーザーは、少なくともDNS登録者に匹敵するレジストラと直接的な関係にあることはほとんどありません。
The role of a Registry described here is a "thin" one, where the Registry manages basic allocation information for the numbering space, such as information about whether or not the number is assigned, and if assigned, by which Registrar. It is the Registrar that, in turn, manages detailed administrative data about those assignments, such as contact or billing information for the assignee. In some models, CSPs and Registrars will be combined (the same administrative entity), and in others the Registry and Registrar may similarly be composed. Typically, service data resides largely at the CSP itself, though in some models a "thicker" Registry may itself contain a pointer to the servicing CSP for a number or number block. In addition to traditional centralized Registries, this framework also supports environments where the same data is being managed by multiple administrative entities and stored in many locations. A distributed registry system is discussed further in [DRIP]. To support those use cases, it is important to distinguish the following:
ここで説明するレジストリの役割は「シン」であり、レジストリは、番号が割り当てられているかどうか、割り当てられている場合はどのレジストラによって割り当てられているかなどの、番号付けスペースの基本的な割り当て情報を管理します。次に、担当者の連絡先や請求情報など、これらの割り当てに関する詳細な管理データを管理するのはレジストラです。一部のモデルでは、CSPとレジストラが結合され（同じ管理エンティティ）、他のモデルでは、レジストリとレジストラが同様に構成される場合があります。通常、サービスデータは主にCSP自体にありますが、一部のモデルでは、「より厚い」レジストリ自体に、番号または番号ブロックのサービスCSPへのポインターが含まれている場合があります。従来の中央集中型レジストリに加えて、このフレームワークは、同じデータが複数の管理エンティティによって管理され、多くの場所に格納されている環境もサポートします。分散レジストリシステムについては、[DRIP]でさらに説明します。これらのユースケースをサポートするには、以下を区別することが重要です。
Data Store: A data store is a service that stores and enables access to administrative and/or service data.
データストア：データストアは、管理データやサービスデータを保存し、それらへのアクセスを可能にするサービスです。
Reference Address: A reference address is a URL that dereferences to the location of the data store.
参照アドレス：参照アドレスは、データストアの場所を逆参照するURLです。
Distributed Data Stores: In a distributed data store, administrative or service data can be stored with multiple actors. For example, CSPs could provision their service data to multiple other CSPs.
分散データストア：分散データストアでは、管理データまたはサービスデータを複数のアクターと共に格納できます。たとえば、CSPはサービスデータを他の複数のCSPにプロビジョニングできます。
Distributed Registries: Multiple Registries can manage the same numbering resource. In these architectures, actors could interact with one or multiple Registries. The Registries would update each other when change occurs. The Registries have to ensure that data remains consistent, e.g., that the same TN is not assigned to two different actors.
分散レジストリ：複数のレジストリが同じ番号付けリソースを管理できます。これらのアーキテクチャでは、アクターは1つまたは複数のレジストリと対話できます。レジストリは、変更が発生すると互いに更新します。レジストリは、データが一貫していることを確認する必要があります。たとえば、同じTNが2つの異なるアクターに割り当てられないようにする必要があります。
The framework outlined in this document requires three Internet-based mechanisms for managing and resolving TNs in an IP environment. These mechanisms will likely reuse existing protocols for sharing structured data; it is unlikely that new protocol development work will be required, though new information models specific to the data itself will be a major focus of framework development. Likely candidates for reuse here include work done in DRINKS [RFC6461] and Web Extensible Internet Registration Data Service (WEIRDS) [RFC7482], as well as the Telephone-Related Information (TeRI) framework [TERI-INFO].
このドキュメントで概説するフレームワークには、IP環境でTNを管理および解決するための3つのインターネットベースのメカニズムが必要です。これらのメカニズムは、構造化データを共有するために既存のプロトコルを再利用する可能性があります。データ自体に固有の新しい情報モデルがフレームワーク開発の主な焦点になるが、新しいプロトコル開発作業が必要になることはほとんどありません。ここで再利用される可能性が高い候補には、DRINKS [RFC6461]とWeb拡張インターネット登録データサービス（WEIRDS）[RFC7482]、電話関連情報（TeRI）フレームワーク[TERI-INFO]で行われた作業が含まれます。
These protocol mechanisms are scoped in a way that makes them likely to apply to a broad range of future policies for number administration. It is not the purpose of this framework to dictate number policy but instead to provide tools that will work with policies as they evolve going forward. These mechanisms, therefore, do not assume that number administration is centralized nor that number allocations are restricted to any category of service providers, though these tools must and will work in environments with those properties.
これらのプロトコルメカニズムは、番号管理に関する将来の幅広いポリシーに適用される可能性が高い方法でスコープが設定されています。このフレームワークの目的は、番号ポリシーを指示することではなく、ポリシーが今後進化するときにポリシーと連動するツールを提供することです。したがって、これらのメカニズムは、番号管理が一元化されていることや、番号割り当てがサービスプロバイダーの任意のカテゴリに制限されていることを想定していません。
The three mechanisms are:
3つのメカニズムは次のとおりです。
Acquisition: A protocol mechanism for acquiring TNs, including an enrollment process.
取得：登録プロセスを含む、TNを取得するためのプロトコルメカニズム。
Management: A protocol mechanism for associating data with TNs.
管理：データをTNに関連付けるためのプロトコルメカニズム。
Retrieval: A protocol mechanism for retrieving data about TNs.
取得：TNに関するデータを取得するためのプロトコルメカニズム。
The acquisition mechanism will enable actors to acquire TNs for use with a communication service by requesting numbering resources from a service operated by a Registrar, CSP, or similar actor. TNs may be requested either on a number-by-number basis or as inventory blocks. Any actor who grants numbering resources will retain metadata about the assignment, including the responsible organization or individual to whom numbers have been assigned.
取得メカニズムにより、アクターは、レジストラー、CSP、または同様のアクターが運用するサービスから番号付けリソースを要求することにより、通信サービスで使用するTNを取得できます。 TNは、番号ごとまたはインベントリブロックとして要求できます。番号付けリソースを付与するアクターは、番号が割り当てられた責任組織または個人を含む、割り当てに関するメタデータを保持します。
The management mechanism will let actors provision data associated with TNs. For example, if a User has been assigned a TN, they may select a CSP to provide a particular service associated with the TN, or a CSP may assign a TN to a User upon service activation. In either case, a mechanism is needed to provision data associated with the TN at that CSP and to extend those data sets as CSPs (and even Users) require.
管理メカニズムにより、アクターはTNに関連付けられたデータをプロビジョニングできます。たとえば、ユーザーにTNが割り当てられている場合、ユーザーはTNに関連付けられた特定のサービスを提供するためにCSPを選択するか、サービスのアクティブ化時にCSPがユーザーにTNを割り当てることができます。どちらの場合も、そのCSPでTNに関連付けられたデータをプロビジョニングし、それらのデータセットをCSP（およびユーザー）が必要とするように拡張するためのメカニズムが必要です。
The retrieval mechanism will enable actors to learn information about TNs. For real-time service data, this typically involves sending a request to a CSP; for other information, an actor may need to send a request to a Registry rather than a CSP. Different parties may be authorized to receive different information about TNs.
検索メカニズムにより、アクターはTNに関する情報を学習できます。リアルタイムサービスデータの場合、これには通常、要求をCSPに送信することが含まれます。その他の情報については、アクターはCSPではなくレジストリにリクエストを送信する必要がある場合があります。 TNに関するさまざまな情報を受信するために、さまざまな当事者が許可される場合があります。
As an example, a CSP might use the acquisition interface to acquire a chunk of numbers from a Registrar. Users might then provision administrative data associated with those numbers at the CSP through the management interface and query for service data relating to those numbers through the retrieval interface of the CSP.
例として、CSPは取得インターフェイスを使用して、レジストラーから番号のチャンクを取得します。次に、ユーザーは、管理インターフェイスを介してCSPでこれらの番号に関連付けられた管理データをプロビジョニングし、CSPの取得インターフェイスを介してこれらの番号に関連するサービスデータを照会します。
+--------+
|Registry|
+---+----+
|
V
+---------+
|Registrar|
+---------+
\
\\
Acquisition \\
\\+-------+
\ CSP |
+---+---+
A A
| |
Management | | Retrieval
| |
| |
+-------++ ++-------+
| User | | User |
+--------+ +--------+
(Delegate) (Caller)
Figure 2: Example of the Three Interfaces
図2：3つのインターフェースの例
The high-level use cases in this section will provide an overview of the expected operation of the three interfaces in the MODERN problem space.
このセクションの高レベルの使用例では、MODERN問題空間での3つのインターフェースの予想される動作の概要を示します。
There are various scenarios for how TNs can be acquired by the relevant actors, that is, a CSP, Service Enabler, and a User. There are three actors from which numbers can be acquired: a Registrar, a CSP, and a User (presumably one who is delegating to another party). It is assumed either that Registrars are the same entity as Registries or that Registrars have established business relationships with Registries that enable them to distribute the numbers that the Registries administer. In these use cases, a User may acquire TNs either from a CSP, a Registry, or an intermediate delegate.
関連するアクター、つまりCSP、Service Enabler、およびユーザーがTNを取得する方法には、さまざまなシナリオがあります。番号を取得できる3つのアクターがあります。レジストラ、CSP、およびユーザー（おそらく別のパーティーに委任しているユーザー）です。レジストラは、レジストリと同じエンティティであるか、またはレジストラが管理する番号を配布できるようにするために、レジストリとのビジネス関係を確立していると想定されます。これらの使用例では、ユーザーはCSP、レジストリ、または中間デリゲートからTNを取得できます。
The most traditional number acquisition use case is one where a CSP, such as a carrier, requests a block of numbers from a Registrar to hold as inventory or assign to customers.
最も伝統的な番号取得の使用例は、キャリアなどのCSPが、在庫として保持するか顧客に割り当てるために、レジストラーに番号のブロックを要求する場合です。
Through some out-of-band business process, a CSP develops a relationship with a Registrar. The Registrar maintains a profile of the CSP and assesses whether or not CSPs meet the policy restrictions for acquiring TNs. The CSP may then request TNs from within a specific pool of numbers in the authority of the Registry, such as region, mobile, wireline, or freephone. The Registrar must authenticate and authorize the CSP and then either grant or deny a request. When an assignment occurs, the Registry creates and stores administrative information related to the assignment, such as TN status and Registrar contact information, and removes the specific TN(s) from the pool of those that are available for assignment. As a part of the acquisition and assignment process, the Registry provides to the Registrar any tokens or other material needed by a Credential Authority to issue credentials (for example, Secure Telephone Identity Revisited (STIR) certificates [RFC8226]) used to attest the assignment for future transactions. Depending on the policies of the Numbering Authorities, Registrars may be required to log these operations.
CSPは、帯域外のビジネスプロセスを通じて、レジストラとの関係を構築します。レジストラは、CSPのプロファイルを維持し、CSPがTNを取得するためのポリシー制限を満たしているかどうかを評価します。次に、CSPは、地域、携帯電話、有線電話、フリーフォンなど、レジストリの権限の特定の番号プール内からTNを要求します。レジストラーはCSPを認証および承認してから、要求を許可または拒否する必要があります。割り当てが発生すると、レジストリはTNステータスやレジストラの連絡先情報など、割り当てに関連する管理情報を作成して保存し、割り当てに使用できるプールから特定のTNを削除します。取得および割り当てプロセスの一部として、レジストリは、割り当てを検証するために使用される資格情報（たとえば、Secure Telephone Identity Revisited（STIR）証明書[RFC8226]）を発行するために資格証明機関が必要とするトークンまたはその他の資料をレジストラに提供します将来の取引のため。採番機関のポリシーによっては、これらの操作を記録するためにレジストラが必要になる場合があります。
Before it is eligible to receive TN assignments, per the policy of a Numbering Authority, the CSP may need to have submitted (again, through some out-of-band process) additional qualifying information such as the current utilization rate or a demand forecast.
番号割り当て機関のポリシーに従って、TN割り当てを受け取る資格がある前に、CSPは現在の使用率や需要予測などの追加の適格情報を（再度、帯域外プロセスを介して）送信する必要がある場合があります。
There are two scenarios under which a CSP requests resources: either they are requesting inventory or they are requesting for a specific User or delegate. For the purpose of status information, TNs assigned to a User are always considered assigned, not inventory. The CSP will associate service information for that TN (e.g., a service address) and make it available to other CSPs to enable interconnection. The CSP may need to update the Registrar regarding this service activation; this is part of the "TN status" maintained by the Registrar.
CSPがリソースを要求するシナリオは2つあります。それらは、インベントリを要求するか、特定のユーザーまたは委任を要求するかのいずれかです。ステータス情報の目的で、ユーザーに割り当てられたTNは常にインベントリではなく割り当て済みと見なされます。 CSPはそのTNのサービス情報（サービスアドレスなど）を関連付け、他のCSPが相互接続できるようにします。 CSPは、このサービスのアクティブ化に関してレジストラを更新する必要がある場合があります。これは、レジストラによって維持される「TNステータス」の一部です。
There are also use cases in which a User can acquire a TN directly from a Registrar. Today, a User wishing to acquire a freephone number may browse the existing inventory through one or more Registrars, comparing their prices and services. Each such Registrar either is a CSP or has a business relationship with one or more CSPs to provide services for that freephone number. In this case, the User must establish some business relationship directly with a Registrar, similar to how such functions are conducted today when Users purchase domain names. In this use case, after receiving a number assignment from the Registrar, a User will obtain communication service from a CSP and provide to the CSP the TN to be used for that service. The CSP will associate service information for that TN (e.g., the service address) and make it available to other CSPs to enable interconnection. The User will also need to inform the Registrar about this relationship.
また、ユーザーがレジストラから直接TNを取得できるユースケースもあります。今日、無料の電話番号を取得したいユーザーは、1つ以上のレジストラを通じて既存の在庫を閲覧し、価格とサービスを比較することができます。そのような各レジストラはCSPであるか、1つ以上のCSPとビジネス関係を持ち、そのフリーダイヤル番号にサービスを提供します。この場合、ユーザーは、ユーザーがドメイン名を購入するときに今日行われている機能と同様に、レジストラと直接ビジネス関係を確立する必要があります。このユースケースでは、ユーザーはレジストラーから番号割り当てを受け取った後、CSPから通信サービスを取得し、そのサービスに使用するTNをCSPに提供します。 CSPはそのTNのサービス情報（サービスアドレスなど）を関連付け、他のCSPが相互接続できるようにします。ユーザーは、この関係についてレジストラに通知する必要もあります。
Today, a User typically acquires a TN from a CSP when signing up for a communication service or turning on a new device. In this use case, the User becomes the delegate of the CSP. A reseller or a service bureau might also acquire a block of numbers from a CSP to be issued to Users.
今日、ユーザーは通常、通信サービスにサインアップするとき、または新しいデバイスをオンにするときに、CSPからTNを取得します。この使用例では、ユーザーがCSPのデリゲートになります。リセラーまたはサービスビューローは、ユーザーに発行する番号のブロックをCSPから取得する場合もあります。
Consider a case where a User creates or has a relationship with the CSP and subscribes to a communication service that includes the use of a TN. The CSP collects and stores administrative data about the User. The CSP then activates the User on their network and creates any necessary service data to enable connectivity with other CSPs. The CSP could also update public or privileged databases accessible by other actors. The CSP provides any tokens or other material needed by a Credential Authority to issue credentials to the User (for example, a STIR certificate [RFC8226]) to prove the assignment for future transactions. Such credentials could be delegated from the one provided by the Credential Authority to the CSP to continue the chain of assignment. CSPs may be required to log such transactions if required by the policy of the Numbering Authority.
ユーザーがCSPを作成するか、CSPと関係があり、TNの使用を含む通信サービスにサブスクライブする場合を考えます。 CSPは、ユーザーに関する管理データを収集して保存します。次に、CSPはネットワーク上のユーザーをアクティブ化し、他のCSPとの接続を可能にするために必要なサービスデータを作成します。 CSPは、他のアクターがアクセスできるパブリックデータベースまたは特権データベースを更新することもできます。 CSPは、資格証明機関がユーザーに資格情報を発行するために必要なトークンまたはその他の資料（たとえば、STIR証明書[RFC8226]）を提供して、将来のトランザクションの割り当てを証明します。このような資格情報は、資格機関からCSPに提供された資格情報を委任して、割り当てのチェーンを継続することができます。採番機関のポリシーで要求されている場合、CSPはそのようなトランザクションをログに記録する必要がある場合があります。
Virtually, the same flow would work for a reseller: it would form a business relationship with the CSP, at which point the CSP would collect and store administrative data about the reseller and give the reseller any material needed for the reseller to acquire credentials for the numbers. A User might then, in turn, acquire numbers from the reseller: in this case, the delegate redelegating the TNs would be performing functions done by the CSP (e.g., providing any credentials or collecting administrative data or creative service data).
事実上、同じフローがリセラーでも機能します。これはCSPとのビジネス関係を形成し、その時点でCSPはリセラーに関する管理データを収集して保存し、リセラーが資格情報を取得するために必要な資料をリセラーに提供します番号。次に、ユーザーはリセラーから番号を取得します。この場合、TNを再委任するデリゲートは、CSPによって実行される機能を実行します（資格情報の提供、管理データやクリエイティブサービスデータの収集など）。
The CSP could assign a TN from its existing inventory or it could acquire a new TN from the Registrar as part of the assignment process. If it assigns it from its existing inventory, it would remove the specific TN from the pool of those available for assignment. It may also update the Registrar about the assignment so the Registrar has current assignment data. If a reseller or delegate CSP is acquiring the numbers, it may have the same obligations to provide utilization data to the Registry as the assignee, per Section 4.1.1.
CSPは、既存のインベントリからTNを割り当てることも、割り当てプロセスの一環としてレジストラから新しいTNを取得することもできます。既存のインベントリから割り当てると、割り当て可能なプールのプールから特定のTNが削除されます。また、割り当てについてレジストラを更新して、レジストラが現在の割り当てデータを保持するようにすることもできます。リセラーまたは代理のCSPが番号を取得している場合、セクション4.1.1に従って、譲受人と同じようにレジストリに使用状況データを提供する義務がある場合があります。
The management protocol mechanism is needed to associate administrative and service data with TNs and may be used to refresh or rollover associated credentials.
管理プロトコルメカニズムは、管理データとサービスデータをTNに関連付けるために必要であり、関連付けられた資格情報を更新またはロールオーバーするために使用できます。
Administrative data is primarily related to the status of the TN, its administrative contacts, and the actors involved in providing service to the TN. Protocol interactions for administrative data will therefore predominantly occur between CSPs and Users to the Registrar or between Users and delegate CSPs to the CSP.
管理データは、主にTNのステータス、その管理連絡先、およびTNへのサービスの提供に関与するアクターに関連しています。したがって、管理データのプロトコル相互作用は、主にCSPとユーザーの間でレジストラに、またはユーザーとCSPをCSPに委任するときに発生します。
Some administrative data may be private and would thus require special handling in a distributed data store model. Access to it does not require real-time performance; therefore, local caches are not necessary, and the data will include sensitive information such as User and contact data.
一部の管理データはプライベートであるため、分散データストアモデルで特別な処理が必要になります。それへのアクセスには、リアルタイムのパフォーマンスは必要ありません。したがって、ローカルキャッシュは必要ありません。データには、ユーザーデータや連絡先データなどの機密情報が含まれます。
Some of the data could lend itself to being publicly available, such as CSP and TN assignment status. In that case, it would be deemed public information for the purposes of the retrieval interface.
CSPやTN割り当てステータスなど、一部のデータは公に利用可能になる可能性があります。その場合、それは検索インターフェースの目的で公開情報と見なされます。
After a CSP acquires a TN or block of TNs from the Registrar (per Section 4.1.1), it then provides administrative data to the Registrar as a step in the acquisition process. The Registrar will authenticate the CSP and determine if the CSP is authorized to provision the administrative data for the TNs in question. The Registry will update the status of the TN, i.e., that it is unavailable for assignment. The Registrar will also maintain administrative data provided by the CSP.
CSPは、レジストラからTNまたはTNのブロックを取得した後（セクション4.1.1に従って）、取得プロセスのステップとして管理データをレジストラに提供します。レジストラはCSPを認証し、問題のTNの管理データをプロビジョニングする権限がCSPにあるかどうかを判断します。レジストリはTNのステータスを更新します。つまり、割り当てに使用できません。レジストラは、CSPによって提供される管理データも維持します。
Changes to this administrative data will not be frequent. Examples of changes would be terminating service (see Section 4.2.3.2), changing the name or address of a User or organization, or changing a CSP or delegate. Changes should be authenticated by a credential to prove administrative responsibility for the TN.
この管理データは頻繁に変更されません。変更の例としては、サービスの終了（セクション4.2.3.2を参照）、ユーザーまたは組織の名前またはアドレスの変更、CSPまたは委任の変更があります。 TNの管理責任を証明するには、変更を資格情報によって認証する必要があります。
In some cases, such as the freephone system in North America today, the User has a direct relationship with the Registrar. Naturally, these Users could provision administrative data associated with their TNs directly to the Registrar just as a freephone provider today maintains account and billing data. While delegates may not ordinarily have a direct relationship to a Registrar, some environments (as an optimization) might want to support a model where the delegate updates the Registrar directly on changes, as opposed to sending that data to the CSP or through the CSP to the Registrar. As stated already, the protocol should enable Users to acquire TNs directly from a Registrar, which may or may not also act as a CSP. In these cases, the updates would be similar to those described in Section 4.2.1.1.
今日の北米の無料電話システムなど、一部のケースでは、ユーザーはレジストラと直接的な関係を持っています。当然、これらのユーザーは、TNに関連付けられた管理データをレジストラーに直接プロビジョニングできます。これは、今日のフリーダイヤルプロバイダーがアカウントと請求データを維持しているのと同じです。デリゲートは通常、レジストラーと直接的な関係を持っていない場合がありますが、一部の環境（最適化として）は、データをCSPに送信したり、CSPを介してレジストラ。すでに述べたように、プロトコルは、ユーザーがレジストラから直接TNを取得できるようにする必要があります。レジストラは、CSPとしても機能することも、機能しないこともあります。これらの場合、更新はセクション4.2.1.1で説明されているものと同様です。
In a distributed Registry model, TN status (e.g., allocated, assigned, available, or unavailable) would need to be provided to other Registries in real time. Other administrative data could be sent to all Registries, or other Registries could get a reference address to the host Registry's data store.
分散レジストリモデルでは、TNステータス（割り当て済み、割り当て済み、使用可能、または使用不可など）を他のレジストリにリアルタイムで提供する必要があります。他の管理データをすべてのレジストリに送信したり、他のレジストリがホストレジストリのデータストアへの参照アドレスを取得したりする可能性があります。
After a User acquires a TN or block of TNs from a CSP, the User will provide administrative data to the CSP. The CSP commonly acts as a Registrar in this case by maintaining the administrative data and only notifying the Registry of the change in TN status. In this case, the Registry maintains a reference address (see Section 2.3) to the CSP/Registrar's administrative data store so relevant actors have the ability to access the data. Alternatively, a CSP could send the administrative data to an external Registrar to store. If there is a delegate between the CSP and User, they will have to ensure there is a mechanism for the delegate to update the CSP as change occurs.
ユーザーがCSPからTNまたはTNのブロックを取得した後、ユーザーはCSPに管理データを提供します。この場合、CSPは通常、管理データを維持し、レジストリにTNステータスの変更を通知するだけで、レジストラーとして機能します。この場合、レジストリはCSP / Registrarの管理データストアへの参照アドレス（セクション2.3を参照）を保持しているため、関連するアクターがデータにアクセスできます。または、CSPは管理データを外部のレジストラに送信して保存することもできます。 CSPとユーザーの間にデリゲートがある場合、変更が発生したときに、デリゲートがCSPを更新するメカニズムがあることを確認する必要があります。
Service data is data required by an originating or intermediate CSP to enable communication service to a User; a SIP URI is an example of one service data element commonly used to route communication. CSPs typically create and manage service data, however, it is possible that delegates and Users could as well. For most use cases involving individual Users, it is anticipated that lower-level service information changes (such as an end-user device receiving a new IP address) would be communicated to CSPs via existing protocols. For example, the baseline SIP REGISTER [RFC3261] method, even for bulk operations [RFC6140], would likely be used rather than through any new interfaces defined by MODERN.
サービスデータは、ユーザーへの通信サービスを可能にするために、発信元または中間のCSPが必要とするデータです。 SIP URIは、通信のルーティングに一般的に使用される1つのサービスデータ要素の例です。 CSPは通常、サービスデータを作成および管理しますが、デリゲートとユーザーも同様に可能です。個々のユーザーが関与するほとんどのユースケースでは、下位レベルのサービス情報の変更（新しいIPアドレスを受信するエンドユーザーデバイスなど）が既存のプロトコルを介してCSPに伝達されることが予想されます。たとえば、ベースラインのSIP REGISTER [RFC3261]メソッドは、一括操作[RFC6140]の場合でも、MODERNで定義された新しいインターフェイスではなく使用される可能性があります。
After a User enrolls for service with a CSP, in the case where the CSP was assigned the TN by a Registrar, the CSP will then create a service address such as a SIP URI and associate it with the TN. The CSP needs to update this data to enable service interoperability. There are multiple ways that this update can occur, though most commonly service data is exposed through the retrieval interface (see Section 4.3). For certain deployment architectures, like a distributed data store model, CSPs may need to provision data directly to other CSPs.
ユーザーがCSPでサービスに登録すると、CSPがレジストラーによってTNを割り当てられた場合、CSPはSIP URIなどのサービスアドレスを作成し、それをTNに関連付けます。 CSPは、サービスの相互運用を可能にするために、このデータを更新する必要があります。この更新が発生する可能性のある方法はいくつかありますが、ほとんどの場合、サービスデータは取得インターフェイスを通じて公開されます（セクション4.3を参照）。分散データストアモデルのような特定の展開アーキテクチャでは、CSPは他のCSPにデータを直接プロビジョニングする必要がある場合があります。
If the CSP is assigning a TN from its own inventory, it may not need to perform service data updates as change occurs because the existing service data associated with inventory may be sufficient once the TN is put in service. They would, however, likely update the Registry on the change in status.
CSPが独自のインベントリからTNを割り当てている場合、TNのサービスが開始されると、インベントリに関連付けられた既存のサービスデータで十分になるため、変更が発生してもサービスデータを更新する必要がない場合があります。ただし、ステータスの変更時にレジストリを更新する可能性があります。
Users could also associate service data to their TNs at the CSP. An example would be a User acquiring a TN from the Registrar (as described in Section 4.1.1) and wanting to provide that TN to the CSP so the CSP can enable service. In this case, once the User provides the number to the CSP, the CSP would update the Registry or other actors as outlined in Section 4.2.2.1.
ユーザーは、CSPでサービスデータをTNに関連付けることもできます。例としては、（セクション4.1.1で説明されているように）レジストラーからTNを取得し、そのTNをCSPに提供して、CSPがサービスを有効にできるようにするユーザーがあります。この場合、ユーザーが番号をCSPに提供すると、CSPはセクション4.2.2.1で概説されているようにレジストリまたは他のアクターを更新します。
This section will address some special management use cases that were not covered above.
このセクションでは、上記で取り上げられなかったいくつかの特別な管理の使用例を扱います。
Consider the case where a User who subscribes to a communication service (and who received their TN from that CSP) wishes to retain the same TN but move their service to a different CSP.
通信サービスに加入している（およびそのCSPからTNを受け取った）ユーザーが同じTNを保持したいが、サービスを別のCSPに移動する場合を考えてみます。
In the simplest scenario, where there's an authoritative combined Registry/Registrar that maintains service data, the User could provide their credential to the new CSP and let the CSP initiate the change in service. The new CSP could then provide the new service data with the User's credential to the Registry/Registrar, which then makes the change. The old credential is revoked and a new one is provided. The new CSP or the Registrar would send a notification to the old CSP so they can disable service. The old CSP will undo any delegations to the User, including contacting the Credential Authority to revoke any cryptographic credentials (e.g., STIR certificates [RFC8226]) previously granted to the User. Any service data maintained by the CSP must be removed, and, similarly, the CSP must delete any such information it provisioned in the Registry.
最も単純なシナリオでは、サービスデータを維持する信頼できる結合されたレジストリ/レジストラーがあり、ユーザーは資格情報を新しいCSPに提供し、CSPにサービスの変更を開始させることができます。次に、新しいCSPは、新しいサービスデータにユーザーの資格情報をRegistry / Registrarに提供し、変更を加えます。古い資格情報は取り消され、新しい資格情報が提供されます。新しいCSPまたはレジストラは、サービスを無効にできるように古いCSPに通知を送信します。古いCSPは、以前にユーザーに付与されていた暗号化された資格情報（STIR証明書[RFC8226]など）を取り消すために資格証明機関に連絡するなど、ユーザーへの委任を取り消します。 CSPによって維持されているサービスデータはすべて削除する必要があり、同様に、CSPはレジストリでプロビジョニングしたそのような情報を削除する必要があります。
In a model similar to common practice in environments today, the User could alternatively provide their credential to the old CSP, and the old CSP would initiate the change in service. Or, a User could go directly to a Registrar to initiate a port. This framework should support all of these potential flows.
現在の環境における一般的な慣行と同様のモデルでは、ユーザーは代わりに資格情報を古いCSPに提供でき、古いCSPがサービスの変更を開始します。または、ユーザーは、レジストラに直接アクセスして、ポートを開始することもできます。このフレームワークは、これらすべての潜在的なフローをサポートする必要があります。
Note that in cases with a distributed Registry that maintained service data, the Registry would also have to update the other Registries of the change.
サービスデータを維持する分散レジストリの場合、レジストリは変更の他のレジストリも更新する必要があることに注意してください。
Consider a case where a User who subscribes to a communication service (and who received their TN from the CSP) wishes to terminate their service. At this time, the CSP will undo any delegations to the User, which may involve contacting the Credential Authority to revoke any cryptographic credentials (e.g., STIR certificates [RFC8226]) previously granted to the User. Any service data maintained by the CSP must be removed, and similarly, the CSP must delete any such information it provisioned in the Registrar. However, per the policy of the Numbering Authority, Registrars and CSPs may be required to preserve historical data that will be accessible to Government Entities or others through audits, even if it is no longer retrievable through service interfaces.
通信サービスに加入している（CSPからTNを受け取った）ユーザーがサービスを終了したい場合を考えます。この時点で、CSPはユーザーへの委任を取り消します。これには、以前にユーザーに付与されていた暗号化された資格情報（STIR証明書[RFC8226]など）を取り消すために資格証明機関に連絡する必要がある場合があります。 CSPによって維持されているサービスデータはすべて削除する必要があり、同様に、CSPはレジストラでプロビジョニングしたそのような情報を削除する必要があります。ただし、ナンバリング機関のポリシーに従って、レジストラとCSPは、サービスインターフェイスから取得できなくなったとしても、監査を通じて政府機関やその他の人々がアクセスできる履歴データを保持する必要がある場合があります。
The TN will change state from assigned to unassigned, and the CSP will update the Registry. Depending on policies, the TN could go back into the Registry, CSP, or delegate's pool of available TNs and would likely enter an aging process.
TNは状態を割り当て済みから未割り当てに変更し、CSPはレジストリを更新します。ポリシーに応じて、TNはレジストリ、CSP、またはデリゲートの利用可能なTNのプールに戻り、エージングプロセスに入る可能性があります。
In an alternative use case, a User who received their own TN assignment directly from a Registrar terminates their service with a CSP. At this time, the User might terminate their assignment from the Registrar and return the TN to the Registry for reassignment. Alternatively, they could retain the TN and elect to assign it to some other service at a later time.
別の使用例では、レジストラから直接自分のTN割り当てを受け取ったユーザーは、CSPでサービスを終了します。このとき、ユーザーはレジストラからの割り当てを終了し、TNをレジストリに返して再割り当てすることができます。または、TNを保持し、後で他のサービスに割り当てることもできます。
Retrieval of administrative or service data will be subject to access restrictions based on the category of the specific data: public, semi-restricted, or restricted. Both administrative and service data can have data elements that fall into each of these categories. It is expected that the majority of administrative data will fall into the semi-restricted category: access to this information may require some form of authorization, though service data crucial to reachability will need to be accessible. In some environments, it's possible that none of the service data necessary to initiate communication will be useful to an entity on the public Internet, or that all that service data will have dependencies on the origination point for calls.
管理データまたはサービスデータの取得は、特定のデータのカテゴリ（公開、準制限、または制限付き）に基づくアクセス制限の対象になります。管理データとサービスデータの両方に、これらの各カテゴリに分類されるデータ要素を含めることができます。管理データの大部分は準制限カテゴリに分類されることが予想されます。この情報へのアクセスには、何らかの形の承認が必要になる場合がありますが、到達可能性に重要なサービスデータにはアクセスできる必要があります。一部の環境では、通信を開始するために必要なサービスデータが、パブリックインターネット上のエンティティにとって役に立たない場合や、そのすべてのサービスデータが通話の発信ポイントに依存する場合があります。
The retrieval protocol mechanism for semi-restricted and restricted data needs a way for the receiver of the request to identify the originator of the request and what is being requested. The receiver of the request will process that request based on this information.
半制限データと制限データの取得プロトコルメカニズムでは、要求の受信者が要求の発信者と要求されているものを識別する方法が必要です。リクエストの受信者は、この情報に基づいてそのリクエストを処理します。
Either administrative or service data may be made publicly available by the authority that generates and provisions it. Under most circumstances, a CSP wants its communication service to be publicly reachable through TNs, so the retrieval interface supports public interfaces that permit clients to query for service data about a TN. Some service data may, however, require that the client be authorized to receive it, per the use case in Section 4.3.3.
管理データまたはサービスデータのいずれかは、それを生成してプロビジョニングする当局によって公に利用可能になる場合があります。ほとんどの状況では、CSPは通信サービスがTNを通じてパブリックに到達可能であることを望んでいるため、検索インターフェイスは、クライアントがTNに関するサービスデータを照会できるようにするパブリックインターフェイスをサポートしています。ただし、一部のサービスデータでは、セクション4.3.3のユースケースに従って、クライアントがデータを受信することを許可されている必要があります。
Public data can simply be posted on websites or made available through a publicly available API. Public data hosted by a CSP may have a reference address at the Registry.
公開データは、単にWebサイトに投稿するか、公開されているAPIを介して利用可能にすることができます。 CSPがホストするパブリックデータは、レジストリに参照アドレスを持つ場合があります。
Consider a case in which a CSP is having service problems completing calls to a specific TN, so it wants to contact the CSP serving that TN. The Registry authorizes the originating CSP to access this information. It initiates a query to the Registry, the Registry verifies the requestor and the requested data, and the Registry responds with the serving CSP and contact data. However, CSPs might not want to make those administrative contact points public data: they are willing to share them with other CSPs for troubleshooting purposes, but not to make them available to general communication.
CSPが特定のTNへの呼び出しを完了する際にサービスの問題を抱えているため、そのTNを提供しているCSPに連絡したいとします。レジストリは、元のCSPがこの情報にアクセスすることを承認します。レジストリへのクエリを開始し、レジストリはリクエスタと要求されたデータを検証し、レジストリはサービス提供のCSPと連絡先データで応答します。ただし、CSPはこれらの管理用連絡先を公開データにしたくない場合があります。トラブルシューティングの目的で、CSPを他のCSPと共有することはできますが、一般的な通信では利用できません。
Alternatively, that information could be part of a distributed data store and not stored at a monolithic Registry. In that case, the CSP has the data in a local distributed data store, and it initiates the query to the local data store. The local data store responds with the CSP and contact data. No verification is necessary because it was done when the CSP was authorized to receive the data store.
または、その情報が分散データストアの一部であり、モノリシックレジストリに格納されていない場合もあります。その場合、CSPはローカルの分散データストアにデータを持ち、ローカルデータストアへのクエリを開始します。ローカルデータストアは、CSPおよび連絡先データで応答します。検証は、CSPがデータストアの受信を承認されたときに行われたため、必要ありません。
Consider a case where a User on a CSP's network calls a TN. The CSP initiates a query for service data associated with the TN to complete the call and will receive special service data because the CSP operates in a closed environment where different CSPs receive different responses, and only participating CSPs can initiate communication. This service data would be flagged as semi-restricted. The query and response have real-time performance requirements in that environment.
CSPのネットワーク上のユーザーがTNを呼び出す場合を考えます。 CSPは、TNに関連付けられたサービスデータのクエリを開始して呼び出しを完了し、特別なサービスデータを受信します。これは、CSPが異なる応答を受信するクローズド環境で動作し、参加しているCSPのみが通信を開始できるためです。このサービスデータには、準制限のフラグが付けられます。クエリと応答には、その環境でのリアルタイムのパフォーマンス要件があります。
Semi-restricted service data also works in a distributed data store model where each CSP distributes its updated service data to all other CSPs. The originating CSP has the service data in its local data store and queries it. The local data store responds with the service data. The service data in the response can be a reference address to a data store maintained by the serving CSP or it can be the service address itself. In the case where the response gives a reference address, a subsequent query would go to the serving CSP, who would, in turn, authorize the requestor for the requested data and respond appropriately. In the case, where the original response contains the service address, the requestor would use that service address as the destination for the call.
準制限付きのサービスデータは、各CSPが更新されたサービスデータを他のすべてのCSPに配布する分散データストアモデルでも機能します。元のCSPは、ローカルデータストアにサービスデータを持ち、クエリを実行します。ローカルデータストアはサービスデータで応答します。応答内のサービスデータは、サービスを提供するCSPが保持するデータストアへの参照アドレスにすることも、サービスアドレス自体にすることもできます。応答が参照アドレスを提供する場合、後続のクエリはサービングCSPに送信され、サービングCSPは要求されたデータに対してリクエスターを承認し、適切に応答します。元の応答にサービスアドレスが含まれている場合、リクエスタはそのサービスアドレスを呼び出しの宛先として使用します。
In some environments, aspects of the service data may reside at the Registry itself (for example, the assigned CSP for a TN); thus, the query may be sent to the Registry. The Registry verifies the requestor and the requested data and responds with the service data, such as a SIP URI containing the domain of the assigned CSP.
一部の環境では、サービスデータの側面がレジストリ自体に存在する場合があります（たとえば、TNに割り当てられたCSP）。したがって、クエリはレジストリに送信されます。レジストリは、要求者と要求されたデータを検証し、割り当てられたCSPのドメインを含むSIP URIなどのサービスデータで応答します。
A Government Entity wishes to access information about a particular User who subscribes to a communication service. The entity that operates the Registry on behalf of the Numbering Authority in this case has some predefined relationship with the Government Entity. When the CSP acquired TNs from the Numbering Authority, it was a condition of that assignment that the CSP provide access for Government Entities to telephone numbering data when certain conditions apply. The required data may reside either in the CSP or in the Registrar.
政府機関は、通信サービスに加入している特定のユーザーに関する情報にアクセスしたいと考えています。この場合、採番機関に代わってレジストリを運営する事業体は、政府機関といくつかの事前定義された関係を持っています。 CSPが番号付け機関からTNを取得したとき、特定の条件が適用されるときに、CSPが政府機関に電話番号データへのアクセスを提供することは、その割り当ての条件でした。必要なデータは、CSPまたはレジストラに存在する可能性があります。
For a case where the CSP delegates a number to the User, the CSP might provision the Registrar (or itself, if the CSP is composed with a Registrar) with information relevant to the User. At such a time as the Government Entity needs information about that User, the Government Entity may contact the Registrar or CSP to acquire the necessary data. The interfaces necessary for this will be the same as those described in Section 4.3; the Government Entity will be authenticated and an authorization decision will be made by the Registrar or CSP under the policy dictates established by the Numbering Authority.
CSPがユーザーに番号を委任する場合、CSPはユーザーに関連する情報をレジストラー（またはCSPがレジストラーで構成されている場合はそれ自体）をプロビジョニングする場合があります。政府機関がそのユーザーに関する情報を必要とするようなときに、政府機関はレジストラまたはCSPに連絡して必要なデータを取得する場合があります。これに必要なインターフェースは、セクション4.3で説明したものと同じです。政府機関は認証され、承認決定は、番号付け機関によって確立されたポリシーに基づいて、レジストラまたはCSPによって行われます。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
This framework defines two categories of information about telephone numbers: service data and administrative data. Service data describes how telephone numbers map to particular services and devices that provide real-time communication for users. As such, service data could potentially leak resource locations and even lower-layer network addresses associated with these services, and in rare cases, with end-user devices. Administrative data more broadly characterizes who the administrative entities are behind telephone numbers, which will often identify CSPs but some layers of the architecture could include Personally Identifiable Information (PII), even WHOIS-style information, about the end users behind identifiers. This could conceivably encompass the sorts of data that carriers and similar CSPs today keep about their customers for billing purposes, like real names and postal addresses. The exact nature of administrative data is not defined by this framework, and it is anticipated that the protocols that will perform this function will be extensible for different use cases, so at this point, it is difficult to characterize exactly how much PII might end up being housed by these services.
このフレームワークは、電話番号に関する2つのカテゴリの情報、サービスデータと管理データを定義します。サービスデータは、電話番号が特定のサービスやユーザーにリアルタイムの通信を提供するデバイスにどのようにマッピングされるかを示します。そのため、サービスデータは、リソースの場所や、これらのサービスに関連付けられた、さらにまれなケースでは、エンドユーザーのデバイスに関連付けられた下位層のネットワークアドレスをリークする可能性があります。管理データは、管理エンティティが電話番号の背後にいる人物をより広く特徴付けます。これにより、多くの場合CSPが識別されますが、アーキテクチャの一部の層には、識別子の背後にあるエンドユーザーに関する個人識別情報（PII）、さらにはWHOISスタイルの情報を含めることができます。これには、キャリアや類似のCSPが、本名や住所などの請求目的で顧客について現在保持している種類のデータが含まれると考えられます。管理データの正確な性質はこのフレームワークでは定義されておらず、この機能を実行するプロトコルはさまざまなユースケースに拡張可能であると予想されるため、現時点では、PIIがどの程度終わるかを正確に特徴付けることは困難です。これらのサービスによって収容されています。
As such, if an attacker were to compromise the registrar services that maintains administrative data in this architecture, and in some cases even service data, this could leak PII about end users. These interfaces, and the systems that host them, are a potentially attractive target for hackers and need to be hardened accordingly. Protocols that are selected to fulfill these functions must provide the security features described in Section 7.
そのため、攻撃者がこのアーキテクチャで管理データを維持するレジストラサービス、場合によってはサービスデータを侵害すると、エンドユーザーに関するPIIが漏洩する可能性があります。これらのインターフェースとそれらをホストするシステムは、ハッカーにとって魅力的なターゲットであり、それに応じて強化する必要があります。これらの機能を満たすために選択されたプロトコルは、セクション7で説明されているセキュリティ機能を提供する必要があります。
Finally, this framework recognizes that, in many jurisdictions, certain government agencies have a legal right to access service and administrative data maintained by CSPs. This access is typically aimed at identifying the users behind the communication identifier in order to enforce regulatory policy. Those legal entities already have the power to access the existing data held by CSPs in many jurisdictions, though, potentially, the administrative data associated with this framework could be richer information.
最後に、このフレームワークは、多くの管轄区域において、特定の政府機関がCSPによって維持されているサービスおよび管理データにアクセスする法的権利を持っていることを認識しています。このアクセスは通常、規制ポリシーを実施するために、通信識別子の背後にいるユーザーを識別することを目的としています。これらの法人は、多くの管轄区域のCSPが保持する既存のデータにアクセスする権限をすでに持っていますが、このフレームワークに関連付けられている管理データは、より豊富な情報になる可能性があります。
The acquisition, management, and retrieval of administrative and service data associated with telephone numbers raises a number of security issues.
電話番号に関連する管理およびサービスデータの取得、管理、および取得は、多くのセキュリティ問題を引き起こします。
Any mechanism that allows an individual or organization to acquire telephone numbers will require a means of mutual authentication, of integrity protection, and of confidentiality. A Registry as defined in this document will surely want to authenticate the source of an acquisition request as a first step in the authorization process to determine whether or not the resource will be granted. Integrity of both the request and response is essential to ensuring that tampering does not allow attackers to block acquisitions, or worse, to commandeer resources. Confidentiality is essential to preventing eavesdroppers from learning about allocations, including the personally identifying information associated with the administrative or technical contracts for allocations.
個人または組織が電話番号を取得できるようにするメカニズムには、相互認証、完全性保護、および機密保持の手段が必要です。このドキュメントで定義されているレジストリは、リソースが許可されるかどうかを決定するための承認プロセスの最初のステップとして、確実に取得要求のソースを認証する必要があります。要求と応答の両方の整合性は、改ざんによって攻撃者が取得をブロックしたり、さらに悪いことに、リソースを指揮したりできないようにするために不可欠です。秘密保持は、盗聴者が割り当てについて知ることを防ぐために不可欠です。
A management interface for telephone numbers has similar requirements. Without proper authentication and authorization mechanisms in place, an attack could use the management interface to disrupt service data or administrative data, which could deny service to users, enable new impersonation attacks, prevent billing systems from operating properly, and cause similar system failures.
電話番号の管理インターフェースにも同様の要件があります。適切な認証および承認メカニズムがない場合、攻撃は管理インターフェイスを使用してサービスデータまたは管理データを妨害し、ユーザーへのサービスを拒否し、新しい偽装攻撃を有効にし、課金システムが適切に動作しなくなり、同様のシステム障害を引き起こす可能性があります。
Finally, a retrieval interface has its own needs for mutual authentication, integrity protection, and confidentiality. Any CSP sending a request to retrieve service data associated with a number will want to know that it is reaching the proper authority, that the response from that authority has not been tampered with in transit, and, in most cases, the CSP will not want to reveal to eavesdroppers the number it is requesting or the response that it has received. Similarly, any service answering such a query will want to have a means of authenticating the source of the query and of protecting the integrity and confidentiality of its responses.
最後に、検索インターフェースには、相互認証、完全性保護、および機密性に対する独自のニーズがあります。番号に関連付けられたサービスデータを取得する要求を送信するCSPは、それが適切な機関に到達していること、その機関からの応答が転送中に改ざんされていないこと、ほとんどの場合、CSPが望まないことを知る必要があります。要求している番号または受信した応答を盗聴者に明らかにする。同様に、そのようなクエリに応答するサービスは、クエリのソースを認証し、その応答の完全性と機密性を保護する手段を必要としています。
[DRIP] Wendt, C. and H. Bellur, "Distributed Registry Protocol (DRiP)", Work in Progress, draft-wendt-modern-drip-02, July 2017.
[DRIP] Wendt、C。およびH. Bellur、「Distributed Registry Protocol（DRiP）」、Work in Progress、draft-wendt-modern-drip-02、2017年7月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC3375] Hollenbeck, S., "Generic Registry-Registrar Protocol Requirements", RFC 3375, DOI 10.17487/RFC3375, September 2002, <https://www.rfc-editor.org/info/rfc3375>.
[RFC3375] Hollenbeck、S。、「Generic Registry-Registrar Protocol Requirements」、RFC 3375、DOI 10.17487 / RFC3375、2002年9月、<https://www.rfc-editor.org/info/rfc3375>。
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, DOI 10.17487/RFC3912, September 2004, <https://www.rfc-editor.org/info/rfc3912>.
[RFC3912] Daigle、L。、「WHOIS Protocol Specification」、RFC 3912、DOI 10.17487 / RFC3912、2004年9月、<https://www.rfc-editor.org/info/rfc3912>。
[RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 6116, DOI 10.17487/RFC6116, March 2011, <https://www.rfc-editor.org/info/rfc6116>.
[RFC6116] Bradner、S.、Conroy、L。、およびK.藤原、「E.164からURI（Uniform Resource Identifiers）Dynamic Delegation Discovery System（DDDS）Application（ENUM）」、RFC 6116、DOI 10.17487 / RFC6116 、2011年3月、<https://www.rfc-editor.org/info/rfc6116>。
[RFC6140] Roach, A., "Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)", RFC 6140, DOI 10.17487/RFC6140, March 2011, <https://www.rfc-editor.org/info/rfc6140>.
[RFC6140] Roach、A。、「Registration for Multiple Phone Numbers in the Session Initiation Protocol（SIP）」、RFC 6140、DOI 10.17487 / RFC6140、2011年3月、<https://www.rfc-editor.org/info/ rfc6140>。
[RFC6461] Channabasappa, S., Ed., "Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS) Use Cases and Protocol Requirements", RFC 6461, DOI 10.17487/RFC6461, January 2012, <https://www.rfc-editor.org/info/rfc6461>.
[RFC6461] Channabasappa、S。、編、「Inter- / Intra-NetworK SIP（DRINKS）の使用例とプロトコル要件の到達可能性に関するデータ」、RFC 6461、DOI 10.17487 / RFC6461、2012年1月、<https：// www .rfc-editor.org / info / rfc6461>。
[RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access Protocol (RDAP) Query Format", RFC 7482, DOI 10.17487/RFC7482, March 2015, <https://www.rfc-editor.org/info/rfc7482>.
[RFC7482]ニュートンA.およびS.ホレンベック、「Registration Data Access Protocol（RDAP）Query Format」、RFC 7482、DOI 10.17487 / RFC7482、2015年3月、<https://www.rfc-editor.org/info/ rfc7482>。
[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity Credentials: Certificates", RFC 8226, DOI 10.17487/RFC8226, February 2018, <https://www.rfc-editor.org/info/rfc8226>.
[RFC8226] Peterson、J。およびS. Turner、「Secure Telephone Identity Credentials：Certificates」、RFC 8226、DOI 10.17487 / RFC8226、2018年2月、<https://www.rfc-editor.org/info/rfc8226>。
[TERI-INFO] Peterson, J., "An Architecture and Information Model for Telephone-Related Information (TeRI)", Work in Progress, draft-peterson-modern-teri-04, March 2018.
[TERI-INFO]ピーターソンJ.、「電話関連情報のアーキテクチャと情報モデル（TeRI）」、進行中の作業、draft-peterson-modern-teri-04、2018年3月。
Acknowledgments
謝辞
We would like to thank Henning Schulzrinne and Adam Roach for their contributions to this problem statement and framework; we would also like to thank Pierce Gorman for detailed comments.
この問題の声明と枠組みへの貢献について、ヘニングシュルズリンネとアダムローチに感謝します。また、詳細なコメントを提供してくれたPierce Gormanにも感謝します。
Authors' Addresses
著者のアドレス
Jon Peterson Neustar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 United States of America
Jon Peterson Neustar、Inc. 1800 Sutter St Suite 570 Concord、CA 94520アメリカ合衆国
Email: jon.peterson@neustar.biz
Tom McGarry
トム・マクギャリー
Email: tmcgarry6@gmail.com