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|
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?
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.
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
'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!)