RE: Artart telechat review of draft-ietf-alto-multi-cost-08

"Randriamasy, Sabine (Nokia - FR/Nozay)" <> Tue, 25 April 2017 17:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41FE31316D6; Tue, 25 Apr 2017 10:26:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z_GVWp4Riwbm; Tue, 25 Apr 2017 10:26:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A993C129AB2; Tue, 25 Apr 2017 10:26:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xrSNF8YSOouXuL+jyq4t1k3/OeIaRENSfwVWiYhZrA8=; b=YymU6rOlnl9lJ0zUTOo2j80qbrlZBpPsCle9IVwznqqgS+iiBeGu0GU0hha4HkxUTQL8uPNsAmTX0F4XGqy6z8EY2rRLN5314X13kiucfynCnmPxhE81Fx0/W74M5faXbglZhZ4lLQvaAT+NH2mCsiXb1sfQJG/a9wv2Wfemy9I=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6; Tue, 25 Apr 2017 17:26:40 +0000
Received: from ([]) by ([]) with mapi id 15.01.1061.011; Tue, 25 Apr 2017 17:26:40 +0000
From: "Randriamasy, Sabine (Nokia - FR/Nozay)" <>
To: Martin Thomson <>, "" <>
CC: "" <>, "" <>, "" <>
Subject: RE: Artart telechat review of draft-ietf-alto-multi-cost-08
Thread-Topic: Artart telechat review of draft-ietf-alto-multi-cost-08
Thread-Index: AQHSrnqQeK8CFgpYuE64kjZYAubM4qHWYMDg
Date: Tue, 25 Apr 2017 17:26:40 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: en-US
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; DB6PR0701MB2455; 7:1cBM0Up4I8Aer73/BhkQIv3yAD6n2ASwTylLjQluWHeaRDPNfcrHzusxbJXQFKmPrzrJrFCxArvodk3oemsp4BgwdqwFvqV+sK623Vx0vbMXMb24fmdi+g/wfCGdMckVAJEkNT4Iux0xPvULB9vOu2GW9rilBvERAbqAKx8efZDGhsBFn0ZdWrKFaA4L1JRLh50ZD6OtEW7yc8c3Nny0IsUhe9GN9CzBFpZ1OEgZ3AUyUpUcLp8so0q3f+gHhFypypTmYCjwdVtaPBbAKxT63jeBrQORxlebtcSSJrmPPsz6nBN+k0F2d3jAGpXg0FMi73D524iU2DMfMnO8qk9kSA==
x-ms-office365-filtering-correlation-id: 93ceb0cc-8dc0-4a4d-f14a-08d48c003c26
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DB6PR0701MB2455;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(120809045254105)(131327999870524);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148); SRVR:DB6PR0701MB2455; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2455;
x-forefront-prvs: 0288CD37D9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39840400002)(39450400003)(39850400002)(39400400002)(39410400002)(13464003)(51444003)(377424004)(2900100001)(6246003)(2501003)(38730400002)(6306002)(6436002)(54906002)(9686003)(189998001)(6506006)(106356001)(53936002)(230783001)(6116002)(3846002)(102836003)(66066001)(99286003)(55016002)(7696004)(3660700001)(122556002)(39060400002)(2950100002)(7736002)(50986999)(76176999)(54356999)(3280700002)(81166006)(2906002)(8936002)(25786009)(8676002)(4326008)(77096006)(74316002)(33656002)(305945005)(345774005)(5660300001)(229853002)(86362001)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2455;; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2017 17:26:40.0604 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2455
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Apr 2017 17:26:46 -0000

Hello Martin, 

First of all thank you for your thorough review and comments. 
A new version has been uploaded to address them and is available at 
I hope the updates address your questions. Please, let me know otherwise.

Please see also inline for my answers,

Best regards,

>>-----Original Message-----
>>From: Martin Thomson []
>>Sent: 06 April 2017 04:08
>>Subject: Artart telechat review of draft-ietf-alto-multi-cost-08
>>Reviewer: Martin Thomson
>>Review result: Ready with Issues
>>Document: draft-ietf-alto-multi-cost-08
>>Date: 2017-04-06
>>Reviewer: Martin Thomson
>>This document describes how ALTO can be used to acquire cost maps with
>>multiple cost metric instead of a single metric.
>>The document very carefully deals with backwards compatibility with existing
>>ALTO servers and clients.  I don't anticipate many issues arising from the
>>deployment of this protocol.
>>I started reading -07, but finished with -08.  I checked that the issues I raise
>>still exist, but I'm not infallible.  Apologies if I get something wrong.
>>Minor issues: I've identified a few issues that are more than nits, these are
>>marked "IMPORTANT" below.
>>The abstract includes considerable justificiation.  An abstract only needs to
>>describe the *what*, not the *why*.  Thus, what is there could be simplified
>>considerably, e.g.,
>>   This document defines a new method for retrieving multiple cost metrics in
>>   single request for an ALTO filtered cost map.  It also defines improvements
>>   to the constraints that can be used for filtered cost maps.

[SR     ]  OK. Abstract shortened in that direction
>>Section 1
>>The introduction uses a bunch of odd terms.  Some of these are recognizable
>>from the ALTO specification, but some of the jargon seems unnecessary.  In
>>particular, "Internet View", "Provider Network region" and "Vector costs".
>>All of which I think that I understand, but they make the doc hard to follow.
>>Generally, I found the introduction quite hard to follow, both for that reason
>>and structurally.  The introduction could be a lot shorter and more
>>1. ALTO defines multiple cost types (and more are being defined).
>>2. Clients sometimes consume multiple cost types.
>>3. Requesting multiple cost types at the same time is more efficient (for
>>   several reasons).
>>4. This document defines how to do that.
>>5. Separately, when multiple cost types are present, more sophisticated
>>   filtering can improve efficiency further.
>>6. This document defines how to do that too.
[SR     ] OK, section revised in that direction

>>Section 2
>>There are several items in the list here that are not used:
>>Application Client,
>>Network Service Provider, maybe more.  Please check and remove those
>>that don't apply.
[SR     ] OK: removed 3 definitions

>>The RFC 7285 section reference thing is unnecessary.
[SR     ] OK: moved to end of section 2, to avoid repeating "of [RFC7285]" too often.

>>This document doesn't cite RFC 2119, but it uses the keywords.
[SR     ] RFC 2119 is cited on page 1, section " Requirements Language" and section "9.1.  Normative References". Should it be referenced elsewhere? 

