Re: [core] Robert Wilton's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT)

"Rob Wilton (rwilton)" <rwilton@cisco.com> Wed, 14 July 2021 09:10 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 109773A19D3; Wed, 14 Jul 2021 02:10:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.595
X-Spam-Level:
X-Spam-Status: No, score=-9.595 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=j3T/rS1+; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Sm0juOOc
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 lFYuiZllgAoW; Wed, 14 Jul 2021 02:10:01 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AB143A1742; Wed, 14 Jul 2021 02:10:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7752; q=dns/txt; s=iport; t=1626253801; x=1627463401; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Y5JgqaWbxWwCHmfOIVomcy7DUIfWtcyoNM7lYTHKuyY=; b=j3T/rS1+FLyBA/SwweFlnpKtfDFp7y2Vee1Je4+ayAMOnBb4dc0iBUDR b0V1vIqR+mF8GSbZO0wxxlP0hxFM6pz0snS9ArKF0AZcUR57xl+cvcaI0 AmDFaqiuiwnKC0MGePPg19GXHNKeF7/0ZSsHehA9jb8KNckfcDiPlA/XM s=;
IronPort-PHdr: =?us-ascii?q?A9a23=3A1S1c4x8TwYilGP9uWMHoyV9kXcBvk679OAIY7?= =?us-ascii?q?p8ujfRFe/fr85fjORnZ4vNgxB/MUJ7A4v1Jw+zRr+j7WGMG7JrA1RJKcJFFW?= =?us-ascii?q?xIfz8lDmQsmDZ2eAEv3IfrvZip8F80RHFNg9muwZE5SHsu2blbOo3q0uDgVH?= =?us-ascii?q?Bi3NQd8KunvXIDIiMHi3OGp8JqVaAJN11KA?=
IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AG4b3saNxV6o82cBcT07155DYdb4zR+YMi2?= =?us-ascii?q?TDiHoRdfUFSKKlfp6V88jzjSWE9Ar5K0tQ5uxoX5PwD080lKQFrrX5WI3DYO?= =?us-ascii?q?CIghrREGgP1/qG/9SkIVyCygc/79YgT0EdMqyKMbESt6+Ti2PUf6dCsbu6Ge?= =?us-ascii?q?KT9J3jJhxWPGZXgtRbnn5E43GgYytLrWd9dP4EPavZwvACiyureHwRYMj+LG?= =?us-ascii?q?ICRfL/q9rCk4+jSQIaBjY8gTP+zQ+A2frfKVy1zx0eWzRAzfMJ6m7eiTH04a?= =?us-ascii?q?2lrrWS1gLc7WnO9J5b8eGRieerRfb8yPT9GA+czjpAV74RHIFqewpF5t1H3W?= =?us-ascii?q?xa1eUkZS1QZvibpUmhJl1d6iGdpTUImAxemkMKj2Xo2kcKZafCNW8H4w0rv/?= =?us-ascii?q?MCTvKR0TtRgPhslK1MxG6XrJxREFfJmzn8/cHBU1VwmlOzumdKq59Zs5Vza/?= =?us-ascii?q?pWVFZql/1WwKqVKuZ1IAvqrIQ8VOV+BsDV4/hbNVuccnDCp2FqhNihRG46EB?= =?us-ascii?q?uKSlUL/pX96UkaoFlpi08DgMAPlHYJ85wwD5FC+uTfK6xt0LVDVNUfY65xDP?= =?us-ascii?q?oIBcG3FmvOSxTRN3/6GyWsKEjGAQO6l3fT2sR42AiHQu178HICouW3bLoDjx?= =?us-ascii?q?9AR6vHM7z64KF2?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B+EgCMqe5g/5NdJa1aHgEBCxIMQIM?= =?us-ascii?q?sUQd3WjcxhEiDSAOFOYhXA5otglMDVAsBAQENAQE1DAQBAYFggnQCF4JgAiU?= =?us-ascii?q?4EwIEAQEBEgEBBQEBAQIBBgRxE4VoDYZFAQEBAQMSEREMAQEpDwsEAgEIEQQ?= =?us-ascii?q?BAQECAiYCAgIwFQgIAgQBEggTB4JQglUDLwEOmzEBgToCih96gTKBAYIHAQE?= =?us-ascii?q?GBASBSUGDQxiCMgMGgRAqgnuEDoJog3onHIFJRIEVQ4JiPoJiAQECAYFFGoM?= =?us-ascii?q?VNoIugh8aWwYBYwQnASkCIA8xMQctPwEOZJEpg0aIbJ8PCoMkijOUGxKCMoE?= =?us-ascii?q?xonaWBoIbihSYVAIEAgQFAg4BAQaBciSBWXAVgyRQGQ6IHIYDDBYVgzmFFIV?= =?us-ascii?q?KczgCBgEJAQEDCYwMAQE?=
X-IronPort-AV: E=Sophos;i="5.84,238,1620691200"; d="scan'208";a="886344109"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Jul 2021 09:09:55 +0000
Received: from mail.cisco.com (xbe-rcd-003.cisco.com [173.37.102.18]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 16E99sMt032517 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 14 Jul 2021 09:09:54 GMT
Received: from xfe-aln-004.cisco.com (173.37.135.124) by xbe-rcd-003.cisco.com (173.37.102.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 14 Jul 2021 04:09:54 -0500
Received: from xfe-rtp-002.cisco.com (64.101.210.232) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 14 Jul 2021 04:09:54 -0500
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-002.cisco.com (64.101.210.232) 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, 14 Jul 2021 05:09:54 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XoN/zSSrH/bAp5bhRn2Xd3iCMD1kMn0ayDUkoNbhDIbGGv4JGZJb3eKNuJ39qp0OMs9LQMqmeLCqTqn08ZLnY3JYXo5y3PICOJ1xIEc/boP6Ex+crFnAMNsoOhKoJjbNhlIwv8QSoPhFYJeuEoD9N3faxaROweQu8I7a0H76zG52rBAsKmoBYW1+qhOazudGWC1dEVn3tI7VSWD4xnRZuW4A6zltZWbLZtlSHpexfp1crHKp0mdAe6bIf5VJFLpaCNmF2FgQHdnGU5grrOBaWE6X3v8/93i8bIg4snRq4twLymQMslyFoS8MdrWdV3t1D0hcJ/kfvUUgy1/2rmP2Bg==
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=Y5JgqaWbxWwCHmfOIVomcy7DUIfWtcyoNM7lYTHKuyY=; b=Gslsqi/jYGhre+3g/VEP/5c6NpPXwCam1xLfx2rZSxm67cFL7RuUTamtGT/fzyGjovH5PelSLoRUH9Sxr13/aTwhJSGMrynCjBqMWWqzxYamz/vUuOZBNwYLU0g+uLab82nPR5fjVTtGecdjcFK0i+rF9HoL2J4PC60K8MpJFXmGEjOufF1Tk88RtfN5TzSQ/mn3Pn73iVc6d+MMyMNGWWHak1qfl8s23Fo76NNebiVWrTC1YrJlJqzV9WF2ZWm3xbJb3UF9EyMVxgxO7e5HLWc0ajT5WJwfxc7kY7f/7x/GPIJD9cA534bwRyyags5jDOy8KeHXNeDplH5UnmR4yA==
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=Y5JgqaWbxWwCHmfOIVomcy7DUIfWtcyoNM7lYTHKuyY=; b=Sm0juOOcoS4K2zVaAVyWEy1cDM1k1BP1bTAJzeX+LDBkJJ75xWQc6yic+CNTFonrbFETqsiswBHH9USXysHzAGFW5H9iTv7vvYbyjik8n7JbgeNpMCp7z3rkoqum3tTkrAm5RyZfz4FiSnjziFg6c67qw8jwd1vII2KQXHXeg2A=
Received: from DM4PR11MB5438.namprd11.prod.outlook.com (2603:10b6:5:399::21) by DM6PR11MB2956.namprd11.prod.outlook.com (2603:10b6:5:64::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.22; Wed, 14 Jul 2021 09:09:53 +0000
Received: from DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12]) by DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12%6]) with mapi id 15.20.4331.021; Wed, 14 Jul 2021 09:09:53 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, The IESG <iesg@ietf.org>, "draft-ietf-core-sid@ietf.org" <draft-ietf-core-sid@ietf.org>, "core-chairs@ietf.org" <core-chairs@ietf.org>, "core@ietf.org" <core@ietf.org>
Thread-Topic: [core] Robert Wilton's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT)
Thread-Index: AQHXeAALE98pHaaPt0GwTNHeUw7K96tBK82AgAAPFvCAAAfIAIAA4oyw
Date: Wed, 14 Jul 2021 09:09:52 +0000
Message-ID: <DM4PR11MB5438DA81DEF22A441A30FB8BB5139@DM4PR11MB5438.namprd11.prod.outlook.com>
References: <162619194652.5730.10916340155265302741@ietfa.amsl.com> <26411.1626197913@localhost> <DM4PR11MB54388A5B0C2305C66A39EE2BB5149@DM4PR11MB5438.namprd11.prod.outlook.com> <17256.1626202824@localhost>
In-Reply-To: <17256.1626202824@localhost>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: eff452da-1520-416c-32fe-08d946a72435
x-ms-traffictypediagnostic: DM6PR11MB2956:
x-microsoft-antispam-prvs: <DM6PR11MB295697E2027B1FBADDBE8770B5139@DM6PR11MB2956.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: 2wiT0Volnq5gYQCGFhCRWoTSKpFQtSAA3bEsJ2QFGoqU8hsyKvL85zTuU7pJhoMvT8tGgHYENzHfozB5jaazyjS6zo+0EV6dTpYxHnGbwhhj8BE/Bf2wdXQ2j1ti/hHLaYzt4n3qKJ3kEkbQQ3I4ZvnelExs58V2uBBVHzKER9mWiaYqXula3sw4gh8M5Aum4Oq5tKFaIl5Bl2Pl/MQ0uY9imCMLWewvRglgSb9FzHwzb9/aVveDCOaIcjb4VMJsoQ9N02VT1xEiS6NgFxqHb0pR6GNS6Sjix/bOxJDEZrNnzdRr4bL0R0nW4NB+bhWcTXQz5Lr80ygfPQhk8O9XvsZvT0pV2qmuCF2ugoRURt3n/0WHEcAN5twMZ9JFx+Uj3O+UApxbq/1TZmHnRn2a2EvH2OBJth3ubKHFFmsBUn/NDQah1R339lZBmUULAzhQC4b4iiEcBl4n7tgdAHnWb4er0OfEdLVb2HvuRYVn8kY3BKBO0czcY7g4r4copKJsulA3m1+OTQm595hefwP/+HN3u1838mwzgQtbznobMNaDYo1Kp+2WFv3ZPOsoD6q+Uogj+sYOaHNBpIHTdONDvDU3lR7QS/bY7T00EgNt8mLU6amltmfMDDsEOw5bqqA6D0nKqc+Ev+phdz7+2gyYlkdsrxBd+jckyG2scWxcUzi5SZk7+IkNSTRKPBMs4ScAemYgcyeda29KNphxKtTJryfzwkkHlEH6nI7dYMHL9rIj3J9xPU+qOZ5upJ1KlPN79ucSEJClziMuXVppr6cWQytXp4syVQ1iyWfYtzu64bo=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5438.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(136003)(376002)(346002)(396003)(39860400002)(86362001)(55016002)(52536014)(2906002)(122000001)(186003)(66574015)(71200400001)(38100700002)(26005)(478600001)(76116006)(6506007)(33656002)(5660300002)(110136005)(8676002)(9686003)(53546011)(66476007)(66556008)(64756008)(66446008)(66946007)(8936002)(7696005)(966005)(83380400001)(316002)(38070700004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?MGYzY3JjaUovM3lneXI4RHFwVW12NFBaT1FNWmpJRkhUT0JYNSsxZUozTFF2?= =?utf-8?B?dmdncWJXbHpEWHo1bC9xRkdyejluUnhON0EzT1ZhaFhEM2xDVXdwdUZ4Ym9w?= =?utf-8?B?cnpRNThpbzZQcEhFNWNJMEhTMWpNWVhjREkyMDJKVHdXd1g0UHpNZjF6cGdx?= =?utf-8?B?WG8yMXo4eFhBZ3pQQ3gwU1diR1I5c1Vyd3hjaTcyc05NYVprZ2hSRVl6Q2hQ?= =?utf-8?B?WGQ3eG5OV1ZGQzRoLzljMWFzVGVta2FPR1IwbjFFS0NSOWk4Qk8vRFBuaE9E?= =?utf-8?B?SEtDaExhRStpRFBVVWQ4YmFpTktiUC9KY2ZrcnRTOUNTU2N3MTcwLzYrV25C?= =?utf-8?B?dnJNV01ER1BzVmZTOWlZNThPc3BpREI2TUk2aGM0QTJkN3UvTWVtN2lyNUNS?= =?utf-8?B?UFN0ODEwNWVPNXhNbGNPNWNPb3lwQVMvVHI5OGdLSEd6VDcrL3duVkl5UUR6?= =?utf-8?B?cGRzTndRZGdMOHRZM2ZjbXVuVi8vSGZuSVkwMm1QZzE4R1RrU3prZ3Fudjhs?= =?utf-8?B?b1FLTEFQTGFhbWI5Rm1EUnROV3VpaExsZDFlNDRNVW1OYlJqYkVQZHBXOWRW?= =?utf-8?B?ZVhoVGxUYmg4bzVHSVR2RmNQdEVicnZQSFVDdnNaa3gyNG4rQjlqTWFoREho?= =?utf-8?B?TlJzRkM4QjNleGxNUEZoeXJ1SkF1a2F6VnRVeXBab0lqZTdwdEZsTFVsTFor?= =?utf-8?B?NUh3SUpMc2hKeFpINWtnTDFJMzZFd3REcXg0a25vL2lqZWxGMldhK2UrNmVB?= =?utf-8?B?TTB6dzFQQlJpRjk4RHZvemllajl0R1h0ckdxTUNKNi9BazJlWFVnOU5qaEs5?= =?utf-8?B?ejcrREI1OFY4aWYvV3FqTjhwWEpheU9VQ2pzYzVnY0J6dUpQc29ZbmR1MWhH?= =?utf-8?B?bEo5MURhMEs1ckh0Nk5TYnJTZEd6MnNHS0tuekZudmxrSkFQUFlZUnZUb3h4?= =?utf-8?B?aWwrUjBaTmkweHJPcG1zTXdLWlFlR2ZJNHBNZk9UZUY1L1E5bk5UaExpS2Ni?= =?utf-8?B?eXR0am5aYXhudTB2Q1cxNnFrRU1YNzUreWtNT0ZOcW1PanFjcTB2SnJWVERm?= =?utf-8?B?WHVaTkR6MnJoMTNvRzd4MVJ0YUZuVTZyMHBkSjE4S09ZdnpGZ2lKRG9WVnZm?= =?utf-8?B?cXZoZHM1RHlhajFkZWJoQ1kvcnBlZE0weHBWV1pEUW83TmxmWitjK0txbktV?= =?utf-8?B?dHBVeWVSdkVXSW9ZNEdOSGNsRkNGcXdSL2hMYVpRMThEN0s1YWN5WDZXcjRy?= =?utf-8?B?TDNCazB3VUdzTG1DZVc4ZWUxbC9ZU05wNWMxUmc5VFE4M2hzQUhnS2JKZWxs?= =?utf-8?B?ODk2SmwyYm9PQXcrdGZrRFVOWlBsemlXVUdlMTlQdWx3YTVLUDlxcWw2MnJp?= =?utf-8?B?cEsvc24wV20rcXBWc2dMQWVHa2ppMWRTd0U0NDRVQTZobmFsUkdPM2RnWG42?= =?utf-8?B?SzdxTktBNXdwRlF1cUR4cytLV2RubXFYUjhEUm5FMUYwb1ZhLzBQNVBKdzhw?= =?utf-8?B?Q0IrRXNnQWVqTnhzYWFDNlVmV05Jb29sMGcvdm4zTlJTVDhOQTlaRDllMjF6?= =?utf-8?B?cXNnNWtKZU9YdWdSOGlZVTZ0MTBKMS9ibXV2UzNlWmhkUFllWTZTOEhTVHky?= =?utf-8?B?TkRDWDAxek9HQzhoNFRXS2VIaEpGalhFQ2x5eFA5V2tPQktDQUI4OEFKUWlI?= =?utf-8?B?YWFhMjkzcmwrUUtwVktLWVBrK3FSU1hjRmpQYkNEQzB5WG04SXZ2NnZiRk1B?= =?utf-8?Q?YM3tx+qwGDo5L6FZHCfza9PMdQ3CXJS1on6GiKE?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5438.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: eff452da-1520-416c-32fe-08d946a72435
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2021 09:09:52.9051 (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: dfNzPR4x7McDu/fALTo7dl3/ZbktfgXM/N/ihD1hHX+OcbPwUARJdXU7MBY+EYK0vds/mi/0Q1R8gvgARzMGOA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2956
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.18, xbe-rcd-003.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/Oj0vpxnDCRuPdIgtdqFt85uBbOQ>
Subject: Re: [core] Robert Wilton's Discuss on draft-ietf-core-sid-16: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Jul 2021 09:10:07 -0000


> -----Original Message-----
> From: Michael Richardson <mcr+ietf@sandelman.ca>
> Sent: 13 July 2021 20:00
> To: Rob Wilton (rwilton) <rwilton@cisco.com>om>; The IESG <iesg@ietf.org>rg>;
> draft-ietf-core-sid@ietf.org; core-chairs@ietf.org; core@ietf.org
> Subject: Re: [core] Robert Wilton's Discuss on draft-ietf-core-sid-16: (with
> DISCUSS and COMMENT)
> 
> 
> Rob Wilton (rwilton) <rwilton@cisco.com> wrote:
>     > leaf foo {
>     > type string {
>     > len "1..20";
>     > }
>     > }
> 
>     > Or the definition of foo could change in a non-backwards-compatible
> way.  E.g.,
> 
>     > leaf foo {
>     > type int32;
>     > }
> 
>     > RFC 7950 basically states that this is not allowed, but these sorts of
>     > changes happens anyway (e.g., vendors fixing bugs, or bugs in standard
>     > YANG models), and the YANG versioning work will allow these sorts of
>     > changes with appropriate mitigations.
>     > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-
> versioning-03
> 
>     > But in all these cases, no new SID should be allocated, or otherwise
>     > you will have two SIDs assigned to the same name/path.
> 
> Encoding towards CBOR, the CBOR wouldn't care that much about the
> change in
> type, as the CBOR is self-describing in that way.
> So maybe it's okay if a new SID is not allocated.
> 
> Where it would be a problem is if the change was from a 1-based count to a
> 0-based count, both encoded as integers.  In that case, I really hope it
> would go from "foo" to "foo-0" or something like that.

Yes, but this isn't an issue specific to SIDs or the CBOR encoding.  This concern should be left to the core YANG specs.

With regular YANG, you have a problem if the client and server are using incompatible definitions of the schema nodes.  This is a known issue, and the solution to this problem is either not do this (e.g., as per RFC 7950 section 11 module update guidelines) or manage this is in a way that the client and server can handle the changes (which is the problem that the YANG versioning work is providing a solution for).

But at the end of the day, a SID is just a more efficient way of encoding the item name within a given module.  I.e., it allows one to use an integer instead of "module-foo:leaf-bar".  It cannot have any semantic beyond that.  If the item name changes then a new SID is allocated.  If the item name stays the same, but the definition changes, then the same SID is used.

Andy's comment also summed this up well.


> 
>     >> > The draft states that if the
>     >> > definition is changed in a non-backwards-compatible (NBC) way then
> a
>     >> > new SID
>     >> > SHOULD be allocated.
>     >>
>     >> True, I assume that this leads to a new YANG leaf name.
> 
>     > Only if the author gives the definition a new name, and from a SID
>     > allocation POV, this is just a new item name in the schema, and hence
>     > needs a new SID.  I.e., the allocation of a new SID is related to a new
>     > item name, not because of changes in a definition.
> 
> I agree that we have a problem enforcing at the pyang sid generation place
> that non-backwards compatible changes need new SIDs.  That sounds like a
> tooling improvement, rather than a bug in the spec.

I disagree.  The spec should only be binding the SID to the schema node name, not its definition.

Otherwise, you will end up with SID files that look like this (if the definition of the hostname has changed):

        {
          "namespace": "data",
          "identifier": "/ietf-system:system/hostname",
          "sid": 1752
        },
        {
          "namespace": "data",
          "identifier": "/ietf-system:system/hostname",
          "sid": 1879
        },
        {
          "namespace": "data",
          "identifier": "/ietf-system:system/hostname",
          "sid": 2011
        },

How does the server know what value to use when encoding it?  Does a client have to handle decoding all these SID values?  Noting that there is no extra information in the SID file to indicate how these should be processed differently.




> 
>     >> > The policy in 7.6 for the "IETF
>     >> > YANG SID Registry" requires an RFC.  What is the mechanism if an
>     >> > individual or
>     >> > open source project wanted to get SIDs assigned for some of their
> YANG
>     >> > modules?
>     >>
>     >> > I.e., should we be defining a separate mega-range, managed by IANA,
>     >> > with just
>     >> > Expert Review or Specification Required so that these modules could
> use
>     >> > SIDs
>     >> > allocated?  Or do you envisage a separate entity taking up the
>     >> > responsibility
>     >> > for coordinating this?
>     >>
>     >> My impression was that there would be a mega-range operated outside
> of
>     >> IANA
>     >> for this (open source, non-RFC YANG module) kind of thing, but I think
> that
>     >> the energy for doing that may have waned.
> 
>     > Okay.  If there is a lack of energy there, do you think that this is
>     > something that we should be asking IANA to manage (i.e., have this
>     > draft separate a separate mega-range for these other modules)?
> 
> So, we should have a second mega-range allocation, with a FCFS
> considerations.  I would be in favour of that.
> (It could also happen in a new document or via some other IESG action.)

Thanks,
Rob


> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide