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

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 2 Apr 2020 15:53:20 +0200

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: [email-masked]
> 
> 1353	   Dirk Kutscher
> 1354	   University of Applied Sciences Emden/Leer
> 1355	   Constantiapl. 4
> 1356	   26723 Emden
> 1357	   Germany
> 
> 1359	   Email: [email-masked]
> 1360	   URI:   https://dirk-kutscher.info
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> DaveO
> 
> 
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc
>

---

From: "David R. Oran" <[email-masked]>
Date: Thu, 02 Apr 2020 09:59:42 -0400

> Will investigate, and if possible provide a fix in the next release,
I looked more carefully and this is because the author address is so long it looks like it’s only one character away from the status, and hence is parsed as part of that. Probably need to figure out how to split long right-justified lines that over-run to the left.

> Huh.  I'll check the code.
On further investigation, I think this is a boggie due to the intended status getting defaulted to Proposed Standard when incorrectly parse above.

> Ack.  Will follow up when I have more information.
Many thanks!
I decided to try to submit anyway and am now being done in by “Failed decoding the uploaded file: "'ascii' codec can't decode byte 0xc3 in position 69240: ordinal not in range(128)"

Time to go count characters in the .txt file. Sigh.

DaveO

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 2 Apr 2020 16:40:32 +0200

Hi Dave,

On 2020-04-02 15:59, David R. Oran wrote:
> I looked more carefully and this is because the author address is so
> long it looks like it’s only one character away from the status, and
> hence is parsed as part of that. Probably need to figure out how to
> split long right-justified lines that over-run to the left.

Ack on that.  I've adjusted idnits; will do a new release shortly.

> On further investigation, I think this is a boggie due to the
> intended status getting defaulted to Proposed Standard when
> incorrectly parse above.

Ah.  Right.

> I decided to try to submit anyway and am now being done in by “Failed
> decoding the uploaded file: "'ascii' codec can't decode byte 0xc3 in
> position 69240: ordinal not in range(128)"
> 

Saw your other post on this, good that the workaround worked.

Best,

	Henrik