<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC4838    SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4838.xml">
<!ENTITY RFC4949    SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml">
<!ENTITY RFC6234    SYSTEM "https://xml.resource.org/public/rfc/bibxml/reference.RFC.6234.xml">
<!ENTITY RFC7476    PUBLIC '' '../bib/reference.RFC.7476.xml'>
<!ENTITY RFC7927    PUBLIC '' '../bib/reference.RFC.7927.xml'>
<!ENTITY RFC7945    PUBLIC '' '../bib/reference.RFC.7945.xml'>
<!ENTITY RFC7933    PUBLIC '' '../bib/reference.RFC.7933.xml'>
<!ENTITY RFC8569	PUBLIC '' '../bib/reference.RFC.8569.xml'>
<!ENTITY RFC8609 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8609.xml">
<!ENTITY I-D.irtf-icnrg-disaster PUBLIC '' '../bib/reference.I-D.irtf-icnrg-disaster.xml'>
]>

<?rfc rfcedstyle="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc text-list-symbols="-o*+"?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" category="info" docName="draft-irtf-icnrg-terminology-08"> consensus="true" docName="draft-irtf-icnrg-terminology-08" number="8793" obsoletes="" updates="" submissionType="IRTF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">

  <front>
    <title abbrev="ICN Terminology">Information-Centric Networking (ICN): CCNx
    Content-Centric Networking (CCNx) and NDN Named Data Networking (NDN)
    Terminology</title>
    <seriesInfo name="RFC" value="8793"/>
    <author fullname="Bastiaan Wissingh" initials="B.F." initials="B." surname="Wissingh">
      <organization>TNO</organization>
      <address>
        <email>bastiaan.wissingh@tno.nl</email>
      </address>
    </author>
    <author fullname="Christopher A. Wood" initials="C." surname="Wood">
      <organization>University of California Irvine</organization>
      <address>
        <email>woodc1@uci.edu</email>
        <email>caw@heapingbits.net</email>
      </address>
    </author>
    <author fullname="Alex Afanasyev" initials="A." surname="Afanasyev">
      <organization>Florida International University</organization>
      <address>
        <email>aa@cs.fiu.edu</email>
      </address>
    </author>
    <author fullname="Lixia Zhang" initials="L." surname="Zhang">
      <organization>UCLA</organization>
      <address>
        <email>lixia@cs.ucla.edu</email>
      </address>
    </author>
    <author fullname="David Oran" initials="D." surname="Oran">
      <organization>Network Systems Research &amp; Design</organization>
      <address>
        <email>daveoran@orandom.net</email>
      </address>
    </author>
    <author fullname="Christian Tschudin" initials="C." surname="Tschudin">
      <organization>University of Basel</organization>
      <address>
        <email>christian.tschudin@unibas.ch</email>
      </address>
    </author>
    <date month="January" month="June" year="2020"/>
    <area>IRTF</area>
    <workgroup>ICNRG</workgroup>
    <keyword>Internet-Draft</keyword>
    <workgroup>Information-Centric Networking</workgroup>

