The main point is about the state diagrams in section 7.

1. While having a standard set of possible states is good, it looks to me like the actual state diagram (the transitions
 from one state to the others) is implementation dependent. I'm referring in particular to the service and guarantee 
state diagrams. So in my opinion the recommendation shouldn't be prescriptive in this area.

For example, in one service scenario, it may happen that the service cannot change from "ready" to "not ready", for 
example when the service can only be requested for a continuous time span (so that there are not intermediate intervals 
in which the service moves from ready to not ready and vice versa).


2. It looks like the agreement states specified in the Agreement State Types Schema (beforeOBserved/observed/
afterObserved) are not documented in the text as it is done for the guarantee and service. If so, please add a paragraph
 about agreement states in Section 7.

3. Currently the agreement cannot be in aborted state. I think it should be added. The same applies to the service, for 
example the  agreement could be observed, by because of a service provider failure, the associated service could be 
aborted.

4. With regards to the agreement state, another state that coud be possibly added, when it's under re-negotitation. For 
example, and agreement could be in "obvserved" state, but the initiator may be trying to renegotiate some of its 
attributes.