[alto] Review of draft-ietf-alto-incr-update-sse-07

Jensen Zhang <jingxuan.n.zhang@gmail.com> Wed, 19 July 2017 17:47 UTC

Return-Path: <jingxuan.n.zhang@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 9FC331317BE; Wed, 19 Jul 2017 10:47:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 rOxye9qx7G-D; Wed, 19 Jul 2017 10:47:37 -0700 (PDT)
Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (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 B6B0B12F092; Wed, 19 Jul 2017 10:47:34 -0700 (PDT)
Received: by mail-ua0-x229.google.com with SMTP id u4so5281634uaa.1; Wed, 19 Jul 2017 10:47:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=cF25A7WO1s4sFIUpxEI9ybZOcl2HTZSTahUz8Q1vYls=; b=PUDHHZ5l21eGEobdOJH2AzsUefX7NLmC6h2Z4mOQWGohVGwWfi/ZCZBQq0E6oMU5Xe GGTHY97b5bsmxDUd8PNHOqb/Qd4tMA6qlLqzFSgv/Rwaaukrc3quFATdy7VaPhPa2ePn HPqxaMHqM2mHM1pMx+W1fnOlHYp2ufuJ27EaIVL/F7v8lqciWOklrMGmhzXnbFNo1/7v A6a/vkF2YlQYeIUmva1NFT+MYL8MCD6IpDLOHiYc70CLfpGeaOzK7ET1irTpg9wmh9OZ dvbZLDht9GAK6pCIC6yfb+ySwrEEqycX+1LEQT0VmkOPWgwsnUFXdDKkdPuRBCT3dU+U uw6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=cF25A7WO1s4sFIUpxEI9ybZOcl2HTZSTahUz8Q1vYls=; b=tjRv3lkCjTtU+IMhwUDbVBqY5DI0JJHVb/KpiuSMYTFrWt6jRubSAbO+mfooaKWKhY Q+/2YFdvYi6PEBWpO7HJx7+qRQhCAqQOe+kNJ91w3Ul4eYuSMFBGYkWkYVH6goCkcPVR jLFO8gO5w+RpCbMQ+tegQNByNls5JkzOxkC86+q/5lb75g6HlzhX7XoTEnyJVzrenfc3 1F6U4exIdBC35zt61oSplW24FyLmpzG7xExob9cXH1Uy/JRn+iL+qZQT89q8rBoQ/6ac 7yYyIWwGFT9rB9xkfgKaFejbHsW4MbFm18AZafliLBWQfv8NkXazU1S/3KpTydeRER/F D9Tg==
X-Gm-Message-State: AIVw112N6qQyy1/+Xf6DKBdZyX4YIIjCA7WIUzvFh8w1zeYL6CtDca3o 9pXZ0AWq/LdwLem8RR/gAOB4JeMyzg==
X-Received: by 10.176.67.163 with SMTP id l32mr576335ual.119.1500486453514; Wed, 19 Jul 2017 10:47:33 -0700 (PDT)
MIME-Version: 1.0
From: Jensen Zhang <jingxuan.n.zhang@gmail.com>
Date: Wed, 19 Jul 2017 17:47:22 +0000
Message-ID: <CAAbpuyqbwJLXAOLgthNhMsAy2YMg26LUJjZ-5vzftbKYecEWPg@mail.gmail.com>
To: IETF ALTO <alto@ietf.org>, draft-ietf-alto-incr-update-sse@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c095b800d55ca0554af3abd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/YSET7h8uN8hj84n2YcNhPBZGjuQ>
Subject: [alto] Review of draft-ietf-alto-incr-update-sse-07
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 19 Jul 2017 17:47:40 -0000

Document: draft-ietf-alto-incr-update-sse-07
Reviewer: Jensen Zhang

Summary: I have reviewed the latest update of this document. Overall, it is
well-written. I think It is almost ready to be last called once the
following points are addressed.

Comments:

Section 3., paragraph 0:

 3.  Terms

  This section is still empty. I feel the usage of some frequently
  appeared concepts (e.g. "update stream", "update stream resource",
  "update stream message", "update stream instance", etc.) is confusing
  and inconsistent. Authors can consider to define them precisely in
  this section.


Section 5., paragraph 2:

>    The building block of the update mechanism defined in this document
>    is update stream resources (defined in Section 7), where each update
>    stream resource (or update stream for short) is a POST-mode service

  Here introduced "update stream" as a new concept, but the definition
  may be inconsistent with the usage below.


Section 6., paragraph 1:

>    We now define the details of ALTO incremental update.  Specifically,
>    an update stream consists of a stream of update events (Section 6.2)

  update stream -> update stream message?  Because in Section 5,
  update stream is short for update stream resource.


Section 6.1., paragraph 1:

>    Update and control events have the same basic structure.  The data
>    field is a JSON object, and the event field contains the media type
>    of the data field, and an optional client id.  Update events use the
>    client id to identify the ALTO resource to which the update message
>    applies.  Client ids MUST follow the rules for ALTO ResourceIds (see
>    {10.2} of [RFC7285].  Client ids MUST be unique within an update
>    stream, but need not be globally unique.  For example, if a client

  The same problem as above. I think "update stream" indicates
  "update stream message" here.


Section 6.1., paragraph 7:

>    Note that an update stream does not use the SSE "id" field.

  The same problem as above.


Section 6.3., paragraph 3:

>    The "control-uri" field is the URI of the stream control resource for
>    this update stream (see Section 8).  The ALTO server MUST send a
>    control event with that URI as the first event in an update stream.

  The same problem as above.


Section 7., paragraph 2:

>    When a server creates a new update stream, it also creates a new
>    stream control service for that update stream.  A client uses the

  I think the two "update stream"s here mean "update stream instance"s.


Section 7., paragraph 3:

>    stream control service to remove resources from the update stream
>    instance, or to request updates for additional resources.  A client
>    cannot obtain the stream control service through the IRD.  Instead,
>    the first event that the server sends to the client has the URI for
>    the associated control service (see Section 6.3.

  Missing right parenthesis.


Section 7.3., paragraph 1:

>    An ALTO client specifies the parameters for the new update stream by

  update stream -> update stream instance.


Best,
Jensen