<keyword>content routing</keyword>
<keyword>content caching</keyword>
<keyword>content distribution networks</keyword>
<keyword>data-centric security</keyword>

    <abstract>
		<t>Information Centric
      <t>Information-Centric Networking (ICN) is a novel paradigm where network communications are accomplished by requesting named content, 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).
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="introduction"> anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>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 caching, and
      replication of data objects. </t>
      <t>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 <xref
      target="RFC8569"/>, <xref target="RFC8609"/>, and <xref
      target="NDNTLV"/>. Other ICN projects such as <xref target="Netinf"/>, target="NETINF"
      format="default"/>, <xref target="PSIRP"/>, target="PSIRP" format="default"/>, or <xref target="MobilityFirst"/>
      target="MOBILITY-FIRST" format="default"/> are not covered and may be
      the subject of other documents.</t>

	<t>To
      <t>In this document, to help provide context for the individual defined terms, in this document we first sketch the bigger picture of an ICN network by
      introducing the basic concepts and identifying the major components of
      the architecture in <xref target="a-sketch-of-the-big-picture-of-icn"/>, target="a-sketch-of-the-big-picture-of-icn"
      format="default"/>; after which, in <xref target="terms-by-category"/>, ICN related target="terms-by-category"
      format="default"/>, ICN-related terms are listed by different
      categories. Readers should be aware that in this organization organization, some terms
      may be used in other definitions before they themselves are defined.</t>
      <t>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 application-layer concern.</t>
      <t>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.</t>
    </section>
    <section title="A anchor="a-sketch-of-the-big-picture-of-icn" numbered="true" toc="default">
      <name>A Sketch of the Big Picture of ICN" anchor="a-sketch-of-the-big-picture-of-icn"> ICN</name>
      <t>In networking terms, an ICN is a delivery infrastructure for named
      data. For other complementing views views, see <xref target="semantics-and-usage"/>.</t>
      target="semantics-and-usage" format="default"/>.</t>
      <figure anchor="fig:i-d-protocol" align="center" title="Request-Reply anchor="fig_i-d-protocol">
        <name>Request-Reply Protocol of ICN networking. Legend: n=name, c=content, s=signature."> Networking.</name>
        <artwork align="center"> align="center" name="" type="" alt=""><![CDATA[
requestor         zero or more           data sources or
(node)          forwarding nodes         replica nodes
  |                 | ... |                  |...|
  |   Interest(n)   |     |   Interest(n)    |   |
  | --------------&gt; --------------> |     | ---------------&gt; ---------------> |   |
  |                 |     | -------------------&gt; -------------------> |
  |                 |     |                  |   |
  |                 |     |  Data([n],c,[s]) |   |
  |                 |     | &lt;--------------- <--------------- |   |
  |                 |     | &lt;------------------- <------------------- |
  | Data([n],c,[s]) |     |                  |   |
  | &lt;-------------- <-------------- |     |                  |   |
	</artwork>

      Legend: n=name, c=content, s=signature]]></artwork>
      </figure>
      <t>The following list describes the basic ICN concepts needed to discuss
      the implementation of this service abstraction.</t>

  <t><spanx style="strong">Request-Reply
      <t><strong>Request-Reply Protocol (Interest and Data Packet)</spanx>:</t>
  <t><list style="empty">
		<t>An ICN’s
      Packet):</strong></t>
      <ul empty="true" spacing="normal">
        <li>An ICN's lookup service is implemented by defining two types of
        network packet formats: Interest packets <xref target="interest_packet"
        format="none">Interest packets</xref> that request content by name, name and Data packets
        <xref target="data_packet" format="none">Data packets</xref> that
        carry the requested content. The returned Data packet must match the request’s
        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 Layer 2 interfaces).</t>
	</list></t>

	<t><spanx style="strong">Packet interfaces).</li>
      </ul>
      <t><strong>Packet and Content Names</spanx>:</t>
	<t><list style="empty">
		<t>Without Names:</strong></t>
      <ul empty="true" spacing="normal">
        <li>Without a strong cryptographic binding between the name of a Data packet <xref
        target="data_packet" format="none">Data packet</xref> and its content, Data
        packet names would be useless for fetching specific content. In ICN,
        verification of a Data packet’s packet's name-to-content binding is achieved
        through cryptographic means, means either by (1) a cryptographic signature
        that explicitly binds an application-chosen name to a Data packet’s content, 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.</t>
	</list></t>

	<t><spanx style="strong">Data means.</li>
      </ul>

      <t><strong>Data Authenticity and Encryption</spanx>:</t>
	<t><list style="empty">
		<t>Any Encryption:</strong></t>
      <ul empty="true" spacing="normal">
        <li>Any data consumer or network element can (in principle) validate
        the authenticity of a Data packet <xref target="data_packet" format="none">Data
        packet</xref> 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.</t>
	</list></t>

	<t><spanx style="strong">Trust</spanx>:</t>
	<t><list style="empty">
		<t>Data purpose.</li>
      </ul>
      <t><strong>Trust:</strong></t>
      <ul empty="true" spacing="normal">
        <li>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. <xref target="security-considerations"/> target="security-considerations" format="default"/>
        discusses this further.</t>
	</list></t>

	<t><spanx style="strong">Segmenting and Versioning</spanx>:</t>
	<t><list style="empty">
		<t>An further.</li>
      </ul>
      <t><strong>Segmenting and Versioning:</strong></t>
      <ul empty="true" spacing="normal">
        <li>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. <xref target="data_packet"
        format="none">Data packets</xref>. 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.</t>
	</list></t>

	<t><spanx style="strong">Packet and Frame</spanx>:</t>
	<t><list style="empty">
		<t>NDN object.</li>
      </ul>
      <t><strong>Packet and Frame:</strong></t>
      <ul empty="true" spacing="normal">
        <li>NDN and CCNx introduce Protocol Data Units (PDUs) (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 Layer 2
        interfaces as frames. Handling layer Layer 2 technologies which that lead to
        fragmentation of ICN packets is done inside the ICN network and is not
        visible at the service interface.</t>
	</list></t>

	<t><spanx style="strong">ICN Node</spanx>:</t>
	<t><list style="empty">
		<t>A interface.</li>
      </ul>
      <t><strong>ICN Node:</strong></t>
      <ul empty="true" spacing="normal">
        <li>A node within an ICN network can fulfill the role of a data
        producer, a data consumer, and/or a forwarder for Interest <xref
        target="interest_packet" format="none">Interest</xref> and Data packets. <xref
        target="data_packet" format="none">Data packets</xref>. 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, 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.</t>
	</list></t>

	<t><spanx style="strong">Forwarding Plane</spanx>:</t>
	<t><list style="empty">
		<t>The decisions.</li>
      </ul>
      <t><strong>Forwarding Plane:</strong></t>
      <ul empty="true" spacing="normal">
        <li>The canonical way of implementing packet forwarding in an ICN
        network relies on three data structures that capture a node’s node's state: a
        Forwarding Interest Table Base (FIB), a Pending Interest Table (PIT), and a Content Store
        <xref target="content_store" format="none">Content Store</xref>
        (CS). It also utilizes Interest forwarding strategies strategies, which take
        input from both FIB and measurements to make Interest forwarding
        decisions. When a node receives an Interest packet, <xref target="interest_packet"
        format="none">Interest packet</xref>, 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.</t>
	</list></t> FIB.</li>
      </ul>

    </section>
    <section title="Terms anchor="terms-by-category" numbered="true" toc="default">
      <name>Terms by category" anchor="terms-by-category"> Category</name>
      <section title="Generic terms" anchor="generic-terms">

		<t><spanx style="strong">Information-Centric anchor="generic-terms" numbered="true" toc="default">
        <name>Generic Terms</name>
        <t><strong>Information-Centric Networking (ICN)</spanx>:</t>
		<t><list style="empty">
			<t>A (ICN):</strong></t>
        <ul empty="true" spacing="normal">
          <li>A networking architecture that retrieves Data packets as <xref
	  target="data_packet" format="none">Data packets</xref> in
          response to Interest packets. <xref target="interest_packet" format="none">Interest packets</xref>. Content-Centric Networking (CCNx 1.x)
          and Named Data Networking (NDN) are two realizations (designs) of an
          ICN architecture.</t>
		</list></t>

		<t><spanx style="strong">Data packet Immutability</spanx>:</t>
		<t><list style="empty">
			<t>After architecture.</li>
        </ul>
        <t><strong>Data Packet Immutability:</strong></t>
        <ul empty="true" spacing="normal">
          <li>After a data packet <xref target="data_packet" format="none">Data
          packet</xref> 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 Data packet is intended to be mutable,
          versioning of the name should be used, 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.</t>
		</list></t>
          achieved.</li>
        </ul>
      </section>
      <section title="Terms related anchor="terms-related-to-icn-nodes" numbered="true" toc="default">
        <name>Terms Related to ICN Nodes" anchor="terms-related-to-icn-nodes">

    	<t><spanx style="strong">ICN Interface</spanx>:</t>
    	<t><list style="empty">
    		<t>A Nodes</name>
        <t><strong>ICN Interface:</strong></t>
        <ul empty="true" spacing="normal">
          <li>A generalization of the network interface that can represent a
          physical network interface (ethernet, wifi, 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.).</t>
    	</list></t>
    	<t><list style="empty">
      		<t><list style="empty">
        		<t>Common etc.).</li>
        </ul>

        <ul empty="true" spacing="normal">
          <li>
            <ul empty="true" spacing="normal">
              <li>Common aliases include: face.</t>
      		</list></t>
    	</list></t>

		<t><spanx style="strong">ICN Consumer</spanx>:</t>
    	<t><list style="empty">
    		<t>An face.</li>
            </ul>
          </li>
        </ul>
        <t><strong>ICN Consumer:</strong></t>
        <ul empty="true" spacing="normal">
          <li>An ICN entity that requests Data packets <xref target="data_packet"
          format="none">Data packets</xref> by generating and sending out Interest packets
          <xref target="interest_packet" format="none">Interest packets</xref>
          towards local (using intra-node interfaces) or remote (using
          inter-node interfaces) ICN Forwarders.</t>
    	</list></t>
    	<t><list style="empty">
      		<t><list style="empty">
        		<t>Common Forwarders.</li>
        </ul>
        <ul empty="true" spacing="normal">
          <li>
            <ul empty="true" spacing="normal">
              <li>Common aliases include: consumer, information consumer, data consumer, consumer of the content.</t>
      		</list></t>
    	</list></t>

    	<t><spanx style="strong">ICN Producer</spanx>:</t>
    	<t><list style="empty">
    		<t>An content.</li>
            </ul>
          </li>
        </ul>
        <t><strong>ICN Producer:</strong></t>
        <ul empty="true" spacing="normal">
          <li>An ICN entity that creates Data packets <xref target="data_packet"
          format="none">Data packets</xref> and makes them available for retrieval.</t>
    	</list></t>
    	<t><list style="empty">
      		<t><list style="empty">
        		<t>Common
          retrieval.</li>
        </ul>
        <ul empty="true" spacing="normal">
          <li>
            <ul empty="true" spacing="normal">
              <li>Common aliases include: producer, publisher, information publisher, data publisher, data producer.</t>
      		</list></t>
    	</list></t>

		<t><spanx style="strong">ICN Forwarder</spanx>:</t>
    	<t><list style="empty">
    		<t>An producer.</li>
            </ul>
          </li>
        </ul>
        <t><strong>ICN Forwarder:</strong></t>
        <ul empty="true" spacing="normal">
          <li>An ICN entity that implements stateful forwarding.</t>
	    </list></t>
    	<t><list style="empty">
      		<t><list style="empty">
        		<t>Common forwarding.</li>
        </ul>
        <ul empty="true" spacing="normal">
          <li>
            <ul empty="true" spacing="normal">
              <li>Common aliases include: ICN router.</t>
      		</list></t>
    	</list></t>

    	<t><spanx style="strong">ICN Data Mule</spanx>:</t>
    	<t><list style="empty">
    		<t>An router.</li>
            </ul>
          </li>
        </ul>
        <t><strong>ICN Data Node:</strong></t>
        <ul empty="true" spacing="normal">
          <li>An ICN entity that temporarily stores and potentially carries an
          Interest or Data packet <xref target="data_packet" format="none">Data
          packet</xref> before forwarding it to next ICN entity. Note that
          such ICN data mules nodes do not have all the properties of data mules nodes as
          employed in the Delay Tolerant Networking (DTN) <xref target="RFC4838">(DTN)</xref> specifications.</t>
    	</list></t>
          target="RFC4838" format="default"></xref> specifications.</li>
        </ul>
      </section>

      <section title="Terms related anchor="terms-related-to-the-forwarding-plane" numbered="true" toc="default">
        <name>Terms Related to the Forwarding plane" anchor="terms-related-to-the-forwarding-plane">

    	<t><spanx style="strong">Stateful forwarding</spanx>:</t>
    	<t><list style="empty">
    		<t>A Plane</name>
        <t><strong>Stateful Forwarding:</strong></t>
        <ul empty="true" spacing="normal">
          <li>A forwarding process that records incoming Interest packets <xref
          target="interest_packet" format="none">Interest packets</xref> in
          the PIT and uses the recorded information to forward the retrieved Data packets
          <xref target="data_packet" format="none">Data packets</xref> back to
          the consumer(s). The recorded information can also be used to
          measure data plane data-plane performance, e.g., to adjust interest forwarding strategy decisions.</t>
    	</list></t>
    	<t><list style="empty">
    		<t><list style="empty">
    			<t>Common
          forwarding-strategy decisions.</li>
        </ul>
        <ul empty="true" spacing="normal">
          <li>
            <ul empty="true" spacing="normal">
              <li>Common aliases include: ICN Data plane, ICN Forwarding.</t>
    		</list></t>
    	</list></t>

		<t><spanx style="strong">Forwarding strategy</spanx>:</t>
		<t><list style="empty">
			<t>A Forwarding.</li>
            </ul>
          </li>
        </ul>
        <t anchor="forwarding_strategy"><strong>Forwarding Strategy:</strong></t>
        <ul empty="true" spacing="normal">
          <li>A module of the ICN stateful forwarding (ICN data) plane that
          implements a decision on where/how to forward the incoming Interest packet. <xref
          target="interest_packet" format="none">Interest packet</xref>. The forwarding strategy
          can take input from the Forwarding Information Base (FIB), measured data plane
          data-plane performance parameters, and/or use other mechanisms to
          make the decision.</t>
		</list></t>
		<t><list style="empty">
			<t><list style="empty">
				<t>Common decision.</li>
        </ul>
        <ul empty="true" spacing="normal">
          <li>
            <ul empty="true" spacing="normal">
              <li>Common aliases include: Interest forwarding strategy.</t>
			</list></t>
		</list></t>

		<t><spanx style="strong">Upstream (forwarding)</spanx>:</t>
		<t><list style="empty">
			<t>Forwarding strategy.</li>
            </ul>
          </li>
        </ul>

        <t><strong>Upstream (forwarding):</strong></t>
        <ul empty="true" spacing="normal">
          <li>Forwarding packets in the direction of Interests (i.e., Interests are forwarded upstream): consumer, router, router, …, producer.</t>
		</list></t>

		<t><spanx style="strong">Downstream (forwarding)</spanx>:</t>
		<t><list style="empty">
			<t>Forwarding ..., producer.</li>
        </ul>
        <t><strong>Downstream (forwarding):</strong></t>
        <ul empty="true" spacing="normal">
          <li>Forwarding packets in the opposite direction of Interest
          forwarding (i.e., Data and Interest Nacks <xref target="interest_nack"
          format="none">Interest Nacks</xref> are forwarded downstream):
          producer, router, …, consumer(s).</t>
		</list></t>

		<t><spanx style="strong">Interest forwarding</spanx>:</t>
		<t><list style="empty">
			<t>A ..., consumer(s).</li>
        </ul>
        <t><strong>Interest Forwarding:</strong></t>
        <ul empty="true" spacing="normal">
          <li>A process of forwarding Interest packets <xref target="interest_packet"
          format="none">Interest packets</xref> using the Names <xref target="name"
          format="none">Names</xref> carried in the Interests. In case of Stateful
          stateful forwarding, this also involves creating an entry in the
          PIT. The forwarding decision is made by the Forwarding Strategy.</t>
		</list></t>

		<t><spanx style="strong">Interest aggregation</spanx>:</t>
		<t><list style="empty">
			<t>A <xref
          target="forwarding_strategy" format="none">Forwarding
          Strategy</xref>.</li>
        </ul>
        <t><strong>Interest Aggregation:</strong></t>
        <ul empty="true" spacing="normal">
          <li>A process of combining multiple Interest packets <xref target="interest_packet"
          format="none">Interest packets</xref> with the same Name <xref
          target="name" format="none">Name</xref> and additional restrictions
          for the same Data into a single PIT entry.</t>
		</list></t>
		<t><list style="empty">
			<t><list style="empty">
				<t>Common entry.</li>
        </ul>
        <ul empty="true" spacing="normal">
          <li>
            <ul empty="true" spacing="normal">
              <li>Common aliases include: Interest collapsing.</t>
			</list></t>
		</list></t>

		<t><spanx style="strong">Data forwarding</spanx>:</t>
		<t><list style="empty">
			<t>A collapsing.</li>
            </ul>
          </li>
        </ul>
        <t><strong>Data Forwarding:</strong></t>
        <ul empty="true" spacing="normal">
          <li>A process of forwarding the incoming Data packet <xref target="data_packet" format="none">Data packet</xref> to the
          interface(s) recorded in the corresponding PIT entry (entries) and
          removing the corresponding PIT entry (entries).</t>
		</list></t>

		<t><spanx style="strong">Satisfying (entries).</li>
        </ul>
        <t><strong>Satisfying an Interest</spanx>:</t>
		<t><list style="empty">
			<t>An Interest:</strong></t>
        <ul empty="true" spacing="normal">
          <li>An overall process of returning content that satisfies the
          constraints imposed by the Interest, most notably a match in the
          provided Name.</t>
		</list></t>

    	<t><spanx style="strong">Interest match <xref target="name" format="none">Name</xref>.</li>
        </ul>
        <t><strong>Interest Match in FIB (longest prefix match)</spanx>:</t>
    	<t><list style="empty">
    		<t>A match):</strong></t>
        <ul empty="true" spacing="normal">
          <li>A process of finding a FIB entry with the longest Name <xref
	  target="name" format="none">Name</xref> (in terms
          of Name components) <xref target="name_component" format="none">Name components</xref>) that is a prefix of the specified Name. See
          <xref target="terms-related-to-name-types"/> target="terms-related-to-name-types" format="default"/> for
          terms related to name prefixes</t>
    	</list></t>

		<t><spanx style="strong">Interest match prefixes.</li>
        </ul>
        <t><strong>Interest Match in PIT (exact match)</spanx>:</t>
		<t><list style="empty">
			<t>A match):</strong></t>
        <ul empty="true" spacing="normal">
          <li>A process of finding a PIT entry that stores the same Name <xref
	  target="name" format="none">Name</xref> as
          specified in the Interest (including Interest restrictions, if any).</t>
		</list></t>

		<t><spanx style="strong">Data match
          any).</li>
        </ul>
        <t><strong>Data Match in PIT (all match)</spanx>:</t>
		<t><list style="empty">
			<t>A match):</strong></t>
        <ul empty="true" spacing="normal">
          <li>A process of finding (a set of) PIT entries that can be
	  satisfied with the specified Data packet.</t>
		</list></t>

		<t><spanx style="strong">Interest match <xref target="data_packet" format="none">Data packet</xref>.</li>
        </ul>
        <t><strong>Interest Match in CS (any match)</spanx>:</t>
		<t><list style="empty">
			<t>A match):</strong></t>
        <ul empty="true" spacing="normal">
          <li>A process of finding an entry in router’s Content Store a router's <xref
	  target="content_store" format="none">Content Store</xref> that
          can satisfy the specified Interest.</t>
		</list></t>

		<t><spanx style="strong">Pending Interest.</li>
        </ul>
        <t><strong>Pending Interest Table (PIT)</spanx>:</t>
		<t><list style="empty">
			<t>A (PIT):</strong></t>
        <ul empty="true" spacing="normal">
          <li>A database that records received and not yet satisfied 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 data-plane performance. Interests for the same Data are
          aggregated into a single PIT entry.</t>
		</list></t>

		<t><spanx style="strong">Forwarding entry.</li>
        </ul>
        <t><strong>Forwarding Information Base (FIB)</spanx>:</t>
		<t><list style="empty">
			<t>A (FIB):</strong></t>
        <ul empty="true" spacing="normal">
          <li>A database that contains a set of prefixes, each prefix
          associated with one or more faces that can be used to retrieve Data packets <xref
          target="data_packet" format="none">Data packets</xref> with Names <xref target="name"
          format="none">Names</xref> 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.</t>
		</list></t>

		<t><spanx style="strong">Content
          forwarding-strategy decisions.</li>
        </ul>
        <t anchor="content_store"><strong>Content Store (CS)</spanx>:</t>
		<t><list style="empty">
			<t>A (CS):</strong></t>
        <ul empty="true" spacing="normal">
          <li>A database in an ICN router that provides caching.</t>
		</list></t>

		<t><spanx style="strong">In-network storage</spanx>:</t>
		<t><list style="empty">
			<t>An caching.</li>
        </ul>
        <t><strong>In-Network Storage:</strong></t>
        <ul empty="true" spacing="normal">
          <li>An optional process of storing a Data packet <xref target="data_packet"
          format="none">Data packet</xref> 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.</t>
		</list></t>

		<t><spanx style="strong">Opportunistic caching</spanx>:</t>
		<t><list style="empty">
			<t>A plane.</li>
        </ul>
        <t><strong>Opportunistic Caching:</strong></t>
        <ul empty="true" spacing="normal">
          <li>A process of temporarily storing a forwarded Data packet <xref
	  target="data_packet" format="none">Data packet</xref> in the router’s
          router's memory (RAM or disk), so it can be used to satisfy future
          Interests for the same Data, if any.</t>
		</list></t>
		<t><list style="empty">
			<t><list style="empty">
				<t>Common any.</li>
        </ul>
        <ul empty="true" spacing="normal">
          <li>
            <ul empty="true" spacing="normal">
              <li>Common aliases include: on-path in-network caching</t>
			</list></t>
		</list></t>

		<t><spanx style="strong">Managed caching</spanx>:</t>
		<t><list style="empty">
			<t>A caching.</li>
            </ul>
          </li>
        </ul>
        <t><strong>Managed Caching:</strong></t>
        <ul empty="true" spacing="normal">

      <li>The process of temporarily, permanently, achieving the temporary, permanent, or scheduled storing
      storage of a selected (set of) Data packet(s).</t>
		</list></t>
		<t><list style="empty">
			<t><list style="empty">
				<t>Common <xref target="data_packet" format="none">Data packet(s)</xref>.</li>
        </ul>
        <ul empty="true" spacing="normal">
          <li>
            <ul empty="true" spacing="normal">
              <li>Common aliases include: off-path in-network storage</t>
			</list></t>
		</list></t>

		<t><spanx style="strong">Managed in-network storage</spanx>:</t>
		<t><list style="empty">
			<t>An storage.</li>
            </ul>
          </li>
        </ul>
        <t><strong>Managed In-Network Storage:</strong></t>
        <ul empty="true" spacing="normal">
          <li>An entity acting as an ICN publisher that implements managed caching.</t>
		</list></t>
		<t><list style="empty">
			<t><list style="empty">
				<t>Common caching.</li>
        </ul>
        <ul empty="true" spacing="normal">
          <li>
            <ul empty="true" spacing="normal">
              <li>Common aliases include: repository, repo</t>
			</list></t>
		</list></t>

		<t><spanx style="strong">ICN repo.</li>
            </ul>
          </li>
        </ul>
        <t><strong>ICN Routing plane</spanx>:</t>
		<t><list style="empty">
			<t>An Plane:</strong></t>
        <ul empty="true" spacing="normal">
          <li>An ICN protocol or a set of ICN protocols to exchange
          information about Name <xref target="name" format="none">Name</xref> space reachability.</t>
		</list></t>

		<t><spanx style="strong">ICN reachability.</li>
        </ul>
        <t><strong>ICN Routing Information Base (RIB)</spanx>:</t>
		<t><list style="empty">
			<t>A (RIB):</strong></t>
        <ul empty="true" spacing="normal">
          <li>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.</t>
		</list></t> FIB.</li>
        </ul>
      </section>
      <section title="Terms related anchor="terms-related-to-packet-types" numbered="true" toc="default">
        <name>Terms Related to Packet Types" anchor="terms-related-to-packet-types">

		<t><spanx style="strong">Interest packet</spanx>:</t>
		<t><list style="empty">
			<t>A Types</name>
        <t anchor="interest_packet"><strong>Interest Packet:</strong></t>
        <ul empty="true" spacing="normal">
          <li>A network-level packet that expresses the request for a data packet <xref
          target="data_packet" format="none">Data packet</xref> 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.</t>
		</list></t>
		<t><list style="empty">
			<t><list style="empty">
				<t>Common vary.</li>
        </ul>
        <ul empty="true" spacing="normal">
          <li>
            <ul empty="true" spacing="normal">
              <li>Common aliases include: Interest, Interest message, information request</t>
			</list></t>
		</list></t>

		<t><spanx style="strong">Interest Nack</spanx>:</t>
		<t><list style="empty">
			<t>A request.</li>
            </ul>
          </li>
        </ul>
        <t anchor="interest_nack"><strong>Interest Nack:</strong></t>
        <ul empty="true" spacing="normal">
          <li>A packet that contains the Interest packet <xref target="interest_packet"
          format="none">Interest packet</xref> and optional annotation, which is sent
          by the ICN Router 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.</t>
		</list></t>
		<t><list style="empty">
			<t><list style="empty">
				<t>Common reason.</li>
        </ul>
        <ul empty="true" spacing="normal">
          <li>
            <ul empty="true" spacing="normal">
              <li>Common aliases include: network NACK, Interest return.</t>
			</list></t>
		</list></t>

		<t><spanx style="strong">Data packet</spanx>:</t>
		<t><list style="empty">
			<t>A return.</li>
            </ul>
          </li>
        </ul>
        <t anchor="data_packet"><strong>Data Packet:</strong></t>
        <ul empty="true" spacing="normal">
          <li>A network-level packet that carries payload, uniquely identified
          by a name, and that is directly secured through cryptographic signature mechanisms.</t>
		</list></t>
		<t><list style="empty">
			<t><list style="empty">
				<t>Common
          mechanisms.</li>
        </ul>
        <ul empty="true" spacing="normal">
          <li>
            <ul empty="true" spacing="normal">
              <li>Common aliases include: data, data object, content object, content object packet, data message, named data object, named data.</t>
			</list></t>
		</list></t>

		<t><spanx style="strong">Link</spanx>:</t>
		<t><list style="empty">
			<t>A data.</li>
            </ul>
          </li>
        </ul>
        <t anchor="link"><strong>Link:</strong></t>
        <ul empty="true" spacing="normal">
          <li>A type of Data packet <xref target="data_packet" format="none">Data
          packet</xref> whose body contains the Name <xref target="name"
          format="none">Name</xref> of another Data packet. This inner Name is
          often a Full Name, <xref target="full_name" format="none">Full Name</xref>,
          i.e., it specifies the Packet ID of the corresponding Data packet,
          but this is not a requirement.</t>
		</list></t>
		<t><list style="empty">
			<t><list style="empty">
				<t>Common requirement.</li>
        </ul>
        <ul empty="true" spacing="normal">
          <li>
            <ul empty="true" spacing="normal">
              <li>Common aliases include: pointer.</t>
			</list></t>
		</list></t>

		<t><spanx style="strong">Manifest</spanx>:</t>
		<t><list style="empty">
			<t>A pointer.</li>
            </ul>
          </li>
        </ul>
        <t><strong>Manifest:</strong></t>
        <ul empty="true" spacing="normal">
          <li>A type of Data packet <xref target="data_packet" format="none">Data packet</xref> that contains Full Name Links <xref target="full_name" format="none">Full Name</xref> <xref
	  target="link" format="none">Links</xref> 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”.
          "directory". Manifests have the additional benefit of amortizing the
          signature verification cost for each Data packet referenced by the
          inner Links. <xref target="link" format="none">Links</xref>. 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.</t>
		</list></t> packets.</li>
        </ul>
      </section>
      <section title="Terms related anchor="terms-related-to-name-types" numbered="true" toc="default">
        <name>Terms Related to Name Types" anchor="terms-related-to-name-types">

		<t><spanx style="strong">Name</spanx>:</t>
		<t><list style="empty">
    		<t>A Data packet Types</name>
        <t anchor="name"><strong>Name:</strong></t>
        <ul empty="true" spacing="normal">
          <li>A <xref target="data_packet" format="none">Data packet</xref>
          identifier. An ICN name is hierarchical (a sequence of name
          components) and usually is semantically meaningful, making it
          expressive, flexible flexible, and application-specific (akin to a an HTTP
          URL). A Name may encode information about application context,
          semantics, locations (topological, geographical, hyperbolic, etc.),
          a service name, etc.</t>
    	</list></t>
		<t><list style="empty">
			<t><list style="empty">
				<t>Common etc.</li>
        </ul>
        <ul empty="true" spacing="normal">
          <li>
            <ul empty="true" spacing="normal">
              <li>Common aliases include: data name, interest name, content name.</t>
			</list></t>
		</list></t>

		<t><spanx style="strong">Name component</spanx>:</t>
		<t><list style="empty">
			<t>A name.</li>
            </ul>
          </li>
        </ul>
        <t anchor="name_component"><strong>Name component:</strong></t>
        <ul empty="true" spacing="normal">
          <li>A sequence of bytes and optionally a numeric type representing a single label in the hierarchical structured name.</t>
		</list></t>
		<t><list style="empty">
			<t><list style="empty">
				<t>Common name.</li>
        </ul>
        <ul empty="true" spacing="normal">
          <li>
            <ul empty="true" spacing="normal">
              <li>Common aliases include: name segment (as in CCNx).</t>
			</list></t>
		</list></t>

		<t><spanx style="strong">Packet ID</spanx>:</t>
		<t><list style="empty">
			<t>A CCNx).</li>
            </ul>
          </li>
        </ul>
        <t><strong>Packet ID:</strong></t>
        <ul empty="true" spacing="normal">
          <li>A unique cryptographic identifier for a Data packet. <xref
	  target="data_packet" format="none">Data packet</xref>. Typically,
          this is a cryptographic hash digest of a data Data packet (such as SHA256
          <xref target="RFC6234">SHA256</xref>), target="RFC6234" format="default"></xref>), including
          its name, payload, meta information, and signature.</t>
		</list></t>
		<t><list style="empty">
			<t><list style="empty">
				<t>Common signature.
