Re: [alto] Benjamin Kaduk's No Objection on draft-ietf-alto-cost-calendar-09: (with COMMENT)

"Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <sabine.randriamasy@nokia-bell-labs.com> Thu, 24 January 2019 14:15 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 6F4CC124C04; Thu, 24 Jan 2019 06:15:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.453
X-Spam-Level:
X-Spam-Status: No, score=-6.453 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 fIJoWy3mu4BT; Thu, 24 Jan 2019 06:15:56 -0800 (PST)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02on0721.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe05::721]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4E28124BE5; Thu, 24 Jan 2019 06:15:55 -0800 (PST)
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:X-MS-Exchange-SenderADCheck; bh=5eGQiWFJaxX4CbI9xBnni9ISR+Neo7FiohQ6DY85scU=; b=ew0QQA+rrrn0cBAzgcmA11mEjS+iZc/lIAQd5gpH5FDjnwss8r3fiZwuRFjRPple2+YvyHZBi87HhOAhBCqmTWaxtBOAxhOi20tYSvZLUwZXHPMmZ77s3RTkTNkaq5imXHMpyrOlU7wDcjqJ9KbpCgOo3GPh8XqB93QByP1Z+1w=
Received: from VI1PR07MB3247.eurprd07.prod.outlook.com (10.175.243.141) by VI1PR07MB4879.eurprd07.prod.outlook.com (20.177.200.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.11; Thu, 24 Jan 2019 14:15:29 +0000
Received: from VI1PR07MB3247.eurprd07.prod.outlook.com ([fe80::fc4d:1a0:4e11:8f5]) by VI1PR07MB3247.eurprd07.prod.outlook.com ([fe80::fc4d:1a0:4e11:8f5%5]) with mapi id 15.20.1580.004; Thu, 24 Jan 2019 14:15:29 +0000
From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <sabine.randriamasy@nokia-bell-labs.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "draft-ietf-alto-cost-calendar@ietf.org" <draft-ietf-alto-cost-calendar@ietf.org>, Vijay Gurbani <vijay.gurbani@gmail.com>, "alto-chairs@ietf.org" <alto-chairs@ietf.org>, "alto@ietf.org" <alto@ietf.org>
Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-alto-cost-calendar-09: (with COMMENT)
Thread-Index: AQHUjUUc6emPW2oRJk+Q4Dey2i6T4KWyLexQ
Date: Thu, 24 Jan 2019 14:15:29 +0000
Message-ID: <VI1PR07MB32470A6AF6F39546B1F7DD20959A0@VI1PR07MB3247.eurprd07.prod.outlook.com>
References: <154408810269.3321.15120210159742976150.idtracker@ietfa.amsl.com>
In-Reply-To: <154408810269.3321.15120210159742976150.idtracker@ietfa.amsl.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=sabine.randriamasy@nokia-bell-labs.com;
x-originating-ip: [135.245.212.89]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB4879; 6:NjlKzDg8CxaRbqy4UNJ8JHG3dW7PC2No6z5YdKnoxw6vo+SFm0DlIt0GFONYa2b70J8PzJWcBc9MiBBDAt9EXRN5IhuvQIvpOQ4N8kYBfpzt2wUbdqufsk25poRm+Ui3B4qqaug/MSOpBxf53cK7/jAp6seVM3DivKPZzu0djVnn34C7CrSxjfMQnclopxi58O3t+dBM1OHoK69bKFeFWImfxwKaot8rc2RQku1HHeC+NHNQFdQZ/0A570Hhy0AS9vL5vr1B3USZF2PwyiEyfKHWvJfepGEjpr4DjTO55dZloopAzjVMWFUKA432k7U+1lc2AugINsI5YXLugFzdsJnm6BddRSd+FQp2cytwjZAsUQnt7tPmOjkwxI3fhXWQMQUoAltRSJFPhJDitVljpTx1ehENdm9iipDiXJQvqULSIjpWx/MQtbidEDbK7ygmI1izDU+jf1z8XURRmF72kg==; 5:RTwqOmxzPDpRIkAALdvmvaNJids3I3gOBsHs7LHjpSgZ3WBOiKHBdRXTRqmy65eFsMIrRVm+YgT7guZDbAH4eoEWw+uIlZhYoLQ71/05s4NMHwQrpjc2XnzBhcM4e6iEpvdfctA23EsqmYwqudd7oXNHEW6VmgVs3H5SLXvm+4LpgC97hWcdOfgo4nK9WHwCuHVGj8wqgOgMzodch3kr5Q==; 7:KScxng6i5CxKaVPQbqE1tHLLBboR6RwI9gSfr8VbjB4gopgttKIAbA8xEVm0ytI9QwBiY8pUyIybwUT4kfKwSsiYJ2nDPCKNCL2yaSzCW03KXbYMmJxzlRCL2bBXcaNBvP0mTwk5DcBl7tb1bEjp8A==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: b3e4e44a-f9f6-4bc8-1147-08d6820664dd
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605077)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:VI1PR07MB4879;
x-ms-traffictypediagnostic: VI1PR07MB4879:
x-microsoft-antispam-prvs: <VI1PR07MB487929F3F21915A46A61FA6B959A0@VI1PR07MB4879.eurprd07.prod.outlook.com>
x-forefront-prvs: 0927AA37C7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(376002)(346002)(39860400002)(396003)(51914003)(13464003)(189003)(199004)(99286004)(86362001)(74316002)(7736002)(2171002)(478600001)(71200400001)(71190400001)(2906002)(6246003)(186003)(486006)(966005)(229853002)(3846002)(33656002)(446003)(11346002)(476003)(14454004)(6116002)(53936002)(305945005)(66066001)(8676002)(68736007)(54906003)(6436002)(110136005)(256004)(97736004)(4326008)(14444005)(5024004)(6306002)(53546011)(6506007)(76176011)(316002)(55016002)(9686003)(7696005)(8936002)(25786009)(39060400002)(105586002)(26005)(81156014)(81166006)(106356001)(102836004); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4879; H:VI1PR07MB3247.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0;
received-spf: None (protection.outlook.com: nokia-bell-labs.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 3+orryt+284oorpgxztuYpA6hORh24L9GC/lfGx6xkKLf2oTjnWZVPXGw2CKbDmFi6daOX74HmGK6IAcv1qT5YWRch2kZJr3YzuQfzRw8ZLt9rV7IP5Wx1Yh5e1cMvCAcZ7iP4rKbxe1Rho9YnUcKqbG7wE4aGF73sQn8mp/9nvL58ZYVPhgqeA4AwYeqStDaPsMuEBklOkJRenM0w64/nCy1GCF/LZN1HGRXK+D/ZTQrlhbhQKov6kSdcgaER/zVpx+mA5OBG6q9hL5rKtGO/VwSeBBKYxtPC7kbcrm3MWjzI9AKfuLqQelHZhDJzlBgsiBSn/yWL+gzX2V3R/vMU5xIEbwrI715e5JRE4nu6cH5Gnm7dxlAinstymXgzS8hX8NmuMi0477avrbzePfKiPTR8cZc7CZRDFQu5nttlI=
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-Network-Message-Id: b3e4e44a-f9f6-4bc8-1147-08d6820664dd
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2019 14:15:29.2087 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4879
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/YJhIF3TtRdN3mOkCw6ZVjxUl438>
Subject: Re: [alto] Benjamin Kaduk's No Objection on draft-ietf-alto-cost-calendar-09: (with COMMENT)
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.29
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, 24 Jan 2019 14:15:58 -0000

Hello Benjamin,

Thanks for your comments. A new version of this draft will be submitted and the updates hopefully addressing your comments. 
Please see inline for the responses.  
All the best for 2019,

Sabine


-----Original Message-----
From: Benjamin Kaduk <kaduk@mit.edu>; 
Sent: Thursday, December 06, 2018 10:22 AM
To: The IESG <iesg@ietf.org>;
Cc: draft-ietf-alto-cost-calendar@ietf.org; Gurbani, Vijay (Nokia - US/Naperville) <vijay.gurbani@nokia.onmicrosoft.com>;; alto-chairs@ietf.org; Gurbani, Vijay (Nokia - US/Naperville) <vijay.gurbani@nokia.onmicrosoft.com>;; alto@ietf.org
Subject: Benjamin Kaduk's No Objection on draft-ietf-alto-cost-calendar-09: (with COMMENT)

Benjamin Kaduk 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:
https://datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar/



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

Section 3.1

   The capabilities of a Calendar-aware information resource entry have
   a member named "calendar-attributes" which is an array of objects of
   type CalendarAttributes.  It is necessary to use an array because of
   resources such as Filtered Cost Map and Endpoint Cost Map, for which
   the member "cost-type-names" is an array of 1 or more values.

I don't really follow this argument.  Why does the value for "cost-type-names"
affect the structure of the containing "calendar-attributes"?
[[SR]] The wording is indeed unclear. It relates to a previous design where Attributes were explicitly attached to cost types. 
 Would the following update in 3.1 be OK?
- First paragraph of 3.1: 
" When for an applicable resource, an ALTO Server provides a Cost Calendar for a given Cost Type, it MUST indicate this in the IRD capabilities of this resource, by an object of type ’CalendarAttributes’, that associates one or more Cost Types with Calendar Attributes and is specified below. "
- 2nd paragraph (you quoted) of 3.1:
" The capabilities of a Calendar-aware information resource entry have a member named "calendar-attributes" which is an array of objects of type CalendarAttributes. Each CalendarAttributes object applies to a set of one or more Cost Types. Different Calendar Attributes may apply to different Cost Types supported by this resource. "

   An ALTO Client should assume that the time interval size specified in
   the IRD is the smallest possible one that the ALTO Server can
   provide.  The Client can aggregate cost values on its own if it needs
   a larger granularity.

Where is the normative requirement on the server to behave in this fashion?
[[SR]] Actually there is none. Maybe, we could instead write:
" it is RECOMMENDED  for an ALTO Server that the time interval size specified in the IRD is the smallest possible one that it can provide. The Client can aggregate cost values on its own if it needs a larger granularity."  

It's weird to use string packing for units instead of a separate structured element in the language/structure.

Section 4.1.1

   This field is an array of 1 to N boolean values, where N is the
   number of requested metrics.  Each boolean value indicates whether or
   not the ALTO Server should provide the values for this Cost Type as a
   calendar.  The array MUST contain exactly N boolean values, otherwise
   the server returns an error.

Is it a MUST requirement for the server to check?
[[SR]] Yes, otherwise the Server cannot understand for which Cost Type the Client wants a Calendar. 
Should we append this latter sentence to the paragraph you quoted? 


Section 4.2.2

   If the ALTO client provides member "calendared" in the input
   parameters with a value equal to 'true' for given requested Cost
   Types, the "meta" member of a Calendared Endpoint Cost response MUST
   include, for these Cost Types, the same additional member "calendar-
   response-attributes", as specified for the Filtered Cost Map Service.

On first reading I thought this was a requirement for data/value consistency between endpoint icost and filtered cost map service responses, but rereading it looks like it's just data structure reuse.
So maybe something like "the contents of which obey the same rules as for the Filtered Cost Map Service (Section 4.1.2)".
[[SR]] Would the following re-wording be ok?
"   If the ALTO client provides member "calendared" in the input
   parameters with a value equal to 'true' for given requested Cost
   Types, the "meta" member of a Calendared Endpoint Cost response MUST
   include, for these Cost Types, an additional member "calendar-
   response-attributes", the contents of which obey the same rules as for the Filtered Cost Map Service (Section 4.1.2)."

Section 6

Thanks for these well-thought-out security considerations; it's a pleasure to see.

With respect to the last paragraph's mention of how the provided future guidance can be wrong, is this going to be a scenario where it would be helpful for the client to be able to just ping the server to ask "you gave me this data yesterday and I just want to double-check that it's still fresh/correct"?  I don't see an obvious way in which this would be helpful (unless the size of the JSON responses are getting to be prohibitively large or something, I suppose), but I'm writing this on a plane so the risk of me missing something is higher even than its usual rate.
[[SR]] This will be addressed by: it is RECOMMENDED that Servers supporting calendars also support ALTO Incremental Updates
   Using Server-Sent Events (SSE)" service, specified in [draft-ietf-alto-incr-update-sse] and likewise, that Clients using Calendars also support the SSE service