Re: [alto] Chair review of unified-props (Part 2 of 2)
"Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <sabine.randriamasy@nokia-bell-labs.com> Fri, 12 March 2021 19:18 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 EF9633A1C23; Fri, 12 Mar 2021 11:18:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.146
X-Spam-Level:
X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 z8caAYm2DBnf; Fri, 12 Mar 2021 11:18:16 -0800 (PST)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on071c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::71c]) (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 C286D3A1C0D; Fri, 12 Mar 2021 11:18:15 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DLdfaoHOPoORvQXa9XW8gSxU6eSWVnm7Ol6nSmSS1JJBww8Yk/R6M/pZXHYCOl89g99pVaVfdcVENPslDonTvXaO/G9hOlC5eZ5tbg5+dhEfVlWE2WCS/en4pxcQQLjemm6qfLVO4L0bURHvQHkaNFccShfvOxaiforOvPKM1uO0CFiPmaVRR4EG7spCKdMlklmDVjr8gHg1AydlLviLwN9ALEY2lrEwJCBAXHu8JWwpBIRsnkGHY1bRmmhR3heJ2BdtWnJrZJyRu7RxCiaJbWqjYRWLCaIDtSK9r4lowMDzPECD8N59UB3FHxw9eduTJV0+/giOlUMtuvUqY9GHiw==
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=U2kaxhBg7O5Azvm6aFt+7YrVFbhA4rMGb/es11a6Zbo=; b=mhfs3yJVT0qPOYK5gYu/ogjOQvziJpaxFxPrt+m+jOCdcTHaH2jzKJupQWIdy8R6S1P8DKSYXxjdFxRDJtyLH+lGeZl6kxVaj1i2ahpwbuE3jPCZjRMAxTuNjDQa3yfB5PNWdzKgEghbeVMUa0af14gbqWzAZwfGHqX22b196bg6eUS0eZyZwbIL6LQPJCGRIxKxN8wjVxRsY4e67oMr3lV0Nkkl/5yxihTyZVXzm63yXYhSa3FMPP6fShNjt1qW/Pu1oxwid90rjR7rH/pB4K2tYWKxyVXalAhyICxuiEv0t9SHopPH/Prd9YhwLG4FZ41AmFTm1elQYzHGQg26YQ==
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=U2kaxhBg7O5Azvm6aFt+7YrVFbhA4rMGb/es11a6Zbo=; b=sFlaE04kI6jWdOhCHlb6mvevgvmac9ugRXdpDuyBBACF8YVly82KU6HVI89UL62QLa3OL2vufUL7dMOLI3yYkESzqo7gwS8NNqiy50DqH3J/8H8PFP5X7ZeGPGdIAhqelPaEjiLnUKjiqlREiXuH/f5NXjb+Y56vIWOt7N4k5Uc=
Received: from PR3PR07MB7018.eurprd07.prod.outlook.com (2603:10a6:102:7d::13) by PA4PR07MB7615.eurprd07.prod.outlook.com (2603:10a6:102:cd::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.10; Fri, 12 Mar 2021 19:17:52 +0000
Received: from PR3PR07MB7018.eurprd07.prod.outlook.com ([fe80::9d49:f9dd:e65d:51a7]) by PR3PR07MB7018.eurprd07.prod.outlook.com ([fe80::9d49:f9dd:e65d:51a7%7]) with mapi id 15.20.3912.031; Fri, 12 Mar 2021 19:17:52 +0000
From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <sabine.randriamasy@nokia-bell-labs.com>
To: Vijay Gurbani <vijay.gurbani@gmail.com>, "draft-ietf-alto-unified-props-new@ietf.org" <draft-ietf-alto-unified-props-new@ietf.org>
CC: IETF ALTO <alto@ietf.org>
Thread-Topic: Chair review of unified-props (Part 2 of 2)
Thread-Index: AQHW9MmGbOqBj+e7AUCr+rNvM4bNcKqA/WeA
Date: Fri, 12 Mar 2021 19:17:52 +0000
Message-ID: <PR3PR07MB701884C3CE4698DBC35FDBDA956F9@PR3PR07MB7018.eurprd07.prod.outlook.com>
References: <CAMMTW_KN1b6hbTu4rqXkrTCaNfXNWW2vj=a0tTL3n4n_=m2g7Q@mail.gmail.com>
In-Reply-To: <CAMMTW_KN1b6hbTu4rqXkrTCaNfXNWW2vj=a0tTL3n4n_=m2g7Q@mail.gmail.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: [2a01:e0a:16a:5400:d49c:c92c:24e5:9887]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: a706313e-ddb6-4f0a-eeb8-08d8e58b88ae
x-ms-traffictypediagnostic: PA4PR07MB7615:
x-microsoft-antispam-prvs: <PA4PR07MB7615F23002F1124BC48FE5A7956F9@PA4PR07MB7615.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ndCqcftiEXm20fp6iNUSvGqryoY/V16lzxxtY4q2oXE36NM10RU6F1iq92cLzVPD2Mm+dGLkOFG81pi4cDfMOPgQ0VJbmarSBAsC4oEKwsIAT49987LaN1+kATH65UkRtdu0fdTke5a8D14GDJDljK44jPimXiNrMvB+ZOgjkyW3QH50gFBzbeio4OUun7CIaMCXYnM7pa/eCghjoSQBFntSmETwm4CFQZ0on/tkkUIuC7KL5aMstPD3FWUWnEqulsQWGz0Y2Zfk8p7mWu+DuXW91J3bdCcwYgcU+gPxRAKu7DkNel9tuRl0I9Bkw3t0p/eUd7wATMzJved/ebZQP1s+Sc0vQnySNgMucCabJ9XLsiZ8B0sdnFfagWnbZYWe33Ls/+8WWSLdliR4WZ770E7qIBZqqpvDGf+Boxq6tj4YmILFguiCFfM2YVylxqONdsRiNnA3kIe76kQ+hys2dzvL2u//fkWEHmnwEKeYH3roVuhENhRnJqY6NJrB1ghn16rZ2f7GOSOqMXBxi73loxC3Z3/8vNMVDwstbw1/wThnnhEJ6Bjkb9SJSncE+HX+
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR3PR07MB7018.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(376002)(346002)(136003)(39860400002)(83380400001)(66556008)(64756008)(66446008)(66946007)(66476007)(76116006)(7696005)(53546011)(33656002)(6506007)(316002)(52536014)(110136005)(478600001)(186003)(4326008)(8676002)(5660300002)(71200400001)(86362001)(8936002)(9686003)(55016002)(2906002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: cUqQWvAyrNybXXzhuwwWqyTSzmZOMkzpXWshxdaBLMJ7F6WvViQpp3Xi6/wvh+qZGLlxw9SnO5ewKrsJ6bjliMlNc700Y6l5qK1OOdo8NCxeVPcNVHkUDeRpVb7fwvTFtzcWfxFl3MxAoMDMpIT31rIk0UxT2dMO5QqwshkOtoW2L5Yg3uns2jNPdX0wjXulM4SCtIq6jAMPcEkQeJsQNccFQJ6hCK7hKs29uYwfIVUFoQpyNQYUrUnCVkZM2fNnfl3Nm3eYZq1KCnISt7OoIHu/cyg68M+ZNu7V1p/mACGrOOwhM+JKnnz4Lr40XVn5oh32mT38GH9qjdbg0didWMZQhBCyHvBZ9+pffeCWrtvPjzFVYEjez3XGG1zk5bi6MuuV8WrhPXf2FECasKtsAwsPOXTZPrvEfbw9DVp+Oau0E3CBNT4zr3KIWTLedl0sJDZuNKS66YoclxP8EFsseaeWLDYx+tEmqC09LQ8ASm1s39CXNNugCSNqx7aZqncmw0ZBj0iywljLPET+Cg3aBPg/NsZPjfAvdHb9Qsn5Q2hTAOTrchz1QgnrdZSBRnGpisJ9pBPP3a5o1kP5APWlxtNRrcKH6/m4IXAOupwBEHh+Xdpr2mo9MqLqlq5AVPRimSnEtxWjd7Kq8slYuVEer2KUdRCJ+j8uIdlxmYMFhTW99+OqBzFF78xn4A5LBtrPn9JN9JLijp2SOzyuUaVZOkQEBCHk8XqOEHHyD2Qr208gTAwyJydLB/UxrQezK4853tpXS3QAsmCrbCEXlXualpPatxIA17Ze0UTInNYWHTrQ2j3oq7/NDGLQnPlJJkrKzAsQuicqjAJlBxykq1ebZQ0ta/UGnRM8qUATkHgn5DUf8CHRUEcoYBbU09eLYHCIWCQucxw5eZnh3XjeunOwiGKkVNiJww+X0pxLlaiT9DyfpcowxpO9haWJ023i6OLpcDvSplEnv7iSTorio1TAJjp3NNIOGTFv1dfV2IAg4nKWRHDrwjA+uom004ncvL0XZDpF58nLDbLGO3oIVyWdWYVybx2bVHfmNr6eUJHE1XGJiVFYANhKBba4TGq/sYqX241+hbcC8NrkhY4YJ4Om03qTxQ+qb7kaY/qTQ990DTou4Q8qhscKdNjaOX3S5i8/uVgoLMmFVSMiXb5BAjhKYNe2R4jm/N9Woc6S9ZqFOrrklDDVkLd5g0rg3XqqrpymD1/V9KnBJTAVFu33hiWQwDXw6/3c+VQRc1cEJo5csWnlZLIHPPt07kndzylL07LGoho44+NhHRPsF9hKy+Pp/PT3ETPXc/7258Pchqqt8mxGEkz0hC59NO3MiN8a7B4snPcphgY9lMWgKDJBUkECyRrG/vaNz+vnYbbn00W+aFNJzBCWztwggjCg+NVLM/8l
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_PR3PR07MB701884C3CE4698DBC35FDBDA956F9PR3PR07MB7018eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia-bell-labs.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PR3PR07MB7018.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a706313e-ddb6-4f0a-eeb8-08d8e58b88ae
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2021 19:17:52.8489 (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: Tw6i38grni2KfngXYDqjN4aFdaCenTRfOAJOWWpri1dgZ7lyps8dEpZhOSQGccxVVQ2Gk/S8pTOPNVCO1gXcrP6bL/iRFukU70xNQsXvKE9Ez55FNNfdgF2c0Hv2qnb0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR07MB7615
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/ozkEiGUgQOG2ZVtCN_ak0EEyv24>
Subject: Re: [alto] Chair review of unified-props (Part 2 of 2)
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: Fri, 12 Mar 2021 19:18:19 -0000
Hello Vijay, Thank you for your review of Entity Property Maps. As promised, please find inline the answers from Jensen and myself on how your comments have been addressed, prefixed respectively by “[jensen]” and “(sabine)”. Responses on sections 9.3 and 11, with “*****”, request further feedback from you. Thanks, Sabine From: Vijay Gurbani <vijay.gurbani@gmail.com> Sent: Wednesday, January 27, 2021 5:28 PM To: draft-ietf-alto-unified-props-new@ietf.org Cc: IETF ALTO <alto@ietf.org> Subject: Chair review of unified-props (Part 2 of 2) Chair review from Section 5 - end (inclusive). Please go through the Major review points, they require some attention. This concludes my review of this document. Overall a well-written document covering a range of important extensions to ALTO. Major: - S5.1.1: "The '.' separator MUST NOT be used unless specifically indicated in a further extension document." ==> I don't understand this. If the '.' must not be used, then this should be an absolute condition (MUST NOT is the normative strength in the sentence). If this document allows the '.' to be used in a further extension document, then this is a relative --- not absolute --- condition, and thus a normative SHOULD NOT seem to be better. However, as currently written, this sentence seems rather wishy-washy. Either say '.' is out of bounds or say it is not, it seems weird to say that this document does not use it, but others can. One way to achieve this is to replace that sentence with: The '.' separator is not used by this document, however, future extensions may use it. For the purpose of this document, the strings "ipv4", "ipv6", and "pid" are valid entity domain types, while "ipv4.anycast", and "pid.local" are invalid. However, even then, I am not sure if the above is correct. Later, in S5.1.2, you go on to say that "Note that the '.' separator is not allowed in EntityDomainType and hence there is no ambiguity on whether an entity domain name refers to a resource-agnostic entity domain or a resource-specific entity domain." Thus it seems to me that future extensions could run into trouble if they allow '.' in the EntityDomainType. This needs to be resolved before publication. [ [SR] ] [Jensen] Thanks for noticing this bug. The '.' separator is not allowed even in an extension document. The paragraph has been revised to the following: An entity domain has a type, which is uniquely identified by a string that MUST be no more than 64 characters, and MUST NOT contain characters other than US-ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen ('-', U+002D), or the low line ('_', U+005F). - S5.1.2, last paragraph: "Note that the resource ID format defined in Section 10.1 of [RFC7285]..." ==> Section 10.1 of RFC 7285 defines "PID Name", not "Resource ID", which is defined in the next section. Please clarify. [ [SR] ] [Jensen] New paragraph rephrasing now: Note also that Section 10.1 of [RFC7285] specifies the format of the PID Name which is the format of the resource ID including the following specification: ... - S9.1: "...it is RECOMMENDED that the EPS be deprecated in favour of ..." ==> This is very important: If this draft is recommending a change in RFC 7285, then the status of this draft must say "Updates: 7285" at the top of the draft (it currently does not). This will cause the RFC Editor to enter a "Updated by: RFCXXXX" in the masthead of RFC7285. Further, I presume that since this update is a recommendation, the processing rules of property map and filtered property map are distinct enough that legacy ALTO servers and clients will continue operations? Please advise. [ [SR] ] [Jensen] We do not intend to update RFC7285 to deprecate EPS. This recommendation is more like suggesting that the new ALTO servers that support UP should also provide the EPS to be backwards compatible with legacy clients. Since the keyword "RECOMMENDED" has a specific meaning, let's not use this keyword here. The paragraph has been changed as follows: NEW Since the Property Map and the Filtered Property Map defined in this document provide a functionality that covers the Endpoint Property Service (EPS) defined in Section 11.4 of [RFC7285], ALTO servers may prefer to provide Property Map and Filtered Property Map in place of EPS. However, for the legacy endpoint properties, it is recommended that ALTO servers also provide EPS so that legacy clients can still be supported. - S9.3: What does "little or no impact on other previously defined properties" mean? Again, this appears wishy-washy for a standards document. Either we know that there is some impact, and we document what the impact is, or we state that there is no impact. But saying "little or no impact" is not helpful. Please state where there is impact and whether this impact will cause backwards compatibility problems. I note that S12.2.1 further expands on this "little or no impact". Perhaps a second order look at S9.3 is in order before publication to document the impacts on previously defined properties. [ [SR] ] (sabine) Agree. We have skipped this unclear first sentence and focused on the impact on the property semantics. ***** (Note: I did not find the text in 12.2.1 of version 15 that expands on this "little or no impact") The paragraph was updates as follows: NEW In the present extension, properties can now be defined on sets of entity addresses, rather than just individual endpoint addresses as is is the case in RFC7285. This might change the semantics of a property. These sets can be for example hierachical IP address blocs. For instance, a property such as fictitious "geo-location", defined on a set of IP addresses would have a value corresponding to the barycenter of this set of addresses. - S10: Please fill in all of the "###" for "Content-Length: ###" in all examples. [ [SR] ] [Jensen] done - S11: Did anyone in the WG do a threat analysis of the information exposed by the property maps related to, say, domain type "ane"? As the example in S10.9 demonstrates, there is a lot of information in the returned response that will be of interest to malicious actors. I note that there is a blanket paragraph in this section ("A particular fundamental ... URI to provide the information.") that appears to address such a scenario, but I don't see a well thought out threat-model that drives the discussion in this section. At the very least, the authors should spend some time thinking about the information in the property maps and how it may be used if it fell in the hands of a malicious actor. If after reflection they come to the conclusion that the second blanket paragraph outlines a mitigation strategy that suffices, then that is fine. Just wanted to make sure that the authors have spent some time here. [ [SR] ] (sabine) ***** agree The text indeed proposes one option, that consists in managing access to information on a per property "P" value, matched against the IP address of the Client. Another, maybe more scalable option is to gather information that the provider considers sensitive in a delegate ALTO Server, whose access would be restricted. If you think this makes sense, we will further check with the WG on such options, especially with operators and applications and hope to get back with new text that better reflects protection strategies, possibly see how access to sensitive information can be managed. Minor: - S5.1.3, last paragraph: I think you should append the following sentence to the paragraph: Such equivalences should be established by the object represented by DomainTypeSpecificEntityID, for example, [RFC5952] establishes equivalence for IPv6 addresses, while [RFC4632] does so for IPv4 addresses. [ [SR] ] [Jensen] Thanks. I like this suggestion. Done. Nits: - Please run idnits; currently, it is reporting 3 errors having to do with using obsoleted references (RFCs 5226 and 7159) and a downref (RFC 7921). [ [SR] ] [Jensen] Done. Thanks, - vijay
- [alto] Chair review of unified-props (Part 2 of 2) Vijay Gurbani
- Re: [alto] Chair review of unified-props (Part 2 … Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
- Re: [alto] Chair review of unified-props (Part 2 … Randriamasy, Sabine (Nokia - FR/Paris-Saclay)