Open Grid Forum


Community Practice

Archived Comments



OGF Public Comments

Public comments are a very important part of the OGF document approval process.  Through public comments, documents are given scrutiny by people with a wide range of expertise and interests. Ideally, a OGF document will be self-contained, relying only on the other documents and standards it cites to be clear and useful.  Public comments of any type are welcomed, from small editorial comments to broader comments about the scope or merit of the proposed document.  The simple act of reading a document and providing a public comment that you read it and found it suitable for publication is very useful, and provides valuable feedback to the document authors.

Thank you for making public comments on this document!

Comments for Document: Network Services Framework
Author(s):J. Garcia-Espin, C. Guok. R. Krzywania, T. Kudoh, J. MacAuley, T. Miyamoto, I. Monga, G. Roberts, J. Sobieski, S. Soudan, J. Vollbrecht, F. Dijkstra, J. van der Ham
Public Comment End:24 Sep, 2010

To make anonymous comments, please use 'anonymous' and 'guest' as the un/pw.


Posted by: replogle 2010-08-24 11:07:22Initial Comments from J. van der Ham
Following comments provided by Jeroen van der Ham:

I have reviewed the Network Services Framework document, and I believe it is a fine document, that reflects what the group has decided on, and
provides a good framework for the coming work and documents.

I can't speak for the whole NML-WG, but my personal opinion is that the document is completely compatible with the goals and use of NML.

I do have some small remarks, mostly editorial:

The word "community" in the first sentence is italicized, and it shouldn't be.

Section 2.3 mentions a "NSI interface", which expands to a Network Service Interface interface, is that correct?

Just above Figure 6 is the line "Need more explanation of figure 6...", I assume that's fixed?

Figure 7 looks corrupted on the Mac version.

At the end of section 3.3 is a sentence with "serve as *a* both human readable".

In section 3.4 is a sentence ending in "[…], require temporal aspects to be understood and deterministic." I think I understand what it means, but it
is a strange way to say it.

Section 3.5 mentions four types of trust, but then only three are enumerated.

Section 4.1 uses "intra-network" and "Inter-Network" (and once "intra-Network"). Why the different capitalization, what does that mean?

Figure 9 should also include the meaning of the abbreviation SDP, and it should be mentioned in the text explaining figure 9 as well.

At the end of section 4.2.1 is an enumeration of STP instances, according to the way they are enumerated, there are only 45 of them, not 90.

Section 4.2.2 is titled Service Demarcation Point (fix capitalization there too?), but the section mentions SDPs only once. The section should at
least include the abbreviation, and perhaps some more wording about what it is and what it's for.
Figure 10 and accompanying text makes it unclear how grouping relates to SDPs, is a group an SDP, or is each pairing of STPs an SDP? Shouldn't it be
called an SDP group?

Posted by: hayashim 2010-08-26 03:48:45Authorization of transport resources
I want to express sincere congratulation to the accomplishment of this draft. I believe this achievement of NSI-WG is an important milestone not only for Grid but also for future Internet.
I have one small finding in the definition of NRM.

Clause 7 defines NRM as follows;
Network Resource Manager (NRM)
The Network Resource Manager owns a set of transport resources and has ultimate responsibility for authorizing and managing the use of these resources. Each NRM is always associated with a single NSA.

The intention of this is understandable, but the principle of authorizing transport resource and the relationship between authorization and NSI protocol cannot be understood from this framework document. I would like to see those description or assumption in clause 2 and 3.

Posted by: anonymous 2010-08-26 08:38:31Comments from Remco Poortinga - van Wijnen
I've gone through the document and found it easy to read and understand, which is very commendable; so thank you for that.

I have a few (minor) comments that I hope are helpful.

Section 2.7, page 7:
explanation is missing (as is indicated).
My implicit assumption here is that from a requestor NSA's view (so externally to a federated NSA), a federated NSA is indistinguishable from a non-federated NSA. Is this indeed the case? Otherwise NSA's should react differently depending on the type of NSA, which I think is not a good idea.

Figure 7 on page 8 is weird, looks like an invisible/white object is blocking out some lines?

Last paragraph on page 8 is somewhat confusing to me.
Section 2.3 at page 4 suggests that for every request a service instance is created (which I interpret as: a service instance represents a 'session' with a requester),
But page 8 says that a service instance may refer to a particular connection (for the connection service) or to a topology graph (for the topology distribution service). Suggesting that it is *not* always equal to a 'relation/session' with a requester?

At least this may mean that a service instance identifier is equal to a connection identifier? If a service instance is intended to act as a session then I think it is a bad idea to mix it/reuse it as a connection identifier.
If this is not the intention then maybe it is better to reword it to something like:
"Every service instance is typically associated with a single independent, uniquely identifiable deliverable unit as the service.
For example, an NSI connection service instance is associated with a particular connection, (...)".

Section 3.5, page 10:
The last type of trust: "Trust between attribute provider and policy server (attribute user)"
This terminology (attribute provider/user, policy server) are not introduced beforehand.
Wouldn't it be easier to say: 'Non-adjacent NSA-to-NSA relationship'? (I think that is what is meant here).

Section 3.6, page 10:
The definition of a soft or hard failure seems muddled.
Isn't the distinction that a failure that causes loss of state information is a hard failure (e.g. caused by reset), and
any other type is a soft failure (e.g. lost communication)?

Section 4.1, page 12:
Would a federated NSA belong to the 'intra-network topology' category, or the 'inter-network' one? The definition for an intra-network topology suggests that it doesn't apply to a federated NSA, while it may be useful in that case?

Figure 9, page 13: Mentions SDP (Service Demarcation Point?), but SDP is not described in the legend at the left.

Page 13, second to last paragraph: "From a global perspective, the use of the intra-network topology to aggregate detailed transport
topology within a Network object substantially reduces the size and complexity of the topology
information base."
'intra-network' should probably be 'inter-network' here?

As far as I'm concerned these are minor issues, nothing that a rewording can't solve I think. (and if my comments are unclear, please ask/contact me!)

> login   RSS RSS Contact Webmaster

OGFSM, Open Grid ForumSM, Grid ForumSM, and the OGF Logo are trademarks of OGF