</li>
        </ul>
        <ul empty="true" spacing="normal">
          <li>
            <ul empty="true" spacing="normal">
              <li>Common aliases include: implicit digest.</t>
			</list></t>
		</list></t>

		<t><spanx style="strong">Selector</spanx>:</t>
		<t><list style="empty">
			<t>A digest.</li>
            </ul>
          </li>
        </ul>
        <t><strong>Selector:</strong></t>
        <ul empty="true" spacing="normal">
          <li>A mechanism (condition) to select an individual Data packet <xref
	  target="data_packet" format="none">Data packet</xref> from
	  a collection of Data packets that match a given Interest that
	  requests data using a prefix or exact Name.</t>
		</list></t>
		<t><list style="empty">
			<t><list style="empty">
				<t>Common <xref target="name" format="none">Name.</xref></li>
        </ul>
        <ul empty="true" spacing="normal">
          <li>
            <ul empty="true" spacing="normal">
              <li>Common aliases include: interest selector, restrictor, interest restrictor.</t>
			</list></t>
		</list></t>

		<t><spanx style="strong">Nonce</spanx>:</t>
		<t><list style="empty">
			<t>A restrictor.</li>
            </ul>
          </li>
        </ul>
        <t><strong>Nonce:</strong></t>
        <ul empty="true" spacing="normal">
          <li>A field of an Interest packet <xref target="interest_packet"
          format="none">Interest packet</xref> 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 <xref target="RFC4949"/>.</t>
		</list></t>

		<t><spanx style="strong">Exact Name</spanx>:</t>
		<t><list style="empty">
			<t>A name target="RFC4949"
          format="default"/>.</li>
        </ul>
        <t><strong>Exact Name:</strong></t>
        <ul empty="true" spacing="normal">
          <li>A <xref target="name" format="none">Name</xref> that is encoded inside a Data packet <xref target="data_packet"
          format="none">Data packet</xref> and which that typically uniquely
          identifies this Data packet.</t>
		</list></t>

		<t><spanx style="strong">Full Name</spanx>:</t>
		<t><list style="empty">
			<t>An packet.</li>
        </ul>
        <t anchor="full_name"><strong>Full Name:</strong></t>
        <ul empty="true" spacing="normal">
          <li>An exact Name <xref target="name" format="none">Name</xref> with the Packet ID of the corresponding Data packet.</t>
		</list></t>

		<t><spanx style="strong">Prefix Name</spanx>:</t>
		<t><list style="empty">
			<t>A Name <xref
	  target="data_packet" format="none">Data packet</xref>.</li>
        </ul>
        <t><strong>Prefix Name:</strong></t>
        <ul empty="true" spacing="normal">
          <li>A <xref target="name" format="none">Name</xref> that includes a partial sequence of Name components
	  (starting from the first one) of a Name encoded inside a Data packet.</t>
		</list></t>
		<t><list style="empty">
			<t><list style="empty">
				<t>Common <xref
	  target="data_packet" format="none">Data packet</xref>.</li>
        </ul>
        <ul empty="true" spacing="normal">
          <li>
            <ul empty="true" spacing="normal">
              <li>Common aliases include: prefix.</t>
			</list></t>
		</list></t> prefix.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section title="Terms related anchor="terms-related-to-name-usage" numbered="true" toc="default">
        <name>Terms Related to Name Usage" anchor="terms-related-to-name-usage">

		<t><spanx style="strong">Naming conventions</spanx>:</t>
		<t><list style="empty">
			<t>A Usage</name>
        <t><strong>Naming conventions:</strong></t>
        <ul empty="true" spacing="normal">
          <li>A convention, agreement, or specification for the Data packet <xref
	  target="data_packet" format="none">Data packet</xref> naming. a Naming convention structures a namespace.</t>
		</list></t>
		<t><list style="empty">
			<t><list style="empty">
				<t>Common namespace.</li>
        </ul>
        <ul empty="true" spacing="normal">
          <li>
            <ul empty="true" spacing="normal">
              <li>Common aliases include: Naming scheme, ICN naming scheme, namespace convention.</t>
			</list></t>
		</list></t>

		<t><spanx style="strong">Hierarchically convention.</li>
            </ul>
          </li>
        </ul>
        <t><strong>Hierarchically structured naming</spanx>:</t>
		<t><list style="empty">
			<t>The naming:</strong></t>
        <ul empty="true" spacing="normal">
          <li>The naming scheme that assigns and interprets a Name <xref
	  target="name" format="none">Name</xref> 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.</t>
		</list></t>
		<t><list style="empty">
			<t><list style="empty">
				<t>Common Name.</li>
        </ul>
        <ul empty="true" spacing="normal">
          <li>
            <ul empty="true" spacing="normal">
              <li>Common aliases include: hierarchical naming, structured naming.</t>
			</list></t>
		</list></t>

		<t><spanx style="strong">Flat naming</spanx>:</t>
		<t><list style="empty">
			<t>The naming.</li>
            </ul>
          </li>
        </ul>
        <t><strong>Flat naming:</strong></t>
        <ul empty="true" spacing="normal">
          <li>The naming scheme that assigns and interprets a Name <xref
	  target="name" format="none">Name</xref> as a single label (Name component) without any internal structure. This can be considered a special (or degenerate) case of structured names.</t>
		</list></t>

		<t><spanx style="strong">Segmentation</spanx>:</t>
		<t><list style="empty">
			<t>A names.</li>
        </ul>
        <t><strong>Segmentation:</strong></t>
        <ul empty="true" spacing="normal">
          <li>A process of splitting large application content into a set of
          uniquely named data packets. <xref target="data_packet" format="none">Data packets</xref>. When using hierarchically structured
          names, each created data Data packet has a common prefix and an
          additional component representing the segment (chunk) number.</t>
		</list></t>
		<t><list style="empty">
			<t><list style="empty">
				<t>Common number.</li>
        </ul>
        <ul empty="true" spacing="normal">
          <li>
            <ul empty="true" spacing="normal">
              <li>Common aliases include: chunking.</t>
			</list></t>
		</list></t>

		<t><spanx style="strong">Versioning</spanx>:</t>
		<t><list style="empty">
			<t>A chunking.</li>
            </ul>
          </li>
        </ul>
        <t><strong>Versioning:</strong></t>
        <ul empty="true" spacing="normal">
          <li>A process of assigning a unique Name <xref target="name"
          format="none">Name</xref> to the revision of the content carried in
          the Data packet. <xref target="data_packet" format="none">Data
          packet</xref>. 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).</t>
		</list></t>

		<t><spanx style="strong">Fragmentation</spanx>:</t>
		<t><list style="empty">
			<t>A data).</li>
        </ul>
        <t><strong>Fragmentation:</strong></t>
        <ul empty="true" spacing="normal">
          <li>A process of splitting PDUs into Frames so that they can be transmitted over a layer Layer 2 interface with a smaller MTU size.</t>
		</list></t> size.</li>
        </ul>
      </section>
      <section title="Terms related anchor="terms-related-to-data-centric-security" numbered="true" toc="default">
        <name>Terms Related to Data-Centric Security" anchor="terms-related-to-data-centric-security">

    	<t><spanx style="strong">Data-Centric Security</spanx>:</t>
    	<t><list style="empty">
    		<t>A Security</name>
        <t><strong>Data-Centric Security:</strong></t>
        <ul empty="true" spacing="normal">
          <li>A security property associated with the Data packet, <xref
	  target="data_packet" format="none">Data packet</xref>, including
          data (Data-Centric) integrity, authenticity, and optionally
          confidentiality. These security properties stay with the data Data packet
          regardless of where it is stored and how it is retrieved.</t>
    	</list></t>
    	<t><list style="empty">
    		<t><list style="empty">
    			<t>Common retrieved.</li>
        </ul>
        <ul empty="true" spacing="normal">
          <li>
            <ul empty="true" spacing="normal">
              <li>Common aliases include: directly securing data packet</t>
    		</list></t>
    	</list></t>

    	<t><spanx style="strong">Data Integrity</spanx></t>
    	<t><list style="empty">
    		<t>A Data packet.</li>
            </ul>

          </li>
        </ul>
        <t><strong>Data Integrity</strong></t>
        <ul empty="true" spacing="normal">
          <li>A cryptographic mechanism to ensure the consistency of the Data packet <xref
	  target="data_packet" format="none">Data
          packet</xref> 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.</t>
    	</list></t>

    	<t><spanx style="strong">Data Authenticity</spanx></t>
    	<t><list style="empty">
    		<t>A modification.</li>
        </ul>
        <t><strong>Data Authenticity</strong></t>
        <ul empty="true" spacing="normal">
          <li>A cryptographic mechanism to ensure trustworthiness of a Data packet, <xref
	  target="data_packet" format="none">Data
          packet</xref> 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), ECDSA) but can also
          be realized using symmetric signatures (e.g., HMAC) Hashed Message
	  Authentication Code (HMAC)) within trusted domains.</t>
    	</list></t>

		<t><spanx style="strong">Data Confidentiality</spanx></t>
		<t><list style="empty">
			<t>A
          domains.</li>
        </ul>
        <t><strong>Data Confidentiality</strong></t>
        <ul empty="true" spacing="normal">
          <li>A cryptographic mechanism to ensure secrecy of a Data packet. <xref
          target="data_packet" format="none" >Data packet</xref>. Data
          confidentiality includes separate mechanisms: content confidentiality <xref
          target="content_confidentiality" format="none">Content
          confidentiality</xref> and Name confidentiality</t>
		</list></t>

		<t><spanx style="strong">Content Confidentiality</spanx></t>
		<t><list style="empty">
			<t>A <xref target="name_confidentiality"
          format="none">Name confidentiality</xref>.</li>
        </ul>
        <t anchor="content_confidentiality"><strong>Content Confidentiality</strong></t>
        <ul empty="true" spacing="normal">
          <li>A cryptographic mechanism to prevent an unauthorized party to
          get access to the plain-text payload of a Data packet. <xref target="data_packet"
	  format="none">Data packet</xref>. Can be
          realized through encryption (symmetric, asymmetric, hybrid) and
          proper distribution of the decryption keys to authorized parties.</t>
		</list></t>

		<t><spanx style="strong">Name Confidentiality</spanx></t>
		<t><list style="empty">
			<t>A
          parties.</li>
        </ul>
        <t anchor="name_confidentiality"><strong>Name Confidentiality</strong></t>
        <ul empty="true" spacing="normal">
          <li>A cryptographic mechanism to prevent an observer of
          Interest-Data exchanges (e.g., intermediate router) from gaining
          detailed meta information about the Data packet. <xref target="data_packet" format="none">Data packet</xref>. This mechanism can
          be realized using encryption (same as content confidentiality) or
          obfuscation mechanisms.</t>
		</list></t> mechanisms.</li>
        </ul>
      </section>
    </section>
    <section title="Semantics anchor="semantics-and-usage" numbered="true" toc="default">
      <name>Semantics and Usage" anchor="semantics-and-usage"> Usage</name>
      <t>The terminology described above is the manifestation of intended
      semantics of NDN and CCNx operations (what (What do we expect the network to
      do?). In this section section, we summarize the most commonly proposed use cases
      and interpretations.</t>
      <section title="Data Transfer" anchor="data-transfer"> anchor="data-transfer" numbered="true" toc="default">
        <name>Data Transfer</name>
        <t>The networking view of NDN and CCNx is that the request/reply
        protocol implements a basic, unreliable data transfer service for
        single, named packets.</t>
      </section>
      <section title="Data Transport" anchor="data-transport"> anchor="data-transport" numbered="true" toc="default">
        <name>Data Transport</name>
        <t>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).</t> etc.).</t>
      </section>
      <section title="Lookup Service" anchor="lookup-service"> anchor="lookup-service" numbered="true" toc="default">
        <name>Lookup Service</name>
        <t>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.</t>
      </section>
      <section title="Database Access" anchor="database-access"> anchor="database-access" numbered="true" toc="default">
        <name>Database Access</name>
        <t>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. A Therefore, a name prefix therefore stands for a collection or table of
        a database, while the rest of the name specifies the query expression
        to be executed.</t>
      </section>
      <section title="Remote anchor="remote-procedure-call" numbered="true" toc="default">
        <name>Remote Procedure Call" anchor="remote-procedure-call"> Call</name>
        <t>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 ACM Association for Computing
	Machinery (ACM) ICN paper on <xref target="RICE"/>.
        target="RICE" format="default"/>. These capabilities can be further
        extended into a full distributed computing infrastructure, infrastructure such as
        that proposed in the ACM ICN paper <xref target="CFN"/>.</t>

