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.