Bundle Protocol Version 7
draft-ietf-dtn-bpbis-31
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2022-01-24
|
31 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2021-11-30
|
31 | Zaheduzzaman Sarker | Shepherding AD changed to Zaheduzzaman Sarker |
2021-11-23
|
31 | (System) | RFC Editor state changed to AUTH48 |
2021-10-04
|
31 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2021-09-08
|
31 | (System) | RFC Editor state changed to REF from EDIT |
2021-08-02
|
31 | (System) | RFC Editor state changed to EDIT from MISSREF |
2021-02-23
|
31 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2021-02-23
|
31 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2021-02-23
|
31 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2021-02-22
|
31 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2021-02-17
|
31 | (System) | RFC Editor state changed to MISSREF from EDIT |
2021-02-17
|
31 | (System) | RFC Editor state changed to EDIT |
2021-02-17
|
31 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2021-02-17
|
31 | (System) | Announcement was received by RFC Editor |
2021-02-17
|
31 | (System) | IANA Action state changed to In Progress |
2021-02-17
|
31 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2021-02-17
|
31 | Cindy Morgan | IESG has approved the document |
2021-02-17
|
31 | Cindy Morgan | Closed "Approve" ballot |
2021-02-17
|
31 | Cindy Morgan | Ballot writeup was changed |
2021-02-17
|
31 | Magnus Westerlund | IESG state changed to Approved-announcement to be sent from Waiting for AD Go-Ahead |
2021-02-17
|
31 | Magnus Westerlund | Ballot approval text was generated |
2021-01-25
|
31 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-01-25
|
31 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-31.txt |
2021-01-25
|
31 | (System) | New version approved |
2021-01-25
|
31 | (System) | Request for posting confirmation emailed to previous authors: Edward Birrane , Kevin Fall , Scott Burleigh , dtn-chairs@ietf.org |
2021-01-25
|
31 | Scott Burleigh | Uploaded new revision |
2021-01-21
|
30 | Sabrina Tanamal | IANA Experts State changed to Expert Reviews OK from Issues identified |
2021-01-21
|
30 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2021-01-18
|
30 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2021-01-13
|
30 | (System) | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
2021-01-13
|
30 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-dtn-bpbis-30. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-dtn-bpbis-30. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. We understand that, upon approval of this document, there are eight actions which we must complete. First, in the Bundle Block Types registry on the Bundle Protocol registry page located at: https://www.iana.org/assignments/bundle/ the existing registry is to be changed. A new column will be added to the registry and marked as "Bundle Protocol Version." In addition, three new values are to be registered (values 6, 7 and 10). The revised Bundle Block Types registry will be as follows: +----------+-------+-----------------------------+----------------------------+ | Bundle | Value | Description | Reference | | Protocol | | | | | Version | | | | +----------+-------+-----------------------------+----------------------------+ | none | 0 | Reserved | [RFC6255] | | 6,7 | 1 | Bundle Payload Block | [RFC5050] | | 6 | 2 | Bundle Authentication Block | [RFC6257] | | 6 | 3 | Payload Integrity Block | [RFC6257] | | 6 | 4 | Payload Confidentiality Blk | [RFC6257] | | 6 | 5 | Previous-Hop Insertion Block| [RFC6259] | | 7 | 6 | Previous node (proximate | [ RFC-to-be ] | | | | sender) | | | 7 | 7 | Bundle age (in seconds) | [ RFC-to-be ] | | 6 | 8 | Metadata Extension Block | [RFC6258] | | 6 | 9 | Extension Security Block | [RFC6257] | | 7 | 10 | Hop count (#prior xmit | [ RFC-to-be ] | | | | attempts) | | | 7 | 11-191| Unassigned | | | 6,7 |192-255| Reserved for Private and/or | [RFC5050][ RFC-to-be ] | | | | Experimental Use | | +----------+-------+-----------------------------+----------------------------+ As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." Second, The Primary Bundle Protocol Version Registry also on the Bundle Protocol registry page located at: https://www.iana.org/assignments/bundle/ will have one, new registration added as follows: Value: 7 Description: Assigned Reference: [ RFC-to-be ] Third, in the Bundle Processing Control Flags registry on the Bundle Protocol registry page located at: https://www.iana.org/assignments/bundle/ the existing registry is to be changed. A new column will be added to the registry and marked as "Bundle Protocol Version." In addition, one new value is to be registered (values 6). The revised Bundle Processing Control Flags registry will be: +--------------------+----------------------------------+----------------------------+ | Bundle | Bit | Description | Reference | | Protocol| Position | | | | Version | (right | | | | | to left) | | | +--------------------+----------------------------------+----------------------------+ | 6,7 | 0 | Bundle is a fragment | [RFC5050][ RFC-to-be ] | | 6,7 | 1 | Application data unit is an | [RFC5050][ RFC-to-be ] | | | | administrative record | | | 6,7 | 2 | Bundle must not be fragmented | [RFC5050][ RFC-to-be ] | | 6 | 3 | Custody transfer is requested | [RFC5050] | | 6 | 4 | Destination endpoint is singleton| [RFC5050] | | 6,7 | 5 | Acknowledgement by application | [RFC5050][ RFC-to-be ] | | | | is requested | | | 7 | 6 | Status time requested in reports | [ RFC-to-be ] | | 6 | 7 | Class of service, priority | [RFC5050] | | 6 | 8 | Class of service, priority | [RFC5050] | | 6 | 9 | Class of service, reserved | [RFC5050] | | 6 | 10 | Class of service, reserved | [RFC5050] | | 6 | 11 | Class of service, reserved | [RFC5050] | | 6 | 12 | Class of service, reserved | [RFC5050] | | 6 | 13 | Class of service, reserved | [RFC5050] | | 6,7 | 14 | Request reporting of bundle | [RFC5050][ RFC-to-be ] | | | | reception | | | 6,7 | 16 | Request reporting of bundle | [RFC5050][ RFC-to-be ] | | | | forwarding | | | 6,7 | 17 | Request reporting of bundle | [RFC5050][ RFC-to-be ] | | | | delivery | | | 6,7 | 18 | Request reporting of bundle | [RFC5050][ RFC-to-be ] | | | | deletion | | | 6,7 | 19 | Reserved | [RFC5050][ RFC-to-be ] | | 6,7 | 20 | Reserved | [RFC5050][ RFC-to-be ] | | | 21-63 | Unassigned | | +--------------------+----------------------------------+----------------------------+ IANA Question --> In section 10.3 of the current document, Bundle Processing Control Flags bit position 15 is not accounted for. What should be the entry for bit position 15? As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." Fourth, in the Block Processing Control Flags registry on the Bundle Protocol registry page located at: https://www.iana.org/assignments/bundle/ the existing registry is to be changed. A new column will be added to the registry and marked as "Bundle Protocol Version." The revised Bundle Processing Control Flags registry will be: +--------------------+----------------------------------+------------------------+ | Bundle | Bit | Description | Reference | | Protocol| Position | | | | Version | (right | | | | | to left) | | | +--------------------+----------------------------------+------------------------+ | 6,7 | 0 | Block must be replicated in | [RFC5050][ RFC-to-be ] | | | | every fragment | | | 6,7 | 1 | Transmit status report if block | [RFC5050][ RFC-to-be ] | | | | can't be processed | | | 6,7 | 2 | Delete bundle if block can't be | [RFC5050][ RFC-to-be ] | | | | processed | | | 6 | 3 | Last block | [RFC5050] | | 6,7 | 4 | Discard block if it can't be | [RFC5050][ RFC-to-be ] | | | | processed | | | 6 | 5 | Block was forwarded without | [RFC5050] | | | | being processed | | | 6 | 6 | Block contains an EID reference | [RFC5050] | | | | field | | | | 7-63 | Unassigned | | +--------------------+----------------------------------+------------------------+ Fifth, in the Bundle Status Report Reason Codes registry on the Bundle Protocol registry page located at: https://www.iana.org/assignments/bundle/ the existing registry is to be changed. A new column will be added to the registry and marked as "Bundle Protocol Version." In addition, three new values are to be registered (values 9, 10 and 11). The revised Bundle Status Report Reason Codes registry will be as follows: +--------------------+-------------------------------------------+------------------------+ | Bundle | Value | Description | Reference | | Protocol | | | | | Version | | | | | | | | | +--------------------+--------+----------------------------------+------------------------+ | 6,7 | 0 | No additional information | [RFC5050][ RFC-to-be ] | | 6,7 | 1 | Lifetime expired | [RFC5050][ RFC-to-be ] | | 6,7 | 2 | Forwarded over unidirectional | [RFC5050][ RFC-to-be ] | | | | link | | | 6,7 | 3 | Transmission canceled | [RFC5050][ RFC-to-be ] | | 6,7 | 4 | Depleted storage | [RFC5050][ RFC-to-be ] | | 6,7 | 5 | Destination endpoint ID | [RFC5050][ RFC-to-be ] | | | | unintelligible | | | 6,7 | 6 | No known route to destination | [RFC5050][ RFC-to-be ] | | | | from here | | | 6,7 | 7 | No timely contact with next node | [RFC5050][ RFC-to-be ] | | | | on route | | | 6,7 | 8 | Block unintelligible | [RFC6255][ RFC-to-be ] | | 7 | 9 | Hop limit exceeded | [ RFC-to-be ] | | 7 | 10 | Traffic pared | [ RFC-to-be ] | | 7 | 11 | Block unsupported | [ RFC-to-be ] | | | 12-254 | Unassigned | | | 6,7 | 255 | Reserved | [RFC6255] | +-------+--------------------------------------------------------+------------------------+ As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." Sixth, a new registry is to be created called the Bundle Protocol URI Scheme Type registry. The new registry will be managed via Standards Action as defined by RFC 8126. The reference for the new registry is to be [ RFC-to-be ]. There are initial registrations in the new registry as follows: +--------------+-------------+----------------+--------------------------+ | Value | Description | BP Utilization | Reference | | | | Reference | | +--------------+-------------+----------------+--------------------------+ | 0 | Reserved | n/a | | | 1 | dtn | [ RFC-to-be ] | [ RFC-to-be ] | | 2 | ipn | [ RFC-to-be ] | RFC6260, RFC-to-be | | 3-254 | Unassigned | n/a | | | 255-65535 | reserved | n/a | | | >65535 | open for | n/a | | | | private use | | | +--------------+-------------+----------------+--------------------------+ Seventh, in the Uniform Resource Identifier (URI) Schemes registry located at: https://www.iana.org/assignments/uri-schemes/ the existing registration for: dtn will be changed as follows: URI Scheme: dtn Description: DTNRG research and development Status: permanent Reference: [ RFC-to-be ] As this document requests modifications in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." Eighth, in the Uniform Resource Identifier (URI) Schemes registry located at: https://www.iana.org/assignments/uri-schemes/ the existing registration for: ipn will be changed as follows: URI Scheme: ipn Description: ipn Status: permanent Reference: [ RFC-to-be ] As this document requests modifications in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2020-12-17
|
30 | Cindy Morgan | The following Last Call announcement was sent out (ends 2021-01-18): From: The IESG To: IETF-Announce CC: fred.l.templin@boeing.com, Fred Templin , magnus.westerlund@ericsson.com, dtn-chairs@ietf.org, … The following Last Call announcement was sent out (ends 2021-01-18): From: The IESG To: IETF-Announce CC: fred.l.templin@boeing.com, Fred Templin , magnus.westerlund@ericsson.com, dtn-chairs@ietf.org, draft-ietf-dtn-bpbis@ietf.org, dtn@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Bundle Protocol Version 7) to Proposed Standard The IESG has received a request from the Delay/Disruption Tolerant Networking WG (dtn) to consider the following document: - 'Bundle Protocol Version 7' as Proposed Standard This is a second IETF last call due to extensive changes since previous IETF last call. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-01-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This Internet Draft presents a specification for the Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research group of the Internet Research Task Force and documented in RFC 5050. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dtn-bpbis/ No IPR declarations have been submitted directly on this I-D. |
2020-12-17
|
30 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2020-12-17
|
30 | Magnus Westerlund | Last call was requested |
2020-12-17
|
30 | Magnus Westerlund | IESG state changed to Last Call Requested from IESG Evaluation::AD Followup |
2020-12-17
|
30 | Magnus Westerlund | Last call announcement was changed |
2020-12-17
|
30 | Magnus Westerlund | Last call announcement was generated |
2020-12-10
|
30 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-12-10
|
30 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-30.txt |
2020-12-10
|
30 | (System) | New version approved |
2020-12-10
|
30 | (System) | Request for posting confirmation emailed to previous authors: Scott Burleigh , Kevin Fall , dtn-chairs@ietf.org, Edward Birrane |
2020-12-10
|
30 | Scott Burleigh | Uploaded new revision |
2020-12-02
|
29 | Benjamin Kaduk | [Ballot comment] [updating my position for the -29, but no further actions are expected after my comments on the -27] Section 10.7 I assume that … [Ballot comment] [updating my position for the -29, but no further actions are expected after my comments on the -27] Section 10.7 I assume that as part of the IANA processing, we will have this document added as a reference for the updated "dtn" registration. (Whether or not that change is specifically mentioned in the final RFC is probably not of great import.) |
2020-12-02
|
29 | Benjamin Kaduk | Ballot comment text updated for Benjamin Kaduk |
2020-12-02
|
29 | Amanda Baber | URI scheme expert asked that references (cf. https://datatracker.ietf.org/doc/html/rfc7595#section-7.4) be added to the dtn and ipn templates, but called it non-blocking. |
2020-12-02
|
29 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-12-02
|
29 | Erik Kline | [Ballot comment] I was going to ballot as Discuss, but I lack some context on the history of this document and its evolution. Nevertheless, hopefully … [Ballot comment] I was going to ballot as Discuss, but I lack some context on the history of this document and its evolution. Nevertheless, hopefully the "discuss" points below leave a record of things about which I had some concern. [[ discuss ]] [ section 4.1.5.1.2 ] * The encoding considerations mentions "dtn" scheme but this is the "ipn" scheme section so...should this be "ipn"? [ section 5.2 ] * Should step 2 be step 1 of 5.3 (not 5.4)? [ section 5.4.2 ] * It seems to me that the behaviour in step 1, which I think does make some sense, pretty easily sets up the potential for ping-ponging (AIUI). If true, should there be some text (perhaps in 5.4) acknowledging that forwarding a given bundle to a node for the 2nd time might warrant, at least, some reassessment of the routing/reachability state in the node? I fully understand that extensive routing discussion is out of scope for this document. [ section 5.6 ] * Does "cannot process" include "does not understand"? If so it might be good to use a different reason value from "Block unintelligible" so that some other node can understand that, for example, the CRC (if sent) was valid. Basically, consider differentiating between "understood but malformed" and "not understood". [ section 5.9 ] * The mention of non-overlapping fragments brings a few issues to mind that have been encountered in IPv6 when considering fragment handling: [1] How are overlapping fragments to be handled? Are they ignored and/or cause any specific error to be generated? (vis. IPv6: RFC 5722) [2] What about "atomic fragments", i.e. a fragment that starts at offset zero and has a total payload length equal to the actual length of the payload (i.e. a fragmented payload consisting of a single fragment)? (vis. IPv6: RFC 6949) I'm guessing these should be silently accepted, but there might be some text saying they MUST/SHOULD NOT be generated. [[ comments ]] [ section 4.2.2 ] * The Creation Timestamp element description seems to copy a bunch of text from 4.1.7. Might be able to shorten the document a bit by referring to 4.1.7 for extended discussion of creation timestamp operations. [[ questions ]] [ section 4.3.3 ] * What's the value of using a {limit, incrementing_value} pair like this over just a single decrements_to_zero integer? I'm not suggesting this be changed (it's probably too late anyway), but I was just curious as to the motivation. |
2020-12-02
|
29 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2020-12-02
|
29 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2020-12-01
|
29 | Robert Wilton | [Ballot comment] Hi, Thank you for this document. Just a few minor observations/comments. Quite possibly only the last comment is actionable, and the rest are … [Ballot comment] Hi, Thank you for this document. Just a few minor observations/comments. Quite possibly only the last comment is actionable, and the rest are just observations. 1) Figure 2: Components of a Bundle Node It would be nice if this diagram is not split across page boundaries, hopefully the RFC editor can sort this out. 2) 4. Bundle Format Each bundle SHALL be a concatenated sequence of at least two blocks, represented as a CBOR indefinite-length array It wasn't immediate obvious why this restriction was here, I presume that this is to ensure that there is a canonical representation? 4.1.1. CRC Type I was surprised to see that CRC-16 is also supported. I presume that reasoning for this is because blocks could be small, and hence the overhead from always using CRC32 was regarded as being too much? 4.1.2. CRC I was also slightly surprised that these are encoded as fixed length byte strings rather than as unsigned integers. I presume that this is done to make them fixed length and also easier to zero out when performing the CRC calculation? It looks like RFC 2119 language used to define the bundle format both in section 4 and 4.2.1. Possibly it would be better to not use RFC 2119 language in the intro of section 4, and instead refer to 4.2.1 for the normative definition? Regards, Rob |
2020-12-01
|
29 | Robert Wilton | Ballot comment text updated for Robert Wilton |
2020-12-01
|
29 | Robert Wilton | [Ballot comment] Hi, Thank you for this document. Just a few minor observations/comments. Quite possibly only the last comment is actionable, and the rest are … [Ballot comment] Hi, Thank you for this document. Just a few minor observations/comments. Quite possibly only the last comment is actionable, and the rest are just observations. 1) Figure 2: Components of a Bundle Node It would be nice if this diagram is not split across page boundaries, hopefully the RFC editor can sort this out. 2) 4. Bundle Format Each bundle SHALL be a concatenated sequence of at least two blocks, represented as a CBOR indefinite-length array It wasn't immediate obvious why this restriction was here, I presume that this is to ensure that there is a canonical representation? 4.1.1. CRC Type I was surprised to see that CRC-16 is also supported. I presume that reasoning for this is because blocks could be small, and hence the overhead from always using CRC32 was regarded as being too much? 4.1.2. CRC I was also slightly surprised that these are encoded as fixed length byte strings rather than as unsigned integers. I presume that this is done to make them fixed length and also easier to zero out when performing the CRC calculation? It looks like RFC 2119 language used to define the bundle format both in section 4 and 4.2.1. Possibly it would be better to not use RFC 2119 language in the intro of section 4, and instead refer to 4.2 for the normative definition? Regards, Rob |
2020-12-01
|
29 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2020-11-30
|
29 | Alvaro Retana | [Ballot Position Update] Position for Alvaro Retana has been changed to No Objection from Discuss |
2020-11-24
|
29 | Martin Duke | [Ballot comment] Sec 4.1.5.1.2 I though this section was all about endpoint IDs. So what are the "all other purposes" that involve ASCII representations? Sec … [Ballot comment] Sec 4.1.5.1.2 I though this section was all about endpoint IDs. So what are the "all other purposes" that involve ASCII representations? Sec 7. Please add "congestion control" to the list of services the CL provides. Sec 10. There are many instances in these registries of a codepoint only applying to Version 6, but including 'RFC-to-be' as a reference. Is this a mistake, or am I missing something? |
2020-11-24
|
29 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2020-11-17
|
29 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-29.txt |
2020-11-17
|
29 | (System) | New version approved |
2020-11-17
|
29 | (System) | Request for posting confirmation emailed to previous authors: Kevin Fall , Scott Burleigh , Edward Birrane , dtn-chairs@ietf.org |
2020-11-17
|
29 | Scott Burleigh | Uploaded new revision |
2020-11-02
|
28 | Amy Vezza | Telechat date has been changed to 2020-12-03 from 2020-02-06 |
2020-10-30
|
28 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-28.txt |
2020-10-30
|
28 | (System) | New version approved |
2020-10-30
|
28 | (System) | Request for posting confirmation emailed to previous authors: Kevin Fall , Scott Burleigh , dtn-chairs@ietf.org, Edward Birrane |
2020-10-30
|
28 | Scott Burleigh | Uploaded new revision |
2020-10-30
|
27 | Benjamin Kaduk | [Ballot comment] Thank you for addressing my Discuss (and comment) points! Just a few final remarks on the -27 (no reply needed): Section 4.1.5.1 … [Ballot comment] Thank you for addressing my Discuss (and comment) points! Just a few final remarks on the -27 (no reply needed): Section 4.1.5.1 The second item of the array SHALL be the applicable CBOR representation of the scheme-specific part (SSP) of the EID, defined as noted in the URI scheme code number registry entry for the EID's URI scheme. (nit?) Perhaps "as noted in the reference(s) for the URI scheme code [...]", since the registry itself is unlikely to have those details. Section 4.1.5.1.1 Standard ABNF is case-insensitive, so we do match (e.g.) "DtN:NoNE" with this dtn-uri construction. While this might in some formal sense be problematic since (IIRC) URI schemes are case-sensitive, I don't think it's going to cause problems in practice and don't recommend any changes. Section 10.7 I assume that as part of the IANA processing, we will have this document added as a reference for the updated "dtn" registration. (Whether or not that change is specifically mentioned in the final RFC is probably not of great import.) |
2020-10-30
|
27 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2020-10-30
|
27 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to Yes from Discuss |
2020-10-27
|
27 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-27.txt |
2020-10-27
|
27 | (System) | New version approved |
2020-10-27
|
27 | (System) | Request for posting confirmation emailed to previous authors: Kevin Fall , Edward Birrane , Scott Burleigh , dtn-chairs@ietf.org |
2020-10-27
|
27 | Scott Burleigh | Uploaded new revision |
2020-10-23
|
26 | Benjamin Kaduk | [Ballot discuss] [Retaining (1) as placeholder for ongoing discussions; (11) is new] (1) It's not clear to me that we should be defining new (near-)application-layer … [Ballot discuss] [Retaining (1) as placeholder for ongoing discussions; (11) is new] (1) It's not clear to me that we should be defining new (near-)application-layer protocols on the standards track without mandatory security mechanisms. Even draft-ietf-dtn-bpsec defines a "BPSec threat model" that is largly the same as the RFC 3552 threat model, in which the network is completely untrusted and to provide end-to-end communications we must supply additional security mechanisms, yet BPSec is not required to implement or use. I could perhaps see room for allowing waypoint nodes that do not act as endpoints to remain security-unaware, but the justification for security-unaware endpoints seems quite lacking. (11) The ABNF for the "dtn" URI scheme does not seem to allow for a URI of "dtn:none". We may need to consult the ART ADs to determine how problematic this is, as this is a bit outside my area of expertise. |
2020-10-23
|
26 | Benjamin Kaduk | [Ballot comment] Section 4.1.5.1 The second item of the array SHALL be the applicable CBOR representation of the scheme-specific part (SSP) of the … [Ballot comment] Section 4.1.5.1 The second item of the array SHALL be the applicable CBOR representation of the scheme-specific part (SSP) of the EID, defined as noted in the specification for the EID's URI scheme. I think this would be in the document that makes the registration in the "URI scheme code numbers for Bundle Protocol" registry, which is not necessarily the same document that has the specification for the EID's URI scheme. (E.g., that seems to be the case for the "ipn" scheme already, since we are leaving RFC 6260 as the reference for the URI scheme registration but have the scheme code number for it in this document.) Section 4.1.5.1.1 [I note that the way the ABNF is currently written will cause endpoint ID URIs to have a trailing slash. This is not inherently problematic, of course, but may not be aesthetically preferred to everyone.] Section 4.2.2 of the bundle sequence count never be reset to zero. Note that, in general, the creation of two distinct bundles with the same source node ID and bundle creation timestamp may result in unexpected network behavior and/or suboptimal performance. The combination of source node ID and bundle creation timestamp serves to identify a single transmission request, enabling it to be acknowledged by the receiving application (provided the source node ID is not the null endpoint ID). Similar text appeared up in Section 4.1.7 already; we may not need it in both places. Section 5.2 Technically the text we have about source node ID being the "EID of a singleton endpoint whose only member is" is still accurate/workable even though we have nailed down more tightly the definition of "node ID", though we might consider just saying "node ID" here to make things a bit more deterministic. Section 5.4 forward the bundle. In that event, processing proceeds from Step 4 of Section 5.4. The minimum number of times a given node will (This is Section 5.4, so we could probably just say "proceeds from Step 4".) initiate another forwarding attempt for any single bundle in this event (a number which may be zero) is a node configuration parameter that MUST be exposed to other nodes in the network to the extent that this is required by the operating environment. (This caveats for this "MUST" are vague enough that it may be better as just a "must".) Section 5.6 has an attached CRC. If any block of the bundle is malformed according to this specification (including syntactically invalid CBOR), or if any block has an attached CRC and the CRC computed for (side note) I note that draft-ietf-cbor-7049bis introduces a new hierarchical ladder of classes of (in)validity and "well-formed"-ness. I think this description stands alone just fine, but it could potentially adopt the 7049bis terminology, too. Section 5.7 If this procedure results in reassembly of the entire original application data unit, processing of the fragmentary bundle whose payload has been replaced by the reassembled application data unit (whether this bundle or a previously received fragment) proceeds (nit) this wording is a little awkward, since we don't define "fragmentary bundles" until §5.8. Section 9 I think we should have a brief note that "[t]his protocol makes use of absolute timestamps for several purposes. Provisions are included for nodes without accurate clocks to retain most of the protocol functionality, but nodes that are unaware that their clock is inaccurate may exhibit unexpected behavior." Section 10.7 We probably want to have a clause about "orignally documented in RFC 5050" the way that we do for the "ipn" scheme in Section 10.8. And maybe also to have this document listed as the reference, since we have a lot more text (befitting a permanent, rather than provisional, scheme registration) about the scheme in this document. |
2020-10-23
|
26 | Benjamin Kaduk | Ballot comment and discuss text updated for Benjamin Kaduk |
2020-07-28
|
26 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-07-28
|
26 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-26.txt |
2020-07-28
|
26 | (System) | New version accepted (logged-in submitter: Scott Burleigh) |
2020-07-28
|
26 | Scott Burleigh | Uploaded new revision |
2020-06-29
|
25 | Magnus Westerlund | [Ballot discuss] Holding discuss to ensure IANA is satisfied, which they are pending 2 minor editorial fixes. |
2020-06-29
|
25 | Magnus Westerlund | [Ballot comment] I consider Mirja's discuss to be resolved. |
2020-06-29
|
25 | Magnus Westerlund | Ballot comment and discuss text updated for Magnus Westerlund |
2020-06-26
|
25 | Amanda Baber | Minor fix requested by URI Scheme expert. |
2020-06-26
|
25 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-06-05
|
25 | Amanda Baber | Issues identified by Bundle expert. Minor fix requested by URI Scheme expert. |
2020-05-22
|
25 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-25.txt |
2020-05-22
|
25 | (System) | New version approved |
2020-05-22
|
25 | (System) | Request for posting confirmation emailed to previous authors: Scott Burleigh , dtn-chairs@ietf.org, Kevin Fall , Edward Birrane |
2020-05-22
|
25 | Scott Burleigh | Uploaded new revision |
2020-03-09
|
24 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-24.txt |
2020-03-09
|
24 | (System) | New version approved |
2020-03-09
|
24 | (System) | Request for posting confirmation emailed to previous authors: Edward Birrane , Scott Burleigh , dtn-chairs@ietf.org, Kevin Fall |
2020-03-09
|
24 | Scott Burleigh | Uploaded new revision |
2020-03-04
|
23 | Magnus Westerlund | [Ballot discuss] Holding discuss to ensure IANA is satisfied. Taking over Mirja's discuss. There need to be a requirement on all convergence layers to provide … [Ballot discuss] Holding discuss to ensure IANA is satisfied. Taking over Mirja's discuss. There need to be a requirement on all convergence layers to provide congestion control or some other type of rate control. |
2020-03-04
|
23 | Magnus Westerlund | Ballot discuss text updated for Magnus Westerlund |
2020-02-25
|
23 | Roman Danyliw | Request closed, assignment withdrawn: Roman Danyliw Last Call SECDIR review |
2020-02-25
|
23 | Roman Danyliw | Closed request for Last Call review by SECDIR with state 'Withdrawn': Past review. Already balloted as AD on the draft. |
2020-02-24
|
23 | Roman Danyliw | [Ballot comment] Thank you for addressing my DISCUSS and COMMENTs items. |
2020-02-24
|
23 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2020-02-20
|
23 | Alexey Melnikov | [Ballot comment] I am clearing my DISCUSS with understanding that future work will be done in this area: 1) Retry strategies are listed as out-of-scope … [Ballot comment] I am clearing my DISCUSS with understanding that future work will be done in this area: 1) Retry strategies are listed as out-of-scope for this document. This is not sufficient for writing an interoperable implementation, unless there is a separate document that provides such details. Below I describe 1 remaining relevant place in the text and suggest some possible ways of addressing my DISCUSS: Step 5: When all selected convergence layer adapters have informed the bundle protocol agent that they have concluded their data sending procedures with regard to this bundle, processing may depend on the results of those procedures. If completion of the data sending procedures by all selected convergence layer adapters has not resulted in successful forwarding of the bundle (an implementation-specific determination that is beyond the scope of this specification), then the bundle protocol agent MAY choose (in an implementation-specific manner, again beyond the scope of this specification) to initiate another attempt to forward the bundle. Similar to the above: retries affect interoperability and should be documented as description of a convergence layer document. I think you need to add this as a requirement to section 7 ("Services Required of the Convergence Layer"). In that event, processing proceeds from Step 4 of Section 5.4. ********************************************************************** * Note, that I am conducting an experiment when people aspiring to be* * Area Directors get exposed to AD work ("AD shadowing experiment"). * * As a part of this experiment they get to review documents on IESG * * telechats according to IESG Discuss criteria document and their * * comments get relayed pretty much verbatim to relevant editors/WGs. * * As an AD I retain responsibility in defending their position when * * I agree with it. * * Recipients of these reviews are encouraged to reply to me directly * * about perceived successes or failures of this experiment. * ********************************************************************** I also have some comments on Benjamin's comments below marked with "[[Alexey]]:" The following comments were provided by Benjamin Schwartz : Benjamin would have balloted *DISCUSS* on this document. He wrote: This draft’s content seems sound but the text is difficult to understand and needs some editorial improvements. ## Abstract Nit: Abstract should be before status. Nit: “specification for Bundle Protocol” -> “for the Bundle Protocol”. ## Section 1 Title: If this document doesn’t describe the operation, routing, or management of bundles, maybe it doesn’t describe a complete protocol. Consider retitling to “Bundle Protocol Version 7: Format and Architecture” [[Alexey]]: This relates to my DISCUSS points, but my DISCUSS position is stronger than this statement. ## Section 4.1.3 Nit: It would be clearer to move the reserved and unassigned flags to an IANA considerations section, here and throughout. ## Section 4 Phrasing: “The last item of the array ... SHALL be a CBOR "break" stop code.” This seems like a misuse of the word “item”. I would suggest “The array SHALL be terminated by a CBOR “break” stop code.” Similarly in Section 4.2.1. ## Section 4.1.4 Clarity: The “(Boolean)” specifiers seem redundant. What is a non-boolean flag? Clarity: The two lists here seem redundant. Can they be collapsed? Clarity: The phrasing “...the value of the "Transmit status report if block can't be processed" flag in every canonical block…” suggests that these flags should be named or numbered before attempting to describe them. ## Section 4.1.5.1 These two sentences seem contradictory: * “Any scheme conforming to [URIREG] may be used in a bundle protocol endpoint ID.” * “The first item of the array SHALL be the code number identifying the endpoint's URI scheme [URI], as defined in the registry of URI scheme code numbers” Please rephrase. [[Alexey]]: This is similar to Roman's DISCUSS. ## Section 5.4.2 Consistency: This section relies on the presence of a Previous Node block, but nothing in the forwarding procedure instructs any agent to add a Previous Node block. Correctness: If two nodes both opt to return failed bundles, how are they to avoid a ping-pong loop? [[Alexey]]: I included these in the DISCUSS portion of my ballot. ##Section 5.6 Error handling: What about CBOR parsing failures? [[Alexey]]: I included these in the DISCUSS portion of my ballot. ## Section 5.8 Clarity: The insistence, here and earlier, that a bundle is only fragmented into two packets, and that this can then be performed recursively, seems unhelpful. Bundles can be fragmented into arbitrarily many pieces, and this binary subdivision concept is not actually present in the protocol. I suggest removing it from the text as well. ## Section 6.1 Formatting: This table is excessive for a single value. Clarity: The text specifies the contents twice, which is unhelpful for comprehension. ## Section 10 Formatting: The extra line breaks in the vertical dividers are distracting. Please fill them in or remove the breaks if possible. |
2020-02-20
|
23 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss |
2020-02-10
|
23 | Alexey Melnikov | [Ballot discuss] I am looking forward for this document to be finished and approved as an RFC. Before I can recommend this, I have several … [Ballot discuss] I am looking forward for this document to be finished and approved as an RFC. Before I can recommend this, I have several DISCUSS points and comments that I would like to address: 1) Retry strategies are listed as out-of-scope for this document. This is not sufficient for writing an interoperable implementation, unless there is a separate document that provides such details. Below I describe 1 remaining relevant place in the text and suggest some possible ways of addressing my DISCUSS: Step 5: When all selected convergence layer adapters have informed the bundle protocol agent that they have concluded their data sending procedures with regard to this bundle, processing may depend on the results of those procedures. If completion of the data sending procedures by all selected convergence layer adapters has not resulted in successful forwarding of the bundle (an implementation-specific determination that is beyond the scope of this specification), then the bundle protocol agent MAY choose (in an implementation-specific manner, again beyond the scope of this specification) to initiate another attempt to forward the bundle. Similar to the above: retries affect interoperability and should be documented as description of a convergence layer document. I think you need to add this as a requirement to section 7 ("Services Required of the Convergence Layer"). In that event, processing proceeds from Step 4 of Section 5.4. [Two other cases were addressed in -23] 2) [Addressed in -23] 3) [Addressed in -23] |
2020-02-10
|
23 | Alexey Melnikov | Ballot discuss text updated for Alexey Melnikov |
2020-02-07
|
23 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-02-07
|
23 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2020-02-07
|
23 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-23.txt |
2020-02-07
|
23 | (System) | New version approved |
2020-02-07
|
23 | (System) | Request for posting confirmation emailed to previous authors: Edward Birrane , Kevin Fall , Scott Burleigh , dtn-chairs@ietf.org |
2020-02-07
|
23 | Scott Burleigh | Uploaded new revision |
2020-02-07
|
22 | Alexey Melnikov | [Ballot discuss] I am looking forward for this document to be finished and approved as an RFC. Before I can recommend this, I have several … [Ballot discuss] I am looking forward for this document to be finished and approved as an RFC. Before I can recommend this, I have several DISCUSS points and comments that I would like to address: 1) Routing decisions, discovery of endpoints to contact for forwarding and retry strategies are listed as out-of-scope for this document. This is not sufficient for writing an interoperable implementation, unless there is a separate document that provides such details. Below I describe 3 relevant places in the text and suggest some possible ways of addressing my DISCUSS: 5.4. Bundle Forwarding Step 2: The bundle protocol agent MUST determine whether or not forwarding is contraindicated (that is, rendered inadvisable) for any of the reasons listed in Figure 4. In particular: . The bundle protocol agent MAY choose either to forward the bundle directly to its destination node(s) (if possible) or to forward the bundle to some other node(s) for further forwarding. The manner in which this decision is made may depend on the scheme name in the destination endpoint ID and/or Lack of this information (how node to forward to are discovered) would prevent interoperability. (By comparison, SMTP specification which has somewhat similar design contains information about how next nodes to forward to are selected.) I think you need to create a new section in this document specifying requirements on URI scheme documents and include this as a MUST level requirement there. (If you already have a document that does this, you can just normatively point to it.) on other state but in any case is beyond the scope of this document. If the BPA elects to forward the bundle to some other node(s) for further forwarding but finds it impossible to select any node(s) to forward the bundle to, then forwarding is contraindicated. . Provided the bundle protocol agent succeeded in selecting the node(s) to forward the bundle to, the bundle protocol agent MUST subsequently select the convergence layer adapter(s) whose services will enable the node to send the bundle to those nodes. The manner in which specific appropriate convergence layer adapters are selected is beyond the scope of this document. Similar to the above: lack of description of how convergence layers are discovered (for example this might include discovery using DNS or something else) or, alternatively, a mandatory to implement convergence layer would affect interoperability. I think you need to add this as a requirement to section 7 ("Services Required of the Convergence Layer"). Also having some (even non normative) information about which convergence layer to select if multiple are available would be useful. If the agent finds it impossible to select any appropriate convergence layer adapter(s) to use in forwarding this bundle, then forwarding is contraindicated. Step 5: When all selected convergence layer adapters have informed the bundle protocol agent that they have concluded their data sending procedures with regard to this bundle, processing may depend on the results of those procedures. If completion of the data sending procedures by all selected convergence layer adapters has not resulted in successful forwarding of the bundle (an implementation-specific determination that is beyond the scope of this specification), then the bundle protocol agent MAY choose (in an implementation-specific manner, again beyond the scope of this specification) to initiate another attempt to forward the bundle. Similar to the above: retries affect interoperability and should be documented as description of a convergence layer document. I think you need to add this as a requirement to section 7 ("Services Required of the Convergence Layer"). In that event, processing proceeds from Step 4 of Section 5.4. 2) As pointed out by Benjamin Schwartz: In Section 5.4.2 Consistency: This section relies on the presence of a Previous Node block, but nothing in the forwarding procedure instructs any agent to add a Previous Node block. Correctness: If two nodes both opt to return failed bundles, how are they to avoid a ping-pong loop? 3) As pointed out by Benjamin Schwartz: In Section 5.6 Error handling: What about CBOR parsing failures? |
2020-02-07
|
22 | Alexey Melnikov | [Ballot comment] ********************************************************************** * Note, that I am conducting an experiment when people aspiring to be* * Area Directors get exposed to AD work ("AD … [Ballot comment] ********************************************************************** * Note, that I am conducting an experiment when people aspiring to be* * Area Directors get exposed to AD work ("AD shadowing experiment"). * * As a part of this experiment they get to review documents on IESG * * telechats according to IESG Discuss criteria document and their * * comments get relayed pretty much verbatim to relevant editors/WGs. * * As an AD I retain responsibility in defending their position when * * I agree with it. * * Recipients of these reviews are encouraged to reply to me directly * * about perceived successes or failures of this experiment. * ********************************************************************** I also have some comments on Benjamin's comments below marked with "[[Alexey]]:" The following comments were provided by Benjamin Schwartz : Benjamin would have balloted *DISCUSS* on this document. He wrote: This draft’s content seems sound but the text is difficult to understand and needs some editorial improvements. ## Abstract Nit: Abstract should be before status. Nit: “specification for Bundle Protocol” -> “for the Bundle Protocol”. ## Section 1 Title: If this document doesn’t describe the operation, routing, or management of bundles, maybe it doesn’t describe a complete protocol. Consider retitling to “Bundle Protocol Version 7: Format and Architecture” [[Alexey]]: This relates to my DISCUSS points, but my DISCUSS position is stronger than this statement. ## Section 4.1.3 Nit: It would be clearer to move the reserved and unassigned flags to an IANA considerations section, here and throughout. ## Section 4 Phrasing: “The last item of the array ... SHALL be a CBOR "break" stop code.” This seems like a misuse of the word “item”. I would suggest “The array SHALL be terminated by a CBOR “break” stop code.” Similarly in Section 4.2.1. ## Section 4.1.4 Clarity: The “(Boolean)” specifiers seem redundant. What is a non-boolean flag? Clarity: The two lists here seem redundant. Can they be collapsed? Clarity: The phrasing “...the value of the "Transmit status report if block can't be processed" flag in every canonical block…” suggests that these flags should be named or numbered before attempting to describe them. ## Section 4.1.5.1 These two sentences seem contradictory: * “Any scheme conforming to [URIREG] may be used in a bundle protocol endpoint ID.” * “The first item of the array SHALL be the code number identifying the endpoint's URI scheme [URI], as defined in the registry of URI scheme code numbers” Please rephrase. [[Alexey]]: This is similar to Roman's DISCUSS. ## Section 5.4.2 Consistency: This section relies on the presence of a Previous Node block, but nothing in the forwarding procedure instructs any agent to add a Previous Node block. Correctness: If two nodes both opt to return failed bundles, how are they to avoid a ping-pong loop? [[Alexey]]: I included these in the DISCUSS portion of my ballot. ##Section 5.6 Error handling: What about CBOR parsing failures? [[Alexey]]: I included these in the DISCUSS portion of my ballot. ## Section 5.8 Clarity: The insistence, here and earlier, that a bundle is only fragmented into two packets, and that this can then be performed recursively, seems unhelpful. Bundles can be fragmented into arbitrarily many pieces, and this binary subdivision concept is not actually present in the protocol. I suggest removing it from the text as well. ## Section 6.1 Formatting: This table is excessive for a single value. Clarity: The text specifies the contents twice, which is unhelpful for comprehension. ## Section 10 Formatting: The extra line breaks in the vertical dividers are distracting. Please fill them in or remove the breaks if possible. |
2020-02-07
|
22 | Alexey Melnikov | Ballot comment and discuss text updated for Alexey Melnikov |
2020-02-06
|
22 | Magnus Westerlund | [Ballot discuss] Holding discuss to ensure IANA is satisfied. |
2020-02-06
|
22 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to Discuss from Yes |
2020-02-06
|
22 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2020-02-06
|
22 | Michelle Cotton | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
2020-02-06
|
22 | Alissa Cooper | [Ballot comment] I support Benjamin's first DISCUSS point. The registration templates in 10.7 and 10.8 should include iesg@ietf.org as the contact information for the change … [Ballot comment] I support Benjamin's first DISCUSS point. The registration templates in 10.7 and 10.8 should include iesg@ietf.org as the contact information for the change controller. |
2020-02-06
|
22 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2020-02-06
|
22 | Alexey Melnikov | [Ballot discuss] Preliminary DISCUSS, I am likely to Defer the document, as I have more detailed comments. Routing decisions, discovery of endpoints to contact for … [Ballot discuss] Preliminary DISCUSS, I am likely to Defer the document, as I have more detailed comments. Routing decisions, discovery of endpoints to contact for forwarding and retry strategies are listed as out-of-scope for this document. This is not sufficient for writing an interoperable implementation, unless there is a separate document that provides such details. |
2020-02-06
|
22 | Alexey Melnikov | [Ballot Position Update] New position, Discuss, has been recorded for Alexey Melnikov |
2020-02-06
|
22 | Alvaro Retana | [Ballot discuss] §10.3/§10.4: The registration policy for this namespace is changed to "Standards Action". Given the limited number of bits available, the allocation … [Ballot discuss] §10.3/§10.4: The registration policy for this namespace is changed to "Standards Action". Given the limited number of bits available, the allocation should only be granted for a standards-track RFC approved by the IESG. The original BP work (rfc5050) is a product of the IRTF. The new registration policy blocks the ability for anyone outside the IETF to register new values. I understand the need to conserve resources, and the intent to Obsolete rfc5050 in a separate document, which should mean that future work on the BP is done in the IETF. That process hasn't been done yet. I am balloting DISCUSS on this point of the process so that the needed steps can catch up and the group of documents can progress together. [Note that changing the registration policy to allow work from outside the IETF to use the registries would also lead me to clear this DISCUSS. However, I don't think that is necessary.] |
2020-02-06
|
22 | Alvaro Retana | [Ballot comment] I support Ben's DISCUSS. |
2020-02-06
|
22 | Alvaro Retana | [Ballot Position Update] New position, Discuss, has been recorded for Alvaro Retana |
2020-02-05
|
22 | Barry Leiba | [Ballot comment] I support the Sec ADs’ DISCUSS and comment points. I have only a small thing to add to what’s already been said: — … [Ballot comment] I support the Sec ADs’ DISCUSS and comment points. I have only a small thing to add to what’s already been said: — Section 1 — You mention RFC5050 several times here, but it isn’t actually cited as a reference until Section 10.1. You would normally put it in as a citation the first time, at the beginning of Section 1, and I think you should. |
2020-02-05
|
22 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2020-02-05
|
22 | Benjamin Kaduk | [Ballot discuss] I support Roman's Discuss. (1) It's not clear to me that we should be defining new (near-)application-layer protocols on the standards track without … [Ballot discuss] I support Roman's Discuss. (1) It's not clear to me that we should be defining new (near-)application-layer protocols on the standards track without mandatory security mechanisms. Even draft-ietf-dtn-bpsec defines a "BPSec threat model" that is largly the same as the RFC 3552 threat model, in which the network is completely untrusted and to provide end-to-end communications we must supply additional security mechanisms, yet BPSec is not required to implement or use. I could perhaps see room for allowing waypoint nodes that do not act as endpoints to remain security-unaware, but the justification for security-unaware endpoints seems quite lacking. (2) The state machine for transitions between singleton EID and non-singleton EID seems highly unclear to be usable in a globally synchronized manner (I refer specifically to the text in Section 4.1.5.2: "A node's membership in a given singleton endpoint MUST be sustained at least until the nominal operation of the Bundle Protocol no longer depends on the identification of that node using that endpoint's ID"). Distinction between singleton-EID and non-singleton EID may need to be made an explicit protocol element. (3) The forwarding procedure in Section 5.4 refers to a "data label extension block (to be defined in a future document)" with no reference; it doesn't really seem like this sort of speculative forward-looking statement is appropriate in a Proposed Standard. (4) We discuss using a Previous Node block to "return a bundle to sender" when forwarding failed, but do not discuss whether Previous Node should be added (or updated or removed) on transmission, receipt, or both. (5) The extensibility story seems incompletely described: what should an implementation do upon receiving a bundle with an unrecognized control flag bit set, or a block with an unrecognized control flag set? (6) The use of absolute times for creation timestamps suggests a strong dependence on accurate time (for nodes that do not acknowledge their lack of an accurate clock); the consequences of the failure of accurate time should be discussed in the security considerations section. (7) Section 4.1.6 should make a statement regarding whether leap seconds are included or excluded from the count of seconds since the DTN epoch. (8) The definition of Fragment offset needs to specify whether the lowest allowed byte index is zero or 1 (I believe zero, from other discussion). (9) Bundle status reports are only defined to include the creation timestamp of the bundle whose status is being reported on, but not the sequence number thereof. Since we allow nodes without accurate clocks to use a creation timestamp of zero and rely solely on the sequence number to identify bundles, it seems that the status reports for such bundles are effectively useless without the sequence number information. (10) Please resolve the internal inconsistency in Section 10.6 that simultaneously claims that potential bundle protocol URI scheme types are integers of undefined length and only have 255 available codepoints (i.e., definite length). |
2020-02-05
|
22 | Benjamin Kaduk | [Ballot comment] It's pretty unfortunate that we have to have separate (built-in) CRC and (dedicated block type) BIB support; a more unified scheme that always … [Ballot comment] It's pretty unfortunate that we have to have separate (built-in) CRC and (dedicated block type) BIB support; a more unified scheme that always provides cryptographic integrity protection would have simpler encoding rules. I rather wonder why it's not possible to roll the CRC as a mechanism for detecting media-induced errors into the CLA functionality as opposed to needing to be in the top-level BPA. Then media not susceptible to errors could use no or a small CRC and more malleable media could use stronger CRCs, leaving the decision closer to the knowledge of the transport properties. Is a registration something that conceptually lives "in the network", or a purely local matter to the node in question? What about active vs. passive state thereof? The creation timestamp, sequence number, and lifetime can serve to some extent to detect replay of old data, though given the environments we expect this to operate in, it may be hard to differentiate a replay from normal delivery. I don't see any mechanisms that would allow for detection of dropped bundles (whether due to attack or other error), though it's not entirely clear that such a mechanism is possible in these environments. It may also be worth considering whether there is use for the ability detect a truncated application-layer "stream" that's a group of bundles related to each other in some way. I do see that the protocol is largely focused on bundles as discrete units, and so expect the answer to be "no", but this is one of the more standard security mechanisms, so I wanted to explicitly check. Similarly, one might imagine a block type that indicates the initial block types present in a bundle, which could be (required to be) subject to integrity protection so that removal of blocks could be detected at the recipient. Some further discussion of these points, in terms of the goals for these environments and what behaviors are actually attained, might be appropriate in the security considerations section. Section 3.1 Application Data Unit (ADU) - An application data unit is the unit of data whose conveyance to the bundle's destination is the purpose for the transmission of some bundle that is not a fragment (as defined below). I understand the desire for precision, but this definition feels very convoluted and could perhaps be made more accessible to an application author. Bundle node - A bundle node (or, in the context of this document, simply a "node") is any entity that can send and/or receive bundles. Each bundle node has three conceptual components, defined below, as shown in Figure 2: a "bundle protocol agent", a set of zero or more "convergence layer adapters", and an "application agent". If a node always has an application agent, won't anything done by that application agent make the node also part of an endpoint? Yet we discuss waypoint nodes that are not endpoints... Delivery - A bundle is considered to have been delivered at a node subject to a registration as soon as the application data unit that is the payload of the bundle, together with any relevant metadata (an implementation matter), has been presented to the node's application agent in a manner consistent with the state of that registration. Is this metadata considered attached to the ADU or the bundle or something else? Delivery failure action - The delivery failure action of a registration is the action that is to be taken when a bundle that is "deliverable" subject to that registration is received at a time when the registration is in the Passive state. Just to check my understanding: with registrations being per-(node,endpoint), in a case where many nodes are in an endpoint, we'll undertake a delivery failure action for each node with a passive registration even if the bundle is successfully delivered to a different node with an active registration? How does this interact with the "report-to" EID? Section 3.2 Every CLA implements its own thin layer of protocol, interposed between BP and the (usually "top") protocol(s) of the underlying native protocol stack; this "CL protocol" may only serve to multiplex and de-multiplex bundles to and from the underlying native protocol, or it may offer additional CL-specific functionality. The manner in which a CLA sends and receives bundles, as well as the definitions of CLAs and CL protocols, are beyond the scope of this specification. We still need to specify what interfaces a CLA needs to present to the BPA, though! Section 7 is a start at this (and probably worth cross-referencing from here), though it feels pretty sparse. In the case of a node that serves simply as a BP "router", the AA may have no application-specific element at all. The application- (But earlier we said that a node has all three elements, including an application agent. What would the Administrative Element do on such a "router" node?) The destination of every bundle is an endpoint, which may or may not be singleton. The source of every bundle is a node, identified by the endpoint ID for some singleton endpoint that contains that node. It might be worty a forward-reference to Section 4.1.5.2 where we record the requirement for a valid endpoint ID of a given node. The bundle protocol is designed for extensibility. Bundle protocol extensions, documented elsewhere, may extend this specification by: [...] . defining additional mandates and constraints on processing that conformant bundle protocol agents must perform at specified points in the inbound and outbound bundle processing cycles. It's not clear to me how "additional mandates and constraints" can successfully be imposed by protocol extensions given that the source node cannot in general know the path(s) the bundle will take. Section 4.1.2 When not omitted, the CRC SHALL be represented as a CBOR byte string of two bytes (that is, CBOR additional information 2, if CRC type is 1) or of four bytes (that is, CBOR additional information 4, if CRC type is 2); in each case the sequence of bytes SHALL constitute an unsigned integer value (of 16 or 32 bits, respectively) in network byte order. This seems to preclude the possibility of any future CRC types being defined (without an update to this specification). Section 4.1.3 If the bundle's source node is omitted (i.e., the source node ID is the ID of the null endpoint, which has no members as discussed below; this option enables anonymous bundle transmission), then the bundle is not uniquely identifiable and all bundle protocol features that rely on bundle identity must therefore be disabled: the "Bundle must not be fragmented" flag value must be 1 and all status report request flag values must be zero. It's also impossible for the user application to acknowledge such an anonymous bundle, right, so that flag would also be zero? Or do such reports go to the "Report-to EID"? . Bits 21-63 are unassigned. Does this imply a mandatory encoding (width) of the CBOR unsigned integer representing the flags (and a hard limit on the number of possible flags)? Section 4.1.4 . This block must be replicated in every fragment. (Boolean) . Transmission of a status report is requested if this block can't be processed. (Boolean) . Block must be removed from the bundle if it can't be processed. (Boolean) . Bundle must be deleted if this block can't be processed. (Boolean) nit: perhaps we could reorder this list to match the order in which the bit flags are allocated? Section 4.1.5.1 Each BP endpoint ID (EID) SHALL be represented as a CBOR array comprising a 2-tuple. nit: Is there a reason to not just say "a CBOR array of two elements"? The first item of the array SHALL be the code number identifying the endpoint's URI scheme [URI], as defined in the registry of URI scheme code numbers for Bundle Protocol maintained by IANA as described in Section 10. [URIREG]. Each URI scheme code number I'm not sure why [URIREG] is the reference here; it has nothing to do with the "code numbers for Bundle Protocol". . If the EID's URI scheme is "ipn" then the SSP SHALL be represented as a CBOR array comprising a 2-tuple. The first [same comment about "two elements"] item of this array SHALL be the EID's node number represented as a CBOR unsigned integer. The second item of this array SHALL be the EID's service number represented as a CBOR unsigned integer. Where are node and service numbers defined? . Definitions of the CBOR representations of the SSPs of EIDs encoded in other URI schemes are included in the specifications defining those schemes. This feels kind of weird; the vast majority of URI schemes are not going to define CBOR encoding rules for their SSPs, but above we claim that bundle protocol is usable with any registered URI scheme. Absent some mechanism for a separate document from the scheme definition to specify the CBOR encoding rules for the SSP, these claims are incompatible. Section 4.1.5.2 . The EID of any singleton endpoint of which a node is a member MAY be used to identify that node. A "node ID" is an EID that is used in this way. . A node's membership in a given singleton endpoint MUST be sustained at least until the nominal operation of the Bundle Protocol no longer depends on the identification of that node using that endpoint's ID. Per the Discuss point, this feels like it's unworkable in practice; if we had a way to reliably distribute knowledge of which EIDs are usable as node IDs and/or are in use as node IDs, we could also use that mechanism to distribute lots of other useful things, like key material, revocation information, etc. Since we claim to not be able to do those things, it's a little boggling to see a claim that we can do this for node IDs. It kind of seems like we may have to make a fundamental distinction between "singleton EIDs" and "EIDs that may have multiple member nodes" in order to get these properties to be workable globally. Section 4.1.7 The second item of the array SHALL be the creation timestamp's sequence number, represented as a CBOR unsigned integer. We haven't introduced the term "sequence number" yet. Section 4.1.8 Block-type-specific data in each block (other than the primary block) SHALL be the applicable CBOR representation of the content of nit: as a stylistic matter, this qualification seems too important to relegate to a parenthetical. Section 4.2.1 We probably want to check for consistency between what's here and what's covered in the section-4 intro -- both use normative keywords, and Section 4 talks about the penultimate array item being the payload block, which we don't mention here. Section 4.2.2 The primary block of each bundle SHALL be immutable. The values of all fields in the primary block must remain unchanged from the time the block is created to the time it is delivered. Is there a technical mechanism that can enforce this? Lifetime: The lifetime field is an unsigned integer that indicates the time at which the bundle's payload will no longer be useful, encoded as a number of microseconds past the creation time. (For high-rate deployments with very brief disruptions, fine-grained expression of bundle lifetime may be useful.) When a bundle's age Does this mean that we assume that the creation time has microsecond accuracy as a reference even though it is only encoded with seconds-level precision? the CRC type. The CRC SHALL be computed over the concatenation of all bytes (including CBOR "break" characters) of the primary block including the CRC field itself, which for this purpose SHALL be temporarily populated with the value zero. nit: the CRC is a CBOR byte string; "the value zero" assumes an implied encoding of that byte string. Perhaps "all bytes zero" is better. Section 4.2.3 Every block other than the primary block (all such blocks are termed "canonical" blocks) SHALL be represented as a CBOR array; the number of elements in the array SHALL be 5 (if CRC type is zero) or 6 (otherwise). Is this an invariant that future-defined block types must also adhere to? computed over the concatenation of all bytes of the block (including CBOR "break" characters) including the CRC field itself, which for this purpose SHALL be temporarily populated with the value zero. [same comment as above re. "all bytes zero"] Section 4.3.2 The Bundle Age block, block type 7, contains the number of microseconds that have elapsed between the time the bundle was created and time at which it was most recently forwarded. It is (Are we again assuming the creation time to have microsecond accuracy even though the precision of representation is in seconds?) The block-type-specific data of this block is an unsigned integer containing the age of the bundle in microseconds, which SHALL be represented as a CBOR unsigned integer item. (The age of the bundle is the sum of all known intervals of the bundle's residence at forwarding nodes, up to the time at which the bundle was most recently forwarded, plus the summation of signal propagation time over all episodes of transmission between forwarding nodes. Determination of these values is an implementation matter.) If the I get that determination of these times will depend on the CLA(s) in use, but it sounds like we are making a hard requirement that an accurate value with microseconds precision is available? That seems like a pretty stringent requirement to place on the underlying transport technologies. bundle's creation time is zero, then the bundle MUST contain exactly one (1) occurrence of this type of block; otherwise, the bundle MAY contain at most one (1) occurrence of this type of block. A bundle MUST NOT contain multiple occurrences of the bundle age block, as this could result in processing anomalies. I'm a bit confused at the formal state of this extension block type. Up in Section 4.3 we said that not all nodes will implement processing or production of extension blocks, but this text is in the core spec and says that this extension block MUST be present under some conditions. Is this implicitly predicated on the implementation in question supporting Bundle Age, or is it a hard requirement? Section 4.3.3 Where do we discuss the consequences of nodes failing to implement the Hop Count extension block (as is apparently allowed by Section 4.3)? unsigned integer. A bundle MAY contain at most one (1) occurrence of this type of block. nit: I think this is "MAY contain this type of block" but "MUST contain at most 1 occurrence". Section 5.1 Note that requesting status reports for any single bundle might easily result in the generation of (1 + (2 *(N-1))) status report [(1 + (2 *(N-1))) might be more concisely expressed as ((2*N) -1).] . A "bundle reception status report" is a bundle status report with the "reporting node received bundle" flag set to 1. . A "bundle forwarding status report" is a bundle status report with the "reporting node forwarded the bundle" flag set to 1. . A "bundle delivery status report" is a bundle status report with the "reporting node delivered the bundle" flag set to 1. . A "bundle deletion status report" is a bundle status report with the "reporting node deleted the bundle" flag set to 1. These strings (the flag names) appear twice in the document: here and in Section 6.1.1; neither location explicitly says that it *defines* the flag values (though the latter does seem to actually do so, in the prose). Section 5.3 Step 1: If the bundle's destination endpoint is an endpoint of which the node is a member, the bundle delivery procedure defined in Section 5.7 MUST be followed and for the purposes of all subsequent processing of this bundle at this node the node's membership in the bundle's destination endpoint SHALL be disavowed; specifically, even though the node is a member of the bundle's destination endpoint, the node SHALL NOT undertake to forward the bundle to itself in the course of performing the procedure described in Section 5.4. The discussion so far in the document has not prepared me for the notion that a bundle would continue to be forwarded even after it has been delivered. Please put a description somewhere of why this might occur. (Also, nit(?): everything in this paragraph is contingent on the node being a member of the destination endpoint, right?) Section 5.4 Step 2: The bundle protocol agent MUST determine whether or not forwarding is contraindicated (that is, rendered inadvisable) for any of the reasons listed in Figure 4. In particular: I'm a bit confused by this wording, since Figure 4 is in essence a table of status report reason codes, i.e., values that appear on the wire in status report messages. The contents of that table are not, logically, actual *reasons*, but rather the protocol contants. It seems like it would be better to refer to some (possibly prose) description of the actual situations that would induce a "failure to forward" condition (and cause the generation of a report using one of those codes). Furthermore, Figure 4 only contains those codes that are currently defined; future extensions can define additional codes as well. (This is not the only place where Figure 4 is referenced as an alleged list of reasons to not forward.) Step 4: For each node selected for forwarding, the bundle protocol agent MUST invoke the services of the selected convergence layer adapter(s) in order to effect the sending of the bundle to that node. [...] I appreciate the proper use of effect(v) -- thanks! Determining the time at which the bundle protocol agent invokes convergence layer adapter services is a BPA implementation matter. Determining the time at which each convergence layer adapter subsequently responds to this service invocation by sending the bundle is a convergence-layer adapter implementation matter. I appreciate that the actual procedures involved will depend on the CLAs and, to large extent, BPA implementation, but without giving some requirements as to what properties are needed, this protocol is incomplete. I could make a BPA implementation that chooses to never invoke CLA services and that would comply with this text (yet would not be a usable implementation at all). . If the bundle contains a data label extension block (to be defined in a future document) then that data label value MAY identify procedures for determining the order in which This doesn't feel like it needs to be a normative "MAY" vs. descriptive "may". . If the bundle has a bundle age block, as defined in 4.3.2. above, then at the last possible moment before the CLA initiates conveyance of the bundle via the CL protocol the bundle age value MUST be increased by the difference between the current time and the time at which the bundle was received (or, if the local node is the source of the bundle, created). This does not seem to account for the transmission time from the previous node to this one, which was a required component in the definition of the bundle age. In that event, processing proceeds from Step 4 of Section 5.4. [This is Section 5.4, so this is self-referential.] If completion of the data sending procedures by all selected convergence layer adapters HAS resulted in successful forwarding of ["HAS" is not a BCP 14 keyword.] the bundle, or if it has not but the bundle protocol agent does not choose to initiate another attempt to forward the bundle, then: [...] endpoint ID. The reason code on this bundle forwarding status report MUST be "no additional information". It's kind of weird to use "no additional information" for both the "success" case and the "I just decided not to" case. Section 5.4.1 Otherwise, when -- at some future time - the forwarding of this nit: two hyphens for the second em dash. Section 5.6 Why is "Block unintelligible" used for both CRC failures and "extension not implemented"? Section 5.8 I suggest to replace "fragmented bundle" with "bundle being fragmented", for clarity. . Beyond these rules, replication of extension blocks in the fragments is an implementation matter. It seems prudent to give some indication of how the BPsec blocks are managed across fragmentation. Section 5.9 If the concatenation -- as informed by fragment offsets and payload lengths -- of the payloads of all previously received fragments with nit: talking about this as "concatenation of all fragment payloads" is a bit risky, since we admit the possibility of overlapping fragments; would it be better to talk about "recovering the full application-data-unit-length byte array by inserting fragment contents at the indicated offsets"? . This byte array -- the reassembled application data unit -- MUST replace the payload of this fragment. . The "Reassembly pending" retention constraint MUST be removed from every other fragment whose payload is a subset of the reassembled application data unit. Why is the last-received fragment special that it's payload is replaced by the entire payload? Wouldn't it make more sense to promote the fragment with offset zero, since that is guaranteed to have the right extension blocks? Section 6.1.1 There's a lot of nested arrays here; some examples would really help clarify the structure. Each item of the bundle status information array SHALL be a bundle status item represented as a CBOR array; the number of elements in each such array SHALL be either 2 (if the value of the first item of this bundle status item is 1 AND the "Report status time" flag was ["AND" is not a BCP 14 keyword] It's somewhat surprising to have several of the reason codes in the figure that appear with no accompanying prose discussion of when they might be used. With the presence of a "traffic pared" report code, one wonders if it might be worth defining a mechanism to consolidate multiple status reports, so that one might report (e.g.) paring several bundles in a single status report. Section 6.2 Step 1: The administrative record must be constructed. If the administrative record references a bundle and the referenced bundle is a fragment, the administrative record MUST contain the fragment offset and fragment length. To be clear: this is normative guidance that applies to all administrative record types that may be defined in the future? Section 7.2 . sending a bundle to a bundle node that is reachable via the convergence layer protocol; . notifying the bundle protocol agent when it has concluded its data sending procedures with regard to a bundle; . delivering to the bundle protocol agent a bundle that was sent by a bundle node via the convergence layer protocol. The convergence layer service interface specified here is neither exhaustive nor exclusive. That is, supplementary DTN protocol specifications (including, but not restricted to, the Bundle Security Protocol [BPSEC]) may expect convergence layer adapters that serve BP implementations conforming to those protocols to provide additional services such as reporting on the transmission and/or reception progress of individual bundles (at completion and/or incrementally), retransmitting data that were lost in How is "reporting on the transmission and/or reception progress of individual bundles" different from the bullet points above? Section 8 . the Bundle Protocol (BP, RFC 5050), . the Bundle Protocol version 7 specification draft (version 6), Is this still accurate? We're on version 21 of the draft, now, not version 6, and it rather defies belief that there have been no protocol-relevant changes since version -06. (I understand this will get removed before publication as an RFC, but it would be somewhat telling if the implementation efforts had stalled.) Section 9 Should we discuss the risk that the presence of "reassembly pending" retention constraints pose of a DoS on node storage, or do we think that's adequately covered already? Additionally, convergence-layer protocols that ensure authenticity of communication between adjacent nodes in BP network topology SHOULD be used where available, to minimize the ability of "Authenticity of communication" requires some sense of identity and credentials associated thereto; with the current formulation of node identities as EID URIs, I'm not sure what sort of credentials would be used for this purpose. Can you give some examples? different blocks. One possible variation is to sign and/or encrypt blocks using symmetric keys securely formed by Diffie-Hellman procedures (such as EKDH) using the public and private keys of the sending and receiving nodes. For this purpose, the key distribution problem reduces to the problem of trustworthy delay-tolerant distribution of public keys, a current research topic. It's important to inject some fresh entropy when using static-static DH for key generation, as otherwise the problems from cryptographic key reuse become basically unbearable. Section 10.1 Technically we're codepoint squatting for the new allocations here (unless we say that these are "suggested values"), in a specification-required registry. I assume the experts (as authors/shepherd) are aware of this work and would not allocate the requested codepoints to another document, though, so I am not making this a Discuss point. | 6 | 4 | Payload Confidentiality Blk | [RFC6257] | We already have rows that spill over to another line; spelling out "Block" as is done in the current registry contents seems best. Section 10.3 Why is RFC-to-be listed as a reference for bits 7-13 when the applicable version is only 6 (not 7)? Section 10.5 [same note about codepoint-squatting] | 6,7 | 5 | Destination endpoint ID |[RFC5050],| | | | unintelligible |RFC-to-be | The current wording is "Destination endpoint ID unavailable", so this is requesting a content change. | 6,7 | 8 | Block unintelligible |[RFC6255],| | | | |RFC-to-be | The registry currently shows RFC 5050 as a reference, not RFC 6255. | 6 | 255 | Reserved |[RFC6255] | Not also RFc-to-be? Section 10.6 The Bundle Protocol has a URI scheme type field - an unsigned integer of undefined length - for which IANA is requested to create (All CBOR unsigned integers are of "indefinite" (variable) length. Also note that RFC 7049 prefers to use "indefinite length" over "undefined length", but also that 7049 does not use "indefinite length" for integers.) | 1 | dtn | RFC-to-be | | 2 | ipn | [RFC6260] | Why is "ipn" left with RFC6260 as the reference even though we are updating its registration in this document just as we are for "dtn"? Section 10.7 (and with minimal changes, 10.8) dtn-hier-part = "//" node-name name-delim demux ; a path-rootless Is there supposed to be more (or less) to that comment? receives the bundle. In both cases (and indeed in all bundle processing), the node that receives a bundle should verify its authenticity and validity before operating on it in any way. How is this possible in the absence of BPSEC? Does this imply a recommendation or requirement to implement BPSEC? Section 11.1 [BPSEC] Birrane, E., "Bundle Security Protocol Specification", Work In Progress, October 2015. I agree with the directorate reviewer that we need to give a more concrete reference here (e.g., draft-ietf-dtn-bpsec) Section 11.2 The way in which we reference [UTC] is arguably normative. Appendix B start = bundle / #6.55799(bundle) This is the tag for "self-describe [sic] CBOR" per RFC 7049; did Carsten make any indication that a more specific tag could/should be allocated for BP? ; The root bundle array bundle = [primary-block, *extension-block, payload-block] I see that CDDL does not have provisions for noting indefinite- vs. definite-length encoding, so a comment here might be in order. bundleflagbits = &( reserved: 21, [...] RFC 8610 seems to suggest that omitting reserved bits may be appropriate (to disallow them from being set within this CDDL model). (Similarly for the blockflagbits.) |
2020-02-05
|
22 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2020-02-05
|
22 | Roman Danyliw | [Ballot discuss] ** Section 4.1.5.1. Can the permissible schemes for the Endpoint ID URL be clarified. Initially the text says: The scheme identified by the … [Ballot discuss] ** Section 4.1.5.1. Can the permissible schemes for the Endpoint ID URL be clarified. Initially the text says: The scheme identified by the < scheme name > in an endpoint ID is a set of syntactic and semantic rules that fully explain how to parse and interpret the SSP. The set of allowable schemes is effectively unlimited. Any scheme conforming to [URIREG] may be used in a bundle protocol endpoint ID. [URIREG] would suggest that any schema in IANA "Uniform Resource Identifier (URI) Schemes" Registry’ is valid. However, later, the text says: The first item of the array SHALL be the code number identifying the endpoint's URI scheme [URI], as defined in the registry of URI scheme code numbers for Bundle Protocol maintained by IANA as described in Section 10. [URIREG]. This text suggests that the new Bundle Protocol URI Scheme Type registry should govern the EID schemes. However, then the text again cites URIREG. Perhaps the intent is that URI's valid per [URIREG] would be registered in the new bundle protocol registry and values in this new registry would be used. |
2020-02-05
|
22 | Roman Danyliw | [Ballot comment] ** Figure 1. Does the second from the left column running “T1/T2” and “N1/N2” mean that this node has a dual stack of … [Ballot comment] ** Figure 1. Does the second from the left column running “T1/T2” and “N1/N2” mean that this node has a dual stack of N1+T1 and N2+T2? ** Section 3.1. Can a node be part of multiple bundle endpoints? I would assume yes, but don't see that said anywhere? ** Section 3.1. Per the definition of Bundle endpoint, there is a reference to Section 4.4.1 but that section doesn’t exist. Did you mean Section 4.1.5? ** Section 3.1. Per the definition of Registration, and registrations having two states (active and passive), could you please clarify why one would choose to be in either state. ** Section 3.3. Per this list of BPA services, please add clarifying language to the effect that the details of this registration functionality is out of scope. ** Section 4. (Note that, while CBOR permits considerable flexibility in the encoding of bundles, this flexibility must not be interpreted as inviting increased complexity in protocol data unit structure.) What is practical guidance should an implementer take from this text? ** Section 4.1.5.2 Per “A node's membership in a given singleton endpoint MUST be sustained at least until the nominal operation of the Bundle Protocol no longer depends on the identification of that node using that endpoint's ID.” -- what does it mean to “sustain” the membership? -- how would a node know that the "nominal operation of the BP no longer depends" of this address binding? ** Section 4.2.2. Per “Note that, in general, the creation of two distinct bundles with the same source node ID and bundle creation timestamp may result in unexpected network behavior and/or suboptimal performance”, where is that behavior described? ** Section 5.1. Per “When the generation of status reports is enabled, the decision on whether or not to generate a requested status report is left to the discretion of the bundle protocol agent.”, can way points also choose not for forward these reports based on configuration? ** Section 6.1.1. Valid status report reason codes are defined in Figure 4 below but the list of status report reason codes provided here is neither exhaustive nor exclusive; supplementary DTN protocol specifications (including, but not restricted to, the Bundle Security Protocol [BPSEC]) may define additional reason codes. Shouldn’t the text point to the associated IANA sub-registry (“Bundle Status Report Reason Codes” sub-registry) as the canonical place to understand semantics of future values? ** Section 9. Recommend being clearer on the scope of the protections. OLD: Because the security mechanisms are extension blocks that are themselves inserted into the bundle, the integrity and confidentiality of bundle blocks are protected while the bundle is at rest, awaiting transmission at the next forwarding opportunity, as well as in transit. NEW: Because the security mechanisms are extension blocks that are themselves inserted into the bundle, the protections they afford apply when while the bundle is at rest, awaiting transmission at the next forwarding opportunity, as well as in transit. ** Section 9. How is an implementor supposed to use the guidance in “Note that, while the primary block must remain in the clear for routing purposes, the Bundle protocol could be protected against traffic analysis to some extent by using bundle-in-bundle encapsulation … [which] is a current research topic”? There is no actionable guidance or pointers to more information. ** Section 9. . How is an implementor supposed to use the guidance in paragraph starting with “The bpsec extensions accommodate an open-ended range ...”. If there is a concrete proposal for “to sign and/or encrypt blocks using symmetric keys securely formed by Diffie-Hellman procedures”, BpSec suggest a spec needs to be written to register a security context to realize this approach. Recommend removal. Editorial Nit -- Figure 2. “CL1”, “CL2 …” is “Convergence Layer 1”, “2”? “CL” is not defined anywhere -- Section 5.4. s/adapter(s) in order to effect/adapter(s) in order to affect/ |
2020-02-05
|
22 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2020-02-05
|
22 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2020-02-05
|
22 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2020-02-05
|
22 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-22.txt |
2020-02-05
|
22 | (System) | New version approved |
2020-02-05
|
22 | (System) | Request for posting confirmation emailed to previous authors: Edward Birrane , Kevin Fall , Scott Burleigh , dtn-chairs@ietf.org |
2020-02-05
|
22 | Scott Burleigh | Uploaded new revision |
2020-02-05
|
21 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-02-05
|
21 | Amanda Baber | Expert has asked that issues identified in this review be addressed by submitter or IESG: https://mailarchive.ietf.org/arch/msg/uri-review/rmQ_o9zhT0n3HAuMbhnLIBdp7FU |
2020-02-05
|
21 | Amanda Baber | IANA Experts State changed to Issues identified |
2020-02-05
|
21 | Amanda Baber | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
2020-02-05
|
22 | (System) | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
2020-02-04
|
21 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2020-02-03
|
21 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events' |
2020-02-03
|
21 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. And it is a really interesting topic ! The document is not really easy … [Ballot comment] Thank you for the work put into this document. And it is a really interesting topic ! The document is not really easy to read with some long and convoluted sentence such as "An application data unit is the unit of data whose conveyance to the bundle's destination is the purpose for the transmission of some bundle that is not a fragment (as defined below)." Another one: "The payload for a bundle forwarded in response to reception of a bundle is the payload of the received bundle." The above sentences and others make the reading really difficult. Probably too late to change now... The section 3.2 go a little too deep IMHO in details (do we care whether the BPA is general-purpose computer?) As a side note, I would be interested by the potential use of this bundle protocol to transport the future webpack ;-) Please find below some non-blocking COMMENTs. C1) is there any reason why the reserved bits in section 4.3.1 are not specified with the usual 'transmitted as 0 and ignored by receiver' ? C2) in section 4.1.5, is there a registry or a mechanism to avoid / detect identifier collisions ? C3) just curious, why is it version 7 ? C4) in section 4.3.2, if the bundle age is expressed in microseconds, then I would suggest to define exactly 'most recently forwarded': by which component of the bundle node ? is it measured at the completion of the action (e.g., layer-2 serialization is finished). Section 5.4 adds some more information but not enough to my taste (is it when the forwarding decision is made or when the convergence layer has accepted it). C5) in section 4.3.3., why not following the usual method of hop-limit starting at a non-zero value and being decremented at each forwarding operation ? it is like using DTN time from 2000 rather than the usual timestamp definition. Nothing bad or blocking, but, I wonder why re-inventing the wheel if there is no real reason C6) the possibility of having a single bundle to generate multiple reports along its path to the 'report-to' endpoint ID per section 5.6 could possibly be used for an amplification attacks + resource exhaustion attack on traversed nodes. Should a rate limiting be mentionned ? C7) section 5.9, should the re-assembly process time out ? E.g., taking into account the max bundle age ? C8) section 8, I have hard time to parse the following "the Bundle Protocol version 7 specification draft (version 6)" even if I think I got it right C9) section 8, an interop status (if any) between the three existing implementations would be welcome I hope that this helps to improve the document, Regards, -éric |
2020-02-03
|
21 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2020-02-03
|
21 | Mirja Kühlewind | [Ballot discuss] I looked up RFC 4838 and there is a section on congestion control, however it only says: "Congestion control is an ongoing research … [Ballot discuss] I looked up RFC 4838 and there is a section on congestion control, however it only says: "Congestion control is an ongoing research topic." Unfortunately this document also doesn't give any further advise about congestion control but as a PS it really should. I understand that the bundle protocol is basically an application layer protocol on top of a transport that should care about congestion control, however, the document doesn't talk much about anything related to that underlying protocol. It would be important to specify requirements for the underlying transport protocol, indicating that is must be congestion controlled or rate limited (see RFC8085 as a reference for rate limiting of (uni-direction) UDP-based protocols). Further this sentence in Sec 5.1 needs more clarification: “For this reason, the generation of status reports MUST be disabled by default and enabled only when the risk of excessive network traffic is deemed acceptable.” It is not clear when it makes sense to enable and if enables one should probably also implement some filtering and rate limiting. |
2020-02-03
|
21 | Mirja Kühlewind | [Ballot comment] 1) One general comment on the style of the document: I found it actually quite hard to read. I think it would help … [Ballot comment] 1) One general comment on the style of the document: I found it actually quite hard to read. I think it would help to add some overview text from time to time instead of going into all the details right away. E.g. maybe provide some kind of short summary/overview at the beginning of section 5 like the “Life cycle of a bundle“. In contrast I think you could cut down the section on concepts a bit (move some the implementation related notes to the appendix). Further, compared to the previous RFC, now that CBOR is used the text because actually more abstract. I think it would actually help to put CDDL fragment in body of document. 2) Sec 4.1.3 and 4.1.4: Maybe use normative language here for all or most of the musts, e.g. s/then all status report request flag values must be zero/then all status report request flag values MUST be zero/ 3) Quick question on Sec 4.2.2: “Version number SHALL be represented as a CBOR unsigned integer item.” The document says that this version is not backward compatible. Is the version number the only field that can be used to identify the bundle protocol? |
2020-02-03
|
21 | Mirja Kühlewind | [Ballot Position Update] New position, Discuss, has been recorded for Mirja Kühlewind |
2020-01-31
|
21 | Stewart Bryant | Request for Telechat review by GENART Completed: Ready with Issues. Reviewer: Stewart Bryant. Sent review to list. |
2020-01-30
|
21 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-21.txt |
2020-01-30
|
21 | (System) | New version approved |
2020-01-30
|
21 | (System) | Request for posting confirmation emailed to previous authors: Edward Birrane , Kevin Fall , Scott Burleigh , dtn-chairs@ietf.org |
2020-01-30
|
21 | Scott Burleigh | Uploaded new revision |
2020-01-23
|
20 | Jean Mahoney | Request for Telechat review by GENART is assigned to Stewart Bryant |
2020-01-23
|
20 | Jean Mahoney | Request for Telechat review by GENART is assigned to Stewart Bryant |
2020-01-23
|
20 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-20.txt |
2020-01-23
|
20 | (System) | New version approved |
2020-01-23
|
20 | (System) | Request for posting confirmation emailed to previous authors: Edward Birrane , Kevin Fall , Scott Burleigh , dtn-chairs@ietf.org |
2020-01-23
|
20 | Scott Burleigh | Uploaded new revision |
2020-01-20
|
19 | Magnus Westerlund | IESG state changed to IESG Evaluation from Waiting for Writeup |
2020-01-20
|
19 | Magnus Westerlund | Changed consensus to Yes from Unknown |
2020-01-19
|
19 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Jürgen Schönwälder was marked no-response |
2020-01-17
|
19 | Cindy Morgan | Placed on agenda for telechat - 2020-02-06 |
2020-01-17
|
19 | Magnus Westerlund | Ballot has been issued |
2020-01-17
|
19 | Magnus Westerlund | [Ballot Position Update] New position, Yes, has been recorded for Magnus Westerlund |
2020-01-17
|
19 | Magnus Westerlund | Created "Approve" ballot |
2020-01-17
|
19 | Magnus Westerlund | Ballot writeup was changed |
2020-01-16
|
19 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-19.txt |
2020-01-16
|
19 | (System) | New version approved |
2020-01-16
|
19 | (System) | Request for posting confirmation emailed to previous authors: Edward Birrane , Kevin Fall , Scott Burleigh , dtn-chairs@ietf.org |
2020-01-16
|
19 | Scott Burleigh | Uploaded new revision |
2020-01-15
|
18 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-01-15
|
18 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-18.txt |
2020-01-15
|
18 | (System) | New version approved |
2020-01-15
|
18 | (System) | Request for posting confirmation emailed to previous authors: Edward Birrane , Kevin Fall , Scott Burleigh , dtn-chairs@ietf.org |
2020-01-15
|
18 | Scott Burleigh | Uploaded new revision |
2019-11-12
|
17 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2019-11-12
|
17 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2019-11-12
|
17 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-dtn-bpbis-17. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-dtn-bpbis-17. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Functions Operator understands that, upon approval of this document, there are six actions which we must complete. First, in the Bundle Block Types registry on the Bundle Protocol registry page located at: https://www.iana.org/assignments/bundle/ the existing registry is to be changed. A new column will be added to the registry and marked as "Bundle Protocol Version." In addition, three new values are to be registered (values 6, 7 and 10). Values 11-15 will be marked as reserved as defined by RFC 8126. The revised Bundle Block Types registry will be as follows: +----------+-------+-----------------------------+----------------------------+ | Bundle | Value | Description | Reference | | Protocol | | | | | Version | | | | +----------+-------+-----------------------------+----------------------------+ | none | 0 | Reserved | [RFC6255] | | 6,7 | 1 | Bundle Payload Block | [RFC5050] | | 6 | 2 | Bundle Authentication Block | [RFC6257] | | 6 | 3 | Payload Integrity Block | [RFC6257] | | 6 | 4 | Payload Confidentiality Blk | [RFC6257] | | 6 | 5 | Previous-Hop Insertion Block| [RFC6259] | | 7 | 6 | Previous node (proximate | [ RFC-to-be section 4.3.1] | | | | sender) | | | 7 | 7 | Bundle age (in seconds) | [ RFC-to-be section 4.3.2] | | 6 | 8 | Metadata Extension Block | [RFC6258] | | 6 | 9 | Extension Security Block | [RFC6257] | | 7 | 10 | Hop count (#prior xmit | [ RFC-to-be section 4.3.3] | | | | attempts) | | | 7 | 11-15 | Reserved | [ RFC-to-be section 4.3] | | | 16-191| Unassigned | | | 6 |192-255| Reserved for Private and/or | [RFC5050] | | | | Experimental Use | | +----------+-------+-----------------------------+----------------------------+ IANA Question --> The current reference for the Bundle Block Types Registry is RFC 6255. Should the reference be changed to [ RFC-to-be ]? Second, The Primary Bundle Protocol Version Registry also on the Bundle Protocol registry page located at: https://www.iana.org/assignments/bundle/ will have one, new registration added as follows: Value: 7 Description: Assigned Reference: [ RFC-to-be Section 4.2.2] Third, in the Bundle Processing Control Flags registry on the Bundle Protocol registry page located at: https://www.iana.org/assignments/bundle/ the existing registry is to be changed. A new column will be added to the registry and marked as "Bundle Protocol Version." In addition, one new value is to be registered (values 6). The revised Bundle Processing Control Flags registry will be: +--------------------+----------------------------------+----------------------------+ | Bundle | Bit | Description | Reference | | Protocol| Position | | | | Version | (right | | | | | to left) | | | +--------------------+----------------------------------+----------------------------+ | 6,7 | 0 | Bundle is a fragment | [RFC5050] | | 6,7 | 1 | Application data unit is an | [RFC5050] | | | | administrative record | | | 6,7 | 2 | Bundle must not be fragmented | [RFC5050] | | 6 | 3 | Custody transfer is requested | [RFC5050] | | 6 | 4 | Destination endpoint is singleton| [RFC5050] | | 6,7 | 5 | Acknowledgement by application | [RFC5050] | | | | is requested | | | 7 | 6 | Status time requested in reports | [ RFC-to-be section 4.1.3] | | 6 | 7 | Class of service, priority | [RFC5050] | | 6 | 8 | Class of service, priority | [RFC5050] | | 6 | 9 | Class of service, reserved | [RFC5050] | | 6 | 10 | Class of service, reserved | [RFC5050] | | 6 | 11 | Class of service, reserved | [RFC5050] | | 6 | 12 | Class of service, reserved | [RFC5050] | | 6 | 13 | Class of service, reserved | [RFC5050] | | 6,7 | 14 | Request reporting of bundle | [RFC5050] | | | | reception | | | 6 | 15 | Request reporting of custody | [RFC5050] | | | | acceptance | | | 6,7 | 16 | Request reporting of bundle | [RFC5050] | | | | forwarding | | | 6,7 | 17 | Request reporting of bundle | [RFC5050] | | | | delivery | | | 6,7 | 18 | Request reporting of bundle | [RFC5050] | | | | deletion | | | 6 | 19 | Reserved | [RFC5050] | | 6 | 20 | Reserved | [RFC5050] | | | 21-63 | Unassigned | | +--------------------+----------------------------------+----------------------------+ IANA Question --> The current reference for the Bundle Block Types Registry is RFC 6255. Should the reference be changed to [ RFC-to-be ]? Fourth, in the Block Processing Control Flags registry on the Bundle Protocol registry page located at: https://www.iana.org/assignments/bundle/ the existing registry is to be changed. A new column will be added to the registry and marked as "Bundle Protocol Version." The revised Bundle Processing Control Flags registry will be: +--------------------+----------------------------------+----------+ | Bundle | Bit | Description | Reference| | Protocol| Position | | | | Version | (right | | | | | to left) | | | +--------------------+----------------------------------+----------+ | 6,7 | 0 | Block must be replicated in | [RFC5050]| | | | every fragment | | | 6,7 | 1 | Transmit status report if block | [RFC5050]| | | | can't be processed | | | 6,7 | 2 | Delete bundle if block can't be | [RFC5050]| | | | processed | | | 6 | 3 | Last block | [RFC5050]| | 6,7 | 4 | Discard block if it can't be | [RFC5050]| | | | processed | | | 6 | 5 | Block was forwarded without | [RFC5050]| | | | being processed | | | 6 | 6 | Block contains an EID reference | [RFC5050]| | | | field | | | | 7-63 | Unassigned | | +--------------------+----------------------------------+----------+ IANA Question --> The current reference for the Bundle Block Types Registry is RFC 6255. Should the reference be changed to [ RFC-to-be ]? Fifth, in the Bundle Status Reason Codes registry on the Bundle Protocol registry page located at: https://www.iana.org/assignments/bundle/ the existing registry is to be changed. A new column will be added to the registry and marked as "Bundle Protocol Version." In addition, two new values are to be registered (values 9 and 10). The revised Bundle Status Reason Codes registry will be as follows: +--------------------+----------------------------------+----------------------------+ | Bundle | Value | Description | Reference | | Protocol| | | | | Version | | | | | | | | | +--------------------+----------------------------------+----------------------------+ | 6,7 | 0 | No additional information | [RFC5050] | | 6,7 | 1 | Lifetime expired | [RFC5050] | | 6,7 | 2 | Forwarded over unidirectional | [RFC5050] | | | | link | | | 6,7 | 3 | Transmission canceled | [RFC5050] | | 6,7 | 4 | Depleted storage | [RFC5050] | | 6,7 | 5 | Destination endpoint ID | [RFC5050] | | | | unintelligible | | | 6,7 | 6 | No known route to destination | [RFC5050] | | | | from here | | | 6,7 | 7 | No timely contact with next node | [RFC5050] | | | | on route | | | 6,7 | 8 | Block unintelligible | [RFC6255] | | 7 | 9 | Hop limit exceeded | [ RFC-to-be Section 6.1.1] | | 7 | 10 | Traffic pared | [ RFC-to-be Section 6.1.1] | | | 11-254 | Unassigned | | | 6 | 255 | Reserved | [RFC6255] | +-------+-----------------------------------------------+----------------------------+ IANA Question --> The current reference for the Bundle Block Types Registry is RFC 6255. Should the reference be changed to [ RFC-to-be ]? Sixth, a new registry is to be created called the Bundle Protocol URI Scheme Type registry. IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols? The new registry will be managed via Specification Required as defined by RFC 8126. The reference for the new registry is to be [ RFC-to-be ]. There are initial registrations in the new registry as follows: +--------------+-----------------------------+--------------------------+ | Value | Description | Reference | +--------------+-----------------------------+--------------------------+ | 0 | Reserved | | | 1 | dtn | [ RFC-to-be Section 10.7]| | 2 | ipn | RFC6260, Section 4 | | 3-254 | Unassigned | | | 255 | reserved | | +--------------+-----------------------------+--------------------------+ The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2019-11-12
|
17 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-11-06
|
17 | Stewart Bryant | Request for Last Call review by GENART Completed: Not Ready. Reviewer: Stewart Bryant. Sent review to list. |
2019-11-04
|
17 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder |
2019-11-04
|
17 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder |
2019-11-01
|
17 | Jean Mahoney | Request for Last Call review by GENART is assigned to Stewart Bryant |
2019-11-01
|
17 | Jean Mahoney | Request for Last Call review by GENART is assigned to Stewart Bryant |
2019-10-31
|
17 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Roman Danyliw |
2019-10-31
|
17 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Roman Danyliw |
2019-10-29
|
17 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2019-10-29
|
17 | Amy Vezza | The following Last Call announcement was sent out (ends 2019-11-12): From: The IESG To: IETF-Announce CC: magnus.westerlund@ericsson.com, dtn-chairs@ietf.org, fred.l.templin@boeing.com, Fred Templin , … The following Last Call announcement was sent out (ends 2019-11-12): From: The IESG To: IETF-Announce CC: magnus.westerlund@ericsson.com, dtn-chairs@ietf.org, fred.l.templin@boeing.com, Fred Templin , draft-ietf-dtn-bpbis@ietf.org, dtn@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Bundle Protocol Version 7) to Proposed Standard The IESG has received a request from the Delay/Disruption Tolerant Networking WG (dtn) to consider the following document: - 'Bundle Protocol Version 7' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2019-11-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This Internet Draft presents a specification for Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research group of the Internet Research Task Force and documented in RFC 5050. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dtn-bpbis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dtn-bpbis/ballot/ No IPR declarations have been submitted directly on this I-D. |
2019-10-29
|
17 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2019-10-29
|
17 | Magnus Westerlund | Last call was requested |
2019-10-29
|
17 | Magnus Westerlund | Ballot approval text was generated |
2019-10-29
|
17 | Magnus Westerlund | Ballot writeup was generated |
2019-10-29
|
17 | Magnus Westerlund | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2019-10-29
|
17 | Magnus Westerlund | Last call announcement was generated |
2019-10-25
|
17 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-17.txt |
2019-10-25
|
17 | (System) | New version approved |
2019-10-25
|
17 | (System) | Request for posting confirmation emailed to previous authors: Edward Birrane , Kevin Fall , Scott Burleigh , dtn-chairs@ietf.org |
2019-10-25
|
17 | Scott Burleigh | Uploaded new revision |
2019-10-25
|
16 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-16.txt |
2019-10-25
|
16 | (System) | New version approved |
2019-10-25
|
16 | (System) | Request for posting confirmation emailed to previous authors: Edward Birrane , Kevin Fall , Scott Burleigh , dtn-chairs@ietf.org |
2019-10-25
|
16 | Scott Burleigh | Uploaded new revision |
2019-10-18
|
15 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-10-18
|
15 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-15.txt |
2019-10-18
|
15 | (System) | New version approved |
2019-10-18
|
15 | (System) | Request for posting confirmation emailed to previous authors: Edward Birrane , Kevin Fall , Scott Burleigh , dtn-chairs@ietf.org |
2019-10-18
|
15 | Scott Burleigh | Uploaded new revision |
2019-09-12
|
14 | Magnus Westerlund | Sent feedback on changes. There are a couple of issues that still needs to be resolved before progressing. |
2019-09-12
|
14 | Magnus Westerlund | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2019-08-04
|
14 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-08-04
|
14 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-14.txt |
2019-08-04
|
14 | (System) | New version approved |
2019-08-04
|
14 | (System) | Request for posting confirmation emailed to previous authors: Edward Birrane , Scott Burleigh , Kevin Fall , dtn-chairs@ietf.org |
2019-08-04
|
14 | Scott Burleigh | Uploaded new revision |
2019-07-26
|
13 | Marc Blanchet | Added to session: IETF-105: dtn Fri-1000 |
2019-07-25
|
13 | Magnus Westerlund | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document requests Proposed Standard publication, as indicated in the title page header. Proposed Standard is appropriate, as this document is based on an earlier IRTF experimental RFC [RFC5050] that has seen wide-scale implementation and experimentation experience. Since the publication of [RFC5050] in 2007, the Delay-Tolerant Networking (DTN) Bundle Protocol has been implemented in multiple programming languages and deployed to a wide variety of computing platforms for a wide range of successful exercises. This implementation and deployment experience has demonstrated the general utility of the protocol for challenged network operations. [RFC5050] was a product of the now-closed IRTF DTN Research Group. That group has been succeeded by the IETF Delay Tolerant Networking Working Group (dtnwg) which was chartered within the Transport Area November 7, 2014. The current document was accepted as a dtnwg working document July 30, 2015. A critical amount of the community seems to think that the DTN Bundle Protocol is a promising approach that merits Proposed Standard. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Since the publication of the Bundle Protocol Specification (Experimental RFC 5050) in 2007, the Delay-Tolerant Networking Bundle Protocol has been implemented in multiple programming languages and deployed to a wide variety of computing platforms. This implementation and deployment experience has identified opportunities for making the protocol simpler, more capable, and easier to use. The present document, standardizing the Bundle Protocol (BP), is adapted from RFC 5050 in that context. This document describes version 7 of BP. Delay Tolerant Networking is a network architecture providing communications in and/or through highly stressed environments. Stressed networking environments include those with intermittent connectivity, large and/or variable delays, and high bit error rates. To provide its services, BP may be viewed as sitting at the application layer of some number of constituent networks, forming a store-carry-forward overlay network. Key capabilities of BP include: - Ability to use physical mobility for the movement of data - Ability to move the responsibility for error control from one node to another - Ability to cope with intermittent connectivity, including cases where the sender and receiver are not concurrently present in the network - Ability to take advantage of scheduled, predicted, and opportunistic connectivity, whether bidirectional or unidirectional, in addition to continuous connectivity - Late binding of overlay network endpoint identifiers to underlying constituent network addresses Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? This document has been discussed in the DTN working group since the beginning of when the working group was first formed (November 7, 2014), and its publication was one of the primary reasons for the working group formation. Discussion on the mailing list and at IETF WG sessions has produced significant interest and technical feedback that has greatly improved the document (as recorded in the mailing list archives and meeting minutes). Publication of this document will conclude the chartered dtnwg milestone: "December 2016 - RFC5050bis (draft-ietf-dtn-bpbis)". Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Multiple interoperable implementations of [RFC5050] have been deployed in significant ongoing experiments for many years. At the time of this writing, the only known implementation of the current document is microPCN (https://upcn.eu/). According to the developers: “The Micro Planetary Communication Network (uPCN) is a free software project intended to offer an implementation of Delay-tolerant Networking protocols for POSIX operating systems (well, and for Linux) plus for the ARM Cortex STM32F4 microcontroller series. More precisely it currently provides an implementation of - the Bundle Protocol (BP, RFC 5050), - the Bundle Protocol version 7 specification draft (version 6), - the DTN IP Neighbor Discovery (IPND) protocol, and - a routing approach optimized for message-ferry micro LEO satellites. uPCN is written in C and is built upon the real-time operating system FreeRTOS. The source code of uPCN is released under the "BSD 3-Clause License".” A first four-week Working Group Last Call was issued on the -06 version of the document on the dtnwg mailing list on 01/06/2017. Fred Templin posted a document shepherd review on the list on 01/20/2017, and the review comments were addressed by Scott Burleigh with resolutions scheduled to be incorporated in the next document version. The document shepherd review did not identify any major issues that would interrupt the last call. A thorough review of the document was then submitted to the list by Stephen Farrell on 01/23/2017. Extensive list discussions between Stephen, the authors and other WG participants identified resolutions to be incorporated into a -07, the most significant of which was the removal of the Custody Transfer function into a separate document. The Custody Transfer function was then published in ‘draft-burleigh-dtn-bibect’ on 06/22/2017 at the same time as the -07 version of the BP document (with custody transfer removed) was published. Both documents were presented during the DTNWG session at IETF 99 on 07/17/2017. Following the IETF 99 meeting, a -08 version of the BP document was published on 08/08/2017 to address a request for a suitable reference for the CRC functions and to add appropriate IANA Considerations at the request of the document shepherd. No other substantive changes were made. The working group chairs then issued a second Working Group Last Call. During the second WGLC, many contributors reviewed the document and several posted comments for discussion on the list. These included comments from Lucas Kahlert (several posts beginning 08/23/2017), Juan A. Fraire (10/17/2017) and Kiyohisa Suzuki (10/19/2017). All comments were taken under consideration and discussed by the authors in follow-up on the list where necessary. Resolutions were incorporated in a -09 draft version, published 11/22/2017. As the comments were being resolved, many posts to the list expressed support for progressing the document, including Mehmet Adalier (10/12/2017), Ruhai Wang (10/16/2017), Carlo Caini (10/16/2017), Juan Fraire (10/17/2017), Lucas Kahlert (10/18/2017), Kiyohisa Suzuki (10/19/2017), Marco Kaulea (10/22/2017), Marius Feldmann (11/15/2017), Jeremy Mayer (11/16/2017) and Gilbert Clark (11/19/2017). A dissenting opinion was expressed by Lloyd Wood (11/18/2017) and addressed by Fred Templin (11/19/2017). The document does not contain any elements that would require a MIB doctor or Media Type review. Other reviews have been automatically scheduled and will be conducted per standard IETF procedures – see (5) below. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Document Shepherd: Fred L. Templin (fred.l.templin@boeing.com) Responsible Area Director: Magnus Westerlund (magnus.westerlund@ericsson.com) (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd reviewed the -06 version of the document on 01/20/2017 following the first last-call. The review identified several editorial issues – all of which were addressed in the -07 version and carried forward into the -08 version. Numerous comments on the -08 version were subsequently submitted and discussed on the list with agreed resolutions. The document status for version -08 was presented at the IETF100 dtn working group session on 11/16/2017. The group determined that the plan of action was for the authors to submit a -09 version to address list comments and thus end the second WGLC. The -09 version was submitted on 11/22/2017 and reviewed by the document shepherd. The document shepherd discussed several points for clarification with the lead author, and it was agreed that no changes that would require a new draft version were necessary. However, the document was revised to -10 as a final version on 11/27/2017 to simply change the title to “Bundle Protocol Version 7” (see item 16 below). The document is therefore ready for progression to the IESG. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Per the actions noted above, thorough reviews have been conducted and no known concerns or issues are noted. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Bundle protocol security is delegated to the bundle protocol security protocol (bpsec); security review of that specification is clearly needed, and has been performed. No need for additional review from any other perspective has been identified. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The Document Shepherd has no specific concerns regarding this document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. Ed Birrane and Scott Burleigh asserted that they knew of no IPR requiring disclosure. Kevin Fall disclosed one possibly relevant patent (USPTO 7,930,379) but no other IPR requiring disclosure. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No, no known IPR disclosure has been filed that references this document. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This work has solid consensus from the working group, as evidenced by the list discussions (especially following the first WGLC). Please see (2) above regarding list posts supporting publication as well as the list archives themselves. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) Lloyd Wood suggested that there was a lack of support for the document on the list on 10/17/2017. Fred Templin responded that Lloyd was speaking only for himself (given that no others raised objections while many expressed support) and that minority dissenting opinions do not invalidate rough consensus and running code. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. ID nits reported only a single line that was different than "No issues found here." -- Possible downref: Non-RFC (?) normative reference: ref. 'CRC' But, that references is widely used by Internetworking technologies, e.g., as the standard for CRC calculations. A subsequent edition of the draft revises this reference (for CRC-32) and adds a second normative reference for CRC-16. In reference to the Internet-Drafts Checklist: * ABNF is used in section 10.3 of draft 14, but no reference to RFC 5234 is provided. * The IANA Considerations section is present; the details of the required new namespace (a registry of URI scheme types) are provided. Details of the new "dtn" URI scheme were not provided in draft 13 but are provided in draft 14. * Verbatim replication of the IPR Disclosure, IPR Notice, and Copyright Notice and Disclosure are not provided. The language provided is incomplete. * While the bpbis specification supersedes RFC 5050, that RFC is experimental; the absence of Updates or Supersedes language in the Abstract seems appropriate. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review criteria are known to be applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? There is a normative reference to the Bundle Protocol Security Specification, currently under Area Director review. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. Possible downward normative reference(s) to CRC standard(s) as detected by idnits, noted in (11) above. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This publication does not obsolete or change the status of any existing RFCs. The previous version of the Bundle Protocol is specified in RFC5050 as version 6 of the Bundle Protocol. This publication specifies version 7 of the Bundle Protocol. Both protocol versions may remain in service for some time before the deployed base of BPv6 is fully converted to BPv7. In that regard, maturation of the Bundle Protocol follows a similar precedence as for IPv4 and IPv6. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). IANA considerations have been updated to include three new values in the existing Bundle Administrative Record Types registry created by [RFC6255]. IANA considerations further request a new IANA registry for “URI scheme type values” under the existing “Bundle Protocol” heading. Initial values for the registry are given in the IANA Considerations section, along with the appropriate document references. The protocol headers specified in the document define new flag and/or code fields that are assigned initial values. These include the “CRC Type” (Section 4.1.2), “Bundle Processing Control Flags” (Section 4.1.3), “Block Processing Control Flags” (Section 4.1.4), and “Bundle Status Report Code” (Section 6.2). It was unclear to the authors and document shepherd which (if any) of these fields require an IANA registry; therefore, guidance from the IESG is requested. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. The document requests a new IANA registry for “URI scheme type values” under the existing “Bundle Protocol” heading. The initial values in the registry correspond to scheme names already published in existing documents and now provide numeric values corresponding to the names. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. An expression of the Bundle Protocol specification in Concise Data Definition Language (CDDL) is provided in informative Appendix B. This non-normative CDDL formulation was co-written by Carsten Bormann, one of the inventors of CDDL notation; we take this to constitute expert review. |
2019-07-05
|
13 | Magnus Westerlund | AD evaluation comments sent: https://mailarchive.ietf.org/arch/msg/dtn/eLOc9ZV-IHXHCKO-KP5dBNt11XI |
2019-07-05
|
13 | Magnus Westerlund | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2019-06-28
|
13 | Magnus Westerlund | IESG state changed to AD Evaluation from Publication Requested |
2019-06-12
|
13 | Marc Blanchet | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document requests Proposed Standard publication, as indicated in the title page header. Proposed Standard is appropriate, as this document is based on an earlier IRTF experimental RFC [RFC5050] that has seen wide-scale implementation and experimentation experience. Since the publication of [RFC5050] in 2007, the Delay-Tolerant Networking (DTN) Bundle Protocol has been implemented in multiple programming languages and deployed to a wide variety of computing platforms for a wide range of successful exercises. This implementation and deployment experience has demonstrated the general utility of the protocol for challenged network operations. [RFC5050] was a product of the now-closed IRTF DTN Research Group. That group has been succeeded by the IETF Delay Tolerant Networking Working Group (dtnwg) which was chartered within the Transport Area November 7, 2014. The current document was accepted as a dtnwg working document July 30, 2015. A critical amount of the community seems to think that the DTN Bundle Protocol is a promising approach that merits Proposed Standard. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Since the publication of the Bundle Protocol Specification (Experimental RFC 5050) in 2007, the Delay-Tolerant Networking Bundle Protocol has been implemented in multiple programming languages and deployed to a wide variety of computing platforms. This implementation and deployment experience has identified opportunities for making the protocol simpler, more capable, and easier to use. The present document, standardizing the Bundle Protocol (BP), is adapted from RFC 5050 in that context. This document describes version 7 of BP. Delay Tolerant Networking is a network architecture providing communications in and/or through highly stressed environments. Stressed networking environments include those with intermittent connectivity, large and/or variable delays, and high bit error rates. To provide its services, BP may be viewed as sitting at the application layer of some number of constituent networks, forming a store-carry-forward overlay network. Key capabilities of BP include: - Ability to use physical mobility for the movement of data - Ability to move the responsibility for error control from one node to another - Ability to cope with intermittent connectivity, including cases where the sender and receiver are not concurrently present in the network - Ability to take advantage of scheduled, predicted, and opportunistic connectivity, whether bidirectional or unidirectional, in addition to continuous connectivity - Late binding of overlay network endpoint identifiers to underlying constituent network addresses Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? This document has been discussed in the DTN working group since the beginning of when the working group was first formed (November 7, 2014), and its publication was one of the primary reasons for the working group formation. Discussion on the mailing list and at IETF WG sessions has produced significant interest and technical feedback that has greatly improved the document (as recorded in the mailing list archives and meeting minutes). Publication of this document will conclude the chartered dtnwg milestone: "December 2016 - RFC5050bis (draft-ietf-dtn-bpbis)". Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Multiple interoperable implementations of [RFC5050] have been deployed in significant ongoing experiments for many years. At the time of this writing, the only known implementation of the current document is microPCN (https://upcn.eu/). According to the developers: “The Micro Planetary Communication Network (uPCN) is a free software project intended to offer an implementation of Delay-tolerant Networking protocols for POSIX operating systems (well, and for Linux) plus for the ARM Cortex STM32F4 microcontroller series. More precisely it currently provides an implementation of - the Bundle Protocol (BP, RFC 5050), - the Bundle Protocol version 7 specification draft (version 6), - the DTN IP Neighbor Discovery (IPND) protocol, and - a routing approach optimized for message-ferry micro LEO satellites. uPCN is written in C and is built upon the real-time operating system FreeRTOS. The source code of uPCN is released under the "BSD 3-Clause License".” A first four-week Working Group Last Call was issued on the -06 version of the document on the dtnwg mailing list on 01/06/2017. Fred Templin posted a document shepherd review on the list on 01/20/2017, and the review comments were addressed by Scott Burleigh with resolutions scheduled to be incorporated in the next document version. The document shepherd review did not identify any major issues that would interrupt the last call A thorough review of the document was then submitted to the list by Stephen Farrell on 01/23/2017. Extensive list discussions between Stephen, the authors and other WG participants identified resolutions to be incorporated into a -07, the most significant of which was the removal of the Custody Transfer function into a separate document. The Custody Transfer function was then published in ‘draft-burleigh-dtn-bibect’ on 06/22/2017 at the same time as the -07 version of the BP document (with custody transfer removed) was published. Both documents were presented during the DTNWG session at IETF 99 on 07/17/2017. Following the IETF 99 meeting, a -08 version of the BP document was published on 08/08/2017 to address a request for a suitable reference for the CRC functions and to add appropriate IANA Considerations at the request of the document shepherd. No other substantive changes were made. The working group chairs then issued a second Working Group Last Call. During the second WGLC, many contributors reviewed the document and several posted comments for discussion on the list. These included comments from Lucas Kahlert (several posts beginning 08/23/2017), Juan A. Fraire (10/17/2017) and Kiyohisa Suzuki (10/19/2017). All comments were taken under consideration and discussed by the authors in follow-up on the list where necessary. Resolutions were incorporated in a -09 draft version, published 11/22/2017. As the comments were being resolved, many posts to the list expressed support for progressing the document, including Mehmet Adalier (10/12/2017), Ruhai Wang (10/16/2017), Carlo Caini (10/16/2017), Juan Fraire (10/17/2017), Lucas Kahlert (10/18/2017), Kiyohisa Suzuki (10/19/2017), Marco Kaulea (10/22/2017), Marius Feldmann (11/15/2017), Jeremy Mayer (11/16/2017) and Gilbert Clark (11/19/2017). A dissenting opinion was expressed by Lloyd Wood (11/18/2017) and addressed by Fred Templin (11/19/2017). The document does not contain any elements that would require a MIB doctor or Media Type review. Other reviews have been automatically scheduled and will be conducted per standard IETF procedures – see (5) below. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Document Shepherd: Fred L. Templin (fred.l.templin@boeing.com) Responsible Area Director: Spencer Dawkins (spencerdawkins.ietf@gmail.com) (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd reviewed the -06 version of the document on 01/20/2017 following the first last-call. The review identified several editorial issues – all of which were addressed in the -07 version and carried forward into the -08 version. Numerous comments on the -08 version were subsequently submitted and discussed on the list with agreed resolutions. The document status for version -08 was presented at the IETF100 dtn working group session on 11/16/2017. The group determined that the plan of action was for the authors to submit a -09 version to address list comments and thus end the second WGLC. The -09 version was submitted on 11/22/2017 and reviewed by the document shepherd. The document shepherd discussed several points for clarification with the lead author, and it was agreed that no changes that would require a new draft version were necessary. However, the document was revised to -10 as a final version on 11/27/2017 to simply change the title to “Bundle Protocol Version 7” (see item 16 below). The document is therefore ready for progression to the IESG. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Per the actions noted above, thorough reviews have been conducted and no known concerns or issues are noted. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. N/A. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. N/A. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. N/A. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. N/A. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This work has solid consensus from the working group, as evidenced by the list discussions (especially following the first WGLC). Please see (2) above regarding list posts supporting publication as well as the list archives themselves. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) Lloyd Wood suggested that there was a lack of support for the document on the list on 10/17/2017. Fred Templin responded that Lloyd was speaking only for himself (given that no others raised objections while many expressed support) and that minority dissenting opinions do not invalidate rough consensus and running code. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. ID nits reported only a single line that was different than "No issues found here." -- Possible downref: Non-RFC (?) normative reference: ref. 'CRC' But, that references is widely used by Internetworking technologies, e.g., as the standard for CRC calculations. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A. (13) Have all references within this document been identified as either normative or informative? N/A. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? N/A. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. N/A. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This publication does not obsolete or change the status of any existing RFCs. The previous version of the Bundle Protocol is specified in RFC5050 as version 6 of the Bundle Protocol. This publication specifies version 7 of the Bundle Protocol. Both protocol versions may remain in service for some time before the deployed base of BPv6 is fully converted to BPv7. In that regard, maturation of the Bundle Protocol follows a similar precedence as for IPv4 and IPv6. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). IANA considerations have been updated to include three new values in the existing Bundle Administrative Record Types registry created by [RFC6255]. IANA considerations further request a new IANA registry for “URI scheme type values” under the existing “Bundle Protocol” heading. Initial values for the registry are given in the IANA Considerations section, along with the appropriate document references. The protocol headers specified in the document define new flag and/or code fields that are assigned initial values. These include the “CRC Type” (Section 4.1.2), “Bundle Processing Control Flags” (Section 4.1.3), “Block Processing Control Flags” (Section 4.1.4), and “Bundle Status Report Code” (Section 6.2). It was unclear to the authors and document shepherd which (if any) of these fields require an IANA registry; therefore, guidance from the IESG is requested. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. The document requests a new IANA registry for “URI scheme type values” under the existing “Bundle Protocol” heading. The initial values in the registry correspond to scheme names already published in existing documents and now provide numeric values corresponding to the names. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. N/A. |
2019-06-12
|
13 | Marc Blanchet | Responsible AD changed to Magnus Westerlund |
2019-06-12
|
13 | Marc Blanchet | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2019-06-12
|
13 | Marc Blanchet | IESG state changed to Publication Requested from I-D Exists |
2019-06-12
|
13 | Marc Blanchet | IESG process started in state Publication Requested |
2019-04-23
|
13 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-13.txt |
2019-04-23
|
13 | (System) | New version approved |
2019-04-23
|
13 | (System) | Request for posting confirmation emailed to previous authors: Edward Birrane , Scott Burleigh , Kevin Fall , dtn-chairs@ietf.org |
2019-04-23
|
13 | Scott Burleigh | Uploaded new revision |
2019-03-26
|
12 | Rick Taylor | Added to session: IETF-104: dtn Tue-1610 |
2018-11-30
|
12 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-12.txt |
2018-11-30
|
12 | (System) | New version approved |
2018-11-30
|
12 | (System) | Request for posting confirmation emailed to previous authors: Edward Birrane , Kevin Fall , dtn-chairs@ietf.org, Scott Burleigh |
2018-11-30
|
12 | Scott Burleigh | Uploaded new revision |
2018-05-30
|
11 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-11.txt |
2018-05-30
|
11 | (System) | New version approved |
2018-05-30
|
11 | (System) | Request for posting confirmation emailed to previous authors: Edward Birrane , Kevin Fall , dtn-chairs@ietf.org, Scott Burleigh |
2018-05-30
|
11 | Scott Burleigh | Uploaded new revision |
2017-11-29
|
10 | Fred Templin | Changed document writeup |
2017-11-28
|
10 | Fred Templin | Changed document writeup |
2017-11-27
|
10 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-10.txt |
2017-11-27
|
10 | (System) | New version approved |
2017-11-27
|
10 | (System) | Request for posting confirmation emailed to previous authors: Edward Birrane , Kevin Fall , dtn-chairs@ietf.org, Scott Burleigh |
2017-11-27
|
10 | Scott Burleigh | Uploaded new revision |
2017-11-21
|
09 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-09.txt |
2017-11-21
|
09 | (System) | New version approved |
2017-11-21
|
09 | (System) | Request for posting confirmation emailed to previous authors: Edward Birrane , Kevin Fall , dtn-chairs@ietf.org, Scott Burleigh |
2017-11-21
|
09 | Scott Burleigh | Uploaded new revision |
2017-11-15
|
08 | Marc Blanchet | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2017-11-14
|
08 | Marc Blanchet | Added to session: IETF-100: dtn Thu-0930 |
2017-08-08
|
08 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-08.txt |
2017-08-08
|
08 | (System) | New version approved |
2017-08-08
|
08 | (System) | Request for posting confirmation emailed to previous authors: Edward Birrane , Kevin Fall , dtn-chairs@ietf.org, Scott Burleigh |
2017-08-08
|
08 | Scott Burleigh | Uploaded new revision |
2017-06-22
|
07 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-07.txt |
2017-06-22
|
07 | (System) | New version approved |
2017-06-22
|
07 | (System) | Request for posting confirmation emailed to previous authors: Edward Birrane , Kevin Fall , dtn-chairs@ietf.org, Scott Burleigh |
2017-06-22
|
07 | Scott Burleigh | Uploaded new revision |
2017-05-02
|
06 | (System) | Document has expired |
2017-03-25
|
06 | Marc Blanchet | Added to session: IETF-98: dtn Wed-0900 |
2017-01-06
|
06 | Marc Blanchet | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2017-01-06
|
06 | Marc Blanchet | IETF WG state changed to In WG Last Call from WG Document |
2017-01-06
|
06 | Marc Blanchet | Notification list changed to "Fred Templin" <fred.l.templin@boeing.com> |
2017-01-06
|
06 | Marc Blanchet | Document shepherd changed to Fred Templin |
2016-10-29
|
06 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-06.txt |
2016-10-29
|
06 | (System) | New version approved |
2016-10-29
|
05 | (System) | Request for posting confirmation emailed to previous authors: "Kevin Fall" , "Edward Birrane" , "Scott Burleigh" , dtn-chairs@ietf.org |
2016-10-29
|
05 | Scott Burleigh | Uploaded new revision |
2016-09-07
|
05 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-05.txt |
2016-07-05
|
04 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-04.txt |
2016-07-05
|
03 | Rick Taylor | After WG comments received on-list, the document has been returned to the working group for update. |
2016-07-05
|
03 | Rick Taylor | Tag Revised I-D Needed - Issue raised by WGLC set. |
2016-07-05
|
03 | Rick Taylor | IETF WG state changed to WG Document from In WG Last Call |
2016-04-27
|
03 | Brian Haberman | IETF WG state changed to In WG Last Call from WG Document |
2016-03-04
|
03 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-03.txt |
2016-01-11
|
02 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-02.txt |
2015-11-25
|
01 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-01.txt |
2015-07-30
|
00 | Marc Blanchet | Intended Status changed to Proposed Standard from None |
2015-07-30
|
00 | Marc Blanchet | This document now replaces draft-dtnwg-bp instead of None |
2015-07-30
|
00 | Scott Burleigh | New version available: draft-ietf-dtn-bpbis-00.txt |