Document: draft-ietf-dmarc-arc-protocol
(1) The RFC is marked "Experimental", and it is listed correctly.
This is the proper RFC.
(2)
Technical Summary:
The Authenticated Received Chain (ARC) protocol provides an
authenticated "chain of custody" for a message, allowing each entity
that handles a message to see what entities have handled it before,
and to see what the message's authentication assessment was at each step
in the handling. This allows to convey original authentication
assessments across trust boundaries.
Working Group Summary:
The working group process was quite involved, and because this document
is Experimental, there was active discussions on implementations and
experiments that are detailed in the document. Additionally, an example is
included in Appendix B to show a mock up of a message that has multiple
ARC signatures.
Document Quality:
The document lists the existing implementations of the protocol, and
appears to cover a broad spectrum of both puchased software as well as
open source.
Personnel:
Document Shepherd: Tim Wicinski
Area Director: Alexey Melnikov
(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 first did a technical review of the document; and
followed that with an editorial review. There were several small
editorial issues that were passed along to the authors, but do not
affect the document itself.
(4) Does the document Shepherd have any concerns about the depth or breadth
of the reviews that have been performed?
The Document Shepherd does not have any concerns about the depth or
breath of reviews.
(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.
No other reviews are needed.
(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?
There are no concerns or issues.
(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.
Authors have confirmed there are no known IPR disclosures.
(8) Has an IPR disclosure been filed that references this document?
There are no IPR disclosures.
(9) How solid is the WG consensus behind this document?
Consensus is strong, and is both broad and deep in terms of the
working group.
(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 https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
None needed
(13) Have all references within this document been identified as
either normative or informative?
All references have been identified as normative or informative.
The only concern is the Informative References refer to previous
versions of this document. This should not be a problem moving
forward, but it could be addressed.
(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?
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.
There are no downward normative references.
(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.
There are no new IANA registries created by this document.
There are additions to existing registries, and the Document
Shepherd's review confirms the registries are clearly identified,
and the additions are consistent.
(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.
(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.