[alto] Alexey Melnikov's No Objection on draft-ietf-alto-incr-update-sse-20: (with COMMENT)

Alexey Melnikov via Datatracker <noreply@ietf.org> Wed, 11 March 2020 16:49 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: alto@ietf.org
Delivered-To: alto@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED30A3A0D82; Wed, 11 Mar 2020 09:49:28 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alexey Melnikov via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-alto-incr-update-sse@ietf.org, alto-chairs@ietf.org, alto@ietf.org, Vijay Gurbani <vijay.gurbani@gmail.com>, vkg@bell-labs.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.120.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alexey Melnikov <aamelnikov@fastmail.fm>
Message-ID: <158394536893.1552.10301907415625043206@ietfa.amsl.com>
Date: Wed, 11 Mar 2020 09:49:28 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/wM5n5nosNkHGTAIwnpEe_yGuqSI>
Subject: [alto] Alexey Melnikov's No Objection on draft-ietf-alto-incr-update-sse-20: (with COMMENT)
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.29
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, 11 Mar 2020 16:49:30 -0000

Alexey Melnikov has entered the following ballot position for
draft-ietf-alto-incr-update-sse-20: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-alto-incr-update-sse/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for your document. It was generally a pleasure to read. I have a few
minor things that I would like to discuss before recommending approval of the
document:

5.3.  ALTO Control Update Message

   description:  a non-normative text providing an explanation for the
        control event.  When an update stream server stops sending data
        update messages for a resource, it is RECOMMENDED that the
        update stream server use the description field to provide
        details.

I think you should make it more explicit that this is human readable.

I am not going to insist on using language tags, because I don't think this is
going to work for messages generated by developers for developers.

6.7.1.  Event Sequence Requirements

   o  When the ALTO client uses the stream control service to stop
      updates for one or more resources (Section 7), the ALTO client
      MUST send a stream control request.  The update stream server MUST
      send a control update message whose "stopped" field has the
      substream-ids of all active resources.

"Active" or "stopped"? If the former, then the name of the field is misleading.
If the latter, than the above sentence needs to be corrected.

7.1.  URI

   The ALTO client MUST evaluate a non-absolute control URI (for
   example, a URI without a host, or with a relative path)

You might want to add a reference to RFC 3986 here, as it explains relevant
concepts.

   in the context of the URI used to create the update stream.

7.6.  Response

   If the request is valid but the associated update stream has been
   closed.  The stream control server MUST return an HTTP "404 Not
   Found".

I think you have 2 sentences where you really wanted to use 1. I.e, this should
read:

   If the request is valid but the associated update stream has been
   closed than the stream control server MUST return an HTTP "404 Not
   Found".

With recent IESG recommendations to always use encryption, I recommend you use
https:// instead of http:// URIs in examples.

Media Type registrations should use "[RFCXXXX]" or similar convention instead
of just saying "this document", because media type registrations are cut &
pasted to IANA website as separate documents.