DECADE Requirements
draft-ietf-decade-reqs-08

The review as also sent to the authors, chairs, and the doc shepherd:

Please find below my AD review for draft-ietf-decade-reqs-08.

First, here is a my general finding, before going to the details.

I have read the document as part of my AD review, also considered the comments received from Dave Crocker on this document, and also the general comments of the the DECADE requirements at the time of the review by Dave Crocker and Carsten Bormann.

I have almost for every requirement a point which is worth a DISCUSS, if this draft would come to the final IESG review.
I have to second Dave Crocker's concerns about this draft and also second the general concerns that have been expressed by many community members about the general technical quality of DECADE.

The DECADE Requirements are far away from being a stable and useful information RFC for the IETF community. It is lacking a good structure of the requirements, many requirements are a mingle-mangle, and are not clear, and a lot of aspects are just missing.

Furthermore, I cannot see that the comments from Dave Crocker have been addressed in an appropriate way, at least this is not obvious to me at all.

Therefore, I have returned the document to the WG and it is not under consideration by IESG for publication right now. The state in the data tracker is again AD watching/revised ID needed.

The WG must work on the points raise below, as the draft is not in a good shape.

Here is my detailed review:
- The split between SDT and DRP is introduced, but it is not reflected in any way in the document to group requirements accordingly. Either this has been forgotten or the whole split between the logical parts is useless. This is one of the main criticism I have about the draft.


- Abstract and all over the document:
The DECADE WG is not working on a DECADE system but on the DECADE protocol(s). This seems to be a fundamental misunderstanding throughout the full document.

- The title of the document should read "DECADE Protocol Requirements" instead of "DECADE requirements", just to be precise and to avoid any doubt.

- Section 2 on Terminology:
There is absolutely not need to have a section per term. It is sufficient to have a single section for all terms.

- The RFC 2119 language is cited in a rather strange place outside the terminology section.

- The definition in the Sections 2.4, 2.5, and 2.6 a rather strange. The definition of provider and consumer does not depend on the crypto credentials, but are more roles on who is providing data and who is retrieving it.

- Terminology in Section 2.7 suggest that data can be divided in smaller chunks, but not necessarily, i.e., it can be single large block. However, the introduction says the slightly the opposite of this, i.e.,  "typically broken in". I guess that the text is just not clear enough.

- Section 2.11.: I don't see that we define a DECADE compatible system, as we are defining requirements for the DECADE protocol.

- Section 3, page 8, at the bottom
OLD
combined on the wire
NEW
combined in one protocol

- Section 3, page 9, at the head of the page
OLD
If the protocols are physically separate on the wire,
NEW
If the protocols are separated,

- Section 4, 1st paragraph
OLD
  This document specifies the requirements for the DECADE DRP and SDT
  functions, either existing ones or new ones, and storage system to
  enable Target Applications to make use of storage within the network,
NEW
  This document specifies the requirements for the DECADE DRP and SDT
  protocols to
  enable Target Applications to make use of storage within the network,
I have not see specific requirements for storage.

- Section 4, 2nd bullet out of the bullet list
The term "Data transport" is defined there, but it is not listed in the terminology section.

- Section 5.1, head of page 10

  REQUIREMENT(S):  Each Data Object should be named to allow access.
      DECADE-compatible protocol(s) MUST support a data object naming
      scheme that ensures a high probability of uniqueness, with no
      coordination among multiple Storage Providers.  In other words,
      two Data Objects with the same name should be the same content
      with high probability.  A DECADE-compatible server SHOULD be able
      to respond to a DECADE-compatible client with an error indicating
      potential name conflicts.
This requirement is actually a set of *four* requirements all stuffed together.
1) Each object must be associated with a name.
2) the naming scheme for those names must support a high probability of uniqueness
3) no coordination between multiple decade servers required
4) The error handling. Which is, by the way, not related to data name uniqueness whatsoever.

The 'rational' sub-part is not doing its job. E.g., there can be collisions on the name space between different objects that have different content. However, it is not clear, i.e., the rational, why this is ok for your system. The rational is solely motivating the collision detection mechanism.
By the way, there is no real requirements that says that such a collision detection mechanism is required on the server, as one could also implement this on the client, right?

