On Tue, Mar 10, 2020 at 12:25:12AM -0400, Y. Richard Yang wrote: > 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 < > noreply@xxxxxxxx> 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>. > > > > 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. I did not remember getting the impression that it was required to use HTTP/1.x transport with this specification, as I attempted to note in my ballot, SSE is not HTTP/1.x-specific. If the intent is to only allow the usage of HTTP/1.x with HTTP/2 (or HTTP/3) left to future work, I think that (e.g.) the end of Section 3.3 needs to be more explicit about this. -Ben -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
