Suggestions for draft-ggf-ghpn-netserv-2
Dear all, FINALLY, I found the time to read the netservices draft. I know that this group has been working on the document for a long time, and so I'm really sorry that it took me so long. Now that I did, I have a question and some suggestions (mostly nits). My question is: an "advanced network reservation" service is mentioned in some places in this document. Where is this service specified? Is this one of the more concrete things that was originally contained in netservices-0 and was now removed? Then, where will it be contained - is a related document in the works? So here are my suggestions. Note that I'm not a native English speaker, so any English corrections may be wrong - it's all just my opinion, and I hope it helps!! legend: pg = page pa = paragraph l = line fig = figure # = remove => = replacement _WORD_ = update (inserted word, changed word, ..) "=====" marks content suggestions (as opposed to typos and such) pg 1, pa 1: repetition of "as such" pg 5 pa 1: "...various flows _THAT_ can be ..." pa 2: # of in "a few of feedback" pa 5: # "such as the NM-WG ..." (this information is already in the footnote!) # pg 5 pa 6, # pg 6 pa 1, 2, 3, 4 ... all this is a repetition of previous text! last pa: "two ways basically to" => "basically to ways..." "(2) NS _IS_ forming a Grid..." ===== pg 7 fig 3: I would change (b), as it doesn't reflect the horizontal nature of interactions at all - in fact, it looks quite vertical. There are no interactions between NS and grid services (or other NS's) shown. ====== pg 8 pa 3: remove "Etc." at the end or include it in the last sentence. last pa, l 1: I noticed "signalling" here - is this a British or American document? I guess it's the latter (i.e. you ought to have "signaling" here) - although there is quite a bit of British text in this document (e.g. the Network Monitoring Service section, 5.2.8). In any case, the spelling should be consistent - no problem with a spell checker :-) There's probably a grammatical singular/plural issue in the same sentence - "enable" refers to plural, but "is provided" doesn't... ====== My answer to the query outlined on pg 10 / 11 / 12: I would vote for option 4 (Franco's proposal). It seems like an "information service" would be something you query, and the information is not supposed to change all the time (things like the topology, and link capacities could go in there, I guess). I envision a monitoring service as an online tool that I can use to (for instance, manually) shift resources from one place to the other on-the-fly when I see that something goes wrong. Of course, the process could be automatic, but assuming about manual operation simplifies things in my opinion. If I were to manually run a Grid application, I'd first check the information service to guide my scheduling decision, then run it and keep checking the monitoring service to make updates while my application is active. ====== pg 14 pa 5 bullet 3: "it is clear _THAT_ monitoring..." pg 25 pa 2: there's a [?] reference. pg 26, pa 1, l 1: "_THE_ OGSA framework..." pg 27 pa 3: "It is clear that _THE_ Grid Service model share_S_ the same..." pa 4: "As mentioned earlier" => "Since" here, and "system: hence, it is..." => "system, it is ..." Reason: the statement that you're referring to is just in the previous sentence. So, it's like: "X. As mentioned earlier, X. Hence, Y." which is weird to me, but: "X. Since X, Y." might work. pa 5: "part-details" => "them" The last sentence of pg 27 made me smile. It is correct that abstraction enables us to build more complex systems - so maybe we should abandon abstraction in Grids, after all :-) Then, I had to laugh really hard because the very next sentence says: "Always strive for simplicity." Now this really sounds like a contradiction - we should use abstraction because it enables us to build really complex things and still use them, but at the same time, we should always strive for simplicity. Perhaps changing the word "build" would do the trick. What about "Abstraction enables us to utilize complex systems."... or something of that sort... pg 28 pa2: "services make_S_ it difficult..." pg 28 pa 4: I think that the last sentence ("An indication that one has defined...") is unclear. pa 5 l 1: "_THE_ structure of the implementation..." l 5: "document allow[#s] state information..." below: "Resuse" => "Reuse" Finally, I found it disturbing that most, but not all of the text is center justified - some pages, e.g. 25-28 are left justified. This should be changed to give the document are more homogeneous look. All in all, I found this a useful document but partially tough to read. I hope that this feedback is useful, cheers, Michael
Michael, I have gone through all your comments and would like to respond to some of them. In general, your comments are going into the right direction - for better organizing the structure and the layout of the document. That was the main motivation for revising this draft. Below are some specific comments.
My question is: an "advanced network reservation" service is mentioned in some places in this document. Where is this service specified? Is this one of the more concrete things that was originally contained in netservices-0 and was now removed? Then, where will it be contained - is a related document in the works?
This is open to discussion. In the current structure it is meant to be under the Section 5 - "Service Profiles".
# pg 5 pa 6, # pg 6 pa 1, 2, 3, 4 ... all this is a repetition of previous text!
Do you mean Section 2.1? If so, do you mean it should be deleted, shortened or rephrased? This text does sound a bit introductory, but it is definitely different from the intro itself. (or, I am missing the point.)
===== pg 7 fig 3: I would change (b), as it doesn't reflect the horizontal nature of interactions at all - in fact, it looks quite vertical. There are no interactions between NS and grid services (or other NS's) shown.
Maybe the Figure does not reflect the "horizontal" nature of the concept very well, but it is in my opinion needed as an alternative to the "vertical" paradigm of Grid-network interactions. Think of it as network running internally within the Grid service, e.g. such as virtualizing a distributed machine (over network).
====== My answer to the query outlined on pg 10 / 11 / 12: I would vote for option 4 (Franco's proposal). It seems like an "information service" would be something you query, and the information is not supposed to change all the time (things like the topology, and link capacities could go in there, I guess). I envision a monitoring service as an online tool that I can use to (for instance, manually) shift resources from one place to the other on-the-fly when I see that something goes wrong.
Of course, the process could be automatic, but assuming about manual operation simplifies things in my opinion. If I were to manually run a Grid application, I'd first check the information service to guide my scheduling decision, then run it and keep checking the monitoring service to make updates while my application is active. ======
I like the idea of coupling one service to the application lifetime (monitoring) and the other to the off-line analysis of the available resources (information). -- Admela
Hi,
# pg 5 pa 6, # pg 6 pa 1, 2, 3, 4 ... all this is a repetition of previous text!
Do you mean Section 2.1? If so, do you mean it should be deleted, shortened or rephrased? This text does sound a bit introductory, but it is definitely different from the intro itself. (or, I am missing the point.)
Yep, section 2.1. In the version I printed, the last paragraph on page 5 is exactly the same as the first paragraph on the same page, and the next four paragraphs (1-4 on page 6) are exactly the same as paragraphs 2-5 on page 5. It looks like a copy-one-paste-twice type of error to me :-)
pg 7 fig 3: I would change (b), as it doesn't reflect the horizontal nature of interactions at all - in fact, it looks quite vertical. There are no interactions between NS and grid services (or other NS's) shown.
Maybe the Figure does not reflect the "horizontal" nature of the concept very well, but it is in my opinion needed as an alternative to the "vertical" paradigm of Grid-network interactions. Think of it as network running internally within the Grid service, e.g. such as virtualizing a distributed machine (over network).
Absolutely! I definitely didn't mean to say that it should be removed!!! - but I think that it should be changed to show the horizontal aspect more clearly. Cheers, Michael
participants (3)
-
Admela Jukan -
Michael Welzl -
Michael Welzl