The 'exception' part is actually generating a new requirement which is also listed later on. This text isn't consistent and it is really hard to read and understand.

- Section 5.2 is completely empty. You may have lost text here.

- Section 5.3
What is 'DECADE MUST allow for efficient storage and data transfer'? How to do test if a protocol is fulfilling this requirement?
I do not see how it can be tested for compliance!

- Section 5.4
Again this requirement is actually a mingle-mangle of multiple requirements, actually a total of **six**:
1)    DECADE MUST support the ability to associate a set
      of system attributes with a data object with a scope local to a
      DECADE-compatible server.
2a)    In particular, the set MUST include
      time-to-live (or expiration time),
2b)    creation timestamp,
2c)    object size,
2d)    and object type.
By the way what is the object type? File type, mime type, etc??

3)    A DECADE-compatible client, with access
      permission,
4)    MUST be able to query the set of system attributes.
5)    The transmission of the attributes MUST use an operating system-
      independent and architecture-independent standard format.
6)    An ability to extend the set of attributes MUST exist.

- Section 5.5.
  REQUIREMENT(S):  DECADE-compatible clients and DECADE-compatible
      servers MUST NOT be able to associate Application-defined
      properties (metadata) with data objects beyond what is provided
      by Section 5.4.

I can understand that DECADE does have to have the ability to store extra data with the data object, but why do you need to rule this out forever? Isn't it enough to specify what you must store, leaving space for future work to add to application defined properties in the protocol?

- Section 6.1
  REQUIREMENT(S):  A Provider MUST be able to access the resources of
      its account.

I am absolutely not sure what this requirement is meaning for a protocol specification?

- Section 6.2
  REQUIREMENT(S):  Access to an account on a server MUST be granted to
      a provider based on cryptographic security.

Hmm, wouldn't be the first requirement saying that the protocol must support something like an account based access control?
And what must be provided by the cryptographic security?
The 'rational' part is not explaining any good reason why crypto is needed. Support for mobile users can also work with random, non-crypto cookies...

- Section 6.3 actually defines implicitly that user access control must be supported, but it is not explicitly stated.

- Section 6.4. I do not understand the offline aspect of the provider? Do you mean that the provider must be able to store credentials for data objects on the DECADE server?

- Section 6.5. This requirement sounds like voodoo to me. How does a Provider indicate policies to a server without contacting it?

- Section 6.6, this is more about access policies/features.
The requirement is actually again three requirements:
1) individual clients must be subject to access control to be allowed to access the DECADE server at all.
2) individual clients must be subject to access control with respect to particular data objects.
3) there is the need to support multiple policies, such as, read access, write access, read and write access, etc.


I could continue the list of my issues but I do stop here, as there are just too many issues. Sorry, but this document needs a lot of attention and work of the whole WG.


Please check other RFCs that enumerate requirements for protocols, one solely as an example: RFC 6457. Or the ALTO reqs which are in the RFC editor queue as an example closer to the topic of DECADE.

The document needs a major piece of work by the WG and will be pushed back to the WG to do so. The complete AD review will have more details.

State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
AD Review for draft-ietf-decade-reqs-05

1) A major problem of this document is that it uses DECADE as an actor, and specifies what DECADE must do. But DECADE is not an actor. The document really needs to be written in terms of the components of the system, and the specification of compliant behaviors. DECADE is really only a set of documents specifying compliance rules. The actors are decade-compatible servers, decade-compatible clients, decade-compatible protocols and the specification must describe what those actors are required to do, not what DECADE must do.

2) in 1, "the object of DECADE is"; is this use of decade a reference to the WG or the system? DECADE does not exist.

3) in 1, s/behind SPECIFIC requirements/behind requirements/
s/DOES NOT/does not/
s/DECADE protocols/DECADE-compatible protocols/

4) in 2, You should have a terminology section that defines what a decade server is/does, and what a decade client is/does.
I recommend that this document specifies **which** terms it uses from problem-statement.

so what is the difference between a target application and a decade client?

5) in 2, s/deliver content to a large number of users/deliver content to users/

