Re: [Int-area] AD review of draft-ietf-intarea-gue

"Eric Vyncke (evyncke)" <evyncke@cisco.com> Wed, 06 October 2021 08:12 UTC

Return-Path: <evyncke@cisco.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB80F3A175E; Wed, 6 Oct 2021 01:12:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.599
X-Spam-Level:
X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=C5+XZMkI; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=xo1YrwTH
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 UBqzuks-9eMx; Wed, 6 Oct 2021 01:12:43 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC113A1758; Wed, 6 Oct 2021 01:12:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13052; q=dns/txt; s=iport; t=1633507962; x=1634717562; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MeN/x5FdTmOqgIMgb3HLniNP2E5xGgc+9lgYJ/7T+Hs=; b=C5+XZMkIRDE76jWRXRdizgpjvNlAXP8BSOm7ugwVOy4nNEjUBynGLa9S JZwySXzqSNNu+7SOkU4D8jFQ8sPetV5BvaAttLMrTqZDS72swmeVqj8RP 3I/zxU2biqHcQJBhioSFAGOfOND0okXsmRQPLrrlFzRLcyXZ17b9tCcP/ 8=;
IronPort-PHdr: =?us-ascii?q?A9a23=3AF5Cnhx2omhZdXZnJsmDPQVBlVkEcU/3cPgMP4?= =?us-ascii?q?Jc9l7ZHdKjl9JPnbwTT5vRo2VnOW4iTq/dJkPHfvK2oX2scqY2Av3YPfN0pN?= =?us-ascii?q?VcFhMwakhZmDJuDDkv2f/7ndSY3BthGXVlpuXq8NBsdFMP3fVaHpHq04HYbE?= =?us-ascii?q?Qn+MgwgIOPzF8bSgs272vr09YfUZlBDhSG2ZvV5KxDlxTg=3D?=
IronPort-Data: =?us-ascii?q?A9a23=3A6HrlOKv3P4PgpkclX/CX/2aJpufnVKxcMUV32?= =?us-ascii?q?f8akzHdYApBsoF/qtZmKW7VOP+JajOjcox2OYS+/RgHvpOEmtFjQAZorioxR?= =?us-ascii?q?XxHgMeUXt7xwmUckM+xwmwvdK/shiknQoGowPscEzmM+39BDpC79SMljPnQG?= =?us-ascii?q?+KnYAL5EnkZqTFMGX9JZS1Lw4bVsqYw6TSIK1vlVeHa+qUzC3f9s9JACV/43?= =?us-ascii?q?orYwP9ZUFsejxtD1rA2TagjUFYzDBD5BrpHTU26ByOQroW5goeHq+j/ILGRp?= =?us-ascii?q?gs1/j83Ad+j1738aEBPEvjZPBOFjTxdXK3Kbhpq/3NplP1kcqtHLx4L111ln?= =?us-ascii?q?PgpoDlJnZGuWAEiPaDkk+UGWB4eGCZ7VUFD0O6ceiPj75DMniUqdFOpmZ2CF?= =?us-ascii?q?noeMooC4PdfDHtBs/USJDZLZxvFmuHe6J6yVOhgwO4nJcLoFI8SvnUmxjbcZ?= =?us-ascii?q?d4nR4yGSr/H7PdZ0Ss+wMdUEp72a9AQZyYqbRncbVhOPEseEp832ei1iz/2d?= =?us-ascii?q?zlwqV+Jq+ww+We75BB21ZDtPcDfd8aWQcxTkgCToWeuwohTKnn2L/SFwjaDt?= =?us-ascii?q?3mrnOKKzWXwWZkZE/uz8fsCvbFa/URLYDV+aLdxiaPRZpaCZu9i?=
IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AIkJ0AK1PlcIf/sIJCIab4wqjBeRxeYIsim?= =?us-ascii?q?QD101hICG9Lfb4qyn+ppomPEHP5wr5AEtQ5uxpOMG7MBThHQYc2/hTAV7QZn?= =?us-ascii?q?iZhILOFvAh0WKC+UyhJ8SazI5gPMhbAtND4bHLfD1HZIPBkXWF+rUbsZy6Gc?= =?us-ascii?q?KT9J3jJh5WJGkAAcwNnmQJaDpzUHcGOTWubqBJcqZ0k/A33wZIDk5nF/hTaE?= =?us-ascii?q?N1O9TrlpnurtbLcBQGDxko5E2lljWz8oP3FBCew1M3Ty5P6a1KyxmAryXJoo?= =?us-ascii?q?GY992rwB7V0GHeq75MnsH699dFDMuQzuAINzTXjBqybogJYczEgNl1mpDo1L?= =?us-ascii?q?8ZqqiVn/4SBbUp15oXRBDunfLZ4Xi47N/p0Q6+9bbXuwq+nSWzfkNKNyMIv/?= =?us-ascii?q?MoTvKe0Tt+gDm5u5g7jl5wcPFsfE39dW3Glqr1v1sBrDvGnVMy1eEUlHBRSo?= =?us-ascii?q?0YdftYqpEe5lpcFNMaEDv9851PKpgjMCjw3ocdTbqhVQGVgoCv+q3bYl0jWh?= =?us-ascii?q?OdBkQSsM2c1DZb2Hh/0ksD3cQa2nMN7og0RZVI7/nNdv0ArsABcuYGKaZmQO?= =?us-ascii?q?sRS8q+DWLABRrKLWKJOFziUKUKIWjEpZL76Kg8oOuqZJsLxp0vn4mpaiIWiU?= =?us-ascii?q?ciP0b1TcGe1pxC9R7ABG27QDT208lbo4N0v7XtLYCbehFriGpe2/dIhs9vQ/?= =?us-ascii?q?Ezd8zDTK6+MsWTZFcGQ7w5qjEWc6MiXkUjbA=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CZAACQWV1h/5BdJa1aHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUUHAQELAQGBTykoB3daNzGER4NHA4RZYIgJA4ETgXCHcYU?= =?us-ascii?q?giliBLhSBEQNUCwEBAQ0BATcKBAEBhH0CF4IvAiU0CQ4BAgQBAQESAQEFAQE?= =?us-ascii?q?BAgEGBIERE4U7CCUNQBYBhWsBAQEBAxIREQwBATcBDwIBCBEDAQIDAiYCAgI?= =?us-ascii?q?fERMCCAgCBAENBSKCTwGCVQMvAQ6kIQGBOgKKH3qBMYEBgggBAQYEBIE2AYN?= =?us-ascii?q?TDQuCNQMGgRAqAYMAhBWGcCccgUlEgRUnHIIwNz6CBB1CAoErAQsHASEHM4J?= =?us-ascii?q?eN4IuiixSISEPMgQvHAgUOzZIHAISAQQCDyAIFSeOIAmDGAKDToximx9nCoM?= =?us-ascii?q?wikWNPH0GhWEFLINnQospA5c6liWMSYM9kDEShHMCBAIEBQIOAQEGgWE7aXB?= =?us-ascii?q?wFTsqAYIKAQEyURkPhkKHXgwWgQQBBIFAgQeFFIVKdAI2AgYBCgEBAwmQeoF?= =?us-ascii?q?CAiYHgTpdAQE?=
X-IronPort-AV: E=Sophos;i="5.85,350,1624320000"; d="scan'208";a="933346479"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Oct 2021 08:12:40 +0000
Received: from mail.cisco.com (xbe-rcd-006.cisco.com [173.37.102.21]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 1968Cadb027720 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 6 Oct 2021 08:12:36 GMT
Received: from xfe-rtp-003.cisco.com (64.101.210.233) by xbe-rcd-006.cisco.com (173.37.102.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 6 Oct 2021 03:12:36 -0500
Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xfe-rtp-003.cisco.com (64.101.210.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 6 Oct 2021 04:12:35 -0400
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Wed, 6 Oct 2021 03:12:34 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J9EH9gfyWdtgNLBF6P2pdzgWUYHMtvfg1sW+H86behOZxGk4Jn59vAEHjK2ylv0O5yns1Btee0XpOvsSCzsYkGW5EtOch9ap8bY6sqfYy8iDrYZpAcM/rRIBX2zH5IoYjIuyTTq2AdxRlBbworpjDHvPdxPZQrZg7DURSxuvyKhtzKkNNw6u/Ph7gJloKQntQpEhlc1WL/9dmbV7CBcUMdcwKH/lwkYFgDyEH9YczkELeYAGOpKWo3gdW3zU0jr7DLHSzz5E6zIKmhhH5C/w1GcIJyBPagh44r9baAWag2ond3Q8HthDlJZJNTsPj4Tbk6+eZSvle0Tf4nOkMCRpxQ==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MeN/x5FdTmOqgIMgb3HLniNP2E5xGgc+9lgYJ/7T+Hs=; b=Z8fZlwrsbq5H0x4vAnoib7uH+o5Y0kkRV9pEJDP/D0qsiKQ7IItgqfntHEROAUFzwMLByyg5dohp2zDAJ32w/TSBXfATYJnJHVvjuoun0WfRlTjsUtcRTxyAvuX2/M5UlOc3EoVi/ZrNf0JiipXGfpaY9ZOC825BCL9l0ft2QTFA4aUrPY18+sNXM2gX8raeHHTQH/20rKWt4Fl+vhazJM/kePEWIDDBWnn/azN50sxeHq48kRXikEFFNNESjt8WNGZGaApH8KLQukvH0JxyJAar99mf9a4FP7ZFSUGvZ5kAGaXmH+NYdc05fGCIwMvCRZX4RBb5geWYOj5W8Wh4Ag==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MeN/x5FdTmOqgIMgb3HLniNP2E5xGgc+9lgYJ/7T+Hs=; b=xo1YrwTHRJJBF7YAsQUoklhzU5nbR4iZqpOFFFR34T+pGT7Z5Vier2Zt+EcYYvseEmBCrVS0oglswYvIR6Q99smulc+cc/HtgYTVsJ7sKabZoGFAKn9d5Q1cBdjrg6t/sMIrUuTDRr9lKAU2uAImgJEWmLMrJEDmqfekjiMInGc=
Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB5110.namprd11.prod.outlook.com (2603:10b6:510:3f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.22; Wed, 6 Oct 2021 08:12:33 +0000
Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::596b:9fa6:18d4:67e7]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::596b:9fa6:18d4:67e7%8]) with mapi id 15.20.4566.022; Wed, 6 Oct 2021 08:12:33 +0000
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: "tom@herbertland.com" <tom@herbertland.com>, "draft-ietf-intarea-gue.all@ietf.org" <draft-ietf-intarea-gue.all@ietf.org>
CC: int-area <int-area@ietf.org>, "Black, David" <David.Black@dell.com>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Thread-Topic: AD review of draft-ietf-intarea-gue
Thread-Index: AQHXugiOZC2tDWAt1UiCTidDCrMp1avFwUmA
Date: Wed, 6 Oct 2021 08:12:33 +0000
Message-ID: <229AF489-C543-45A9-A5ED-E49546CB5796@cisco.com>
References: <6D36704E-EF85-41F4-B9C2-A7158B86842A@cisco.com>
In-Reply-To: <6D36704E-EF85-41F4-B9C2-A7158B86842A@cisco.com>
Accept-Language: fr-BE, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.53.21091200
authentication-results: herbertland.com; dkim=none (message not signed) header.d=none;herbertland.com; dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8717fef3-517f-4ca9-a5d3-08d988a10ced
x-ms-traffictypediagnostic: PH0PR11MB5110:
x-microsoft-antispam-prvs: <PH0PR11MB5110F69D89DCC9F215C4EF48A9B09@PH0PR11MB5110.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 0M9IwYy+vyjmYk6KSW93dUPXILtJFqoU6BCPuLZTQJ5rF6iLMlAzPvF60+98peneHmAkp7EcaXCDMzWm0uPJEigdRD8MEXfzPgL6Vn8N6LaKEOpSnmh9/tl7W1caBsAKe2D/UxiEW//LmgwnSwoUxhUdheiY4mSouOpc0+s49l0sa27Z8lL+rKWWK5H1TbIoJpqKA/3pMvRt7aEJQD8oAuhHFaOBdrx99LeUEWmkkZIU/OsADc/cgpofrZbkDDv/bvPPNeiSF+G466cT/D6P8RmW1Tm/f5BkUuKUo5zb/8t5oj3dxHFaeK2Ik7p2iIYHIO/ZCqg6XMiEuKW+za1nrL++5vHa+iQcDT9HgnJQfsgutjrAaw7YSkpWLhmI1PkRBd8Dh/I5NdGEGapmYf6TlErlMTTA1HhbkCxBmryx1QvlpYFUc/wRHHgdKBv1Kmmoio+s9nE+kIF1BycCGOidazaW6g3bjQjvsGCs2jMn3toW2OOayHEm6T8wwZdrUNuwD5fF5ezIg5P22HqcGfpPha3iNvGgVbASXx186g7afIS5nXqQMMAMyQ/ed/Zi1kBlsJbImrnEp143XTtH1YOdkxYOP2QKqKf2g1QA4bmfYe8CMEtAkhvKBSCqWyFUpdyh4VKrBJe3pQ27JdTQozHz4ZyolD2nTj+ZiYcrRlvALKjB84bPhDs7WK95vbMxbqBELtFK1zAhKCW4ple934zjYpi/eBlhJ7lzgE+M9CqO2Ep+Wxe073Z5RsG25bNlA65xKtWZ90NZgqDtvPn3GJIy18qKaODsmZ3K67aINZQKO5WJSu7xkP+9ybHLII906qIzvAuxlz7yL7pEBDgM+o321OiSEqHW3hh84RlqSitK6pk=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(6512007)(71200400001)(316002)(33656002)(8676002)(122000001)(86362001)(38100700002)(5660300002)(91956017)(966005)(8936002)(6506007)(53546011)(6486002)(66446008)(66946007)(66476007)(4326008)(66556008)(76116006)(2616005)(83380400001)(38070700005)(186003)(66574015)(2906002)(54906003)(36756003)(64756008)(110136005)(45080400002)(508600001)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?RERDRjNBWG9KYWdtYTZKdC9CZ240Q3I4WDNDZkhwZCtFVFJSTVhnSEFLczNJ?= =?utf-8?B?WVhhUkFac0Yxb01DUFlKL3VtRzRyZVl3THJ2RG9WWWZVaEVmVE9XbVRlZXBQ?= =?utf-8?B?OFArRU14OGJaaUdocjBrc0gwZ1AwUWhmQVFVTndnOVFLTExUNm81RWVING1Z?= =?utf-8?B?Mk9EbUI5akJsZDRibW9IRGowSmc2WDdERS81c3pZOHlQUFAzSG9LS2pXQkU0?= =?utf-8?B?SDk0VE1QVFZpQkVsaGJrTHZqVW1DYmIzd05zdE9lNnBnVUJKbmdnbkhwd3Ru?= =?utf-8?B?Yi96RTJickJnN08zZ2ZJYWh5T0tLNmJLbVVCZXJrWlF2MlRReXlTWm11VWw3?= =?utf-8?B?K0hyNzUzK1o1RTExWEFlbXJPNnJLcndqTzlZaWxYaVlyNnc1blJNWVdqcW9Z?= =?utf-8?B?ajlrbTErd1l1aW95cThEbXB6cE1FcStNUGR3Nmt1MDZHYmtua0JOUXhYeU5K?= =?utf-8?B?L0ZoZWZSRHo3OGN6ZXExNnJtQm1hWGZXbnBMNjhJbk54WWhkMmJBeXFGWXhQ?= =?utf-8?B?cy9PRDZKcURGWERZUEE4ZC93K1crZExqd3R5dVJDdSs1V3BEZ3NDL0s2Tyt0?= =?utf-8?B?aDZVZE10cCtpMVhGNjlyamowajExL0xxVURqUEE0MkgvWlR3MXY2NXliNGVI?= =?utf-8?B?b3JBOHR2SDQrVVZnNzdoVmNZQTgxWUVINkYrUjAyeERjaTl3OXhtamtNbDVs?= =?utf-8?B?dzUwazRFTG4zbE9XRHNXRDFzNnBHVk5FeFgzVWhyMXduMFh4VjFRaG9LT3NB?= =?utf-8?B?ci9sMTFFMXhXS1VpLzV4SjJsRTc3YWhGcklYdVlXMHBKSmhJU2IzYXdabWRo?= =?utf-8?B?Y1lBYmxzek5IRDcvNGpzVm5IdnYrTlRyakJNTEhQV0RWRm15Q3RVVGxJZFBQ?= =?utf-8?B?QnJqTHd1TnRJbytYaVFyam9oZ0ptZGlVVWcxNlVDRzVZcWk0cVJNZnpwQWJM?= =?utf-8?B?MkEvTVB3ZW5hN0d0am5KR0t3dTMvQ0lwOUtrci9wK2dCK1RHTVgrK2V4ZzI2?= =?utf-8?B?YWpPZGUzcVZaNEltVmZvN1NCenV0SzdqYUJpeDRUTGgxN3kvSURHRWVDemc3?= =?utf-8?B?am1tVTVOb04yQ0hlQWhtekxMNmcvRkJHZTVrOEUrUENPbk5tU3FNdkZ5QUlp?= =?utf-8?B?VDZ4Yks3eENFMGhmNFR6dGRTSG9ta2dFcmdZNjQ5Y0w4VDRwVHlMYWpTaGE2?= =?utf-8?B?OXVRQ1BZa1ZWUFNnbjBLTWpudHdiRVRnNUFZdWNXTzlTcm5qUVdjY0RBTmh6?= =?utf-8?B?TEtWQVA2eDJyWUtudHdDd05ONnRTcHg1MVluN2VuWTVrUm5SbGRGdUN6K0h4?= =?utf-8?B?amVZOVVPYXRwVmhVckN2MVFuVnE2ZGhBelhaQjdmZWhLeEJtZk1DRDF3TFRU?= =?utf-8?B?bXNTb2U0WEhSaDdjWVQ3MUxUbkpuN0JpNlM3UzBtWDVBYng2WWZDSWlaSVds?= =?utf-8?B?RUNIbnM0UEtNVGN5V3draGE2WmdsM0JaOG02MjVMaHNuL0lOOFkzaXZXbzQ4?= =?utf-8?B?N29QOEN5VmRKaUlNK21PR291WGRuQlhTK2RVajlPeWpKeFJRU1dnT2EvcTho?= =?utf-8?B?YzJPOEI0YTVXeXJHVSt3Vi95Z1l5dUdJSjltTC81cUhlUmZETllKNXh5SWVq?= =?utf-8?B?V0RURzFIN2JIbUljRlZWdTNEY3l4a2tia0hMdm1SMDBCdTFuMDJtRFNZTmdh?= =?utf-8?B?TE5WNWQweSt0ZnM5V3RyNGgyOE1QTnhhTHJucWZTcnlmK2N1bVRDUHNldHFI?= =?utf-8?B?bG5iN0xCUWZiOFZUQXFHQk5oZDVzTVc2UzJjK3VreHdiamIxbHhmT256U2VH?= =?utf-8?B?WWNvdEcycXNodGVBc0lKTG8rV0o5RFdVSXNPUjZXS3hUM1BrT1luYWR6ZFhj?= =?utf-8?B?R1ltODg3aEgraStTUnlUVEVGY25CQTVRenRybUFUSlM0S0E9PQ==?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <FCEB12ABCFF46743BE1621140B1BC1A5@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8717fef3-517f-4ca9-a5d3-08d988a10ced
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2021 08:12:33.5986 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: +GyDA8OWwlgT4Hd032RWbVyA1ZMpUypwlBqBAGI3fYGhlEBD4OyjEuXAcVZ1uLQxhpblc3cZfuVo0L5JdhA5Tg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5110
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.21, xbe-rcd-006.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/rjcdpi4SOZpSnWZY3iOvFkA5i04>
Subject: Re: [Int-area] AD review of draft-ietf-intarea-gue
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Oct 2021 08:12:49 -0000

Tom, Lucy, Osama,
 
One year and one day after my AD review, I must notice that the document is in the same state even after a couple of reminders. 
 
Most probably a lack of energy/interest to advance this document when other UDP encapsulation protocols have been published and vastly implemented. And, this is a perfectly sensible decision of yours.
 
Therefore, as the responsible AD for intarea, I am sending this I-D back to the WG and declaring it dead (see section 4.2.6 of RFC 6174).
 
Regards and thanks anyway for the work done
 
-éric


From: Eric Vyncke <evyncke@cisco.com>
Date: Monday, 5 October 2020 at 15:38
To: "tom@herbertland.com" <tom@herbertland.com>, "lucy_yong@yahoo.com" <lucy_yong@yahoo.com>, "osamaz@microsoft.com" <osamaz@microsoft.com>
Cc: Suresh Krishnan <suresh.krishnan@gmail.com>, Erik Kline <ek.ietf@gmail.com>, "fred.l.templin@boeing.com" <fred.l.templin@boeing.com>, Wassim Haddad <wassim.haddad@ericsson.com>, Juan Carlos Zuniga <juancarlos.zuniga@sigfox.com>, int-area <int-area@ietf.org>, "Black, David" <David.Black@dell.com>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Subject: AD review of draft-ietf-intarea-gue

Tom, Lucy, Osama, 

As you probably know by now, I have become the responsible AD for this document for a couple of months (since I replaced Suresh who is in cc).

As usual, I do an AD review before launching the IETF Last Call step. So, here are my comments.

The first one is really about what is the added value of GUE wrt to so many already specified encapsulations. Of course, UDP-encapsulation guarantees a better middle-box traversal (being NAT or firewall or ...) but L2TPv2, Geneve/NVO3, IPsec, VxLAN, GRE over UDP, ... already apply the same UDP envelope (albeit for very specific tunneling techniques and to encapsulate a layer-2 frame). As the intarea WG has adopted this document and the WGLC was positive, I will go forward with the publication process anyway; but, I fear that the IETF Last Call and IESG evaluation will bring this discussion again. Section 6 should perhaps be moved forward as well.

I failed to see any reply to David Blake's early review for tsvart: https://mailarchive.ietf.org/arch/msg/int-area/Z67X78mJyzijDmt4GlCktndInzI/

In Tom's reply to Gory's review in https://mailarchive.ietf.org/arch/msg/int-area/66jAlVmJ-JqO_yy9utivM6bGhHg/ there is "I will reply to comments in time", and I have not seen a reply (possibly a bad search of mine).

In one email from Tom, it seems that GUE is implemented in Linux for years. This could become part of an implementation status section that is always useful for an intended PS status.

Where is described the process of receiving an ICMP by the encapsulator about a GUE packet?

Abstract: I wonder what is "specialized capabilities in networking hardware for efficient handling of UDP packets" except perhaps for ECMP ? Probably worth being specific even in the abstract.

Introduction: the text is about 'optional data' and 'extensions' and is not really clear whether they are identical, especially when the text is split in two paragraphs. Suggest to merge the last 2 paragraphs.

Section 1.2: why is this 'implicitly' for 'control' rather than 'explicitly' and nothing is said for 'data'. C-bit is an 'explicit' way of declaring this packet as 'control', or did I miss something?

Section 1.2: "control the state or behavior of a tunnel", humm I had in mind that GUE is not only for tunnels

Section 1.2: suggest to also define primary and extension fields (even if those terms can be inferred/guessed)

Section 1.2: "Proto/ctype" there is no protocol number in IPv6

Section 1.3: please use BCP 14 and RFC 8174

Section 3.1: about the UDP source port, is a 'RECOMMENDED' recommended in the choice of source port ?

Section 3.1: please add "and ignored at reception" when describing the 'Flags' field.

Section 3.2.1 in the last paragraph: 'nodes' is rather vague... is it the decapsulating node ? And beside 'MUST NOT parse', should the packet be dropped silently ? or dropped and ICMP generated ? or ?

Section 3.2.2: "Control messages will be defined in an IANA" should rather be "Control messages are defined in an IANA". Also, "and may be defined in standards" is not the usual wording for extensions.

Section 3.3: draft-ietf-intarea-gue-extensions seems to be expired... and MUST be normative, IMHO, as " [GUEEXTEN] defines an initial set of GUE extensions." indicates it.

Section 3.3.1: while the exact meaning of "Extension fields are placed in order of the flags" can be guessed, strongly suggest to be clear about this 'order of the flags'.

Section 3.2.2: unsure whether a copy & paste of another not-really-active document is wise. Suggest to remove this section completely.

Section 3.4: is "optional integrity check" defined in this document ? Else, I suggest to remove this text

Section 3.5.1: "implicitly" or "explicitly" because C-flag is set and the dest address is obviously the decapsulator

Section 3.5.2: we are well deep in the document and it is still unclear how the encapsulation can be done with variant 0. Is it a 'virtual' removing of UDP & GUE header ? I.e., leaving the outer IP header intact ?

Section 4: it is really smart to use the IP version field to indicate variant 1 (assuming that Internet Stream Protocol is no more used)

Section 5.2: why "should be co-resident with the hosts" ? Isn't it obvious then, rather than using "should be", let's use "are"

Section 5.2: "and the transport packet." how would ICMP qualify as it is rather layer 3 and not really 'transport' ?

Section 5.2: "Note that the transport layer ports " => "Note that the transport layer ports (if any) "

Section 5.2: I am afraid that some text about IPv6 extension headers is required here (and possibly for IPv4 options)

Section 5.3: "intended target (decapsulator)" why not simply writing "decapsulator" ?

Section 5.3: suggest s/it SHOULD follow standard conventions /it MUST follow standard conventions / 

Section 5.3: must include the normative references to 'standard conventions'

Section 5.3: what about MTU considerations as packet size is increased ?

Section 5.4: should an ICMP message be generated when packet is not validated and should it be dropped ? rate limited of course ;-)

