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

"Y. Richard Yang" <yry@cs.yale.edu> Thu, 19 March 2020 17:36 UTC

Return-Path: <yang.r.yang@gmail.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF05A3A0BD6; Thu, 19 Mar 2020 10:36:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.11
X-Spam-Level:
X-Spam-Status: No, score=-3.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktFhAH-iKepj; Thu, 19 Mar 2020 10:36:26 -0700 (PDT)
Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com [209.85.217.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79A103A0BB0; Thu, 19 Mar 2020 10:36:25 -0700 (PDT)
Received: by mail-vs1-f46.google.com with SMTP id p7so2204032vso.6; Thu, 19 Mar 2020 10:36:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oD328sSVEEm6VsBHLRX0ZZ6rbPAo/3+SdFTRCcyaSQs=; b=oFdBQbQ4ockTXknzRvPwlvFOOJAXXmkJwJC2ZELmktVZLMEsRGQqaHBWase9EQw3Y0 yt+CzHvlQ2u+a/zaQWjQx82KBDFfSu0FFB159GZMtsEqCFV6198qWcqfkI3TVrD1/NzT hn+Tm6U8wb7aX+IlYj7YSKZc8aHK3zzSm1dt9/k36g560v94i+qU1GxkWJg3BFeyV9B+ n67xD43YKq8RJU4YpstxvMeU6YVkWa/rH28LI/v0/bUaBR8+d9TNnjuinqMJPdB1xiLr J69Kw6dwyxXLL2tDca5hHaYFDK9pbqprfuYrwx31wskVKcSdW8q+Uxnr/fCR9zz0i+nm acNw==
X-Gm-Message-State: ANhLgQ0GhUig1MkBwdNty1nDnkZbzlzfW+gVSMZSNbwr55/SR5UayAtx Y90t4W7qyd2La2zTIfNFgTKb30Oea8gCBNr3+gg=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vucJXfB5C+GMugXlfsgQOPPe+KHGyZRvJqOqhjB?= =?utf-8?q?SdIBiHQkDaIkKSm7MSUva0TnxsHYozfyJITibo76lh213hs=3D?=
X-Received: by 2002:a05:6102:48d:: with SMTP id n13mr2842287vsa.102.1584639384363; Thu, 19 Mar 2020 10:36:24 -0700 (PDT)
MIME-Version: 1.0
References: <158380111093.5655.3828389409545643059@ietfa.amsl.com> <CANUuoLpCzwwWAtof+qhAcnY7c0qGOYDsPY-hdQ1rQo_pA0RMMQ@mail.gmail.com> <20200315040912.GB50174@kduck.mit.edu>
In-Reply-To: <20200315040912.GB50174@kduck.mit.edu>
From: "Y. Richard Yang" <yry@cs.yale.edu>
Date: Thu, 19 Mar 2020 13:36:13 -0400
Message-ID: <CANUuoLqL3uzpj+X8a4Jy58=7CUBd0TbTiOWtfr5awV7F6tXsCw@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Elwyn Davies <elwynd@dial.pipex.com>, alto@ietf.org, draft-ietf-alto-incr-update-sse.all@ietf.org, gen-art@ietf.org, last-call@ietf.org
Content-Type: multipart/alternative; boundary="0000000000009a264a05a1389b77"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/CBVyBqsNotiY4GKTBHztP1CFoCk>
Subject: Re: [alto] [Last-Call] Genart last call review of draft-ietf-alto-incr-update-sse-20
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Mar 2020 17:36:28 -0000

Hi Ben,

Just an update that we have submitted -21 and will upload -22 tomorrow (we
submitted -22 twice but somehow it did not post; we will take the
opportunity of waiting for one day to proofread the document and upload by
the end of Friday for you to check if the revision handles your review,
which is exceedingly valuable.

Richard

On Sun, Mar 15, 2020 at 12:09 AM Benjamin Kaduk <kaduk@mit.edu> wrote:

> 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@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>.
> > >
> > > 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
>
-- 
Richard