idnits 2.17.1 draft-wissingh-icnrg-terminology-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2599 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.irtf-icnrg-ccnxmessages' is defined on line 605, but no explicit reference was found in the text == Unused Reference: 'I-D.irtf-icnrg-ccnxsemantics' is defined on line 610, but no explicit reference was found in the text == Unused Reference: 'I-D.irtf-icnrg-challenges' is defined on line 615, but no explicit reference was found in the text == Unused Reference: 'I-D.irtf-icnrg-disaster' is defined on line 621, but no explicit reference was found in the text == Unused Reference: 'I-D.irtf-icnrg-evaluation-methodology' is defined on line 627, but no explicit reference was found in the text == Unused Reference: 'I-D.irtf-icnrg-videostreaming' is defined on line 633, but no explicit reference was found in the text == Unused Reference: 'RFC7476' is defined on line 640, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-irtf-icnrg-ccnxmessages-03 == Outdated reference: A later version (-10) exists of draft-irtf-icnrg-ccnxsemantics-03 == Outdated reference: A later version (-10) exists of draft-irtf-icnrg-disaster-00 Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 icnrg B. Wissingh 3 Internet-Draft TNO 4 Intended status: Informational C. Wood 5 Expires: September 14, 2017 University of California Irvine 6 A. Afanasyev 7 L. Zhang 8 UCLA 9 D. Oran 10 Network Systems Research & Design 11 C. Tschudin 12 University of Basel 13 March 13, 2017 15 Information-Centric Networking (ICN): Terminology 16 draft-wissingh-icnrg-terminology-01 18 Abstract 20 Information Centric Networking (ICN) is a new paradigm where network 21 communications are accomplished by requesting named content, instead 22 of sending packets to destination addresses. Named Data Networking 23 (NDN) and Content-Centric Networking (CCN) are two prominent ICN 24 architectures. This document provides an overview of the terminology 25 and definitions that have been used in describing concepts in these 26 two projects. While there are other ICN architectures, they are not 27 part of the NDN and CCN vision and as such are out of scope for this 28 document. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 14, 2017. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. A Sketch of the Big Picture of ICN . . . . . . . . . . . . . 3 66 3. Terms by category . . . . . . . . . . . . . . . . . . . . . . 5 67 3.1. Generic terms . . . . . . . . . . . . . . . . . . . . . . 5 68 3.2. Terms related to Name Types . . . . . . . . . . . . . . . 6 69 3.3. Terms related to Name Usage . . . . . . . . . . . . . . . 7 70 3.4. Terms related to Data-Centric Security . . . . . . . . . 8 71 3.5. ICN Node related terms . . . . . . . . . . . . . . . . . 9 72 3.6. Stateful forwarding plane related terms . . . . . . . . . 10 73 3.7. Specific solution related terms . . . . . . . . . . . . . 12 74 3.8. Uncategorized terms . . . . . . . . . . . . . . . . . . . 12 75 4. Semantics and Usage . . . . . . . . . . . . . . . . . . . . . 12 76 4.1. Data Transfer . . . . . . . . . . . . . . . . . . . . . . 13 77 4.2. Data Transport . . . . . . . . . . . . . . . . . . . . . 13 78 4.3. Lookup Service . . . . . . . . . . . . . . . . . . . . . 13 79 4.4. Database Access . . . . . . . . . . . . . . . . . . . . . 13 80 4.5. Remote Procedure Call . . . . . . . . . . . . . . . . . . 13 81 5. Informational References . . . . . . . . . . . . . . . . . . 13 82 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 85 1. Introduction 87 Information-centric networking (ICN) is an approach to evolve the 88 Internet infrastructure from the existing host-centric design to a 89 data-centric architecture where accessing data by name becomes the 90 essential network primitive. The goal is to let applications refer 91 to data independently of their location or means of transportation, 92 which --for immutable data items-- enables native multicast delivery, 93 ubiquitous in-network caching and replication of data objects. 95 As the work on this topic continues to evolve, many new terms are 96 emerging over time. The goal of this document is to provide a 97 thorough collection of these terms with a corresponding definition as 98 they are used in the CCNx and NDN projects. Other, historic ICN 99 projects like NetInf, XIA or Mobility First are not covered and will 100 be the subject of other documents. 102 To help provide context for the individual terms to be defined, in 103 this draft we first sketch the bigger picture of an ICN network by 104 introducing the basic concepts and identifying the major components 105 of the architecture in section 2 after which in section 3 ICN related 106 terms are listed by different categories. 108 2. A Sketch of the Big Picture of ICN 110 In networking terms, an ICN is a delivery infrastructure for named 111 data. For other, complementing views see Section 4. 113 requestor zero or more data sources or 114 (node) forwarding nodes replica nodes 115 | | ... | |...| 116 | Interest(n) | | Interest(n) | | 117 | --------------> | | ---------------> | | 118 | | | -------------------> | 119 | | | | | 120 | | | Data([n],c,[s]) | | 121 | | | <--------------- | | 122 | | | <------------------- | 123 | Data([n],c,[s]) | | | | 124 | <-------------- | | | | 126 Figure 1: Request-Reply Protocol of ICN networking. Legend: n=name, 127 c=content, s=signature. 129 The following list describes the basic ICN concepts needed to discuss 130 the implementation of this service abstraction. 132 Request-Reply Protocol (Interest and Data Packet): 134 An ICN's lookup service is implemented by defining two types of 135 network packet formats: Interest packets that request content by 136 name, and data packets that carry the requested content. The 137 returned data packet must match the request's parameters (e.g., 138 having a partially or fully matching name). If the request is 139 ambigious and several data packets would satisfy the request, the ICN 140 network will typically return only one matching data packet. 142 Packet and Content Names: 144 Without an irrefutable binding between a name of a data packet and 145 its content, data packet names would be useless for fetching specific 146 content. In ICN, verification of a data packet's name-to-content 147 binding is achieved through cryptographic means, either by (1) a 148 cryptographic signature that explicitely binds an application-chosen 149 name to a data packet's content, or (2) relying on an implicit name 150 (cryptographic hash of the data packet) that the data consumer 151 obtained through other means. 153 Data Authenticity and Encryption: 155 Any data consumer and network element can validate the authenticity 156 of a data packet by verifying its cryptographic name-to-content 157 binding. In contrast, whether a data packet's content (payload) 158 itself is encrypted or not is irrelevant to the ICN network: The use 159 and management of content encryption keys is an application-layer 160 concern. 162 Trust: 164 Data authenticity is distinct from data trustworthiness, though the 165 two concepts are related. A packet is authentic if it has a valid 166 name-to-content binding. A packet is trustworthy, i.e., it comes 167 from a reputable or trusted origin, if this binding is only valid in 168 the context of a trust model. For example, if a corresponding trust 169 infrastructure (e.g., PKI) is in place, a packet's signature even 170 enables to assess authenticity with relation to to real world 171 identities which can be trusted or not. 173 Segmenting and Versioning: 175 An ICN network will be engineered for some packet size limit. As 176 application-level data objects will often be considerably larger, 177 objects must be segmented into multiple data packets. The names for 178 these data packets can, for example, be constructed by choosing one 179 application-level object name to which a different suffix is added 180 for each segment. The same method can be used to handle different 181 versions of an application-level object by including a version number 182 into the name of the overall object. 184 Packet and Frame: 186 NDN and CCN introduce Protocol Data Units (PDUs) which typically are 187 larger than the maximum transmission unit of the underlying 188 networking technology. We refer to PDUs as 'packets' and the 189 (potentially fragmented) packet parts that traverse MTU-bound links 190 as 'frames'. Handling link-layer technologies which lead to 191 fragmentation of ICN packets is done inside the ICN network and is 192 not visible at the service interface. 194 ICN Node: 196 A node within an ICN network can fulfill the role of a data producer, 197 a data consumer, and/or a forwarder for interest and data packets. 198 When a forwarder has connectivity to neighbor nodes, it performs 199 interest and data packet forwarding in real time. It can also behave 200 like a packet mule, that is it may carry an interest or data packet 201 for some time before forwarding it to next node. An ICN node may 202 also run routing protocols to assist its interest forwarding 203 decisions. 205 --> add ASCII art here 206 (of a forwarding node 207 and its PIT, FIB, CS) 209 Figure 2: Structure of an ICN forwarding node. 211 Forwarding Plane: 213 The canonical way of implementing packet forwarding in an ICN network 214 like NDN and CCN relies on three data structures that capture a 215 node's state: a Forwarding Interest Table (FIB), a Pending Interest 216 Table (PIT), and a Content Store (CS). It also utilizes interest 217 forwarding strategies which takes input from both FIB and 218 measurements to make interest forwarding decisions. When a node 219 receives an ICN interest packet, it checks its CS and PIT to find a 220 matching name; if no match is found, the node records the interest in 221 its PIT and forwards the interest to the next hop(s) towards the 222 requested content based on the information in its FIB. There exist 223 alternative approaches which aim at reducing the amount of state that 224 a nodes must keep, up to fully PIT-less designs using packets for 225 keeping state but without changing the overall service model. 227 3. Terms by category 229 3.1. Generic terms 231 Information-Centric Networking (ICN): a networking architecture 232 that retrieves data packets as response to interest packets. 233 Content-Centric Networking (CCN) and Named Data Networking (NDN) 234 are two types of ICN architectures. 236 Data packet: a network-level packet that carries payload, uniquely 237 identified by a name, and is directly secured. 239 Common aliases include: data, data object, content object, 240 content object packet, data message, named data object, named 241 data. 243 Interest packet: a network-level packet that expresses the request 244 for a data packet using either an exact name or a name prefix. An 245 interest packet may optionally carry a set of additional 246 restrictions (e.g. interest selectors). An interest may be 247 associated with additional information to facilitate forwarding 248 and can include interest lifetime, hop limit, forwarding hints, 249 labels, etc. In different ICN designs, the set of additional 250 associated information may vary. 252 Common aliases include: interest, interest message, information 253 request 255 Data packet immutability: after a data packet is created, it 256 cannot change. If the content carried in the data packet is 257 mutable, versioning should be used, so that each version uniquely 258 identifies an immutable instance of the content. This allows 259 disambiguation of coordination in distributed systems. 261 3.2. Terms related to Name Types 263 Name: a data packet identifier. An ICN name is expressive, 264 flexible and can be application-specific (akin to a HTTP URL). A 265 Name may encode information about application context, semantics, 266 locations (topological, geographical, hyperbolic, etc.), a service 267 name, etc. A Name is a sequence of non-empty name components (see 268 below). The components of a name are said to be complete if they 269 uniquely identify a single data packet. A Name is exact if its 270 components are complete. 272 Common aliases include: data name, interest name, content name. 274 Name component: a sequence of octets and optionally a numeric type 275 representing a single label in the hierarchical structured name. 277 Common aliases include: name segment (as in CCN). 279 Packet ID: a unique cryptographic identifier for a data packet. 280 Typically, this is the cryptographic hash digest of a data packet, 281 including its name, payload, meta information, and signature. 283 Full Name: An exact Name with the Packet ID of the corresponding 284 data packet. 286 Prefix Name: A Name with incomplete components. 288 Common aliases include: prefix. 290 Selector: Depending on the implementation, some restrictors show 291 up as name components or as explicit fields of an interest. 292 Selectors are not 'names' in a proper sense although they are able 293 to "name content." Examples include selectors used to reference 294 nameless objects, specify publisher restriction, etc. In that 295 sense, a single data packet will have multiple 'name-like 296 properties' through which it can be referenced, interest packets 297 are able to express them. 299 Common aliases include: restrictor. 301 Nonce: Field of an interest packet that transiently 'names' an 302 interest instance. 304 3.3. Terms related to Name Usage 306 Naming scheme (ICN naming scheme): a convention/agreement/ 307 specification for the data packet naming. Structures a name 308 space. 310 Hierarchically structured naming: the naming scheme that assigns 311 and interprets name as a sequence of labels (name components) with 312 hierarchical structure. A structure provides useful context 313 information for the name. 315 Common aliases include: hierarchical naming, structured naming. 317 Flat naming: the naming scheme that assigns and interprets name as 318 a single label (name component) without any internal structure. 319 This can be considered a special (or degenerated) case of 320 structured names. 322 Segmentation: a process of splitting large application content 323 into a set of uniquely named data packets. When using 324 hierarchically structured name, each created data packet has a 325 common prefix and additional component representing the segment 326 (chunk) number. 328 Common aliases include: chunking (as in CCN). 330 Versioning: a process of assigning a unique name to the revision 331 of the content carried in the data packet. When using a 332 hierarchically structured name, the version of the data packet can 333 be carried in a dedicated name component (e.g., prefix identifies 334 data, unique version component identifies the revision of the 335 data). 337 Fragmentation: a process of splitting data packets into frames so 338 that they can be transmitted over the link with a smaller MTU 339 size. 341 3.4. Terms related to Data-Centric Security 343 Directly secured data packet: a data packet with inherent security 344 properties (authenticity and optionally confidentiality), i.e., 345 the security properties stay with the data packet regardless where 346 it is stored and how it is retrieved. 348 Data authenticator: a set of parameters carried in the data packet 349 that is used to verify integrity and authenticity of the data 350 packet. The Data authenticator can include a cryptographic 351 signature (RSA, ECDSA, HMAC, etc.), meta information about the 352 signature (e.g., validity period), and additional information to 353 facilitate signature verification (e.g., key locator, key ID, HMAC 354 tag identifier, etc.) 356 Common aliases include: content authenticator. 358 Data confidentiality credentials: a set of parameters carried in 359 the data packet that identify the needed algorithm and key 360 identifiers to decrypt the confidential data. 362 Key owner (same as Identity): an entity (user, device, program, 363 program instance, module in the program instance, etc.) that owns 364 private key(s) and the corresponding public key(s). 366 Certificate: a data packet that carries a public key as payload 367 with optional additional meta information regarding the key (e.g., 368 validity period, signature time, etc.). Ownership of the public 369 key is made implicitly through the name of the packet or 370 explicitly through meta information. 372 Key locator: Parameter(s) that identify the ICN key. A key 373 locatore can be the ICN key's name, its prefix, the ICN key ID, 374 etc. 376 Key ID: Unique identifier (e.g., hash digest) for a public or 377 secret key. 379 Trust model: a model or framework that defines trust 380 relationships, i.e., which entity (represented by an ICN key) is 381 authorized to sign which data packets. 383 Trust schema: a formal description of a trust model, e.g., in the 384 form of a set of name-based relationships between data and key 385 names and a set of the trust anchors. 387 Trust anchor: an ICN key that is assumed to be trusted within the 388 context of a specific trust model. 390 ICN key chain: a chain of ICN keys (certificates) wherein each key 391 (certificate) is signed by its predecessor and the head of the 392 chain is a trust anchor, i.e., its authenticity is assumed. 394 Common aliases include: certificate chain. 396 3.5. ICN Node related terms 398 ICN Interface: a generalization of the network interface that can 399 represent a physical network interface (ethernet, wifi, bluetooth 400 adapter, etc.), an overlay inter-node channel (IP/UDP tunnel, 401 etc.), or an intra-node IPC channel to an application (unix 402 socket, shared memory, intents, etc.). 404 Common aliases include: face. 406 ICN Consumer: an ICN entity that requests data packets by 407 generating and sending out interest packets towards local (using 408 intra-node interfaces) or remote (using inter-node interfaces) ICN 409 Forwarders. 411 Common aliases include: consumer, information consumer, data 412 consumer, consumer of the content. 414 ICN Producer: an ICN entity that creates data packets and makes 415 them available for retrieval. 417 Common aliases include: producer, publisher, information 418 publisher, data publisher, data producer. 420 ICN Forwarder: an ICN entity that implements stateful forwarding. 422 Common aliases include: ICN router. 424 Data Mule: an ICN entity that temporarily stores and potentially 425 carries an interest or data packet before forwarding it to next 426 ICN entity. 428 3.6. Stateful forwarding plane related terms 430 Stateful forwarding: a forwarding process that records incoming 431 interest packets in the PIT and uses the recorded information to 432 forward the retrieved data packets back to the consumer(s). The 433 recorded information can also be used to measure data plane 434 performance, e.g., to adjust interest forwarding strategy 435 decisions. 437 Common aliases include: ICN Data plane, ICN Forwarding. 439 Name-based routing: a process of forwarding interest packets using 440 the names in interests to guide the forwarding process 442 ICN Pending Interest Table (PIT): a database that records received 443 and not yet satisfied interests with the interfaces from where 444 they were received. The PIT can also store interfaces to where 445 Interests were forwarded, and information to assess data plane 446 performance. Interests for the same data are aggregated into a 447 single PIT entry. 449 ICN Routing plane: an ICN protocol or a set of ICN protocols to 450 exchange information about name space reachability. 452 Reverse path forwarding: a process of forwarding the incoming data 453 packet to the incoming interface(s) recorded in the corresponding 454 PIT entry (entries) and removing the PIT entry (entries). 456 Interest forwarding strategy: a module of the ICN stateful 457 forwarding (ICN data) plane that implements a decision on where/ 458 how to forward the incoming interest packet. The forwarding 459 strategy can take input from ICN Forwarding Information Base 460 (FIB), measured data plane performance parameters, and/or use 461 other mechanisms to make the decision. 463 Common aliases include: forwarding strategy. 465 Satisfying an interest: overall process of returning content that 466 satisfies the constraints imposed by the Interest, most notably a 467 match in the provided name. Four different flavors of "matching" 468 are used in an ICN network, as described below. 470 Interest match in FIB (longest prefix match): a process of finding 471 a FIB entry with the longest name (in terms of name components) 472 that is a prefix of the specified name. 474 Interest match in PIT (exact match): a process of finding a PIT 475 entry that stores the same as specified interest (including 476 interest restrictions, if any). 478 Data match in PIT (all match): a process of finding (a set of) PIT 479 entries that can be satisfied with the specified data packet. 481 Interest match in CS (any match): a process of finding an entry in 482 router's content store that can satisfy the specified interest. 484 Interest aggregation: a process of combining multiple interest 485 packets for the same data into a single PIT entry. 487 Common aliases include: interest suppression, interest 488 collapsing. 490 ICN Forwarding Information Base (FIB): a database that, for a set 491 of prefixes, records a list of interfaces that can be used to 492 retrieve data packets with names under the corresponding prefixes. 493 The list of interfaces for each prefix can be ranked, and prefix/ 494 interfaces mapping , and interfaces can be associated with the 495 additional information to facilitate forwarding strategy 496 decisions. 498 ICN Routing Information Base (RIB): a database that records a set 499 of prefix-interface mappings that represent a candidate interface 500 through which a data packet with the specified prefix can be 501 retrieved. RIB can be used to populate FIB. 503 Interest Nack: a packet that contains the interest packet and 504 optional annotation, which is sent by the router to the 505 interface(s) the Interest was received from. Interest Nack is 506 used to inform downstream ICN nodes about inability to forward the 507 included interest packet. The annotation can describe the reason. 509 Common aliases include: network NACK, interest return. 511 Upstream forwarding: forwarding packets in the direction of 512 interests (i.e., interests are forwarded upstream): consumer, 513 router, router, ..., producer. 515 Downstream forwarding: forwarding packets in the direction 516 opposite of interest forwarding (i.e., data and interest nacks are 517 forwarded downstream): producer, router, ..., consumer(s). 519 In-network storage: a process of storing a data packet within the 520 network (in routers opportunistic on-path caches, in dedicated on/ 521 off path caches, and managed in-network storage systems), so it 522 can satisfy an incoming interest for this data packet. The in- 523 network storages can optionally advertise the stored data packets 524 in the routing plane. 526 Opportunistic caching (or on-path in-network caching or just 527 caching): a process of temporarily storing a forwarded data packet 528 in the router's memory (RAM or disk), so it can be used to satisfy 529 future interests for the same data, if any. 531 Managed caching (or off-path in-network storage): a process of 532 temporarily, permanently, or scheduled storing of a selected (set 533 of) data packet(s). 535 Content Store (CS): a database on an ICN router that provides 536 opportunistic caching. 538 Managed in-network storage (repository, repo): an entity acting as 539 an ICN producer that implements managed caching. 541 3.7. Specific solution related terms 543 Route-By-Name Routing (RBNR) 545 Lookup-By-Name Routing (LBNR) 547 Bread-crumbs routing 549 Replication-by-name 551 Routing Locator Signing 553 3.8. Uncategorized terms 555 Content based 557 ICN API 559 Information Centric Delay Tolerant Network 561 Located-Named-Data 563 Sessionless 565 4. Semantics and Usage 567 The terminology described above is the manifestation of intended 568 semantics of NDN and CCN operations (what do we expect the network to 569 do?). In this section we summarize the most commonly proposed use 570 cases and interpretations. 572 4.1. Data Transfer 574 The networking view of NDN and CCN is that the request/reply protocol 575 implements a basic, unreliable data transfer service for single, 576 named packets. 578 4.2. Data Transport 580 Data transfer can be turned into a data transport service for 581 application-level objects by additional logic. This transport logic 582 must understand and construct the series of names needed to 583 reassemble the segmented object. Various flavors of transport can be 584 envisaged (reliable, streaming, mailbox, etc) 586 4.3. Lookup Service 588 A more distributed systems view of the basic request/reply protocol 589 is that NDN and CCN provide a distributed lookup service: Given a key 590 value (=name), the service will return the corresponding value. 592 4.4. Database Access 594 The lookup service turns into a database access protocol by ... 595 namespace design ... prefix standing for a collection ... The DB 596 query expression must be encoded as a name. 598 4.5. Remote Procedure Call 600 More generally, ... parameters in the interest ... used e.g. as 601 command channel for remote control of neighbor routers. 603 5. Informational References 605 [I-D.irtf-icnrg-ccnxmessages] 606 marc.mosko@parc.com, m., Solis, I., and c. cwood@parc.com, 607 "CCNx Messages in TLV Format", draft-irtf-icnrg- 608 ccnxmessages-03 (work in progress), June 2016. 610 [I-D.irtf-icnrg-ccnxsemantics] 611 marc.mosko@parc.com, m., Solis, I., and c. cwood@parc.com, 612 "CCNx Semantics", draft-irtf-icnrg-ccnxsemantics-03 (work 613 in progress), June 2016. 615 [I-D.irtf-icnrg-challenges] 616 Kutscher, D., Eum, S., Pentikousis, K., Psaras, I., 617 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 618 "ICN Research Challenges", draft-irtf-icnrg-challenges-06 619 (work in progress), March 2016. 621 [I-D.irtf-icnrg-disaster] 622 Seedorf, J., Arumaithurai, M., Tagami, A., Ramakrishnan, 623 K., and N. Blefari-Melazzi, "Using ICN in disaster 624 scenarios", draft-irtf-icnrg-disaster-00 (work in 625 progress), February 2016. 627 [I-D.irtf-icnrg-evaluation-methodology] 628 Pentikousis, K., Ohlman, B., Davies, E., Spirou, S., and 629 G. Boggia, "Information-centric Networking: Evaluation and 630 Security Considerations", draft-irtf-icnrg-evaluation- 631 methodology-05 (work in progress), April 2016. 633 [I-D.irtf-icnrg-videostreaming] 634 cedric.westphal@huawei.com, c., Lederer, S., Mueller, C., 635 Detti, A., Corujo, D., Wang, J., Montpetit, M., Murray, 636 N., Timmerer, C., Posch, D., aytav.azgin, a., and S. 637 (Will), "Adaptive Video Streaming over ICN", draft-irtf- 638 icnrg-videostreaming-08 (work in progress), April 2016. 640 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 641 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 642 "Information-Centric Networking: Baseline Scenarios", 643 RFC 7476, DOI 10.17487/RFC7476, March 2016, 644 . 646 Appendix A. Acknowledgments 648 Mark Mosco, ... 650 Authors' Addresses 652 Bastiaan Wissingh 653 TNO 655 EMail: bastiaan.wissingh@tno.nl 657 Christopher A. Wood 658 University of California Irvine 660 EMail: woodc1@uci.edu 662 Alex Afanasyev 663 UCLA 665 EMail: aa@cs.ucla.edu 667 Lixia Zhang 668 UCLA 670 EMail: lixia@cs.ucla.edu 672 David Oran 673 Network Systems Research & Design 675 EMail: daveoran@orandom.net 677 Christian Tschudin 678 University of Basel 680 EMail: christian.tschudin@unibas.ch