<!-->
    	<t><spanx style="strong">Interest match in FIB (longest prefix match)</spanx>:</t>    <t><list style="empty">
    		<t>A process of finding a FIB entry with the longest Name (in terms of Name components) that is a prefix of the specified Name.</t>
    	</list></t>

    	<t><spanx style="strong">Interest match in PIT (exact match)</spanx>:</t>
    	<t><list style="empty">
    		<t>A process of finding a PIT entry that stores the same Name as specified in the Interest (including Interest restrictions, if any).</t>
    	</list></t>

    	<t><spanx style="strong">Data match in PIT (all match)</spanx>:</t>
    	<t><list style="empty">
    		<t>A process of finding (a set of) PIT entries that can be satisfied with the specified Data packet.</t>
    	</list></t>

    	<t><spanx style="strong">Interest match in CS (any match)</spanx>:</t>
    	<t><list style="empty">
    		<t>A process of finding an entry in router’s Content Store that can satisfy the specified Interest.</t>
    	</list></t>
--> target="CFN"
        format="default"/>.</t>

    </section>
      <section title="Publish/Subscribe" anchor="publish-subscribe"> anchor="publish-subscribe" numbered="true" toc="default">
        <name>Publish/Subscribe</name>
        <t>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 fully worked example of how to construct such an ICN-based system,
        see the ACM ICN paper <xref target="LessonsLearned"/>.</t> target="LESSONS-LEARNED"
        format="default"/>.</t>
      </section>
    </section>
    <section title="IANA Considerations" anchor="iana-considerations">
	<t>There are anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA considerations related to this document.</t> actions.</t>
    </section>
    <section title="Security Considerations" anchor="security-considerations"> anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>While the terms defined in this specification do not in and of
      themselves present new security considerations, the architectures which that
      utilize the terms most certainly do. Readers should look at those
      specifications (e.g. (e.g., <xref target="RFC8569"/>, target="RFC8569" format="default"/> and <xref target="NDN"/>)
      target="NDN" format="default"/>) where various security considerations
      are addressed in detail.</t>
      <t>Some of the terms in this document use the words "trust",
      "trustworthy", or "trust model". We intend that these have their
      colloquial meanings, however meanings; however, much work on trust, and specifically on
      trust schemas for ICN architectures architectures, has been published in the last few
      years. For example, it is useful to look at <xref target="SchematizingTrust"/>
      target="SCHEMATIZING-TRUST" format="default"/> for more information on
      the approachs approaches taken to formalize notions of trust for current NDN and
      CCNx systems.</t>
    </section>
  </middle>
  <back>
	<references title="Informational References">
	   	&RFC4838;
	   	&RFC4949;
	   	&RFC6234;
