(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper
type of RFC? Is this type of RFC indicated in the title page header?
- An “Informational” track RFC is being requested and is indicated in the title
page header. All the DECADE WG deliverables as per the current charter are
Informational. This is because protocol specification work for DECADE is
currently out of scope of the WG.
(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:
Relevant content can frequently be found in the abstract and/or introduction of
the document. If not, this may be an indication that there are deficiencies in
the abstract or introduction. - The target of the DECoupled Application Data
Enroute (DECADE) system
is to provide an open and standard in-network storage system for
applications, primarily P2P (peer-to-peer) applications, to store,
retrieve and manage their data. This draft enumerates and explains
requirements, not only for storage and retrieval, but also for data
management, access control and resource control, that should be
considered during the design and implementation of a DECADE-
compatible system. These are requirements on the entire system; some
of the requirements may eventually be implemented by an existing
protocol with/without some extensions (e.g., a protocol used to read
and write data from the storage system). The requirements in this
document are intended to ensure that a DECADE-compatible system
architecture includes all of the desired functionality for intended
applications.
Working Group Summary:
Was there anything in WG process that is worth noting? For example, was there
controversy about particular points or were there decisions where the consensus
was particularly rough? - There is support in the WG to advance this work.
There has not been any major controversy.
Document Quality:
Are there existing implementations of the protocol? Have a significant number
of vendors indicated their plan to implement the specification? Are there any
reviewers that merit special mention as having done a thorough review, e.g.,
one that resulted in important changes or a conclusion that the document had no
substantive issues? If there was a MIB Doctor, Media Type or other expert
review, what was its course (briefly)? In the case of a Media Type review, on
what date was the request posted? - This is a requirements document for the
DECADE system. There is no DECADE protocol I-D specified yet. So there is no
existing implementations of DECADE. However, there have been some early
experimental work by the research community in the space of DECADE type
in-network storage as, for example, captured by:
http://datatracker.ietf.org/doc/draft-ietf-decade-integration-example/
Personnel:
Who is the Document Shepherd? Who is the Responsible Area Director?
- Akbar Rahman (Akbar.Rahman@InterDigital.com) is the Document Shepherd.
Martin Stiemerling is the Responsible Area Director.
(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. -
I have previously been part of the WG reviews of this document and am familiar
with the technical content of the document. I have re-reviewed the document
when it started the publication process.
(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed? - The document has had extensive reviews
from both key and other WG members. I am satisfied with the depth and breadth
of the reviews.
- After the initial Document Shepherd write-up (Dec. 25, 2011) there have been
some detailed extra reviews as follows:
- Apps Area review by Dave Crocker on rev-05:
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04704.html
- Extra WG Review by Kostas on the draft-ietf-decade-arch which also had
re-structuring impacts (e.g. definitions and description text) on the
draft-ietf-decade-reqs (rev-06):
http://www.ietf.org/mail-archive/web/decade/current/msg00718.html
(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. The
document is covering DECADE requirements and the WG has had quite extensive
reviews of the document.
(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. - I do not have any
specific concerns at this time regarding this document. The document has been
presented and discussed adequately in previous WG meetings and on the mailing
list. (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, the authors have
confirmed by E-mail and have copied the chairs.
(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures. - I
am NOT aware of any IPR disclosures directly related to this document (other
than the general statement recently posted by the chair (Haibin) in
http://www.ietf.org/mail-archive/web/decade/current/msg00770.html ).
(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? - There is good concurrence among
active participants in the WG. I believe the majority of the WG understands the
document and do not object.
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.) - No threats of appeal or extreme
discontent have been expressed regarding this I-D.
(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. - Yes. I
have run the I-D through the ID nits tool and against the points of the
Checklist and found no major issues.
(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, media type, and URI type reviews. - Not Applicable.
(13) Have all references within this document been identified as either
normative or informative? - References are split into normative and informative
sections. The normative references are published RFCs.
(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 (see RFC 3967)? If so, list these
downward references to support the Area Director in the Last Call procedure. -
No.
(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it
unnecessary. - 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). - Not applicable.
(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. - Not applicable.
(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. - Not applicable.