Section 5.4: s/GUE packet is received by a decapsulator with unknown flags, the packet MUST be dropped./GUE packet is received by a decapsulator with unknown flags set, the packet MUST be dropped/

Section 5.4: should an ICMP message be generated when dropping GUE packets ?

Section 5.4.1: must be explicit about the processing of any IPv6 extension headers

Section 5.4.1: suggest to also indicate the inner/outer src and dst IPv4 addresses

Section 5.4.2: should/may an ICMP be generated ?
"
Section 5.5: unsure whether a section about middle box is required/useful because those will do whatever they want (typically evil). Also, "A middlebox MUST NOT drop a GUE packet merely because there are flags unknown to it." is wishful thinking as firewalls tend to block what they do not recognize.

Section 5.6.2: would a section on NAT64 be useful ?

Section 5.7: RFC 4459 is informational and will cause a down ref (that is OK) as the reference should be normative. As mentioned by David Blake in his review, RFC 4459 is about to be updated by draft-ietf-intarea-tunnels, the later should probably be mentioned as well.

Section 5.8.2: replace RFC 2460 by RFC 8200 ;-)

Section 5.8.2: while I am unsure whether the considerations about when using no UDP checksum are relevant/useful, it is probably shared by IPv4 and IPv6, so, move this part outside of 5.8.2 ?

