<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.30 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?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*+"?>
<rfc category="info" docName="draft-wissingh-icnrg-terminology-00">
  <front>
    <title abbrev="ICN Terminology">Information-Centric Networking:
    Terminology</title>

    <author fullname="Bastiaan Wissingh" initials="B.F." surname="Wissingh">
      <organization>TNO</organization>

      <address>
        <email>bastiaan.wissingh@tno.nl</email>
      </address>
    </author>

    <author fullname="Christopher Wood" initials="C." surname="Wood">
      <organization>PARC</organization>

      <address>
        <email>christopher.wood@parc.com</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="Alex Afanasyev" initials="A." surname="Afanasyev">
      <organization>UCLA</organization>
      
      <address>
        <email>aa@cs.ucla.edu</email>
      </address>
    </author>

    <author fullname="David Oran" initials="D." surname="Oran">
      <organization>Cisco Systems, Inc.</organization>

      <address>
        <email>oran@cisco.com</email>
      </address>
    </author>
    
    <date day="8" month="July" year="2016"/>

    <area>General</area>

    <workgroup>icnrg</workgroup>

    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>Information Centric Networking (ICN) is a new paradigm where 
      network communications are accomplished by requesting named content,
      instead of sending packets to destination addresses. This document
      provides an overview of the terminology and definitions that have been
      used in describing this new paradigm. This document is a product
      of the IRTF Information-Centric Networking Research Group (ICNRG).</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>Information-centric networking (ICN) is an approach to evolve the
        Internet infrastructure from the existing host-centric design to 
        a data-centric architecture where named data becomes the essential 
        network primitive. The ICN design directly names and secures data 
        objects, making them independent of their location or means of 
        transportation, and enabling native multicast delivery and ubiquitous 
        in-network caching and replication of data objects.</t>

      <t>As the work on this topic continues to evolve, many new terms are 
        born over time. The goal of this document is to provide a complete
        collection of these terms with a corresponding definition. To help 
        provide the context of the individual terms to be defined, in this 
        draft we first sketch the bigger picture of an ICN network, introducing 
        the basic concepts and identifying the major components in the 
        architecture in section 2 after which in section 3 ICN related terms 
        are listed by different categories.</t>
    </section>

    <section anchor="architecture" title="A Sketch of the Big Picture of an ICN Network Architecture">
      <t>In an ICN network data is fetched by names. This is accomplished by defining 
        two types of network packet formats: interest packets that request a piece of 
        named content and data packets that carry the requested content. Every data 
        packet must be cryptographically signed which binds its name and content together. 
        A basic set of ICN concepts is listed below:</t>
  
      <t>Data Naming:</t>
      <t>Within ICN, the granularity of names is on a per packet basis. This implies 
        that if the size of a piece of content from an application exceeds the network 
        packet size limit, the content is segmented into multiple data packets. Each of 
        these individual data packets is then uniquely named with the content name 
        concatenated with the segment number.</t>
  
      <t>Each ICN data packet is also immutable. This is accomplished by assigning a 
        version number to each piece of application content. When the content changes, 
        the version number in its name changes as well.</t>
  
      <t>Data-Centric Security:</t>
      <t>Security within ICN concerns data authentication, confidentiality, and user 
        privacy. Each ICN data packet carries a signature that binds the name and content 
        of the data packet together, allowing a named packet to be fetched from anywhere 
        while the application is still able to verify the validity of the data packet.</t>

      <t>ICN node:</t>
      <t>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 like a packet mule, that is it may carry an interest or data packet over 
        some distance before forwarding it to next node. An ICN node may also run routing 
        protocols to assist its interest forwarding decisions.</t>
  
      <t>Stateful forwarding plane:</t>
      <t>Generally speaking, an ICN forwarder keeps three data structures: a Forwarding Interest 
        Table (FIB), a Pending Interest Table (PIT), and a Content Store (CS). It also utilizes 
        interest forwarding strategies which takes input from both FIB and measurements to make 
        interest forwarding decisions.  When a node receives an ICN interest packet, it checks 
        its CS and PIT to find a matching name; 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> 
    </section>

    <section anchor="categorized-terms" title="Terms by category">
      
      <section title="Generic terms">
        <t><list>
          <t>Information-Centric Networking (ICN): a networking architecture that retrieves data packets as response to interest packets.</t>
          
          <!--<t>Information-Centric approach (?):</t>-->
          
          <t>Data packet (same as data, data object, content object packet, data message, named data object, named data): a network-level packet that carries payload, uniquely identified by a name, and is directly secured.</t>
          
          <t>Interest packet (same as interest, information request): 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.</t>
          
          <!--<t>Location-independence (?)</t>[LZ: I’d suggest to move all location/identifier related stuff into one place, which is not here]-->
          
          <t>Data packet immutability: after a data packet is created, it cannot change. When content carried in the data packet is mutable, versioning should be used, so each version is uniquely identified. This allows disambiguation of coordination in distributed ICN networks that may not be always connected.</t>
        </list></t>
      </section>
      <section anchor="naming" title="Data naming related terms">
        <t><list>
          <t>Name (aka data name, interest name, content name): a unique identifier of the data packet. ICN name is expressive, flexible, and can be application-specific (akin HTTP URL), a name may encode information about application context, semantics, locations (topological, geographical, hyperbolic, etc.), service name, etc.</t>
          
          <t>Self-certifying name: a special type of data name that uses a packet ID as data name or uses a packet ID as part of the name</t>
          
          <t>Packet ID: a unique cryptographic identifier for a data packet. Typically, this is the cryptographic hash digest of a data packet, including its name, payload, meta information, and signature.</t>
          
          <t>Naming scheme (ICN naming scheme): a convention/agreement/specification for the data packet naming.</t>
          
          <t>Hierarchically structured naming (same as hierarchical naming, structured naming): the naming scheme that assigns and interprets name as a sequence of labels (name components) with hierarchical structure. A structure provides useful context information for the name.
            <!-- Name or parts of it can be “human-readable” to ease human interaction, but a hierarchical name is ultimately a sequence of ICN node interpretable name components. -->
          </t>
          
          <t>Flat naming: the naming scheme that assigns and interprets name as a single label (name component) without any internal structure. This can be considered a special (or degenerated) case of structured names. </t>
          
          <t>Name component (same as name segment): a sequence of octets and optionally a numeric type representing a single label in the hierarchical structured name.</t>
          
          <t>Name prefix: a sequence of name components from the beginning of a hierarchically structured name.</t>
          
          <!-- <t>Information Identifiers (?):</t> <t>Location prefix (?):</t> [LZ: I commented these out, to minimize confusions-->
          
          <t>Segmentation (same as chunking): a process of splitting large application content into a set of uniquely named data packets. When using hierarchically structured name, each created data packet has a common prefix and additional component representing the segment (chunk) number.</t>
          
          <t>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).</t>
          
          <t>Fragmentation: a process of splitting large data packets into smaller pieces so that they can be transmitted over the link with a smaller MTU size.</t>
          
          <!-- Naming scalability (?)  [LZ: probably a confusion with routing scalability] -->
        </list></t>
      </section>
      <section anchor="security" title="Data-Centric Security related terms">
        <t><list>
          <t>Directly secured data packet: a data packet with inherent security properties (authenticity and optionally confidentiality), i.e., the security properties stay with the data packet regardless where it is stored and how it is retrieved.</t>
          
          <t>Data authenticator (content authenticator): a set of parameters carried in the data packet that is used to verify integrity and authenticity of the data packet. The Data authenticator can include a cryptographic signature (RSA, ECDSA, HMAC, etc.), meta information about the signature (e.g., validity period), and additional information to facilitate signature verification (e.g., key locator, key ID, HMAC tag identifier, etc.)</t>
          
          <t>Data confidentiality credentials: a set of parameters carried in the data packet that is used to identify how the confidential data can be decrypted by authorized consumers.</t>
          
          <t>ICN (public) key (same as ICN certificate): a data packet that carries public key or public key certificate as payload and may have additional meta information regarding the public key (e.g., validity period, signature time, etc.). The key belongs to the ICN key owner and can be associated with it implicitly through the name or explicitly through meta information.</t>
          
          <t>ICN key owner (same as Identity): an entity (user, device, program, program instance, module in the program instance, etc.) that owns the private key that corresponds to the ICN key.</t> 
          
          <t>Key locator (same as ?): Parameter(s) that identify the ICN key, which can be the ICN key name, ICN key prefix, ICN key ID, etc.</t>
          
          <t>ICN key ID: Packet ID of the ICN (public) key.</t>
          
          <t>Trust model: a model or framework that defines trust relationships, i.e., which entity (represented by an ICN key) is authorized to sign which data packets.</t>
          
          <t>ICN key chain (certificate chain): a chain of ICN keys (certificates) wherein each key (certificate) is signed by its predecessor and the head of the chain is a trust anchor, i.e., its authenticity is assumed.</t>
          
          <t>Trust schema: a formal description of a trust model, e.g., in the form of a set of name-based relationships between data and key names and a set of the trust anchors.</t>
          
          <!--<t>Security context</t>-->
          
          <t>Trust anchor: an ICN key that is assumed to be trusted within the context of a specific trust model.</t>
        </list></t>
      </section>

      <section anchor="icn-node" title="ICN Node related terms">
        <t><list>
          <t>ICN Interface (same as face): a generalization of the network interface that can represent a physical network interface (ethernet, wifi, bluetooth adapter, etc.), an overlay inter-node channel (IP/UDP tunnel, etc.), or an intra-node IPC channel to an application (unix socket, shared memory, intents, etc.).</t>
          
          <t>ICN Consumer (same as consumer, information consumer, data consumer, consumer of the content): 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.</t>
          
          <t>ICN Producer (same as producer, publisher, information publisher, data publisher, data producer): an ICN entity that creates data packets and makes them available for retrieval.</t>
          
          <t>ICN Forwarder (same as ICN router): an ICN entity that implements stateful forwarding.</t>
          
          <t>Data Mule: an ICN entity that carries an interest or data packet over some distance before forwarding it to next ICN entity.</t>
        </list></t>
      </section>

      <section anchor="stateful-forwarding" title="Stateful forwarding plane related terms">
        <t><list>
          <t>Stateful forwarding (same as ICN Data plane, ICN 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.</t>
          
          <t>Name-based routing: a process of forwarding interest packets using the names in interests to guide the forwarding process</t>
          
          <t>ICN 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.</t>
          
          <!--<t>ICN Data plane:</t>
        <t></t>-->
          
          <t>ICN Routing plane: an ICN protocol or a set of ICN protocols to exchange information about data packet availability.</t>
          
          <t>Satisfying an Interest: a process of forwarding the incoming data packet to the incoming interface(s) recorded in the corresponding PIT entry (entries) and removing the PIT entry (entries).</t>
          
          <t>Interest forwarding strategy (same as 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 ICN Forwarding Information Base (FIB), measured data plane performance parameters, and/or use other mechanisms to make the decision. </t>
          
          <t>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.</t>
          
          <t>Interest match in PIT (exact match): a process of finding a PIT entry that stores the same as specified interest (including interest restrictions, if any).</t>
          
          <t>Data match in PIT (all match): a process of finding (a set of) PIT entries that can be satisfied with the specified data packet.</t>
          
          <t>Interest match in CS (any match): a process of finding an entry in router’s content store that can satisfy the specified interest.</t>
          
          <t>Interest aggregation (same as interest suppression, interest collapsing): a process of combining multiple interest packets for the same data into a single PIT entry.</t>
          
          <t>ICN Forwarding Information Base (FIB): a database that, for a set of prefixes, records a list of interfaces that can be used to retrieve data packets with names under the corresponding prefixes. The list of interfaces for each prefix can be ranked, and prefix/interfaces mapping , and interfaces can be associated with the additional information to facilitate forwarding strategy decisions.</t>
          
          <t>ICN Routing Information Base (RIB): a database that records a set of prefix-interface mappings that represent a candidate interface through which a data packet with the specified prefix can be retrieved. RIB can be used to populate FIB.</t>
          
          <t>Interest Nack (same as network NACK, interest return): a packet that contains the interest packet and optional annotation, which is sent by the router to the interface(s) the Interest was received from. Interest Nack is used to inform downstream ICN nodes about inability to forward the included interest packet. The annotation can describe the reason.</t>
          
          <t>Upstream forwarding: forwarding packets in the direction of interests (i.e., interests are forwarded upstream): consumer, router, router, …, producer.</t>
          
          <t>Downstream forwarding: forwarding packets in the direction opposite of interest forwarding (i.e., data and interest nacks are forwarded downstream): producer, router, …, consumer(s).</t>
          
          <t>In-network storage: a process of storing a data packet within the network (in routers opportunistic on-path caches, in 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>
          
          <t>Opportunistic caching (or on-path in-network caching or just 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.</t>
          
          <t>Managed caching (or off-path in-network storage): a process of temporarily, permanently, or scheduled storing of a selected (set of) data packet(s).</t>
          
          <t>Content Store (CS): a database on an ICN router to implement the opportunistic caching.</t>
          
          <t>Managed in-network storage (repository, repo): an entity acting as an ICN producer that implements managed caching.</t>
          
          <!--<t>Off-path caching:</t>
        <t></t>-->
          
          <!--<t>On-path caching:</t>
        <t></t>-->
          
          <!--<t>Cache poisoning</t>-->
          
          <!--<t>Name mapping resolution (same as name resolution, name mapping):</t>
        <t></t>-->
          <!-- AA: this seem to be not the right place. This implies a routing scalability solution that uses name mapping. May be we have a dedicated section on that -->
        </list></t>
      </section>

      <section anchor="specific-solutions" title="Specific solution related terms">
          <t><list>
            <t>Route-By-Name Routing (RBNR)</t>
            <t>Lookup-By-Name Routing (LBNR)</t>
            <t>Bread-crumbs routing</t>
            <t>Replication-by-name</t>
            <t>Routing Locator Signing</t>
          </list></t>
      </section>

      <section anchor="uncategorized" title="Uncategorized terms">
        <t><list>
        <t>Chunks (same as segments)</t>
        <t>Content based</t>
        <t>ICN API</t>
        <t>Information Centric Delay Tolerant Network</t>
        <t>Located-Named-Data</t>
        <t>NDN</t>
        <t>Sessionless</t>
        </list></t>
      </section>
    </section>

  </middle>

  <back>
    <references title="Informational References">
      <reference anchor="RFC7476"
                 target="http://www.rfc-editor.org/info/rfc7476">
        <front>
          <title>Information-Centric Networking: Baseline Scenarios</title>

          <author fullname="K. Pentikousis" initials="K." role="editor"
                  surname="Pentikousis">
            <organization/>
          </author>

          <author fullname="B. Ohlman" initials="B." surname="Ohlman">
            <organization/>
          </author>

          <author fullname="D. Corujo" initials="D." surname="Corujo">
            <organization/>
          </author>

          <author fullname="G. Boggia" initials="G." surname="Boggia">
            <organization/>
          </author>

          <author fullname="G. Tyson" initials="G." surname="Tyson">
            <organization/>
          </author>

          <author fullname="E. Davies" initials="E." surname="Davies">
            <organization/>
          </author>

          <author fullname="A. Molinaro" initials="A." surname="Molinaro">
            <organization/>
          </author>

          <author fullname="S. Eum" initials="S." surname="Eum">
            <organization/>
          </author>

          <date month="March" year="2015"/>

          <abstract>
            <t>This document aims at establishing a common understanding about
            a set of scenarios that can be used as a base for the evaluation
            of different information-centric networking (ICN) approaches so
            that they can be tested and compared against each other while
            showcasing their own advantages. Towards this end, we review the
            ICN literature and document scenarios which have been considered
            in previous performance evaluation studies. We discuss a variety
            of aspects that an ICN solution can address. This includes general
            aspects, such as, network efficiency, reduced complexity,
            increased scalability and reliability, mobility support, multicast
            and caching performance, real-time communication efficiency,
            energy consumption frugality, and disruption and delay tolerance.
            We detail ICN-specific aspects as well, such as information
            security and trust, persistence, availability, provenance, and
            location independence.</t>

            <t>This document is a product of the IRTF Information-Centric
            Networking Research Group (ICNRG).</t>
          </abstract>
        </front>

        <seriesInfo name="RFC" value="7476"/>

        <seriesInfo name="DOI" value="10.17487/RFC7476"/>
      </reference>
      <reference anchor="I-D.irtf-icnrg-challenges">
        <front>
          <title>ICN Research Challenges</title>
          <author initials="D" surname="Kutscher" fullname="Dirk Kutscher">
            <organization/>
          </author>
          <author initials="S" surname="Eum" fullname="Suyong Eum">
            <organization/>
          </author>
          <author initials="K" surname="Pentikousis" fullname="Kostas Pentikousis">
            <organization/>
          </author>
          <author initials="I" surname="Psaras" fullname="Ioannis Psaras">
            <organization/>
          </author>
          <author initials="D" surname="Corujo" fullname="Daniel Corujo">
            <organization/>
          </author>
          <author initials="D" surname="Saucez" fullname="Damien Saucez">
            <organization/>
          </author>
          <author initials="T" surname="Schmidt" fullname="Thomas C. Schmidt">
            <organization/>
          </author>
          <author initials="M" surname="Waehlisch" fullname="Matthias Waehlisch">
            <organization/>
          </author>
          <date month="March" day="19" year="2016"/>
          <abstract>
            <t>
              This memo describes research challenges for Information-Centric Networking (ICN), an approach to evolve the Internet infrastructure to directly support information distribution by introducing uniquely named data as a core Internet principle. Data becomes independent from location, application, storage, and means of transportation, enabling or enhancing a number of desirable features, such as security, user-mobility, multicast and in-network caching. Mechanisms for realizing these benefits is subject of on-going research in the IRTF and elsewhere. This document describes current research challenges in ICN, including naming, security, routing, system scalability, mobility management, wireless networking, transport services, in-network caching, and network management. This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).
            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-irtf-icnrg-challenges-06"/>
        <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-irtf-icnrg-challenges-06.txt"/>
      </reference>
      <reference anchor="I-D.irtf-icnrg-evaluation-methodology">
        <front>
          <title>
            Information-centric Networking: Evaluation and Security Considerations
          </title>
          <author initials="K" surname="Pentikousis" fullname="Kostas Pentikousis">
            <organization/>
          </author>
          <author initials="B" surname="Ohlman" fullname="Borje Ohlman">
            <organization/>
          </author>
          <author initials="E" surname="Davies" fullname="Elwyn B. Davies">
            <organization/>
          </author>
          <author initials="S" surname="Spirou" fullname="Spiros Spirou">
            <organization/>
          </author>
          <author initials="G" surname="Boggia" fullname="Gennaro Boggia">
            <organization/>
          </author>
          <date month="April" day="12" year="2016"/>
          <abstract>
            <t>
              This document presents a number of considerations regarding evaluating Information-centric Networking (ICN) and sheds some light on the impact of ICN on network security. It also surveys the evaluation tools currently available to researchers in the ICN area and provides suggestions regarding methodology and metrics.
            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-irtf-icnrg-evaluation-methodology-05"/>
        <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-irtf-icnrg-evaluation-methodology-05.txt"/>
      </reference>
      <reference anchor="I-D.irtf-icnrg-videostreaming">
        <front>
          <title>Adaptive Video Streaming over ICN</title>
          <author initials="c" surname="cedric.westphal@huawei.com" fullname="cedric.westphal@huawei.com">
            <organization/>
          </author>
          <author initials="S" surname="Lederer" fullname="Stefan Lederer">
            <organization/>
          </author>
          <author initials="C" surname="Mueller" fullname="Christopher Mueller">
            <organization/>
          </author>
          <author initials="A" surname="Detti" fullname="Andrea Detti">
            <organization/>
          </author>
          <author initials="D" surname="Corujo" fullname="Daniel Corujo">
            <organization/>
          </author>
          <author initials="J" surname="Wang" fullname="Jianping Wang">
            <organization/>
          </author>
          <author initials="M" surname="Montpetit" fullname="Marie-Jose Montpetit">
            <organization/>
          </author>
          <author initials="N" surname="Murray" fullname="Niall Murray">
            <organization/>
          </author>
          <author initials="C" surname="Timmerer" fullname="Christian Timmerer">
            <organization/>
          </author>
          <author initials="D" surname="Posch" fullname="Daniel Posch">
            <organization/>
          </author>
          <author initials="a" surname="aytav.azgin" fullname="aytav.azgin">
            <organization/>
          </author>
          <author initials="S" surname="(Will)" fullname="Shucheng LIU (Will)">
            <organization/>
          </author>
          <date month="April" day="28" year="2016"/>
          <abstract>
            <t>
              This document considers the consequences of moving the underlying network architecture from the current Internet to an Information- Centric Network (ICN) architecture on video distribution. As most of the traffic in future networks is expected to be video, we consider how to modify the existing video streaming mechanisms. Several important topics related to video distribution over ICN are presented, covering a wide range of scenarios: we look at how to evolve DASH to work over ICN, and leverage the recent ISO/IEC Moving Picture Experts Group (MPEG) Dynamic Adaptive Streaming over HTTP (DASH) standard; we consider layered encoding over ICN; Peer-to-Peer (P2P) mechanisms introduce distinct requirements for video and we look at how to adapt PPSP for ICN; Internet Protocol Television (IPTV) adds delay constraints, and this will create more stringent requirements over ICN as well. As part of the discussion on video, we discuss Digital Rights Management (DRM) in ICN. Finally, in addition to considering how existing mechanisms would be impacted by ICN, this document lists some research issues to design ICN specific video streaming mechanisms.
            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-irtf-icnrg-videostreaming-08"/>
        <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-irtf-icnrg-videostreaming-08.txt"/>
      </reference>
      <reference anchor="I-D.irtf-icnrg-ccnxmessages">
        <front>
          <title>CCNx Messages in TLV Format</title>
          <author initials="m" surname="marc.mosko@parc.com" fullname="marc.mosko@parc.com">
            <organization/>
          </author>
          <author initials="I" surname="Solis" fullname="Ignacio Solis">
            <organization/>
          </author>
          <author initials="c" surname="cwood@parc.com" fullname="cwood@parc.com">
            <organization/>
          </author>
          <date month="June" day="28" year="2016"/>
          <abstract>
            <t>
              This document specifies the encoding of CCNx messages using a TLV Packet specification. CCNx messages follow the CCNx Semantics specification. This document defines the TLV types used by each message element and the encoding of each value.
            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-irtf-icnrg-ccnxmessages-03"/>
        <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-irtf-icnrg-ccnxmessages-03.txt"/>
      </reference>
      <reference anchor="I-D.irtf-icnrg-ccnxsemantics">
        <front>
          <title>CCNx Semantics</title>
          <author initials="m" surname="marc.mosko@parc.com" fullname="marc.mosko@parc.com">
            <organization/>
          </author>
          <author initials="I" surname="Solis" fullname="Ignacio Solis">
            <organization/>
          </author>
          <author initials="c" surname="cwood@parc.com" fullname="cwood@parc.com">
            <organization/>
          </author>
          <date month="June" day="28" year="2016"/>
          <abstract>
            <t>
              This document describes the core concepts of the CCNx architecture and presents a minimum 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. The protocol also uses a Control message called an InterestReturn, 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>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-irtf-icnrg-ccnxsemantics-03"/>
        <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-irtf-icnrg-ccnxsemantics-03.txt"/>
      </reference>      
      <reference anchor="I-D.irtf-icnrg-disaster">
        <front>
          <title>Using ICN in disaster scenarios</title>
          <author initials="J" surname="Seedorf" fullname="Jan Seedorf">
            <organization/>
          </author>
          <author initials="M" surname="Arumaithurai" fullname="Mayutan Arumaithurai">
            <organization/>
          </author>
          <author initials="A" surname="Tagami" fullname="Atsushi Tagami">
            <organization/>
          </author>
          <author initials="K" surname="Ramakrishnan" fullname="K. Ramakrishnan">
            <organization/>
          </author>
          <author initials="N" surname="Blefari-Melazzi" fullname="Nicola Blefari-Melazzi">
            <organization/>
          </author>
          <date month="February" day="18" year="2016"/>
          <abstract>
            <t>
              Information Centric Networking (ICN) is a new paradigm where the network provides users with named content, instead of communication channels between hosts. This document outlines some research directions for Information Centric Networking with respect to applying ICN approaches for coping with natural or human-generated, large-scale disasters.
            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-irtf-icnrg-disaster-00"/>
        <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-irtf-icnrg-disaster-00.txt"/>
      </reference>
    </references>
  
    <section anchor="acknowledgements" title="Acknowledgments">
      <t>The authors would like to thank Christian Tschudin for providing suggestions on the structure of the document and some of the ICN related terms.</t>
    </section>
  </back>
</rfc>