<!--		&RFC8569;
   	&RFC8609; -->

    <references>
      <name>References</name>

      <references>
        <name>Normative References</name>

        <reference anchor="RFC8569" target="https://www.rfc-editor.org/info/rfc8569"> anchor="NETINF" target="https://dl.acm.org/citation.cfm?id=2459643">
          <front>
<title>Content-Centric Networking (CCNx) Semantics</title>
            <title>Network of Information (NetInf) - An information-centric networking architecture</title>
            <seriesInfo name="DOI" value="10.1016/j.comcom.2013.01.009"/>
            <author initials="M." surname="Mosko" fullname="M. Mosko">
<organization/>
</author> surname="Dannewitz" initials="C."/>
            <author initials="I." surname="Solis" fullname="I. Solis">
<organization/>
</author> surname="Kutscher" initials="D."/>
            <author initials="C." surname="Wood" fullname="C. Wood">
<organization/>
</author> surname="Ohlman" initials="B."/>
            <author surname="Farrell" initials="S."/>
            <author surname="Ahlgren" initials="B."/>
            <author surname="Holger" initials="K."/>
            <date year="2019" month="July"/>
<abstract>
<t>
This document describes the core concepts of the Content-Centric year="2013" month="April"/>
          </front>
<refcontent>Computer Communications
</refcontent>
<refcontent>Volume 36, Issue 7
</refcontent>
        </reference>

