idnits 2.17.1 draft-blanchet-dtnrg-iana-registries-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([DTNRGREG]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 22, 2010) is 5148 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'DTNRGREG' is mentioned on line 99, but not defined == Unused Reference: 'I-D.irtf-dtnrg-bundle-previous-hop-block' is defined on line 476, but no explicit reference was found in the text == Unused Reference: 'I-D.symington-dtnrg-bundle-multicast-custodial' is defined on line 498, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-irtf-dtnrg-bundle-metadata-block-07 == Outdated reference: A later version (-12) exists of draft-irtf-dtnrg-bundle-previous-hop-block-11 == Outdated reference: A later version (-19) exists of draft-irtf-dtnrg-bundle-security-15 == Outdated reference: A later version (-05) exists of draft-irtf-dtnrg-ecos-00 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Blanchet 3 Internet-Draft Viagenie 4 Intended status: Informational March 22, 2010 5 Expires: September 23, 2010 7 Delay-Tolerant Networks (DTN) IANA Registries 8 draft-blanchet-dtnrg-iana-registries-00.txt 10 Abstract 12 The DTNRG research group has defined many protocols such as Bundle 13 Protocol and Licklider. The specifications of these protocols 14 contain fields that are subject to a registry. For the purpose of 15 its research work, the group created adhoc registries[DTNRGREG]. As 16 the specifications are stable and have multiple interoperable 17 implementations, the group would like to handoff the registries to 18 IANA for official custidy. This document describes the actions 19 needed to be executed by IANA. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 23, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Bundle Protocol . . . . . . . . . . . . . . . . . . . . . . . 4 75 2.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . . 4 76 2.2. Primary Bundle Protocol Version . . . . . . . . . . . . . 6 77 2.3. Bundle Processing Control Flags . . . . . . . . . . . . . 6 78 2.4. Block Processing Control Flags . . . . . . . . . . . . . . 7 79 2.5. Bundle Status Report Flags . . . . . . . . . . . . . . . . 8 80 2.6. Bundle Status Report Reason Codes . . . . . . . . . . . . 9 81 2.7. Bundle Custody Signal Reason Codes . . . . . . . . . . . . 9 82 3. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 4. MIME Media Type . . . . . . . . . . . . . . . . . . . . . . . 11 84 5. LickLider Protocol . . . . . . . . . . . . . . . . . . . . . . 11 85 5.1. LickLider Protocol Version . . . . . . . . . . . . . . . . 11 86 5.2. LickLider Cancel Segments Reason Codes . . . . . . . . . . 11 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 89 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 90 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 93 1. Introduction 95 The DTNRG research group has defined many protocols[RFC4838] such as 96 Bundle Protocol[RFC5050] and Licklider[RFC5326]. The specifications 97 of these protocols contain fields that are subject to a registry. 98 For the purpose of its research work, the group created adhoc 99 registries[DTNRGREG]. As the specifications are stable and have 100 multiple interoperable implementations, the group would like to 101 handoff the registries to IANA for official custidy. This document 102 describes the actions needed to be executed by IANA. 104 2. Bundle Protocol 106 The Bundle Protocol(BP)[RFC5050] has fields requiring a registry 107 managed by IANA. 109 2.1. Bundle Block Types 111 The Bundle Protocol has a Bundle Block Type code field (section 112 4.5.2) [RFC5050]. An IANA registry shall be setup as follows. 114 The registration policy for this registry is: 115 0-191: Specification Required 116 192-255: Private or experimental use. No assignment by IANA. 118 The Value range is: unsigned 8 bit integer. 120 Bundle Block Type Codes Registry 122 +--------+--------------+-------------------------------------------+ 123 | Value | Description | Reference | 124 +--------+--------------+-------------------------------------------+ 125 | 0 | Reserved | This document | 126 | 1 | Bundle | [RFC5050] | 127 | | Payload | | 128 | | Block | | 129 | 2 | Bundle | [I-D.irtf-dtnrg-bundle-security] | 130 | | Authenticati | | 131 | | on Block | | 132 | 3 | Bundle | [I-D.irtf-dtnrg-bundle-security] | 133 | | Security | | 134 | | Block | | 135 | 4 | Payload | [I-D.irtf-dtnrg-bundle-security] | 136 | | Confidential | | 137 | | ity Block | | 138 | 5 | Previous Hop | [I-D.irtf-dtnrg-bundle-previous-hop-block | 139 | | Insertion | ] | 140 | | Block | | 141 | 6 | Proxy EID | [I-D.symington-dtnrg-bundle-multicast-cus | 142 | | Extension | todial] | 143 | | Block | | 144 | 7 | Retransmissi | [I-D.irtf-dtnrg-bundle-retrans-block] | 145 | | on Block | | 146 | 8 | Metadata | [I-D.irtf-dtnrg-bundle-metadata-block] | 147 | | Extension | | 148 | | Block | | 149 | 9 | Extension | [I-D.irtf-dtnrg-bundle-security] | 150 | | Security | | 151 | | Block | | 152 | 10-19 | Unassigned | | 153 | 20 | Extended | [I-D.irtf-dtnrg-ecos] | 154 | | Class of | | 155 | | Service | | 156 | | Block | | 157 | TBD | SCHL | [I-D.fall-dtnrg-schl] | 158 | | Extension | | 159 | | Block | | 160 | TBD-19 | Unassigned | | 161 | 1 | | | 162 | 192-25 | Private | [RFC5050] | 163 | 5 | and/or | | 164 | | experimental | | 165 | | use | | 166 +--------+--------------+-------------------------------------------+ 167 The value "0" was not defined in any document or in the adhoc 168 registry. As per concensus by the DNTRG research group, it is 169 reserved per this document. 171 RG TBD: decide for value 0. decide registration policy 173 2.2. Primary Bundle Protocol Version 175 The Bundle Protocol has a version field (section 4.5.1) [RFC5050]. 176 An IANA registry shall be setup as follows. 178 The registration policy for this registry is: RFC Required 180 The Value range is: unsigned 8 bit integer. 182 Primary Bundle Protocol Version Registry 184 +-------+-------------+---------------+ 185 | Value | Description | Reference | 186 +-------+-------------+---------------+ 187 | 0-5 | Reserved | This document | 188 | 6 | Assigned | [RFC5050] | 189 | 7-255 | Unassigned | | 190 +-------+-------------+---------------+ 192 RG TBD: decide registration policy. versions 0-5 are ... 194 2.3. Bundle Processing Control Flags 196 The Bundle Protocol has a Bundle Processing Control flags field 197 (section 4.2) [RFC5050]. An IANA registry shall be setup as follows. 199 The registration policy for this registry is: Specification Required 201 The Value range is: Variable length. 203 Bundle Processing Control Flags Registry 205 +---------------------+---------------------------------+-----------+ 206 | Bit Position (right | Description | Reference | 207 | to left) | | | 208 +---------------------+---------------------------------+-----------+ 209 | 0 | Bundle is a fragment | [RFC5050] | 210 | 1 | Application data unit is an | [RFC5050] | 211 | | administrative record | | 212 | 2 | Bundle must not be fragmented | [RFC5050] | 213 | 3 | Custody transfer is requested | [RFC5050] | 214 | 4 | Destination endpoint is a | [RFC5050] | 215 | | singleton | | 216 | 5 | Acknowledgement by application | [RFC5050] | 217 | | is requested | | 218 | 6 | Reserved | [RFC5050] | 219 | 7-8 | Class of service: priority | [RFC5050] | 220 | 9-13 | Class of service: reserved | [RFC5050] | 221 | 14 | Request reporting of bundle | [RFC5050] | 222 | | reception | | 223 | 15 | Request reporting of custody | [RFC5050] | 224 | | acceptance | | 225 | 16 | Request reporting of bundle | [RFC5050] | 226 | | forwarding | | 227 | 17 | Request reporting of bundle | [RFC5050] | 228 | | delivery | | 229 | 18 | Request reporting of bundle | [RFC5050] | 230 | | deletion | | 231 | 19 | Reserved | [RFC5050] | 232 | 20 | Reserved | [RFC5050] | 233 +---------------------+---------------------------------+-----------+ 235 RG TBD: decide registration policy. 237 2.4. Block Processing Control Flags 239 The Bundle Protocol has a Block Processing Control flags field 240 (section 4.2) [RFC5050]. An IANA registry shall be setup as follows. 242 The registration policy for this registry is: Specification Required 244 The Value range is: Variable length. 246 Block Processing Control Flags Registry 248 +--------------------+----------------------------------+-----------+ 249 | Bit Position | Description | Reference | 250 | (right to left) | | | 251 +--------------------+----------------------------------+-----------+ 252 | 0 | Block must be replicated in | [RFC5050] | 253 | | every fragment | | 254 | 1 | Transmit status report if block | [RFC5050] | 255 | | can't be processed | | 256 | 2 | Delete bundle if block can't be | [RFC5050] | 257 | | processed | | 258 | 3 | Last block | [RFC5050] | 259 | 4 | Discard block if it can't be | [RFC5050] | 260 | | processed | | 261 | 5 | Block was forwarded without | [RFC5050] | 262 | | being processed | | 263 | 0 | Block contains an EID-reference | [RFC5050] | 264 | | field | | 265 +--------------------+----------------------------------+-----------+ 267 RG TBD: decide registration policy. 269 2.5. Bundle Status Report Flags 271 The Bundle Protocol has a Status Report Status Flag field(section 272 6.1.1) [RFC5050]. An IANA registry shall be setup as follows. 274 The registration policy for this registry is: Specification Required 276 The Value range is: 8 bits. 278 Bundle Status Report Flags Registry 280 +----------+----------------------------------------+---------------+ 281 | Value | Description | Reference | 282 +----------+----------------------------------------+---------------+ 283 | 00000000 | Reserved | This document | 284 | 00000001 | Reporting node received bundle | [RFC5050] | 285 | 00000010 | Reporting node accepted custody of | [RFC5050] | 286 | | bundle | | 287 | 00000100 | Reporting node forwarded the bundle | [RFC5050] | 288 | 00001000 | Reporting node delivered the bundle | [RFC5050] | 289 | 00010000 | Reporting node deleted the bundle | [RFC5050] | 290 | 00100000 | Unassigned | [RFC5050] | 291 | 01000000 | Unassigned | [RFC5050] | 292 | 10000000 | Unassigned | [RFC5050] | 293 +----------+----------------------------------------+---------------+ 294 RG TBD: decide registration policy. value 0 is ... 296 2.6. Bundle Status Report Reason Codes 298 The Bundle Protocol has a Bundle Status Report Reason Codes 299 field(section 6.1.1) [RFC5050]. An IANA registry shall be setup as 300 follows. 302 The registration policy for this registry is: Specification Required 304 The Value range is: unsigned 8 bit integer. 306 Bundle Status Report Reason Codes Registry 308 +-------+-------------------------------------------+-----------+ 309 | Value | Description | Reference | 310 +-------+-------------------------------------------+-----------+ 311 | 0 | No additional information | [RFC5050] | 312 | 1 | Lifetime expired | [RFC5050] | 313 | 2 | Forwarded over unidirectional link | [RFC5050] | 314 | 3 | Transmission canceled | [RFC5050] | 315 | 4 | Depleted storage | [RFC5050] | 316 | 5 | Destination endpoint ID unintelligible | [RFC5050] | 317 | 6 | No known route to destination from here | [RFC5050] | 318 | 7 | No timely contact with next node on route | [RFC5050] | 319 | 8 | Block unintelligible | [RFC5050] | 320 | 9-255 | Unassigned | | 321 +-------+-------------------------------------------+-----------+ 323 RG TBD: decide registration policy. do we want to reserve a value for 324 future extensions? 255? 326 2.7. Bundle Custody Signal Reason Codes 328 The Bundle Protocol has a Bundle Custody Signal Reason Codes 329 field(section 6.1.2) [RFC5050]. An IANA registry shall be setup as 330 follows. 332 The registration policy for this registry is: Specification Required 334 The Value range is: unsigned 7 bit integer. 336 Bundle Custody Signal Reason Codes Registry 338 +-------+---------------+-------------------------------------------+ 339 | Value | Description | Reference | 340 +-------+---------------+-------------------------------------------+ 341 | 0 | No additional | [RFC5050] | 342 | | information | | 343 | 1-2 | Unassigned | | 344 | 3 | Redundant | [RFC5050] | 345 | | reception | | 346 | | (reception by | | 347 | | a node that | | 348 | | is a | | 349 | | custodial | | 350 | | node for this | | 351 | | bundle) | | 352 | 4 | Depleted | [RFC5050] | 353 | | storage | | 354 | 5 | Destination | [RFC5050] | 355 | | endpoint ID | | 356 | | unintelligibl | | 357 | | e | | 358 | 6 | No known | [RFC5050] | 359 | | route to | | 360 | | destination | | 361 | | from here | | 362 | 7 | No timely | [RFC5050] | 363 | | contact with | | 364 | | next node on | | 365 | | route | | 366 | 8 | Block | [RFC5050] | 367 | | unintelligibl | | 368 | | e | | 369 | 9 | Bundle | [I-D.symington-dtnrg-bundle-multicast-cus | 370 | | Forwarded | todial] | 371 | | Non-custodial | | 372 | | ly | | 373 | 10-12 | Unassigned | | 374 | 7 | | | 375 +-------+---------------+-------------------------------------------+ 377 RG TBD: decide registration policy. do we want to reserve a value for 378 future extensions? 255? 380 3. URI Scheme 382 IANA has registered the "dtn" URI Scheme 384 [IANAURISCH:http://www.iana.org/assignments/uri-schemes.html] as 385 provisional. This document requests to change the status of this 386 assignment from "Provisional" to "Permanent". 388 RG TBD: request dtn as permanent? has to be "ready" per RFC4395 390 4. MIME Media Type 392 RG TBD: do we want application/dtn? 394 5. LickLider Protocol 396 5.1. LickLider Protocol Version 398 The Licklider Protocol has a version field (section 3.1) [RFC5326]. 399 An IANA registry shall be setup as follows. 401 The registration policy for this registry is: RFC Required 403 The Value range is: unsigned 4 bit integer. 405 LickLider Protocol Version Registry 407 +-------+------------------+-----------+ 408 | Value | Description | Reference | 409 +-------+------------------+-----------+ 410 | 0 | RFC 5326 version | [RFC5326] | 411 | 1-15 | Unassigned | | 412 +-------+------------------+-----------+ 414 RG TBD: decide registration policy. 416 5.2. LickLider Cancel Segments Reason Codes 418 The LickLider Protocol has Cancel Segments Reason Codes field(section 419 3.2.4) [RFC5326]. An IANA registry shall be setup as follows. 421 The registration policy for this registry is: Specification Required 423 The Value range is: unsigned 8 bit integer. 425 LickLider Cancel Segments Reason Codes Registry 427 +-------+------------+----------------------------------+-----------+ 428 | Value | Mnemonic | Description | Reference | 429 +-------+------------+----------------------------------+-----------+ 430 | 0 | USR_CNCLD | Client service canceled session | [RFC5326] | 431 | 1 | UNREACH | Unreachable client service | [RFC5326] | 432 | 2 | RLEXC | Retransmission limit exceeded | [RFC5326] | 433 | 3 | MISCOLORED | Received either a red-part data | [RFC5326] | 434 | | | segment at block offset above | | 435 | | | any green-part data segment | | 436 | | | offset or a green-part data | | 437 | | | segment at block offset below | | 438 | | | any red-part data segment offset | | 439 | 4 | SYS_CNCLD | A system error condition caused | [RFC5326] | 440 | | | unexpected session termination | | 441 | 5 | RXMTCYCEXC | Exceeded the | [RFC5326] | 442 | | | Retransmission-Cycles limit | | 443 | 6-255 | Unassigned | | | 444 +-------+------------+----------------------------------+-----------+ 446 RG TBD: decide registration policy. RFC5326 says 6-255 is 447 "reserved". does that mean no new assignment, or "unassigned"? 449 6. Security Considerations 451 TBD 453 7. IANA Considerations 455 TBD. point to all sections requiring IANA Actions. 457 8. Acknowledgements 459 The editor would like to thank the following people who have provided 460 comments and suggestions to this document, in no specific order: 461 Stephen Farrell. 463 9. Normative References 465 [I-D.fall-dtnrg-schl] 466 Fall, K., "DTN Scope Control using Hop Limits (SCHL)", 467 draft-fall-dtnrg-schl-00 (work in progress), 468 February 2010. 470 [I-D.irtf-dtnrg-bundle-metadata-block] 471 Symington, S., "Delay-Tolerant Networking Metadata 472 Extension Block", 473 draft-irtf-dtnrg-bundle-metadata-block-07 (work in 474 progress), February 2010. 476 [I-D.irtf-dtnrg-bundle-previous-hop-block] 477 Symington, S., "Delay-Tolerant Networking Previous Hop 478 Insertion Block", 479 draft-irtf-dtnrg-bundle-previous-hop-block-11 (work in 480 progress), February 2010. 482 [I-D.irtf-dtnrg-bundle-retrans-block] 483 Symington, S., "Delay-Tolerant Networking Retransmission 484 Block", draft-irtf-dtnrg-bundle-retrans-block-06 (work in 485 progress), October 2009. 487 [I-D.irtf-dtnrg-bundle-security] 488 Symington, S., Farrell, S., Weiss, H., and P. Lovell, 489 "Bundle Security Protocol Specification", 490 draft-irtf-dtnrg-bundle-security-15 (work in progress), 491 February 2010. 493 [I-D.irtf-dtnrg-ecos] 494 Burleigh, S., "Bundle Protocol Extended Class Of Service 495 (ECOS)", draft-irtf-dtnrg-ecos-00 (work in progress), 496 December 2009. 498 [I-D.symington-dtnrg-bundle-multicast-custodial] 499 Symington, S., Durst, R., and K. Scott, "Delay-Tolerant 500 Networking Custodial Multicast Extensions", 501 draft-symington-dtnrg-bundle-multicast-custodial-06 (work 502 in progress), August 2009. 504 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 505 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 506 Networking Architecture", RFC 4838, April 2007. 508 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 509 Specification", RFC 5050, November 2007. 511 [RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider 512 Transmission Protocol - Specification", RFC 5326, 513 September 2008. 515 Author's Address 517 Marc Blanchet 518 Viagenie 519 2600 boul. Laurier, suite 625 520 Quebec, QC G1V 4W1 521 Canada 523 Email: Marc.Blanchet@viagenie.ca 524 URI: http://www.viagenie.ca