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 <***@hotmail.com> wrote:
> Kerim:
>
> Thanks for the review. Fix soon.
>
> Thanks,
> Dawn
>
> ________________________________________
> From: alto <alto-***@ietf.org> on behalf of Kerim Gokarslan <
> ***@yale.edu>
> 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 <***@nokia.com<
> mailto:***@nokia.com>> 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 <***@cs.yale.edu<mailto:
> ***@cs.yale.edu>
> > <mailto:***@cs.yale.edu<mailto:***@cs.yale.edu>>> 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
> > <***@nokia..com <mailto:***@nokia.com<mailto:
> ***@nokia.com>>> 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
> > <***@nokia.com<mailto:***@nokia.com>
> <mailto:***@nokia.com<mailto:***@nokia.com>>
> > > <mailto:***@nokia.com<mailto:***@nokia.com
> >
> > <mailto:***@nokia.com<mailto:***@nokia.com>>>>
> 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
> > > > <***@nokia.com<mailto:***@nokia.com>
> > <mailto:***@nokia.com<mailto:***@nokia.com>>
> <mailto:***@nokia.com<mailto:***@nokia.com>
> > <mailto:***@nokia.com<mailto:***@nokia.com
> >>>
> > > <mailto:***@nokia.com<mailto:vijay.gurbani@
> nokia.com>
> > <mailto:***@nokia.com<mailto:***@nokia.com>>
> <mailto:***@nokia.com<mailto:***@nokia.com>
> > <mailto:***@nokia.com<mailto:***@nokia.com
> >>>>>
> > > 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 / ***@nokia.com<mailto:
> ***@nokia.com>
> > <mailto:***@nokia.com<mailto:***@nokia.com>>
> > > <mailto:***@nokia.com<mailto:vijay.gurbani@
> nokia.com>
> > <mailto:***@nokia.com<mailto:***@nokia.com
> >>>
> > > > <mailto:***@nokia.com<mailto:
> ***@nokia.com>
> > <mailto:***@nokia.com<mailto:***@nokia.com>>
> > <mailto:***@nokia.com<mailto:***@nokia.com>
> <mailto:***@nokia.com<mailto:***@nokia.com>>>>
> > > > Network Data Science, Nokia Networks
> > > > Calendar: http://goo.gl/x3Ogq
> > > >
> > > > _______________________________________________
> > > > alto mailing list
> > > > ***@ietf.org<mailto:***@ietf.org> <mailto:
> ***@ietf.<mailto:***@ietf.>.org>
> > <mailto:***@ietf.org<mailto:***@ietf.org> <mailto:
> ***@ietf.org<mailto:***@ietf.org>>>
> > <mailto:***@ietf.org<mailto:***@ietf.org> <mailto:
> ***@ietf.org<mailto:***@ietf.org>>
> > > <mailto:***@ietf.org<mailto:***@ietf.org> <mailto:
> ***@ietf.org<mailto:***@ietf.org>>>>
> > > > https://www.ietf.org/mailman/listinfo/alto
> > <https://www.ietf..org/mailman/listinfo/alto>
> > > >
> > > >
> > >
> > > - vijay
> > > --
> > > Vijay K. Gurbani / ***@nokia.com<mailto:
> ***@nokia.com>
> > <mailto:***@nokia.com<mailto:***@nokia.com>>
> > > <mailto:***@nokia.com<mailto:vijay.gurbani@
> nokia.com>
> > <mailto:***@nokia.com<mailto:***@nokia.com
> >>>
> > > Network Data Science, Nokia Networks
> > > Calendar: http://goo.gl/x3Ogq
> > >
> > >
> > >
> > > --
> > > --
> > > =====================================
> > > | Y. Richard Yang <***@cs.yale.edu<mailto:***@cs.yale.edu>
> <mailto:***@cs.yale.edu<mailto:***@cs.yale.edu>>
> > <mailto:***@cs.yale.edu<mailto:***@cs.yale.edu> <mailto:
> ***@cs.yale.edu<mailto:***@cs.yale.edu>>>> |
> > > | Professor of Computer Science |
> > > | http://www.cs.yale.edu/~yry/ |
> > > =====================================
> >
> > - vijay
> > --
> > Vijay K. Gurbani / ***@nokia.com<mailto:
> ***@nokia.com>
> > <mailto:***@nokia.com<mailto:***@nokia.com>>
> > Network Data Science, Nokia Networks
> > Calendar: http://goo.gl/x3Ogq
> >
> >
> >
> > --
> > --
> > =====================================
> > | Y. Richard Yang <***@cs.yale.edu<mailto:***@cs.yale..edu> <mailto:
> ***@cs.yale.edu<mailto:***@cs.yale.edu>>> |
> > | Professor of Computer Science |
> > | http://www.cs.yale.edu/~yry/ |
> > =====================================
> >
> > _______________________________________________
> > alto mailing list
> > ***@ietf.org<mailto:***@ietf.org> <mailto:***@ietf.org<mailto:a
> ***@ietf.org>>
> > https://www.ietf.org/mailman/listinfo/alto
> > <https://www.ietf.org/mailman/listinfo/alto>
> >
> >
>
> - vijay
> --
> Vijay K. Gurbani / ***@nokia.com<mailto:***@nokia.com>
> Network Data Science, Nokia Networks
> Calendar: http://goo.gl/x3Ogq
>
> _______________________________________________
> alto mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>