[netmod] Re: Comments on draft-lindblad-tlm-philatelist-01

"Jan Lindblad (jlindbla)" <jlindbla@cisco.com> Wed, 12 June 2024 15:12 UTC

Return-Path: <jlindbla@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6B4C1840EB for <netmod@ietfa.amsl.com>; Wed, 12 Jun 2024 08:12:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.594
X-Spam-Level:
X-Spam-Status: No, score=-14.594 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, 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_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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="Li+V+USQ"; dkim=pass (1024-bit key) header.d=cisco.com header.b="Hvv3yMrh"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bF8bxrlUllxU for <netmod@ietfa.amsl.com>; Wed, 12 Jun 2024 08:12:01 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (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 DA3B1C1D876E for <netmod@ietf.org>; Wed, 12 Jun 2024 08:11:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.com; i=@cisco.com; l=46432; q=dns/txt; s=iport; t=1718205117; x=1719414717; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=EJpuS4ZaJm6/8e/UzrFHDzF+OXEZ2Mfh7u0uyAtPypk=; b=Li+V+USQZE7XVlYJygyfUmCWo3qaDI7+twTDjhNkQEV31Abgi2JkO69q P14AlTcHF6JY1yWcHedLFPzpPrA6N2HvXUFsY7Fam1AHdoD7LCkoTvTfS AqRVfkJPw1qgDhJ1AnRurKIcIojC2y8Pwaz5aHRy6CUhYwmz8ANKkligj Q=;
X-CSE-ConnectionGUID: YkMb+3WKSA+ywcUJ8aQrBA==
X-CSE-MsgGUID: ho8H4Q3CSAOtQmVOCxmzuQ==
X-IPAS-Result: A0AwAQBHumlmmJBdJa1RCYEugSqBQTFSegKBHEiEVYNMA4UtiG4DngyBJQNWBwgBAQENAQE5CwQBAYUGAhaIVgImNAkOAQICAgEBAQEDAgMBAQEBAQEBAQYBAQUBAQECAQcFFAEBAQEBAQEBHhkFDhAnhXQNhlkBAQEBAxIRHQEBKBAPAgEGAhEDAQINARMBCQICAi8dCAIEARIIEweCXgGCHEgDARCTC49QAYFAAoooeoEygQGCDAEBBgQFgU9B22cDBoFIiDEBJIExAgKIYycbgUlEgVeBZoECPoJhAQECAYExLh4Ngy46gi+BFYN0HQSBeYcDHYMMQYFNgRyBCINMD4IjCBZZGCiCGYFJUIFMgT9pFiQCC0ODJodXVHciAyYzIQIRAVUTFws+CRYCFgMbFAQwDwkLJioGOQISDAYGBlk0CQQjAwgEAxAyAyBxEQMEGgQLB3eBcYE0BBNHSG8GiWkMgXuBDAIFIYFyJ4ELF4J3S2yBHAKCZoFrDGGIC2OBEIE+gWYBToMGTCWCWB1AAwttPTUGDhsFBIE1BadcBDiDYmoEGA8cBwcCcw1FGgYeAQ81L5JGg32LLUehToE8CoQTjA+VWBeEBZN7gwSOUWSYZSCNVpUWMIUkAgQCBAUCDwEBBoFlOoFbcBU7gmdSGQ+OLQ0Jg1iFFMMIeDsCBAMBCgEBAwmGSIQgAQE
IronPort-PHdr: A9a23:5ad0wBxSDj+BxbvXCzMVngc9DxPP8539OgoTr50/hK0LL+Ko/o/pO wrU4vA+xFPKXICO8/tfkKKWqKHvX2Uc/IyM+G4Pap1CVhIJyI0WkgUsDdTDCBjTJ//xZCt8F 8NHBxd+53/uCUFOA47lYkHK5Hi77DocABL6YAhxJ+L5EIrbp8+2zOu1vZbUZlYAiD+0e7gnN Byttk2RrpwMjIlvIbp5xhrS931PfekXjW89LlOIlBG67cC1lKM=
IronPort-Data: A9a23:pQH8eqncAGGqMqeBToGy0zro5gz/JkRdPkR7XQ2eYbSJt1+Wr1Gzt xIfUDyBa/vfZmD9eNB3O9+/8EoFusDVzoQ3HVNvqHs9RFtH+JHPbTi7wugcHM8zwunrFh8PA xA2M4GYRCwMZiaB4E/rav649SUUOZigHtLUEPTDNj16WThqQSIgjQMLs+Mii+aEu/Dha++2k Y20+5231GONgWYubjpKsvjb8nuDgdyr0N8mlg1mDRx0lAe2e0k9VPo3Oay3Jn3kdYhYdsbSq zHrlezREsvxpn/BO/v9+lrJWhRiro36YWBivkFrt52K2XCukMCdPpETb5LwYW8P49mAcksYJ N9l7fRcQi9xVkHAdXh0vxRwS0lD0aN6FLDvEHuau4/I8G79Wjj93P5TLhE/BJcy07MiaY1O3 aRwxDEldBuPgae9x6i2D7kqjcU4J86tN4Qa0p1i5WiGVrB9HtaSGOOTuYMwMDQY3qiiGd7cY 8sfZTBrZTzLYgZEPREcD5dWcOKA3CijImYI8ALEzUYxy2jUnCwt6ePGC/PyZuWPe+J+jkOKu 1uTqgwVBTlBaYTAkmDamp62vcfJkD/+X446FbCk+LhtmlL7+4AIIAcdWV3+qv6jhwvuHdleM EcTvCEpqMDe6XBHUPHMXDiy4yW7nSU1GMtPGNAYuAi00ID9tlPx6nc/chZNb9kvtckTTDMs1 0OUk96BOdCJmOPMIZ563unOxQ5eKRQowXk+iTjopDbpDvH5q401yxnIVNsmQOi+j8b+Hnf7x DXiQMkCa1c705JjO0aTpAyvb9eQSn7hFVVdCuL/BT/N0++BTNT5D7FEEHCChRq6EK6XT0Oao F8PkNWE4eYFAPmlzXPUELxWRO/2uKfYaVUwZGKD+bF8qFxBHFb+IuhtDM1Wei+Fz+5dIG60O BeD0e+vzMYKZCLCgVBLj3KZUJlykvO6SrwJp9jfb8FFZdBqZRSb8SR1LU+W1CaFraTfuf9XB HtvSu71VSxyIf0+lFKeHr5BuZd1nXpW7T2IGvjGI+GPjOD2iIi9E+lVaTNjr4kRscu5neki2 4wOaZrVlE8PCLKWj+u+2dd7EG3m5EMTXPjeg8dWbeWEZAFhHQkc5zX5mNvNp6QNc3xpq9r1
IronPort-HdrOrdr: A9a23:iGBubKwo/GWVe+yH14XzKrPxZOgkLtp133Aq2lEZdPULSL36qy n+ppQmPEHP6Qr5AEtQ5+xoWJPtfZquz+8F3WBxB8bvYOCCghrLEGgM1/qZ/9SNIVyYygcZ79 YeT0EcMqy+MbEZt7eG3ODQKb9Jq7f3ldHNuQ6d9QYQcegAUdAY0+4NMHfhLqQAfng/OXNWLu v72uN34xCbVTA8aMO9CnMZX+7FieHqufvdCyIuNloM0iXLqSmnxoLbPnGjsyv2VQkh/Z4StU z+1yDp7KSqtP+2jjXG0XXI0phQkNz9jvNeGc2lkKEuW3TRozftQL4kd6yJvTgzru3qwk0tis PwrxApONk2w2/Nf1uyvQDm12DboXYTAj7ZuBylaEnY0InErQEBeo58bEViA1zkAn8bzZNBOW RwriSkXtRsfEr9dW/Glqj1vllR5zmJSDwZ4KAuZ7g1a/pEVFeXxrZvpH99AdMOGjn355sgF/ QrBMbA5OxOeVffdHzBuHJzqebcFUjbMy32C3TqgPblmwR+jTR81Q8V1cYflnAP+NY0TIRF/f 3NNuBtmKtVRsEbYKphDKNZKPHHR1DlUFbJKiafMF7nHKYINzbErIP2+qw84KWvdIYTxJU/lZ zdWBdTtHI0eUjpFcqStac7uCzlUSG4R3Dg28te7592tvn1Q6fqKzSKTBQ0n86ps5wkc7vmsj aISeVr6tPYXB/T8Nxyrn/DsrFpWAwjbPE=
X-Talos-CUID: 9a23:amQN32zlPyubJzM8Ev/QBgUlGeUvMSbi70z5YF6nAltLGLSsU3W5rfY=
X-Talos-MUID: 9a23:RBHcDgjtLVB+XUblXpi1+MMpNMA4w/iXU2s2uLIagsy6EgdgPiWAtWHi
X-IronPort-Anti-Spam-Filtered: true
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-6.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jun 2024 15:11:56 +0000
Received: from alln-opgw-5.cisco.com (alln-opgw-5.cisco.com [173.37.147.253]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 45CFButl010789 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <netmod@ietf.org>; Wed, 12 Jun 2024 15:11:56 GMT
X-CSE-ConnectionGUID: jih3iSVqRs2fgHMXfbzPzw==
X-CSE-MsgGUID: DdHVQOuFTruFVuq44+KZfw==
Authentication-Results: alln-opgw-5.cisco.com; dkim=pass (signature verified) header.i=@cisco.com; spf=Pass smtp.mailfrom=jlindbla@cisco.com; dmarc=pass (p=reject dis=none) d=cisco.com
X-IronPort-AV: E=Sophos;i="6.08,233,1712620800"; d="scan'208,217";a="10731640"
Received: from mail-bn1nam02lp2042.outbound.protection.outlook.com (HELO NAM02-BN1-obe.outbound.protection.outlook.com) ([104.47.51.42]) by alln-opgw-5.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jun 2024 15:11:56 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AkX9voxjlp+fCiGpixgvveGTnovRvPjHPoOvigBNk5z1kaaxeZzTH8k9Y5cnf/BVXIW9hMo7Is/XbQOQi2BhKX3OzqvGeyFUy7UL/3pIyRFjuGib0ZyMMX4zqjYVLP3dspyd4BO1lGXKEBxGfX49JaX6zDJCediyzozdnt7pm6iZRpxlZHGJ4dhI1J+8gWD47qtO5pFmI6Kyy/20IXx6+M96yWtXtX5MBJOdhDYVG877drmkTWH0om/47sE9ZYCCx5Z3iQhdJFb4I6Pq5G3aF0ecbpBqIWdp5fMKdsZnVwebCEiNYL8/Jt1PZcdQiFTYE5choHx57Upff7n8yErvdA==
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=EJpuS4ZaJm6/8e/UzrFHDzF+OXEZ2Mfh7u0uyAtPypk=; b=Eg/u4BdKx7aoSYdv4w6UvzeML/h0twIdCrd4MOZ+OCNmQnDInVTA5WlqStMIp8DzY8G5NfjLigHdLeTyWwMEQCNHEwNsOnoB2l/PLa+tqIjbPwdocdEA/ZpkDdeDsNcTWSVdY5zvPKQzndGLZVXcpmmj5U34FCzngbsu80nMMPjZg4H5af20W2tG0w+7IH4oPTmj77WEGTrxgzBKW68/ZBuvnzKi4+NRKq2ulRoCDP2zmL+mSwjZ3oPIJNaoVD7xFqbwO8xO3pb+lYGE3HV22o70DoDas+8MHynDdI7jI/amq0MqEkpD0KBFyV8xVHP+7QK3MzySW99yT4O34Cj3Yg==
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.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EJpuS4ZaJm6/8e/UzrFHDzF+OXEZ2Mfh7u0uyAtPypk=; b=Hvv3yMrhDcTjbAc90r2UmEaac0vxCqYpuaty0sGLEMO32uu7twaHOo53s60Jx/GsV5N3JaFoFVyOILT+6G6OvkoRN8/zrsnpEXQn6Edv/PKZxZyVQ6Ruh+via/diFCmv8kt4E8WEyLJjUWC5MiM90xuTUmU2oQbENhC5fi/5uGc=
Received: from DM6PR11MB2841.namprd11.prod.outlook.com (2603:10b6:5:c8::32) by MN0PR11MB6255.namprd11.prod.outlook.com (2603:10b6:208:3c4::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7677.20; Wed, 12 Jun 2024 15:11:52 +0000
Received: from DM6PR11MB2841.namprd11.prod.outlook.com ([fe80::d5eb:e654:d468:9327]) by DM6PR11MB2841.namprd11.prod.outlook.com ([fe80::d5eb:e654:d468:9327%4]) with mapi id 15.20.7677.019; Wed, 12 Jun 2024 15:11:52 +0000
From: "Jan Lindblad (jlindbla)" <jlindbla@cisco.com>
To: James Henderson <james.henderson@dataductus.com>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: Comments on draft-lindblad-tlm-philatelist-01
Thread-Index: AQHauDjDr7CNl5Y+1UGMbeERDcLL5rHCj+px
Date: Wed, 12 Jun 2024 15:11:52 +0000
Message-ID: <DM6PR11MB2841C576F42E281A7DE68CAFCAC72@DM6PR11MB2841.namprd11.prod.outlook.com>
References: <GV3P280MB016334543D4D017266A54E7D99FA2@GV3P280MB0163.SWEP280.PROD.OUTLOOK.COM>
In-Reply-To: <GV3P280MB016334543D4D017266A54E7D99FA2@GV3P280MB0163.SWEP280.PROD.OUTLOOK.COM>
Accept-Language: sv-SE, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM6PR11MB2841:EE_|MN0PR11MB6255:EE_
x-ms-office365-filtering-correlation-id: 09fadb99-4d40-4b4b-2611-08dc8af1fd8d
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230032|376007|366009|1800799017|38070700011;
x-microsoft-antispam-message-info: HnYHBuoQvzBttd489tC+KAC+oeHgKmW0zEpgTpLOilx+MYRCCZ+p0+SJO2pANbLteh6cEBff91ABrDBimXLRW/0Nh1VRk4Z/iowfS99sNLkqlFnF8m/bXET/CEy1D/KCAanSJFaEoxQ9UPwrZBIB/gu4SXD3oH6mSK8kMwL+AD1xwUQc5wM7Q62bp9abkN/SIDOKct4xkIRXXNHnhyGlWwDroxzJ/iSKfmvX4dkHiRoTuxMiTE86lYNq/+Labch+LkEP8gAF2VIL/y+nbd08YXSgkQRLLws98n29iOfNYApm/M8jzALpvYAE2+rqZfULT9LvL5MZz9VusizsDImvUaFgw6ci/CXnmQ6SvrmBYUJ8LLHlO/vmQW3a7ROgKjmVDP9fNhFQE57FaQJel+HBweBsVPB3kvfSYpME5NpCGjGzTB91q6f2M5tUYwwktu9VhlgyiiOX4qIH9tvqErnukADWJdb7LdtgTDuligYgpi2C313KkJV1NRf+GzZocxWnDqe5fo1cFuOzusEaXDUNSIQ71KK+a+Wy43ygg7VqUpPpSuAw88rp0bnFkuEfECxeYVjJ++SJKQz7Wc2jpTI2JWhPdfHVXF2hsaTkkkTsv3aHQcNbDhcF9+9guFvc0ROr4pd1cb7jYvcC6MXkw7OjrhQRpGnWAqQaY6C0zZH9dJ5SCXrr9DA82Qu+UgHBJTHa5nt0SgAKDfoy3pKpDfkltGIGeMU85DuU3wXwkV2yrgTtG0RpUdnV6mSf4tIW3b4V08KRcJv9fVGW3tb0chzQr3+wL+ZUpC8iwzAsx6zNORMLb5yaLUKw4jW0d+7LMpCNht+/AZcsRAPflXEW1Qoy3WluKtV1qKhQWee0i90c3N1MwfG2nYxrXg394+6q8h4UC4iyu6o4x3M7Qmi8/4ChaiIFytUoK/GghvOYwzzzK1ZQCBIxH7w/0smd+MVxioMQJRdgl3J/Tx0TDOdtfxn9QfLA+5dLyWPf7pVONsjpkk/JNRpNHH3jIOKphtTOe1RWQuLrq7+BhhWf180XwulOqhWHD52n/DPhrYOc6DxDQz+IJsU+cJRNzYkAixBNvqFgnvnPEHWC8tWFO2z8jbZaelqDg0iG0uP3b3emTp6qf7bzhLqUCnfwS9YxtBrICLER6Em9YuGGc4cCpZkEFlzyWG3ZntRNIUsP+ykUFps8QW24kHrzdLBQOliCsrQMi1H2FHRZGoLyIy2buYWpYAGzYRafRtN3r8YrydjdLqL6w9bzB7+ilTLPB2SA0+RtThmJBX4hyOj55HCCJR9b7R3FLT2EpdHSw8ZxjjxizJGalLXRaxJjFricjuxzUUvTj0D/DTap9K0VnFacN/3TLGoSyECV1WX1PYwAIsLMPmORW6c=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR11MB2841.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230032)(376007)(366009)(1800799017)(38070700011);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: plubJdm1ZKzEpcpuQxhYP8vfNOI1Bs6elTWmKV8w1SZhbeHv3rxLTxpYFGSPjSxiwHqxrymTkci97gnjn4EVBaQRycJJwz4/RyoG3jEydo/Q+nskAHoUC2zSXIfGVHiE0xw9Umagly0xB2+jEg+kbSogwUJJEY+87Q2GCb28yiqFJ05ZL8QEaJYi5QJYZW1GRgee+Xk7j1n97+8m4uHlAYOb9ATSZJa/Y2ssS7SjMleqLmnQzMNph+YNHUWdCPwpGxlmeQSialN0n0BWfeYUAGMsI0JZIqyPi5rvTE/nwvlIt3r6Hrc3I4ZyfOT9AjpvqOU3hcEh5tG3FvVole1FERBEE+MoUp3dBqOZrq13wKVPcNPXpmAJ0X7ngMG4SRLyiV5s13T1dTFdw/KLQT/zZkWUZo/AdMmxGxHcC5BoxUzEVk4j5tAwjvWRBZEhYqDJcHR8q9PsshRtqTIMU7rbr9U+qe8BcCueoKsTscgas9L8PrNrXzlWlGb4HGimgXGh9xGHGpSI871bTPjMewByIX8+R3LLXqZyxOrOJkH+yzT89nKNb3+yejsR5IlkSc6GtRpYV8vLrYNEtPTDbdj8V4ZzdJkgG/BkL3ipyBq4BSb+X9YbmMTxH7sN+GeDTuCtNGQyQxwz3DP4jNUPWrSPbtf+CpUa1peJKop9wrLN+Uf+uW9svgxBx9PGjwgGl28LQW5i/o7cKzDiRQeMb9zfxKPFEm1w0ayPry8Gqlacw+0QgQOieMUENkAcJoQSaxz7aMHY+eThN7AzB0L8hbudHvQ2eycIr8nlApLNP6bOMpD/o1fwQ3wW5oeo+0ISWM5E8p6mzyi4dvig8d7c4CF5hu+m9+XmxwqgoELSfdvRjSuooGGwHcme4bgVjW/J/jDx9rAp/g3KuIwGkxpAWD7s+viY9e+ICK/qdDGFPfQ8fT0f2pG1Z5uXT7+hQczA7tfbkT3NrF6Wee9QJv++Y+oYbeCIwnlPF6IGEXi2ip5iqLMJDxSMi68RFpiF5mWng9sRerVCJP3rOg1WBMYppHThU80Q6oFx5RdaU/XwKrStwaIe7U8SJV39zCF4JUxFCjZR2P0iSHBBgg4DR0mg3z1J4LDmMuQ/cwAl+1NE+eNw3hi2LYYmupfLs7UBwOiZaSZ98B6Ue9cBdC8TmcRuJyXcoGf89MqOhK7ZG5rLBy5/iZYHVPSRpC1OtSKeuoF1Q4nwECX3DJKfvFyoghBfncNPjEb5JTlAAYKyRKT0vxOqLN0/7LkvIHQ3Logh51KOBNaMxkMmDzFLQupha69b1jzzgSDpKj+EDhZyTHH/qa9DGzFigTF11hMknrksPi9odYoDLdJkIlrCg7cefNMZhxwWbydvrMYWP+fgWo0MfTTFG+qzkmFb5I2OQiClTF/4p8T6jzPT3ansRLzf0hVDjZ0ERDfS2zWNjRLDzQ06FHPx7iCGwQuCPUEGRkR1xCtrW+SIMDIusVRJgGFXf0vo7/qrb7PXNpuosBZs2SpmnWzQCHgsi8xqQuQVNw7GaoytjMxSLCqbR6/xAOZ3lhFkJjvr+Qzs/EMaaVn/Lxp2u5oNG5YWlrixtWWWeHic1JdGDqROA28aMmLrIWf1Y75OzRv/Og==
Content-Type: multipart/alternative; boundary="_000_DM6PR11MB2841C576F42E281A7DE68CAFCAC72DM6PR11MB2841namp_"
MIME-Version: 1.0
X-OriginatorOrg: cisco.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB2841.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 09fadb99-4d40-4b4b-2611-08dc8af1fd8d
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2024 15:11:52.5224 (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: +JfCCBV9FGqO5kYP6YXSQsC4MVHkkUT3I8CfNzkzswnOKF5Z+537JRN+HSAmeWL6zkWxT+gMw9kfJKzMgGqK6A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR11MB6255
X-Outbound-SMTP-Client: 173.37.147.253, alln-opgw-5.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Message-ID-Hash: J4NZNWFEY7Z3LQDDGKJ5GHSBPDWFKDC5
X-Message-ID-Hash: J4NZNWFEY7Z3LQDDGKJ5GHSBPDWFKDC5
X-MailFrom: jlindbla@cisco.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-netmod.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [netmod] Re: Comments on draft-lindblad-tlm-philatelist-01
List-Id: NETMOD WG list <netmod.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/qBcXr4FzU1ahxkqWKtzXpGHhIsc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Owner: <mailto:netmod-owner@ietf.org>
List-Post: <mailto:netmod@ietf.org>
List-Subscribe: <mailto:netmod-join@ietf.org>
List-Unsubscribe: <mailto:netmod-leave@ietf.org>

James,

Many thanks for taking the time to review, and for great suggestions!
Comments inline marked [janl].

From: James Henderson <james.henderson@dataductus.com>
Date: Thursday, 6 June 2024 at 19:53
To: netmod@ietf.org <netmod@ietf.org>
Subject: [netmod] Comments on draft-lindblad-tlm-philatelist-01
I have a couple of comments and questions on philatelist. Overall, I think this is important work, and I’m happy to see someone is working on it!

1)

In access-g it seems there is a reason why an identityref for method, and containers with when statements were used instead of a choice with similarly named containers.

The obvious awkwardness of configuring something like:

method get-local-url-once
get-static-url-once url https://bogo

vs:

get-static-url-once url https://bogo

I am curious to understand what reasons went into this decision. I suspect it was for extensibility to make it easier for someone to expand on the available options.

[janl] Exactly. By using a discriminator design (the method leaf) with an identity type, plus containers with detailed settings, it will be easy to expand this model. It would be easy both to add new variants of the already existing methods as well as completely new methods. Let me show an example of each.

Example 1: Variant method

Let’s say someone comes up with a variant of the get-local-url-once where the document fetched by the URL contains information about many different kinds of devices, each under a different section header.

To allow this sort of file to be used, the user would have to additionally configure which section should be read in the file pointed to by the URL. To add this possibility in YANG, something like the following would be required:

module get-local-url-section-once {
   namespace blabla prefix import …

  identity get-static-url-section-once {
    base ietf-tlm-philatelist-types:get-static-url-once;
  }
  augment /ietf-tlm-philatelist-collector:tlm-collector/
    ietf-tlm-philatelist-collector:organizations/
    ietf-tlm-philatelist-collector:organization/
    ietf-tlm-philatelist-collector:device-groups/
    ietf-tlm-philatelist-collector:device-group/
    ietf-tlm-philatelist-collector:accesses/
    ietf-tlm-philatelist-collector:access/
    ietf-tlm-philatelist-collector:get-static-url-once {
      when "derived-from-or-self(../method,
            'ietf-tlm-philatelist-types:get-static-url-section-once')";
      leaf section-heading {
        type ietf-tlm-philatelist-types:something;
      }
    }
  }
}

Example 2: Completely new method

Let’s say someone comes up with a completely collection method, e.g. “SNMP v8” 😊
It could be added like this:

module tlm-snmpv8-subscribe {
   namespace blabla prefix import …

  identity snmpv8-subscribe {
    base ietf-tlm-philatelist-types:connection-method;
  }
  augment /ietf-tlm-philatelist-collector:tlm-collector/
    ietf-tlm-philatelist-collector:organizations/
    ietf-tlm-philatelist-collector:organization/
    ietf-tlm-philatelist-collector:device-groups/
    ietf-tlm-philatelist-collector:device-group/
    ietf-tlm-philatelist-collector:accesses/
    ietf-tlm-philatelist-collector:access {
      when "derived-from-or-self(method,
            'ietf-tlm-philatelist-types:snmpv8-subscribe')";
      // <all the snmpv8 subscription relevant details here>
    }
  }
}

Hope this explains why I did it this way. We may of course decide that we don’t need this level of flexibility, or that we can achieve a sufficient level of flexibility using some other design. This was just my initial proposal, discussion welcome.

2)

For the access-path I noticed that there was not a way to deal with paths that may themselves require a literal dollar sign followed by a literal parenthesis. While this may not seem like a very likely path, it may be technically possible in some systems. I was thinking a more complicated, but also more flexible solution would be to use the IETF proposed standard URI Template https://datatracker.ietf.org/doc/html/rfc6570

