Re: [alto] Artart telechat review of draft-ietf-alto-multi-cost-08
"Randriamasy, Sabine (Nokia - FR/Nozay)" <sabine.randriamasy@nokia-bell-labs.com> Thu, 06 April 2017 09:44 UTC
Return-Path: <sabine.randriamasy@nokia-bell-labs.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 608651293E4; Thu, 6 Apr 2017 02:44:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.697
X-Spam-Level:
X-Spam-Status: No, score=-4.697 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.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 z9VMWphqXuoW; Thu, 6 Apr 2017 02:44:40 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10091.outbound.protection.outlook.com [40.107.1.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31040127B31; Thu, 6 Apr 2017 02:44:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ty2qw21hKkS5GMbsMLX9Z3oBZImmX/jsWU6KoM8POC0=; b=dyLBiXCDmuK+z1caEkf0UF52KkeXvEh+eUh3hEcBIF6oPAFwkwQeIyemT1sqsdmVug2vCIS10SMUcurAovgMqGkvxe7T3xSNXc+ANYb+O3aTK0TWCVxRu4FbtU71iHcpeFD3MadfkuirDZuvDACtW/NHisxRTJQPtQ/U8i5nrxo=
Received: from DB6PR0701MB2454.eurprd07.prod.outlook.com (10.168.75.147) by DB6PR0701MB2453.eurprd07.prod.outlook.com (10.168.75.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Thu, 6 Apr 2017 09:44:37 +0000
Received: from DB6PR0701MB2454.eurprd07.prod.outlook.com ([10.168.75.147]) by DB6PR0701MB2454.eurprd07.prod.outlook.com ([10.168.75.147]) with mapi id 15.01.1019.021; Thu, 6 Apr 2017 09:44:37 +0000
From: "Randriamasy, Sabine (Nokia - FR/Nozay)" <sabine.randriamasy@nokia-bell-labs.com>
To: Martin Thomson <martin.thomson@gmail.com>, "art@ietf.org" <art@ietf.org>
CC: "alto@ietf.org" <alto@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-alto-multi-cost.all@ietf.org" <draft-ietf-alto-multi-cost.all@ietf.org>
Thread-Topic: Artart telechat review of draft-ietf-alto-multi-cost-08
Thread-Index: AQHSrnqQeK8CFgpYuE64kjZYAubM4qG4F1CQ
Date: Thu, 06 Apr 2017 09:44:36 +0000
Message-ID: <DB6PR0701MB2454D5B2935448FFAE234C12950D0@DB6PR0701MB2454.eurprd07.prod.outlook.com>
References: <149144445494.22036.11923880719369865745@ietfa.amsl.com>
In-Reply-To: <149144445494.22036.11923880719369865745@ietfa.amsl.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nokia-bell-labs.com;
x-originating-ip: [135.245.212.27]
x-microsoft-exchange-diagnostics: 1; DB6PR0701MB2453; 7:Wbk6gNXKv+vaGMZHY3U2CdDSgoz8YqQx1XWNBQvezsFYanZBj3f23hleRVX3IuGcg2rvemjDob2Vo3BhM/qOegYpJJGVFytN83gmXEZbVcpr18xsFB3gXTQJQzn6QEu8OKksLfBJZnu2cd56NFBOJgJM0yMr9oXq325IWcaFDhyRrZivmnNYNMj2No7k0h4FolrEHhxnBchfFG9FtCBQKqfdGcVZCa1CP4q5EtB7hpHkJB+XTknu4xz4URC9e3Zcu1agm1zbDCUL2WpPnQtFAeAXTmKqDjj79VsXO0WwP4RC8wQBq5c6NtTFK0HsTkHjeNxw9nX/8O+gdPlpeZZjbw==
x-ms-office365-filtering-correlation-id: 27756a60-56e2-4099-c426-08d47cd189fe
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DB6PR0701MB2453;
x-microsoft-antispam-prvs: <DB6PR0701MB2453B83CF19950CD9944210F950D0@DB6PR0701MB2453.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:DB6PR0701MB2453; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2453;
x-forefront-prvs: 02698DF457
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39850400002)(39410400002)(39840400002)(39400400002)(39450400003)(13464003)(51444003)(377424004)(25786009)(8676002)(7696004)(39060400002)(38730400002)(54906002)(6246003)(8936002)(7736002)(77096006)(3660700001)(9686003)(55016002)(81166006)(305945005)(2501003)(74316002)(66066001)(4326008)(2950100002)(99286003)(229853002)(2900100001)(6436002)(76176999)(3846002)(6116002)(102836003)(86362001)(2906002)(50986999)(33656002)(5660300001)(3280700002)(230783001)(54356999)(122556002)(189998001)(53936002)(6506006)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2453; H:DB6PR0701MB2454.eurprd07.prod.outlook.com; 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-OriginatorOrg: nokia-bell-labs.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2017 09:44:36.9104 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2453
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/f9u6vqV12rOFqH22Ehfsix6tYCQ>
Subject: Re: [alto] Artart telechat review of draft-ietf-alto-multi-cost-08
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: Thu, 06 Apr 2017 09:44:43 -0000
Hello Martin, Thanks a lot for your review. The draft will be updated so as to address them. Best regards, Sabine >>-----Original Message----- >>From: Martin Thomson [mailto:martin.thomson@gmail.com] >>Sent: 06 April 2017 04:08 >>To: art@ietf.org >>Cc: alto@ietf.org; ietf@ietf.org; draft-ietf-alto-multi-cost.all@ietf.org >>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 >>a >> single request for an ALTO filtered cost map. It also defines improvements >> to the constraints that can be used for filtered cost maps. >> >>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 >>concise: >> >>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. >> >>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. >> >>The RFC 7285 section reference thing is unnecessary. >> >>This document doesn't cite RFC 2119, but it uses the keywords. >> >>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. >> >>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. >> >>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. >> >>Section 3.6.2 >> >>IMPORTANT: You don't define what happens when a client provides "or- >>constraints" >>and "constraints" at the same time. There are several valid options, but you >>need to choose. >> >>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 >>"constraints"/"or-constraints". >> >>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. >> >>Section 3.6.5 >> >>Uppercase for "must not" in the second paragraph. (The "may" later in the >>paragraph might be better as "can".) >> >>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? >> >>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. >> >>Can testable-cost-type-names be present and empty if cost-constraints is >>false? >>The first part of the definition permits that, the second forbids it. >> >>Section 4.1.2 >> >>The redefinition of PIDFilter is unnecessary. >> >>IMPORTANT: pids is optional in RFC 7285. Why the change? >> >>I find the redefinition of the optionality of cost-type to be worthy of special >>note. >> >>In the definition of "or-constraints", you use a "database query" >>where words >>would suffice. >> >>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. >> >>Section 4.2 contains mismatched braces/parens for section references. >> >>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 >>ReqEndpointCostMap. >> >>As before, repeating the definition of EndpointFilter is unnecessary. >> >>Section 4.2.3 - see comment on 4.1.3 >> >>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. >> >>It should be relatively easy to populate Content-Length now that the >>examples are "final". >> >>Section 5.1 >> >>You have unmatched braces in "meta" due to the comment. >> >>Section 5.2 >> >>Do you want to show one of the examples as having no cost values at all >>across all the cost types? >>
- Re: [alto] Artart telechat review of draft-ietf-a… Randriamasy, Sabine (Nokia - FR/Nozay)
- Re: [alto] Artart telechat review of draft-ietf-a… Randriamasy, Sabine (Nokia - FR/Nozay)
- Re: [alto] Artart telechat review of draft-ietf-a… Martin Thomson
- Re: [alto] Artart telechat review of draft-ietf-a… Randriamasy, Sabine (Nokia - FR/Nozay)
- [alto] Artart telechat review of draft-ietf-alto-… Martin Thomson
- Re: [alto] Artart telechat review of draft-ietf-a… Randriamasy, Sabine (Nokia - FR/Nozay)
- Re: [alto] Artart telechat review of draft-ietf-a… Mirja Kuehlewind (IETF)
- Re: [alto] Artart telechat review of draft-ietf-a… Martin Thomson
- Re: [alto] Artart telechat review of draft-ietf-a… Mirja Kuehlewind (IETF)