Section 5.9.1: up to the authors, but I would use a "SHOULD NOT" in "a GUE tunnel MUST NOT be deployed to carry non-congestion-controlled traffic over the Internet"

Section 5.10: even after reading carefully the document, I am unclear about what are the "GUE parameters and properties" required to decapsulate

Section 5.10: is it useful to specify whether anycast traffic is supported?

Section 5.11.1: is "connection semantics"  already defined? Not the first time it is mentioned but its definition should either occur before or a forward internal reference pointer added

Section 5.11.1: "corresponds to the flow of the inner packet" seems to indicate a 1:1 mapping between outer source port and internal 5-tuple. Suggest to use a different word than "corresponds"

Section 5.11.1: "is set" or "SHOULD be set" ?

Section 5.11.1: please add references to ESP & AH RFC

Section 5.11.2: would it be useful to specify that the "flow entropy" should be constant for the same inner flow (= 5-tuple) ?

Section 6: this is really a useful section, IMHO, it should appear earlier in the document.

Section 6.1: "Standardized optional data ... are defined" ... where ?

Section 6.2: I would try to prioritize the list, i.e., imho flow entropy is important, the multiplexing also exists notably in GRE so is less important.

IANA: please use RFC 8126 rather than RFC 5226 ;-)

Possibly a couple of nits (but please bear in mind that English is not my native language):
• s/UDP based protocol/UDP-based protocol/
• s/four byte header/four-octet header/ (at least use 'octet' rather than 'byte' as some ADs are very strict on this use)
• Section 2: about OAM, typically we use the expanded version and put the acronym later, not the other way round.


Hope this helps

-éric