Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

"Jan Lindblad (jlindbla)" <jlindbla@cisco.com> Tue, 11 April 2023 14:05 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 68A22C1522D9 for <netmod@ietfa.amsl.com>; Tue, 11 Apr 2023 07:05:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=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="i1QyIfbF"; dkim=pass (1024-bit key) header.d=cisco.com header.b="fReU0h2w"
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 rw_FeKxoxXOL for <netmod@ietfa.amsl.com>; Tue, 11 Apr 2023 07:05:37 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58CC9C1522C2 for <netmod@ietf.org>; Tue, 11 Apr 2023 07:05:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=67997; q=dns/txt; s=iport; t=1681221936; x=1682431536; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0Q9uuziPH7/Pb23LCVilI2Mzw8YB1pKFzW/8M3JEL0E=; b=i1QyIfbFuxHLAGvCnYKs4gp7W72o3B53XSDl+c3Bm7HvkQOCMqRKG+l/ Tpnfy6ko1CMOh3mxUgSXy5wG39drQQjep0n4IIeszu64iNgDyxSJW1RfI VlmyScApHvaoNPo4Z136ENjNMUdMcMgK9KxkNAMYOqZn7iaubskZhfMo7 g=;
X-IPAS-Result: A0ADAAC3aDVklxbLJq1aGgEBAQEBAQEBAQEDAQEBARIBAQEBAgIBAQEBZYEWBQEBAQELAYEqMVJzAlkpEkaEUoNMA4RPX4gwA5EfjD6BJQNWDwEBAQ0BATsJBAEBhQYCFoUnJjQJDgECAgIBAQEBAwIDAQEBAQEBAwEBBQEBAQIBBwQUAQEBAQEBAQE3BRA1hWgNhgMBAQEBAxIICR0BASoNAQ8CAQgRAQMBASEBBgMCAgIwFAMGCAIEDgUbB4JcAYIVRwMBD6AGAYE/AoogeoEygQGCCAEBBgQFgU1BnRMDBoFBAYkeAQGIGUKBSUSBFSccgWaBAT6CYgEBAgGBRRcuCYMlOYIugiyIEIFeglCLRAqBNHaBIA5Kc4EEAgkCEWuBEAhmgXlAAg1kCw5xgUmDKgQCFDQHNgMJAwcFLB1AAwsYDRY6Eyw1FB8GWGwtEhIFAwsVKkcECDgGGzQRAggPEg8GJkQOQjczEwZcASkLDhEDT0IZbAQvgVoKBgEmJJwcgVwRWwYBPSYEIg0MCA4CBBxbFjIUAwQHEwUGAQIsCAMRKZIrBxQygx6KSYQRnk0Kg36LcpUVBC+DfYxmhmuFDowEYpdzjVOVEgsNAQFMhCsCBAIEBQIOAQEGgWM6gVtwFWUBgjw/ExkPjiAMDQmDUIUUimV1AjsCBwEKAQEDCYZGgigtgUxeAQE
IronPort-PHdr: A9a23:FuBdgRdojXlsoShGJPEhekptlGM/foqcDmcuAtIPgr9UN6O78IunY ArU5O5mixnCWoCIo/5Hiu+Dq6n7QiRA+peOtnkebYZBHwEIk8QYngEsQYaFBET3IeSsbnkSF 8VZX1gj9Ha+YgBOAMirX1TJuTWp6CIKXBD2NA57POPwT4zWjsK73eS705bSeA5PwjG6ZOA6I BC/tw6ErsANmsMiMvMo1xLTq31UeuJbjW9pPgeVmBDxp4+8qZVi6C9X/fkm8qZ9
IronPort-Data: A9a23:9YAWLqjCHVulFRJmLmda5HNeX161ARAKZh0ujC45NGQN5FlHY01je htvWW7TPvaNZGqjctF2bou/9U1Tv5PWyIdhGlBr/H1gFi5jpJueD7x1DKtf0wB+jyHnZBg6h ynLQoCYdKjYdleF+lH1dOKJQUBUjclkfJKkYAL/En03FF8MpBsJ00o5wLZl29cw27BVPivU0 T/Mi5yHULOa82Yc3lI8s8pvfzs24ZweEBtB1rAPTagjUG32zhH5P7pDTU2FFEYUd6EPdgKMq 0kv+5nilo/R109F5tpICd8XeGVSKlLZFVDmZna7x8FOjzAazhHe3JrXO9IbcWcNsB6oz+t/5 +xXrr7sahclEYblzbF1vxlwS0mSPIVP9aWCKn+lvInPiUbHaHDrhf5pCSnaP6VBpb0xWjEIr 6RDbmpXBvyAr7reLLaTSO1tgMgpKMDDN4IEsXYmxjbcZRojac6THvuTtIYwMDEYj9lSDfbVQ eYjOAF9YhSeP0BKZw0KIcdr9AuvriCvL2IHwL6PnoIx7nTWywBZ0bXxPpzSYNPieClOtk+Vv CfH52PjHlQcPcDZwjue+XXqjejK9c/mZG4MPLqg1qRRq3zD/WI8MQcNdweYsfWWoWfrDrqzN Hco0iYpqKEz8mmiQd/8QwC0rRa4Uvg0BoI4/woStVnl90bE3+qKLjVcFmMRNLTKoOdvFG1xi gXhc8bBXGQ36NWopWShGqC8lRfa1cI9DnULZigbJefuy4K65dlr3nojov5HHbWug8e9ITb0y jaGxBXSZon/b+ZWjc1XHnie3VpAQ6QlqSZvv23qspqNtF8RWWJcT9XABaLnxfhBNp2FaVKKo WIJncOThMhXU8HUzXHUHL9STevzjxpgDNE6qQMwd3XG32nyk0NPgagLiN2DDB4za51dKWOBj LH76FkKjHOsAJdaRfYnP93uYyjb5aPhDt/iHuvFdcZDZ4MZSeN01H8GWKJk5Ei0yBJEufhmY f+zKJ/8ZUv2/Iw6lVJasc9GiuR1rs3/rEuOLa3GI+OPiODONC7KF+pabDNjrIkRtcu5nekcy P4GX+OiwBREW+q4aS7SmbP/53hTRZTnLfgac/BqS9M=
IronPort-HdrOrdr: A9a23:j9FeXq7Pom3HNfYGFwPXwWOBI+orL9Y04lQ7vn2ZFiY0TiXIra GTdaoguyMc0AxhJk3I+ertBEGBKUmsk6KdkrNhTItKPTOW91dASbsSjrcKrAeQYREWmtQtsZ uINpIOd+EYbmIKw/oSgjPIburIqePvmMvD6Ja9vhJQpENRGt1dBmxCe3+m+zhNNXJ77O0CZe KhD6R81l2dkHIsAfiTNz0gZazuttfLnJXpbVotHBg88jSDijuu9frTDwWY9g12aUIO/Z4StU z+1yDp7KSqtP+2jjXG0XXI0phQkNz9jvNeGc23jNQPIDmEsHfqWG0hYczBgNkGmpDq1L8Yqq iKn/7mBbU015rlRBDxnfIq4Xi47N9h0Q679bbSuwqSnSWwfkNINyMGv/MZTvMcgHBQ5u2VF8 lwrjmknosSAhXakCvn4d/UExlsi0qvuHIn1fUelnpFTOIlGfVsRRx2xjImLH4sJlOz1GkcKp gkMOjMoPJNNV+KZXHQuWdihNSqQ3QoBx+DBkwPoNac3TRalG1wixJw/r1Sol4QsJYmD5VU7e XNNapl0LlIU88NdKp4QOMMW9G+BGDBSQ/FdGiSPVPkHqcaPG+lke+73JwloOWxPJAYxpo7n5 rMFFteqG4pYkrrTdaD2ZVamyq9CVlVnQ6dvP22y6IJzYEUHoCbRBFrYGpe5/ednw==
X-IronPort-Anti-Spam-Filtered: true
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Apr 2023 14:05:34 +0000
Received: from aer-opgw-4.cisco.com (aer-opgw-4.cisco.com [173.38.212.136]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 33BE5YeT012756 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <netmod@ietf.org>; Tue, 11 Apr 2023 14:05:34 GMT
Received: from mail-dm6nam04lp2041.outbound.protection.outlook.com (HELO NAM04-DM6-obe.outbound.protection.outlook.com) ([104.47.73.41]) by aer-opgw-4.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Apr 2023 14:05:33 +0000
Received: from mail-dm6nam04lp2041.outbound.protection.outlook.com (HELO NAM04-DM6-obe.outbound.protection.outlook.com) ([104.47.73.41]) by aer-opgw-4.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Apr 2023 14:05:33 +0000
Authentication-Results: aer-opgw-4.cisco.com; dkim=pass (signature verified) header.i=@cisco.com; spf=Pass smtp.mailfrom=jlindbla@cisco.com; dmarc=pass (p=quarantine dis=none) d=cisco.com
X-IronPort-AV: E=Sophos;i="5.98,336,1673913600"; d="scan'";a="26652"
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LN6nWFIcZ22nVfGvWg0rE7OK5yharstmWNskeVv0MpjyaEOuzVq3UzNhs6M/TNpzSiBgveIdagI2HoobH57X8npWqBj07n0JhKi3STdaJa3QuRGHJrcZnxuh4Hrm1XNXtspYPNnHb+yX6TLlsDm02mns3wcN4xkklaqXRobET4tHUNeax6x0wtq4NuB4XuDvnm9Er4IovKwYd8/6m4NhLzVn3LWhFl/HaD6tSbYajZDBr4pjYfjyIRbLjqAX/SwNKhOKjbOpbsYcmHJjA9YqsbF6VOUjAOH3cxSLnJ79MSjQ13SI1/YJ2OJBK9E5U1Urlztst2HWZ5jBh39Rhi4znA==
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=0Q9uuziPH7/Pb23LCVilI2Mzw8YB1pKFzW/8M3JEL0E=; b=PGhS+RkO1bEEkojhW9ewCVb3Vm6KED/y/S4oHlSnhXnShaw676bfaD2zsjSdoDrFuhJZx2XFiZE4UIuzUzFxheK5Dzt3BbOmCGxeUHNUfsEYu1JvURvGx9t7FViUFJDEV3SE4Y3Y8cjRdhKKl98P3ayjxrz3TynjR1ShM/ElolShyRK9MIRAU+ZukKtP/qjfq7WH5krzDiov3ZlXvO6QYcK9W1aABR7q41ZXwyjAXM8+7X+6ch6xPaCXTteT/8QROHLGi830mkMx/Eg77bpGzhoc1Fvk6qO74a8ATgz19I9pI/GHm+HHNn8yPC3Fh7x+OVSRCmTX73SjsW2X0l9VmQ==
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=0Q9uuziPH7/Pb23LCVilI2Mzw8YB1pKFzW/8M3JEL0E=; b=fReU0h2wq/zVsvOkzQQ5OmiYfJ+cJsygnBDMVOJeLRXmRqq+drZqKf6d4l5sG5lLISjpQNrhaXz/hfmQEv0K2q9ntppBOvyyGoWU8CBDfprpTfmClOAaSzCI2pRG3qHDI/6/zOGWCTObt2HkG7XRUjpr7Aw7zz4plpw77xT7BvU=
Received: from DM6PR11MB2841.namprd11.prod.outlook.com (2603:10b6:5:c8::32) by PH0PR11MB5578.namprd11.prod.outlook.com (2603:10b6:510:e7::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6277.38; Tue, 11 Apr 2023 14:05:29 +0000
Received: from DM6PR11MB2841.namprd11.prod.outlook.com ([fe80::16e8:93c9:1706:63e7]) by DM6PR11MB2841.namprd11.prod.outlook.com ([fe80::16e8:93c9:1706:63e7%4]) with mapi id 15.20.6277.038; Tue, 11 Apr 2023 14:05:29 +0000
From: "Jan Lindblad (jlindbla)" <jlindbla@cisco.com>
To: "maqiufang (A)" <maqiufang1=40huawei.com@dmarc.ietf.org>
CC: Kent Watsen <kent+ietf@watsen.net>, "Rob Wilton (rwilton)" <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] Comments on draft-ma-netmod-immutable-flag-06
Thread-Index: AQHZY5/rh0zhQFpk/UKbbJCClVu7/q8ZsYAAgABsQgCAAnOWgIAAWgEAgAKR6ACABrjVAA==
Date: Tue, 11 Apr 2023 14:05:28 +0000
Message-ID: <C2D8A539-4AF9-44FA-92E8-9A9DC6CE7971@cisco.com>
References: <PAWPR07MB92743ED513FA25816935A0E3F0BA9@PAWPR07MB9274.eurprd07.prod.outlook.com> <F534A076-F959-4F03-9E23-6C80A4F0DC58@cisco.com> <ed2f5323329c4d05ab04c8d80866ab71@huawei.com> <59DAD4D3-754D-41E1-A4D4-0CA8FEA263F1@cisco.com> <BY5PR11MB41964C481FCE2619020F1D7AB5929@BY5PR11MB4196.namprd11.prod.outlook.com> <010001874900b5fd-f56744b5-974d-40b2-8177-221a23de41ca-000000@email.amazonses.com> <BY5PR11MB419677D444D44125DD69C91CB5909@BY5PR11MB4196.namprd11.prod.outlook.com> <0100018752302133-19bdf548-f01c-4b78-931e-6be80ec494fa-000000@email.amazonses.com> <b8e370d2ad5042c99c6f0d98345d3c5b@huawei.com>
In-Reply-To: <b8e370d2ad5042c99c6f0d98345d3c5b@huawei.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3696.120.41.1.3)
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM6PR11MB2841:EE_|PH0PR11MB5578:EE_
x-ms-office365-filtering-correlation-id: 960e3099-441e-4eac-ad4c-08db3a95ce33
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: bXy6FKOQv+2FqJU3EYd6cFgX1nLrm1iGrd2+T/isq3oVVKQt/yB7cCU6P7P984YJphEEuXM+QdfCWloYarEz99GT/FMzWj9Igy6PqGW3cBCDrJxFdh8IMNdh24M6l2RgZp1AdnVDH+WUtDgPTPOQRmvuwu83DnbpFknT2OQfEWF1frCfU1Jv3kn4aSL9fswaDI12QS45X69GHjxAjIJGYD4v2IFIdZwgGspe1//BQKiPM4u5cQBkTOiiov38Tz815JHVhr6EzqH1jqHKKmZGIAy5IsUhLZwFaoGMZtRYmKcX5zms8RwrkEzXx+5kL66ey9TTsxJXjFNe1KGIH4txJ7S9vX1dBZZPWx/Y2dz+IXywRnrlwZMJapIVthW1uvE7v97c49FtcSWZ66lBKkmBHZDyCFiDcOrRi3FRonpeP59awJYsui+SE50dZvJFljjL8BzrB25vpOIHxULmNSwGZ8nUBDyytWuPvt4HXyBB67QGmXcfOJ2A707DQOKWln+RAO1pjZ0ZSy00NegMOfuxjmIOoh5SxzQrIACknXLnghz2k5TdTjwWFkVmQJhbG31fERGMAlfORbeVX9I48tS8q8BDa3t3TG6DAU7QzqJAQOGrkncCC679K/hregNkDpGw+jQFyiqT8aqiCvkOmXWxe4KUi9EYAHZ4dy6zQ6ZlVmQ=
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:(13230028)(366004)(396003)(376002)(346002)(39860400002)(136003)(451199021)(71200400001)(478600001)(6512007)(316002)(53546011)(6506007)(186003)(54906003)(91956017)(6486002)(2906002)(30864003)(5660300002)(4326008)(66946007)(76116006)(66446008)(41300700001)(8676002)(66476007)(166002)(64756008)(8936002)(66556008)(122000001)(86362001)(83380400001)(33656002)(36756003)(2616005)(38070700005)(38100700002)(66899021)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: MBRZOJ6z7Z72zNcVy9ePOI2PGX04ZmR+RRUvqwA25fzjhO7oQfi+ra7SIPZU2Ma6gkAXLkodOuiMdM6k5vYaX2gg5VeB2czBcuKDcJBf36KW4Z6NRbUPxrzitSd409pawT4LKf6ytjpXqHAwyxD0htCbj0jyhHZ/YSD8QZxNDnd1UyAfDFjgTknFQBTWDaZGfUp2ab8W6KzlSD+yGcoVPPfsggIWnOB/5VbyZuAUF5Mc9K3DF7V3EMVByTDNQ6fKNk7QEdI0OFF8fuvdWPVSDjnn+qAriLlCeXIfKI0hb+KbxlZnpjV7QovAJImIUhI2Rjrsfyn7gGt2WrjfUnFeg62N7+uj8PoAJfe+1+OTxlpbMr/ITFFx+7XYYu+oSjkhGVg7DYmF7bg5+sRy+dVNhPyZPA/dusSTIzjaOxNNj4XOxWHnZ6935vdsmhmiKjJ9tcDOUWCmjZv01ZyhJVWOY3oWdAKwGYP4p2h8l9C/+Qd6WBBY9S+wJXVVpWRBYH36pnF5MN6W1i3K3EKptfXV2Al8zlMv71Q1oMoOAZCweqpvWJFR9XHobhRli7z935MZNpGO2e/BMAXv7netu6XLERkni61LlxuN7by40azdlFkPtTV+CBPLCKcUO3LCQP4/yybO39MdiO5dhUNP3Z0ORhMiFGjjFyAk4tQ4iTfyzrK+J81GmCwEBby3dWVZZo+RDcnkn7w7BN3V5Iy820nMLg4PK1EokTQCjer4hc7CFtzA19BNk9lfl0A0s48PBpKNj49Qfq9aKTGToeQsB3KcB4HFMTu4pNLs9GpEXYW9A6UaURNlVdm1jdCeIQHurj27xPBNKlBWDeo8AoXN3qiwBl8vpOB2bPn/7Rq2Y3ngR8EVVU3kX7UpqrB+jwxenbAAefQ4N/OnAYlmXA6Rdy+Ws0tD4Nr7fPhqaOvZ9gH2FxQ4NYdh2eUx2a+ICrXyAA1bEIxE5LPugB8/dDOBYlnoUesXocCfsZfeBf0f+BdVE3OAU2cm84EFV9oVb90T+CX6SIh+M3z8AV/T8r6ZzJ9vzQhMvCu2wVo8ZmEHwwyw65BZpW3TbHQeLVBuW1aXrVY8TbBQud4BU41b4v19E3Oyd8atK9/woHSORwzK7E/uprqa5SKiE2GU5ef7Ij42s8HcYT4UeV/Ora3DINUR8ZMitStG5RZeFHBuAvYjfPpdt8HYw3amuS2V388nVrauMsVoVEXxXPUIkQJb8BZDmlt04wn7hscxtyVPOLvl4F/9kcP2DRpaH98mLct/kBxjoGbOHMt2iclkSwWbt16DxXSwLbq6uQxOc/Je6z2NBqIt8lojGMnY01ZXTy96hTMhQTNBW6/RbynI3TkXNvUx6P2EGIfJ5OWMZO/GVjryW/TlfY9ovZaELxrd9vl9O8+cFAU5W60B+Z+7pFZkXUvRWd40XUyzaZB6kvPfPnSldZUPIUZuRUjBBtuKboE9NOs9bCSUj6wp2uot1zebXbyHuIjg6GnxhDDGAwlOrc77odNxEqsga6QvjLeJHq+fNeMs6daU573P5cR7QHS6NAWGXPzBf8TM5ResCdWmLxZJ6Zp6i0ZTRG2gXTO/xwpGZYsTZ4EZj2S+TtYerNC0iUtunMMBKDsKOPFuRZNkKJ/+rP4Q0UF2LJVk7eZvAX2UXim28+Gk
Content-Type: multipart/alternative; boundary="_000_C2D8A5394AF944FA92E89A9DC6CE7971ciscocom_"
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: 960e3099-441e-4eac-ad4c-08db3a95ce33
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2023 14:05:28.6625 (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: klctTBhseyd1Fuj4DMKs8WCwWEAk9Dg+Bl4hqiSDia1nNaQlPoNzunTP9yokxPEikzAKig8HLz1UdPc6yaEbRg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5578
X-Outbound-SMTP-Client: 173.38.212.136, aer-opgw-4.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/wSOt_hXMcfsPIMS0a6QaOv2n-bw>
Subject: Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Apr 2023 14:05:42 -0000

Qiufang,

Thank you for your continued work on this. I think the critical point to decide now is which use cases are in and which are out.

If we decide that only the five or six use cases listed currently in -06 are included, I'm quite happy about standardizing some YANG extension and metadata keywords for them. As I mentioned earlier, I think a slightly simpler solution would be sufficient and preferable for the current, rather small and simple set of use cases. If someone prefers the solution proposed in -06 because it better caters for some not yet listed use case, please share that use case so we can see the whole picture and discuss.

I think that regarding the isInvariant concept in the liaison, 3GPP is asking to model the object which cannot be modified once created. While it's just a natural workaround for the clients to first delete it and then recreate with the really desired value, but not requiring that clients must do that.

Objects that cannot be modified once created cannot exist in a transactional protocol. If we introduce such objects, that would seriously detract from the value of NETCONF/YANG (XC/Y). Rather than watering down XC/Y to match the expectations by legacy management protocols, I'd suggest we ask servers that want to advertise themselves as XC/Y servers to add the missing functionality to their implementation. This is not unreasonable, as many, many server implementors have already done so across many industries.

If a particular vendor is unable or unwilling to implement a server to industry expectations, there is no way for me or anyone to prevent that vendor from releasing a YANG module with some proprietary extensions to describe that behavior. In fact, several already have, and that's probably fine. I just don't understand why IETF should spend valuable time to confuse he market and standardize such backward things. If 3GPP thinks the create-no-modify concept is valuable in the world of automation interfaces, they could release a 3GPP YANG module with such extensions.

As Jan pointed out, all the use cases written in the current document now are targeting configuration cannot be updated or deleted. I also feel it better to define identities to only support our current use cases now, and leave the door open to allow other implementation to extend more if needed.

While I like the flexibility with identities, they would really remove most of the value of standardization in this case. YANG already allows any vendor to invent their own extension keywords. If we standardize a new extension that relies on identities specified by vendors, we have not really gained much.

Again, as mentioned, the objective is to document existing server behaviors, if the server already internally considers some configuration immutable for valid reasons. It doesn't apply to servers which don't have any immutable configuration, much less to encourage servers to add more such restrictions. The document should be updated if it failed to make that clear.

I'm fine with marking some parts of the configuration as immutable/impossible to change. This may cause some operational trouble in the field, but not as much as non-transactionality. It is the non-transactional behavior I find really hard to live with. Let's first decide which use cases we are addressing, then find the least intrusive solution to that set.

Best Regards,
/jan




From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen
Sent: Thursday, April 6, 2023 12:12 AM
To: Rob Wilton (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>>
Cc: Jan Lindblad (jlindbla) <jlindbla=40cisco.com@dmarc.ietf.org<mailto:jlindbla=40cisco.com@dmarc.ietf.org>>; netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

Hi Rob,

My prior response to you focused on what the draft specifies (not the liaison), since you wrote:

"Fundamentally, I generally interpret this draft as saying:  NETCONF/YANG doesn't really match the existing management model/API in 3GPP and hence we want to make non-backwards compatible changes to NETCONF/YANG to match the 3GPP semantics."

Which isn't the draft's proposition.  Maybe you meant s/draft/liaison/?


I just re-read the liaison and I fail to see how the immutable-flag draft's goal of describing existing server behavior isn't aligned with the liaison.  At the end of the day, it doesn't really matter what extensions exist in the YANG, or annotations in the data, the client can send any request it wants to the server and, ultimately, the server must enforce whatever it wants to enforce.

It effectively comes down to a quality-assurance effort to determine if the YANG accurately describes the server's existing behavior.  To the extent that XC/Y tools might someday grok the YANG-extensions and/or data-annotations (to do some of the heavy-lifting) is out of scope, IMO.

I'm unsure if the set of the extensions and annotations in the current draft are robust enough to sufficiently support every use-case.  The WG could create taxonomies and the like to prove this out.  But a possibly better solution is for the immutable-flag draft to define behaviors using identities (instead of bits/boolean), so that 1) we don't have to define a perfect set of flags upfront and 2) applications (3GPP) can define additional flags if desired.

Whilst I agree that it is best for servers to be completely transactional, avoiding the need to delete a parent container in order to recreate a previously-immutable child, 3GPP has already decided to do this.  I see no issue in providing them an ability to capture this semantic using identities they defined themselves.

Kent





On Apr 5, 2023, at 6:49 AM, Rob Wilton (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>> wrote:

Hi Kent,

Some of my concern stems from the fact that during the NMDA architecture discussions there was a strong desire to make the configuration data stored in <running> to be owned by the client.  I.e., the server has the right to accept or reject a particular configuration but ultimately it is the client that should control what is in <running>.  Related to this, is the goal of ensuring the validation of the configuration is based on the state that the configuration represents, not the particular config edit that is being made to transition the configuration into that state.  I.e., it should be possible for a client to change the configuration from any valid state A to any valid state B, without requiring extra client orchestration steps to keep the server happy (e.g., you can transition from A to B, but must go via C, D and E on the way).  Or to put it another way, if such steps are required, then it is much simpler (for an automation client) to do those transitional steps on the server than it is to expose and force them on to the client.

As you point out, existing implementations don’t always follow these rules above, but I regard these as warts in the implementations relative to following the ideal architecture above.  As such, I have little issue with a YANG extension or metadata annotation to programmatically indicate to clients where these aberrations occur for this use case.

But this isn’t what the 3GPP liaison is asking for.  They are requesting to bake the edit-config constraints directly into the management APIs defined in YANG because this is how their underlying management model is defined and they don’t want to change their underlying paradigm.  No longer is YANG just defining the configuration data model, but protocol edit-config semantics are being merged and baked into the data model defining the management API.

These newly defined management APIs will not just work with existing generic YANG clients and orchestrators because I presume that the clients will require custom code to be able to successfully interface with the server implementing these models.  Perhaps these annotations provide sufficient information for YANG clients to generically work around these restrictions?  But even in the case that they do then I still question whether that is really helpful.  I.e., what is ultimately achieved other than the addition of some extra complexity in the automation, and what is the true goal here.  If the aim is to signal to the client that there are some properties that cannot be changed without tearing down the containing service in a traffic impacting way, then rather than marking the properties as being immutable, it might be sufficient to annotate them as service impacting if changed.  This might still provide the necessary visibility and awareness to the client, whilst avoiding additional orchestration complexity for clients.  After all, there are many properties in the network configuration models standardized in the IETF (and OpenConfig) that are similarly service impacting if changed, that don’t seemingly require any protection.

It also feels that we are on the path of fracturing the definition of the NETCONF/YANG management protocols, which is somewhat like how OpenConfig decided to interpret the pattern statement regex language differently (which they have now backtracked on) or their recent statement that servers are not generally expected/required to validate leaf ref constraints in the running configuration.  Each of these little cuts, whilst innocent and good intentioned on their own, risk gradually devaluing the common standards by creating many incompatible subvariants of the language and protocols.

Hence, this is why I think Jan’s approach of looking at the individual problems that are being solved and having a discussion as to what is the best way of solving these individual problems may result in a better overall solution.  Specifically, is there a compromise that can meet 3GPP’s and ITU’s goals without eroding the underlying NETCONF/YANG architecture?

Regards,
Rob

// Still no hats.

From: netmod <netmod-bounces@ietf.org<mailto:netmod-bounces@ietf.org>> On Behalf Of Kent Watsen
Sent: 03 April 2023 22:23
To: Rob Wilton (rwilton) <rwilton=40cisco.com@dmarc.ietf.org<mailto:rwilton=40cisco.com@dmarc.ietf.org>>
Cc: Jan Lindblad (jlindbla) <jlindbla=40cisco.com@dmarc.ietf.org<mailto:jlindbla=40cisco.com@dmarc.ietf.org>>; netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

Hi Rob,



- In terms of properties that cannot be changed once written, I would rather see this issue framed more in the direction of it just being extra documentation written in a machine-readable way.  Specifically, using the annotation to give an indication that servers MAY reject requests to create/delete, or change, the configuration, but not requiring that they do so.  I.e., at the data model level, I don't think that we should preclude servers being able to handle this is in a more client friendly way (e.g., by breaking a single client transaction up into multiple internal transactional changes where needed).

I agree that the document does not make it clear enough, but this is already the case.   As I said at the end of this document's presentation on Friday's NETMOD, session, this document has no runtime-impact on servers (other than them needing to return annotated YANG and/or metadata).  There is also no runtime-impact on clients, as they as free to ignore all the annotations and metadata.   All this document does is define a mechanism for servers to describe the behavior they already implement.   The text in the document is confusing because the normative statements make it sound like the server needs to implement behavior to reject certain updates *because annotations/metadata said so*, but actually it's the other way around, as the server was already implemented to reject the changes.

1st paragraph in the Introduction:

This document defines a way to formally document as a YANG extension or YANG metadata an existing model handling behavior that is already allowed in YANG and which has been used by multiple standard organizations and vendors. It is the aim to create one single standard solution for documenting modification restrictions on data declared as configuration, instead of the multiple existing vendor and organization specific solutions. See Appendix B<https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag#Existing_implementations> for existing implementations.¶<https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag#section-1-1>






- For any immutable related metadata annotations, I think that this additional metadata should only be returned to clients when explicit requested via a separate RPC parameter, and I think that the draft needs to add text for protocol capabilities used to indicate whether this new option is supported (e.g., along the lines of RFC 6243, with-defaults).

Somewhat agree (Principle of Least Astonishment), though it's neither illegal, would cause client problems, or cause excessive network utilization (unlike with-defaults).

K.