I think this might allow the easier construction of some more complicated URIs, and is also simple enough for the usual case, which would be something like:

    /if:interfaces/interface[name='{interfaces_interface_name}']/statistics/in-unicast-pkts

However, this solution has the same problem that there seems to be no way to escape the braces! However, since literal braces are considered unsafe for URIs in general, I think that is the reason, since you can just use percent encoding on the braces for a URI.

I think the challenge is that while access-path may often _be_ a URI, it is not guaranteed to be so. In addition, adding URI Template as a requirement for any implementation does add some challenge although several libraries do exist.

So, I don't think URI Template works unless we can say that the access-path is a URI fragment.

Another option might be to simply document that two dollar signs will be converted into a single dollar sign, or pick an existing standard template language.

[janl] Thanks! I had entirely missed RFC 6570. While perhaps not aimed exactly at our specific use case, I think it will be useful, and certainly better than the home cooked syntax I invented. If curly braces would be needed in the URL, I guess they could always be represented as %7b and %7d. I’ll introduce this in the next draft version, unless someone teaches me why this isn’t a great idea.


3)

For device-groups it may be useful to allow the user to reference some other part of the data model for the definition of some device-group. For example, a path, using the same syntax as the abbreviated xpath syntax used for leafref type in YANG could be used to reference some other set of leafs or a leaf-list. If this could use operational as well as config data, then it would be straightforward to reference for example an NSO device-group member list: /devices/device-group[name='NE']/member.

[janl] Since many people might be using a controller that already has a device-group concept, I certainly understand how referencing pre-existing device-groups could be (very) useful. It’s certainly an interesting and relevant idea, but if that’s the way to build an interoperable standard, I’m not yet sure. For pointing to an existing config true list anywhere in the YANG tree, I think the YANG instance-identifier type would be the best choice. I don’t think we’d want to allow pointing to config false lists, as that would go against one of the fundamental principles of YANG regarding config true references to config false data.

Once again, thank you for the review, this is really good feedback.

Best Regards,
/Jan