[要約] RFC 8793は、情報中心ネットワーキング（ICN）の基本的な概念と、CCNxおよびNDNという2つの主要な実装について紹介する入門ドキュメントです。コンテンツ名に基づいたルーティング、内蔵キャッシュ、および署名付きデータパケットなどの、従来のIPネットワーキングとは異なる特徴を解説しています。次世代のネットワークアーキテクチャであるICNの可能性と利点を、技術コミュニティに広く周知することを目的としています。
Internet Research Task Force (IRTF) B. Wissingh
Request for Comments: 8793 TNO
Category: Informational C. Wood
ISSN: 2070-1721 University of California Irvine
A. Afanasyev
Florida International University
L. Zhang
UCLA
D. Oran
Network Systems Research & Design
C. Tschudin
University of Basel
June 2020
Information-Centric Networking (ICN): Content-Centric Networking (CCNx) and Named Data Networking (NDN) Terminology
RFC 8793 - 情報中心型ネットワーキング（ICN）：コンテンツ中心型ネットワーキング（CCNx）および名前付きデータネットワーキング（NDN）の用語
Abstract
概要
Information-Centric Networking (ICN) is a novel paradigm where network communications are accomplished by requesting named content instead of sending packets to destination addresses. Named Data Networking (NDN) and Content-Centric Networking (CCNx) are two prominent ICN architectures. This document provides an overview of the terminology and definitions that have been used in describing concepts in these two implementations of ICN. While there are other ICN architectures, they are not part of the NDN and CCNx concepts and as such are out of scope for this document. This document is a product of the Information-Centric Networking Research Group (ICNRG).
情報中心型ネットワーキング（ICN）は、宛先アドレスにパケットを送信するのではなく、名前付きコンテンツを要求することによってネットワーク通信が実現される新しいパラダイムです。 Named Data Networking（NDN）とContent-Centric Networking（CCNx）は、2つの有名なICNアーキテクチャです。このドキュメントでは、ICNのこれら2つの実装の概念を説明する際に使用されてきた用語と定義の概要を説明します。他のICNアーキテクチャもありますが、それらはNDNおよびCCNxの概念の一部ではないため、このドキュメントの範囲外です。この文書は、情報中心型ネットワーキング研究グループ（ICNRG）の製品です。
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 Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Information-Centric Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、Internet Research Task Force（IRTF）の製品です。 IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適さない可能性があります。このRFCは、インターネットリサーチタスクフォース（IRTF）の情報中心型ネットワーキングリサーチグループのコンセンサスを表しています。 IRSGによる公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc8793.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc8793で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction 2. A Sketch of the Big Picture of ICN 3. Terms by Category 3.1. Generic Terms 3.2. Terms Related to ICN Nodes 3.3. Terms Related to the Forwarding Plane 3.4. Terms Related to Packet Types 3.5. Terms Related to Name Types 3.6. Terms Related to Name Usage 3.7. Terms Related to Data-Centric Security 4. Semantics and Usage 4.1. Data Transfer 4.2. Data Transport 4.3. Lookup Service 4.4. Database Access 4.5. Remote Procedure Call 4.6. Publish/Subscribe 5. IANA Considerations 6. Security Considerations 7. References 7.1. Normative References 7.2. Informative References Acknowledgments Authors' Addresses
Information-centric networking (ICN) is an architecture to evolve the Internet infrastructure from the existing host-centric design to a data-centric architecture, where accessing data by name becomes the essential network primitive. The goal is to let applications refer to data independently of their location or means of transportation, which enables native multicast delivery, ubiquitous in-network caching, and replication of data objects.
情報中心のネットワーキング（ICN）は、インターネットインフラストラクチャを既存のホスト中心の設計からデータ中心のアーキテクチャに進化させるアーキテクチャであり、名前でデータにアクセスすることが重要なネットワークプリミティブになります。目標は、アプリケーションがその場所や移動手段とは無関係にデータを参照できるようにすることです。これにより、ネイティブマルチキャスト配信、ユビキタスネットワーク内キャッシング、およびデータオブジェクトのレプリケーションが可能になります。
As the work on this topic continues to evolve, many new terms are emerging. The goal of this document is to collect the key terms with a corresponding definition as they are used in the CCNx and NDN projects. Among the important documents for these projects are [RFC8569], [RFC8609], and [NDNTLV]. Other ICN projects such as [NETINF], [PSIRP], or [MOBILITY-FIRST] are not covered and may be the subject of other documents.
In this document, to help provide context for the individual defined terms, we first sketch the bigger picture of an ICN network by introducing the basic concepts and identifying the major components of the architecture in Section 2; after which, in Section 3, ICN-related terms are listed by different categories. Readers should be aware that in this organization, some terms may be used in other definitions before they themselves are defined.
このドキュメントでは、定義された個々の用語のコンテキストを提供するために、最初にセクション2で基本的な概念を紹介し、アーキテクチャの主要なコンポーネントを特定して、ICNネットワークの全体像を概説します。その後、セクション3では、ICN関連の用語がさまざまなカテゴリ別にリストされています。読者は、この組織では、一部の用語が定義される前に他の定義で使用される可能性があることに注意する必要があります。
While this terminology document describes both confidentiality and integrity-related terms, it should be noted that ICN architectures like NDN and CCNx generally do not provide data confidentiality, which is treated in these architectures as an application-layer concern.
この用語ドキュメントでは機密性と整合性関連の両方の用語について説明していますが、NDNやCCNxなどのICNアーキテクチャは一般にデータの機密性を提供しないため、これらのアーキテクチャではアプリケーション層の問題として扱われます。
This document represents the consensus of the Information-Centric Networking Research Group (ICNRG). It has been reviewed extensively by the Research Group (RG) members active in the specific areas of work covered by the document. It is not an IETF product and is not intended for standardization in the IETF.
このドキュメントは、情報中心のネットワーキング研究グループ（ICNRG）のコンセンサスを表しています。それは、文書でカバーされている特定の作業領域で活動している研究グループ（RG）メンバーによって広範囲にレビューされています。これはIETF製品ではなく、IETFでの標準化を目的としたものではありません。
In networking terms, an ICN is a delivery infrastructure for named data. For other complementing views, see Section 4.
ネットワーキングの用語では、ICNは名前付きデータの配信インフラストラクチャです。その他の補足的なビューについては、セクション4を参照してください。
requestor zero or more data sources or
(node) forwarding nodes replica nodes
| | ... | |...|
| Interest(n) | | Interest(n) | |
| --------------> | | ---------------> | |
| | | -------------------> |
| | | | |
| | | Data([n],c,[s]) | |
| | | <--------------- | |
| | | <------------------- |
| Data([n],c,[s]) | | | |
| <-------------- | | | |
Legend: n=name, c=content, s=signature
Figure 1: Request-Reply Protocol of ICN Networking.
図1：ICNネットワーキングの要求/応答プロトコル。
The following list describes the basic ICN concepts needed to discuss the implementation of this service abstraction.
次のリストは、このサービス抽象化の実装について説明するために必要なICNの基本概念を示しています。
*Request-Reply Protocol (Interest and Data Packet):*
An ICN's lookup service is implemented by defining two types of network packet formats: Interest packets that request content by name and Data packets that carry the requested content. The returned Data packet must match the request's parameters (e.g., having a partially or fully matching name). If the request is ambiguous and several Data packets would satisfy the request, the ICN network returns only one matching Data packet (thus achieving flow balance between Interest and Data packets over individual Layer 2 interfaces).
ICNの検索サービスは、2種類のネットワークパケット形式を定義することによって実装されます。名前でコンテンツを要求するインタレストパケットと、要求されたコンテンツを運ぶデータパケットです。返されたデータパケットは、リクエストのパラメータと一致している必要があります（たとえば、名前が部分的または完全に一致している）。要求があいまいで、複数のデータパケットが要求を満たす場合、ICNネットワークは一致するデータパケットを1つだけ返します（これにより、個々のレイヤー2インターフェイスでインタレストパケットとデータパケット間のフローバランスが達成されます）。
*Packet and Content Names:*
Without a strong cryptographic binding between the name of a Data packet and its content, Data packet names would be useless for fetching specific content. In ICN, verification of a Data packet's name-to-content binding is achieved through cryptographic means either by (1) a cryptographic signature that explicitly binds an application-chosen name to a Data packet's content or by (2) relying on an implicit name (cryptographic hash of the Data packet with or without application-chosen name) that the data consumer obtained through other means.
データパケットの名前とそのコンテンツの間に強力な暗号バインディングがない場合、データパケット名は特定のコンテンツを取得するのに役立ちません。 ICNでは、データパケットの名前からコンテンツへのバインディングの検証は、（1）アプリケーションで選択された名前をデータパケットのコンテンツに明示的にバインドする暗号署名によって、または（2）暗黙的な名前に依存することによって、暗号化手段によって実現されます。 （アプリケーションが選択した名前の有無にかかわらず、データパケットの暗号化ハッシュ）データコンシューマが他の手段で取得したもの。
*Data Authenticity and Encryption:*
Any data consumer or network element can (in principle) validate the authenticity of a Data packet by verifying its cryptographic name-to-content binding. Note that data authenticity is distinct from data trustworthiness, though the two concepts are related. A packet is authentic if it has a valid name-to-content binding, but it may still be unwise to "trust" the content for any particular purpose.
データコンシューマまたはネットワーク要素は、（原則として）暗号の名前とコンテンツのバインディングを検証することにより、データパケットの信頼性を検証できます。データの信頼性はデータの信頼性とは異なりますが、2つの概念は関連しています。パケットは、名前とコンテンツの有効なバインディングがあれば本物ですが、特定の目的のためにコンテンツを「信頼する」ことは賢明ではない場合があります。
*Trust:*
Data authenticity is distinct from data trustworthiness, though the two concepts are related. A packet is authentic if it has a valid name-to-content binding. A packet is trustworthy, i.e., it comes from a reputable or trusted origin, if this binding is valid in the context of a trust model. The trust model provides assurance that the name used for a given piece of content is appropriate for the value of the content. Section 6 discusses this further.
2つの概念は関連していますが、データの信頼性はデータの信頼性とは異なります。名前からコンテンツへの有効なバインディングがある場合、パケットは本物です。このバインディングが信頼モデルのコンテキストで有効である場合、パケットは信頼できます。つまり、信頼できる発信元から送信されます。信頼モデルは、特定のコンテンツに使用される名前がコンテンツの価値に適切であることを保証します。セクション6では、これについてさらに説明します。
*Segmenting and Versioning:*
An ICN network will be engineered for some packet size limit. As application-level data objects will often be considerably larger, objects must be segmented into multiple Data packets. The names for these Data packets can, for example, be constructed by choosing one application-level object name to which a different suffix is added for each segment. The same method can be used to handle different versions of an application-level object by including a version number in the name of the overall object.
ICNネットワークは、パケットサイズの制限に合わせて設計されます。アプリケーションレベルのデータオブジェクトはかなり大きくなることが多いため、オブジェクトを複数のデータパケットにセグメント化する必要があります。これらのデータパケットの名前は、たとえば、セグメントごとに異なるサフィックスが追加された1つのアプリケーションレベルのオブジェクト名を選択することで作成できます。オブジェクト全体の名前にバージョン番号を含めることで、同じメソッドを使用して、アプリケーションレベルのオブジェクトの異なるバージョンを処理できます。
*Packet and Frame:*
NDN and CCNx introduce Protocol Data Units (PDUs), which typically are larger than the maximum transmission unit of the underlying networking technology. We refer to PDUs as packets and the (potentially fragmented) packet parts that traverse MTU-bound Layer 2 interfaces as frames. Handling Layer 2 technologies that lead to fragmentation of ICN packets is done inside the ICN network and is not visible at the service interface.
NDNおよびCCNxはプロトコルデータユニット（PDU）を導入します。これは通常、基盤となるネットワーキングテクノロジーの最大伝送ユニットよりも大きくなります。 PDUをパケットと呼び、MTUにバインドされたレイヤー2インターフェイスを通過する（フラグメント化される可能性のある）パケット部分をフレームと呼びます。 ICNパケットの断片化につながるレイヤ2テクノロジーの処理は、ICNネットワーク内で行われ、サービスインターフェイスでは表示されません。
*ICN Node:*
A node within an ICN network can fulfill the role of a data producer, a data consumer, and/or a forwarder for Interest and Data packets. When a forwarder has connectivity to neighbor nodes, it performs Interest and Data packet forwarding in real time. It can also behave as a store and forward node carrying an Interest or Data packet for some time before forwarding it to the next node. An ICN node may also run routing protocols to assist its Interest forwarding decisions.
ICNネットワーク内のノードは、インタレストパケットおよびデータパケットのデータプロデューサー、データコンシューマー、および/またはフォワーダーの役割を果たすことができます。フォワーダーが隣接ノードに接続できる場合、フォワーダーはインタレストとデータパケットの転送をリアルタイムで実行します。また、インタレストパケットまたはデータパケットを次のノードに転送する前にしばらく転送するストアアンドフォワードノードとしても動作します。 ICNノードはルーティングプロトコルを実行して、インタレスト転送の決定を支援することもできます。
*Forwarding Plane:*
The canonical way of implementing packet forwarding in an ICN network relies on three data structures that capture a node's state: a Forwarding Interest Base (FIB), a Pending Interest Table (PIT), and a Content Store (CS). It also utilizes Interest forwarding strategies, which take input from both FIB and measurements to make Interest forwarding decisions. When a node receives an Interest packet, it checks its CS and PIT to find a matching entry; if no match is found, the node records the Interest in its PIT and forwards the Interest to the next hop(s) towards the requested content, based on the information in its FIB.
ICNネットワークでパケット転送を実装する標準的な方法は、ノードの状態をキャプチャする3つのデータ構造、つまりForwarding Interest Base（FIB）、Pending Interest Table（PIT）、およびContent Store（CS）に依存しています。また、FIBと測定の両方から入力を受け取り、インタレスト転送の決定を行うインタレスト転送戦略を利用します。ノードがインタレストパケットを受信すると、CSとPITをチェックして一致するエントリを見つけます。一致が見つからない場合、ノードはPITにインタレストを記録し、FIBの情報に基づいて、インタレストを要求されたコンテンツへの次のホップに転送します。
*Information-Centric Networking (ICN):*
A networking architecture that retrieves Data packets in response to Interest packets. Content-Centric Networking (CCNx 1.x) and Named Data Networking (NDN) are two realizations (designs) of an ICN architecture.
インタレストパケットに応答してデータパケットを取得するネットワークアーキテクチャ。 Content-Centric Networking（CCNx 1.x）とNamed Data Networking（NDN）は、ICNアーキテクチャの2つの実現（設計）です。
*Data Packet Immutability:*
After a Data packet is created, the cryptographic signature binding the name to the content ensures that if either the content or the name changes, that change will be detected and the packet discarded. If the content carried in a Data packet is intended to be mutable, versioning of the name should be used so that each version uniquely identifies an immutable instance of the content. This allows disambiguation of various versions of content such that coordination among the various instances in a distributed system can be achieved.
データパケットが作成された後、名前をコンテンツにバインドする暗号化署名により、コンテンツまたは名前のいずれかが変更された場合、その変更が検出され、パケットが破棄されます。データパケットで運ばれるコンテンツが変更可能であることが意図されている場合、名前のバージョン管理を使用して、各バージョンがコンテンツの不変のインスタンスを一意に識別できるようにする必要があります。これにより、コンテンツのさまざまなバージョンの明確化が可能になり、分散システムのさまざまなインスタンス間の調整を実現できます。
*ICN Interface:*
A generalization of the network interface that can represent a physical network interface (ethernet, Wi-Fi, bluetooth adapter, etc.), an overlay inter-node channel (IP/UDP tunnel, etc.), or an intra-node inter-process communication (IPC) channel to an application (unix socket, shared memory, intents, etc.).
物理ネットワークインターフェイス（イーサネット、Wi-Fi、Bluetoothアダプターなど）、オーバーレイノード間チャネル（IP/UDPトンネルなど）、またはノード内ノードを表すことができるネットワークインターフェイスの一般化アプリケーションへのプロセス通信（IPC）チャネル（UNIXソケット、共有メモリ、インテントなど）。
Common aliases include: face.
一般的なエイリアスには、顔があります。
*ICN Consumer:*
An ICN entity that requests Data packets by generating and sending out Interest packets towards local (using intra-node interfaces) or remote (using inter-node interfaces) ICN Forwarders.
インタレストパケットを生成してローカル（ノード内インターフェイスを使用）またはリモート（ノード間インターフェイスを使用）のICNフォワーダーに向けて送信することにより、データパケットを要求するICNエンティティ。
Common aliases include: consumer, information consumer, data consumer, consumer of the content.
一般的なエイリアスには、コンシューマー、情報コンシューマー、データコンシューマー、コンテンツのコンシューマーが含まれます。
*ICN Producer:*
An ICN entity that creates Data packets and makes them available for retrieval.
データパケットを作成し、それらを取得できるようにするICNエンティティ。
Common aliases include: producer, publisher, information publisher, data publisher, data producer.
一般的なエイリアスには、プロデューサー、パブリッシャー、情報パブリッシャー、データパブリッシャー、データプロデューサーがあります。
*ICN Forwarder:*
An ICN entity that implements stateful forwarding.
ステートフル転送を実装するICNエンティティ。
Common aliases include: ICN router.
一般的なエイリアスは次のとおりです。ICNルーター。
*ICN Data Node:*
An ICN entity that temporarily stores and potentially carries an Interest or Data packet before forwarding it to next ICN entity. Note that such ICN data nodes do not have all the properties of data nodes as employed in the Delay Tolerant Networking (DTN) [RFC4838] specifications.
インタレストパケットまたはデータパケットを一時的に保存し、次のICNエンティティに転送する前に運ぶ可能性のあるICNエンティティ。そのようなICNデータノードは、Delay Tolerant Networking（DTN）[RFC4838]仕様で採用されているデータノードのすべてのプロパティを持つわけではないことに注意してください。
*Stateful Forwarding:*
A forwarding process that records incoming Interest packets in the PIT and uses the recorded information to forward the retrieved Data packets back to the consumer(s). The recorded information can also be used to measure data-plane performance, e.g., to adjust interest forwarding-strategy decisions.
着信インタレストパケットをPITに記録し、記録された情報を使用して、取得したデータパケットをコンシューマに転送する転送プロセス。記録された情報は、データプレーンのパフォーマンスを測定するために、たとえばインタレスト転送戦略の決定を調整するためにも使用できます。
Common aliases include: ICN Data plane, ICN Forwarding.
一般的なエイリアスには、ICNデータプレーン、ICN転送があります。
*Forwarding Strategy:*
A module of the ICN stateful forwarding (ICN data) plane that implements a decision on where/how to forward the incoming Interest packet. The forwarding strategy can take input from the Forwarding Information Base (FIB), measured data-plane performance parameters, and/or use other mechanisms to make the decision.
着信インタレストパケットの転送先/転送方法の決定を実装するICNステートフル転送（ICNデータ）プレーンのモジュール。転送戦略は、転送情報ベース（FIB）、測定されたデータプレーンパフォーマンスパラメータから入力を受け取り、他のメカニズムを使用して決定を下すことができます。
Common aliases include: Interest forwarding strategy.
一般的なエイリアスは次のとおりです。インタレスト転送戦略。
*Upstream (forwarding):*
Forwarding packets in the direction of Interests (i.e., Interests are forwarded upstream): consumer, router, router, ..., producer.
インタレストの方向にパケットを転送する（つまり、インタレストはアップストリームに転送されます）：コンシューマー、ルーター、ルーター、...、プロデューサー。
*Downstream (forwarding):*
Forwarding packets in the opposite direction of Interest forwarding (i.e., Data and Interest Nacks are forwarded downstream): producer, router, ..., consumer(s).
インタレスト転送の反対方向にパケットを転送します（つまり、データとインタレストのNackがダウンストリームに転送されます）：プロデューサー、ルーター、...、コンシューマー。
*Interest Forwarding:*
A process of forwarding Interest packets using the Names carried in the Interests. In case of stateful forwarding, this also involves creating an entry in the PIT. The forwarding decision is made by the Forwarding Strategy.
Interestsで運ばれる名前を使用してInterestパケットを転送するプロセス。ステートフル転送の場合、これにはPITでのエントリの作成も含まれます。転送の決定は転送戦略によって行われます。
*Interest Aggregation:*
A process of combining multiple Interest packets with the same Name and additional restrictions for the same Data into a single PIT entry.
同じ名前を持つ複数のInterestパケットと、同じデータに対する追加の制限を1つのPITエントリに結合するプロセス。
Common aliases include: Interest collapsing.
一般的なエイリアスには、次のものがあります。
*Data Forwarding:*
A process of forwarding the incoming Data packet to the interface(s) recorded in the corresponding PIT entry (entries) and removing the corresponding PIT entry (entries).
着信データパケットを対応するPITエントリ（エントリ）に記録されたインターフェイスに転送し、対応するPITエントリ（エントリ）を削除するプロセス。
*Satisfying an Interest:*
An overall process of returning content that satisfies the constraints imposed by the Interest, most notably a match in the provided Name.
インタレストによって課された制約を満たすコンテンツを返す全体的なプロセス。最も顕著なのは、指定された名前の一致です。
*Interest Match in FIB (longest prefix match):*
A process of finding a FIB entry with the longest Name (in terms of Name components) that is a prefix of the specified Name. See Section 3.5 for terms related to name prefixes.
指定された名前の接頭辞である（名前コンポーネントの観点から）最長の名前を持つFIBエントリを見つけるプロセス。名前の接頭辞に関連する用語については、セクション3.5を参照してください。
*Interest Match in PIT (exact match):*
A process of finding a PIT entry that stores the same Name as specified in the Interest (including Interest restrictions, if any).
インタレスト（指定されている場合はインタレスト制限を含む）で指定されたものと同じ名前を格納するPITエントリを見つけるプロセス。
*Data Match in PIT (all match):*
A process of finding (a set of) PIT entries that can be satisfied with the specified Data packet.
指定されたデータパケットで満たすことができるPITエントリ（のセット）を見つけるプロセス。
*Interest Match in CS (any match):*
A process of finding an entry in a router's Content Store that can satisfy the specified Interest.
指定されたインタレストを満たすことができるルーターのコンテンツストア内のエントリを見つけるプロセス。
*Pending Interest Table (PIT):*
A database that records received and not-yet-satisfied Interests with the interfaces from where they were received. The PIT can also store interfaces to where Interests were forwarded, and information to assess data-plane performance. Interests for the same Data are aggregated into a single PIT entry.
受信されたインタレストと、まだ満たされていないインタレストを、それらが受信された場所からのインターフェースで記録するデータベース。 PITには、インタレストが転送された場所へのインターフェイス、およびデータプレーンのパフォーマンスを評価するための情報も格納できます。同じデータのインタレストは1つのPITエントリに集約されます。
*Forwarding Information Base (FIB):*
A database that contains a set of prefixes, each prefix associated with one or more faces that can be used to retrieve Data packets with Names under the corresponding prefix. The list of faces for each prefix can be ranked, and each face may be associated with additional information to facilitate forwarding-strategy decisions.
プレフィックスのセットを含むデータベース。各プレフィックスは、対応するプレフィックスの下の名前を持つデータパケットを取得するために使用できる1つ以上の面に関連付けられています。各プレフィックスの顔のリストにランクを付けることができ、各顔を転送情報の決定を容易にするために追加情報に関連付けることができます。
*Content Store (CS):*
A database in an ICN router that provides caching.
キャッシングを提供するICNルーター内のデータベース。
*In-Network Storage:*
An optional process of storing a Data packet within the network (opportunistic caches, dedicated on/off path caches, and managed in-network storage systems), so it can satisfy an incoming Interest for this Data packet. The in-network storages can optionally advertise the stored Data packets in the routing plane.
データパケットをネットワーク内に保存するオプションのプロセス（便宜的キャッシュ、専用のオン/オフパスキャッシュ、および管理されたネットワーク内ストレージシステム）。これにより、このデータパケットの着信インタレストを満たすことができます。ネットワーク内ストレージは、オプションで、ルーティングプレーンに格納されたデータパケットをアドバタイズできます。
*Opportunistic Caching:*
A process of temporarily storing a forwarded Data packet in the router's memory (RAM or disk), so it can be used to satisfy future Interests for the same Data, if any.
転送されたデータパケットをルーターのメモリ（RAMまたはディスク）に一時的に格納するプロセス。これにより、同じデータに対する将来の関心があれば、それを満たすために使用できます。
Common aliases include: on-path in-network caching.
一般的なエイリアスには、パス上のネットワーク内キャッシュがあります。
*Managed Caching:*
The process of achieving the temporary, permanent, or scheduled storage of a selected (set of) Data packet(s).
選択された（セットの）データパケットの一時的、永続的、またはスケジュールされたストレージを実現するプロセス。
Common aliases include: off-path in-network storage.
一般的なエイリアスには、オフパスのネットワーク内ストレージがあります。
*Managed In-Network Storage:*
An entity acting as an ICN publisher that implements managed caching.
マネージドキャッシュを実装するICNパブリッシャーとして機能するエンティティ。
Common aliases include: repository, repo.
一般的なエイリアスには、リポジトリ、リポジトリなどがあります。
*ICN Routing Plane:*
An ICN protocol or a set of ICN protocols to exchange information about Name space reachability.
名前空間の到達可能性に関する情報を交換するためのICNプロトコルまたは一連のICNプロトコル。
*ICN Routing Information Base (RIB):*
A database that contains a set of prefix-face mappings that are produced by running one or multiple routing protocols. The RIB is used to populate the FIB.
1つまたは複数のルーティングプロトコルを実行することによって生成される一連のプレフィックス面マッピングを含むデータベース。 RIBは、FIBへの入力に使用されます。
*Interest Packet:*
A network-level packet that expresses the request for a Data packet using either an exact name or a name prefix. An Interest packet may optionally carry a set of additional restrictions (e.g., Interest selectors). An Interest may be associated with additional information to facilitate forwarding and can include Interest lifetime, hop limit, forwarding hints, labels, etc. In different ICN designs, the set of additional associated information may vary.
正確な名前または名前プレフィックスのいずれかを使用して、データパケットの要求を表すネットワークレベルのパケット。インタレストパケットは、オプションで一連の追加制限（インタレストセレクタなど）を運ぶことができます。インタレストは、転送を容易にするために追加情報に関連付けることができ、インタレストライフタイム、ホップリミット、転送ヒント、ラベルなどを含めることができます。ICNの設計によっては、追加の関連情報のセットが異なる場合があります。
Common aliases include: Interest, Interest message, information request.
一般的なエイリアスには、インタレスト、インタレストメッセージ、情報リクエストがあります。
*Interest Nack:*
A packet that contains the Interest packet and optional annotation, which is sent by the ICN router to the interface(s) the Interest was received from. An Interest Nack is used to inform downstream ICN nodes about the inability to forward the included Interest packet. The annotation can describe the reason.
Interestパケットとオプションの注釈を含むパケット。ICNルーターによって、Interestの受信元のインターフェイスに送信されます。 Interest Nackは、含まれるInterestパケットを転送できないことを下流のICNノードに通知するために使用されます。注釈は理由を説明できます。
Common aliases include: network NACK, Interest return.
一般的なエイリアスには、ネットワークNACK、インタレストリターンがあります。
*Data Packet:*
A network-level packet that carries payload, uniquely identified by a name, that is directly secured through cryptographic signature mechanisms.
名前によって一意に識別されるペイロードを運ぶネットワークレベルのパケット。暗号化署名メカニズムによって直接保護されます。
Common aliases include: data, data object, content object, content object packet, data message, named data object, named data.
一般的なエイリアスには、データ、データオブジェクト、コンテンツオブジェクト、コンテンツオブジェクトパケット、データメッセージ、名前付きデータオブジェクト、名前付きデータが含まれます。
*Link:*
A type of Data packet whose body contains the Name of another Data packet. This inner Name is often a Full Name, i.e., it specifies the Packet ID of the corresponding Data packet, but this is not a requirement.
本体に別のデータパケットの名前が含まれるデータパケットのタイプ。多くの場合、この内部名はフルネームです。つまり、対応するデータパケットのパケットIDを指定しますが、これは必須ではありません。
Common aliases include: pointer.
一般的なエイリアスには、ポインタがあります。
*Manifest:*
A type of Data packet that contains Full Name Links to one or more Data Packets. Manifests group collections of related Data packets under a single Name. Manifests allow both large Data objects to be conveniently split into individual Content Objects under one name, and to represent sets of related Content Objects as a form of "directory". Manifests have the additional benefit of amortizing the signature verification cost for each Data packet referenced by the inner Links. Manifests typically contain additional metadata, e.g., the size (in bytes) of each linked Data packet and the cryptographic hash digest of all Data contained in the linked Data packets.
1つ以上のデータパケットへのフルネームリンクを含むデータパケットのタイプ。マニフェストは、関連するデータパケットのコレクションを単一の名前でグループ化します。マニフェストを使用すると、両方の大きなデータオブジェクトを1つの名前で個々のコンテンツオブジェクトに簡単に分割し、関連するコンテンツオブジェクトのセットを「ディレクトリ」の形式で表すことができます。マニフェストには、内部リンクによって参照される各データパケットの署名検証コストを償却するという追加の利点があります。マニフェストには通常、追加のメタデータが含まれます。たとえば、リンクされた各データパケットのサイズ（バイト単位）や、リンクされたデータパケットに含まれるすべてのデータの暗号化ハッシュダイジェストなどです。
*Name:*
A Data packet identifier. An ICN name is hierarchical (a sequence of name components) and usually is semantically meaningful, making it expressive, flexible, and application-specific (akin to an HTTP URL). A Name may encode information about application context, semantics, locations (topological, geographical, hyperbolic, etc.), a service name, etc.
データパケット識別子。 ICN名は階層的（名前コンポーネントのシーケンス）であり、通常は意味的に意味があり、表現力があり、柔軟性があり、アプリケーション固有（HTTP URLと同様）になります。 Nameは、アプリケーションコンテキスト、セマンティクス、場所（トポロジー、地理、双曲線など）、サービス名などに関する情報をエンコードします。
Common aliases include: data name, interest name, content name.
一般的なエイリアスには、データ名、インタレスト名、コンテンツ名が含まれます。
*Name component:*
A sequence of bytes and optionally a numeric type representing a single label in the hierarchical structured name.
一連のバイトと、オプションで、階層構造名の単一のラベルを表す数値型。
Common aliases include: name segment (as in CCNx).
一般的なエイリアスには、名前セグメント（CCNxなど）が含まれます。
*Packet ID:*
A unique cryptographic identifier for a Data packet. Typically, this is a cryptographic hash digest of a Data packet (such as SHA256 [RFC6234]), including its name, payload, meta information, and signature.
データパケットの一意の暗号識別子。通常、これはデータパケットの暗号化ハッシュダイジェスト（SHA256 [RFC6234]など）で、名前、ペイロード、メタ情報、署名が含まれています。
Common aliases include: implicit digest.
一般的なエイリアスには、暗黙のダイジェストが含まれます。
*Selector:*
A mechanism (condition) to select an individual Data packet from a collection of Data packets that match a given Interest that requests data using a prefix or exact Name.
プレフィックスまたは正確な名前を使用してデータを要求する特定のインタレストに一致するデータパケットのコレクションから個々のデータパケットを選択するメカニズム（条件）。
Common aliases include: interest selector, restrictor, interest restrictor.
一般的なエイリアスには、インタレストセレクター、リストリクター、インタレストリストリクターがあります。
*Nonce:*
A field of an Interest packet that transiently names an Interest instance (instance of Interest for a given name). Note: the specifications defining nonces in NDN do not necessarily satisfy all the properties of nonces as discussed in [RFC4949].
Interestインスタンス（特定の名前のInterestのインスタンス）に一時的に名前を付けるInterestパケットのフィールド。注：NDNでノンスを定義する仕様は、[RFC4949]で説明されているように、ノンスのすべてのプロパティを必ずしも満たすわけではありません。
*Exact Name:*
A Name that is encoded inside a Data packet and that typically uniquely identifies this Data packet.
データパケット内でエンコードされ、通常はこのデータパケットを一意に識別する名前。
*Full Name:*
An exact Name with the Packet ID of the corresponding Data packet.
対応するデータパケットのパケットIDを含む正確な名前。
*Prefix Name:*
A Name that includes a partial sequence of Name components (starting from the first one) of a Name encoded inside a Data packet.
データパケット内にエンコードされた名前の名前コンポーネントのシーケンス（最初のコンポーネントから開始）を含む名前。
Common aliases include: prefix.
一般的なエイリアスには次のものがあります。
*Naming conventions:*
A convention, agreement, or specification for the Data packet naming. a Naming convention structures a namespace.
データパケットの命名規則、合意、または仕様。命名規則は名前空間を構成します。
Common aliases include: Naming scheme, ICN naming scheme, namespace convention.
一般的なエイリアスには、命名スキーム、ICN命名スキーム、名前空間規則があります。
*Hierarchically structured naming:*
The naming scheme that assigns and interprets a Name as a sequence of labels (Name components) with hierarchical structure without an assumption of a single administrative root. A structure provides useful context information for the Name.
単一の管理ルートを前提とせずに、名前を階層構造を持つ一連のラベル（名前コンポーネント）として割り当て、解釈する命名スキーム。構造は、名前に役立つコンテキスト情報を提供します。
Common aliases include: hierarchical naming, structured naming.
一般的なエイリアスには、階層的な命名、構造化された命名があります。
*Flat naming:*
The naming scheme that assigns and interprets a Name as a single label (Name component) without any internal structure. This can be considered a special (or degenerate) case of structured names.
Nameを内部構造のない単一のラベル（Nameコンポーネント）として割り当て、解釈する命名スキーム。これは、構造化された名前の特別な（または縮退した）ケースと考えることができます。
*Segmentation:*
A process of splitting large application content into a set of uniquely named Data packets. When using hierarchically structured names, each created Data packet has a common prefix and an additional component representing the segment (chunk) number.
大きなアプリケーションコンテンツを一意の名前が付けられた一連のデータパケットに分割するプロセス。階層構造の名前を使用する場合、作成された各データパケットには、共通のプレフィックスと、セグメント（チャンク）番号を表す追加のコンポーネントがあります。
Common aliases include: chunking.
一般的なエイリアスには、チャンクがあります。
*Versioning:*
A process of assigning a unique Name to the revision of the content carried in the Data packet. When using a hierarchically structured Name, the version of the Data packet can be carried in a dedicated Name component (e.g., prefix identifies data, unique version component identifies the revision of the data).
データパケットで伝送されるコンテンツのリビジョンに一意の名前を割り当てるプロセス。階層構造の名前を使用する場合、データパケットのバージョンを専用の名前コンポーネントで伝達できます（たとえば、プレフィックスはデータを識別し、一意のバージョンコンポーネントはデータのリビジョンを識別します）。
*Fragmentation:*
A process of splitting PDUs into Frames so that they can be transmitted over a Layer 2 interface with a smaller MTU size.
PDUをフレームに分割して、MTUサイズの小さいレイヤ2インターフェイスで送信できるようにするプロセス。
*Data-Centric Security:*
A security property associated with the Data packet, including data (Data-Centric) integrity, authenticity, and optionally confidentiality. These security properties stay with the Data packet regardless of where it is stored and how it is retrieved.
データ（データセントリック）の整合性、信頼性、オプションで機密性など、データパケットに関連付けられたセキュリティプロパティ。これらのセキュリティプロパティは、データの保存場所や取得方法に関係なく、データパケットに残ります。
Common aliases include: directly securing Data packet.
一般的なエイリアスには、データパケットを直接保護することが含まれます。
*Data Integrity*
*データの整合性*
A cryptographic mechanism to ensure the consistency of the Data packet bits. The Data integrity property validates that the Data packet content has not been corrupted during transmission, e.g., over lossy or otherwise unreliable paths, or been subject to deliberate modification.
データパケットビットの一貫性を保証する暗号化メカニズム。データ整合性プロパティは、データパケットのコンテンツが伝送中に破損していないことを検証します。
*Data Authenticity*
*データの信頼性*
A cryptographic mechanism to ensure trustworthiness of a Data packet based on a selected (e.g., by a consumer/producer) trust model. Typically, data authenticity is assured through the use of asymmetric cryptographic signatures (e.g., RSA, ECDSA) but can also be realized using symmetric signatures (e.g., Hashed Message Authentication Code (HMAC)) within trusted domains.
選択された（たとえば、コンシューマ/プロデューサによって）信頼モデルに基づいてデータパケットの信頼性を保証する暗号化メカニズム。通常、データの信頼性は非対称暗号署名（RSA、ECDSAなど）を使用して保証されますが、信頼できるドメイン内で対称署名（ハッシュメッセージ認証コード（HMAC）など）を使用して実現することもできます。
*Data Confidentiality*
*データの機密性*
A cryptographic mechanism to ensure secrecy of a Data packet. Data confidentiality includes separate mechanisms: Content confidentiality and Name confidentiality.
データパケットの機密性を保証する暗号化メカニズム。データの機密性には、コンテンツの機密性と名前の機密性という別個のメカニズムが含まれます。
*Content Confidentiality*
*コンテンツの機密性*
A cryptographic mechanism to prevent an unauthorized party to get access to the plain-text payload of a Data packet. Can be realized through encryption (symmetric, asymmetric, hybrid) and proper distribution of the decryption keys to authorized parties.
無許可のパーティがデータパケットの平文ペイロードにアクセスするのを防ぐための暗号メカニズム。暗号化（対称、非対称、ハイブリッド）および許可された関係者への復号化キーの適切な配布を通じて実現できます。
*Name Confidentiality*
*名前の機密性*
A cryptographic mechanism to prevent an observer of Interest-Data exchanges (e.g., intermediate router) from gaining detailed meta information about the Data packet. This mechanism can be realized using encryption (same as content confidentiality) or obfuscation mechanisms.
Interest-Data交換のオブザーバー（中間ルーターなど）がDataパケットに関する詳細なメタ情報を取得しないようにする暗号化メカニズム。このメカニズムは、暗号化（コンテンツの機密性と同じ）または難読化メカニズムを使用して実現できます。
The terminology described above is the manifestation of intended semantics of NDN and CCNx operations (What do we expect the network to do?). In this section, we summarize the most commonly proposed use cases and interpretations.
上記の用語は、NDNおよびCCNx操作の意図されたセマンティクスの明示です（ネットワークが何を期待するか）。このセクションでは、最も一般的に提案されている使用例と解釈を要約します。
The networking view of NDN and CCNx is that the request/reply protocol implements a basic, unreliable data transfer service for single, named packets.
NDNとCCNxのネットワーキングビューでは、要求/応答プロトコルは、単一の名前付きパケット用の基本的で信頼性の低いデータ転送サービスを実装しています。
Data transfer can be turned into a data transport service for application-level objects by additional logic. This transport logic must understand and construct the series of names needed to reassemble the segmented object. Various flavors of transport can be envisaged (reliable, streaming, mailbox, etc.).
追加のロジックにより、データ転送をアプリケーションレベルのオブジェクトのデータ転送サービスに変えることができます。このトランスポートロジックは、セグメント化されたオブジェクトを再構成するために必要な一連の名前を理解および構築する必要があります。さまざまな種類のトランスポートを想定できます（信頼性、ストリーミング、メールボックスなど）。
In a more distributed systems view of the basic request/reply protocol, NDN and CCNx provide a distributed lookup service: given a key value (=name), the service will return the corresponding value.
基本的な要求/応答プロトコルのより分散したシステムビューでは、NDNとCCNxが分散ルックアップサービスを提供します。キー値（= name）が指定されると、サービスは対応する値を返します。
A lookup service can be turned into a database access protocol by using the namespace structure to specify names as access keys into a database. Therefore, a name prefix stands for a collection or table of a database, while the rest of the name specifies the query expression to be executed.
ネームスペース構造を使用して名前をデータベースへのアクセスキーとして指定することにより、検索サービスをデータベースアクセスプロトコルに変えることができます。したがって、名前のプレフィックスはデータベースのコレクションまたはテーブルを表し、残りの名前は実行されるクエリ式を指定します。
The names as defined in this document for Interests and Data can refer to Remote Procedure call functions, their input arguments, and their results. For a comprehensive view of how to construct RPC or other remote invocation systems, see the Association for Computing Machinery (ACM) ICN paper on [RICE]. These capabilities can be further extended into a full distributed computing infrastructure such as that proposed in the ACM ICN paper [CFN].
このドキュメントでインタレストとデータについて定義されている名前は、リモートプロシージャコール関数、その入力引数、およびその結果を参照できます。 RPCまたはその他のリモート呼び出しシステムを構築する方法の包括的なビューについては、[RICE]に関するAssociation for Computing Machinery（ACM）ICNペーパーを参照してください。これらの機能は、ACM ICNペーパー[CFN]で提案されているような完全な分散コンピューティングインフラストラクチャにさらに拡張できます。
The names as defined in this document for Interests and Data can refer to data collections to be subscribed and individual data objects to be published in a Publish-Subscribe application architecture. For a fully worked example of how to construct such an ICN-based system, see the ACM ICN paper [LESSONS-LEARNED].
このドキュメントでインタレストとデータについて定義されている名前は、サブスクライブされるデータコレクションと、パブリッシュ/サブスクライブアプリケーションアーキテクチャでパブリッシュされる個々のデータオブジェクトを指します。そのようなICNベースのシステムを構築する方法の完全に機能する例については、ACM ICNペーパー[LESSONS-LEARNED]を参照してください。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
While the terms defined in this specification do not in and of themselves present new security considerations, the architectures that utilize the terms most certainly do. Readers should look at those specifications (e.g., [RFC8569] and [NDN]) where various security considerations are addressed in detail.
この仕様で定義されている用語自体には新しいセキュリティの考慮事項はありませんが、これらの用語を使用するアーキテクチャでは最も確実に考慮されます。読者は、さまざまなセキュリティの考慮事項が詳細に説明されている仕様（[RFC8569]や[NDN]など）を確認する必要があります。
Some of the terms in this document use the words "trust", "trustworthy", or "trust model". We intend that these have their colloquial meanings; however, much work on trust, and specifically on trust schemas for ICN architectures, has been published in the last few years. For example, it is useful to look at [SCHEMATIZING-TRUST] for more information on the approaches taken to formalize notions of trust for current NDN and CCNx systems.
このドキュメントの一部の用語では、「信頼」、「信頼できる」、または「信頼モデル」という言葉を使用しています。私たちはこれらが口語的な意味を持つことを意図しています。ただし、信頼、特にICNアーキテクチャの信頼スキーマに関する多くの研究が過去数年で発表されています。たとえば、現在のNDNおよびCCNxシステムの信頼の概念を公式化するために採用されたアプローチの詳細については、[SCHEMATIZING-TRUST]を参照すると便利です。
[CFN] Krol, M., Mastorakis, S., Kutscher, D., and D. Oran, "Compute First Networking: Distributed Computing meets ICN", ACM ICN, DOI 10.1145/3357150.3357395, September 2019, <https://dl.acm.org/citation.cfm?id=3357395>.
[CFN] Krol, M., Mastorakis, S., Kutscher, D., and D. Oran、「Compute First Networking：Distributed Computing meets ICN」、ACM ICN、DOI 10.1145/3357150.3357395、2019年9月、<https://dl.acm.org/citation.cfm?id=3357395>。
[LESSONS-LEARNED] Nichols, K., "Lessons Learned Building a Secure Network Measurement Framework using Basic NDN", ACM ICN, DOI 10.1145/3357150.3357397, September 2019, <https://dl.acm.org/citation.cfm?id=3357397>.
[LESSONS-LEARNED] Nichols, K.、「Lessons Learned a Secure Network Measurement Framework using Basic NDN」、ACM ICN、DOI 10.1145/3357150.3357397、2019年9月、<https://dl.acm.org/citation.cfm?id=3357397>。
[MOBILITY-FIRST] Raychaudhuri, D., Nagaraja, K., and A. Venkataramani, "MobilityFirst: a robust and trustworthy mobility-centric architecture for the future internet", ACM SIGMOBILE, Volume 16, Issue 3, DOI 10.1145/2412096.2412098, July 2012, <https://dl.acm.org/citation.cfm?id=2412098>.
[MOBILITY-FIRST] Raychaudhuri, D., Nagaraja, K., and A. Venkataramani、「MobilityFirst：堅牢で信頼できるモビリティ中心のアーキテクチャ、未来のインターネット」、ACM SIGMOBILE、第16巻、第3号、DOI 10.1145/2412096.2412098 、2012年7月、<https://dl.acm.org/citation.cfm?id=2412098>。
[NDNTLV] Named Data Networking, "NDN Packet Format Specification", <https://named-data.net/doc/ndn-tlv/>.
[NDNTLV] Named Data Networking、「NDN Packet Format Specification」、<https://named-data.net/doc/ndn-tlv/>。
[NETINF] Dannewitz, C., Kutscher, D., Ohlman, B., Farrell, S., Ahlgren, B., and K. Holger, "Network of Information (NetInf) - An information-centric networking architecture", Computer Communications, Volume 36, Issue 7, DOI 10.1016/j.comcom.2013.01.009, April 2013, <https://dl.acm.org/citation.cfm?id=2459643>.
[NETINF] Dannewitz, C., Kutscher, D., Ohlman, B., Farrell, S., Ahlgren, B., and K. Holger, "Network of Information（NetInf）-an information-centric networking architecture"、Computer Communications、Volume 36、Issue 7、DOI 10.1016/j.comcom.2013.01.009、2013年4月、<https://dl.acm.org/citation.cfm?id=2459643>。
[PSIRP] Trossen, D., Tuononen, J., Xylomenos, G., Sarela, M., Zahemszky, A., Nikander, P., and T. Rinta-aho, "From Design for Tussle to Tussle Networking: PSIRP Vision and Use Cases", May 2008, <http://www.psirp.org/files/Deliverables/PSIRP-TR08-0001_Vision.pdf>.
[PSIRP] Trossen, D., Tuononen, J., Xylomenos, G., Sarela, M., Zahemszky, A., Nikander, P., and T. Rinta-aho、「Tussle for Design for Tussle Networking：PSIRPビジョンと使用例」、2008年5月、<http://www.psirp.org/files/Deliverables/PSIRP-TR08-0001_Vision.pdf>。
[RICE] Krol, M., Habak, K., Kutscher, D., Oran, D., and I. Psaras, "RICE: remote method invocation in ICN", ACM ICN, DOI 10.1145/3267955.3267956, September 2018, <https://dx.doi.org/10.1145/3267955.3267956>.
[RICE] Krol, M., Habak, K., Kutscher, D., Oran, D., and I. Psaras、「RICE：remote method invocation in ICN」、ACM ICN、DOI 10.1145/3267955.3267956、2018年9月、<https://dx.doi.org/10.1145/3267955.3267956>。
[SCHEMATIZING-TRUST] Yu, Y., Afanasyev, A., Clark, D., Claffy, K. C., Jacobson, V., and L. Zhang, "Schematizing Trust in Named Data Networking", ACM ICN, DOI 0.1145/2810156.2810170, September 2015, <https://dx.doi.org/10.1145/2810156.2810170>.
[SCHEMATIZING-TRUST] Yu, Y., Afanasyev, A., Clark, D., Claffy, K. C., Jacobson, V., and L. Zhang、「名前付きデータネットワーキングにおける信頼の体系化」、ACM ICN、DOI 0.1145/2810156.2810170 、2015年9月、<https://dx.doi.org/10.1145/2810156.2810170>。
[NDN] Named Data Networking, "Named Data Networking: Executive Summary", September 2010, <https://named-data.net/project/execsummary/>.
[NDN] Named Data Networking、「Named Data Networking：Executive Summary」、2010年9月、<https://named-data.net/project/execsummary/>。
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, April 2007, <https://www.rfc-editor.org/info/rfc4838>.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss、「Delay-Tolerant Networking Architecture」 、RFC 4838、DOI 10.17487/RFC4838、2007年4月、<https://www.rfc-editor.org/info/rfc4838>。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <https://www.rfc-editor.org/info/rfc4949>.
[RFC4949] Shirey, R.、「インターネットセキュリティ用語集、バージョン2」、FYI 36、RFC 4949、DOI 10.17487/RFC4949、2007年8月、<https://www.rfc-editor.org/info/rfc4949>。
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>.
[RFC6234] Eastlake 3rd, D. and T. Hansen、「US セキュアハッシュアルゴリズムs（SHA and SHA-based HMAC and HKDF）」、RFC 6234、DOI 10.17487/RFC6234、2011年5月、<https://www.rfc-editor.org/info/rfc6234>。
[RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Semantics", RFC 8569, DOI 10.17487/RFC8569, July 2019, <https://www.rfc-editor.org/info/rfc8569>.
[RFC8569] Mosko, M., Solis, I., and C. Wood、「Content-Centric Networking（CCNx）Semantics」、RFC 8569、DOI 10.17487/RFC8569、2019年7月、<https://www.rfc-editor.org/info/rfc8569>。
[RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Messages in TLV Format", RFC 8609, DOI 10.17487/RFC8609, July 2019, <https://www.rfc-editor.org/info/rfc8609>.
[RFC8609] Mosko, M., Solis, I., and C. Wood、「TLV形式のContent-Centric Networking（CCNx）メッセージ」、RFC 8609、DOI 10.17487/RFC8609、2019年7月、<https://www.rfc-editor.org/info/rfc8609>。
Acknowledgments
謝辞
Marc Mosko provided much guidance and helpful precision in getting these terms carefully formed and the definitions precise. Marie-Jose Montpetit did a thorough IRSG review, which helped a lot to improve the text. Further comments during the IRSG Poll from Stephen Farrell, Ari Keraenen, Spencer Dawkins, Carsten Bormann, and Brian Trammell further improved the document. Additional helpful comments were received as part of the IESG conflict review from Mirja Kuehlewind and Benjamin Kaduk.
Marc Moskoは、これらの用語を注意深く作成し、定義を正確にするために、多くのガイダンスと役立つ正確さを提供しました。 Marie-Jose Montpetitは徹底的なIRSGレビューを行いました。これはテキストの改善に大いに役立ちました。 Stephen Farrell、Ari Keraenen、Spencer Dawkins、Carsten Bormann、およびBrian TrammellからのIRSG投票中のさらなるコメントにより、文書がさらに改善されました。 Mirja KuehlewindとBenjamin KadukからIESG紛争レビューの一環として追加の有益なコメントが寄せられました。
Authors' Addresses
著者のアドレス
Bastiaan Wissingh TNO
バスティアンウィシンTNO
Email: bastiaan.wissingh@tno.nl
Christopher A. Wood University of California Irvine
クリストファーA.ウッドカリフォルニア大学アーバイン校
Email: caw@heapingbits.net
Alex Afanasyev Florida International University
Alex Afanasyevフロリダ国際大学
Email: aa@cs.fiu.edu
Lixia Zhang UCLA
l張UCLAの下
Email: lixia@cs.ucla.edu
David Oran Network Systems Research & Design
デビッドオランネットワークシステムリサーチ＆デザイン
Email: daveoran@orandom.net
Christian Tschudin University of Basel
バーゼルのキリスト教Tschudin大学
Email: christian.tschudin@unibas.ch