Shepherd writeup
draft-ietf-dtn-bpbis-12

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.
Back