6) in 2 "typically immutable" is a bit problematic. In the decade docs, immutable is sometimes described as a requirement of the system, but then other places talk about "typically", and "may be modified". You canno thane it both ways. Either the data is immutable or it is not, and that has a significant effect on the requirements and the ability to use existing protocols that do not meet that requirement. My impression is that requiring immutability severely contrains the decade approach, and is a bad thing to require.

== in 3 ==
7) "a back-end storage system" - what is a back end?

8) "DECADE does not intend". DECADE is not a concrete thing, so it cannot "do" anything. It is not sentient, so it cannot "intend". The closest you come to decade being concrete it that is is a WG, but a WG is a temporary thing and the document will outlast its lifetime; you should write in terms of the specifications; the specifications are real things.

9) [intends] "to create a protocol". The WG has explicitly NOT been authorized to create a new protocol (i.e. a new messaging protocol). That was very deliberate. Many of the tasks required of a "decade system" can be done using existing open, standard protocols. The WG is chartered to explore the problem space, and to develop an abstract architecture to break the problem into manageable parts, and to identify the requirements for those parts to work together. A gap analysis identifying how existing protocols cannot meet the requirements can be part of the outcome, but creating a protocol is explicitly out of scope of this WG.

10) in 3, first paragraph, "implementation of the DECADE servers"; I think there is a distinction that should be made between the functionality in an implementation for decade support, and a storage server. Therefore, I think "DECADE servers as much as possible" really should be "storage servers as much as possible"

11) a nit that drives me crazy - "It should be made clear that …"; You are absolutely right. and as editor of this draft, you should already be making this clear by documenting it clearly. therefore, there is no need to say "It should be made clear that …". I also recommend avoiding the use of "Note that …", "It should be noted that …" and so on. THat is exactly wheat you as editor are doing - noting the important points.

12) "the approach is to make DECADE a simple protocol". Similar to the WG, this "approach" is a temporary thing. But you are writing specifications that will last as long as the RFC series lasts. This whole paragraph can be summarized in about one sentence. "This specification discusses the requirements of functionality implemented with a storage system and within applications, to permit interoperable communications concerning the manipulation of stored content."

13) in 4, "This section details the requirements of DECADE protocol(s)". Is this the requirements applied to all protocols used with the decade architecture (including for example existing protocols)? or are these requirements of future protocol specifications? or are these requirements of protocol implementations? Those are different things.
If you are requiring something, then you should be using active voice to specific "who must do what". So is the who a protocol that fits within the architecture (an existing protocol used within the decade architecture must be able to pass  information from the client to the server)? or is it a decade client implementation (the implementation MUST include support for TLS1.0)? or is it the editor of future specifications designed to fit within the architecture (new protocol designs MUST support SHA-256)?

14) in 4.1.1.1 "SHOULD be usable"; whenever you use SHOULD, you imply there are acceptable exceptions to a MUST. Please identify what the acceptable exceptions are.

15) in 4.1.1.1, "should be usable across firewalls … [without ALGs)" I think this could be specified more accurately as "A decade client SHOULD NOT require ALGs to work across NATs and firewalls". I am not sure how useful this is as a requirement. There are certain things that require ALGs to be used, such as passing an IP address literal in a message. A good requirement, then, is "a decade protocol should not pass literal IP addresses in messages."

16) in 4.1.1.2 "DECADE SHOULD require that …" DECADE does not exist. The closest thing you have to DECADE requiring something is documenting it in this requirements document. So if it really is a REQUIREMENT, then write a requirement. But you should be able to justify WHY this is a requirement.

Is there an assumption here that the server is publicly accessible, and the client is behind a NAT? What if the server is behind a firewall, and the client is not? What if the client and the server are both behind firewalls? What if a protocol has a callback feature in order to work around this situation (the client can send a message out of band asking the server to initiate the connection)?

17) in 4.1.2.1 "DECADE MUST contain a mode" - what is DECADE? are you referring to a client-server protocol?
What MUST be implemented?

18) in 4.1.2.1, DECADE MUST contain a [secure] mode". Please see RFC3668. I think any new protocol MUST be implemented with strong security. Standard security protocols typically have non-secure crypto algorithms that an operator can choose to use. Defining "modes" makes a protocol more complex.

