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
-------------------------------------------------------------------------------
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)
[I-D.ietf-dtn-bpbis].
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.
Personnel:
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 ERROR:
1) Obsolete normative reference: RFC 5246 has been obsoleted by RFC 8446.
8 WARNINGS:
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.
2 COMMENTS:
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?
No.
(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.