Shepherd writeup

Document Shepherd Write-Up for Delay-Tolerant Networking TCP Convergence 
Layer Protocol Version 4

Ed Birrane
19 June 2019

(1) What type of RFC is being requested? Why is this the proper type of RFC? 
    Is this type of RFC indicated in the title page header?

A Proposed Standard is being requested.  This is the appropriate type of RFC 
because the specification documented in the current Internet Draft describes
a protocol that is being implemented and used on the Internet. The title page 
header indicates that the intended status is Standards Track. 

(2) The IESG approval announcement includes a Document Announcement Write-Up.    
    Please provide such a Document Announcement Write-Up. 


Document Announcement Write-Up for Delay-Tolerant Networking TCP Convergence 
Layer Protocol Version 4

Ed Birrane
18 June 2019

Technical Summary:

This document describes the Delay-Tolerant Networking TCP Convergence Layer 
Protocol Version 4 (TCPCLv4) for use with the Bundle Protocol Version 7 (BPv7) 

The BPv7 implements a store-and-forward overlay network suitable for 
delay-tolerant message exchange. The protocol data unit for the BPv7 is the 
"bundle". BPv7 agents require convergence layer adapters (CLAs) to send and 
receive "bundles" using the service of some "native" link, network, or 
Internet protocol. Both the BPv7 and its CLAs reside at the application layer 
of the Internet model protocol stack [RFC1122]. 

The TCPCLv4 describes a CLA that sends and received bundles using the well-known 
Transmission Control Protocol (TCP). This specification describes the format and 
processing of the protocol data units passed between entities participating in 
TCPCLv4 communications.  

Working Group Summary:

TCPCLv4 is descended from an experimental IRTF specification TCPCLv3 [RFC7242]. 
Implementation experience with TCPCLv3 identified limitations such as ambiguity 
in bundle acknowledgment and refusal, non-normative discussion on how to 
incorporate TLS, and minor inefficiencies associated with sequencing. TCPCLv4 
was created to address those limitations and prepare the specification for 
non-experimental use. Technical discussions over the last 3 years have been
well informed and focused on TLS negotiations, overall protocol agent state 
machines, and a protocol extension mechanism. There is no controversy related 
to the adoption of the specification; DTNWG consensus on the draft is strong. 

Document Quality:

The workflow for TCPCLv4 remained largely unchanged from that of TCPCLv3 for 
which reference implementations exist. Co-author B. Sipos has created a 
reference implementation of TCPCLv4 to demonstrate features and ensure the 
clarity of the draft. Much of the recent review provided by the DTNWG focused 
on increasing the overall clarity of the specification to ensure no ambiguities 
exist for implementers. There have been no problems discovered with the 
reference implementation for this draft. 


The Document Shepherd is Ed Birrane.

The Responsible Area Director is Magnus Westerlund.


(3) Briefly describe the review of this document that was performed by the 
    Document Shepherd. 

The Document Shepherd has been reviewing and commenting on drafts of this 
specification since March of 2017 (IETF 98).  The current edition of the 
specification is considered ready for publication. 

(4) Does the document Shepherd have any concerns about the depth or breadth of 
    the reviews that have been performed?

No. Reviews have been performed by persons with a good understanding of the
Bundle Protocol and the concept of convergence layer adapters. Original authors
of the TCPCLv3 also reviewed and refined this specification, as have
implementers in the context of a reference implementation. 

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

The Document Shepherd does not perceive any need for review from additional 
perspectives. The DTNWG reviews have covered Bundle Protocol concepts, and the
use of TCP and TLS in this specification follows established norms. 

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

The Document Shepherd has no specific concerns or issues with this document.  
Technical questions have been discussed at length and resolved by consensus 
within the WG. Much of the recent discussion in the WG has focused on ensuring
that concepts are clear and this current revision of the specification has
accomplished that clarity.

