Hi All, These were my comments on the base document. I am still new to perfSONAR suite of services, so would love to get educated as well through the responses. I volunteer to fix the nits on SVN if you agree they are valid comments :). 1. It seems odd to have requirements specific MUST, SHOULD in a preliminary example. It would be great to consolidate the requirements either in Sections 4.3/4.4 or message structure protocol requirements before the example in Section 4.1. 2. In Section 4.1, page 7 a. I understand the concept behind "rejected outright" but it will good to elaborate what that means like " message is discarded and an response sent with a corresponding error message". b. In my understanding "Note this message is similar to the response in many ways" - the word response should actually be "request"? 3. In section 4.3.2.2, it seems that different services can react radically differently to the presence of objects in an API. I do not think it is wise for some services to view inclusion of this element as an "error". For optional elements, if a service that does not expect those elements and they are not mandatory, it should ignore it, as long as the overall request makes sense. Is there a particular case where inclusion of this element should generate an error? 4. It is mentioned many times that id may be used to track state between messages and services. The examples in the doc do illustrate how request/response and metadataidref use the id to do chaining. What is unclear is what other state can be tracked with "id"'s? An example would be great here. 5. Section 5.1, it seems like incorrect bold/highlighting of should, shall etc. I think Freek volunteered to fix it...but I could take a shot there as well. 6. Section 5.1.2 - The first line "When we are faced with like elements that MAY NOT share a common namespace, we SHOULD NOT combine." I am unclear what it means, would the meaning the sentence means to convey stay the say if I rephrased it as "When we are faced with like elements that do not share a common namespace, we SHOULD NOT combine". In the current instantiation within the document, it seems to indicate that if there are like elements that share a common namespace, there may be reasons not to combine. If there are exceptions like these, we should highlight what cases might those be..... 7. I am still trying to wrap my head around all the nuances of chaining, though the base concepts are simple. The confusion is especially around the descriptions of the three approaches "safe and stupid, dangerous yet intelligent and slow and steady". Should these three approaches be broken into their own sub-sections for better readability? Thanks, Inder