Re: [xml2rfc] Some problems with idnits checks on V3 document

[Henrik Levkowetz <[e-mail]>]

Hi Dave,

On 2020-03-31 15:58, David R. Oran wrote:
> One of these seem to be xml2rfc rendering problem; others may be idnit 
> glitches that only show up on V3 docs:
> 
> - The too long line 1551 is in fact not too long - the length 
> computation seems to be screwed up by the non-ascii characters (probably 
> idnit problem?)

Yes, that's right.  Will see what can be done.

> - somehow xml2rfc elided part of an author name into the updates head 
> field and author address into the Intended Status header field. This 
> only happens in the .txt output, not the HTML or PDF. xml2rfc bug?

Will investigate, and if possible provide a fix in the next release,
due tomorrow.

> - idnits says this has a downref, but I believe that an I.D. marked 
> experimental saying it updates an experimental RFC isn’t a downref, 
> right?

Huh.  I'll check the code.

> I include the idnits output below and the xml file as an attachment 
> (note that this is still a bit private - we haven’t submitted yes)

Understood.

> Let me know of any followup I should do - would like to get this 
> submitted in the next couple of days.

Ack.  Will follow up when I have more information.


Best regards,

	Henrik



> Thanks! DaveO.
> 
> ————————————
> 
> idnits 2.16.03
> 
> 
> tmp/draft-oran-icnrg-reflexive-forwarding.txt:
> tmp/draft-oran-icnrg-reflexive-forwarding.txt(1491): Found non-ascii 
> character (�) in position 18.
> tmp/draft-oran-icnrg-reflexive-forwarding.txt(1500): Found non-ascii 
> character (�) in position 16.
> tmp/draft-oran-icnrg-reflexive-forwarding.txt(1551): Line is too long: 
> the offending characters are 'ch,'
> tmp/draft-oran-icnrg-reflexive-forwarding.txt(1551): Found non-ascii 
> character (�) in position 16.
> tmp/draft-oran-icnrg-reflexive-forwarding.txt(1597): Found non-ascii 
> character (�) in position 67.
> 
> 
>    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:
>    ----------------------------------------------------------------------------
> 
>     == There are 4 instances of lines with non-ascii characters in the 
> document.
> 
> 
>    Checking nits according to https://www.ietf.org/id-info/checklist :
>    ----------------------------------------------------------------------------
> 
>    ** There is 1 instance of too long lines in the document, the longest 
> one
>       being 3 characters in excess of 72.
> 
> 
>    Miscellaneous warnings:
>    ----------------------------------------------------------------------------
> 
>    == Unrecognized Status in 'Intended status: Experimental  University 
> of
>       Applied Sciences Emden/Leer', assuming Proposed Standard
> 
>       (Expected one of 'Standards Track', 'Full Standard', 'Draft 
> Standard',
>       'Proposed Standard', 'Best Current Practice', 'Informational',
>       'Experimental', 'Informational', 'Historic'.)
> 
>    == Couldn't figure out when the document was first submitted -- there 
> may
>       comments or warnings related to the use of a disclaimer for 
> pre-RFC5378
>       work that could not be issued because of this.  Please check the 
> Legal
>       Provisions document at https://trustee.ietf.org/license-info to 
> determine
>       if you need the pre-RFC5378 disclaimer.
> 
> 
>    Checking references for intended status: Proposed Standard
>    ----------------------------------------------------------------------------
> 
>       (See RFCs 3967 and 4897 for information about using normative 
> references
>       to lower-maturity documents in RFCs)
> 
>    ** Downref: Normative reference to an Experimental RFC: RFC 8569
> 
>    ** Downref: Normative reference to an Experimental RFC: RFC 8609
> 
> 
>       Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 0 comments 
> (--).
> 
> --------------------------------------------------------------------------------
> 
> 
> 2	ICNRG                                                            D. 
> Oran
> 3	Internet-Draft                       Network Systems Research and 
> Design
> 4	Updates: 8569, 8609 (if approved)                            D. 
> Kutscher
> 5	Intended status: Experimental  University of Applied Sciences 
> Emden/Leer
> 6	Expires: 2 October 2020                                    31 March 
> 2020
> 
> 8	            Reflexive Forwarding for CCNx and NDN Protocols
> 9	                draft-oran-icnrg-reflexive-forwarding-00
> 
> 11	Abstract
> 
> 13	   Current Information-Centric Networking protocols such as CCNx and 
> NDN
> 14	   have a wide range of useful applications in content retrieval and
> 15	   other scenarios that depend only on a robust two-way exchange in 
> the
> 16	   form of a request and response (represented by an _Interest-Data
> 17	   exchange_ in the case of the two protocols noted above).  A number 
> of
> 18	   important applications however, require placing large amounts of 
> data
> 19	   in the Interest message, and/or more than one two-way handshake.
> 20	   While these can be accomplished using independent Interest-Data
> 21	   exchanges by reversing the roles of consumer and producer, such
> 22	   approaches can be both clumsy for applications and problematic 
> from a
> 23	   state management, congestion control, or security standpoint.  
> This
> 24	   specification proposes a _Reflexive Forwarding_ extension to the 
> CCNx
> 25	   and NDN protocol architectures that eliminates the problems 
> inherent
> 26	   in using independent Interest-Data exchanges for such 
> applications.
> 27	   It updates RFC8569 and RFC8609.
> 
> 29	Status of This Memo
> 
> 31	   This Internet-Draft is submitted in full conformance with the
> 32	   provisions of BCP 78 and BCP 79.
> 
> 34	   Internet-Drafts are working documents of the Internet Engineering
> 35	   Task Force (IETF).  Note that other groups may also distribute
> 36	   working documents as Internet-Drafts.  The list of current 
> Internet-
> 37	   Drafts is at https://datatracker.ietf.org/drafts/current/.
> 
> 39	   Internet-Drafts are draft documents valid for a maximum of six 
> months
> 40	   and may be updated, replaced, or obsoleted by other documents at 
> any
> 41	   time.  It is inappropriate to use Internet-Drafts as reference
> 42	   material or to cite them other than as "work in progress."
> 
> 44	   This Internet-Draft will expire on 2 October 2020.
> 
> 46	Copyright Notice
> 
> 48	   Copyright (c) 2020 IETF Trust and the persons identified as the
> 49	   document authors.  All rights reserved.
> 
> 51	   This document is subject to BCP 78 and the IETF Trust's Legal
> 52	   Provisions Relating to IETF Documents (https://trustee.ietf.org/
> 53	   license-info) in effect on the date of publication of this 
> document.
> 54	   Please review these documents carefully, as they describe your 
> rights
> 55	   and restrictions with respect to this document.
> 
> 57	Table of Contents
> 
> 59	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  
>   3
> 60	     1.1.  Problems with pushing data  . . . . . . . . . . . . . . .  
>   4
> 61	     1.2.  Problems with utilizing independent exchanges . . . . . .  
>   5
> 62	   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .  
>   6
> 63	   3.  Overview of the Reflexive Forwarding design . . . . . . . . .  
>   6
> 64	   4.  Naming of Reflexive Interests . . . . . . . . . . . . . . . .  
> 10
> 65	   5.  Forwarder operation for Reflexive Interests . . . . . . . . .  
> 11
> 66	   6.  State coupling between producer and consumer  . . . . . . . .  
> 12
> 67	   7.  Use cases for Reflexive Interests . . . . . . . . . . . . . .  
> 12
> 68	     7.1.  Achieving Remote Method Invocation with Reflexive
> 69	           Interests . . . . . . . . . . . . . . . . . . . . . . . .  
> 12
> 70	     7.2.  RESTful Web Interactions  . . . . . . . . . . . . . . . .  
> 15
> 71	     7.3.  Achieving simple data pull from consumers with reflexive
> 72	           Interests . . . . . . . . . . . . . . . . . . . . . . . .  
> 15
> 73	   8.  Implementation Considerations . . . . . . . . . . . . . . . .  
> 19
> 74	     8.1.  Forwarder implementation considerations . . . . . . . . .  
> 19
> 75	       8.1.1.  Forwarding Information Base (FIB) . . . . . . . . . .  
> 19
> 76	       8.1.2.  Interactions with Interest Lifetime . . . . . . . . .  
> 20
> 77	       8.1.3.  Interactions with Interest aggregation  . . . . . . .  
> 21
> 78	     8.2.  Consumer Implementation Considerations  . . . . . . . . .  
> 21
> 79	       8.2.1.  Data objects returned by the consumer to reflexive 
> name
> 80	               Interests arriving from a producer  . . . . . . . . .  
> 21
> 81	       8.2.2.  Terminating unwanted reflexive Interest exchanges . .  
> 22
> 82	       8.2.3.  Interactions with caching . . . . . . . . . . . . . .  
> 22
> 83	     8.3.  Producer Implementation Considerations  . . . . . . . . .  
> 22
> 84	   9.  Operational Considerations  . . . . . . . . . . . . . . . . .  
> 23
> 85	   10. Mapping to CCNx and NDN packet encodings  . . . . . . . . . .  
> 24
> 86	     10.1.  Packet encoding for CCNx . . . . . . . . . . . . . . . .  
> 24
> 87	     10.2.  Packet encoding for NDN  . . . . . . . . . . . . . . . .  
> 24
> 88	   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  
> 24
> 89	   12. Security Considerations . . . . . . . . . . . . . . . . . . .  
> 25
> 90	     12.1.  Collisions of reflexive Interest names . . . . . . . . .  
> 25
> 91	     12.2.  Additional resource pressure on PIT and FIB  . . . . . .  
> 26
> 92	     12.3.  Privacy Considerations . . . . . . . . . . . . . . . . .  
> 26
> 93	   13. Normative References  . . . . . . . . . . . . . . . . . . . .  
> 27
> 94	   14. Informative References  . . . . . . . . . . . . . . . . . . .  
> 27
> 95	   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  
> 30
> 
> 97	1.  Introduction
> 
> 99	   Current ICN protocols such as CCNx [RFC8569] and [NDN] have a wide
> 100	   range of useful applications in content retrieval and other 
> scenarios
> 101	   that depend only on a robust two-way exchange in the form of a
> 102	   request and response.  These ICN architectures use the terms
> 103	   "consumer" and "producer" for the respective roles of the 
> requester
> 104	   and the responder, and the protocols directly capture the 
> mechanics
> 105	   of the two-way exchange through the "Interest message" carrying 
> the
> 106	   request, and the "Data message" carrying the response.  Through 
> these
> 107	   constructs, the protocols are heavily biased toward a pure _pull-
> 108	   based_ interaction model where requests are small (carrying 
> little or
> 109	   no user-supplied data other than the name of the requested data
> 110	   object), and responses are relatively large - up to an 
> architecture-
> 111	   defined maximum transmission unit (MTU) on the order of kilobytes 
> or
> 112	   tens of kilobytes.
> 
> 114	   A number of important applications however require interaction 
> models
> 115	   more complex than individual request/response interactions in the
> 116	   same direction (i.e. between the same consumer and one or more
> 117	   producers).  Among these we identify three important classes 
> which
> 118	   are the target of the proposed enhancements defined in this
> 119	   specification.  These are described in the following paragraphs.
> 
> 121	   *Remote Method Invocation (RMI, aka RPC):*  When invoking a 
> remote
> 122	      method, it is common for the method to require arguments 
> supplied
> 123	      by the caller.  In conventional TCP/IP style protocols like 
> CORBA
> 124	      or HTTP "Post", these are pushed to the server as part of the
> 125	      message or messages that comprise the request.  In ICN-style
> 126	      protocols there is an unattractive choice between inflating 
> the
> 127	      request initiation with pushed arguments, or arranging to have 
> one
> 128	      or more independent request/responses in the opposite 
> direction
> 129	      for the server to fetch the arguments.  Both of these 
> approaches
> 130	      have substantial disadvantages.  Recently, a viable 
> alternative
> 131	      emerged through the work on RICE [Krol2018] which pioneered 
> the
> 132	      main design elements proposed in this specification.
> 
> 134	   *Phone-Home scenario:*  Applications in sensing, 
> Internet-of-things
> 135	      (IoT) and other types where data is produced unpredictably and
> 136	      needs to be _pushed_ somewhere create a conundrum for the pure
> 137	      pull-based architectures considered here.  If instead one 
> eschews
> 138	      relaxing the size asymmetry between requests and responses, 
> some
> 139	      additional protocol machinery is needed.  Earlier efforts in 
> the
> 140	      ICN community have recognized this issue and designed methods 
> to
> 141	      provoke a cooperating element to issue a request to return the
> 142	      data the originator desires to push, essentially "phoning 
> home" to
> 143	      get the responder to fetch the data.  One that has been 
> explored
> 144	      to some extent is the _Interest-Interest-Data_ exchange
> 145	      [Carzaniga2011], where an Interest is sent containing the 
> desired
> 146	      request as encapsulated data.  CCNx-1.0 Bidirectional Streams
> 147	      [Mosko2017] are also based on a scheme where an Interest is 
> used
> 148	      to signal a name prefix that a consumer has registered for
> 149	      receiving Interests from a peer in a bidirectional streaming
> 150	      session.
> 
> 152	   *Peer state synchronization:*  A large class of applications,
> 153	      typified by those built on top of on reliable order-preserving
> 154	      transport protocols, require initial state synchronization 
> between
> 155	      the peers.  This is accomplished with a three-way (or longer)
> 156	      handshake, since employing a two-way handshake as provided in 
> the
> 157	      existing NDN and CCNx protocols exposes a number of well-know
> 158	      hazards, such as _half-open connections_. When attempted for
> 159	      security-related operations such as key exchange, additional
> 160	      hazards such as _man-in-the-middle_ attacks become trivial to
> 161	      mount.  Existing alternatives, similar to those used in the 
> two
> 162	      examples above, instead utilize either overlapping 
> Interest-Data
> 163	      exchanges in opposite directions (resulting in a four-way
> 164	      handshake) or by adding initialization data to the initial 
> request
> 165	      and employing an Interest-Interest-Data protocol extension as
> 166	      noted in the Phone-home scenarios above.
> 
> 168	   All of the above application interaction models present 
> interesting
> 169	   challenges, as neither relaxing the architecture to support 
> pushing
> 170	   large amounts of data, nor introducing substantial complexities
> 171	   through multiple independent Interest-Data exchanges is an 
> attractive
> 172	   approach.  The following subsections provide further background 
> and
> 173	   justification for why push and/or independent exchanges are
> 174	   problematical.
> 
> 176	1.1.  Problems with pushing data
> 
> 178	   There are two substantial problems with the simple approach of 
> just
> 179	   allowing arbitrary amounts of data to be included with requests.
> 180	   These are:
> 
> 182	   1.  In ICN protocols, Interest messages are intended to be small, 
> on
> 183	       the order the size of a TCP ACK, as opposed to the size of a 
> TCP
> 184	       data segment.  This is because the hop-by-hop congestion 
> control
> 185	       and forwarder state management requires Interest messages to 
> be
> 186	       buffered in expectation of returning data, and possibly
> 187	       retransmitted hop-by-hop as opposed to end-to-end.  In 
> addition,
> 188	       the need to create and manage state on a per-Interest basis 
> is
> 189	       substantially complicated if requests in Interest messages 
> are
> 190	       larger than a Path MTU (PMTU) and need to be fragmented 
> hop-by-
> 191	       hop.
> 
> 193	   2.  If the payload data of a request is used for invoking a
> 194	       computation (as in the RMI case described above) then 
> substantial
> 195	       bandwidth can be wasted if the computation is either refused 
> or
> 196	       abandoned for any number of reasons, including the requestor
> 197	       failing an authorization check, or the responder not having
> 198	       sufficient resources to execute the associated computation.
> 
> 200	   These problems also exist in pure datagram transport protocols 
> such
> 201	   as those used for legacy RMI applications like NFS [RFC7530].  
> More
> 202	   usual are application protocols like HTTP(s) which rely on the 
> TCP or
> 203	   QUIC 3-way handshake to establish a session and then have 
> congestion
> 204	   control and segmentation provided as part of the transport 
> protocol,
> 205	   further allowing sessions to be rejected before large amounts of 
> data
> 206	   are transmitted or significant computational resources expended.
> 
> 208	1.2.  Problems with utilizing independent exchanges
> 
> 210	   In order to either complete a three-way handshake, or fetch data 
> via
> 211	   a pull from the original requestor, the role of consumer and 
> producer
> 212	   need to be reversed and an Interest/Data exchange initiated in 
> the
> 213	   direction opposite of the initiating exchange.  When done with an
> 214	   independent Interest/Data request and response, a number of
> 215	   complications ensue.  Among them are:
> 
> 217	   1.  The originating consumer needs to have a routable name prefix
> 218	       that can be used for the exchange.  This means the consumer 
> must
> 219	       arrange to have its name prefix propagated in the ICN routing
> 220	       system with sufficient reach that the producer issuing the
> 221	       interest can be assured it is routed appropriately.  While 
> some
> 222	       consumers are generally online and act as application 
> servers,
> 223	       justifying the maintenance of this routing information, many 
> do
> 224	       not.  Further, in mobile environments, a pure consumer that 
> does
> 225	       not need to have a routable name prefix can benefit from the
> 226	       inherent consumer mobility support in the CCNx and NDN 
> protocols.
> 227	       By requiring a routable name prefix, extra mobile routing
> 228	       machinery is needed, such as that proposed in KITE 
> [Zhang2018] or
> 229	       MAPME [Auge2018].
> 
> 231	   2.  The consumer name prefix in item (1) above must be 
> communicated
> 232	       to the producer as a payload, name suffix, or other field of 
> the
> 233	       initiating Interest message.  Since this name in its entirety 
> is
> 234	       chosen by the consumer, it is highly problematic from a 
> security
> 235	       standpoint, as it can recruit the producer to mount a 
> reflection
> 236	       attack against the consumer's chosen victim.
> 
> 238	   3.  The correlation between the exchanges in opposite directions 
> must
> 239	       be maintained by both the consumer and the producer as
> 240	       independent state, as opposed to being architecturally tied
> 241	       together as would be the case with a conventional 3-way 
> handshake
> 242	       finite state machine.  While this can of course be 
> accomplished
> 243	       with care by both parties, experience has shown that it is 
> error
> 244	       prone (for example see the checkered history of interactions
> 245	       between the SIP [RFC3261] and SDP Offer-Answer [RFC6337])
> 246	       protocols.  When employed as the wrapper for a key management
> 247	       protocol such as with TLS [RFC8446] state management errors 
> can
> 248	       be catastrophic for security.
> 
> 250	2.  Requirements Language
> 
> 252	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
> NOT",
> 253	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 
> and
> 254	   "OPTIONAL" in this document are to be interpreted as described in
> 255	   [RFC2119].
> 
> 257	3.  Overview of the Reflexive Forwarding design
> 
> 259	   This specification defines a _Reflexive Forwarding_ extension to 
> CCNx
> 260	   and NDN that avoids the problems enumerated in Sections 1.1 and 
> 1.2.
> 261	   It straightforwardly exploits the hop-by-hop state and symmetric
> 262	   routing properties of the current protocols.
> 
> 264	   Figure 1 below illustrates a canonical NDN/CCNx forwarder with 
> its
> 265	   conceptual data structures of the Content Store (CS), Pending
> 266	   Interest Table (PIT) and Forwarding Information Base (FIB).  The 
> key
> 267	   observation involves the relation between the PIT and the FIB.  
> Upon
> 268	   arrival of an Interest, a PIT entry is created which contains 
> state
> 269	   recording the incoming interface on which the Interest.  If the
> 270	   Interest is not immediately satisfied by cached data in the CS, 
> the
> 271	   forwarder looks up the name in the FIB to ascertain the 
> _next-hop_ to
> 272	   propagate the Interest onward upstream toward the named producer.
> 273	   Therefore, a chain of forwarding state is established during 
> Interest
> 274	   forwarding that couples the PIT entries of the chain of 
> forwarders
> 275	   together conceptually as _breadcrumbs_. These are used to forward 
> the
> 276	   returning Data Message over the inverse path through the chain of
> 277	   forwarders until the Data message arrives at the originating
> 278	   consumer.  The state in the PITs is _unwound_ by destroying it as
> 279	   each PIT entry is _satisfied_. This behavior is *critical* to the
> 280	   feasibility of the reflexive forwarding design we propose.
> 
> 282	    
> +-----------------------------------------------------------------+
> 283	    |                                                      ICN Node  
>   |
> 284	    | Send data to all                                     ========  
>   |
> 285	    | interfaces that                                                
>   |
> 286	    | requested it                                                   
>   |
> 287	    |                  YES +------------------+                      
>   |
> 288	   <------------------------| Pending Interest |  
> <---------------------
> 289	    |              |       |    Table (PIT)   |               Data   
>   |
> 290	    |              |       +------------------+  1) Find     
> (Signed) |
> 291	    |              | 2) Save         |              Name             
>   |
> 292	    |              V    Data         | NO            in              
>   |
> 293	    |   +---------------+            |              PIT?             
>   |
> 294	    |   | Content Store |            |                               
>   |
> 295	    |   |      (CS)     |            |                               
>   |
> 296	    |   +---------------+            |                               
>   |
> 297	    |                                |                               
>   |
> 298	    |                                V                               
>   |
> 299	    |                             Drop Data                          
>   |
> 300	    |                                                                
>   |
> 301	    
> +-----------------------------------------------------------------+
> 302	    
> +-----------------------------------------------------------------+
> 303	    |                                                      ICN Node  
>   |
> 304	    |                                                      ========  
>   |
> 305	    |                                                                
>   |
> 306	    |                                           
> +====================+|
> 307	    |                                           |Forwarding Strategy 
> ||
> 308	    |                                           
> +====================+|
> 309	    |                                                                
>   |
> 310	    |   1) Find name          2) Matching        3) Find matching    
>   |
> 311	    |        in CS?              name in PIT?       entry in FIB?    
>   |
> 312	    |                    NO                   NO                   
> YES|
> 313	    |  +---------------+   +----------------+   
> +-------------------+ |
> 314	    |  | Content Store |   |   Pending      |   |  Forwarding       
> | |
> 315	   --->|      (CS)     |-->|   Interest     |-->|  Information Base 
> |-->
> 316	    |  |               |   |   Table (PIT)  |   |     ( FIB)        
> | |
> 317	    |  +---------------+   +----------------+   
> +-------------------+ |
> 318	    | Return   | YES           YES | NO               NO |           
>   |
> 319	    |  Data    |          Add      |   Add               |  Drop     
>   |
> 320	    |          |          Incoming |   new               |   or      
>   |
> 321	    |   <------|          Itf.     |   Interest          |  NACK     
>   |
> 322	    |                              V                     V           
>   |
> 323	    |                                                                
>   |
> 324	    
> +-----------------------------------------------------------------+
> 
> 326	                     Figure 1: ICN forwarder structure
> 
> 328	   Given the above forwarding properties for Interests, it should be
> 329	   clear that while an Interest is outstanding and ultimately 
> arrives at
> 330	   a producer who can respond to it, there is sufficient state in 
> the
> 331	   chain of forwarders to route not just a returning Data message, 
> but
> 332	   potentially another Interest directed through the inverse path to 
> the
> 333	   unique consumer who issued the original Interest.  (Section 8.1.3
> 334	   describes how Interest aggregation interacts with this scheme.)  
> The
> 335	   key question therefore is how to access this state in a way that 
> it
> 336	   can be used to forward Interests.
> 
> 338	   In order to achieve this _Reflexive Interest_ forwarding on the
> 339	   inverse path recorded in the PIT of each forwarder, we need a few
> 340	   critical design elements.  These are as follows:
> 
> 342	   1.  The Reflexive Interest needs to have a Name.  This name is 
> what
> 343	       the originating consumer will use to match against the Data
> 344	       object (or objects - more on this later) it wishes the 
> producer
> 345	       to fetch by issuing the Reflexive Interest.  This cannot be 
> just
> 346	       any name, but needs to essentially name the state already
> 347	       recorded in the PIT and not allow the consumer to manufacture 
> an
> 348	       arbitrary name and mount a reflection attack as pointed out 
> in
> 349	       Section 1.2, Paragraph 2, Item 2.
> 
> 351	   2.  There has to be a FIB entry at each forwarder for this name
> 352	       prefix so that when the reflexive interest arrives, the 
> forwarder
> 353	       can forward it downstream toward the originating consumer.  
> This
> 354	       FIB entry points directly to the incoming interface on which 
> the
> 355	       corresponding original Interest arrived.  The FIB entry needs 
> to
> 356	       be created as part of the forwarding of the original Interest 
> so
> 357	       that it is available in time to catch any reflexive Interest
> 358	       issued by the producer.  It usually makes sense to destroy 
> this
> 359	       FIB entry when the Data message satisfying the original 
> Interest
> 360	       arrives since this avoids any dangling stale state.  Given 
> the
> 361	       deign details documented later in this specification, stale 
> FIB
> 362	       state does not represent a correctness hazard and hence can 
> be
> 363	       done lazily if desired in an implementation.  See Section 5 
> for
> 364	       more details on FIB operation considerations.
> 
> 366	   3.  There has to be coupling of the state between the originating
> 367	       Interest-Data exchange and the enclosed Reflexive 
> Interest-Data
> 368	       exchange at both the consumer and the producer.  In our 
> design,
> 369	       this accomplished by the way reflexive interest names are 
> chosen.
> 
> 371	   The following sections provide the normative details on each of 
> these
> 372	   design elements.  The overall interaction flow for reflexive
> 373	   forwarding is illustrated below in Figure 2.
> 
> 375	   +-----------+    +-----------+                  +-----------+
> 376	   | Consumer  |    | Forwarder |                  | Producer  |
> 377	   +-----------+    +-----------+                  +-----------+
> 378	         |                |                              |
> 379	         | I1             |                              |
> 380	         |--------------->|                              |
> 381	         |--------------\ |                              |
> 382	         || Install RNP |-|                              |
> 383	         || in FIB      | |                              |
> 384	         ||-------------| |                              |
> 385	         |                |                              |
> 386	         |                | I1                           |
> 387	         |                |----------------------------->|
> 388	         |                |                              | 
> -----------\
> 389	         |                |                              |-| Create  
>   |
> 390	         |                |                              | | RI 
> state |
> 391	         |                |                              | 
> |----------|
> 392	         |                |                              |
> 393	         |                |                           RI |
> 394	         |                |<-----------------------------|
> 395	         |                | --------------------\        |
> 396	         |                |-| lookup RNP in FIB |        |
> 397	         |                | |-------------------|        |
> 398	         |                |                              |
> 399	         |             RI |                              |
> 400	         |<---------------|                              |
> 401	         |                |                              |
> 402	         | D2             |                              |
> 403	         |--------------->|                              |
> 404	         |                |                              |
> 405	         |                | D2                           |
> 406	         |                |----------------------------->|
> 407	         |                |                              | 
> ------------\
> 408	         |                |                              |-| answer 
> I1 |
> 409	         |                |                              | 
> |-----------|
> 410	         |                |                              |
> 411	         |                |                           D1 |
> 412	         |                |<-----------------------------|
> 413	         |                | -----------------------\     |
> 414	         |                |-| remove RNP FIB entry |     |
> 415	         |                | |----------------------|     |
> 416	         |                |                              |
> 417	         |             D1 |                              |
> 418	         |<---------------|                              |
> 419	         |                |                              |
> 
> 421	       Legend:
> 422	       I1: Interest #1 containing the Reflexive Name Prefix TLV
> 423	       RI: Reflexive Interest with Reflexive Name Prefix Component
> 424	       RNP: Reflexive Name Prefix
> 425	       D1: Data message, answering initiating I1 Interest
> 426	       D2: Data message, answering RI
> 
> 428	                      Figure 2: Message Flow Overview
> 
> 430	4.  Naming of Reflexive Interests
> 
> 432	   A consumer may have one or more objects for the producer to 
> fetch,
> 433	   and therefore needs to communicate enough information in their
> 434	   initial Interest to allow the producer to construct properly 
> formed
> 435	   reflexive Interest names.  For some applications the set of _full
> 436	   names_ (see [I-D.irtf-icnrg-terminology]) is known a priori, for
> 437	   example through compile time bindings of arguments in interface
> 438	   definitions or by the architectural definition of a simple sensor
> 439	   reading.  In other cases the full names of the individual objects
> 440	   must be communicated in the original Interest message.  In all 
> cases
> 441	   enough state must be provided by the consumer for the forwarders 
> to
> 442	   construct a FIB entry (as noted in Section 3, Paragraph 6, Item 
> 2).
> 443	   This is accomplished through the following naming construct.
> 
> 445	   We define a new typed name component, identified by a registered 
> name
> 446	   component type in the IANA registry for [RFC8569].  We call this 
> the
> 447	   _Reflexive Interest Name Component type_. It MUST be the first 
> (i.e.
> 448	   high order) name component of any Reflexive Interest issued by a
> 449	   producer.  Its value is a random 64 bit number, assigned by the
> 450	   consumer, which provides the entropy required to uniquely 
> identify
> 451	   the issuing consumer for the duration of any outstanding 
> Interest-
> 452	   Data exchange.  The consumer SHOULD choose a different random 
> value
> 453	   for each Interest message it constructs, for two reasons:
> 
> 455	   1.  If stale FIB sate is present, the randomness prevents 
> potential
> 456	       mis-routing of reflexive interests (see Section 8.1.1 below 
> for
> 457	       more details), and
> 
> 459	   2.  Re-use of the same reflexive interest name over multiple
> 460	       interactions might reveal linkability information that could 
> be
> 461	       used by surveillance adversaries for tracking purposes.
> 
> 463	   This initial name component is either communicated by itself 
> through
> 464	   a _Reflexive Name Prefix TLV_ in the originating Interest, or
> 465	   prepended to any object names the consumer wishes the producer to
> 466	   fetch explicitly where there is more than one object needed by 
> the
> 467	   producer for the current Interest-Data interaction.  There are 
> four
> 468	   cases to consider:
> 
> 470	   1.  The reflexive _fullname_ of a single object to fetch.
> 
> 472	   2.  A single reflexive name prefix out of which the producer can 
> (by
> 473	       application-specific means) construct a number of _fullnames_ 
> of
> 474	       the objects it may want to fetch,
> 
> 476	   3.  The reflexive _fullname_ of a FLIC Manifest 
> [I-D.irtf-icnrg-flic]
> 477	       enumerating the suffixes that may be used by the producer to
> 478	       construct the necessary names,
> 
> 480	   4.  Multiple reflexive name TLVs MAY be included in the Interest
> 481	       message if none of the above 3 options covers the desired use
> 482	       case.
> 
> 484	   The last of the four options above, while not explicitly 
> outlawed,
> 485	   SHOULD NOT be used.  This is because it results in a longer 
> Interest
> 486	   message and requires extra FIB resources.  Hence, it is more 
> likely a
> 487	   forwarder will reject the Interest for lack of resources.  A
> 488	   forwarder MAY optimize for the case of a single Reflexive Name 
> TLV at
> 489	   the expense of those with more than one.
> 
> 491	   A producer, upon receiving an Interest with one or more Reflexive
> 492	   Name TLVs, may decide it needs the pull the associated data
> 493	   object(s).  It therefore can issue one or more Reflexive 
> Interests by
> 494	   appending the necessary name components needed to form valid full
> 495	   names of the associated objects present at the originating 
> consumer.
> 496	   These in fact comprise conventional Interest-Data exchanges, with 
> no
> 497	   alteration of the usual semantics with regard to signatures, 
> caching,
> 498	   expiration, etc.  When the producer has retrieved the required
> 499	   objects to complete the original Interest-Data exchange, it can 
> issue
> 500	   its Data response, which unwinds all the established state at the
> 501	   producer, the consumer, and the intermediate forwarders.
> 
> 503	5.  Forwarder operation for Reflexive Interests
> 
> 505	   The forwarder operation for CCNx and/or NDN is changed in three
> 506	   respects when supporting Reflexive Interests.
> 
> 508	   1.  The forwarder MUST create short-lifetime FIB entries for any
> 509	       Reflexive Interest Name prefixes communicated in an Interest
> 510	       message.  If the forwarder does not have sufficient resources 
> to
> 511	       do so, it MUST reject the Interest with the 
> T_RETURN_NO_RESOURCES
> 512	       error - the same error used if the forwarder were lacking
> 513	       sufficient PIT resources to process the Interest message.
> 
> 515	   2.  Those FIB entries MUST be queried whenever an Interest 
> message
> 516	       arrives whose first name component is of the type _Reflexive
> 517	       Interest Name Component_
> 
> 519	   3.  The FIB entry MUST be removed eventually, after the 
> corresponding
> 520	       Data message has been forwarded.  One option would be to 
> remove
> 521	       the FIB directly after the Data message has been forwarded.
> 522	       However, the forwarder MAY do lazy cleanup.
> 
> 524	   The PIT entry for the Reflexive Interest is consumed per regular
> 525	   Interest/Data message forwarding requirements.  The PIT entry for 
> the
> 526	   originating Interest (that communicated the Reflexive Interest 
> Name)
> 527	   is also consumed by a final Data message from the producer to the
> 528	   original consumer.
> 
> 530	6.  State coupling between producer and consumer
> 
> 532	   A consumer that wishes to use this scheme MUST utilize one of the
> 533	   reflexive naming options defined in Section 4 and include it in 
> the
> 534	   corresponding Interest message.  The Reflexive Name TLV _and_ the
> 535	   full name of the requested data object (that identifies the 
> producer)
> 536	   identify the common state shared by the consumer and the 
> producer.
> 537	   When the producer responds by sending Interests with the 
> Reflexive
> 538	   Name Prefix, the original consumer therefore has sufficient
> 539	   information to map these Interests to the ongoing Interest-Data
> 540	   exchange.
> 
> 542	   The exchange is finished when the producer who received the 
> original
> 543	   Interest message responds with a Data message (or an Interest 
> Return
> 544	   message in the case of error) answering the original Interest.  
> After
> 545	   sending this Data message, the producer SHOULD destroy the
> 546	   corresponding shared state.  It MAY decide to use a timer that 
> will
> 547	   trigger a later state destruction.  After receiving this Data
> 548	   message, the originating consumer MUST destroy the corresponding
> 549	   Interest-Data exchange state.
> 
> 551	7.  Use cases for Reflexive Interests
> 
> 553	7.1.  Achieving Remote Method Invocation with Reflexive Interests
> 
> 555	   RICE (Remote Method Invocation in ICN) [Krol2018] uses the 
> Reflexive
> 556	   Interest Forwarding scheme that inspired the design specified in 
> this
> 557	   document.
> 
> 559	   In RICE, the original Interest denotes the remote method (plus
> 560	   potential parameters) to be invoked at a producer (server).  
> Before
> 561	   committing any computating resources, the server can then request
> 562	   authentication credentials and (optional) parameters using 
> reflexive
> 563	   Interest-Data exchanges.
> 
> 565	   When the server has obtained the necessary credentials and input
> 566	   parameters, it can decide to commit computing resources, starts 
> the
> 567	   compute process, and returns a handle ("Thunk") in the final Data
> 568	   message to the original consumer (client).
> 
> 570	   The client would later request the computation results using a
> 571	   regular Interest-Data exchange (outside the Reflexive-Interest
> 572	   transaction) -- using the Thunk as a name for the computation 
> result.
> 
> 574	   Figure 3 depicts an abstract message diagram for RICE.  In 
> addition
> 575	   to the 4-way Reflexive Forwarding Handshake (see Figure 2 for the
> 576	   details of the interaction), RICE adds another (standard) ICN
> 577	   Interest/Data exchange for transmitting the RMI result.  The 
> Thunk
> 578	   name is provided to the consumer in the D1 DATA message 
> (answering
> 579	   the initial I1 Interest).
> 
> 581	   +-----------+              +-----------+
> 582	   | Consumer  |              | Producer  |
> 583	   +-----------+              +-----------+
> 584	         |                          |
> 585	         | I1                       |
> 586	         |------------------------->|
> 587	         |                          | ---------------------\
> 588	         |                          |-| Requesting request |
> 589	         |                          | | parameters         |
> 590	         |                          | | and credentials    |
> 591	         |                          | |--------------------|
> 592	         |                          |
> 593	         |                       RI |
> 594	         |<-------------------------|
> 595	         |                          |
> 596	         | D2                       |
> 597	         |------------------------->|
> 598	         |                          | --------------------\
> 599	         |                          |-| Commit compute    |
> 600	         |                          | | resources,        |
> 601	         |                          | | return Thunk name |
> 602	         |                          | |-------------------|
> 603	         |                          |
> 604	         |                       D1 |
> 605	         |<-------------------------|
> 606	         |                          | ----------------\
> 607	         |                          |-| Invoke Remote |
> 608	         |                          | | Method        |
> 609	         |                          | |---------------|
> 610	         | -------------------\     |
> 611	         |-| After some time, |     |
> 612	         | | request result   |     |
> 613	         | |------------------|     |
> 614	         |                          |
> 615	         | I3                       |
> 616	         |------------------------->|
> 617	         |                          |
> 618	         |                       D3 |
> 619	         |<-------------------------|
> 620	         |                          |
> 621	       Legend:
> 622	       I1: Interest #1 containing the Reflexive Name Prefix TLV
> 623	       D1: Data message, answering initiating I1 Interest,
> 624	           returning Thunk name
> 625	       D2: Data message, answering RI (parameters, credentials)
> 626	       I3: Regular Interest for Thunk (compute result)
> 627	       D3: Data message, answering I3
> 628	                        Figure 3: RICE Message Flow
> 
> 630	7.2.  RESTful Web Interactions
> 
> 632	   In todays HTTP-based web, RESTful (Representational State 
> Transfer)
> 633	   web interactions are realized by sending requests in a 
> client/server
> 634	   interaction, where the requests provides the application context 
> (or
> 635	   a reference to it).  It has been noted in [Moiseenko2014] that
> 636	   corresponding requests often exceed the response messages in 
> size,
> 637	   and that this raises the problems noted in Section 1.1 when
> 638	   attempting to map such exchanges directly to CCNx/NDN.
> 
> 640	   Another reason not to include all request parameters in a 
> (possibly
> 641	   encrypted) Interest message is the fact that a server (that is
> 642	   serving thousands of clients) would be obliged to receive, 
> possibly
> 643	   decrypt and parse the complete requests before being able to
> 644	   determine whether the requestor is authorized, whether the 
> request
> 645	   can be served etc.  Many non-trivial requests could thus lead to
> 646	   computational overload attacks.
> 
> 648	   Using Reflexive Interest Forwarding for RESTful Web Interactions
> 649	   would encode the REST request in the Original request, together 
> with
> 650	   a Reflexive Interest Prefix that the server could then use to get
> 651	   back to the client for authentication credentials and request
> 652	   parameters, such as cookies.  The request result (response 
> message)
> 653	   could either be transmitted in the Data message answering the
> 654	   original request, or -- in case of dynamic, longer-running
> 655	   computations -- in a seperate Interest/Data exchange, potentially
> 656	   leveraging the Thunk scheme described in section Section 7.1.
> 
> 658	   Unlike approaches where clients have to signal a globally 
> routable
> 659	   prefix to the network, this approach would not require the client
> 660	   (original consumer) to expose its identity to the network (the
> 661	   network only sees the temporary Reflexive Name Prefix), but it 
> would
> 662	   still be possible to authenticate the client at the server.
> 
> 664	7.3.  Achieving simple data pull from consumers with reflexive 
> Interests
> 
> 666	   An oft-cited use case for ICN network architectures is _Internet 
> of
> 667	   Things_ (IoT), where the sources of data are limited-resource 
> sensor/
> 668	   actuators.  Many approaches have been tried (e.g.  
> [Baccelli2014],
> 669	   [Lindgren2016], [Gundogan2018]) with varying degrees of success 
> in
> 670	   addressing the issues outlined in Section 1.1.  The reflexive
> 671	   forwarding extension may substantially ameliorate the documented
> 672	   difficulties by allowing a different model for the basic 
> interaction
> 673	   of sensors with the ICN network.
> 
> 675	   Instead of acting as a producer (either directly to the Internet 
> or
> 676	   indirectly through the use of some form of application-layer
> 677	   gateway), the IoT device need only act as a consumer.  When it 
> has
> 678	   data to provide, it issues a "phone-home" Interest message to a 
> pre-
> 679	   configured rendezvous name (e.g. an application-layer gateway or 
> ICN
> 680	   Repo [Chen2015]) and provides a reflexive name prefix TLV for the
> 681	   data it wishes to publish.  The target producer may then issue 
> the
> 682	   necessary reflexive Interest message(s) to fetch the data.  Once
> 683	   fetched, validated, and stored, the producer then responds to the
> 684	   original Interest message with a success indication, possibly
> 685	   containing a Data object if needed to allow the originating 
> device to
> 686	   modify its internal state.  Alternatively, the producer might 
> choose
> 687	   to not respond and allow the original Interest to time out, 
> although
> 688	   this is NOT RECOMMENDED except in cases where the extra message
> 689	   transmission bandwith is at a premium compared to the persistence 
> of
> 690	   stale state in the forwarders.  We note that this interaction
> 691	   approach mirrors the earlier efforts using Interest-Interest-Data
> 692	   designs.
> 
> 694	   Figure 4 depicts this interaction with the OPTIONAL D1 message.  
> See
> 695	   Figure 2 for the details of the general Reflexive Forwarding
> 696	   interaction.
> 
> 698	                +-----------+ +-----------+
> 699	                | Consumer  | | Producer  |
> 700	                +-----------+ +-----------+
> 701	        ------------\ |             |
> 702	        | new IoT   |-|             |
> 703	        | data item | |             |
> 704	        | produced  | |             |
> 705	        |-----------| |             |
> 706	     ---------------\ |             |
> 707	     | "phone home" |-|             |
> 708	     | by notifying | |             |
> 709	     | producer     | |             |
> 710	     |--------------| |             |
> 711	                      |             |
> 712	                      | I1          |
> 713	                      |------------>|
> 714	                      |             | --------------------\
> 715	                      |             |-| generate Interest |
> 716	                      |             | | for IoT data      |
> 717	                      |             | |-------------------|
> 718	                      |             |
> 719	                      |          RI |
> 720	                      |<------------|
> 721	   -----------------\ |             |
> 722	   | send requested |-|             |
> 723	   | data object    | |             |
> 724	   |----------------| |             |
> 725	                      |             |
> 726	                      | D2          |
> 727	                      |------------>|
> 728	                      |             | -----------------------\
> 729	                      |             |-| finalize interaction |
> 730	                      |             | | with optional        |
> 731	                      |             | | Data message         |
> 732	                      |             | |----------------------|
> 733	                      |             |
> 734	                      |          D1 |
> 735	                      |<------------|
> 736	                      |             |
> 737	       Legend:
> 738	       I1: Interest #1 containing the Reflexive Name Prefix TLV
> 739	       D1: Data message (OPTIONAL), finalizing interaction
> 740	       D1: Data message, answering RI, returning IoT data object
> 
> 742	                    Figure 4: "Phone Home" Message Flow
> 
> 744	   There are two approaches that the IoT device can use for its 
> response
> 745	   to a reflexive Interest.  It can simply construct a Data Message
> 746	   bound through the usual ICN hash name to the reflexive Interest 
> name.
> 747	   Since the scope of any data object bound in this way is only the
> 748	   duration of the enclosing Interest-Data exchange (see Section 
> 8.2)
> 749	   the producer would need to itself construct any persistent Data
> 750	   object, name it, and sign it.  This is sometimes the right 
> approach,
> 751	   as for some applications the identity of the originating IoT 
> device
> 752	   is not important from an operational or security point of view; 
> in
> 753	   contrast the identity of the gateway or Repo is what matters.
> 
> 755	   If alternatively, the persistent Data object should be bound from 
> a
> 756	   naming and security point of view to the originating IoT device, 
> this
> 757	   can be easily accomplished.  Instead of directly placing the 
> content
> 758	   in a Data object responding to the reflexive Interest as above, 
> the
> 759	   consumer encapsulates a complete CCNx/NDN Data message (which
> 760	   includes the desired name of the data) as in the response to the
> 761	   reflexive Interest message.
> 
> 763	   The interaction model described above brings a number potential
> 764	   advantages, some obvious, some less so.  We enumerate a few of 
> them
> 765	   as follows:
> 
> 767	   *  By not requiring the IoT device to be actively listening for
> 768	      Interests, it can sleep and only wake up if it has something 
> to
> 769	      communicate.  Conversely, parties interested in obtaining data
> 770	      from the device do not need to be constantly polling in order 
> to
> 771	      ascertain if there is new data available.
> 
> 773	   *  No forwarder resources are tied up with state apart from the
> 774	      actual reflexive forwarding interactions.  All that is needed 
> is
> 775	      enough routing state in the FIB to be able to forward the 
> "phone
> 776	      home" Interest to an appropriate target producer.  While this
> 777	      model does not provide all the richness of a full Pub/Sub 
> system
> 778	      (like that described in [Gundogan2018]) we argue it is 
> adequate
> 779	      for a large subclass of such applications.
> 
> 781	   *  The reflexive interest, through either a name suffix or 
> Interest
> 782	      payload, can give the IoT device useful context from which to
> 783	      craft its Data object in response.  One highly useful 
> parameter
> 784	      would be a robust clock value for the device to use as a 
> timestamp
> 785	      of the data, possibly as part of its name to correctly place 
> it in
> 786	      a time seres of sensor readings.  This substantially 
> alleviates
> 787	      the need for low-end devices to have a robust time base, as 
> long
> 788	      as they trust the producer they contact to provide it.
> 
> 790	8.  Implementation Considerations
> 
> 792	   There are a number of important aspects to the reflexive 
> forwarding
> 793	   design which affect correctness and performance of existing
> 794	   forwarder, consumer, and producer implementations desiring to 
> support
> 795	   it.  This section discusses the effect on each of these elements 
> of
> 796	   the CCNx/NDN protocol architecture.
> 
> 798	8.1.  Forwarder implementation considerations
> 
> 800	8.1.1.  Forwarding Information Base (FIB)
> 
> 802	   The FIB is a performance-critical data structure in any 
> forwarder, as
> 803	   it needs to support relatively expensive longest name prefix 
> match
> 804	   (LNPM) lookup algorithms.  A number of well-known FIB data 
> structures
> 805	   are heavily optimized for read access, since for normal Interest
> 806	   message processing the FIB changes slowly - only after 
> topological
> 807	   changes or routing protocol updates.  Support for reflexive names
> 808	   changes this, as FIB entries are created and destroyed rapidly as
> 809	   Interest messages containing reflexive name TLVs are processed 
> and
> 810	   the corresponding Data messages come back.
> 
> 812	   While it may be feasible, especially in low-end forwarders 
> handling a
> 813	   low packet forwarding rate to ignore this problem, for high-speed
> 814	   forwarders there are a number of hazards, including:
> 
> 816	   1.  If the entire FIB needs to be locked in order to insert or 
> remove
> 817	       entries, this could cause inflated forwarding delays or in
> 818	       extreme cases, forwarding performance collapse.
> 
> 820	   2.  A number of high-speed forwarder implementations employ a 
> sharded
> 821	       PIT scheme to better parallelize forwarding across processing
> 822	       cores.  The FIB, however, is still a shared data structure 
> which
> 823	       is either read without read locks across cores, or explicitly
> 824	       copied such that there is a separate copy of the FIB for each 
> PIT
> 825	       shard.  Clearly, a high update rate without read locks and/or
> 826	       updating many copies of the FIB are unattractive 
> implementation
> 827	       options.  (Note: with this reflexive name scheme it is not
> 828	       feasible to force reflexive interests to be hashed or be
> 829	       otherwise directed to the PIT shard holding the original 
> Interest
> 830	       state).
> 
> 832	   There are any number of alternative FIB implementations that can 
> work
> 833	   well however.  The most straightforward is to simply implement a
> 834	   "special" FIB for just reflexive name lookups.  This is feasible
> 835	   because reflexive names deterministically contain the 
> distinguished
> 836	   high-order name component type of T_REFLEXIVE_NAME, whose content 
> is
> 837	   a 64-bit value that can be easily hashed to a FIB entry directly,
> 838	   avoiding the more expensive LNPM lookup.  Inserts and deletes 
> then
> 839	   devolve to the well-understood problem of hash table maintenance.
> 
> 841	8.1.2.  Interactions with Interest Lifetime
> 
> 843	   If and when a producer decides to fetch data from the consumer 
> using
> 844	   one or more reflexive Interest-Data exchanges, the total latency 
> for
> 845	   the original Interest-Data exchange is inflated, potentially by
> 846	   multiple RTTs.  It is difficult for a consumer to predict the
> 847	   inflation factor when issuing the original Interest, and hence 
> there
> 848	   can be a substantial hazard of that Interest lifetime expiring 
> before
> 849	   completion of the full multi-way exchange.  This can result in
> 850	   persistent failures, which is obviously highly undesirable.
> 
> 852	   There is a fairly straightforward technique that can be employed 
> by
> 853	   forwarders to avoid these "false" Interest lifetime expirations.  
> In
> 854	   the absence of a superior alternative technique, it is 
> RECOMMENDED
> 855	   that all forwarders implement the following algorithm.
> 
> 857	   When processing an Interest containing the reflexive name TLV and
> 858	   creating the necessary FIB entry (see Section 8.1.1 above), the
> 859	   forwarder also creates a _back pointer_ from that FIB entry to 
> the
> 860	   PIT entry for the Interest message that created it.  This PIT 
> entry
> 861	   contains the current value of the remaining Interest lifetime or
> 862	   alternatively a value from which the remaining Interest lifetime 
> can
> 863	   be easily computed.  Call this value _IL_(t)_.
> 
> 865	   If and when a reflexive Interest arrives from upstream matching 
> the
> 866	   reflexive FIB entry, the forwarder examines the Interest lifetime 
> of
> 867	   the arriving reflexive Interest.  Call this value _IL_(r)_. The
> 868	   forwarder computes MAX(_IL_(t), (IL_(r) * 1.5)_), and replaces
> 869	   _IL_(t)_ with this value.  This in effect ensures that the 
> remaining
> 870	   Interest lifetime of the original Interest accounts for the
> 871	   additional 1.5 RTTs that may occur as a result of the reflexive
> 872	   Interest-Data exchange.
> 
> 874	   If the above algorithm is implemented naively as described above, 
> it
> 875	   may run afoul of a sharded PIT forwarder implementation, since 
> the
> 876	   PIT entry for the reflexive Interest and the PIT entry for the
> 877	   original Interest may be in different shards.  Therefore, if the
> 878	   update is done cross-shard on each reflexive Interest arrival,
> 879	   performance may suffer, perhaps dramatically.  Instead, the 
> following
> 880	   approach to updating the Interest lifetime after computing the 
> new
> 881	   value is RECOMMMENDED for sharded-PIT forwarders.
> 
> 883	   When creating the reflexive FIB entry as above in Section 8.1.1, 
> copy
> 884	   the remaining Interest lifetime from the PIT entry.  Do the PIT
> 885	   update if and only if this value is about to expire, thus paying 
> the
> 886	   cross-shard update cost only if the original Interest is about to
> 887	   expire.  A further optimization at the cost of modest extra
> 888	   complexity is to instead _queue_ the update to the core holding 
> the
> 889	   shard of the original PIT entry rather than doing the update
> 890	   directly.  If the PIT entry expires or is satisfied, instead of
> 891	   removing it the associated core checks the update queue and does 
> the
> 892	   necessary update.
> 
> 894	   While the above approach of inflating the interest lifetime of 
> the
> 895	   original Interest to accommodate the additional RTTs of reflexive
> 896	   Interest-Data exchanges, this does introduce a new vulnerability 
> that
> 897	   must be dealt with.  A Producer, either through a bug or 
> malicious
> 898	   intent, could keep an originating Interest-Data exchange alive by
> 899	   continuing to send reflexive Interests back to the consumer, 
> while
> 900	   the consumer had no way to terminate the enclosing interaction 
> (there
> 901	   is no "cancel Interest" function in either NDN nor CCNx).  To
> 902	   eliminate this hazard, if the consumer rejects a reflexive 
> interest
> 903	   with a T_RETURN_PROHIBITED error, the forwarder(s), in addition 
> to
> 904	   satisfying the coresponding PIT entry, MUST also delete the
> 905	   associated reflexive FIB entry, thereby preventing any further
> 906	   reflexive Interests from reaching the consumer.  This allows the
> 907	   enclosing Interest-Datsa exchange to either time out or be 
> correctly
> 908	   ended with a Data message or Interest Return from the Producer.
> 
> 910	8.1.3.  Interactions with Interest aggregation
> 
> 912	   As with numerous other situations where multiple Interests for 
> the
> 913	   same named object arrive containing different parameters (e.g.
> 914	   Interest Lifetime, QoS, payload hash) the same phenomenon occurs 
> for
> 915	   the reflexive Name TLV.  If such Interests collide, the forwarder
> 916	   MUST NOT aggregate these Interest messages and instead MUST 
> create a
> 917	   separate PIT entry for each.
> 
> 919	8.2.  Consumer Implementation Considerations
> 
> 921	8.2.1.  Data objects returned by the consumer to reflexive name
> 922	        Interests arriving from a producer
> 
> 924	   The Data objects returned to the producer in response to a 
> reflexive
> 925	   Interest are normal CCNx/NDN data objects.  It is therefore worth
> 926	   noting that the object is bound to the reflexive Interest full 
> name
> 927	   via the hash and hence the scope of the object is under most
> 928	   circumstances meaningful only for the duration of the enclosing
> 929	   Interest-Data interaction.  This property is ideal for naming and
> 930	   securing data that is "part of" the enclosing interaction - 
> things
> 931	   like method arguments, authenticators, and key exchange 
> parameters,
> 932	   but not for the creation and naming of objects intended to 
> survive
> 933	   outside the current interaction's scope (c.f.  Section 7.3, which
> 934	   describes how to provide globally-named objects using 
> encapsulation).
> 935	   In general, the consumer should use the following guidelines in
> 936	   creating Data messages in response to reflexive Interest messages
> 937	   from the producer.
> 
> 939	   (a)  Set the recommended cache time (T_CACHETIME) either to zero, 
> or
> 940	        a value no greater than the Interest lifetime (T_INTLIFE) of 
> the
> 941	        original Interest messsage.
> 
> 943	   (b)  Set the payload type (T_PAYLDTYPE) according to the type of
> 944	        object being returned (e.g. object, link, manifest)
> 
> 946	   (c)  Set the expiry time (T_EXPIRY) to a value greater than 
> _now_,
> 947	        and less than or equal to the _now_ + Interest lifetime
> 948	        (T_INTLIFE) of the original Interest messsage.
> 
> 950	8.2.2.  Terminating unwanted reflexive Interest exchanges
> 
> 952	   A consumer may wish to stop receiving reflxive Interests due to
> 953	   possible erors or malicious behavior on the part of the producer.
> 954	   Therefore, if the consumer receives an unwanted reflexive 
> Interest,
> 955	   it SHOULD reject that interest with a T_RETURN_PROHIBITED error.
> 956	   This will provoke the forwarders to prevent further reflexive
> 957	   Interests from reaching the consumer, as described above in
> 958	   Section 8.1.2, Paragraph 7.
> 
> 960	8.2.3.  Interactions with caching
> 
> 962	   The reflexive named objects provide "local", temporary names that 
> are
> 963	   only defined for one specific interaction between a consumer and 
> a
> 964	   producer.  Corresponding Data objects MUST NOT be shared between
> 965	   multiple consumers (violating this would require specail 
> gyrations by
> 966	   the producer since the reflexive Name utilizes per-consumer/per-
> 967	   interaction random values).  A producer MUST NOT issue an 
> Interest
> 968	   message for any reflexive name after it has sent the final Data
> 969	   message answering the original Interest.
> 
> 971	   Forwarders SHOULD still cache reflexive Data objects for
> 972	   retransmissions within a transactions, but they MUST remove them 
> from
> 973	   the content store when they forward the final Data message 
> answering
> 974	   the original Interest.
> 
> 976	8.3.  Producer Implementation Considerations
> 
> 978	   Producers receiving an Interest with a Reflexive Name Component, 
> MAY
> 979	   decide to issue Interests for the corresponding Data objects.  
> All
> 980	   Reflexive Interest message that a producer sends MUST be sent 
> over
> 981	   the face that the original Interest was received on.
> 
> 983	9.  Operational Considerations
> 
> 985	   This extension represents a substantial enhancement to the 
> CCNx/NDN
> 986	   protocol architecture and hence has important forward and 
> backward
> 987	   compatibility effects.  The most important of these is that 
> correct
> 988	   operation of the scheme requires an unbroken chain of forwarders
> 989	   between the consumer and the desired producer that support the
> 990	   Reflexive Name TLV and the corresponding forwarder capabilities
> 991	   specified in Section 5.  When this invariant is not satisfied, 
> some
> 992	   means is necessary to detect and hopefully recover from the 
> error.
> 993	   We have identified three possible approaches to handling the lack 
> of
> 994	   universal deployment of forwarders supporting the reflexive
> 995	   forwarding scheme.
> 
> 997	   The first approach simply lets the producer detect the error by
> 998	   getting a "no route to destination" error when trying to send an
> 999	   Interest to a reflexive name.  This will catch the error, but 
> only
> 1000	   after forwarding resources are tied up and the producer has done 
> some
> 1001	   work on the original Interest message.  Further, the producer 
> would
> 1002	   need a bit of smarts to determine that this is a permanent error 
> and
> 1003	   not a transient to be retried.  In order for the consumer to 
> attempt
> 1004	   recovery, there might be a need for some explicit error returned 
> for
> 1005	   the original interest to tell the consumer what the likely 
> problem
> 1006	   is.  This approach does not enable an obvious recovery path for 
> the
> 1007	   consumer either, since while we might envision a way to steer a
> 1008	   subsequent Interest onto a working path as proposed in
> 1009	   [I-D.oran-icnrg-pathsteering], there is no capability to force
> 1010	   Interest routing away from an otherwise working path not 
> supporting
> 1011	   the reflexive name TLV.
> 
> 1013	   A second approach is to bump the CCNx/NDN protocol version to
> 1014	   explicitly indicate the lack of comparability.  Such Interests 
> would
> 1015	   be rejected by forwarders not supporting this protocol 
> extension.  A
> 1016	   consumer wishing to use the reflexive name TLV would use the 
> higher
> 1017	   protocol version on those Interest messages (but could of course
> 1018	   continue to use the current version number on other Interest
> 1019	   messages).  This is a big hammer, but may be called for in this
> 1020	   situation because:
> 
> 1022	   (a)  it detects the problem immediately and deterministically, 
> and
> 
> 1024	   (b)  one could assume an ICN routing protocol that would only 
> forward
> 1025	        to a next hop that supports the updated protocol version 
> number.
> 1026	        The supported forwarder protocol versions would have been
> 1027	        communicated in the routing protocol ahead of time.
> 
> 1029	   A third option is to, as a precondition utilizing the protocol 
> in a
> 1030	   deployment, create and deploy a neighbor capability exchange 
> protocol
> 1031	   which will tell a downstream forwarder if the upstream can 
> handle the
> 1032	   new TLV.  This might avoid the large hammer of updating the 
> protocol
> 1033	   version, but of course this puts a pretty strong dependency on
> 1034	   somebody actually designing and publishing such a protocol!  On 
> the
> 1035	   other hand, a neighbor capability exchange protocol for CCNx/NDN
> 1036	   would have a number of other substantial benefits, which makes 
> it
> 1037	   worth seriously considering anyway.
> 
> 1039	10.  Mapping to CCNx and NDN packet encodings
> 
> 1041	10.1.  Packet encoding for CCNx
> 
> 1043	   For CCNx[RFC8569] there is one new Name Component TLV type 
> defined in
> 1044	   this specification.
> 
> 1046	     
> +------------------+----------------+--------------------------+
> 1047	     |      Abbrev      |      Name      |       Description        
> |
> 1048	     
> +==================+================+==========================+
> 1049	     | T_REFLEXIVE_NAME | Reflexive Name | Name component to use as 
> |
> 1050	     |                  | Component      | name prefix in Reflexive 
> |
> 1051	     |                  |                | Interest Message         
> |
> 1052	     
> +------------------+----------------+--------------------------+
> 
> 1054	                       Table 1: Reflexive Name TLV
> 
> 1056	10.2.  Packet encoding for NDN
> 
> 1058	   TBD based on [NDNTLV].  Suggestions from the NDN team greatly
> 1059	   appreciated.
> 
> 1061	11.  IANA Considerations
> 
> 1063	   Please add the T_REFLEXIVE_NAME component TLV to the CCNx Name 
> types
> 1064	   TLV types registry of [RFC8609], with Length 9 bytes and type of 
> 64
> 1065	   bit random integer.
> 
> 1067	                        1                   2                   3
> 1068	    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> 1069	   
> +---------------+---------------+---------------+---------------+
> 1070	   |         T_REFLEXIVE_NAME      |               8               
> |
> 1071	   
> +---------------+---------------+---------------+---------------+
> 1072	   |                                                               
> |
> 1073	   |       64bit Integer randomly assigned by consumer             
> |
> 1074	   
> +-------------------------------+-------------------------------+
> 
> 1076	                  Figure 5: Reflexive Name component type
> 
> 1078	12.  Security Considerations
> 
> 1080	   One of the major motivations for the reflexive forwarding 
> extension
> 1081	   specified in this document is in fact to enable better security 
> and
> 1082	   privacy characteristics for ICN networks.  The main 
> considerations
> 1083	   are presented in Section 1, but we briefly recapitulate them 
> here:
> 
> 1085	   *  Current approaches to authentication and data transfer often 
> use
> 1086	      payloads in Interest messages, which are clumsy to secure
> 1087	      (Interest messages must be signed) and as a consequence make 
> it
> 1088	      very difficult to ensure consumer privacy.  Reflexive 
> forwarding
> 1089	      moves all sensitive data to the Data messages sent in 
> response to
> 1090	      reflexive Interests, which are secured in the same manner as 
> all
> 1091	      other Data messages in the CCNx and NDN protocol designs.
> 
> 1093	   *  In many scenarios, consumers are forced to also act as 
> producers
> 1094	      so that data may be fetched by either a particular, or 
> arbitrary
> 1095	      other party.  The means the consumer must arrange to have a
> 1096	      routable name prefix and that prefix be disseminated by the
> 1097	      routing protocol or other means.  This represents both a 
> privacy
> 1098	      hazard (by revealing possible important information about the
> 1099	      consumer) and a security concern as it opens up the consumer 
> to
> 1100	      the full panoply of flooding and crafted Interest denial of
> 1101	      service attacks.
> 
> 1103	   *  In order to achieve multi-way handshakes, in current designs 
> a
> 1104	      consumer wishing a producer to communicate back must inform 
> the
> 1105	      producer of what (globally routable) name to use.  This gives 
> the
> 1106	      consumer a convenient means to mount a variety of reflection
> 1107	      attacks by enlisting the producer to send Interests to 
> desired
> 1108	      victims.
> 
> 1110	   As a major protocol extension however, this design brings its 
> own
> 1111	   potential security issues, which are discussed in the following
> 1112	   subsections.
> 
> 1114	12.1.  Collisions of reflexive Interest names
> 
> 1116	   Reflexive Interest names are constructed using 64-bit random 
> numbers.
> 1117	   This is intended to ensure an off-path attacker cannot easily
> 1118	   manufacture a matching reflexive Interest and either masquerade 
> as
> 1119	   the producer, or mount a denial of service attack on the 
> consumer.
> 1120	   It also limits tracking through the linkability of Interests
> 1121	   containing a re-used random value.
> 
> 1123	   Therefore consumers MUST utilize a robust means of generating 
> these
> 1124	   random values, and it is RECOMMENDED that a pseudo-random number
> 1125	   generator (PRNG) approved for use with cryptographic protocols 
> be
> 1126	   employed.
> 
> 1128	12.2.  Additional resource pressure on PIT and FIB
> 
> 1130	   Normal Interest message processing in CCNx and NDN needs to 
> consider
> 1131	   effect of various resource depletion attacks on the PIT, 
> particularly
> 1132	   in the form of Interest flooding attacks (see [Gasti2012] for a 
> good
> 1133	   overview of DoS and DDoS mitigation on ICN networks).  Interest
> 1134	   messages utilizing this reflexive forwarding extension can place
> 1135	   additional resource pressure on the PIT, and additionally cause
> 1136	   otherwise stable FIB resources to be subject to highly dynamic 
> usage.
> 
> 1138	   While this does not represent a new DoS/DDoS attack vector, the
> 1139	   ability of a malicious consumer to utilize this extension in an
> 1140	   attack does represent an increased risk of resource depletion,
> 1141	   especially if such Interests are given unfair access to PIT and 
> FIB
> 1142	   resources.  Implementers SHOULD therefore protect PIT and FIB
> 1143	   resources by weighing requests for reflexive forwarding 
> resources
> 1144	   appropriately relative to other Interests.
> 
> 1146	12.3.  Privacy Considerations
> 
> 1148	   ICN architectures like CCNx and NDN provide a rich tapestry of
> 1149	   interesting privacy issues, which have been extensively explored 
> in
> 1150	   the research literature.  The fundamental tradeoffs for privacy
> 1151	   concern the risk of exposing the names of information objects to 
> the
> 1152	   forwarding elements of the network, which is a necessary 
> property of
> 1153	   any name-based routing and forwarding design.  Numerous 
> approaches
> 1154	   have been explored with varying degrees of success, such as 
> onion
> 1155	   routing ([DiBenedettoGTU12]), name encryption ([Ghali2017]), and 
> name
> 1156	   obfuscation ([Arianfar2011]) among others.
> 
> 1158	   Reflexive forwarding does not change the overall landscape of 
> privacy
> 1159	   tradeoffs, nor seem to introduce additional hazards.  In fact, 
> the
> 1160	   privacy exposures are confined to the inverse path of forwarders 
> from
> 1161	   the producer to the consumer, through which the original 
> Interest
> 1162	   forwarding may have already exposed names on path.  Similar name
> 1163	   privacy techniques to those cited above may be equally applied 
> to the
> 1164	   names in reflexive Interests.
> 
> 1166	   While the individual reflexive Interest-Data exchanges have 
> similar
> 1167	   properties to those in any NDN or CCNx exchange, the target 
> usages by
> 1168	   applications may have interaction patterns that are subject to
> 1169	   relatively straightforward fingerprinting by adversaries.  For
> 1170	   example, a particular RMI invocation may fingerprint simply 
> through
> 1171	   the count of arguments fetched by the producer and their sizes.  
> The
> 1172	   attacker must however be on path, which somewhat ameliorates the
> 1173	   exposure hazards.
> 
> 1175	13.  Normative References
> 
> 1177	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
> 1178	              Requirement Levels", BCP 14, RFC 2119,
> 1179	              DOI 10.17487/RFC2119, March 1997,
> 1180	              <https://www.rfc-editor.org/info/rfc2119>.
> 
> 1182	   [RFC8569]  Mosko, M., Solis, I., and C. Wood, "Content-Centric
> 1183	              Networking (CCNx) Semantics", RFC 8569,
> 1184	              DOI 10.17487/RFC8569, July 2019,
> 1185	              <https://www.rfc-editor.org/info/rfc8569>.
> 
> 1187	   [RFC8609]  Mosko, M., Solis, I., and C. Wood, "Content-Centric
> 1188	              Networking (CCNx) Messages in TLV Format", RFC 8609,
> 1189	              DOI 10.17487/RFC8609, July 2019,
> 1190	              <https://www.rfc-editor.org/info/rfc8609>.
> 
> 1192	14.  Informative References
> 
> 1194	   [Arianfar2011]
> 1195	              Arianfar, S., Koponen, T., Raghavan, B., and S. 
> Shenker,
> 1196	              "On preserving privacy in content-oriented networks, 
> in
> 1197	              ICN '11: Proceedings of the ACM SIGCOMM workshop on
> 1198	              Information-centric networking",
> 1199	              DOI https://doi.org/10.1145/2018584.2018589, August 
> 2011,
> 1200	              <https://dl.acm.org/doi/10.1145/2018584.2018589>.
> 
> 1202	   [Auge2018] Augé, J., Carofiglio, G., Grassi, G., Muscariello, 
> L.,
> 1203	              Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-Less
> 1204	              Producer Mobility in Content-Centric Networks, in 
> IEEE
> 1205	              Transactions on Network, Volume 15, Issue 2",
> 1206	              DOI 10.1109/TNSM.2018.2796720, June 2018,
> 1207	              <https://ieeexplore.ieee.org/document/8267132>.
> 
> 1209	   [Baccelli2014]
> 1210	              Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and 
> M.
> 1211	              Wählisch, "Information centric networking in the 
> IoT:
> 1212	              experiments with NDN in the wild, in ACM-ICN '14:
> 1213	              Proceedings of the 1st ACM Conference on Information-
> 1214	              Centric Networking", DOI 10.1145/2660129.2660144,
> 1215	              September 2014,
> 1216	              <https://dl.acm.org/doi/abs/10.1145/2660129.2660144>.
> 
> 1218	   [Carzaniga2011]
> 1219	              Carzaniga, A., Papalini, M., and A.L. Wolf, 
> "Content-Based
> 1220	              Publish/Subscribe Networking and Information-Centric
> 1221	              Networking", DOI 10.1145/2018584.2018599, September 
> 2011,
> 1222	              
> <https://conferences.sigcomm.org/sigcomm/2011/papers/icn/
> 1223	              p56.pdf>.
> 
> 1225	   [Chen2015] Chen, S., Cao, J., and L. Zhu, "NDSS: A Named Data 
> Storage
> 1226	              System, in International Conference on Cloud and 
> Autonomic
> 1227	              Computing", DOI 10.1109/ICCAC.2015.12, September 
> 2014,
> 1228	              <https://ieeexplore.ieee.org/document/7312154>.
> 
> 1230	   [DiBenedettoGTU12]
> 1231	              DiBenedetto, S., Gasti, P., Tsudik, G., and E. Uzun,
> 1232	              "ANDaNA: Anonymous Named Data Networking Application, 
> in
> 1233	              NDSS 2012", DOI https://arxiv.org/abs/1112.2205v2, 
> 2102,
> 1234	              
> <https://www.ndss-symposium.org/ndss2012/andana-anonymous-
> 1235	              named-data-networking-application>.
> 
> 1237	   [Gasti2012]
> 1238	              Gasti, P., Tsudik, G., Uzun, Ersin., and L. Zhang, 
> "DoS
> 1239	              and DDoS in Named Data Networking, in 22nd 
> International
> 1240	              Conference on Computer Communication and Networks
> 1241	              (ICCCN)", DOI 10.1109/ICCCN.2013.6614127, August 
> 2013,
> 1242	              <https://ieeexplore.ieee.org/document/6614127>.
> 
> 1244	   [Ghali2017]
> 1245	              Tsudik, G., Ghali, C., and C. Wood, "When encryption 
> is
> 1246	              not enough: privacy attacks in content-centric 
> networking,
> 1247	              in ICN '17: Proceedings of the 4th ACM Conference on
> 1248	              Information-Centric Networking",
> 1249	              DOI https://doi.org/10.1145/3125719.3125723, 
> September
> 1250	              2017,
> 1251	              <https://dl.acm.org/doi/abs/10.1145/3125719.3125723>.
> 
> 1253	   [Gundogan2018]
> 1254	              Gündoğan, C., Kietzmann, P., Schmidt, T., and M. 
> Wählisch,
> 1255	              "HoPP: publish-subscribe for the constrained IoT, in 
> ICN
> 1256	              '18: Proceedings of the 5th ACM Conference on 
> Information-
> 1257	              Centric Networking", DOI 10.1145/3267955.3269020,
> 1258	              September 2018,
> 1259	              <https://dl.acm.org/doi/abs/10.1145/3267955.3269020>.
> 
> 1261	   [I-D.irtf-icnrg-flic]
> 1262	              Tschudin, C., Wood, C., Mosko, M., and D. Oran, 
> "File-Like
> 1263	              ICN Collections (FLIC)", Work in Progress, 
> Internet-Draft,
> 1264	              draft-irtf-icnrg-flic-02, 4 November 2019,
> 1265	              
> <https://tools.ietf.org/html/draft-irtf-icnrg-flic-02>.
> 
> 1267	   [I-D.irtf-icnrg-terminology]
> 1268	              Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., 
> Oran,
> 1269	              D., and C. Tschudin, "Information-Centric Networking
> 1270	              (ICN): CCNx and NDN Terminology", Work in Progress,
> 1271	              Internet-Draft, draft-irtf-icnrg-terminology-08, 17
> 1272	              January 2020, 
> <https://tools.ietf.org/html/draft-irtf-
> 1273	              icnrg-terminology-08>.
> 
> 1275	   [I-D.oran-icnrg-pathsteering]
> 1276	              Moiseenko, I. and D. Oran, "Path Steering in CCNx and
> 1277	              NDN", Work in Progress, Internet-Draft, 
> draft-oran-icnrg-
> 1278	              pathsteering-00, 21 October 2019,
> 1279	              <https://tools.ietf.org/html/draft-oran-icnrg-
> 1280	              pathsteering-00>.
> 
> 1282	   [Krol2018] Krol, M., Habak, K., Oran, D., Kutscher, D., and I.
> 1283	              Psaras, "RICE: Remote Method Invocation in ICN, in
> 1284	              Proceedings of the 5th ACM Conference on Information-
> 1285	              Centric Networking - ICN '18",
> 1286	              DOI 10.1145/3267955.3267956, September 2018,
> 1287	              
> <https://conferences.sigcomm.org/acm-icn/2018/proceedings/
> 1288	              icn18-final9.pdf>.
> 
> 1290	   [Lindgren2016]
> 1291	              Lindgren, A., Ben Abdessiem, F., Ahlgren, B., 
> Schlelén,
> 1292	              O., and A.M. Malik, "Design choices for the IoT in
> 1293	              Information-Centric Networks, in 13th IEEE Annual 
> Consumer
> 1294	              Communications and Networking Conference (CCNC)",
> 1295	              DOI 10.1109/CCNC.2016.7444905, January 2016,
> 1296	              
> <https://ieeexplore.ieee.org/abstract/document/7444905>.
> 
> 1298	   [Moiseenko2014]
> 1299	              Moiseenko, I., Stapp, M., and D. Oran, "Communication
> 1300	              patterns for web interaction in named data 
> networking",
> 1301	              DOI 10.1145/2660129.2660152, September 2014,
> 1302	              <https://dl.acm.org/doi/10.1145/2660129.2660152>.
> 
> 1304	   [Mosko2017]
> 1305	              Mosko, M., "CCNx 1.0 Bidirectional Streams",
> 1306	              arXiv 1707.04738, July 2017,
> 1307	              <https://arxiv.org/abs/1707.04738>.
> 
> 1309	   [NDN]      "Named Data Networking", 2020,
> 1310	              <https://named-data.net/project/execsummary/>.
> 
> 1312	   [NDNTLV]   "NDN Packet Format Specification", 2016,
> 1313	              <http://named-data.net/doc/ndn-tlv/>.
> 
> 1315	   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., 
> Johnston,
> 1316	              A., Peterson, J., Sparks, R., Handley, M., and E.
> 1317	              Schooler, "SIP: Session Initiation Protocol", RFC 
> 3261,
> 1318	              DOI 10.17487/RFC3261, June 2002,
> 1319	              <https://www.rfc-editor.org/info/rfc3261>.
> 
> 1321	   [RFC6337]  Okumura, S., Sawada, T., and P. Kyzivat, "Session
> 1322	              Initiation Protocol (SIP) Usage of the Offer/Answer
> 1323	              Model", RFC 6337, DOI 10.17487/RFC6337, August 2011,
> 1324	              <https://www.rfc-editor.org/info/rfc6337>.
> 
> 1326	   [RFC7530]  Haynes, T., Ed. and D. Noveck, Ed., "Network File 
> System
> 1327	              (NFS) Version 4 Protocol", RFC 7530, DOI 
> 10.17487/RFC7530,
> 1328	              March 2015, 
> <https://www.rfc-editor.org/info/rfc7530>.
> 
> 1330	   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) 
> Protocol
> 1331	              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 
> 2018,
> 1332	              <https://www.rfc-editor.org/info/rfc8446>.
> 
> 1334	   [Zhang2018]
> 1335	              Zhang, Y., Xia, Z., Mastorakis, S., and L. Zhang, 
> "KITE:
> 1336	              Producer Mobility Support in Named Data Networking, 
> in
> 1337	              Proceedings of the 5th ACM Conference on Information-
> 1338	              Centric Networking - ICN '18",
> 1339	              DOI 10.1145/3267955.3267959, September 2018,
> 1340	              
> <https://conferences.sigcomm.org/acm-icn/2018/proceedings/
> 1341	              icn18-final23.pdf>.
> 
> 1343	Authors' Addresses
> 
> 1345	   Dave Oran
> 1346	   Network Systems Research and Design
> 1347	   4 Shady Hill Square
> 1348	   Cambridge, MA 02138
> 1349	   United States of America
> 
> 1351	   Email: [e-mail]
> 
> 1353	   Dirk Kutscher
> 1354	   University of Applied Sciences Emden/Leer
> 1355	   Constantiapl. 4
> 1356	   26723 Emden
> 1357	   Germany
> 
> 1359	   Email: [e-mail]
> 1360	   URI:   https://dirk-kutscher.info
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> DaveO
> 
> 
> 
> _______________________________________________
> xml2rfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xml2rfc
>