19) in 4.1.3.1 says [a storage system] "must not be required to generate responses"; 4.1.3.2 says "MUST [indicate to] a DECADE client"; So isn't this requiring a response?

20) 4.1.3.2 "since the resources … are not directly attached"; how do we know they are not directly attached? What if some of the resources are directly attached and others are not, as in NFS or SCSI?

21) in 4.1.3.2, why not make usage on remote storage discoverable, such as with the Host Resources MIB [RFC2790]?

22) 4.1.3.3 if access to the data has been identified as illegal, then the requestor is presumably acting illegally. why are we required to respond to illegal requests? Couldn't this help an attacker determine that the data exists and possibly other attributes of the data?

23) in 4.1.3.4 Note that "Note that" isn't needed. ;-)

24) in 4.2.1, the sentence starting "Additionally," - is this a separate requirement? is this really a requirement?
what if a user has two ways to deliver content, one using in-network storage over an inexpensive network such as wifi, and an expensive uplink such as 3G. Can the operator choose to allow latency in delivery over the wifi network that exceeds the latency of the 3G network?

25) in 4.2.1, "DECADE MUST allow clients to specify …" How about rewording this to be about the requirements of the client allowing the user to specify policy, the protocol carrying the (policy) specification, and the requirements of the server to enforce such (policy) specifications. DECADE doesn't exist and cannot allow a client to do anything.

26) 4.2.2 talks about efficient delivery and latency and handling small and large objects. The FEC framework (RFC6363) allows different FEC schemes to accommodate different scenarios that have different requirements on latency, block sizes, etc. Please consider this IETF standard within the proposed decade system.

27) 4.2.3 allows servers to transfer data directly, subject to the authorization in 4.7. I don't see how the requirements in 4.7 fit this specific case. Can you make this clearer?

28) 4.2.3 rationale - how does this affect the requirements for, say, protocols? and servers?

29) 4.3.1 "DECADE MUST support" - what must the client and the server and the protocol support? Please be specific.

30) 4.3.2 "DECADE MUST support"; no, the server must be able to be configured to accept and enforce access control polices that permit …; MUST the client (the application I guess) permit users to specify policies as part of its user interface? or could this be done using a non-decade protocol, such as SNMP or netconf or the cli? MUST the decade protocol be designed to carry the policies from client to server? Why not use something like AAA instead, so the implementation of a decade-specific functionality in the client and protocol and server is simplified?

31) as a member of the security directorate, I question whether 4.3.2 specifies a good requirement - "DECADE allows a user to implement access control policies for users that may or may not be known to the storage provider." This should be specified more clearly. I think what you want to say is that a user can be authenticated and authorized by another user. The server accepts the authentication of a user not known to it, done by a user known to it, and grants access based on the authorization provided by the known user.

Please make sure these access policies and referrals are consistent with other IETF protocols, such as NFS and HTTP.

32) 4.3.4 [protocols] "MUST only provide a minimal set"; I think this is phrased incorrectly. Must provide a minimal set and MAY provide additional

I think we might be specifying compliance the wrong way. The requirement is that the specifications must provide core functionality but may allow flexibility for extensions.

33) 4.4.1 "DECADE SHOULD remain agnostic." again, decade doesn't do anything. and I have no idea how I would judge whether an implementation was compliant to this requirement.

34) 4.4.1 "a compliant client "should be able to use"; let's turn this around. what MUST a compliant client implementation support so that a user can use …? MUST is for implementers; SHOULD is for users. A user cannot use something that an implementer didn't bother to implement. So what MUST an implementer provide so a user can use?

and be careful; if you say an implementer MUST support a bunch of optional services, how will you achieve interoperability across different implementations if vendor A implements only option 1, but vendor B implement only option 2?

35) in 4.4.2, "DECADE protocol(s) must be designed"; "If there is a need to design any DECADE protocols, they SHOULD be designed such that …"

36) 4.4.3, 4.4.4 "DECADE MUST", "DECADE MAY" - put this into client/server/protocol form please.

37) 4.5.1 "high probability of uniqueness" - what happnes i there is a collision? spell out the potential impact if there is a collision.

38) 4.5.1 "with no coordination"; I disagree with this. You are presumably talking about policy-based coordination, with no realtime user coordination.

