Document History
======================
1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?
---
Over the course of development of the DTNMA document since its adoption as a WG
document in August 2019, the document has received broad working group
agreement.
2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?
---
There was no controversy about specific points from within the working group,
but external review by the OPs area identified some controversy around naming
causing the document to be renamed "Delay-Tolerant Network Management
Architecture" from the "Asynchronous Management Architecture".
3. Has anyone threatened an appeal or otherwise indicated extreme discontent?
---
There have been no received threats of appeal or other extreme discontent.
4. For protocol documents, are there existing implementations of the contents
of the document?
---
As an informational document, there are no existing implementations. However,
there are exiting open-source implementations of protocols conformant to this
informational architecture.
Additional Reviews
======================
5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.
---
As an informational architecture document, this document does not closely
interact with other technologies. However, as a management architecture an
early review was requested by the OPS Area. This review was published on
6/26/2023 by Jurgen Schonwalder and can be found at:
https://mailarchive.ietf.org/arch/msg/dtn/QQ1lr9r8ytHP7Z7iFHWgzJHYEkA/.
Recommendations from that review were incorporated into the -06 and -07 version
of this document.
6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
---
As an informational architecture document, there is no requirement for this
review.
7. If the document contains a YANG module..
---
As an informational architecture document, there is no included YANG module.
8. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.
---
As an informational architecture document, there is no included formal language.
Document Shepherd Checks
======================
9. Based on the shepherd's review of the document, is it their opinion that
this document is needed, clearly written, complete, correctly designed, and
ready to be handed off to the responsible Area Director?
---
Yes. This document has been extensively discussed, reviewed and reworked in
the WG over 4 years. It's publication is blocking several personal drafts and
working group documents. This document covers the architecture for a major
working group charter item.
10. Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?
---
There are no identified common issues relating to either the "Transport" (TSV)
or "Operations and Management" (ops) areas.
11a. What type of RFC publication is being requested on the IETF stream?
---
This document is requested to be published as an Informational document.
11b. Why is this the proper type of RFC? Do all Datatracker state attributes
correctly reflect this intent?
---
The information in this document is solely information and not normative. All
data tracker attributes reflect this status.
12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79?
---
The three authors of this document confirm that there is no asserion of
intellectual property rights.
13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.
---
The document has 3 authors who have each confirmed their willingness to be
listed as such.
14. Document any remaining I-D nits in this document.
---
There are no nits on this document.
15. Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.
---
As an informative document there are no normative references.
16. List any normative references that are not freely available to anyone.
---
As an informative document there are no normative references.
17. Are there any normative downward references...
---
As an informative document there are no normative references.
18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
---
As an informative document there are no normative references.
19. Will publication of this document change the status of any existing RFCs?
---
This document will not change the status of any existing RFC.
20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
---
As an informational document, there are no registrations identified to be
managed by IANA.
21. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.
---
As an informational document, there are no registrations identified to be
managed by IANA.