Re: [Gen-art] Gen-ART Telechat review of draft-ietf-anima-grasp-api-08

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 04 December 2020 18:21 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293B43A0EFF; Fri, 4 Dec 2020 10:21:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level:
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu
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 3BmgC_-1dNfY; Fri, 4 Dec 2020 10:21:55 -0800 (PST)
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2049.outbound.protection.outlook.com [40.107.237.49]) (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 8ACF43A0EE1; Fri, 4 Dec 2020 10:21:52 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jnquhPUlqiyo1A7KAd/5mgY/UfpKPgPmQ+DPSQIhfdTzHz5JQ4FNyS3NJR/SVQSjE1qHZ7qQpWJ7Cvj5M9rk+7RQMaufYH2/9DTSuiKUXd27p9gaCHv3rvIh1NnkFr/Sw1n039j6UsKTUBPIOXlCp7T+XySlfffSbUZhS2mIyGGHXj2O/Zn8/suJJMamiDqpTIS4MOu/isy27WY/J+yL0JSVqjcViPlfmwSqCFlx34OOzqHR3qrEwA9czpYzVtNmGSDRIgr7q/lJIn77wWCjGX+5/N9r3HHjmLGRdHCMXo8OGAagxwdEKpjVF6+XkVFc5FIFnBF2LQrtGhYYnFdGZQ==
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=Swvql6GZsqYAvv2B05SodTtW5sVaSHoMY4YJwDFWq2s=; b=hGf4cqEItoGI0ULSKArZgcoIHfLN7riAQEcH1IxpRs9V4UGA61mi+biGytzqZhCTkNbfeh7GAWmvfP9Fr35XabGQO6reTAcNHTZdNJB6+wjOpTa7grGH+lpVXIhl5YT4Kl1SdnkxwbcnC9P4cdqMySCpY3mip9hQdW0XlYQcl6qxmRDG1FWwJPFIg3+8Oxi9f2OUhzRYdhUJ1ZFNNjcy7He05k1XICIbvlJcuazHuvpRKq1AftV9FYiCIUYG8O6iV6UKRwJob/4TElUvch402IeHTdOxvOtSbaZsXh9rvFF5T0Y1WQibWl0OaGq0QU1DrFYAhjSWk2pRLfYh6IVGlA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=gmail.com smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Swvql6GZsqYAvv2B05SodTtW5sVaSHoMY4YJwDFWq2s=; b=XykcH0vJ957rdZxPjjR/rAyvYQog0ST3sBxrV2gKeEL57GUXMGXqz0yXE4yYMk3e2AFKtb+skDsIbCbDXLsRUfFwysArswj0GEyq2HNr65KzxTk3gFX2zjNgIR01rF0Emjg4hN1KL3bWcIFAnZvODDIrNHoM5ChOHLCe8NoI640=
Received: from MN2PR01CA0009.prod.exchangelabs.com (2603:10b6:208:10c::22) by BL0PR12MB2452.namprd12.prod.outlook.com (2603:10b6:207:3f::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17; Fri, 4 Dec 2020 18:21:50 +0000
Received: from BL2NAM02FT059.eop-nam02.prod.protection.outlook.com (2603:10b6:208:10c:cafe::69) by MN2PR01CA0009.outlook.office365.com (2603:10b6:208:10c::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17 via Frontend Transport; Fri, 4 Dec 2020 18:21:50 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=bestguesspass action=none header.from=alum.mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu;
Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT059.mail.protection.outlook.com (10.152.76.247) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.21 via Frontend Transport; Fri, 4 Dec 2020 18:21:49 +0000
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 0B4ILlmV013795 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 4 Dec 2020 13:21:48 -0500
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, draft-ietf-anima-grasp-api.all@ietf.org
Cc: General Area Review Team <gen-art@ietf.org>
References: <033a81cb-0a38-b291-80cb-c94e2147de3c@alum.mit.edu> <291a713f-b685-50fc-f097-1200e6127ef3@gmail.com> <86fa9191-1b74-97d9-d530-9415e7e035f9@alum.mit.edu> <3e979d48-04ee-b711-93e4-f1d51a3bd4bb@alum.mit.edu> <5332b21b-b5eb-7ac6-c759-12ef653706cf@gmail.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <4fb44aa2-7973-349b-db71-e0ade76310ee@alum.mit.edu>
Date: Fri, 4 Dec 2020 13:21:47 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <5332b21b-b5eb-7ac6-c759-12ef653706cf@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 46dea983-6b09-495b-8271-08d8988177a3
X-MS-TrafficTypeDiagnostic: BL0PR12MB2452:
X-Microsoft-Antispam-PRVS: <BL0PR12MB24525AFEFC683A03D008E102F9F10@BL0PR12MB2452.namprd12.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: cLlEsrVL6m6sfjQdmVZlZ40XC6DO8I9+0+nthZIvWyfZWHB8N0sn9K342SuSmxwfMGT6UQo0I5y41eRQ168AhfhTke4s8o6evoTE3n5m5EICwwKn7H39PjKnTddMjv+5kojl/pR0eNWmrfgV82zNzIPVqlqxls2vjhK31s7K8BboD8uOFCokkcir+W7U8HEffcRCOZkSgQ2yJbmGQVgxxMm5p3Xc80b+39qs13JrBz6Oi4i4NSCLMPtoxxLOdg0ww1VrKVoWXyEW4g8yPaAgpryvZdETzTrEoDERPz5jeBaT5NGH3HXIJ64nisZ8s3fG7pqu8vmAVKIBvhLTOXhUw6owfgsM8Dsgt64vHSYfn46RnwYUZo9gyMjGYmCVUTGK/xnWuPY8200zGl9JKhF+o6VbNfPgjuZpG9reyOPCBgOgM/ayio4ePzIQKcrWh/Vv
X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(396003)(346002)(39860400002)(136003)(376002)(46966005)(31696002)(478600001)(53546011)(786003)(86362001)(956004)(83380400001)(5660300002)(47076004)(70206006)(70586007)(82740400003)(82310400003)(336012)(186003)(7596003)(26005)(316002)(8936002)(8676002)(2616005)(356005)(4326008)(2906002)(75432002)(31686004)(43740500002); DIR:OUT; SFP:1101;
X-OriginatorOrg: alum.mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Dec 2020 18:21:49.7453 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 46dea983-6b09-495b-8271-08d8988177a3
X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu]
X-MS-Exchange-CrossTenant-AuthSource: BL2NAM02FT059.eop-nam02.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR12MB2452
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/KtefBX1jldYyQdvFljc7wZK-Es0>
Subject: Re: [Gen-art] Gen-ART Telechat review of draft-ietf-anima-grasp-api-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Dec 2020 18:21:57 -0000

Brian,

Thanks. I'm happy now.

	Paul

On 12/3/20 4:22 PM, Brian E Carpenter wrote:
> Below...
> 
> On 04-Dec-20 04:17, Paul Kyzivat wrote:
>> Brian,
>>
>> One more thing occurred to me:
>>
>> On 12/2/20 12:29 PM, Paul Kyzivat wrote:
>>
>>>>> Also, the goal of negotiation isn't clear to me. I gather it must be for
>>>>> the two sides to agree on a particular value for the objective. But for
>>>>> that to work there must be some rules about how values can change in
>>>>> each step so that the result stabililizes, rather than causing a battle
>>>>> that ends with loop count exhaustion. This could be achieved by always
>>>>> negotiating *down*, or always *up*. But that requires that the objective
>>>>> value type have an ordering function. Given the general nature of the
>>>>> objective I don't think that can be assumed.
>>>>
>>>> No, it explicitly is not defined either in the protocol nor the API.
>>>> The syntax and semantics of the objective value are defined
>>>> per-objective,
>>>> and the objective might or might not be ordered. So there is
>>>> intentionally
>>>> no answer to your question.
>>>>
>>>> In most cases I'd expect that there would be an ordering but we didn't
>>>> want
>>>> to constrain the use cases in that way. Also note that a failed
>>>> negotiation
>>>> (e.g. the loop count expires, or where one end simply rejects the other's
>>>> offer) is not a protocol failure.
>>>>
>>>>>
>>>>> ISTM that more work is needed to define the negotiation process in a way
>>>>> that ensures it ends with both sides agreeing on a single value for the
>>>>> objective.
>>>>
>>>> As noted, that is per-objective. The most complicated case I've coded
>>>> is IP prefix assignment, and it works fine, except that if there is
>>>> no prefix available of the maximum desired length, the requester ends
>>>> up unsatisfied - as intended. There should be no condition in which
>>>> the negotiation loops indefinitely; it either succeeds or fails.
>>>
>>> Without that the result in non-deterministic. The two sides may have
>>> conflicting goals, and then the result will only be determined by the
>>> loop count and timeout.
>>>
>>> Alternately, implementors will establish side agreements that aren't
>>> governed by standards.
>>>
>>> That seems like an undesirable state of affairs.
>>
>> One possibility would be to define the negotiation policy on a
>> per-objective basis. This would be required as part of the definition of
>> the objective that is registered with IANA. It would define how the
>> value may change from step to step of negotiation to ensure convergence.
> 
> The IANA policy is Specification Required. We already have this in the
> GRASP spec itself:
> 
>     There must be a well-defined procedure for concluding that a
>     negotiation cannot succeed, and if so deciding what happens next
>     (e.g., deadlock resolution, tie-breaking, or revert to best-effort
>     service).  This MUST be specified for individual negotiation
>     objectives.
> 
> The natural place to expand on that is in draft-ietf-anima-asa-guidelines
> as it develops.
> 
> Regards
>      Brian
>