>>Section 3.1
>>The example shows an empty cost-type, but the schema you define allows it
>>to be absent.  You REALLY need to pick one.  I don't believe that this is a
>>compatibility issue: once you have determined that a client supports multi-
>>cost, then you can do anything you like, just be clear about it.
[SR     ] OK, added explanations before and after the example 
>>Section 3.2
>>I found the argument about the ease of writing a parser to be quite
>>unconvincing.  However, a new media type that is largely the same as the
>>existing media type won't necessarily result in code duplication.
>>Just say what it is you expect to happen and don't try to be apologetic about
>>it.  What you have appears to be a workable design.
[SR     ] OK, removed 1st paragraph.
>>Section 3.5
>>This section is confusing.  You only need to say that you are not altering full
>>cost map resources in any way and that clients need to use filtered cost maps
>>if they want multiple costs at the same time.  (Obviously you could have, but
>>creating multiple resources with the full combinatorial mess caused by
>>combining many cost types is unwieldy.)  At a minimum, the second
>>paragraph here can be removed.
[SR     ] OK shortened 2nd paragraph
>>Section 3.6.2
>>IMPORTANT: You don't define what happens when a client provides "or-
>>and "constraints" at the same time.  There are several valid options, but you
>>need to choose.
[SR     ] OK added text at the end on why a client cannot provide both
>>Section 3.6.3
>>It is probably worth explicitly noting that if "testable-cost-types"
>>does not
>>include values from "multi-cost-types", then those types can't be included in
[SR     ] OK added this after 1st paragraph
>>Please explain the default value for the index for the "constraints"/"or-
>>constraints" express in this section in addition to where it is hidden in a note
>>later in the document.
[SR     ] OK, moved text to example in section 5.4
>>Section 3.6.5
>>Uppercase for "must not" in the second paragraph.  (The "may" later in the
>>paragraph might be better as "can".)
[SR     ] OK, done. Also added an sentence in 1st paragraph to clarify it. 
>>In the example, the resource named "filtered-multicost-map" is provided for
>>legacy reasons only.  Why bother including "max-cost-types" and "cost-type-
>>names" at all when "filtered-cost-map-extended" includes all that and more?
[SR     ] OK, before example, added text explaining when it is useful to specify both. 
Actually, "cost-type-names" is always present in filtered cost map capabilities.
>>Section 4.1.1
>>The definition of the schema here (and later) actually redefines the object
>>completely.  I found that confusing initially.  It would be good to identify the
>>*changes* from the base specification somehow.
[SR     ] indeed. In RFC7285 {}, member "cost-constraints" is not optional in object specification but is optional in the member description. Added a sentence at the end of 1st paragraph stressing the presence of the 2 new member listed in the beginning of this paragraph. 
Also added some text in introduction of section 4, on the notations, in particular "<m..n>". 
>>Can testable-cost-type-names be present and empty if cost-constraints is
>>The first part of the definition permits that, the second forbids it.
[SR     ] The first part specifies member "testable-cost-type-names" as having "<1..*>" elements, if present.  
Added item to describe "cost-constraints" and moved text from "testable-cost-type-names" there. 
>>Section 4.1.2
>>The redefinition of PIDFilter is unnecessary.
[SR     ] OK, deleted
>>IMPORTANT: pids is optional in RFC 7285.  Why the change?
[SR     ] OK, corrected this, pids optional again. Thanks for catching this.
>>I find the redefinition of the optionality of cost-type to be worthy of special
[SR     ] OK, added sentence in definition of "cost-type" member
>>In the definition of "or-constraints", you use a "database query"
>>where words
>>would suffice.
[SR     ] OK, replaced "database query" with "words"
>>Section 4.1.3
>>I find the choice of value for "cost-type" to be problematic.  It is a string in the
>>base protocol, so changing to an empty object is likely to cause more issues
>>than simply omitting it.
[SR     ] Actually, "cost-type" is defined in {10.7} as an object unlike "cost-type-names" which is array of JSONString.
>>Section 4.2 contains mismatched braces/parens for section references.
[SR     ] OK, corrected
>>Section 4.2.2
>>IMPORTANT: This provides a definition for ReqFilteredCostMap that is very
>>different to that in the base specification.  I think that this should have been
[SR     ] OK, corrected this and replaced " ReqFilteredCostMap " with "ReqEndpointCostMap", thanks for catching this.
>>As before, repeating the definition of EndpointFilter is unnecessary.
[SR     ] OK deleted
>>Section 4.2.3 - see comment on 4.1.3
[SR     ] OK, please see my answer.
>>Section 5
>>I would be more comfortable if the examples used obviously-spurious
>>metrics (e.g., "cattle-head-count", "smell", "shoe-size", etc...) than these
>>metrics that are pretty plausible.  More so when you claim that they are
>>widely valued, which implies some sort of validity.
[SR     ] OK, replaced "hopcount" with "shoesize" and "bandwidthscore" with "sceneryrate" and adapted section introduction accordingly. 
>>It should be relatively easy to populate Content-Length now that the
>>examples are "final".
[SR     ] OK, done
>>Section 5.1
>>You have unmatched braces in "meta" due to the comment.
[SR     ] OK, corrected this. Also removed the comments in the IRD
>>Section 5.2
>>Do you want to show one of the examples as having no cost values at all
>>across all the cost types?
[SR     ] OK, updated text to say this only holds between PID2 and PID3