39) 4.6.1 where is te enforcement done? which actors must do what? how is the multiple-application policy configured? what data should be configurable? if you use out-of-band mechanisms, how will you achieve interoperability across vendors?

40) 4.6.2, "only a certain amount of data" is this referring to the total amount of data, or block sizes, or per-operation?

41) I think in many of these requirements, it would be helpful to point out the applicability of existing protocols like Diameter.

42) 4.7.4 I question whether optimizations should permit a server to not check authorization. You should be specifying what is required for compliance. If unauthorized requests ar not denied, then you are dealing with a non-decade-compliant server. Please don't write requirements saying it is acceptable for servers to not deny access for unauthorized requests.

43) 4.7.5 "not simply by tying access to IP addresses" - I think tying access to a literal IP address is a bad idea and should be a SHOULD NOT (if not a MUST NOT). Allowing the use of literal addresses could lead to the need for ALGs.

44) 4.7.6 so what is the difference between this and 4.6.3?

45) 4.8 is "non-requirements", but 4.8.1 states a requirement (MUST NOT). [and please get rid of the "DECADE MUST" formulations. sigh.

46) 5.1 "MUST only store and manage data" - I think you mean "MUST store and manage only data"

47) 5.1 here immutable objects are MUST, compared to section 1 where immutability is typical.

48) 5.1 if immutability is a requirement, how well will that work with existing protocols? Do any of the existing storage protocols require immutability? data transport protocols? storage protocol standards functionality like dedup?

49) 5.3 Do existing standards have such a rule, or have they already dealt with the complexity of multiple writing? It is a common scenario in the IETF that a new protocol design tries to simplify, but in the end you end uo reinventing the whole ball of wax to deal with real-world needs.

50) 5.5. So other requirements ar here explicitly to avoid complexity, but in this simplest of scenarios, you add complexity by allowing reads before the write is complete. Go figure. This may simplify the server side, but you will increase the complexity of the client side when the writ fails and the subsequent read is aborted mid-read, and so on.

51) 5.6 allows applications to provide application-specific hints about the data, even though 4.8.1 says DECADE MUST NOT provide a mechanism for associating application-defined metadta properties with data.

52) what happens if data arrives out of order due to congestion or other network issues? Should the append append the data in the order received? You know, many existing standard protocols already know how to handle situations like this. Why reinvent the wheel? or do you want to REQUIRE in-order delivery?

53) 5.8 "MUST support [aggregated] data." You are reinventing monitoring. The IETF model, such as SNMP, typically says the client operates on a host, where there are typically plenty of resources. The server runs in an environment satisfying potentially many users, and resources can become scarce. The server should provide the base statistics and let the client do the aggregation, so we don't waste scarce resources (CPU, memory, etc.) doing aggregation calculations at the server.

54) 5.8 'The returned information MUST include resource usage of [self] and [others]". Why must each return include all this info? why not make it possible to request the data needed by the application that will use it? and you should NOT assume that only one application - a specific decade client - will want this information. Network admins might want this to see what impact this storage is having on network congestion; storage admins might want to monitor (and bill) for usage; local admins might want it to bill; remote admins might want ti compare to SLAs, and so on. And some tools might want to take the decade stats and compare them to stats of rather aspects of the network. So this info should probably use a standard technology such as a MIB rather than reinventing all of this as being decade-specific.

55)  5.8 "it is not required that decade support returning info broken down by [client]" - why not? this again gets into mandatory-to-implement, and interoperability. If some vendors choose not to provide the info my client, and some do, how will you achieve interoperability across implementations? How useful is the info if a tool wants to account for all the usage from a given client, but some compliant servers provide this and others do not?

56) 6..1.2 needs more detail as to why this is a requirement. Everybody knows that ALGs can make processing more difficult, but is this actually a "MUST NOT allow the use of additional network support"?  It certainly makes sense to make support for NATs and firewalls a requirement, but to then say additional network support is not allowed makes little sense if the standard mechanism is to have additional network support. Especially for environments where that content might need to cross one or more v4v6 boundaries, that additional network support is likely to be critical.