<reference anchor="NDNTLV" target="https://named-data.net/doc/ndn-tlv/">
                <front>
                        <title>NDN Packet Format Specification</title>
              <author>
<organization>Named Data Networking (CCNx) architecture and presents a network protocol based on two messages: Interests and Content Objects. It specifies the set of mandatory and optional fields within those messages and describes their behavior and interpretation. This architecture and protocol specification is independent of a specific wire encoding.
</t>
<t>
The protocol also uses a control message called an Interest Return, whereby one system can return an Interest message to the previous hop due to an error condition. This indicates to the previous hop that the current system will not respond to the Interest.
</t>
<t>
This document is a product of the Information-Centric Networking Research Group (ICNRG). The document received wide review among ICNRG participants. Two full implementations are in active use and have informed the technical maturity of the protocol specification.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8569"/>
<seriesInfo name="DOI" value="10.17487/RFC8569"/>
</reference>
<reference anchor="RFC8609" target="https://www.rfc-editor.org/info/rfc8609">
<front>
<title>
Content-Centric Networking (CCNx) Messages in TLV Format
</title>
<author initials="M." surname="Mosko" fullname="M. Mosko">
<organization/>
</organization>
	      </author>
<author initials="I." surname="Solis" fullname="I. Solis">
<organization/>
</author>
<author initials="C." surname="Wood" fullname="C. Wood">
<organization/>
</author>
<date year="2019" month="July"/>
<abstract>
<t>
Content-Centric Networking (CCNx) is a network protocol that uses a hierarchical name to forward requests and to match responses to requests. This document specifies the encoding of CCNx messages in a TLV packet format, including the TLV types used by each message element and the encoding of each value. The semantics of CCNx messages follow the encoding-independent CCNx Semantics specification.
</t>
<t>
This document is a product of the Information Centric Networking research group (ICNRG). The document received wide review among ICNRG participants and has two full implementations currently in active use, which have informed the technical maturity of the protocol specification.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8609"/>
<seriesInfo name="DOI" value="10.17487/RFC8609"/>
</reference>

		<reference anchor="NDN" target="https://named-data.net/project/execsummary/">
			<front>
				<title>Named Data Networking</title>
				<author surname="NDN team"/>
				<date year="various"/>
			</front>
		</reference>

    </references>

    <references title="Bibliography">
   		&RFC7476;
		&RFC7927;
		&RFC7945;
		&RFC7933;
    	&I-D.irtf-icnrg-disaster;

		<reference anchor="NDNTLV" target="http://named-data.net/doc/ndn-tlv/">
    		<front>
        		<title>NDN Packet Format Specification</title>
				<author surname="NDN Project Team"/>
				<date year="2016"/>
        	</front>
    	</reference>

    	<reference anchor="Netinf" target="https://dl.acm.org/citation.cfm?id=2459643">
    		<front>
    			<title>Network of Information (NetInf) - An information-centric networking architecture, in Computer Communications, Volume 36, Issue 7</title>
    			<author surname="Dannewitz" initials="C."/>
    			<author surname="Kutscher" initials="D."/>
    			<author surname="Ohlman" initials="B."/>
    			<author surname="Farrell" initials="S."/>
    			<author surname="Ahlgren" initials="B."/>
    			<author surname="Holger" initials="K."/>
    			<date year="2013" month="April"/>

                </front>
    		<seriesInfo name="DOI" value="10.1016/j.comcom.2013.01.009"/>
