[Nmc-wg] Clarifications on the base-doc
Slawomir Trzaszczka
trzaszcz at man.poznan.pl
Thu Jan 28 04:22:50 CST 2010
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
+--------------------------------------------+
More information about the Nmc-wg
mailing list