(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?
Informational
Why is this the proper type of RFC?
This draft is the publication of a formely closed, vendor-specific
transport protocol, which is widely deployed in the internet. Also,
aspects of this protocol are protected by intellectual property
(https://datatracker.ietf.org/ipr/1942/) and are not reviewed
externally.
Is this type of RFC indicated in the title page header?
Yes
(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:
The Secure Real-Time Media Flow Protocol is an endpoint-to-endpoint
communication protocol designed to securely transport parallel flows
of real-time video, audio, and data messages, as well as bulk data,
over IP networks. RTMFP has features making it effective for
peer-to-peer (P2P) as well as client- server communications, even
when Network Address Translators (NATs) are used. Encryption,
Congestion Control, selective acknowledgements, separation of bulk
and real time flows, NAT traversal, reliable, partial reliable and
unreliable transport modes, as well as in-order and received-order
delivery are all core components of this protocol.
Working Group Summary:
The protocol was presented in TSVWG a few times, and the document
reviewed by a number of individuals. As a private protocol, no
technical changes were performed on the protocol itself, but the
authors disclosed more details in response to the WG discussions
(e.g. specifics around the congestion control mechanism).
Document Quality:
There is one existing implementation, widely deployed as part of a
multiple software packages from one vendor. The document was written
with the goal to spur more deployments and implementations.
Personnel:
Document Shepherd - Richard Scheffenegger <rs@netapp.com>
Responsible Area Director - Martin Stiemerling <martin.stiemerling@neclab.eu>
(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 review pointed out a few implicit assumptions, that have been
addressed in the latest version of the document. The reviews
did not modify any technical details that would affect an actual
implementation. The current version has been reviewed by multiple
individuals, and no major glitch or omissions are left after
the feedback was considered in the latest revision.
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
No; by the very nature of an individual contribution, some
details might have been done differently in a open protocol
development. However, the protocol does address all major
points any transport protocol has to consider, and more.
(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.
Security and encryption are key components of the protocol. No
particular encryption method is described. The document points
out a few considerations for selecting suitable encryption
methods. However, no thorough security review was performed.
(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.
None; This document is mainly a private contribution, released
to allow interoperable implementations. The authors choose to
submit it via the transport area, rather than an individual RFC
as a service to the community and to have an open discussion
on aspects of that protocol.
(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
(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the
IPR disclosures.
Yes - https://datatracker.ietf.org/ipr/1942/.
There was no further WG discussion regarding IPR.
(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?
Consensus has been reached that this document discloses all
relevant details of the protocol and its interactions. The
technical merits of the protocol per se were not discussed
in the WG.
(10) Has anyone threatened an appeal or otherwise indicated
extreme discontent?
No.
(11) Identify any ID nits the Document Shepherd has found in
this document. (See http://www.ietf.org/tools/idnits/ and
the Internet-Drafts Checklist). Boilerplate checks are not
enough; this check needs to be thorough.
ID-Nits wrongly identifies text in a graph to have odd
spacing; the objected "v" represents a down-arrow.
ID-Nits warn about comments [0], [1], [2], but these
are C-style references to specific entries of an array.
None of these nits could be interpreted erronously.
On page 19 there is one instance of a single, hanging line
preceeding a new section. It also begins with a RFC2119
keyword. If possible, one additional line from the paragraph
should be broken to the following page for a better look.
Section 3 title is by-itself on the last line on page 41.
Section 3.6.1 title is by-itself on the last line on page 70.
3.6.3.4.7 title on page 95.
section 7 title on page 100.
(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type
reviews.
This document has no interactions where formal reviews
would be required.
(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?
No.
(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.
No. This is an informational track RFC only.
(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 5226).
This document introduces a registry of "chunk type codes".
These type code values are assigned and maintained by Adobe.
Planned extensions will be released and documented by
updating this document.
(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.
None.
(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 document are writting in a formal
language, thus no automated checks were performed.
Type definitions in pseudo-code have been reviewed
manually and found to be consistent throughout the
document and match the descriptive language in the
respective text sections.