Re: [ippm] Francesca Palombini's Discuss on draft-ietf-ippm-ioam-data-12: (with DISCUSS and COMMENT)

"Frank Brockners (fbrockne)" <fbrockne@cisco.com> Mon, 26 April 2021 08:12 UTC

Return-Path: <fbrockne@cisco.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014593A128C; Mon, 26 Apr 2021 01:12:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.917
X-Spam-Level:
X-Spam-Status: No, score=-11.917 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=DgLknBw5; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=awatoRGA
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 AG6j77i6OBVU; Mon, 26 Apr 2021 01:12:19 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 876133A1228; Mon, 26 Apr 2021 01:12:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=57938; q=dns/txt; s=iport; t=1619424739; x=1620634339; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LDpe9M8L8VerKnpJRjXf3/sTXxCTm5PIxEtPLsEDIm0=; b=DgLknBw5tkEEXyWbzFWxSUAbPtoanwdQMJs+a7xP7VLMh2nFECMUIdDK Mi28d65jPSK58Ytw4kZMgFGO/u8is4TNLaq14/pYyh+8YXlxisL3Vk8d6 nW/0AJiUB4iOxF/R4CBbDO1YhdFptTB1HNPRFqpjsrA2A+i9bi0UGwyKC w=;
X-IPAS-Result: A0AOAADJdIZgmIUNJK1aGgEBAQEBAQEBAQEDAQEBARIBAQEBAgIBAQEBggECAQEBAQsBgSIwUX5aNjELhDiDSAOFOYhpA4EMiSaEe4oVgUKBEQNUCwEBAQ0BASgKAgQBAYRQAheBYgIlNwYOAgMBAQEDAgMBAQEBAQUBAQECAQYEFAEBAQEBAQEBaIVQDYZEAQEBBBoJChMBASUEAwsBDwIBBgIRAwEBASEBBgMCAgIfERQJCAIEAQ0FCAyCXQGBflcDLwEOjWGQbQKKH3qBMoEBggQBAQaBNwIOQYMNDQuCEwMGgToBgniECQEBgROFQCccgUlCgRNDgik2PoIeQgEBAQKBKAESASMeDQmCYTaCK4FYUx8BPSYBAyINDAgOAiBTDDUYAwoLBxEBBAIPKjiLZoRsEoJ2QodyMpwteDlbCoMOiXGHI4VSeQSFTRCDUYsFBJY2HZUKghKJZoMZj1MEGAGETAIEAgQFAg4BAQaBaiJrWBEHcBU7gmlQFwIOjh8MDQkVgzmFFIVJcwI2AgYBCQEBAwl8iwMBMl4BAQ
IronPort-PHdr: A9a23:bk7UbB9uz7VS7P9uWNvoyV9lXQAupqn0MwgJ65Eul7NJdOG58o//O FDEjd1gll7CRp7c7bRPjO+F+6zjWGlV55GHvThCdZFXTBYKhI0QmBBoG8+KD0D3bZuIJyw3F chPThlpqne8N0UGFdz/bEbJpXv05jkXSV3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/N lO4twLU48IXmoBlbK02z0ihnw==
IronPort-HdrOrdr: A9a23:E4rCqKtwtLZZvEWq9X82wWI67skCJIcji2hD6mlwRA09T+WxrO rrtOgH1BPylTYaUGwhn9fFA6WbXXbA7/dOgLU5FYyJGC3ronGhIo0n14vtxDX8Bzbzn9Qy6Y 5JSII7MtH5CDFB4vrSyAOzH888hPyO9661jenTpk0dMj1CQYsI1XYfNi+wFEpqSA5aQb8wE5 SB7sRKzgDQB0g/RMK9G3UDQqz/t8TG/aiWLyIuKjwGzE21jT2u4KPnCBTw5Hcjeh5G3LtKyx m/ryXX/aOm2svLryP092iW1JhOncuk990rPr3xtuEwChHBzjmlf55gXbrqhkF1nMiK5EwxmN fB5zcMVv4DkU/5RW2+rRvz1wSI6l9HgBWOpS768BneiPf0Sz4gB81KiZgxSGql12MboNp+3K hXtljp0aZ/MBLakCzxo/jOWh16/3DE2UYKrO8Jg3RTFbYZcb9axLZvhX99LZFoJlOf1KkXVM 1VSO3M7vdfdl2XK1rDuHN0/dCqVnMvWj+bX0kroKWuonhrtUE863Fd6N0Un38G+p54YYJD/f 74PqNhk6wLZtMKbJh6GPwKTaKMey/waCOJFFjXDUXsFakBNX6IgYXw+q8J6Oajf4FN65cuhp LbUhd9uXQpc0zjTe2Ctac7sCzlcSGYZ3DA28te7592tvnXX7zwKxCOT1gojo+uuPMaDsrHW+ uiOZ5fDvP5RFGeXbph7knbYd1/OHMeWMoatpIQQFSVuP/GLYXsq6jafZ/oVf3QOAdhflm6Lm oIXTD1KskFxFusQGXEjB/YXG6ofkT++Jl3AbXL5uR78vlKCqR89iwuzXip7MCCLjNP9oYsel FlHb/hmqSn4W+s/WjJ6G1tMgFHDllc5ajhV38in35OD2rENZI4//mPc2Fb23WKYjVlSdnNLQ JZr1Nrvb6sI4eI3iAkAdK/Omech38ezUj6Fqs0q+mm34PIa5k4BpEpVOhNDg3NDQVyghsvgn xEchU4SkjWES7Oha2pgIcPPvzWc8BxjW6QUJZpgEOakX/ZhMk0AlMHQjalUKes8HcTbgsRom c0zogyr/6rny21JW42neIiWWc8GFi/MfZhFwSKZIJdh7bxXhp/JF363gCyulUUZnfg8VkUiy jHKyCZEMu7X2Z1izR/zrvg9k9yeyGmW39ILlp+sYF7CA39yyxO+OeWe6u+1HaQYFMewucbdC rIeycWPxkG/aHF6DeF3DmFDnko3ZMoI6jUC6kiaaja3je3JJSPjrxuJY4YwL91cNTvuPQMS+ SRZkucKy75Efog32Wu1z0YETgxrHkvivXz3hL5qGC+wX4kGPLXZFBrXasSLd3Z72/qQZ+zod 9EpMNwueu7KWPqbNGajanRcj5YMxvW5XesUPtAk+EjgYsi8L9oW5XLWzrB039KmB04McfvjU sbBKB2+qrININjd9EbEhgpsmYBhZCKNg8mowb2CugxcRU2g3jXM8iA7rDIpbAsa3fx7DfYKB 2a6WlQ7v3FVyyM2foGEKo2O31Rc1V553J4/u+OHregRzmCZqVG5h69PXC8erMGF/TAFrUUsx pg49aH2+WQbDH13QjMvT19ZqJCmlzXNf+aEUaJA6pP9df/JFGHxq2t68S3hC3sSTS6Z18D7L c1PHA4f4BGkH06kIYz0iKuUaT5rUIujktG7Vhc5yvQ85nj5H2eAFpPPgLYiIhHRDVfMnCHis Le7OiTvU6NlwRtyN3ED0dfftZHBtgWQMz2Nk5VWLotgII=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.82,251,1613433600"; d="scan'208,217";a="727184744"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Apr 2021 08:12:18 +0000
Received: from mail.cisco.com (xbe-aln-001.cisco.com [173.36.7.16]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 13Q8CHdD031424 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 26 Apr 2021 08:12:17 GMT
Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xbe-aln-001.cisco.com (173.36.7.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Mon, 26 Apr 2021 03:12:17 -0500
Received: from xfe-aln-005.cisco.com (173.37.135.125) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Mon, 26 Apr 2021 03:12:17 -0500
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Mon, 26 Apr 2021 03:12:17 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mqNwdyP8D2dnHILEMgbpBPJ4VC4+QVndIhZQGJv8TfIuenWMxOM4BPIXLQIGun9rSWDoZnnvP3uhjWASz3k5TpSHbAXjw6ADaL5EkhoZpm/uPU3yJpQWrNtUoCFuYmOCDKAwaeuUsy24LSRJlmSJDT8y2R+busDqjEqKUekTrl9zBEk/Cj+3+/zZkhC7oyxQjR8pDR9E9a+WHjoBKIUabYo+TkgkMxE7xLY9CIGuKe/XUUETcLobD+NdloecdoOyFcKeaN+RsGHjqr7h8L3tyXkYraBmj6iqxJo+8T9xyg4c+8ONAG7qBhbVqxABsIj7BwWha+Q7NMOuXm3pIeCNWw==
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=LDpe9M8L8VerKnpJRjXf3/sTXxCTm5PIxEtPLsEDIm0=; b=BbEMv2jSzBRLhEOOmvDFPbYNzYnXpppk0bDq2/4/kJP+e8KZ3Gyo8mYR8lxtTW7gNZgrh2HILRVb8fw7T3g6i+C72b5F8oGjPi8bRXZthFw2D5xDl9mKfbAOELOYw5HJ/1ifi4u1tcJnnveEMFXdSPmRkP76NgLAhsHrHjaWGUmFDe8r2qN9G93fLuOOJsuOgBEMFS4Pq3ciP8MLfwcnwoOHrOHx8YgZX4R9xVFQ/kXc3XBmCquoZy6Fl9ym8WdlBbGiyEyIydd7O9WvxMGTaDWWJD3RZbuF5UVU4vpp+gCiRXIffKlwBBoyBchG4TwQpFNwQC8CksZ2f2JDDCqrcQ==
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=LDpe9M8L8VerKnpJRjXf3/sTXxCTm5PIxEtPLsEDIm0=; b=awatoRGABX62Hz7WmBcnKoEZvxEXKfpn94jsSYmVzmRub5yfD5s05YSPgpUG9dfBnSuwIx2y+n180iZNY2JYV0XTue8+tOtPmcELWLleimV+8eUl7I6o1j6KyRDWAOe7erlCUnGweO2cL98i1LW/MpMYFxB4Do8wR13YGCLkqVQ=
Received: from BYAPR11MB2584.namprd11.prod.outlook.com (2603:10b6:a02:c8::31) by SJ0PR11MB4912.namprd11.prod.outlook.com (2603:10b6:a03:2ae::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.23; Mon, 26 Apr 2021 08:12:15 +0000
Received: from BYAPR11MB2584.namprd11.prod.outlook.com ([fe80::f0b2:5cc4:e741:93ca]) by BYAPR11MB2584.namprd11.prod.outlook.com ([fe80::f0b2:5cc4:e741:93ca%7]) with mapi id 15.20.4065.026; Mon, 26 Apr 2021 08:12:15 +0000
From: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>
To: Francesca Palombini <francesca.palombini@ericsson.com>, Martin Duke <martin.h.duke@gmail.com>
CC: The IESG <iesg@ietf.org>, "MORTON, ALFRED C (AL)" <acm@research.att.com>, IPPM Chairs <ippm-chairs@ietf.org>, "draft-ietf-ippm-ioam-data@ietf.org" <draft-ietf-ippm-ioam-data@ietf.org>, IETF IPPM WG <ippm@ietf.org>
Thread-Topic: Francesca Palombini's Discuss on draft-ietf-ippm-ioam-data-12: (with DISCUSS and COMMENT)
Thread-Index: AQHXIOCfMuFj4je5h0SdJKx2WpHpNqqU/JoAgAEhFQCALF2SgIAEJ0NQ
Date: Mon, 26 Apr 2021 08:12:14 +0000
Message-ID: <BYAPR11MB2584412CC953DF89583FC53CDA429@BYAPR11MB2584.namprd11.prod.outlook.com>
References: <161661268673.916.16348206674906302793@ietfa.amsl.com> <CAM4esxSYaE27gPRjAuWuZkimW5TLW2J+jrm-7R5r-Wah6OvEsA@mail.gmail.com> <E715D54E-1BCE-4B81-84E1-BCB42407AB36@ericsson.com> <BYAPR11MB25847DBFCBC1974B33EBD425DA459@BYAPR11MB2584.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB25847DBFCBC1974B33EBD425DA459@BYAPR11MB2584.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.220.51]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9e3eec70-0ce6-4282-0886-08d9088b00e2
x-ms-traffictypediagnostic: SJ0PR11MB4912:
x-microsoft-antispam-prvs: <SJ0PR11MB4912A7BB54A015B86FD0A37CDA429@SJ0PR11MB4912.namprd11.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: eFZjtiZ3DJt6dnzdqgxgprbZFNwYDnfPQh+NJBeu3FdnVvm4m72evPyQTrcrbrcMmtEyPhGhmHDncW0N911Q3ZgKm2x0ewc2BUiaJkl8e+dSr/Fa+nDBeWjX0JOwZcGI4L//Xfk4sElcfe+hpa0sOrFUXyJ/1Kn4NKm/zfGQVcqED7JCKySyzC+h7vvlZnbKt/pRgAadnl4YhR2mU24FOtNTS+d89577jZ3jVWEzJ7XURS/ojQDMMXRt99i08W9GdwpUGCwjEtYx8zco9SIFc5GueACe+XEWVuksi0+EpiGxro6AfSNtbONGMeiD4qOu+Kk7cU/aXP0bhxxJ+3tI5SNh4Fd5QVE+3oH0OgK0SWV/g+nFSsV8n5BlDvBpMe0L6aJ/tYSmnvGZ7TcxU0nBe1gUvLRwI+mj6wF/5ekbv2jsmRHPSJSd8tT8jxE1++EZTkFnTm5FGqbFEBM8NY7JSLNIcnNgxNv+ckoWNGvCZadZ8gL0akC45gU8pNdzOUloKkw+VeFTBC4HW5xWHpXffwAv6RCgd3BrPP+AVyeWJ7SSPuLvMkaGk7aTKNjhp8y3RfEOQFh2mJNon7q8XLPFZS5NdBgFTzZsJpaNSmVzgtROfVaPI+xYkElLF34RcmcJ4YQSvCZn3al/QLaPhqgm1Sy6TjH8Hm+W+/GE+FW1+86vvA3tbny/Zrzzn/5g6wIq
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2584.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39860400002)(396003)(366004)(376002)(346002)(122000001)(71200400001)(55016002)(7696005)(186003)(83380400001)(38100700002)(8676002)(9686003)(4326008)(26005)(478600001)(5660300002)(66574015)(6506007)(86362001)(53546011)(76116006)(966005)(54906003)(110136005)(64756008)(66446008)(66946007)(66556008)(166002)(21615005)(66476007)(33656002)(2906002)(30864003)(52536014)(316002)(9326002)(8936002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: hNQKuQSLJNgtCAewFb0ZrAcfP5o3z86W9gyZuxFqCmt0CzwMNYDfFDZLhKVVQeG2EqT/1WVxLTR9E9Ejr3XQWEs0Y8/mFRuPuG/hlHC9UTXn9CctIUV2oxn9zVMG7YsSdXoaQOEbyc1rFeUy+p3w62s/36F/FK5BzaKj8FN5S1NJRtytWacYwQ/1Ng7QJhB2rO26tQLvAuuDCp9KxCN0yfVE46mWOpxaK2SlaDVza9ZL5OJ9OROjgxeqP1f+2jdxWCDSOppRLShkascg2fEOob9n4GD7HLCp62dRmhj97ivOabjUv9VpDiaAUXs2e5qLE+TgPt3wL7B9KMekyUeybdqV0IVVtb1ANBgwqtfvjdY7MF9lNdgxhNzYvstI2tXjIUG7I1fTebZZkZOTrVAnA+TRjnXxUz4gGVpDeL8qvMuyergG7W9Aa+xCLg+Zots7X4wJ6o6fUB9YYqB4DtbtbyTGYCdM+PXwCUiiwR2EuBDmMYKnmRQ/fJdTQimPUQdYPRfPJo0x8HshZjLJXVo66fAySQqtPGiC8WtzdvCr1UWFFlvoHj/M+z2kpjtw0XOPsoCEFS0+KXNGcJhyYU1zY9KyHIUk/5ENbcIAfpO5zMH7oszU6eudaKw3u8AzFhMt+mp4Nkuib9Cpbmi5ebQ46baSNR18rXoorqAhcUwH7/Xv5I5F6Bj35sfecTz91Nm6pQjXqEpcKf2ba8AdBpv2BwoLIWbrNBKSd4TBQEf8QdzqTUMcq4fDaztToQRlIsCY91dW63wv7ZPtUSbwqrH7EIi+nz0IpUBizwOeRU1wCRDwXKq0ARuRdIPQT1oj4HlOUcj6dsOgQ5GEbJ/0Nv0gycUGfzimLwQuV12MdK97XUy1SyjehfVfTu1e/0htOj9DX4YoZO4E1SH36Nkx81zqXrjOg8DxrMwzUSaLwgSk6o+I//6PWQeWWEGqMN0le5DCf4TTnN9Cjf7loCCXfIuDdP1pBmsv8sZkLCjbd/KHvq/KnZO3rd1J6CaxfG9cR1Tpsv6+JpKdHh3+YWGEE4hugh/PAnvCervWEEfk2+u44CnwvuoNbQunSeSMpar3moZX6ZozRsHIIwzumDgLGnH5ESvkirHVkIRJwTwuAuWIWKApOfgYG+9BiYAFpf0oG1Zj2rHu6FVLVGkeNcVpfDlnrPgMMVzxYCfnp1E1zR/WPQXKDAMVjDh54HEiWN/sRV+uHqAKIg1bPs3EqafmQwztQFoAXofzixV8aDOyg66UT032LRUnXAfwP6JK5BjV4m5mgrNvcG1c1Iqju6Ns2UE9CPwqlB9sG2gXG4E+6AE7I7A37R4lWsYmazGzELyka3UF
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BYAPR11MB2584412CC953DF89583FC53CDA429BYAPR11MB2584namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2584.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9e3eec70-0ce6-4282-0886-08d9088b00e2
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2021 08:12:15.6676 (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: ozT5K3xTwwAQnFMAdvkydGe1O7Dsas9tEFNWNdCtVvHRJCv8Bni53OJeg8tTxxCoqywKNuawCJdt/Ibfg+hhQw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB4912
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.16, xbe-aln-001.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/ezGYZ_-5BdCczBHUz8RfqGUAaiU>
Subject: Re: [ippm] Francesca Palombini's Discuss on draft-ietf-ippm-ioam-data-12: (with DISCUSS and COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Apr 2021 08:12:25 -0000

Hi Francesca,

Another follow-up on your point 9. (new registries). Looks that I misread your comment: You were asking why the registry uses “RFC Required” (RFC 8126/section 4.7) and not “IETF Review”  ” (RFC 8126/section 4.8). I missed the “Review” word and got confused. TBH – given that current work, to define additional Flags, Option-Types, etc. are all following the “IETF Review” process already, i.e., there are working group drafts in IPPM for those, it would be very straight forward and even more natural to change to “IETF Review”. Given that you suggest the change, we’ll change to “IETF Review” in the next revision.

In addition – per what I already mentioned below, we’ll add templates per Murray’s suggestion. Suggested text:

IOAM Option-Type Registry

IOAM Option-Type Registry template. New registration requests MUST use the following template:

  Name:
     Name of the newly registered option type.

  Code point:
     Desired value of the requested code point.

  Description:
     Brief description of the newly registered option type.

  Reference
     Reference to the document that defines the new option type.

The templates for the other registries would look very similar. The only difference would be for the namespace registry.

IOAM Namespace-ID Registry

IOAM Namespace-ID Registry template. New registration requests MUST use the following
Template:

  Name:
     Name of the newly registered Namespace-ID.

  Code point:
     Desired value of the requested Namespace-ID.

  Description:
     Brief description of the newly registered Namespace-ID.

  Reference
     Reference to the document that defines the new option type.

  Status
     Status of the registration: Permanent or Provisional.
     Namespace-ID registrations following a successful expert review will have the status "provisional".
     Once the RFC, which defines the new Namespace-ID is published, the status is changed to "permanent".

Thoughts?

Thanks much, Frank


From: Frank Brockners (fbrockne) <fbrockne@cisco.com>
Sent: Freitag, 23. April 2021 20:25
To: Francesca Palombini <francesca.palombini@ericsson.com>; Martin Duke <martin.h.duke@gmail.com>
Cc: The IESG <iesg@ietf.org>; MORTON, ALFRED C (AL) <acm@research.att.com>; IPPM Chairs <ippm-chairs@ietf.org>; draft-ietf-ippm-ioam-data@ietf.org; IETF IPPM WG <ippm@ietf.org>
Subject: RE: Francesca Palombini's Discuss on draft-ietf-ippm-ioam-data-12: (with DISCUSS and COMMENT)

Hi Francesca, Martin,

Sorry for the delayed response. Please see inline (…FB):

From: Francesca Palombini <francesca.palombini@ericsson.com<mailto:francesca.palombini@ericsson.com>>
Sent: Freitag, 26. März 2021 12:04
To: Martin Duke <martin.h.duke@gmail.com<mailto:martin.h.duke@gmail.com>>
Cc: The IESG <iesg@ietf.org<mailto:iesg@ietf.org>>; MORTON, ALFRED C (AL) <acm@research.att.com<mailto:acm@research.att.com>>; IPPM Chairs <ippm-chairs@ietf.org<mailto:ippm-chairs@ietf.org>>; draft-ietf-ippm-ioam-data@ietf.org<mailto:draft-ietf-ippm-ioam-data@ietf.org>; IETF IPPM WG <ippm@ietf.org<mailto:ippm@ietf.org>>
Subject: Re: Francesca Palombini's Discuss on draft-ietf-ippm-ioam-data-12: (with DISCUSS and COMMENT)

Hi Martin,

Yes, 5. In the COMMENT, about referencing normatively IEEE 15888. This was a “discuss” DISCUSS: as I said yesterday in the telechat, I do believe there is unfinished business about normatively referencing documents behind a paywall and wanted to bring this to the IESG attention, but I will not block the document because of it. I do think it is worth considering in this document if the normative reference is necessary, as it feels optional by context.

11. to me feels more important to fix. Also I did not include 8. In the DISCUSS part, but I’d really like a response to that one as well. The rest are less important – clarifications and points raised to make sure the WG had a discussion about them.

Francesca

From: Martin Duke <martin.h.duke@gmail.com<mailto:martin.h.duke@gmail.com>>
Date: Thursday, 25 March 2021 at 18:49
To: Francesca Palombini <francesca.palombini@ericsson.com<mailto:francesca.palombini@ericsson.com>>
Cc: The IESG <iesg@ietf.org<mailto:iesg@ietf.org>>, "MORTON, ALFRED C (AL)" <acm@research.att.com<mailto:acm@research.att.com>>, IPPM Chairs <ippm-chairs@ietf.org<mailto:ippm-chairs@ietf.org>>, "draft-ietf-ippm-ioam-data@ietf.org<mailto:draft-ietf-ippm-ioam-data@ietf.org>" <draft-ietf-ippm-ioam-data@ietf.org<mailto:draft-ietf-ippm-ioam-data@ietf.org>>, IETF IPPM WG <ippm@ietf.org<mailto:ippm@ietf.org>>
Subject: Re: Francesca Palombini's Discuss on draft-ietf-ippm-ioam-data-12: (with DISCUSS and COMMENT)

Hi Francesca,

Which "Point 5" are you referring to in your DISCUSS? Is it the fifth item in your COMMENT?

On Wed, Mar 24, 2021 at 12:05 PM Francesca Palombini via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote:
Francesca Palombini has entered the following ballot position for
draft-ietf-ippm-ioam-data-12: Discuss

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-ippm-ioam-data/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for this document. I think that the discussion on point 5. about
referencing normatively IEEE 1588, and 11. about IANA Expert guidelines are
worth having, and hope we can get them cleared before the document moves
forward. Also, please find some minor comments below.

Francesca


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

1. -----

   document are to be interpreted as described in [RFC2119].

FP: Please update the boilerplate as per RFC 8147.
…FB: Thanks. We’ll fix this in the next revision.


2. -----

  The specification of how IOAM-Data-Fields
   are encapsulated into "parent" protocols, like e.g., NSH or IPv6 is
   outside the scope of this document.

FP: This sentence (or equivalent) appears several times - at least 2 times in
section 4 and once more in 5.1 - please consider removing the repetition.
…FB: Thanks. We’ll remove this repetition in the next revision.


3. -----

      For example, if 3 IOAM-Trace-Type bits are set and none of them
      are wide, then NodeLen would be 3.  If 3 IOAM-Trace-Type bits are

FP: As this is the first time the term "wide" appears, it would be good to
define it and add a reference. Alternatively, a sentence in the terminology
might have helped too.
…FB: The term “wide” is indeed confusing, given that it is used in section 5.4.1 before even the associated data types have been defined. Per your suggestion, we’ll add an explanation of the term, with reference to the associated data fields.


4. -----

      Bit 3    When set, indicates presence of timestamp subseconds in

FP: Same as for 3. - please add a reference to where "subsecond" is defined.
…FB: Another good catch. “Subseconds” are what other documents refer to as “fraction”. Would you be ok do a global “s/subsecond/fraction/” and refer to RFC8877?


5. -----

   formats; based on either PTP [IEEE1588v2], NTP [RFC5905], or POSIX
   [POSIX].  The three timestamp formats are specified in Section 6.  In

FP: Is the normative reference to IEEE 1588 (behind a paywall) absolutely
necessary? Rob Wilton pointed out that maybe a normative reference to RFC 8877
would be enough, however that would create a downref since 8877 is
informational. Also (minor) if kept, please consider updating to IEEE 1588-2019.
…FB: Rather than “referencing documents behind a paywall” as you say above, we can indeed use a reference to RFC 8877 instead. While it would formally be downref as you say, from a pure content perspective, we’d only leverage RFC 8877 in that it documents the PTP timestamp format.


6. -----

         computation, indicates which POT-profile is used.  The two
         profiles are numbered 0, 1.

FP: (just a comment) I found strange at this point that although two profiles
are mentioned, only one is defined in this document.
…FB: There might be a bit of a confusion here. Section 5.5.1 defines the IOAM Proof-of-Transit Option Type 0. The Option-Type differs from the POT-Profile. POT-Profiles are defined in draft-ietf-sfc-proof-of-transit. For the use of the POT-Profile flag, see e.g. section 5.1 in https://tools.ietf.org/html/draft-ietf-sfc-proof-of-transit-08 - the flag is used to flip between “even” and “odd” profiles.


7. -----

   Namespace-ID:  16-bit identifier of an IOAM-Namespace.  The

FP: Each option-type starts with Namespace-ID: couldn't this be optimized, or
what is the reasoning behind this?
…FB: Given all the other comments on IOAM namespaces, we’ll add some additional explanation of  the role of namespaces. The role of namespaces is to provide additional context to IOAM data fields - something that would be quite difficult to tie to a key which is likely going to be per node and potentially even per packet, depending on what scheme we'd use. The draft is pretty explicit about namespaces: “IOAM-Namespaces add further context to IOAM-Option-Types and associated IOAM-Data-Fields.".
Given that IOAM-Data-Fields are always interpreted the context of a specific namespace, the namespace field always needs to be carried along with the data-fields themselves.


8. -----

               IOAM domain.  Within the IOAM encapsulating node, the
               time that the timestamp is retrieved can depend on the
               implementation.  Some possibilities are: 1) the time at

   in one of three possible timestamp formats.  It is assumed that the
   management plane is responsible for determining which timestamp
   format is used.

FP: This is worrying for interoperability within different implementations.
Maybe more details or guidelines about how the management plane deals with this
(or references to relevant specification for which this is in scope) would help.
…FB: The main logic that IOAM follows is to keep the effort on network elements performing the packet forwarding to a minimum. I.e., have the network elements just gather the information – and perform translation/conversion of units on the network-management/analytics systems which would process the IOAM data. Given that there are different timestamp formats in use by different implementations, the operator can choose to use the timestamp format natively supported by the network element. Differentiation between different timestamp formats can easily be done by the use of proper associated namespace ids. Thus there wouldn’t be an interoperability issue. Different nodes would record the information in their preferred format – and the unit conversion would happen in the backend, which processes the data.


9. -----

   New registries in this group can be created via RFC Required process
   as per [RFC8126].

FP: (asking as this was not included in the shepherd review, and just want to
make sure this was addressed) For this and following registries: what is the
reasoning for not going for IETF Review?
…FB: Sorry, but I’m not entirely following. The suggestion is to follow the process defined in section 1.3 of RFC 8126 – assuming that the draft moves to RFC, and thus completes IETF review. Are you suggesting to follow a different process than what is stated in RFC 8126?


10. -----

   The meaning for Bits 1 - 7 are available for assignment via RFC
   Required process as per [RFC8126].

FP: From section 5.5 the bits 1-7 are indicated as Reserved.
…FB: Thanks. This is a really good catch. Section 5.5 shouldn’t list the fields as reserved. The next revision is going to correct that.


11. -----

   of the current document.  Registry entries for the values 0x8000 to
   0xFFFF are to be assigned via the "Expert Review" policy defined in
   [RFC8126].  Upon a new allocation request, the responsible AD will
   appoint a designated expert, who will review the allocation request.
   The expert will post the request on the mailing list of the IPPM
   working group in the IETF (ippm@ietf.org<mailto:ippm@ietf.org>), and possibly on other
   relevant mailing lists, to allow for community feedback.  Based on
   the review, the expert will either approve or deny the request.  The
   intention is that any allocation will be accompanied by a published
   RFC.  But in order to allow for the allocation of values prior to the
   RFC being approved for publication, the designated expert can approve
   allocations once it seems clear that an RFC will be published.

FP: The text above indicates Expert review for the registry. According to RFC
8126:

   The required documentation and review criteria, giving clear guidance
   to the designated expert, should be provided when defining the
   registry.  It is particularly important to lay out what should be
   considered when performing an evaluation and reasons for rejecting a
   request.

Although the paragraph above gives some indication of process for the experts,
it does not give clear review criteria or guidance. I would suggest this to be
expanded to give more indication to experts on what criteria to consider -
these same criteria will be considered by the working group as well.
…FB: Agreed. This can indeed be improved. Would Murray’s suggestion work for you? Murray suggested to include a template in the document, that a new registration would need to include. That way, it would be clear what data is expected to be provided – along with the criteria for acceptance.

Thanks much – and sorry again for the delay.
Cheers, Frank