</reference>

      <reference anchor="PSIRP" target="http://www.psirp.org/files/Deliverables/PSIRP-TR08-0001_Vision.pdf">
          <front>
            <title>From Design for Tussle to Tussle Networking: PSIRP Vision and Use Cases</title>
            <author surname="Trossen" initials="D."/>
            <author surname="Tuononen" initials="J"/>
            <author surname="Xylomenos" initials="G."/>
            <author surname="Sarela" initials="M."/>
            <author surname="Zahemszky" initials="A."/>
            <author surname="Nikander" initials="P."/>
            <author surname="Rinta-aho" initials="T."/>
            <date month="May" year="2008"/>
          </front>
        </reference>

        <reference anchor="MobilityFirst" anchor="MOBILITY-FIRST" target="https://dl.acm.org/citation.cfm?id=2412098">
          <front>
            <title>MobilityFirst: a robust and trustworthy mobility-centric architecture for the future internet, in ACM SIGMOBILE, Volume 16, Issue 3</title> internet</title>
            <seriesInfo name="DOI" value="10.1145/2412096.2412098"/>
            <author surname="Raychaudhuri" initials="D."/>
            <author surname="Nagaraja" initials="K."/>
            <author surname="Venkataramani" initials="V."/> initials="A."/>
            <date year="2012" month="July"/>
          </front>
			<seriesInfo name="DOI" value="10.1145/2412096.2412098"/>
