[decade] AD review of draft-ietf-decade-reqs-05.txt

["Rahman, Akbar" <[e-mail]>]

FYI - Here is the AD review of the DECADE requirements I-D.


Akbar (as document shepherd)


-----Original Message-----
From: IETF Secretariat [mailto:[e-mail]] 
Sent: Thursday, February 16, 2012 12:07 AM
To: [e-mail]; [e-mail]; Rahman, Akbar
Subject: ID Tracker State Update Notice: <draft-ietf-decade-reqs-05.txt>

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.


ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-decade-reqs/