Re: [alto] Chair review of cost-calendar-13

"Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <sabine.randriamasy@nokia-bell-labs.com> Thu, 31 October 2019 16:21 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 F2C22120934; Thu, 31 Oct 2019 09:21:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 UlfhL28_JdzT; Thu, 31 Oct 2019 09:21:19 -0700 (PDT)
Received: from FRA01-MR2-obe.outbound.protection.outlook.com (mail-eopbgr90114.outbound.protection.outlook.com [40.107.9.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA7C31209B2; Thu, 31 Oct 2019 09:21:18 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g35TNSmi2+6aiCY4+ln3WeJMygZIrgQ1XzT5unvrWtsQPTf+k4qnKL9z1rxYCC1pWlOclfQv8wlR+7RQ602RSU92IBmwt8M0pu+RewNsQDNBNq9GrCmeyixGLGvIVWe9TtLSEfgJUyziyl1jKg92/16p//LlKbXzOxtQZGIqKt494rj0QdaVqw4vELM39EpWKRcHwvhRcTJGPEcnEUaPHObhx2NxF1JAPX1HdX/tok/nPai+F+9V4pdLfkfTOZPmP7MCAFfCg5CpukUj9mB5E4SewXBJo0lo+26/4C1ZvNvleVdXnBih8bIqLf0iNIJ3dc7Ea8z1PWIJrmRTPU+T7g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VNpuFT7nCaT3kHe7DOCg0VO/90t1QuWLLuydjyIVvbE=; b=DPRmwGmHxddvD8rI1HeIII13/h0iA3wAUCKMqEaWnPkKiqppVs3Pfbowui7jmiXJSriMD08oGVaFfHJEITbCyW6BEMG8Ss5RFGTjUZyPe6XX8dBpP5bPcia+sovdpb67QXLfSEhHSIp/hObPmS16j7+zVbL8VxMpWHcRuYV/fz0iMy6+MVGKMuYY/F+hVhjA+NIxsHHYeGpUOr7jgwfBYtM5WQblIMaVdZy7S3QKSfxuxJDHoowR6fN3zsov8oEDexD8HDA5kwXRnGCLm7Qv6drP84QV9YIIw2NE8Z5EyTJrz5BaI5sjIl73PR3tkbysU4vOT8XnX08hw68gUKSW+Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia-bell-labs.com; dmarc=pass action=none header.from=nokia-bell-labs.com; dkim=pass header.d=nokia-bell-labs.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VNpuFT7nCaT3kHe7DOCg0VO/90t1QuWLLuydjyIVvbE=; b=k1pRayinYGD1LOEN2G8h4ojjT2zvh/iv+uGZHwN+J3gHEcCmj9IcYzj7S7k6JJIwPYsf0NEpQMZg64iKiEa1tkr/lXL8aPTonCkexJMQWf2Vt1Kk3D3IbQ2ehLb3aZYDwB+Llnifn5pz8eik95XMfXgxS5BtLm4F3rAZaZo8Bj8=
Received: from PR1PR07MB5100.eurprd07.prod.outlook.com (20.177.209.144) by PR1PR07MB4906.eurprd07.prod.outlook.com (20.177.210.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.14; Thu, 31 Oct 2019 16:21:16 +0000
Received: from PR1PR07MB5100.eurprd07.prod.outlook.com ([fe80::dde5:ed04:dd7f:70f]) by PR1PR07MB5100.eurprd07.prod.outlook.com ([fe80::dde5:ed04:dd7f:70f%7]) with mapi id 15.20.2387.030; Thu, 31 Oct 2019 16:21:16 +0000
From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <sabine.randriamasy@nokia-bell-labs.com>
To: Vijay Gurbani <vijay.gurbani@gmail.com>, "draft-ietf-alto-cost-calendar@ietf.org" <draft-ietf-alto-cost-calendar@ietf.org>
CC: IETF ALTO <alto@ietf.org>
Thread-Topic: Chair review of cost-calendar-13
Thread-Index: AQHVj/ZBcAqghV9cAUGWsw4fREZu/ad05KUQ
Date: Thu, 31 Oct 2019 16:21:16 +0000
Message-ID: <PR1PR07MB5100C8EDC7C42FAFDA9D4BAC95630@PR1PR07MB5100.eurprd07.prod.outlook.com>
References: <CAMMTW_KvP4OvvxAZWrBPfGFqt3qccVsDQ7_ePFhYFw+CJeivDg@mail.gmail.com>
In-Reply-To: <CAMMTW_KvP4OvvxAZWrBPfGFqt3qccVsDQ7_ePFhYFw+CJeivDg@mail.gmail.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: [131.228.32.181]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: d9e2cf09-02c2-49f9-a310-08d75e1e5b16
x-ms-traffictypediagnostic: PR1PR07MB4906:
x-microsoft-antispam-prvs: <PR1PR07MB490685DF6BB37E036F74A35395630@PR1PR07MB4906.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-forefront-prvs: 02070414A1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(366004)(39860400002)(136003)(199004)(189003)(51444003)(86362001)(8676002)(186003)(81156014)(52536014)(26005)(229853002)(8936002)(33656002)(14454004)(256004)(102836004)(2501003)(81166006)(110136005)(71190400001)(14444005)(316002)(71200400001)(6506007)(53546011)(478600001)(7736002)(74316002)(3846002)(76176011)(66946007)(7696005)(6116002)(486006)(66556008)(6436002)(55016002)(790700001)(66476007)(64756008)(66446008)(446003)(11346002)(5660300002)(66066001)(2906002)(476003)(6246003)(25786009)(4326008)(76116006)(6306002)(99286004)(54896002)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:PR1PR07MB4906; H:PR1PR07MB5100.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
received-spf: None (protection.outlook.com: nokia-bell-labs.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: JM/9evpVkelYiu9ikO3bjHch2+kqmo6yPwSjd3xeF77wFv3ziZoDD1BplAIEiMX/5ZTSgVGucJJ39yusR1yB+/WIDL1hpVB7rdlEGoHaGZ7PhLiEZHYOmBwZNxPlVkEZWjku5d91YbPbD0qKxeSy2Mx7QAiOBvg0/fmzPgmvWlZFQYK0B+Kp0r1d04BuMN/O+/SHrI2En7kgQ8/h3JjJ/4wjMma+EQK6+lkmwPAhqOhOBNW4rJh9wjhnp/1P84lR8IwAG4wN603QAoEwhLrNoCEPK7vZrTqRLKRM6HURlRynDHxmCOWgUUwQiOmSufDg6wbFgNcSUaP3KEezca+OuzEUDJDUWw5idUFQmg5jgwEUjxQeiTpb1TRWPILeA1YR7LU62j48V5vRtzNJguwa8gfYnKKlT0hdpWJGS5WxNVgcqCabgALZAD0KAcfd2RAv
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_PR1PR07MB5100C8EDC7C42FAFDA9D4BAC95630PR1PR07MB5100eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia-bell-labs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d9e2cf09-02c2-49f9-a310-08d75e1e5b16
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2019 16:21:16.5595 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Vei7adjdjy+7FKGo5mtyc6fk18biLd6W+hj1c3xHeJpCCKVmKEWTBjz3lIWGvF1G+QFAx14ydWBEjD1aj3hMGcQJr0TBWPurYXNEKrvMMzKNyEEnywDDPEpPxb8xO5Dn
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR1PR07MB4906
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/iIRiaH3ysBzCdgOGOQEVWk7qjIk>
Subject: Re: [alto] Chair review of cost-calendar-13
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, 31 Oct 2019 16:21:29 -0000

Hi Vijay,

Great thanks for your thorough review and suggestions. Besides section 4.1.1, I will integrate them since they definitely improve clarity.
I can definitely upload a new version by next Monday.
Regarding comments on the MUST rule in section 4.1.1, I would prefer to keep the MUST rule for the following reason:

If a Calendar-aware client does NOT provide a boolean array “calendared<1..*>”, then, whether the resource has calendaring capabilities or not, the Server will return a non-Calendar aware response (i.e. single cost value) for all requested metrics.
If Client does provide “calendared<1..*>” to a non-Calendar aware ALTO server, the latter will ignore it and send a non-Calendar aware response.
So if the Client really wants calendars, it has to insert “calendared<1..*>”, with values set to ‘true’ for those metrics for which it wants a Calendar. This rule also covers the case where a Client does not want Calendars for all the calendared metrics in a resource.

Does this sound reasonable?

Thanks,
Sabine




From: Vijay Gurbani <vijay.gurbani@gmail.com>;
Sent: Thursday, October 31, 2019 3:22 PM
To: draft-ietf-alto-cost-calendar@ietf.org
Cc: IETF ALTO <alto@ietf.org>;
Subject: Chair review of cost-calendar-13

Dear Sabine: First of all, I must apologize for being the bottleneck on cost-calendar.  I appreciate your patience while I got to it.

I have reviewed the -13 version and I think we are good to go with minor edits as noted below.

I realize Mon is the cutoff date for I-Ds, so sorry for the late post of the edits.  But if you are able to spin a new version by Monday, I can move the work ahead.

Here are the comments, mostly editorial:

- S2.3: What is a "generic timezone"?  Is it UTC or GMT?  Later on, in S4 you
  state that the reference timezone is UTC.  Why not mention that in S2.3?
  Something like this:
     * time zone (in UTC),

- S2.4: s/to be light/to be lightweight/

- S2.4.2: s/That is a legacy/That is, a legacy/

- S3.1: s/lasts respectively 5 minutes and 2 hours./lasts 5 minutes and 2 hours,
  respectively./

- S3.3: '"string-servicestatus": refers to fictitious metric "servicestatus" in
  some example mode "string",', here what do you mean by "some example mode
  "string""?  "string" is not an example mode as much as it denotes a data
  type.  Perhaps you meant to say '"string-servicestatus": refers to a
  fictitious metric "servicestatus" containing a string to reflect...'

- S3.3: s/The design of the Calendar capabilities allows that some Calendars on
  a cost type name are available in several information resources with different
  Calendar Attributes./The design of the Calendar capabilities allows some
  Calendars with the same cost type name to be available in several information
  resources with  different Calendar Attributes./

- S4.1.1, second paragraph: The use of normative MUST is a bit puzzling.  There
  is certainly nothing that prevents a Calendar-aware ALTO client from not
  inserting the 'calendared' field if it chooses to.  (Perhaps it is talking to
  a non-Calendar aware ALTO server.)  I think that s/MUST/can/ is sufficient
  here, unless there is a specific reason on why a Calendar-aware ALTO client
  must always insert the 'calendared' parameter.  Is there?

  (The MUST NOT in the next paragraph is perfect, as it allows for backwards
  compatibility.)

- S8: "it should develop self-check", what exactly is meant here?  My suspicion
  is that you are trying to motivate the use of SSE here.  If that is the case,
  I would recommend that you re-write parts of the paragraph as follows:

  OLD:
  ...adapt and extend protection strategies specified in Section 15.2 of
  the base protocol: it should develop self-check and also ensure
  information update, to reduce the impact of this risk.  To address the
  risk of unexpected ALTO Values changes that the ALTO Client would be
  unaware of, it is RECOMMENDED that Servers supporting Calendars also
  support the "ALTO Incremental Updates Using Server-Sent Events (SSE)"
  Service, specified in [draft-ietf-alto-incr-update-sse].  Likewise, it
  is RECOMMENDED that  Clients using Calendars also support the
  SSE Service.

  NEW:
  ...adapt and extend protection strategies specified in Section 15.2 of
  the base protocol.  For example, to be notified immediately when a
  particular ALTO value that the client depends on changes, it is
  RECOMMENDED that both the ALTO Client and ALTO Server using this
  extension support "ALTO Incremental Updates Using Server-Sent Events
  (SSE)" Service [draft-ietf-alto-incr-update-sse].

Thanks again for your patience.

Cheers,

- vijay