Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-alto-incr-update-sse-20

[Benjamin Kaduk <[e-mail]>]

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 <
> [e-mail]> 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