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

Mirja Kuehlewind <> Fri, 21 February 2020 11:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AACEF120219; Fri, 21 Feb 2020 03:02:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kZVe8DF5yFi0; Fri, 21 Feb 2020 03:01:58 -0800 (PST)
Received: from ( [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C92591200CD; Fri, 21 Feb 2020 03:01:57 -0800 (PST)
Received: from ([] helo=[]); authenticated by running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1j5649-0005jG-38; Fri, 21 Feb 2020 12:01:53 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <>
In-Reply-To: <>
Date: Fri, 21 Feb 2020 12:01:52 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: "Y. Richard Yang" <>
X-Mailer: Apple Mail (2.3445.104.11)
X-HE-SMSGID: 1j5649-0005jG-38
Archived-At: <>
Subject: Re: [alto] AD review of draft-ietf-alto-incr-update-sse-19
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Feb 2020 11:02:01 -0000

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.


> On 21. Feb 2020, at 07:53, Y. Richard Yang <> 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 <> 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 <>
>> wrote:
>>> Hi Richard,
>>> Please see inline.
>>>> On 17. Feb 2020, at 21:03, Y. Richard Yang <> 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 <>
>>> wrote:
>>>> Hi Richard,
>>>> Please see below.
>>>>> On 17. Feb 2020, at 05:44, Y. Richard Yang <> wrote:
>>>>> Hi Mirja,
>>>>> Please see below.
>>>>> On Fri, Feb 14, 2020 at 4:32 PM Mirja Kuehlewind <>
>>> 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 ( 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"/>