[alto] Adam Roach's No Objection on draft-ietf-alto-cost-calendar-09: (with COMMENT)

Adam Roach <adam@nostrum.com> Thu, 29 November 2018 02:48 UTC

Return-Path: <adam@nostrum.com>
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 E612B126CB6; Wed, 28 Nov 2018 18:48:23 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach <adam@nostrum.com>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-alto-cost-calendar@ietf.org, Vijay Gurbani <vijay.gurbani@nokia.com>, alto-chairs@ietf.org, vijay.gurbani@nokia.com, alto@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154345970393.13521.17177728478340801020.idtracker@ietfa.amsl.com>
Date: Wed, 28 Nov 2018 18:48:23 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/ZAVfEw_6StRo5ZLFabFqPpD1B3c>
Subject: [alto] Adam Roach's No Objection on draft-ietf-alto-cost-calendar-09: (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: Thu, 29 Nov 2018 02:48:24 -0000

Adam Roach has entered the following ballot position for
draft-ietf-alto-cost-calendar-09: 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:


Thanks to everyone who worked on creating this extension. It seems useful, and
the document is easy to read. I have a handful of suggestions for improvement.



I found a surprising number of JSON errors in this document by casual
examination.  Those errors I found are called out below, but it is extremely
likely that I have missed some issues. Please run the JSON examples in this
document through a formal validation prior to publication.

With a reasonably modern version of nodejs, validation can be as simple as
something like:

node -e 'console.log(JSON.stringify(JSON.parse(`
    "meta" : {
      "cost-type" : {"cost-mode" : "numerical",
                     "cost-metric" : "routingcost"},
      "calendar-response-attributes" : [
        {"calendar-start-time" : Mon, 30 Jun 2014 00:00:00 GMT,
         "time-interval-size" : "1 hour",
         "number-of-intervals" : 24,
         "repeated": 4
    "endpoint-cost-map" : {
      "ipv4:": {
        "ipv4:"    : [v1, v2, ... v24],
        "ipv4:" : [v1, v2, ... v24],
        "ipv4:"  : [v1, v2, ... v24],
        "ipv6:2000::1:2345:6789:abcd" : [v1, v2, ... v24]

Running this example shows the first error in this example, involving the
date. After fixing that error, you will find the missing comma. And so on.



Please expand "ALTO" in the title, in the Abstract, and on first use in the body
of the document.



>  [RFC7285] ensures the availability of such a solution in its
>  Section 8.3.5.  "Authentication and Encryption", which specifies that
>  "ALTO server implementations as well as ALTO client implementations
>  MUST support the "https" URI scheme [RFC2818] and Transport Layer
>  Security (TLS) [RFC5246]".

Based on this guidance, I would encourage updating all instances of "http://" in
this document to instead be "https://". I count four such instances.



>  In this draft an "ALTO Cost Calendar" is specified by information
>  resources capabilities that are applicable to time-sensitive ALTO
>  metrics.  An ALTO Cost Calendar exposes ALTO Cost Values in JSON

Please cite RFC 8259.



>        "calendar-response-attributes" : [
>          "calendar-start-time" : Tue, 1 Jul 2014 13:00:00 GMT,
>          "time-interval-size" : "2 hour",

Nit: The value for calendar-start-time needs to be enclosed in quotation marks.

       "cost-map" : {
         "PID1": { "PID1": [v1,v2, ... v12],
                   "PID2": [v1,v2, ... v12],
                   "PID3": [v1,v2, ... v12] },
         "PID2": { "PID1": [v1,v2, ... v12],
                   "PID2": [v1,v2, ... v12],
                   "PID3": [v1,v2, ... v12] }

I don't quite follow this closely enough to understand what is intended here,
but the naked 'v1,v2' in the arrays are not valid JSON. Assuming these are
literal values, they need to each be enclosed in quotation marks.

Both of these comments apply to the examples given in §4.2.3 and §4.2.3 as



>       "ipv6:2000::1:2345:6789:abcd"

Please use an address from the range reserved by RFC 3489.

This comment applies to the example given in §4.2.4 as well.

>   }
>   "endpoint-cost-map" : {

There is a missing comma after the closing brace.



>     "calendar-response-attributes" : [
>       {"cost-type-name : num-routingcost"

Nit: This line is missing two quotation marks and a comma. It should be:

        {"cost-type-name" : "num-routingcost",