Re: [alto] AD review of draft-ietf-alto-incr-update-sse-19

["Y. Richard Yang" <[e-mail]>]

Hi Mirja,

Thank you so much!

I had text on 5, 6, 7, but they were not moved to the new version. I will
handle shortening abstract, and clarify http/1.1 right after the last call.

Thanks again!
Richard

On Fri, Feb 21, 2020 at 6:02 AM Mirja Kuehlewind <[e-mail]>
wrote:

> Hi Richard,
>
> Thanks for the update! I just request IETF last call which should start
> today. You can still update the document but you might want to wait until
> the end of the IETF last call in order to also address potential last call
> comments (mainly be SECDIR, GENART, and OPSDIR reviews.)
>
> I believe there are also some small open points from my review (probably
> points 5, 6, and 7) which you might want to consider. And please also
> consider shortening the abstract. You can also look at Vijay’s summary in
> the shepherd-write as an example.
>
> One more editorial comment on the latest changes: Based on the intro text
> in section 3 and the title heading of section 3.3, I actual got confused if
> you proposed now to use HTTP/2. Maybe clarify early on in that section that
> HTTP/1.1. is used.
>
> Thanks!
> Mirja
>
>
>
> > On 21. Feb 2020, at 07:53, Y. Richard Yang <[e-mail]> wrote:
> >
> > Hi Mirja,
> >
> > We have submitted a new version. If you need to move on forward this
> week,
> > please use the submitted version. If you can do so by Monday morning,
> then
> > we plan to take a couple reads during this weekend.
> >
> > Your reviews helped greatly and we greatly appreciate them!
> >
> > Richard
> >
> > On Tue, Feb 18, 2020 at 6:46 PM Y. Richard Yang <[e-mail]> wrote:
> >
> >> Hi Mirja,
> >>
> >> I believe that we have a grasp of all of your feedback. We will submit
> in
> >> the next couple days, a new version directly to the data tracker, as you
> >> suggested.
> >>
> >> Thank you so much! Really appreciate it!
> >>
> >> Richard
> >>
> >> On Tue, Feb 18, 2020 at 4:32 AM Mirja Kuehlewind <[e-mail]>
> >> wrote:
> >>
> >>> Hi Richard,
> >>>
> >>> Please see inline.
> >>>
> >>>> On 17. Feb 2020, at 21:03, Y. Richard Yang <[e-mail]> wrote:
> >>>>
> >>>> Hi Mirja,
> >>>>
> >>>> Thanks a lot for the ultra-fast response. Please see below.
> >>>>
> >>>> On Mon, Feb 17, 2020 at 4:21 AM Mirja Kuehlewind <[e-mail]
> >
> >>> wrote:
> >>>> Hi Richard,
> >>>>
> >>>> Please see below.
> >>>>
> >>>>> On 17. Feb 2020, at 05:44, Y. Richard Yang <[e-mail]> wrote:
> >>>>>
> >>>>> Hi Mirja,
> >>>>>
> >>>>> Please see below.
> >>>>>
> >>>>> On Fri, Feb 14, 2020 at 4:32 PM Mirja Kuehlewind <
> [e-mail]>
> >>> wrote:
> >>>>> Hi authors,
> >>>>>
> >>>>> I reviewed draft-ietf-alto-incr-update-sse in order to potentially
> >>> get this document through the process before I step down as AD in
> March. I
> >>> have a couple of technical questions below that I would some feedback
> about
> >>> before we move on to IETF last call and some fully editorial point
> that can
> >>> be updated anytime before final publication (e.g. also after IETF last
> call
> >>> has ended).
> >>>>>
> >>>>> However, I have one high level question that I would like to at least
> >>> understand to justify it in the IESG before we moved on. Sorry that I
> have
> >>> not raised this earlier in the working group but I realised it just
> now:
> >>>>>
> >>>>> HTTP/2 (and HTTP/3) support multiplexing, why is a separate service
> >>> needed for stream control, instead of just using a different stream on
> the
> >>> same HTTP connection?
> >>>>> Also note that I don’t find the justification, why HTTP/2 Server Push
> >>> is not used, not very convincing and I’m afraid to get push-back from
> the
> >>> ART ADs. Especially given the problems describes in section 9.5.
> However,
> >>> we can give it a try. I think I would recommend to have the
> justification
> >>> in section 13.1 earlier in the document, e.g. in section 3.
> >>>>>
> >>>>>
> >>>>> We are indeed designing an ALTO incremental based on HTTP/2 (/3). For
> >>> now, we plan to clarify that the design is for earlier HTTP and move
> 13.1
> >>> to Sec. 3. How does this sound?
> >>>>
> >>>> It’s okay.
> >>>>
> >>>>
> >>>> However as you are already working on a design for HTTP/2 or HTTP/3,
> >>> would it be better to finish this work up now and specify it from the
> >>> beginning over this more modern protocols? Or is there a goos reason
> why
> >>> HTTP/1 support is needed?
> >>>>
> >>>> Thanks. We will finish this work now, for HTTP/1/1.1, as it is mostly
> >>> done and HTTP/1/1.1 is widely adopted. . HTTP/2 is definitely gaining
> >>> momentum (https://w3techs.com/technologies/details/ce-http2 states
> 43.3%
> >>> in Feb. 2020) and we will do the work during the next phase as soon as
> we
> >>> are done with this one.
> >>>
> >>> I don’t think that is a relevant number for alto because that's about
> >>> Webservers already offering http/2. And I would assume an alto server
> is
> >>> usually not co-located with another Webserver. For alto the most
> important
> >>> question would be if the http sever implementation you are using is
> >>> supporting http/2 and I think in terms of implementation most
> platforms do.
> >>> So if you run an alto server and want to use SSE with http/2 you need
> to be
> >>> willing to update you server; that’s it.
> >>>
> >>> Anyway, I think you need a bit more justification in the draft why this
> >>> is http/1.1 based.
> >>>
> >>>>
> >>>>
> >>>>>
> >>>>> And one more request before we move on, please add the actual
> >>> Content-Length values to the examples and confirm that you did run the
> >>> examples though a syntax checker!
> >>>>>
> >>>>>
> >>>>> Yes. All fixed.
> >>>>
> >>>> Thanks!
> >>>>
> >>>>>
> >>>>>
> >>>>> Here are my other technical questions/comments:
> >>>>>
> >>>>> 1) In section 3.2.1
> >>>>> "This document adopts
> >>>>>   the JSON merge patch message format to encode incremental changes,
> >>>>>   but uses a different HTTP method, i.e., it uses POST instead of
> >>>>>   PATCH.”
> >>>>> I don’t quite understand this sentence. As you use SSE, I guess you
> >>> are using neither POST nor PATCH. The point here is that SSE has a
> quite
> >>> different communication model than otherwise in HTTP, so I’m not sure
> what
> >>> this statement actually tells me.
> >>>>>
> >>>>>
> >>>>> Excellent review. We have revised the paragraph to be the following:
> >>>>>
> >>>>> "JSON merge patch is intended to allow applications to update server
> >>> resources by sending only incremental changes. <xref target="RFC7396"/>
> >>> defines the encoding of incremental changes (called JSON merge patch
> >>> objects)  to be used by the HTTP PATCH method <xref target="RFC5789"/>
>
> --
Richard