idnits 2.17.1 draft-mosko-icnrg-selectors-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (May 8, 2019) is 1816 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC3552' is defined on line 602, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 607, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG M. Mosko 3 Internet-Draft PARC, Inc. 4 Intended status: Experimental May 8, 2019 5 Expires: November 9, 2019 7 CCNx Selector Based Discovery 8 draft-mosko-icnrg-selectors-01 10 Abstract 12 CCNx selector based discovery uses exclusions and interest name 13 suffix matching to discover content in the network. Participating 14 nodes may respond with matching Content Objects from cache using an 15 encapsulation protocol. This document specifies the available 16 selectors, their encoding in a name segment, and the encapsulation 17 protocol. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 9, 2019. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 2. Protocol Description . . . . . . . . . . . . . . . . . . . . 3 56 3. Name Labels and TLV types . . . . . . . . . . . . . . . . . . 5 57 3.1. Child Selector . . . . . . . . . . . . . . . . . . . . . 7 58 3.2. Interest Min(Max)SuffixComponents . . . . . . . . . . . . 7 59 3.3. Name Excludes . . . . . . . . . . . . . . . . . . . . . . 7 60 3.3.1. Exclude Singleton . . . . . . . . . . . . . . . . . . 9 61 3.3.2. Exclude Range . . . . . . . . . . . . . . . . . . . . 9 62 3.3.3. Examples . . . . . . . . . . . . . . . . . . . . . . 9 63 4. Content Store and Caching . . . . . . . . . . . . . . . . . . 10 64 5. Annex A: Examples . . . . . . . . . . . . . . . . . . . . . . 11 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 69 8.2. Informative References . . . . . . . . . . . . . . . . . 13 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 72 1. Introduction 74 Content Discovery is an important feature of CCNx [CCNxSemantics]. 75 This document specifies a discovery mechanism that uses a name 76 segment to encode a discovery query in an Interest. Nodes that 77 participate in discovery may reply with a Content Object if it 78 matches the encoded query. The query uses exclusions to work around 79 incorrect responses. 81 This document updates CCNx Messages [CCNxMessages] with a new name 82 TLV type, T_SELECTOR, for selector query. It also specifies a new 83 Content Object PayloadType that encapsulates another Content Object. 84 The inner Content Object is used to return a Content Object with a 85 longer name than in an interest. The inner object's signature should 86 verify as normal. 88 Not all nodes along the Interest path need to participate in the 89 discovery process. A non-participating node should forward the 90 Interest and encapsulating Content Object as normal. A participating 91 node should verify that the inner Content Object matches the selector 92 query in the PIT entry befor returning it and erasing the PIT entry. 94 Note that Selector discovery is not needed when asking for a Content 95 Object by its Content-Object Hash, as there should only ever be one 96 match for that. 98 Selector discovery in CCNx 1.0 differs in three ways from the prior 99 CCNx 0.x selector discovery. First, CCNx 1.0 uses a distinguished 100 field for the Content-Object Hash restriction. It is not appended to 101 the name to form the so-called "full name." This means that there is 102 no implicit digest name segment. Thus, using a MinSuffixComponents 103 and MaxSuffixComponents of 0 will match the exact name in the 104 Interest without needing to add one extra component to account for 105 the implicit digest. Second, there is a HashExcludes field that 106 lists Content-Object Hash restrictions to exclude instead of 107 appending them as an implicit name component. Third, the encoding of 108 Excludes differs from prior encodings and uses a simpler formulation 109 with the same expressiveness that also takes in to consideration that 110 name segments in CCNx 1.0 have TLV types associated with them. 112 CCNx 1.0 allows Content Objects to have no name and be retrieved by 113 hash only. As they have no name, they are not discoverable via name- 114 based selector discovery. 116 Packets are represented as 32-bit wide words using ASCII art. 117 Because of the TLV encoding and optional fields or sizes, there is no 118 concise way to represent all possibilities. We use the convention 119 that ASCII art fields enclosed by vertical bars "|" represent exact 120 bit widths. Fields with a forward slash "/" are variable bitwidths, 121 which we typically pad out to word alignment for picture readability. 123 1.1. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 2. Protocol Description 131 Selector based discovery uses seven query variables to discover 132 content. These selectors are encoded as a single name segment 133 affixed to an Interest name. The selectors operate on the prefix up 134 to, but not including the selector name segment. The selector name 135 segment should be the last name segment. 137 The selectors are: 139 o MinSuffixComponents: the minimum number of additional name 140 segments a matching Content Object must have in its name. The 141 default value is 0. 143 o MaxSuffixComponents: The maximum number of additional name 144 segments a matching Content Object may have in its name. The 145 default value is unlimited. 147 o ChildSelector: Answer with the left-most or right-most child. 149 o NameExcludes: A set of range and singleton exclusions to eliminate 150 Content Objects. The exclusions match against the name segment 151 that would immediately follow the Interest name prefix up to but 152 not including the Selector name segment. 154 o InnerKeyId: Matches the KeyId of the encapsulated object. 156 o HashExcludes: A list of ContentObjectHashRestrictions to exclude. 158 o SelectorNonce: A number to make the query unique. 160 A node using Selector discovery appends a Selector name segment to 161 the end of the Interest name. Even if no selectors are used, the 162 Selector name segment is added to the end, which indicates to a 163 participating node that it should apply Selector based matching to 164 the Interest. In this case, the default values -- if any -- of each 165 selector are used. 167 A node receiving a Selector Interest should match against the Content 168 Store using the selector rules. Based on the sort order, it should 169 pick the appropriate Content Object, if any, and return it in an 170 Encapsulation Object. If no Content Objects match, the Interest 171 should be forwarded or NACKed as normal. 173 An Encapsulation Object is a Content Object that matches the Selector 174 Interest and whose payload is the discovered Content Object. The 175 ContentType of an Encapsulation Object is "ENCAP". The outer name 176 matches the Selector Interest name. The inner Content Object name 177 matches the Selector discovery. 179 The KeyIdRestriction of the Interest matches the outer KeyId of the 180 outer Content Object, as normal. This allows a responding cache or 181 producer to sign (or MAC or MIC) the response. The InnerKeyId of the 182 Selector matches the inner ContentObject in the same way. This 183 allows the selector to discriminate discovery including the inner 184 KeyId. 186 The HashExcludes eliminate any Content Objects whose 187 ContentObjectHash matches any of the listed values. It should not 188 matter if matching objects are discarded before name prefix selector 189 matching or after. A Content Object must always pass both the 190 HashExcludes filter and the name prefix selector filters, wether it 191 is done first or last does not matter. HashExcludes are encoded the 192 same way as a ContentObjectHashRestriction value in an Interest. 193 Note that this Selector does not exist in NDN or CCNx 0.x. We use an 194 explicit set of HashExcludes rather than constructing a full name 195 with the implicit digest component at the end. 197 A consumer MAY include a SelectorNonce. This nonce is to make the 198 query unqiue to bypass cached reponses to the same Selectors at non- 199 participating nodes. A conumser SHOULD use this field if it receives 200 an non-conforming response in an encapsulated ContentObject and 201 cannot further exclude that response. If an attacker were able to 202 inject an incorrect response into a non-participating cache then that 203 non-participating node cannot determine that the response it is 204 serving from cache is correct or not. Therefore, a consumer can use 205 the SelectorNonce to make its requrest name different from the cached 206 name. Note that if all nodes are participating, then this field has 207 no effect as it is not processed by them. The SelectorNone is not 208 used for loop detection and may be as few bytes as needed to avoid a 209 cached response. 211 If an authoritative producer receives a Selector discovery, it SHOULD 212 generate the inner Content Object as normal and encapsulate it as 213 normal. It MAY also respond with an Interest Return or not respond 214 at all. At the present, responding directly to the Selector Interest 215 with data without encapsulating it is not supported. Note that an 216 application is NOT REQUIRED to implement Selector discovery; if the 217 application wishes to make use of this mechanism, then it must 218 implement it, if it does not use this mechanism then it does not need 219 to implement it. 221 Normally, the outer Content Object does not have a Validation 222 section. A responding node MAY include a CRC32C or other integrity 223 check. Signing or MACing an outer Content Object is possible, but 224 should only be used in environments where that degree of trust is 225 necessary. Signing the outer Content Object in no way replaces the 226 signature (if any) of the inner Content Object. The outer signature 227 only identifies the responding cache (or producer). 229 3. Name Labels and TLV types 231 The Selector name segment type T_SELECTOR has type %x0010. 233 The PayloadType of T_PAYLOADTYPE_ENCAP has the value 8. 235 +------+-----------------+------------+-----------------------------+ 236 | Type | Symbol | Name | Description | 237 +------+-----------------+------------+-----------------------------+ 238 | 1 | T_MINSUFFIX | Selectors: | Minimum number of | 239 | | | Min Suffix | additional name components | 240 | | | Components | after given name to match | 241 | | | | (0 default if missing). | 242 | | | | | 243 | 2 | T_MAXSUFFIX | Selectors: | Maximum number of | 244 | | | Max Suffix | additional name components | 245 | | | Components | after given name to match | 246 | | | | (unlimited default is | 247 | | | | missing). | 248 | | | | | 249 | 3 | T_CHILD | Selectors: | 0 = left, 1 = right | 250 | | | Child | (default) | 251 | | | Selector | | 252 | | | | | 253 | 4 | T_NAME_EXCLUDES | Name | Encloses ExcludeComponents | 254 | | | Excludes | | 255 | | | | | 256 | 1 | T_EX_SINGLE | Exclude | Exclude a single name | 257 | | | Singleton | segment. | 258 | | | | | 259 | 2 | T_EX_RANGE | Exclude | Exclude an half-open range, | 260 | | | Range | beginning at this value and | 261 | | | | continuing up to the next | 262 | | | | Singleton, or to infinity | 263 | | | | if omitted on the last | 264 | | | | entry. | 265 | | | | | 266 | 5 | T_INNER_KEYID | Inner | A restriction on the inner | 267 | | | KeyId | keyid. If present, it must | 268 | | | | match the KeyId of the | 269 | | | | inner Content Object in the | 270 | | | | encapsulated response. | 271 | | | | | 272 | 6 | T_HASH_EXCLUDES | Hash | Excludes a set of | 273 | | | Excludes | ContentObjectHash from the | 274 | | | | allowed responses. Each | 275 | | | | restriction is encoded | 276 | | | | using its Hash Function | 277 | | | | Type Registry type (e.g. | 278 | | | | T_SHA-256) from | 279 | | | | [CCNxMessages]. | 280 +------+-----------------+------------+-----------------------------+ 282 Table 1: Selector Types 284 3.1. Child Selector 286 If there are multiple choices to answer an Interest, the Child 287 Selector specifies the desired ordering of responses. %x00 = 288 leftmost, %x01 = rightmost. 290 1 2 3 291 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 292 +---------------+---------------+---------------+ 293 | T_CHILD | 1 | selector | 294 +---------------+---------------+---------------+ 296 3.2. Interest Min(Max)SuffixComponents 298 The Min and Max suffix components are encoded as a minimum-length 299 unsigned integer in network byte order number inside the value. A 300 "0" is represented as a single byte %0x00. A length 0 value is 301 interpreted the same as the type not being present. 303 1 2 3 304 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 305 +---------------+---------------+---------------+---------------+ 306 | type | length | / 307 +---------------+---------------+ / 308 / Min(Max)SuffixComponents / 309 +---------------+---------------+---------------+---------------+ 310 type = T_MINSUFFIX or T_MAXSUFFIX 312 3.3. Name Excludes 314 Interest Excludes specify a set of singletons and ranges to exclude 315 when matching Content Object names to an Interest. They match the 316 name component immediately following the last component of the 317 Interest name (not including the Selector TLV). The excludes must be 318 sorted in ascending order, using the Exclude sorting rules below. 320 A name exclusion is the full TLV expression of a name component, not 321 just it's value. 323 Exclude Sorting: An exclusion value A is less than B iff the TLV type 324 of A is less than the TLV type of B, or being equal, the TLV value of 325 A is shortlex less than the TLV value of B. A shortlex comparison 326 means that X is less than Y is X is shorter than Y or the lengths 327 being equal, X lexicagraphically sorts before Y. 329 Using the normal 2+2 TLV encoding of [CCNxMessages], the Exclude 330 Sorting can be done by a byte-by-byte memcmp() of two TLVs. This is 331 because the fixed length Type ensures correct type sorting and fixed 332 length Length ensures correct shortlex length sorting. This will not 333 necessarily be true of other encodings. 335 A zero-length exclusion is the minimum exclusion and must appear 336 before any other exclusion. Note that a zero-length exlcusion has no 337 TLV type for the name component, so it will match any name segment 338 TLV type. It is equivalent to minus infinity. 340 The zero-length name component is the minimum name component of that 341 name component type (e.g.T_NAMESEGMENT). 343 An exclude may contain either an Exclude Range type or an Exclude 344 Singleton type. An Exclude Range type means the given value starts a 345 half-open exclusion range that begins inclusive of the Range value 346 and ends open at the next Singleton or at infinity if it is the last 347 exclude component. An Exclude Singleton means to exclude the exact 348 value given. 350 Note that this syntax does not require the "ANY" exclude component 351 that is part of the NDN and CCNx 0.x syntax. 353 1 2 3 354 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 355 +---------------+---------------+---------------+---------------+ 356 | T_EXCLUDES | length | 357 +---------------+---------------+---------------+---------------+ 358 / Zero or more exclude-components / 359 +---------------------------------------------------------------+ 361 exclude-components = *component [start-range-tlv] 362 component = (start-range-tlv singleton-tlv) / singleton-tlv 364 The ABNF of the exclude-component allows for zero or more components 365 followed by an option start-range-tlv. A component is either a half- 366 open range (start-range-tlv singleton-tlv) or a singleton-tlv. 368 The optional final start-range-tlv has no terminating singleton-tlv. 369 This means it extends out to plus infinity. 371 Note that to exclude from negative infinity to some value "foo", we 372 do not need to include an ANY element because the zero-length name 373 component is, by definition, the minimum element and we use inclusive 374 range start. Therefore, begining an exlcusion with the zero-length 375 range effectively excludes from minus infinity. 377 3.3.1. Exclude Singleton 379 A singleton exclude component means to exclude a name segment exactly 380 matching the given value. 382 1 2 3 383 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 384 +---------------+---------------+---------------+---------------+ 385 | T_EX_SINGLE | length | 386 +---------------+---------------+---------------+---------------+ 387 / TLV name segment / 388 +---------------+---------------+---------------+---------------+ 390 3.3.2. Exclude Range 392 A Range exclude means to exclude the from the given value up to but 393 not including the next Singleton. If the Range is the last component 394 in the Exclude, it means to exclude to infinity. 396 1 2 3 397 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 398 +---------------+---------------+---------------+---------------+ 399 | T_EX_RANGE | length | 400 +---------------+---------------+---------------+---------------+ 401 / TLV name segment / 402 +---------------+---------------+---------------+---------------+ 404 3.3.3. Examples 406 In these examples, we will use the notation S[foo] to represent a 407 singleton exclusion "foo" and R[foo] to represent a range exclusion 408 beginning at "foo." In the column Range, we use standard open 409 (parenthesis) and closed (square bracket) interval notation. We 410 assume all TLV name types of T_NAMESEGMENT if there is no explicit 411 name segment type given. In our notation, something like S[VER=bar] 412 would exclude a TLV type Version and value "bar". 414 +---------------+---------------------------------------------------+ 415 | Exclude | Range | 416 | Pattern | | 417 +---------------+---------------------------------------------------+ 418 | S[ace] | NAME=ace | 419 | | | 420 | S[ace] R[bat] | NAME=ace, [NAME=bat, infty) | 421 | | | 422 | R[ace] S[bat] | [NAME=ace, NAME=bat) | 423 | | | 424 | R[CHUNK=0] | [CHUNK=0, CHUNK=20) | 425 | S[CHUNK=20] | | 426 | | | 427 | R[] S[ace] | (-infty, NAME=ace), matches any preceeding TLV | 428 | | types using a zero-length Range exclude | 429 | | | 430 | R[NAME=] | [NAME=, NAME=ace) | 431 | S[ace] | | 432 | | | 433 | R[] | (-infty, +infty) | 434 | | | 435 | S[zoo] S[ape] | Invalid range, not sorted | 436 | | | 437 | R[NAME=ace] | [NAME=ace, CHUNK=0), this will span TLV ranges | 438 | S[CHUNK=0] | type between T_NAMESEGMENT and T_CHUNK | 439 | | | 440 | R[CHUNK=] | [CHUNK=, CHUNK+1=), excludes all CHUNK TLV | 441 | S[CHUNK+1=] | possibilities | 442 +---------------+---------------------------------------------------+ 444 Table 2: CCNx Name Types 446 4. Content Store and Caching 448 The encapsulated responses to discovery are cachable, like all 449 Content Objects. A participating forwarder MAY cache the inner 450 Content Object separately from the outer Content Object assuming it 451 passes the selector tests. A non-participating forwarder MAY only 452 cache the outer Content Object (encapsulating the inner). 454 A participating content store MUST obey both the outer and inner 455 cache control directives: ExpiryTime and RecommendedCacheTime. At a 456 participating node, the outer and inner Content Objects are 457 independent and cached independently. This is allowed because a 458 participating node has verified that the inner ContentObject comes 459 from an on-path direction of the routing prefix, so it cannot be an 460 off-path injection of bad content. 462 A non-participating content store must obey the outer cache control 463 directives, as normal. The inner content object is opaque data to 464 it. 466 It is RECOMMENDED that a participating node creating the encapsulated 467 response set a short ExpiryTime and MAY set a 0 ExpiryTime (to 468 prevent all caching). This is desirable because non-participating 469 nodes only look at the outer ExpiryTime and cannot determine if the 470 inner ContentObject actually satisfies the Selector query. Note that 471 a consumer can also use a SelectorNonce to avoid bad cache entries at 472 non-participating nodes, so it is not necessary for correctness to 473 use a 0 ExpiryTime. 475 Note that cached respones are, in general, not a problem for the 476 discovery process. Participating nodes will always do a full 477 selector match, so a consumer can work around incorrect responses as 478 normal. Because Selector interests with differnent Exclude blocks 479 will result in different names, prior responses will not match in the 480 caches of non-participating nodes, esepcially if the ExpiryTime is 481 set to 0. 483 5. Annex A: Examples 485 We use the CCNx URI scheme [ccnx-uri], CCNx Chunking [ccnx-chunking], 486 and CCNx versioning [ccnx-version]. For example purposes, will use 487 content stored under the name ccnx://example.com/protocol.pdf. The 488 names stored in a repository are, in sorted order: 490 o ccnx:/example/file.txt/Serial=%00/Chunk=%00 492 o ccnx:/example/file.txt/Serial=%01/Chunk=%00 494 o ccnx:/example/file.txt/Serial=%02/annotations/Serial=%00/Chunk=%00 496 o ccnx:/example/file.txt/Serial=%02/Chunk=%00 498 o ccnx:/example/file.txt/Serial=%02/Chunk=%01 500 o ccnx:/example/file.txt/Serial=%02/%f001=foo 502 o ccnx:/example/file.txt/Serial=%02/%f001=foo/%f002=bar 504 Remember that name segments without an explicit type have type Name 505 Segment, which is normalized to %x0001. Chunk is %x0010 and Serial 506 is %x0013. This means the sort order is as above. 508 To discovery the latest version of file.txt, we would issue an 509 Interest with a name of "ccnx:/example/file.txt/ 510 Selector={MINSUFFIX=1}." We use the notation {...} to indicate that 511 the enclosed selectors are encoded as a single TLV name segment. 512 This query ensures that there is at least 1 additional name segment 513 beyond "file.txt." The default is to return the right-most child, 514 which in this case is the Content Object corresponding to 515 "ccnx:/example/file.txt/Serial=%02/%f001=foo/%f002=bar." 517 By parsing the returned name, we know that Serial 2 is the latest 518 version and could begin retrieving the content by asking for chunk 0. 519 If we wished to discovery the ending chunk number of Serial 2, we 520 could use an Interest like "ccnx:/example/file.txt/Serial=%02/ 521 Selector={MINSUFFIX=1, MAXSUFFIX=1}" to try and find a response with 522 only a Chunk number. Unfortunately, there is more junk content with 523 the name "ccnx:/example/file.txt/Serial=%02/%f001=foo." 525 Once we recieve the junk content, we need to exclude it and try 526 again. This could be done by including a hash exclusion. Assuing 527 the SHA256 hash of the returned junk is %x0101...abc, we would re- 528 issue the discovery Interest with name 529 "ccnx:/example/file.txt/Serial=%02/Selector={MINSUFFIX=1, 530 MAXSUFFIX=1, HASH_EXCLUDE=%x0101...abc}." We would now recieve the 531 desired content for chunk 1 of Serial 2. 533 A better way to discover structured names is to use exclusions so we 534 only find objects with a Chunk segment after the serial number. In 535 this case, the discovery Interest would be name 536 "ccnx:/example/file.txt/Serial=%02/Selector={MINSUFFIX=1, 537 MAXSUFFIX=1, EXCLUDES=R[] S[Chunk=0] R[CHUNK+1=]}." This exclusion 538 eliminates everything from -infinity up to, but not including, 539 Chunk=0 and also excludes everything from Chunk+1 (%x0011) to 540 +infinity. 542 6. IANA Considerations 544 This memo includes no request to IANA. TODO: If this document is 545 submitted as an official draft, this section must be updated to 546 reflect the IANA registries described in [CCNxMessages] 548 7. Security Considerations 550 Because respones use encapsulation, there is size expansion in the 551 response from the original Content Object. The expansion will be the 552 length of the encapsulating Selector name plus the size of any 553 validation uses on the outer Content Object (e.g. a CRC32C), plus 554 framing overhead. This means that one cannot respond with a Content 555 Object that is too close to the maximum packet size. 557 Participating nodes should be able to filter incorrect responses just 558 as they do in NDN or CCNx 0.x. If all node participate, then one has 559 equivalent in-network filtering behavior as those other protocols. 561 If the outer Content Object is signed, the consumer should, as 562 normal, verify the signature for accuracy. However, the trust of the 563 outer signature is normally not important and usually reflects 564 operation in a specific environment. An outer Validation section is 565 usually used only for integrity checks. 567 8. References 569 8.1. Normative References 571 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 572 Requirement Levels", BCP 14, RFC 2119, 573 DOI 10.17487/RFC2119, March 1997, . 576 8.2. Informative References 578 [ccnx-chunking] 579 Mosko, M., "CCNx Content Object Chunking", Work in 580 Progress, draft-mosko-icnrg-ccnxchunking-02, June 2016. 582 [ccnx-uri] 583 Mosko, M. and C. Wood, "The CCNx URI Scheme", Work in 584 Progress, draft-mosko-icnrg-ccnxurischeme-01, April 2016. 586 [ccnx-version] 587 Mosko, M., "CCNx Publisher Serial Versioning", Work in 588 Progress, draft-mosko-icnrg-ccnxserialversion-00, January 589 2015. 591 [CCNxMessages] 592 Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 593 Format (Internet draft)", 2019, 594 . 597 [CCNxSemantics] 598 Mosko, M., Solis, I., and C. Wood, "CCNx Semantics 599 (Internet draft)", 2019, . 602 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 603 Text on Security Considerations", BCP 72, RFC 3552, 604 DOI 10.17487/RFC3552, July 2003, . 607 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 608 IANA Considerations Section in RFCs", RFC 5226, 609 DOI 10.17487/RFC5226, May 2008, . 612 Author's Address 614 Marc Mosko 615 PARC, Inc. 616 Palo Alto, California 94304 617 USA 619 Phone: +01 650-812-4405 620 Email: marc.mosko@parc.com