57) 7.1, the storage admin should be able to assign quotas and so on, but it is not necessarily driven by fairness. Maybe it has to do with the negotiated SLA, premium services, and so on. Unless you are going to define technical mechanisms to determine fairness, this doesn't really belong in an IETF document.

58) I question whether sect 7 is really useful. Either you have a requirement or you don't. These don't look like requirements to me. If this section lists things that are out of scope, then you probably should also be listing DRM as a future consideration that is out-of-scope. Gaming the system should be included in the security considerations, but really there should be requirements that prevent gaming the system.

59) "protocols and implementations should be aware" - these are not sentient things; they do not have awareness. Operators/admins have awareness.

60) 8.1, as pointed out earlier, servers DO have to authenticate users. they do so by accepting authentication and authorization referral by another entity.

61) 8.2 "DECADE itself does not provide" - decade does not exist. it cannot provide anything. But if the requirements for decade-compliance is a protocol that provides encryption and the protocol is part of the decade system, then apparently decade does provide encryption. Using DECADE as an actor makes thing ambiguous. Talk in terms of clients, servers, and protocols please.

62) 10.2, if you are referencing definitions in problem-statement that must be understood to understand this document, then the reference is normative.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Document shepherd: Akbar Rahman (as per request from DECADE chairs).
Yes, I have personally reviewed this version of the document and I
believe it is
ready for IESG review and publication.


(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? 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.


(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

I do not have concerns. The document is covering DECADE requirements
and
the WG has had quite extensive reviews of the document.


(1.d) Does the Document Shepherd have any specific concerns or
issues 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. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

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.

I am NOT aware of any IPR disclosures related to this document.


(1.e) 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 on the subject.
I believe the majority of the WG understands the document and do not
object.


(1.f) 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
entered into the ID Tracker.)

No threats of appeal or extreme discontent have been expressed
regarding this I-D.


(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts
Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are

not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes. I have run the I-D through the ID nits tool and found no major
issues.
The only minor warning that I received was regarding version numbers
of some informative references (see below). I believe these can be
fixed when any IESG comments are addressed.



== Outdated reference: A later version (-04) exists of

draft-ietf-decade-problem-statement-03



== Outdated reference: A later version (-04) exists of

draft-ietf-decade-arch-02




(1.h) Has the document split its references into normative and
informative? 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
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

References are split into normative and informative sections.
The normative references are published RFCs.


(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

Yes, I have verified the IANA Considerations Section. There are no
IANA impacts as this is a Requirements document


(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Not applicable.


(1.k) 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 target of DECoupled Application Data Enroute (DECADE) 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 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 the DECADE 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?



This is a requirements document for the DECADE protocol. 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/

(1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Document shepherd: Akbar Rahman (as per request from DECADE chairs).
Yes, I have personally reviewed this version of the document and I believe it is ready for IESG review and publication.


(1.b) Has the document had adequate review both from key WG members and from key non-WG members? 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.


(1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML?

I do not have concerns. The document is covering DECADE requirements and the WG has had quite extensive reviews of the document.


(1.d) Does the Document Shepherd have any specific concerns or issues 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. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue.

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.

I am NOT aware of any IPR disclosures related to this document.


(1.e) 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 on the subject. I believe the majority of the WG understands the document and do not object.


(1.f) 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 entered into the ID Tracker.)

No threats of appeal or extreme discontent have been expressed regarding this I-D.


(1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews?

Yes. I have run the I-D through the ID nits tool and found no major issues. The only minor warning that I received was regarding version numbers of some informative references (see below). I believe these can be fixed when any IESG comments are addressed.

== Outdated reference: A later version (-04) exists of
draft-ietf-decade-problem-statement-03

== Outdated reference: A later version (-04) exists of
draft-ietf-decade-arch-02


(1.h) Has the document split its references into normative and informative? 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
strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].

References are split into normative and informative sections. The normative references are published RFCs.


(1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body
of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation?

Yes, I have verified the IANA Considerations Section. There are no IANA impacts as this is a Requirements document


(1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?

Not applicable.


(1.k) 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 target of DECoupled Application Data Enroute (DECADE) 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 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 the DECADE 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?

This is a requirements document for the DECADE protocol. 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/