Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)
"Jan Lindblad (jlindbla)" <jlindbla@cisco.com> Mon, 02 October 2023 14:36 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 41F08C13AE3A for <netmod@ietfa.amsl.com>; Mon, 2 Oct 2023 07:36:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.595
X-Spam-Level:
X-Spam-Status: No, score=-14.595 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_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_FILL_THIS_FORM_SHORT=0.01, T_SCC_BODY_TEXT_LINE=-0.01, 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="LbOV+4EF"; dkim=pass (1024-bit key) header.d=cisco.com header.b="b1n1Rcxc"
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 LUiYtNRs-qlV for <netmod@ietfa.amsl.com>; Mon, 2 Oct 2023 07:36:03 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (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 91BDCC17EB52 for <netmod@ietf.org>; Mon, 2 Oct 2023 07:34:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=57307; q=dns/txt; s=iport; t=1696257277; x=1697466877; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=M0lUoH3SKlftdv6WZutPmQortWm2JMOCq1OGIDob33I=; b=LbOV+4EF71vc4cHeJDwP0LUoGNXohfh5FxAGlA0MXQ1tzSL2Z0bxnftA eCLsB4gfwR0pUgyHXx/jCnbejoj72CBEj4CVbumAtrbhBywx609qJ2gz1 uC+bG+k69bGyi8XESZ6qIYqYAMLg3Wbx0nxHtyD8dZ8x+Nkv6xNcyhU8K 8=;
X-CSE-ConnectionGUID: LpbEW9QtSYuESnqkp1Ttow==
X-CSE-MsgGUID: ZfizPHJnQQKKwhutj+FEyA==
X-IPAS-Result: A0BXAAA61BplmIkNJK1XAxwBAQEBAQEHAQESAQEEBAEBZYEXBgEBCwGBMzEqKHcCWSoSRzGEIYNMA4UtiGMDgn+IXZIgFDBhA1EFDwEBAQ0BAS4BCgsEAQGEQUYCFjQBBAEIhjMCJjUIDgECAgIBAQEBAwIDAQEBAQEBAQIBAQUBAQECAQcEFAEBAQEBAQEBHhkFDhAnhWgNCAEOEIF9hCgBAQEBAwEBEBEEGQEBLAsBCwICAgEIEQQBASEBBgMCAgIZDAsTAQkIAgQOBRsHglwBJYFxFAMxAwEQplIBgUACiih6fzOBAYIJAQEGBAWybAkFgUMBhDSDOxoBaGYBAYU+gngnG4FJRIEVJwwQgWaBAj6CIEIBAYErARIBCRcHEQoLAREJgxQ5gi+EboNiB22CdIIEFS4HBC6BCwwJJl+CQm0qgxk9g36DbSqBCAhdgWo9Ag1UCwtdgRGBJ4EdAgIRJxITR1oWGwMHA1oqECsHBC8bBwYJFhgVJQZRBBcWJAkTEj4EDYFagVEKgQY/EQ4RgkMiAgc2NhlLgSWBOQkVBjtOdhArBBQXbCAIBGofFR43ERIXDQMIdh0CESM8AwUDBDYKFQ0LIQUUQwNHBkwLAwIcBQMDBIE2BQ8eAhAaBg4nAwMZTgIQFAM+AwMGAwsyAzBXSwxsAwkDBwUsHUADCxgNSBEsNRQbBj8oSweiAwoZbYFyEUIZBi4QJgQOIR4GIDs9QgQHHgMCEQYgCy0Djm8JhAUBgyKKeY49k3hvCoQMjAGPFQWGBgQvhAGMb4Qxk15ih3iQOoJPixODdZErCGaELwIEAgQFAg4BAQaBZQE3a3BwFTsqAYI8CTYTGQ+OIAwNCRaDQIJugiaCaYd8djsCBwEKAQEDCYZIgkELgjUBAQ
IronPort-PHdr: A9a23:ig7VWRSSESLHU7AL3yxWFd4HE9pso3PLVj580XJvo7tKdqLm+IztI wmCo/5sl1TOG47c7qEMh+nXtvX4UHcbqdaasX8EeYBRTRJNl8gMngIhDcLEQU32JfLndWo7S exJVURu+DewNk0GUN3maQjqq2appSUXBg25MAN0IurvHYuHjcC20ey4/5T7aARTjz37arR3f 126qAzLvZwOiJB5YuYpnwLUq2FBffhXw24gKVOIyhD74MrxtJI2+CVLsPVn/MlFOZg=
IronPort-Data: A9a23:76CBkqBQ/bbXGBVW/wjjw5YqxClBgxIJ4kV8jS/XYbTApGsk3zFRy WUWCGzVaK3fYGH9e4hyOtmx9ElQusODn95iOVdlrnsFo1CmBibm6XV1Cm+qYkt+++WaFBoPA /02M4SGdIZsCCaE+n9BC5C5xVFkz6aEW7HgP+DNPyF1VGdMRTwo4f5Zs7ZRbrVA357hWGthh fuo+5eEYQf9gWYtWo4pw/vrRC1H7ayaVAww5jTSVdgT1HfCmn8cCo4oJK3ZBxMUlaENQ4ZW7 86apF2I1juxEyUFU7tJoZ6nGqE+eYM+CCDV4pZgtwdOtTAZzsA6+v5T2PPx8i67gR3R9zx64 I0lWZBd1W7FM4WU8NnxXSW0HAlaJadrx+7+PUOOrOGoyVTFayLQ3/JxWRRe0Y0woo6bAElH8 fgebTsKdB3G26S9wamwTa9ngcFLwMvDZdxE/Co+i2iCS699HvgvQI2SjTNc9DU0h8ZCF/LXT 8EYcjFoKh/HZnWjP39OVs9nw7fy2iiXnztwmlyUt5IXwW7q9S9Sz7jwLNiWVPGbbJAA9qqfj juWozumav0AD/SZxCaA9X6Eh+LTk2X8Qo16KVGj3vduhFvWzWsJBVhKE1C6uvK+zEW5XrqzN nD45AIKtaIfyx2SUuLMQjCDpmeHpkcgR91PRrhSBB629oLY5AOQB24hRzFHacA7uMJeedDM/ gLQ9z8OLWEy2IB5WU5x5Z/P9mvqYnJ9wXsqIH5aEFdev7EPtalu1nryosBf/LlZZzEfMQ7hx zGHxMTVr+pO1Z9bv0lXEKyuvt5BjpHNSghw7QLNUyf5qAh4f4WiIYev7DA3DMqszq7HFTFtX 1BdxKByCdzi67nWyERhp81WTNmUCw6tamG0vLKWN8BJG86R03CiZ5tMxzp1OV1kNM0JERewP h6N4FMMvMQOZSv6BUOSX25XI5l6pUQHPYq9Ps04kvIVCnSMXFbdpXo3NRL4M57FyRVywcnTx qt3ge71XSpFVsyLPRK9RvwW1vcw1zsiyGbILa0XPDz5uYdykEW9EO9fWHPXN7hRxPrd/G39r Y0FX+PUkEo3bQELSnSNmWLlBQpUfSFT6FGfg5E/S9Nv1SI/QzFxUKCLmelxE2Gn9owM/tr1E riGchYw4HL0hGbMLkOBbXULVV8ldc8XQa4TVcD0AWuV5g==
IronPort-HdrOrdr: A9a23:vhXxMKC4z2Ev1JHlHejqsseALOsnbusQ8zAXPh9KOH9om52j9/ xGws576fatskdhZJhBo7y90KnpewKkyXcH2/hgAV7CZniphILMFvAB0WKM+UycJ8STzJ876U 4kSdkBNDSSNyk6sS+Z2njFLz9I+rDum87Y4Ja7854ud3AUV0gK1XYANu/vKDwNeOAwP+tDKH Pz3LsgmxOQPV4sQoCQAH4DU+Lfp9vNuq7HTHc9bSIP2U2ltx/tzKT1PSS5834lPg+nx41MzU H11yjCoomzufCyzRHRk0XJ6Y5NpdfnwtxfQOSRl8k8MFzX+0WVTbUkf4fHkCE+oemp5lpvus LLuQ0cM8N67G6UVn2poCHqxxLr3F8Vmj3fIB6j8D7eSP7CNXUH4vl69MRkm9zimhMdVeRHoe Z2NqSixsJq5F377X/ADpPzJmJXfwKP0AgfeKgo/jxiuU90Us4NkWTZl3klSqsoDWb07psqH/ JpC9yZ7PFKcUmCZ3ScpWV3xsewN05DUytv0iA5y7moOhVt7TtEJnEjtYYit2ZF8Ih4R4hP5u zCPKgtnLZSTtUOZaY4AOsaW8O4BmHEXBqJaQupUBvaPbBCP2iIp4/84b0z6u3vcJsUzIEqkJ CEVF9Dr2Y9d0/nFMXL1pxW9RLGRnm7QF3Wu41jzok8vqe5SKvgMCWFRlxrm8y8o+8HCsmeQP q3MII+OY6qEYIvI/cB4+TTYeglFZBFarxghj8SYSP4nv72
X-Talos-CUID: 9a23:eGOouWO5yq40le5DfDFt2XFFI9weQ2Dw93HJIFfhNXpuV+jA
X-Talos-MUID: 9a23:eWtX+QZExa1CdOBThTHtlglCFsFR2oeNF0AQjZdFleSVHHkl
X-IronPort-Anti-Spam-Filtered: true
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-7.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Oct 2023 14:34:36 +0000
Received: from alln-opgw-5.cisco.com (alln-opgw-5.cisco.com [173.37.147.253]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 392EYZcj011763 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <netmod@ietf.org>; Mon, 2 Oct 2023 14:34:36 GMT
X-CSE-ConnectionGUID: UK9UAZ41Qmmj3Ufy3pjDwA==
X-CSE-MsgGUID: 0Wap86zNSYyzKuKPMKIQhg==
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=quarantine dis=none) d=cisco.com
X-IronPort-AV: E=Sophos;i="6.03,194,1694736000"; d="scan'208,217";a="3301291"
Received: from mail-mw2nam04lp2175.outbound.protection.outlook.com (HELO NAM04-MW2-obe.outbound.protection.outlook.com) ([104.47.73.175]) by alln-opgw-5.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Oct 2023 14:34:34 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eHUCX85fEdEKKbES/j3tdihlwIy6REjGgynhNOPxdJVlR5q0j5NvIZShi8UvTBBkgGjkJbBb/cNzKKoixDsOtQa9Hn5Q9cHc0UY0V1prXVlfzzGXTshRvx8SSMnXWkbLZ9ZNVUXJN1YCJZa7Pmu6VfXGxTO7WMy2ZtF8h1CzIN4ZdlZ/oP2TynxfXe7Fl6x0NA8lgsog/D7mglKe+NLFr+BiGouwSjAi5lG2BxfKq86pw43nBzZTP0HmFq3jGXiCIOvc/aZcmrWNPwr1nL2e1X+kzb98+Xb7FjBRmgOdCutGtqArE5/gZnFPOfyK9foulmayrnzM4H6azRc0I1bDCA==
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=M0lUoH3SKlftdv6WZutPmQortWm2JMOCq1OGIDob33I=; b=MIJb50v73KgpdQWh1mCEv+DWFzaK5lO35d4jouJiSdyKJwGY6sJwBIE3Ykuwf05p1sxASh0msTWfFJHgDFqntLcPHp75dQbTgTmaPQA44hfyTUlTPRItGh0W5asP44Et7qlOnqZ/tCmkOw/GtrGMsI+BTCXNMCHJF1UugkF0Pt578LG+tuuW0SADiePHeBg05Z6jgkmhKMHufi4impbeq42cGEU7qa0ax9h8eROEWciK8b9dM8h/5buUpKQ9fZJQzavO2fc2Qdz8nHr2kAqsfkbBMBnQBm9CIhiNiq5oyQ2FcqUpeJr3xRNu7PxYN3HYTv9CVGtfNqaAniqjTJujGQ==
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=M0lUoH3SKlftdv6WZutPmQortWm2JMOCq1OGIDob33I=; b=b1n1RcxcibdfdkSVK0I8uh/VvQQpz6/G97C+vLkv6/Iuqnh81mpz8aCwfVlJmKh2FGkoKzsKZHLhQMN3M7ppzsBhLopdBGpVWy3q9OfRqhVtM188MYDDcDd0sjsHahe9ujya5v+EGIxpyN7N+Zdoz8CK0IsCr6zSS93Yg7ZHTS8=
Received: from DM6PR11MB2841.namprd11.prod.outlook.com (2603:10b6:5:c8::32) by PH0PR11MB4965.namprd11.prod.outlook.com (2603:10b6:510:34::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6813.28; Mon, 2 Oct 2023 14:34:32 +0000
Received: from DM6PR11MB2841.namprd11.prod.outlook.com ([fe80::d7c8:ee3b:9eb9:fe63]) by DM6PR11MB2841.namprd11.prod.outlook.com ([fe80::d7c8:ee3b:9eb9:fe63%4]) with mapi id 15.20.6838.030; Mon, 2 Oct 2023 14:34:31 +0000
From: "Jan Lindblad (jlindbla)" <jlindbla@cisco.com>
To: Jürgen Schönwälder <jschoenwaelder@constructor.university>
CC: "Jason Sterne (Nokia)" <jason.sterne@nokia.com>, Kent Watsen <kent@watsen.net>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)
Thread-Index: AQHZ9T2OJu2ymSzMZ0u/Sc4TNOzb0w==
Date: Mon, 02 Oct 2023 14:34:31 +0000
Message-ID: <52EB05D2-AC2D-4476-BD66-A539AD7E5939@cisco.com>
References: <DM6PR08MB5084622CC28527D5D2A789FC9BC3A@DM6PR08MB5084.namprd08.prod.outlook.com> <oepghnjqumvlzfjyyi6pycot576gnyxceny3sxwaubzzaqqcwg@ketpanc6djln> <SA1PR17MB5672617B81D7D551E81437B8AFC2A@SA1PR17MB5672.namprd17.prod.outlook.com> <0100018ad95b5af9-37d62ed1-ea21-41c2-b23e-38729efbcc89-000000@email.amazonses.com> <1424028260.978007.1695906023372@mail.yahoo.com> <7p5p42xfecxdbpesl76vtdzkt467g4ryrl63yvfneupxj6eedi@eo66igvcnndq> <DM6PR08MB5084196B0D0656DCE6DCD92E9BC1A@DM6PR08MB5084.namprd08.prod.outlook.com> <dlpqso3z4scdoggkx7mjba5slgyuqpexufj7r6pxzswntps4sg@s6i6jvnpvvid>
In-Reply-To: <dlpqso3z4scdoggkx7mjba5slgyuqpexufj7r6pxzswntps4sg@s6i6jvnpvvid>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3731.700.6)
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM6PR11MB2841:EE_|PH0PR11MB4965:EE_
x-ms-office365-filtering-correlation-id: 1eb5cac7-800d-409f-d4a2-08dbc354b117
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: uFQIF19JYX2nQq62fvr2UAwbxRPuhcBtVSj1Dce46KgRRyddbF1oHdqMxCDHm/PP9eT3Wtx+vg+/CmxzsybfElSIVv5txr9T00JVE1G7PwL0fQvCt3R03GGQ3I3eqQD0D055fqplG6NkIKh1EDL5lPFXDAuUEIcP0Xo1c5Nlaw39diY9UyZm3FgftpqzegDAbmUBNeniw0R2XZ3qUP15ewk866Wo5PwTMcAg+AjxDH6eitBpFXTtlRH/AgMlUQR/3f5b2eEA7eNaxdO6fFqngmMy6TOs/2Kb9/MsA6epVfvi476f+HXWxQMCXfu2F3X2hqCFTPzZbxLDjyBmzldtIr6p63pDuA9IIUUMH/w9US1WEMU9oLpT0fh+wMBf5xFjeih7ait3uHT6BYmWNDrmnilXJICXFCtvpfdpNf7oaozDKXjsn9z+ijnqd5XqyVmFr49f1/bY/j91tXvWoV9ihLUDDNuMfeLE4npAF0SnS0q7HxiUhOCOsDUAu+Vj+HzH5l8yI+2UtgDDG6yULpTPdH2h4rGi0txxpLte1ssG28NEfzAkScLRiopaW0nYuHT0+vb3v2pxRKrtSRtcgzMYZxz265sOR5m9cIXEtSOpF7Qsfko+gbURGQwVom9IHvmIdfsjSdED8Ru4gdMFXBwpe/idI0Pc1kzltu0h9hQPk2E=
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:(13230031)(376002)(366004)(136003)(39860400002)(396003)(346002)(230922051799003)(451199024)(64100799003)(1800799009)(186009)(6506007)(6916009)(41300700001)(316002)(40140700001)(33656002)(26005)(2616005)(71200400001)(6512007)(36756003)(6486002)(83380400001)(478600001)(91956017)(38070700005)(122000001)(38100700002)(54906003)(45080400002)(66556008)(64756008)(76116006)(53546011)(66946007)(166002)(86362001)(66446008)(66574015)(66476007)(84970400001)(966005)(2906002)(8676002)(4326008)(8936002)(5660300002)(17413003)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: AWgwjXGT2yC49ZS/0GCMJcOCbNtCEmYQv0BWg1pyitHz1CISjiAIZeMIPd1cW7b7leGudD4CPMOImtpJLb01B7WNX1q8I4laaOvMtJEOlGFbr8IGxGKFAyo+2gj0axHfFAPWT6wE3c1H7jouauQyLXPrf5I2wyvXIKOaverlty1aD0xOroqHu2mkH3f+VzMZpTiNimLl58K+srA6826XG48MROcn9GmEaTASiV155EjBxgPVNbnmgPH6vDWOHE0WCwjeyrTAGNFzkMXmgskQPA8VyMw1ifgejhKQYGU1rKxx6XdMlKCYwpnhvMgUJI2GEeK1MHYFNmiNcEryX3oIuuxBzU+7U/QlXn8GBHUE+PdAxLpMbk1pFWMiBAIvqyQjcWNgVL/cIZOVABoiHQgrzdDp5Hm4/3uOvPJR1bHuO3AzoMJqFGZcNT6SkuRkRec7JIRACp/nHMTrrguhbduhU2VylrG1gI/cj4TJpEZRymAZY6OWZW12x6iyd06je3duSNNmgHxw7xK92aDxTcDd16bWDRX9P3H+OvU2qeoXlY+NxT1mkBYnehGmxGDQeBSS2D9n4xoUNeWszuoRxmUS/8BwU0hghreC6Xp6E4AxsCRl7b9MSbgxKNGbGUv6Un06xx9qoBzA1NRACZzfeVK+D/DSbMJZZXoNnu+2vEzvPhbJBPdpP5PqJNGyxzyztT2W3/uX9bdb7+HNFbYweEgmU6yIb/wQDA695uWi3T9RPaKcplR6SnwTxaJXbRgiv2XTZzicWMFZRYjM8FJHM5Myc2x0sWHQfkVtc96IovKEuUofNYN5nyoE+QRM1lS5Lwx12GMg+SLKu4hu1G8Eano1ksu9W3B2v1gHdTMx5nMDm5c0INmMmMfHTupYzx4pET6fDSEv3OH3Re5hPr5HFBZlyBFzbgRxNsOc/Xq9QJ2iGaZbwLGSFf5prTDn12r8oAeKH50cUMaoNVuqLPfTPwsDL3MxvZm9xZToPdjy8VxFwtYMwhvgh25aHvSP8etk74LPCLt5p59KJOkCz23LcSG15KdSKQf/n5xeHkzxnxuDGeABOwZCw+gmXURq489Pk+PK1rHAxZS8N12g0QgSd5D+PTDpSVnPgaTcGtTKvgg0lkn7R8rW5U9bXMwAENyearPlUHVMH4Bnfii/Q26Rr5ZahiftRFm/DXHzQmt+uTli6UNlTIz1g6FYUdZy54VEcji3+bjaC4+s9KMEdi28LcqKi2IKS+ljZ1yqauR/rCzW+ZFpT0fdZtQ7bGdRfTSmsDShGCaJcUwV7qBkFtDVqTPQAEzi4FXb9flqYoLgxr7qibA8pZVIguevd/CyzTR31fesadmr0TwUEgKEh0Zufb3RiCl0O/+b1rgm5tB8NzisUCcElCEDU+FdWVgJHd6rrjdfogGuo57kUo9zwZJcdgllfxRT4i/3vGymh7Lgd3e/Q3i6Q1lU0axqw2ZCk2dBoPCDBWtzKC9W6gvOnO9N8QyM8oEohEFgDDRt9luNlifh58wodAy2X3a0bjpldF2dAaKOnfjh2kds6amjbHLYIUmOGXF+cGUf4XCg1WPdwmzdtQ+VsXuSvCto5VJw29kHOEYF
Content-Type: multipart/alternative; boundary="_000_52EB05D2AC2D4476BD66A539AD7E5939ciscocom_"
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: 1eb5cac7-800d-409f-d4a2-08dbc354b117
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2023 14:34:31.8334 (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: ydEiecAUjDJerq6HIMFAPzNCu216OTGQx9SUTf/tcSnpKajp2ttxM3BgszxGZEOjdPWSH8sljX9wiMY6QInpJw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4965
X-Outbound-SMTP-Client: 173.37.147.253, alln-opgw-5.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/YzdnKgvzmHrQaw8zO2R-tUX3kF4>
Subject: Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)
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: Mon, 02 Oct 2023 14:36:07 -0000
Jürgen, WG, I agree that a document that updates 7950 would be the preferred solution here, rather than a bis or errata. I'm quite attracted, however, by the idea to bundle the softening of 7950 with the requirement to document any incompatibilities introduced. This way, we get something useful back as we provide the needed flexibility. This is something I would have an easy time to explain to YANG practitioners, and it seems pragmatic to me. I agree completely that YANG extensions cannot change YANG at all for clients that are not in on them. In the key issue #1 debate, however, I believe most people agreed that we should allow non-backwards compatible changes to some degree. To also require that any such non-backwards compatible changes are documented using an extension statement is not to muddy the waters in my opinion. Quite the contrary, actually. People's understanding of what's going on will likely be improved by this requirement, for clients and server implementors alike. We can certainly discuss the pros and cons of requiring users to document their non-backwards compatible changes once we have the key issue #1 behind us. Best Regards, /jan On 29 Sep 2023, at 07:45, Jürgen Schönwälder <jschoenwaelder@constructor.university> wrote: Jason, the must/should change is technically a change of the language. We can do a short RFC to do that so that we get unstuck and oour AD allows us again to publish YANG modules where bug fixes or alignment with other modeled technologies is desirable. Adding decorations that can be ignored is something one can do with YANG extensions. However, once such extensions change the behaviour of YANG language constructs, we get into muddy waters. I prefer to clearly separate changes of the language from additional decorations that can be ignored and do not influence the behaviour of YANG implementations (i.e., they can be ignored). /js On Thu, Sep 28, 2023 at 08:57:42PM +0000, Jason Sterne (Nokia) wrote: Hi all, IMO - We've already started moving out of the "stuck" situation. We no longer have to debate whether a new YANG 1.2 is needed for allowing an NBC change. That will be the end of a big distraction and circular discussions for the WG. I'm not so convinced we want to rush and do a separate RFC just for that one part of Module Versioning (and one part of the original versioning requirements). It is a key/critical part, but we should continue discussing what other parts we'd want to also tackle as part of the "first" versioning RFC. I'm very doubtful we should relax MUST to SHOULD NOT without also at least making the rev:non-backwards-compatible marker mandatory (as per Module Versioning). The marking is a key part of making this all better for consumers of modules and clients (one of the main problems is the current silent NBC changes happening). We should also clarify that marking an element as "status obsolete" is NBC. That has major impact on clients who are trying to continue using an old version of the module. (and there are likely at least a few other pieces from Module Versioning that should be in a "first" RFC) Jason -----Original Message----- From: netmod <netmod-bounces@ietf.org> On Behalf Of Jürgen Schönwälder Sent: Thursday, September 28, 2023 9:12 AM To: Reshad Rahman <reshad@yahoo.com> Cc: Kent Watsen <kent@watsen.net>; netmod@ietf.org Subject: Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1) CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. The truth is that we did bug fixes in the past. We now have maneuvered us into a situation where work is put on hold because we do not even do bug fixes anymore (and yes, I know, the line between bug fixes, alignment with moving targets and other changes is vague and needs to be decided on a case by case basis). The fastest way to get unstuck is to write this one page content RFC that changes MUST to SHOULD and then we at least get out of the being stuck situation. /js On Thu, Sep 28, 2023 at 01:00:23PM +0000, Reshad Rahman wrote: As a client (consumer of models), I do not want only the MUST -> SHOULD change, IMO that would be worse than the current situation. Regards,Reshad. On Wednesday, September 27, 2023, 09:16:10 PM EDT, Kent Watsen <kent@watsen.net> wrote: This was my thought as well, that it would be best to have the smallest-possible draft update 6020/7950. That way, when someone follows the “Updated” links, they’re not overloaded with material that could’ve been left out. Jason was saying that just doing MUST/SHOULD by alone isn’t great, that at least the "rev:non-backwards-compatible” extension statement should be included and, by extension I suppose, the rules for editing the revision history. Presumably revision labels could be left out. IDK what minimal is possible. K. // contributor On Sep 27, 2023, at 7:06 PM, Rodney Cummings <rodney_cummings_spm@hotmail.com> wrote: It is easy to write a short RFC updating RFC 7950, changing one sentence from MUST to SHOULD. I agree. I found that I cannot enter a response to the poll, because I disagree with both Option 1 and Option 2. My concern is that there are many people out there who are implementing YANG, but who do not follow discussions on this mailing list. I'm concerned that there is a serious risk that those people will interpret the change from MUST to SHOULD as "backward compatibility is irrelevant for YANG". We all know that the concern is about bug fixes and so on, but without explaining that in a short and focused manner (i.e., the short RFC described above), that will be lost in the noise of the larger draft-ietf-netmod-yang-module-versioning change. draft-ietf-netmod-yang-module-versioning is a great draft, but I think it should move forward as an independent RFC, distinct from the MUST/SHOULD change. Rodney Cummings -----Original Message----- From: netmod <netmod-bounces@ietf.org> On Behalf Of Jürgen Schönwälder Sent: Tuesday, September 26, 2023 5:24 PM To: Jason Sterne (Nokia) <jason.sterne@nokia.com> Cc: netmod@ietf.org Subject: Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1) It is easy to write a short RFC updating RFC 7950, changing one sentence from MUST to SHOULD. This is inline with the goal to not change the language, i.e., to keep the version numbers. /js On Tue, Sep 26, 2023 at 03:00:19PM +0000, Jason Sterne (Nokia) wrote: Hello NETMOD WG, We've had a poll going for a few weeks to determine if we require YANG 1.2 for allowing ("SHOULD NOT") NBC changes (see "Poll on YANG Versioning NBC Approach"). As part of that, some discussion has happened on the list around potentially doing an errata for RFC7950/6020 or a bis of 7950/6020 (if rough consensus is reached for option 1 of the poll) 7-8 of us discussed this in the YANG Versioning weekly call group today. First of all: this question of mechanics (errata vs bis vs Module Versioning draft) is orthogonal to the poll. Let's first and separately resolve the poll and confirm if we need YANG 1.2 or not (that's the fundamental question the poll is resolving - everything else is a subsequent issue to be discussed). We'll let the chairs confirm when/if rough consensus on the poll has been reached. But *if* the answer to the poll is option 1, then the weekly call group was unanimous that we should not do an errata for RFC7950/6020 and we should not do a 7950/6020 bis. We should just continue with the Module Versioning draft which will update 7950 and 6020. The primary reason is that we shouldn't just change MUST NOT to SHOULD NOT without also tying it together with the mandatory top level rev:non-backwards- compatible extension when an NBC change is done. Changing the NBC rule to SHOULD NOT needs to be in the same RFC as the mandatory rev:non-backwards- compatible tag. Other reasons: * an errata probably isn't correct since this isn't fixing an intent that was present back when 7950 was written (it was clearly the intent at the time to block NBC changes) * a bis would be odd without actually introducing other changes to YANG and changing the version (this discussion is all based on "if the answer to the poll is option 1") Jason (he/him) _______________________________________________ netmod mailing list netmod@ietf.org https://www.i/ etf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C01%7C%7C22464d2aa09 441 f1b1bd08dbbedf65ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6 38313 638956186415%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj oiV2luM zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DgsZVlBTQt qJjR tVXs%2Bze%2BrOanijgDEuCn93gbN9Jyw%3D&reserved=0 -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> _______________________________________________ netmod mailing list netmod@ietf.org<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod
- [netmod] YANG Versioning: discussion around 7950 … Jason Sterne (Nokia)
- Re: [netmod] YANG Versioning: discussion around 7… Jürgen Schönwälder
- Re: [netmod] YANG Versioning: discussion around 7… Rodney Cummings
- Re: [netmod] YANG Versioning: discussion around 7… Kent Watsen
- Re: [netmod] YANG Versioning: discussion around 7… Reshad Rahman
- Re: [netmod] YANG Versioning: discussion around 7… Jürgen Schönwälder
- Re: [netmod] YANG Versioning: discussion around 7… Jürgen Schönwälder
- Re: [netmod] YANG Versioning: discussion around 7… Jason Sterne (Nokia)
- Re: [netmod] YANG Versioning: discussion around 7… Jason Sterne (Nokia)
- Re: [netmod] YANG Versioning: discussion around 7… Jan Lindblad (jlindbla)
- Re: [netmod] YANG Versioning: discussion around 7… Sergio Belotti (Nokia)
- Re: [netmod] YANG Versioning: discussion around 7… Jürgen Schönwälder
- Re: [netmod] YANG Versioning: discussion around 7… Jason Sterne (Nokia)
- Re: [netmod] YANG Versioning: discussion around 7… Jürgen Schönwälder
- Re: [netmod] YANG Versioning: discussion around 7… Joe Clarke (jclarke)
- Re: [netmod] YANG Versioning: discussion around 7… Jason Sterne (Nokia)
- Re: [netmod] YANG Versioning: discussion around 7… Jan Lindblad (jlindbla)
- Re: [netmod] YANG Versioning: discussion around 7… Reshad Rahman
- Re: [netmod] YANG Versioning: discussion around 7… Jürgen Schönwälder
- Re: [netmod] YANG Versioning: discussion around 7… Jan Lindblad (jlindbla)