[Nmc-wg] Clarifications on the base-doc

[Slawomir Trzaszczka]

On Wed, 2010-01-27 at 02:08 -0800, Inder Monga wrote:
> 

Hi all,

My comments on base-doc

4.1 - "Message Structure - ThereMAY" lack of space
7.1.3.1 - "The following describes the EchoRequest schema" EchoResponse
instead of EchoRequest
7.1.3.3 - "<nmwg:eventType>error.echo</nmwg:eventType>" echo response
example - dotted notation of result codes, in other examples url
notation was used

Regards,

Slawek


> 
> 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
> 
> 
> _______________________________________________
> Nmc-wg mailing list
> Nmc-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nmc-wg
-- 
+--------------------------------------------+
 Slawomir Trzaszczka                       
                                           
 Poznan Supercomputing & Networking Center 
+--------------------------------------------+