Elwyn, thanks for your review. Richard, thanks for your response. I entered a No Objection ballot.
Alissa > On Mar 10, 2020, at 3:24 PM, Y. Richard Yang <y...@cs.yale.edu> wrote: > > Dear Elwyn, > > Thank you so much for the additional comment! Sure we will add the text, and > make clear on the nature and use of tag. It looks that the upload site is > opened again, and we will upload a new version as soon as it will not lead to > confusion of other reviews. > > Richard > > On Tue, Mar 10, 2020 at 11:51 AM elwynd <elw...@googlemail.com > <mailto:elw...@googlemail.com>> wrote: > Hi, Richard. > > Sorry I was a bit rushed last night and should have said a bit more. > > I think adding some text about how consistency is maintained would be a good > solution. As a non-expert in ALTO I was not really aware of the significance > of the tag field when I started readig the draft. Explaining the nature of > the tag field and making sure that it is clear that the old value of the tag > field in an update MUST match the value of the tag field as known by the > client as the key indicator of state consistency would be a considerable > improvement. > > Cheers, > Elwyn > > > > Sent from Samsung tablet. > > > -------- Original message -------- > From: "Y. Richard Yang" <y...@cs.yale.edu <mailto:y...@cs.yale.edu>> > Date: 10/03/2020 04:25 (GMT+00:00) > To: Elwyn Davies <elw...@dial.pipex.com <mailto:elw...@dial.pipex.com>> > Cc: alto@ietf.org <mailto:alto@ietf.org>, > draft-ietf-alto-incr-update-sse....@ietf.org > <mailto:draft-ietf-alto-incr-update-sse....@ietf.org>, gen-...@ietf.org > <mailto:gen-...@ietf.org>, last-c...@ietf.org <mailto:last-c...@ietf.org> > Subject: Re: Genart last call review of draft-ietf-alto-incr-update-sse-20 > > Dear Elwyn, > > Thanks a lot for the review! Please see inline below. > > On Mon, Mar 9, 2020 at 8:45 PM Elwyn Davies via Datatracker <nore...@ietf.org > <mailto:nore...@ietf.org>> wrote: > Reviewer: Elwyn Davies > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>>. > > Document: draft-ietf-alto-incr-update-sse-20 > Reviewer: Elwyn Davies > Review Date: 2020-03-09 > IETF LC End Date: 2020-03-06 > IESG Telechat date: 2020-03-12 > > Summary: > Almost ready. There are a few editorial issues, but I am not sure that > > Major issues: > I am unsure whether this mechanism is proof against loss of messages or > reordering of messags. Although there are state tags, it does not appear to > have any way to ensure that the state to which the updates will be applied in > the client are identical to the state that the updates were generated from. > If > I am wrong, it would be useful (IMO) to explain how the proposal avoids > getting > updates that don't apply to the state in the client. > > Good comment! A short answer is that the design should have no consistency > problems. > > More details: > > (1) This design is based on http/1.x as transport, which provides a single, > reliable, in-order serialization of update messages: m1, m2, m3, .... > The transport will guarantee that the messages will be delivered lossless, in > order. > > (2) One can consider that the messages consist of substreams (resources). > Each substream is total ordered as well. > > (3) The only remaining case is that substreams can have dependencies: for > example a cost map can depend on a network map. The design requires that the > updates to such dependencies are ordered correctly. > > One can see that the consistency model can be weakened: from total > serialization to causal consistency. We plan to design such a weaker (with > less head of line blocking of total order) using http/2. > > I like this comment. How about that we add a realized consistency model > paragraph in the overview? What do you think? > > > > Minor issues: > > Nits/editorial comments: > Abstract: the abstract is too long; I would suggest deleting the second > sentence of the first paragraph and the whole of the second paragraph. Ths > would leave sufficient information to explain what the document proposes but > omits the rationale which is not necessary for outlining the contents. The > deleted text would be usefully incorporated into s1. > > Okay. > > > > Abstract, para 3: s/s ction/section/ > > Thanks. Will fix. > > > > s1: The key role of Server-Sent Events in this proposal is not introduced > here > (and isn't mentioned in the Abstract). In the process SSE needs to be > expanded > on first use (currently right at the end of the section) and a pointer to the > document that defines SSE [SSE] > > Okay. > > > > s1, last para: The reference to Section 13 should come right at the end - and > the last two sections are (no longer) the last sectons: s/last two > sections/Sections 11 and 12/ > > Thanks a lot for identifying this. Will fix. > > > > s2 et seq: I am unsure of the rationale for defining a set of special terms > and > not capitalizing them on every occurrence. > > We feel that this is a style preference. We intended that the terms in Sec 2 > are like keywords of a book. Capitalizing them on each occurrence appears to > be a bit too much, for personal style. We prefer to keep this style, but do > agree that some other ALTO documents use all capitalization. > > > > s2: There is quite a lot of terminology imported from RFC 7285 . This should > be mentioned. > > Good catch. Will add a sentence at the beginning. > > > s3: A pointer to the SSE document would be useful [SSE]. > > Yes. Will do. > > > s3.4: It would be better to use the expanded form of SSE in the first > paragraph > rather than waiting till the 2nd para. > > Sure. Will do. > > > > s4: An explanation in advance of the format of the lines delineated by > **.... > ** would be desirable. > > Sure. > > > s5.1, next to last para: s/ So there is no ambiguous decoding/ So there is no > ambiguity when decoding/ > > Good revision and will do. > > > s5.1, last para: s/id/data-id/ > > Good catch, and will fix. > > > > s6.3, last para: s/will uses/will use/ > > Thanks. Will fix. > > > > s6,5, "incremental changes": s/Section Section6.3/Section 6.3/ > > Thanks. Will fix. > > > > s6.5, "remove": Stating that the client SHOULD ignore this if it present is > potentially problematic. If it is there it is a syntax error - should the > message be ignored and potentailly flagged as an error? > > The overall design strategy of alto is to ignore unknown fields to allow > incremental deployment—a kind of future proof of a future version by a legacy > old version. But in this case, I agree that it is a known error and it is a > good clarification. We will flag it as an error. > > > > s7.6, last para: s/our modular/the modular/ > > Thanks. Will fix. > > > > s13/s13.1:Empty sections are not desirable Please combine the two titles and > remove s13.1 . > > Okay. > > Thanks again! > > Richard > > > -- > -- > ===================================== > | Y. Richard Yang <y...@cs.yale.edu <mailto:y...@cs.yale.edu>> | > | Professor of Computer Science | > | http://www.cs.yale.edu/~yry/ <http://www.cs.yale.edu/~yry/> | > ===================================== > _______________________________________________ > Gen-art mailing list > gen-...@ietf.org <mailto:gen-...@ietf.org> > https://www.ietf.org/mailman/listinfo/gen-art > <https://www.ietf.org/mailman/listinfo/gen-art>
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