(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?

All authors have indicated no known IPR disclosures for this work. 

(8) Has an IPR disclosure been filed that references this document? If so, 
    summarize any WG discussion and conclusion regarding the IPR disclosures.
There is no known IPR disclosure that directly references this document. 
However, the DTNWG mailing list indicated the existence of a patent 
(USPTO #7,930,379)that may or may not have applicability to DTN systems in 
general. This was brought to the attention of the DTNWG, DTNWG chairs, and
responsible AD.

The responsible AD has responded that unless additional IPR disclosures are 
provided this document can progress. 

(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 document appears to the Document Shepherd to represent the solid consensus 
of the WG. There have been no dissenting opinions relating to its most recent 
specifications in the WG itself or on the WG mailing list. Several WG members 
have experience with the preexisting TCPCLv3 that this specification replaces, 
with using Bundle Protocol, and with the concept and use of convergence layer 
adapters. The WG as a whole understands the intent, capabilities, design, and 
approach presenting in this specification. 

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? 

No threatened appeal or extreme discontent has been evident in the WG meetings 
or on the mailing list.

(11) Identify any ID nits the Document Shepherd has found in this document. 

There are some nits in the document, but nothing serious and nothing than 
cannot be easily remedied. 

According to ID Nits check:


  1) Obsolete normative reference: RFC 5246 has been obsoleted by RFC 8446.


  1-6) Warnings identify a "missing reference" for items that are not meant to 
       be references. These warning are considered false positives and refer to 
       labels used in examples and illustrations.

  7) Warning for out of date reference to bpbis. The specification refers to 
     draft-ietf-dtn-bpbis-12 and should refer to draft-ietf-dtn-bpbis-13.  

  8) Warning for out of date reference to bpsec. The specification refers to 
     draft-ietf-dtn-bpsec-09 and should refer to draft-ietf-dtn-bpsec-10.  


  1) The draft header indicates this specification obsoletes RFC7242 (IRTF 
     experimental specification of TCPClv3) but the abstract does not directly 
     say this. The absence of Updates or Supersedes language in the Abstract 
     seems appropriate because the superseded document was experimental. 

  2) The document date (March 31, 2019) is 80 days in the past. This date 
     references the publication date of the current version of the specification.

According to the Internet-Draft Checklist:

  Checklist 2.2.10: Verbatim replication of the IPR Disclosure is not provided.

  Checklist 2.2.11: Verbatim replication of the IPR Notice, and Copyright Notice 
                    and Disclosure are not provided.  

  Checklist 3.8: The specification includes a section 7 "Implementation status" 
                 which details the TCPCLv4 reference implementation. This 
                 section should be removed prior to publication.

  Checklist 3.7.A: The specification includes an informative reference to a 
                   GitHub link hosting the reference implementation. This 
                   reference should be removed at the same time Section 7 
                   "Implementation Status" is removed. 

(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, with one error (detected by ID nits) as noted in section 11.

(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?

The Internet-Draft for Bundle Protocol Version 7 (bpbis) is referenced as a 
normative document.  The bpbis document is being forwarded to the IESG at the 
same time as the TCPCLv4 document itself. 

(15) Are there downward normative references (see RFC 3967)? If so, list these 
     downward references to support the Area Director in the Last Call procedure.

There are no downward normative references, aside from the error (detected by 
ID Nits) as noted in section 11.

(16) Will publication of this document change the status of any existing RFCs? 


(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 8126).

The IANA considerations section is consistent with the body of the document. 
Referenced IANA registries are identified and new registries detailed to include 
their initial contents. Registry names appear reasonable. Registration 
procedures are provided. 

(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 session extension and transfer extension type sub-registries defined in this 
specification would benefit from expert review for future allocations. Expert 
review by people familiar with TCP and TLS would be useful to ensure that 
extensions are not added that would impact the efficient operation of this 
convergence layer adapter.

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

No sections of the TCPCLv4 specification are written in any formal language.