Dear WG, Here is my review of draft-ietf-alto-incr-update-sse-12. I didn’t see any major issues, but here are some short comments on grammatical/spelling/readability errors that I noticed throughout the paper.
-------------------- 1. Introduction -------------------- [comment about Kerim’s review] Page 4, paragraph 3, line 3: it should be ‘provides’ not ‘provide’, because the verb is describing ‘integrating’ Page 4, paragraph 4, sentence 2: We intend *that* the mechanism *can* also support new ALTO services -> We intend *for* the mechanism *to* also support new ALTO services Page 4, paragraph 4, line 6: need -> needs Page 4, paragraph 5, sentence 3: With the background, -> Following the background, ------------ 3. Terms ------------ Page 5, paragraph 4, sentence 1: … and sent … -> … and is sent … Page 5, paragraph 4, sentence 2: can be either a full-replacement or an incremental-change message -> can be either a full-replacement *message* or an incremental-change message Page 5, paragraph 4, sentence 3: Full replacement is a shorthand for a *full replacement* message … -> Full replacement is a shorthand for a *full-replacement* message Page 6, paragraph 2, sentence 1: update stream, is -> update stream is (unnecessary comma) Page 6, paragraph 2, sentence 1: notify the client *on* -> notify the client *of* Page 6, paragraph 2, sentence 3: notify the client *on* -> notify the client *of* Page 6, paragraph 3, sentence 1: to request addition or removal -> to request *the *addition or removal Page 6, paragraph 4: Updatea Strem Control Service -> Update Stream Control Service (spelling error) ------------------- 4. Background ------------------- Page 6, section 4.1, paragraph 2, sentence 2: to the server*,* and keeps the connection open -> to the server and keeps the connection open (unnecessary comma) Page 7, figure 1, last line: should either be ‘goodbye’ or ‘good-bye’, not ‘good bye’ Page 9, paragraph 1, sentence 1: patch and a demonstration of the feasibility to apply JSON merge patch -> patch and *as* a demonstration of the feasibility *of applying *JSON merge patch Page 10, sentence 1: Applying the merge patch update to the initial network map is equivalent to the following ALTO network map -> Applying the merge patch update to the initial network map gives something equivalent to the following ALTO network map Page 10, section 4.2.2.2, sentence 2: Assume *is* a simple example -> Assume a simple example Page 11, last sentence after the example: is equivalent to -> gives something equivalent to Page 12, paragraph 1, sentence 3: When the change is to make a small change to an array -> When making a small change to an array Page 12, paragraph 1, line 9: as JSON merge patch processing algorithm -> as *the *JSON merge patch processing algorithm Page 12, section 4.3.2, sentence 1: both as examples of JSON patch and demonstration of difference -> both as examples of JSON patch and *as a *demonstration of *the *difference Page 14, top example: I believe it should be “op”: “add” instead of “op”: “replace” for defining PID3->PID3 as 1 --------------------------------- 5. Overview of Approach --------------------------------- Page 14, paragraph 3, sentence 2: the update stream services*,* and declares -> the update stream services and declares (unnecessary comma) Page 15, paragraph 3, line 5: one resource*,* and is sent -> one resource and is sent (unnecessary comma) Page 15, paragraph 3, sentence 4: encoded either as a full replacement or an incremental change -> encoded either as a full replacement or *as *an incremental change Page 15, paragraph 4, line 4: shutdown -> shut down -------------------------------------------------------------------------------------- 6. Update Messages: Data Update and Control Update Messages -------------------------------------------------------------------------------------- Page 16, section 6.1, sentence 1: Data update and control update messages -> Data update *messages* and control update messages Page 16, section 6.1, line 3: the data field*, *and an optional -> the data field and an optional (unnecessary comma) Page 18, paragraph 1, sentence 2: that the server starts data update messages -> that the server *will start sending* data update messages ---------------------------------- 7. Update Stream Service ---------------------------------- There is an excessive use of commas in this section, which makes it harder to understand. Page 19, paragraph 1, sentence 1: wants updates*,* and has -> wants updates and has (unnecessary comma) Page 19, paragraph 1, sentence 2: each such resource*, *and -> each such resource and (unnecessary comma) Page 19, paragraph 2, sentence 2: error response*,* and -> error response and (unnecessary comma) Page 19, paragraph 3, sentence 1: ALTO resource*, *and -> ALTO resource and (unnecessary comma) Page 19, paragraph 3, sentence 2: error response*,* and MUST -> error response and MUST (unnecessary comma) Page 20, paragraph 4, sentence 1: control requests*, *and is -> control requests and is (unnecessary comma) Page 20, paragraph 4, sentence 2: error response*,* and MUST -> error response and MUST (unnecessary comma) Page 21, section 7.5, sentence 2: server can always send -> *the *server can always send Page 22, section 7.6.2, paragraph 4, sentence 2: after the data update messages -> after *sending *the data update messages -------------------------------------------- 8. Update Stream Control Service -------------------------------------------- Page 24, paragraph 2, sentence 1: update stream instance*, *and will -> update stream instance and will (unnecessary comma) Page 25, section 8.6, sentence 2: ALTO error code*, *and MUST NOT -> ALTO error code and MUST NOT (unnecessary comma) ---------------- 9. Examples ---------------- Page 28, section 9.2, paragraph 1, line 10: Thus server -> Thus*, the *server Page 29, sentence 1: After sending those events immediately -> After immediately sending those events Page 29, sentence 2: the cost map*, *PID1->PID2 is -> the cost map*. *PID1->PID2 is Page 30, paragraph 2, line 2: *a* ipv4 prefix -> *an *ipv4 prefix Page 30, paragraph 2, line 4: the network map*, *and send -> the network map and send Page 31, section 9.3, line 3: “routingcost” cost map*,* and provides -> “routingcost” cost map and provides (unnecessary comma) Page 34, line 2: are stopped*, *and -> are stopped and (unnecessary comma) Page 34, section 9.4, line 2: set of endpoints*, *and -> set of endpoints and (unnecessary comma) ---------------------------------------------------------------------- 10. Client Actions When Receiving Update Messages ---------------------------------------------------------------------- Page 38, paragraph 2, sentence 2: There are at least two ways a client can do that. -> There are at least two ways a client can avoid making this mistake. Page 39, paragraph 2, line 2: in a buffer*, *and continue -> in a buffer and continue (unnecessary comma) Page 39, paragraph 3, line 3: temporarily invalid*, *and -> temporarily invalid and (unnecessary comma) Page 39, paragraph 4, line 6: resources*, *and give -> resources and give (unnecessary comma) ------------------------------------------------- 11. Design Decisions and Discussions ------------------------------------------------- Page 40, paragraph 2, line 2: Server Push item*, *and -> Server Push item and (unnecessary comma) Page 40, paragraph 5, line 2: optional*, *and -> optional and (unnecessary comma) Page 41, paragraph 2, line 1: drop connections*, *and will -> drop connections and will (unnecessary comma) Page 41, paragraph 4, line 5: *c*ost maps -> *C*ost maps (capitalization error) --------------------------------------------- 12. Miscellaneous Considerations --------------------------------------------- Page 43, section 12.3, paragraph 1, line 6: and Client -> and *the *Client ------------------------------------ 13. Security Considerations ------------------------------------ Page 44, paragraph 1, line 5: of active streams*, *and -> of active streams and (unnecessary comma) Cheers, Isabelle Carson On Tue, Jul 3, 2018 at 10:09 PM, Dawn Chan <[email protected]> wrote: > Kerim: > > Thanks for the review. Fix soon. > > Thanks, > Dawn > > ________________________________________ > From: alto <[email protected]> on behalf of Kerim Gokarslan < > [email protected]> > Sent: Wednesday, July 4, 2018 2:21:26 AM > To: Vijay K. Gurbani > Cc: IETF ALTO > Subject: Re: [alto] WGLC for draft-ietf-alto-incr-update-sse-11 > > Dear Vijay and WG, > > I finished reviewing the draft-ietf-alto-incr-update-ssef document > (version 12). I think the language of the document and the design is clean > and complete. I didn't see any major technical issue (or design errors) but > I marked some small issues like spelling and punctuation errors, which can > be seen as 'nits'. > > > Page 4, Paragraph 3, Line 3: provides -> provide (noun is plural) > > Page 4, Paragraph 4, Line 6: satsify -> satisfy (spelling) > > Page 6, Paragraph 2, Line 7: sends -> send > > Page 6, Paragraph 2, Line 1: Update Stream Control (spelling) > > Page 12, Section 4.3.1, Line 1: the difference (missing the) > > Page 15, Paragraph 3, Line 6: An data -> a data > > Page 15, Paragraph 4, Line 1: A update -> an update > > Page 15, Paragraph 4, Line 2: life time -> lifetime > > Page 17, Last Paragraph, Line 3: an URI -> a URI > > Page 26, Section 9.1 Paragraph 3, Line 1: Also note -> Also, note (missing > comma) > > Page 28, Section 9.2 Paragraph 1, Line 10: Thus server -> Thus, server > (missing comma) > > Page 30, Paragraph 2, Line 2: a ipv4 -> an ipv4 > > Page 40, Paragraph 2, Line 3: Unfortunately there -> Unfortunately, there > (missing comma) > > Page 42, Paragraph 1, Line 2: First consider -> First, consider (missing > comma) > > Page 42, Section 11.4 Paragraph 1, Line 7: extention -> extension > (spelling) > > Page 42, Section 12.1: I think the first paragraph is a little confusing, > maybe the idea can be specified more explicit. > > Page 44, Paragraph 3, Line 1: Alternatively an -> Alternatively, an > (missing comma) > > Regards, > Kerim Gokarslan > > > On Mon, Jul 2, 2018 at 3:43 PM, Vijay K. Gurbani <[email protected]< > mailto:[email protected]>> wrote: > Kerim: Great, thanks a lot for volunteering. > > Please post your review on the WG email list. > > I suspect that you are getting acquainted with IETF processes; in that > vein, here's some quick advice that I hope will help you as you perform > a WGLC. > > A WGLC covers the entire I-D, you can point out anything in the draft > that you feel needs to be improved. Generally speaking, every reviewer > has their own style of performing WGLC reviews, you can see some > examples here [1, 2]. However, all reviews should include issues that > are 'major' (needs attention of author AND WG to moving the work ahead), > minor (may only need the attention of author to clarify things), and > 'nits' (needs attention of authors only). It is okay if one or more of > these categories is empty, however, due diligence must be done to ensure > that there were indeed no issues to raise under that particular category. > > [1] https://www.ietf.org/mail-archive/web/alto/current/msg03581.html > [2] https://www.ietf.org/mail-archive/web/alto/current/msg03513.html > > Cheers, > > On 07/02/2018 05:30 PM, Kerim Gokarslan wrote: > > Hi Vijay, > > > > I talked with Richard and I would like to help with a review. > > > > Regards, > > Kerim Gokarslan > > > > On Mon, Jul 2, 2018 at 3:12 PM, Y. Richard Yang <[email protected]<mailto: > [email protected]> > > <mailto:[email protected]<mailto:[email protected]>>> wrote: > > > > Dear WG, > > > > The authors have gone ahead to fix the coupling issue between update > > stream and stream control. To allow the community to read what the > > document reads like, we have uploaded the newer version, which can > > be found at: > > https://datatracker.ietf.org/doc/draft-ietf-alto-incr-update-sse/ > > <https://datatracker.ietf.org/doc/draft-ietf-alto-incr-update-sse/> > > Please see version 12. > > > > It is a much cleaner, modular, complete design. Last-call feedbacks, > > of course, are still highly appreciated and the authors will update > > as soon as possible, to improve on reactiveness. > > > > Thanks a lot! > > Richard > > > > > > On Mon, Jul 2, 2018 at 11:09 AM Vijay K. Gurbani > > <[email protected] <mailto:[email protected]<mailto: > [email protected]>>> wrote: > > > > Richard, one of them must provide a WGLC review for the draft. > > The WG > > must to due diligence through dedicated reviews to ensure that > > the work > > reflects the consensus of the WG. > > > > I will like to see new members to start contributing to the WG, > > as such > > while my preference would be for Danny to review the draft and > > post WGLC > > comments, I will leave it to the WG members to decide who will > > review it. > > > > I was hesitant to ask Sabine and Jensen since, in all fairness, > they > > have done their share of reviews and comments over the years. I > > iterate, it would be great if other members of the WG step up to > > move > > the work ahead. > > > > >From a process point of view, I realize that the cutoff is > > today so I am > > expecting that we will not be in time to submit a version. > However, > > that is fine as long as we have a WGLC on the currently > > submitted draft > > by the time we have our meeting on Monday, Jul-16. > > > > After the meeting, I can do the proto-writeup and move the work > > ahead. > > > > Cheers, > > > > On 07/02/2018 09:46 AM, Y. Richard Yang wrote: > > > Vijay, > > > > > > The ideas that I posted were discussed with Sabine, Jensen, > > and Danny, > > > who are not co-authors of the document. > > > > > > I assume that they are busy today, as 8 pm ET today is IETF > draft > > > deadline. Maybe they can help with our review tomorrow (July > > 3) or the > > > day after tomorrow (July 4), before the close :-) > > > > > > Thanks! > > > Richard > > > > > > > > > > > > On Mon, Jul 2, 2018 at 9:34 AM Vijay K. Gurbani > > <[email protected]<mailto:[email protected]> > <mailto:[email protected]<mailto:[email protected]>> > > > <mailto:[email protected]<mailto:[email protected] > > > > <mailto:[email protected]<mailto:[email protected]>>>> > wrote: > > > > > > Folks: Following up on Richard's email, we need a > > dedicated WGLC review > > > for SSE from the WG. Jan and I will like to invite at > > least one person > > > who is not an author to volunteer to review the draft as > > part of WGLC. > > > > > > Thus far, besides Richard's email, there has not been any > > review or > > > comments on the draft since it was released for WGLC. We > > will need to > > > be more proactive as a WG to move pending work ahead. > > > > > > Please send me and Jan a message on whether you are able > > to perform a > > > review of the draft in short order so we can move it ahead > > > expeditiously.. > > > > > > Thank you, > > > > > > On 07/01/2018 10:32 PM, Y. Richard Yang wrote: > > > > Dear WG, > > > > > > > > Thanks a lot for those who already sent comments to the > > authors! As an > > > > important service, this document can benefit from > > in-depth reviews, as > > > > Vijay pointed out. > > > > > > > > The main substantive comment so far is on clarifying the > > coupling > > > > between the Update Stream Service (USS), which will be > > used by the > > > > network to send SSE Update Messages to a client, and the > > Update Stream > > > > Control Service (USCS), which will be used by the client > to > > > control the > > > > server, by sending add/remove of resources messages. In > > the current > > > > design, SSE update messages can provide the final > > outcome of a control > > > > request. The comment was whether this is a generic > design. > > > > > > > > After extensive discussions among the authors, we > > propose to make the > > > > following revisions---these revisions will be simple and > > clean, and if > > > > approved by the WG, they can be updated right away: > > > > > > > > M1. The document clarifies that USS uses a *modular* > > design, in > > > that the > > > > Update Stream Service (USS) is a modular service. Hence, > > it can be > > > > controlled by not only USCS but also other potential > > control channels, > > > > such as a private control protocol. Hence, the messaging > > of USS, in > > > > particular, its Control Update Messages, should be > > (slightly) > > > revised to > > > > reflect this spirit. > > > > > > > > M2. The document clarifies that USS uses a > > self-contained design, to > > > > take advantage that current design can be simply, > elegantly > > > extended to > > > > also report error updates. > > > > > > > > The authors request that the WG approve these edits so > > that the > > > authors > > > > can proceed to submit a revision shortly, in just a > > couple days. > > > > > > > > Of course, the authors will also wait for other > > comments, until > > > the July > > > > 4th closing, to make a single, coherent edit. > > > > > > > > Thank you so much! > > > > Richard > > > > > > > > On Wed, Jun 20, 2018 at 11:21 AM Vijay K. Gurbani > > > > <[email protected]<mailto:[email protected]> > > <mailto:[email protected]<mailto:[email protected]>> > <mailto:[email protected]<mailto:[email protected]> > > <mailto:[email protected]<mailto:[email protected] > >>> > > > <mailto:[email protected]<mailto:vijay.gurbani@ > nokia.com> > > <mailto:[email protected]<mailto:[email protected]>> > <mailto:[email protected]<mailto:[email protected]> > > <mailto:[email protected]<mailto:[email protected] > >>>>> > > > wrote: > > > > > > > > All: This email announces the WGLC for SSE [1]; the > > WGLC runs > > > from Wed, > > > > Jun 20, 2018 to Wed, Jul 4, 2018. > > > > > > > > We will like the community members to perform an > > in-depth > > > review of the > > > > draft and post their comments, concerns or approval > > to the > > > mailing list > > > > during this period, even if it is one liner > > expressing support for > > > > moving the draft ahead. > > > > > > > > [1] > > https://tools.ietf..org/html/draft-ietf-alto-incr-update-sse-11< > https://tools.ietf.org/html/draft-ietf-alto-incr-update-sse-11> > > <https://tools.ietf.org/html/draft-ietf-alto-incr-update-sse-11> > > > > > > > > Thank you, > > > > > > > > - vijay > > > > -- > > > > Vijay K. Gurbani / [email protected]<mailto: > [email protected]> > > <mailto:[email protected]<mailto:[email protected]>> > > > <mailto:[email protected]<mailto:vijay.gurbani@ > nokia.com> > > <mailto:[email protected]<mailto:[email protected] > >>> > > > > <mailto:[email protected]<mailto: > [email protected]> > > <mailto:[email protected]<mailto:[email protected]>> > > <mailto:[email protected]<mailto:[email protected]> > <mailto:[email protected]<mailto:[email protected]>>>> > > > > Network Data Science, Nokia Networks > > > > Calendar: http://goo.gl/x3Ogq > > > > > > > > _______________________________________________ > > > > alto mailing list > > > > [email protected]<mailto:[email protected]> <mailto: > alto@ietf.<mailto:alto@ietf.>.org> > > <mailto:[email protected]<mailto:[email protected]> <mailto: > [email protected]<mailto:[email protected]>>> > > <mailto:[email protected]<mailto:[email protected]> <mailto: > [email protected]<mailto:[email protected]>> > > > <mailto:[email protected]<mailto:[email protected]> <mailto: > [email protected]<mailto:[email protected]>>>> > > > > https://www.ietf.org/mailman/listinfo/alto > > <https://www.ietf..org/mailman/listinfo/alto> > > > > > > > > > > > > > > - vijay > > > -- > > > Vijay K. Gurbani / [email protected]<mailto: > [email protected]> > > <mailto:[email protected]<mailto:[email protected]>> > > > <mailto:[email protected]<mailto:vijay.gurbani@ > nokia.com> > > <mailto:[email protected]<mailto:[email protected] > >>> > > > Network Data Science, Nokia Networks > > > Calendar: http://goo.gl/x3Ogq > > > > > > > > > > > > -- > > > -- > > > ===================================== > > > | Y. Richard Yang <[email protected]<mailto:[email protected]> > <mailto:[email protected]<mailto:[email protected]>> > > <mailto:[email protected]<mailto:[email protected]> <mailto: > [email protected]<mailto:[email protected]>>>> | > > > | Professor of Computer Science | > > > | http://www.cs.yale.edu/~yry/ | > > > ===================================== > > > > - vijay > > -- > > Vijay K. Gurbani / [email protected]<mailto: > [email protected]> > > <mailto:[email protected]<mailto:[email protected]>> > > Network Data Science, Nokia Networks > > Calendar: http://goo.gl/x3Ogq > > > > > > > > -- > > -- > > ===================================== > > | Y. Richard Yang <[email protected]<mailto:[email protected]> <mailto: > [email protected]<mailto:[email protected]>>> | > > | Professor of Computer Science | > > | http://www.cs.yale.edu/~yry/ | > > ===================================== > > > > _______________________________________________ > > alto mailing list > > [email protected]<mailto:[email protected]> <mailto:[email protected]<mailto:a > [email protected]>> > > https://www.ietf.org/mailman/listinfo/alto > > <https://www.ietf.org/mailman/listinfo/alto> > > > > > > - vijay > -- > Vijay K. Gurbani / [email protected]<mailto:[email protected]> > Network Data Science, Nokia Networks > Calendar: http://goo.gl/x3Ogq > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