<refcontent>ACM SIGMOBILE
</refcontent>
<refcontent>Volume 16, Issue 3
</refcontent>
        </reference>

        <reference anchor="SchematizingTrust" target="http://dx.doi.org/10.1145/2810156.2810170"> anchor="SCHEMATIZING-TRUST" target="https://dx.doi.org/10.1145/2810156.2810170">
          <front>
            <title>Schematizing Trust in Named Data Networking, in ACM ICN'15</title> Networking</title>
            <seriesInfo name="DOI" value="0.1145/2810156.2810170"/>
            <author surname="Yu" initials="Y."/>
            <author surname="Afanasyev" initials="A."/>
            <author surname="Clark" initials="D."/>
            <author surname="Claffy" initials="kc."/> initials="K. C."/>
            <author surname="Jacobson" initials="V."/>
            <author surname="Zhang" initials="L."/>
            <date month="September" year="2015"/>
          </front>
    		<seriesInfo name="DOI" value="0.1145/2810156.2810170"/>
<refcontent>ACM ICN
</refcontent>
        </reference>

        <reference anchor="RICE" target="http://dx.doi.org/10.1145/3267955.3267956"> target="https://dx.doi.org/10.1145/3267955.3267956">
          <front>
            <title>RICE: remote method invocation in ICN, in ACM ICN'18</title> ICN</title>
            <seriesInfo name="DOI" value="10.1145/3267955.3267956"/>
            <author surname="Krol" initials="m."/> initials="M."/>
            <author surname="Habak" initials="K."/>
            <author surname="Kutscher" initials="D."/>
            <author surname="Oran" initials="D."/>
            <author surname="Psaras" initials="I."/>
            <date month="September" year="2018"/>
          </front>
    		<seriesInfo name="DOI" value="10.1145/3267955.3267956"/>
<refcontent>ACM ICN
</refcontent>
        </reference>

        <reference anchor="CFN" target="https://dl.acm.org/citation.cfm?id=3357395">
          <front>
            <title>Compute First Networking: Distributed Computing meets ICN, in ACM ICN'19</title> ICN</title>
            <seriesInfo name="DOI" value="10.1145/3357150.3357395"/>
            <author surname="Krol" initials="m."/> initials="M."/>
            <author surname="Mastorakis" initials="S."/>
            <author surname="Kutscher" initials="D."/>
            <author surname="Oran" initials="D."/>
            <date month="September" year="2019"/>
          </front>
    		<seriesInfo name="DOI" value="10.1145/3357150.3357395"/>
<refcontent>ACM ICN
</refcontent>
        </reference>

        <reference anchor="LessonsLearned" anchor="LESSONS-LEARNED" target="https://dl.acm.org/citation.cfm?id=3357397">
          <front>
            <title>Lessons Learned Building a Secure Network Measurement Framework using Basic NDN, in ACM ICN'19</title> NDN</title>
            <seriesInfo name="DOI" value="10.1145/3357150.3357397"/>
            <author surname="Nichols" initials="K"/>
            <date month="September" year="2019"/>
          </front>
    		<seriesInfo name="DOI" value="10.1145/3357150.3357397"/>
<refcontent>ACM ICN
</refcontent>
        </reference>
      </references>

      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4838.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4949.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8569.xml"/>
      	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8609.xml"/>

	<reference anchor="NDN" target="https://named-data.net/project/execsummary/">
          <front>
            <title>Named Data Networking: Executive Summary</title>
            <author>
<organization>Named Data Networking
</organization>
	    </author>
            <date month="September" year="2010"/>
          </front>
        </reference>
      </references>

    </references>

    <section anchor="acknowledgements" title="Acknowledgments">
      <t>Marc Mosko numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t><contact fullname="Marc Mosko"/> provided much guidance and helpful
      precision in getting these terms carefully formed and the definitions
      precise. Marie-José Montpetit <contact fullname="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 Keränen, Spencer Dawkins, Carsten Bormann, and Brian Trammell
      <contact fullname="Stephen Farrell"/>, <contact fullname="Ari
      Keraenen"/>, <contact fullname="Spencer Dawkins"/>, <contact fullname="Carsten Bormann"/>, and
      <contact fullname="Brian Trammell"/> further improved the document. Additional helpful
      comments were received as part of the IESG conflict review from Mirja Kuehlewind and Benjamin Kaduk.</t> <contact fullname="Mirja
      Kuehlewind"/> and <contact fullname="Benjamin Kaduk"/>.</t>
    </section>

<!-- [rfced] FYI: The following references are not used and have been removed
from this document. Please let us know if these should be included throughout
the document.

   [ICNRG-DISASTER]
   [NDNTLV]
   [RFC7476]
   [RFC7927]
   [RFC7933]
   [RFC7945]
   [RFC8609]

How about in Intro:

The goal of this document is to collect the key terms with a corresponding
definition as they are used in the CCNx [8609] and NDN [NDNTLV] projects.

-->

  </back>
</rfc>