Hi, some first comments/observations: - I think the structure of namespace could be explained - example of status response in 4.1 does not explain too much (looks the same as earlier response example) - in 4.3.2.6 the concept of key could be explained more (for me the key represents some bigger information structure; reasons: performance, simplicity) - in 4.3.2.7 the reference to "Characteristic" document is missing - I'm wondering whether we can say in 4.3.3 that the request with more data triggers includes logical independent sub-requests - 4.4.1: typo "request schema" - I would remove parameter elements "supportedEventType" from all message examples. I understand that it's supported by the implementations but it's agreed to use eventType element - I think we have to rebuild Result Code section and finish the discussion on new ideas proposed by Slawek and Jeff. That's very important and must be done. Roman
Hi Roman; Thanks for the feedback, comments inline:
some first comments/observations:
- I think the structure of namespace could be explained
The original thinking was the NM-WG document, "An Extensible Schema for Network Measurement and Performance Data", would contain the entire explanation of namespaces (the idea itself coming from another OGF WG). Any future documents from related projects (NMC, NML, others?) would reference this and only note caveats to the original rule. The NM-WG doc is here: https://forge.gridforum.org/sf/go/doc15649?nav=1 And I think namespaces are in section 4. Does everyone think this is sufficient, or should we consider other options?
- example of status response in 4.1 does not explain too much (looks the same as earlier response example)
Now that things are in SVN, could you suggest a more fitting example?
- in 4.3.2.6 the concept of key could be explained more (for me the key represents some bigger information structure; reasons: performance, simplicity)
Good ideas, I will note these.
- in 4.3.2.7 the reference to "Characteristic" document is missing
Good catch, I will add a real reference.
- I'm wondering whether we can say in 4.3.3 that the request with more data triggers includes logical independent sub-requests
The concept of chaining is also something that Martin and I have struggled to find a proper location. Chaining is explained in sections 5 and 6 of the above NM-WG document currently. I think the basics should remain in NM-WG since the concept of the chain is essential to the definition of data and metadata. We may be able to reference the basic concept though to motivate some of the more unique cases.
- 4.4.1: typo "request schema"
I will correct.
- I would remove parameter elements "supportedEventType" from all message examples. I understand that it's supported by the implementations but it's agreed to use eventType element
I don't think this is a big deal, since these are just examples. I can remove them if we think it will cause confusion.
- I think we have to rebuild Result Code section and finish the discussion on new ideas proposed by Slawek and Jeff. That's very important and must be done.
This would be the current venu to do so. Has Slawek updated his document based on the suggestions that were made before the holidays? Perhaps he can send it again? Thanks; -jason
Hi all, On Mon, 2010-01-11 at 20:01 -0500, Jason Zurawski wrote:
Hi Roman;
Thanks for the feedback, comments inline:
some first comments/observations:
- I think the structure of namespace could be explained
The original thinking was the NM-WG document, "An Extensible Schema for Network Measurement and Performance Data", would contain the entire explanation of namespaces (the idea itself coming from another OGF WG). Any future documents from related projects (NMC, NML, others?) would reference this and only note caveats to the original rule. The NM-WG doc is here:
https://forge.gridforum.org/sf/go/doc15649?nav=1
And I think namespaces are in section 4. Does everyone think this is sufficient, or should we consider other options?
- example of status response in 4.1 does not explain too much (looks the same as earlier response example)
Now that things are in SVN, could you suggest a more fitting example?
- in 4.3.2.6 the concept of key could be explained more (for me the key represents some bigger information structure; reasons: performance, simplicity)
Good ideas, I will note these.
- in 4.3.2.7 the reference to "Characteristic" document is missing
Good catch, I will add a real reference.
- I'm wondering whether we can say in 4.3.3 that the request with more data triggers includes logical independent sub-requests
The concept of chaining is also something that Martin and I have struggled to find a proper location. Chaining is explained in sections 5 and 6 of the above NM-WG document currently. I think the basics should remain in NM-WG since the concept of the chain is essential to the definition of data and metadata. We may be able to reference the basic concept though to motivate some of the more unique cases.
- 4.4.1: typo "request schema"
I will correct.
- I would remove parameter elements "supportedEventType" from all message examples. I understand that it's supported by the implementations but it's agreed to use eventType element
I don't think this is a big deal, since these are just examples. I can remove them if we think it will cause confusion.
- I think we have to rebuild Result Code section and finish the discussion on new ideas proposed by Slawek and Jeff. That's very important and must be done.
This would be the current venu to do so. Has Slawek updated his document based on the suggestions that were made before the holidays? Perhaps he can send it again?
Yes, file is in attachment Regards, Slawek
Thanks;
-jason
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
-- +--------------------------------------------+ Slawomir Trzaszczka Poznan Supercomputing & Networking Center +--------------------------------------------+
Thanks Slawomir. It would be great if people could either respond to this thread with their opinions on the proposed solutions, or be on the call/VC so we can come to some resolution on this topic. thanks, jeff On Jan 12, 2010, at 2:58 AM, Slawomir Trzaszczka wrote:
Hi all,
On Mon, 2010-01-11 at 20:01 -0500, Jason Zurawski wrote:
Hi Roman;
Thanks for the feedback, comments inline:
some first comments/observations:
- I think the structure of namespace could be explained
The original thinking was the NM-WG document, "An Extensible Schema for Network Measurement and Performance Data", would contain the entire explanation of namespaces (the idea itself coming from another OGF WG). Any future documents from related projects (NMC, NML, others?) would reference this and only note caveats to the original rule. The NM-WG doc is here:
https://forge.gridforum.org/sf/go/doc15649?nav=1
And I think namespaces are in section 4. Does everyone think this is sufficient, or should we consider other options?
- example of status response in 4.1 does not explain too much (looks the same as earlier response example)
Now that things are in SVN, could you suggest a more fitting example?
- in 4.3.2.6 the concept of key could be explained more (for me the key represents some bigger information structure; reasons: performance, simplicity)
Good ideas, I will note these.
- in 4.3.2.7 the reference to "Characteristic" document is missing
Good catch, I will add a real reference.
- I'm wondering whether we can say in 4.3.3 that the request with more data triggers includes logical independent sub-requests
The concept of chaining is also something that Martin and I have struggled to find a proper location. Chaining is explained in sections 5 and 6 of the above NM-WG document currently. I think the basics should remain in NM-WG since the concept of the chain is essential to the definition of data and metadata. We may be able to reference the basic concept though to motivate some of the more unique cases.
- 4.4.1: typo "request schema"
I will correct.
- I would remove parameter elements "supportedEventType" from all message examples. I understand that it's supported by the implementations but it's agreed to use eventType element
I don't think this is a big deal, since these are just examples. I can remove them if we think it will cause confusion.
- I think we have to rebuild Result Code section and finish the discussion on new ideas proposed by Slawek and Jeff. That's very important and must be done.
This would be the current venu to do so. Has Slawek updated his document based on the suggestions that were made before the holidays? Perhaps he can send it again?
Yes, file is in attachment
Regards,
Slawek
Thanks;
-jason
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
-- +--------------------------------------------+ Slawomir Trzaszczka
Poznan Supercomputing & Networking Center +--------------------------------------------+
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
Proposal 3 seems to be the favorite from the pS-dev mailing list. I like it too, but have the following comments/concerns: - The structure is a bit more rigid than the others, e.g. this is something that we (perfsonar/nmc) would set in stone instead of our normal 'living document' approach. This is not a bad thing, but there is a bit more wiggle room in the other approaches; a developer could carve out new space under /ma or similar for new service types without needing to upset the specification. I think the approach in proposal 3 would force compatibility quickly, but it also puts a lot of pressure to 'get it right' the first time. This group should carefully consider the categories and try to anticipate all of the needs as we make the recommendation. - Jeff/Roman/Myself had started a mini discussion on the merits of clients needing vs wanting to know more about an error, e.g. an error is an error regardless of where it comes from (an mp or an ma). I am still not completely convinced this is always be the case, I think knowledge regarding the service type in particular is valuable. The compromise here is was to introduce parameters to the result code message to convey this information making smart and dumb clients happy. - The document should explain that the eventTypes are set in the stone, and a default message should be described for each as well. It seems reasonable to allows services to modify this message if desired, as long as the eventTypes are respected. Thanks; -jason
Thanks Slawomir.
It would be great if people could either respond to this thread with their opinions on the proposed solutions, or be on the call/VC so we can come to some resolution on this topic.
thanks, jeff
On Jan 12, 2010, at 2:58 AM, Slawomir Trzaszczka wrote:
Hi all,
On Mon, 2010-01-11 at 20:01 -0500, Jason Zurawski wrote:
Hi Roman;
Thanks for the feedback, comments inline:
some first comments/observations:
- I think the structure of namespace could be explained
The original thinking was the NM-WG document, "An Extensible Schema for Network Measurement and Performance Data", would contain the entire explanation of namespaces (the idea itself coming from another OGF WG). Any future documents from related projects (NMC, NML, others?) would reference this and only note caveats to the original rule. The NM-WG doc is here:
https://forge.gridforum.org/sf/go/doc15649?nav=1
And I think namespaces are in section 4. Does everyone think this is sufficient, or should we consider other options?
- example of status response in 4.1 does not explain too much (looks the same as earlier response example)
Now that things are in SVN, could you suggest a more fitting example?
- in 4.3.2.6 the concept of key could be explained more (for me the key represents some bigger information structure; reasons: performance, simplicity)
Good ideas, I will note these.
- in 4.3.2.7 the reference to "Characteristic" document is missing
Good catch, I will add a real reference.
- I'm wondering whether we can say in 4.3.3 that the request with more data triggers includes logical independent sub-requests
The concept of chaining is also something that Martin and I have struggled to find a proper location. Chaining is explained in sections 5 and 6 of the above NM-WG document currently. I think the basics should remain in NM-WG since the concept of the chain is essential to the definition of data and metadata. We may be able to reference the basic concept though to motivate some of the more unique cases.
- 4.4.1: typo "request schema"
I will correct.
- I would remove parameter elements "supportedEventType" from all message examples. I understand that it's supported by the implementations but it's agreed to use eventType element
I don't think this is a big deal, since these are just examples. I can remove them if we think it will cause confusion.
- I think we have to rebuild Result Code section and finish the discussion on new ideas proposed by Slawek and Jeff. That's very important and must be done.
This would be the current venu to do so. Has Slawek updated his document based on the suggestions that were made before the holidays? Perhaps he can send it again?
Yes, file is in attachment
Regards,
Slawek
I like second proposal which groups result codes according to functionalities. It's flexible because it works when e.g. a service acts as ma and mp. I would also add additional category which is not related with a functionality, for example when message parsing fails. 3th proposal is OK as well. Less preferable then 2nd but I'm fine with it if 3th will have more supporters. Roman Jeff W.Boote wrote:
Thanks Slawomir.
It would be great if people could either respond to this thread with their opinions on the proposed solutions, or be on the call/VC so we can come to some resolution on this topic.
thanks, jeff
On Jan 12, 2010, at 2:58 AM, Slawomir Trzaszczka wrote:
Hi all,
On Mon, 2010-01-11 at 20:01 -0500, Jason Zurawski wrote:
Hi Roman;
Thanks for the feedback, comments inline:
some first comments/observations:
- I think the structure of namespace could be explained
The original thinking was the NM-WG document, "An Extensible Schema for Network Measurement and Performance Data", would contain the entire explanation of namespaces (the idea itself coming from another OGF WG). Any future documents from related projects (NMC, NML, others?) would reference this and only note caveats to the original rule. The NM-WG doc is here:
https://forge.gridforum.org/sf/go/doc15649?nav=1
And I think namespaces are in section 4. Does everyone think this is sufficient, or should we consider other options?
- example of status response in 4.1 does not explain too much (looks the same as earlier response example)
Now that things are in SVN, could you suggest a more fitting example?
- in 4.3.2.6 the concept of key could be explained more (for me the key represents some bigger information structure; reasons: performance, simplicity)
Good ideas, I will note these.
- in 4.3.2.7 the reference to "Characteristic" document is missing
Good catch, I will add a real reference.
- I'm wondering whether we can say in 4.3.3 that the request with more data triggers includes logical independent sub-requests
The concept of chaining is also something that Martin and I have struggled to find a proper location. Chaining is explained in sections 5 and 6 of the above NM-WG document currently. I think the basics should remain in NM-WG since the concept of the chain is essential to the definition of data and metadata. We may be able to reference the basic concept though to motivate some of the more unique cases.
- 4.4.1: typo "request schema"
I will correct.
- I would remove parameter elements "supportedEventType" from all message examples. I understand that it's supported by the implementations but it's agreed to use eventType element
I don't think this is a big deal, since these are just examples. I can remove them if we think it will cause confusion.
- I think we have to rebuild Result Code section and finish the discussion on new ideas proposed by Slawek and Jeff. That's very important and must be done.
This would be the current venu to do so. Has Slawek updated his document based on the suggestions that were made before the holidays? Perhaps he can send it again?
Yes, file is in attachment
Regards,
Slawek
Thanks;
-jason
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
-- +--------------------------------------------+ Slawomir Trzaszczka
Poznan Supercomputing & Networking Center +--------------------------------------------+
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg _______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
Roman Lapacz wrote:
I like second proposal which groups result codes according to functionalities. It's flexible because it works when e.g. a service acts as ma and mp. I would also add additional category which is not related with a functionality, for example when message parsing fails.
3th proposal is OK as well. Less preferable then 2nd but I'm fine with it if 3th will have more supporters.
Roman
I'm fine with 2nd and 3rd proposal as well. I might already have said on the perfsonar list, 1st and 2nd proposals are designed from the point of view of a server developer.
From the client side, if the result codes are only expected to be displayed to the human users, and not triggering a client action, it doesn't really matter which proposal will be adopted.
If, on the other hand, an automatic client action is expected, then it is crucial to know if the reason of the failure is server side, or client side (e.g. client submitting wrong data , which can be fixed and resubmitted). Best regards, Nina
Jeff W.Boote wrote:
Thanks Slawomir.
It would be great if people could either respond to this thread with their opinions on the proposed solutions, or be on the call/VC so we can come to some resolution on this topic.
thanks, jeff
On Jan 12, 2010, at 2:58 AM, Slawomir Trzaszczka wrote:
Hi all,
On Mon, 2010-01-11 at 20:01 -0500, Jason Zurawski wrote:
Hi Roman;
Thanks for the feedback, comments inline:
some first comments/observations:
- I think the structure of namespace could be explained
The original thinking was the NM-WG document, "An Extensible Schema for Network Measurement and Performance Data", would contain the entire explanation of namespaces (the idea itself coming from another OGF WG). Any future documents from related projects (NMC, NML, others?) would reference this and only note caveats to the original rule. The NM-WG doc is here:
https://forge.gridforum.org/sf/go/doc15649?nav=1
And I think namespaces are in section 4. Does everyone think this is sufficient, or should we consider other options?
- example of status response in 4.1 does not explain too much (looks the same as earlier response example)
Now that things are in SVN, could you suggest a more fitting example?
- in 4.3.2.6 the concept of key could be explained more (for me the key represents some bigger information structure; reasons: performance, simplicity)
Good ideas, I will note these.
- in 4.3.2.7 the reference to "Characteristic" document is missing
Good catch, I will add a real reference.
- I'm wondering whether we can say in 4.3.3 that the request with more data triggers includes logical independent sub-requests
The concept of chaining is also something that Martin and I have struggled to find a proper location. Chaining is explained in sections 5 and 6 of the above NM-WG document currently. I think the basics should remain in NM-WG since the concept of the chain is essential to the definition of data and metadata. We may be able to reference the basic concept though to motivate some of the more unique cases.
- 4.4.1: typo "request schema"
I will correct.
- I would remove parameter elements "supportedEventType" from all message examples. I understand that it's supported by the implementations but it's agreed to use eventType element
I don't think this is a big deal, since these are just examples. I can remove them if we think it will cause confusion.
- I think we have to rebuild Result Code section and finish the discussion on new ideas proposed by Slawek and Jeff. That's very important and must be done.
This would be the current venu to do so. Has Slawek updated his document based on the suggestions that were made before the holidays? Perhaps he can send it again?
Yes, file is in attachment
Regards,
Slawek
Thanks;
-jason
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
-- +--------------------------------------------+ Slawomir Trzaszczka
Poznan Supercomputing & Networking Center +--------------------------------------------+
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg _______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
Nina Jeliazkova wrote:
Roman Lapacz wrote:
I like second proposal which groups result codes according to functionalities. It's flexible because it works when e.g. a service acts as ma and mp. I would also add additional category which is not related with a functionality, for example when message parsing fails.
3th proposal is OK as well. Less preferable then 2nd but I'm fine with it if 3th will have more supporters.
Roman
I'm fine with 2nd and 3rd proposal as well. I might already have said on the perfsonar list, 1st and 2nd proposals are designed from the point of view of a server developer.
From the client side, if the result codes are only expected to be displayed to the human users, and not triggering a client action, it doesn't really matter which proposal will be adopted.
If, on the other hand, an automatic client action is expected, then it is crucial to know if the reason of the failure is server side, or client side (e.g. client submitting wrong data , which can be fixed and resubmitted).
On the other hand, could we say: client can send anything and it's the matter of a service what is accepted. So in this case there are no server and client errors. Just errors. If a services does not support a request then it generates 'parse error' or 'unknown request error'. Roman
Best regards, Nina
Jeff W.Boote wrote:
Thanks Slawomir.
It would be great if people could either respond to this thread with their opinions on the proposed solutions, or be on the call/VC so we can come to some resolution on this topic.
thanks, jeff
On Jan 12, 2010, at 2:58 AM, Slawomir Trzaszczka wrote:
Hi all,
On Mon, 2010-01-11 at 20:01 -0500, Jason Zurawski wrote:
Hi Roman;
Thanks for the feedback, comments inline:
some first comments/observations:
- I think the structure of namespace could be explained
The original thinking was the NM-WG document, "An Extensible Schema for Network Measurement and Performance Data", would contain the entire explanation of namespaces (the idea itself coming from another OGF WG). Any future documents from related projects (NMC, NML, others?) would reference this and only note caveats to the original rule. The NM-WG doc is here:
https://forge.gridforum.org/sf/go/doc15649?nav=1
And I think namespaces are in section 4. Does everyone think this is sufficient, or should we consider other options?
- example of status response in 4.1 does not explain too much (looks the same as earlier response example)
Now that things are in SVN, could you suggest a more fitting example?
- in 4.3.2.6 the concept of key could be explained more (for me the key represents some bigger information structure; reasons: performance, simplicity)
Good ideas, I will note these.
- in 4.3.2.7 the reference to "Characteristic" document is missing
Good catch, I will add a real reference.
- I'm wondering whether we can say in 4.3.3 that the request with more data triggers includes logical independent sub-requests
The concept of chaining is also something that Martin and I have struggled to find a proper location. Chaining is explained in sections 5 and 6 of the above NM-WG document currently. I think the basics should remain in NM-WG since the concept of the chain is essential to the definition of data and metadata. We may be able to reference the basic concept though to motivate some of the more unique cases.
- 4.4.1: typo "request schema"
I will correct.
- I would remove parameter elements "supportedEventType" from all message examples. I understand that it's supported by the implementations but it's agreed to use eventType element
I don't think this is a big deal, since these are just examples. I can remove them if we think it will cause confusion.
- I think we have to rebuild Result Code section and finish the discussion on new ideas proposed by Slawek and Jeff. That's very important and must be done.
This would be the current venu to do so. Has Slawek updated his document based on the suggestions that were made before the holidays? Perhaps he can send it again?
Yes, file is in attachment
Regards,
Slawek
Thanks;
-jason
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
-- +--------------------------------------------+ Slawomir Trzaszczka
Poznan Supercomputing & Networking Center +--------------------------------------------+
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg _______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
Roman Lapacz wrote:
Nina Jeliazkova wrote:
Roman Lapacz wrote:
I like second proposal which groups result codes according to functionalities. It's flexible because it works when e.g. a service acts as ma and mp. I would also add additional category which is not related with a functionality, for example when message parsing fails.
3th proposal is OK as well. Less preferable then 2nd but I'm fine with it if 3th will have more supporters.
Roman
I'm fine with 2nd and 3rd proposal as well. I might already have said on the perfsonar list, 1st and 2nd proposals are designed from the point of view of a server developer.
From the client side, if the result codes are only expected to be displayed to the human users, and not triggering a client action, it doesn't really matter which proposal will be adopted.
If, on the other hand, an automatic client action is expected, then it is crucial to know if the reason of the failure is server side, or client side (e.g. client submitting wrong data , which can be fixed and resubmitted).
On the other hand, could we say: client can send anything and it's the matter of a service what is accepted. So in this case there are no server and client errors. Just errors. If a services does not support a request then it generates 'parse error' or 'unknown request error'. Well, also a valid point of view. More important is indeed how much information can be extracted from the error codes.
Regards, Nina
Roman
Best regards, Nina
Jeff W.Boote wrote:
Thanks Slawomir.
It would be great if people could either respond to this thread with their opinions on the proposed solutions, or be on the call/VC so we can come to some resolution on this topic.
thanks, jeff
On Jan 12, 2010, at 2:58 AM, Slawomir Trzaszczka wrote:
Hi all,
On Mon, 2010-01-11 at 20:01 -0500, Jason Zurawski wrote:
Hi Roman;
Thanks for the feedback, comments inline:
> some first comments/observations: > > - I think the structure of namespace could be explained > The original thinking was the NM-WG document, "An Extensible Schema for Network Measurement and Performance Data", would contain the entire explanation of namespaces (the idea itself coming from another OGF WG). Any future documents from related projects (NMC, NML, others?) would reference this and only note caveats to the original rule. The NM-WG doc is here:
https://forge.gridforum.org/sf/go/doc15649?nav=1
And I think namespaces are in section 4. Does everyone think this is sufficient, or should we consider other options?
> - example of status response in 4.1 does not explain too much > (looks the > same as earlier response example) > Now that things are in SVN, could you suggest a more fitting example?
> - in 4.3.2.6 the concept of key could be explained more (for me > the key > represents some bigger information structure; reasons: performance, > simplicity) > Good ideas, I will note these.
> - in 4.3.2.7 the reference to "Characteristic" document is missing > Good catch, I will add a real reference.
> - I'm wondering whether we can say in 4.3.3 that the request > with more > data triggers includes logical independent sub-requests > The concept of chaining is also something that Martin and I have struggled to find a proper location. Chaining is explained in sections 5 and 6 of the above NM-WG document currently. I think the basics should remain in NM-WG since the concept of the chain is essential to the definition of data and metadata. We may be able to reference the basic concept though to motivate some of the more unique cases.
> - 4.4.1: typo "request schema" > I will correct.
> - I would remove parameter elements "supportedEventType" from all > message examples. I understand that it's supported by the > implementations but it's agreed to use eventType element > I don't think this is a big deal, since these are just examples. I can remove them if we think it will cause confusion.
> - I think we have to rebuild Result Code section and finish the > discussion on new ideas proposed by Slawek and Jeff. That's very > important and must be done. > This would be the current venu to do so. Has Slawek updated his document based on the suggestions that were made before the holidays? Perhaps he can send it again?
Yes, file is in attachment
Regards,
Slawek
Thanks;
-jason
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
-- +--------------------------------------------+ Slawomir Trzaszczka
Poznan Supercomputing & Networking Center +--------------------------------------------+
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg _______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
Nina Jeliazkova wrote:
Roman Lapacz wrote:
Nina Jeliazkova wrote:
Roman Lapacz wrote:
I like second proposal which groups result codes according to functionalities. It's flexible because it works when e.g. a service acts as ma and mp. I would also add additional category which is not related with a functionality, for example when message parsing fails.
3th proposal is OK as well. Less preferable then 2nd but I'm fine with it if 3th will have more supporters.
Roman
I'm fine with 2nd and 3rd proposal as well. I might already have said on the perfsonar list, 1st and 2nd proposals are designed from the point of view of a server developer.
From the client side, if the result codes are only expected to be displayed to the human users, and not triggering a client action, it doesn't really matter which proposal will be adopted.
If, on the other hand, an automatic client action is expected, then it is crucial to know if the reason of the failure is server side, or client side (e.g. client submitting wrong data , which can be fixed and resubmitted).
On the other hand, could we say: client can send anything and it's the matter of a service what is accepted. So in this case there are no server and client errors. Just errors. If a services does not support a request then it generates 'parse error' or 'unknown request error'.
Well, also a valid point of view. More important is indeed how much information can be extracted from the error codes.
Just out of curiosity - was it considered before to make use of SOAP fault codes [ http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383492 ], instead of custom solution? (I can easily see one advantage of a custom solution, since error codes can now be associated with data/metadata entries ). Nina
Regards, Nina
Roman
Best regards, Nina
Jeff W.Boote wrote:
Thanks Slawomir.
It would be great if people could either respond to this thread with their opinions on the proposed solutions, or be on the call/VC so we can come to some resolution on this topic.
thanks, jeff
On Jan 12, 2010, at 2:58 AM, Slawomir Trzaszczka wrote:
Hi all,
On Mon, 2010-01-11 at 20:01 -0500, Jason Zurawski wrote:
> Hi Roman; > > Thanks for the feedback, comments inline: > > > > >> some first comments/observations: >> >> - I think the structure of namespace could be explained >> >> > The original thinking was the NM-WG document, "An Extensible > Schema for > Network Measurement and Performance Data", would contain the entire > explanation of namespaces (the idea itself coming from another > OGF WG). > Any future documents from related projects (NMC, NML, > others?) would > reference this and only note caveats to the original rule. The > NM-WG > doc is here: > > https://forge.gridforum.org/sf/go/doc15649?nav=1 > > And I think namespaces are in section 4. Does everyone think > this is > sufficient, or should we consider other options? > > > > >> - example of status response in 4.1 does not explain too much >> (looks the >> same as earlier response example) >> >> > Now that things are in SVN, could you suggest a more fitting > example? > > > > >> - in 4.3.2.6 the concept of key could be explained more (for me >> the key >> represents some bigger information structure; reasons: performance, >> simplicity) >> >> > Good ideas, I will note these. > > > > >> - in 4.3.2.7 the reference to "Characteristic" document is missing >> >> > Good catch, I will add a real reference. > > > > >> - I'm wondering whether we can say in 4.3.3 that the request >> with more >> data triggers includes logical independent sub-requests >> >> > The concept of chaining is also something that Martin and I have > struggled to find a proper location. Chaining is explained in > sections > 5 and 6 of the above NM-WG document currently. I think the basics > should remain in NM-WG since the concept of the chain is > essential to > the definition of data and metadata. We may be able to reference > the > basic concept though to motivate some of the more unique cases. > > > > >> - 4.4.1: typo "request schema" >> >> > I will correct. > > > > >> - I would remove parameter elements "supportedEventType" from all >> message examples. I understand that it's supported by the >> implementations but it's agreed to use eventType element >> >> > I don't think this is a big deal, since these are just examples. > I can > remove them if we think it will cause confusion. > > > > >> - I think we have to rebuild Result Code section and finish the >> discussion on new ideas proposed by Slawek and Jeff. That's very >> important and must be done. >> >> > This would be the current venu to do so. Has Slawek updated his > document based on the suggestions that were made before the > holidays? > Perhaps he can send it again? > > Yes, file is in attachment
Regards,
Slawek
> Thanks; > > -jason > > _______________________________________________ > Nmc-wg mailing list > Nmc-wg@ogf.org > http://www.ogf.org/mailman/listinfo/nmc-wg > > > -- +--------------------------------------------+ Slawomir Trzaszczka
Poznan Supercomputing & Networking Center +--------------------------------------------+
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg _______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
Jason Zurawski wrote:
The original thinking was the NM-WG document, "An Extensible Schema for Network Measurement and Performance Data", would contain the entire explanation of namespaces (the idea itself coming from another OGF WG). Any future documents from related projects (NMC, NML, others?) would reference this and only note caveats to the original rule. The NM-WG doc is here:
OK, now I see. So just the reference to namespace description is enough. Comparing those two docs I think we could describe xml elements the same way (now, one doc uses tables, the other one uses simple lists).
And I think namespaces are in section 4. Does everyone think this is sufficient, or should we consider other options?
- example of status response in 4.1 does not explain too much (looks the same as earlier response example)
Now that things are in SVN, could you suggest a more fitting example?
I'll take a close look here.
- I'm wondering whether we can say in 4.3.3 that the request with more data triggers includes logical independent sub-requests
The concept of chaining is also something that Martin and I have struggled to find a proper location. Chaining is explained in sections 5 and 6 of the above NM-WG document currently. I think the basics should remain in NM-WG since the concept of the chain is essential to the definition of data and metadata. We may be able to reference the basic concept though to motivate some of the more unique cases.
Agree. Main description in NM-WG doc and only the reference to it in NMC-WG doc (with some additional information related with NMC). This way we'll keep consistency. Now I see two names for the same thing: operation chaining (NM-WG doc) and filter chaining (NMC-WG doc). I'm also thinking that maybe filer chaining fits better into NMC-WG (it deals more with action than data/metadata representation).
- I would remove parameter elements "supportedEventType" from all message examples. I understand that it's supported by the implementations but it's agreed to use eventType element
I don't think this is a big deal, since these are just examples. I can remove them if we think it will cause confusion.
I would clean it. Roman
Roman & All; SVN is updated with your suggested changes, and I have added some comments in the tex files for items that are still outstanding.
- I'm wondering whether we can say in 4.3.3 that the request with more data triggers includes logical independent sub-requests
The concept of chaining is also something that Martin and I have struggled to find a proper location. Chaining is explained in sections 5 and 6 of the above NM-WG document currently. I think the basics should remain in NM-WG since the concept of the chain is essential to the definition of data and metadata. We may be able to reference the basic concept though to motivate some of the more unique cases.
Agree. Main description in NM-WG doc and only the reference to it in NMC-WG doc (with some additional information related with NMC). This way we'll keep consistency. Now I see two names for the same thing: operation chaining (NM-WG doc) and filter chaining (NMC-WG doc).
There may be some consistency problems since these were written at different times. Martin: what name where we going to stick with? I can make the changes to either document when we decide. -jason
I'm also thinking that maybe filer chaining fits better into NMC-WG (it deals more with action than data/metadata representation).
Hi Jason, On Jan 12, 2010, at 2:01 AM, Jason Zurawski wrote:
Hi Roman;
Thanks for the feedback, comments inline:
some first comments/observations:
- I think the structure of namespace could be explained
The original thinking was the NM-WG document, "An Extensible Schema for Network Measurement and Performance Data", would contain the entire explanation of namespaces (the idea itself coming from another OGF WG). Any future documents from related projects (NMC, NML, others?) would reference this and only note caveats to the original rule. The NM-WG doc is here:
https://forge.gridforum.org/sf/go/doc15649?nav=1
And I think namespaces are in section 4. Does everyone think this is sufficient, or should we consider other options?
The explanation of namespaces is clear to me. But I have a comment about EventTypes. In 3.1 and in 7.1 I understand that the EventyType in a metadata MUST appear only one time. But in the last example in 5.4 is showing two event types and it says that those "MAY NOT appear". I think it should say "MUST NOT appear" unless there are cases where it makes sense to allow two or more event types. Also, the section 5 was a little confuse to me. I see that metadata can be merged but I don't get how they should be merged. I read it again and I'll send comments and ideas about this. Regards -- Cándido Rodríguez Montes E-mail: candido.rodriguez@rediris.es Middleware warrior Tel:+34 955 05 66 13 Red.ES/RedIRIS Edificio CICA Avenida Reina Mercedes, s/n 41012 Sevilla SPAIN
Hi Candido;
- I think the structure of namespace could be explained
The original thinking was the NM-WG document, "An Extensible Schema for Network Measurement and Performance Data", would contain the entire explanation of namespaces (the idea itself coming from another OGF WG). Any future documents from related projects (NMC, NML, others?) would reference this and only note caveats to the original rule. The NM-WG doc is here:
https://forge.gridforum.org/sf/go/doc15649?nav=1
And I think namespaces are in section 4. Does everyone think this is sufficient, or should we consider other options?
The explanation of namespaces is clear to me. But I have a comment about EventTypes. In 3.1 and in 7.1 I understand that the EventyType in a metadata MUST appear only one time. But in the last example in 5.4 is showing two event types and it says that those "MAY NOT appear". I think it should say "MUST NOT appear" unless there are cases where it makes sense to allow two or more event types. Also, the section 5 was a little confuse to me. I see that metadata can be merged but I don't get how they should be merged. I read it again and I'll send comments and ideas about this.
I am a little lost in your explanation, there is not a section 3.1 in the NMC Base document, are you referring to the NM-WG document instead? Let me try to clear up the eventType explanation anyway: - multiple eventTypes in a single metadata are possible and common, e.g. something from the 'characteristic' namespace and the 'tool' namespace. An example would be SNMP data: http://ggf.org/ns/nmwg/tools/snmp/2.0 http://ggf.org/ns/nmwg/characteristic/utilization/2.0 - The example you are referring to (page 30 in the nmc doc I think?) is poorly worded. The situation I was trying to describe is merging metadata where the eventTypes are not compatible. In this case 'errors' is very different than 'utilization' and shouldn't be merged. I will place a note in this to clear this up down the road. Does this help a little bit? Chaining is a hard concept, and this represents my view of how it works. I may have some details wrong. I think that Martin, Jeff, and Roman should carefully read these sections to check my accuracy in describing things. Thanks; -jason
Hi Jason, On Jan 13, 2010, at 3:52 PM, Jason Zurawski wrote:
Hi Candido;
- I think the structure of namespace could be explained
The original thinking was the NM-WG document, "An Extensible Schema for Network Measurement and Performance Data", would contain the entire explanation of namespaces (the idea itself coming from another OGF WG). Any future documents from related projects (NMC, NML, others?) would reference this and only note caveats to the original rule. The NM- WG doc is here:
https://forge.gridforum.org/sf/go/doc15649?nav=1
And I think namespaces are in section 4. Does everyone think this is sufficient, or should we consider other options? The explanation of namespaces is clear to me. But I have a comment about EventTypes. In 3.1 and in 7.1 I understand that the EventyType in a metadata MUST appear only one time. But in the last example in 5.4 is showing two event types and it says that those "MAY NOT appear". I think it should say "MUST NOT appear" unless there are cases where it makes sense to allow two or more event types. Also, the section 5 was a little confuse to me. I see that metadata can be merged but I don't get how they should be merged. I read it again and I'll send comments and ideas about this.
I am a little lost in your explanation, there is not a section 3.1 in the NMC Base document, are you referring to the NM-WG document instead?
Yep, I'm sorry about this confusion. I'd printed both document and I brought the wrong one to home :(
Let me try to clear up the eventType explanation anyway:
- multiple eventTypes in a single metadata are possible and common, e.g. something from the 'characteristic' namespace and the 'tool' namespace. An example would be SNMP data:
http://ggf.org/ns/nmwg/tools/snmp/2.0 http://ggf.org/ns/nmwg/characteristic/utilization/2.0
Yes, I think it's very well explained in the nmc-base document. Maybe we can add a row in tables specifying if the element is multiple or not...
- The example you are referring to (page 30 in the nmc doc I think?) is poorly worded. The situation I was trying to describe is merging metadata where the eventTypes are not compatible. In this case 'errors' is very different than 'utilization' and shouldn't be merged. I will place a note in this to clear this up down the road.
Does this help a little bit?
Chaining is a hard concept, and this represents my view of how it works. I may have some details wrong. I think that Martin, Jeff, and Roman should carefully read these sections to check my accuracy in describing things.
I think it's clearer in the nmc-base document. However, if I've understood it well, the document explains some general rules about chaining but it's the service which decides how it will do it, isn't it? So, there isn't any standard (or automatic) way of doing? Also, there is a typo in the first line in 7.1.5.1. I cannot see the the whole value of the eventType. And about the event types hierarchy, I prefer the 2nd option. Regards
Thanks;
-jason
-- Cándido Rodríguez Montes E-mail: candido.rodriguez@rediris.es Middleware warrior Tel:+34 955 05 66 13 Red.ES/RedIRIS Edificio CICA Avenida Reina Mercedes, s/n 41012 Sevilla SPAIN
Hi Candido;
Let me try to clear up the eventType explanation anyway:
- multiple eventTypes in a single metadata are possible and common, e.g. something from the 'characteristic' namespace and the 'tool' namespace. An example would be SNMP data:
http://ggf.org/ns/nmwg/tools/snmp/2.0 http://ggf.org/ns/nmwg/characteristic/utilization/2.0
Yes, I think it's very well explained in the nmc-base document. Maybe we can add a row in tables specifying if the element is multiple or not...
Good idea, I will add this to the todo list(s).
- The example you are referring to (page 30 in the nmc doc I think?) is poorly worded. The situation I was trying to describe is merging metadata where the eventTypes are not compatible. In this case 'errors' is very different than 'utilization' and shouldn't be merged. I will place a note in this to clear this up down the road.
Does this help a little bit?
Chaining is a hard concept, and this represents my view of how it works. I may have some details wrong. I think that Martin, Jeff, and Roman should carefully read these sections to check my accuracy in describing things.
I think it's clearer in the nmc-base document. However, if I've understood it well, the document explains some general rules about chaining but it's the service which decides how it will do it, isn't it? So, there isn't any standard (or automatic) way of doing?
The procedures in place could vary from service to service, and a goal of this group should be to standardize the procedure so it is uniform. I have added TODO items regarding chaining so some of the original implementors and designers can talk and hopefully record things accurately.
Also, there is a typo in the first line in 7.1.5.1. I cannot see the the whole value of the eventType.
Fixed, thanks for finding this. -jason
participants (6)
-
Candido Rodriguez Montes -
Jason Zurawski -
Jeff W.Boote -
Nina Jeliazkova -
Roman Lapacz -
Slawomir Trzaszczka