Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts
"Rob Wilton (rwilton)" <rwilton@cisco.com> Mon, 26 June 2023 12:01 UTC
Return-Path: <rwilton@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 22608C13AE59 for <netmod@ietfa.amsl.com>; Mon, 26 Jun 2023 05:01:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.896
X-Spam-Level:
X-Spam-Status: No, score=-11.896 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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="nBa4aEkv"; dkim=pass (1024-bit key) header.d=cisco.com header.b="dOs12gDN"
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 9aDAEBQKVvn5 for <netmod@ietfa.amsl.com>; Mon, 26 Jun 2023 05:01:32 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86FA9C13AE57 for <netmod@ietf.org>; Mon, 26 Jun 2023 05:01:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20243; q=dns/txt; s=iport; t=1687780892; x=1688990492; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BY2/+Vx8CdznSezBnyZY6/lWxRh1HGWmxoyGiAheFiQ=; b=nBa4aEkvIVAd2/6zVnSmNn22g9wSxTKXyYne7LDR2N3xVmHGP9NaTbkr JGJLCVLOMRljM2xkrX4gU6fjlh5Z61j2CCVeFpN7mrIb2xzXrd30fsXoO QqsaEAezTZMYS25bjVfnxZfIxupbiZhyTthX/s3MNkfi3zkz8GvbOyZqh U=;
X-IPAS-Result: A0CuAgA+fZlkmIsNJK1XAx4BAQsSDEAlgR8LgWEqKHMCWRMpR4gdA4UthXSCYwOBE5AejD8UgREDVg8BAQENAQEuDQkEAQGCEoIuRgKGBgIlNAkOAQICAgEBAQEDAgMBAQEBAQEDAQEFAQEBAgEHBBQBAQEBAQEBAR4ZBRAOJ4VoDYYEAQEBAQIBAQEQLgEBKQMGBQELAgICAQgRBAEBAS4bDAsdCAIEAQ0FCBMHglwBgjkjAwEQBKMoAYFAAooleIE0gQGCCAEBBgQFgTwCEEGwXAMGBYE9kWkCJxuBSUSBFUOBZgFJOD6Bf2MBAQIBgSgBEgEjHyaDTYIuh3eBIoILBAYEBAUDBAU1gTR4gwmCFBguAwQyi2uBKG+BHoEgegIJAhFngQgIX4FxQAINVAsLY4EcglICAhE6DwVTeBsDBwOBBRAvBwQyHwkGCRgvJQZRBy0kCRMVQQSDWAqBDD8VDhGCWSs2PxtRgm0JFw49A0QdQAMLcD01FB8FBGqBVzA+gQwCIiSgcAM/JYFOARABQRcCBgEvDgMjAQMxAREOAiAmCgsLFQoMBxoTCDYBAg0CAQMkAgkGKQOSLgkBQJAJghieewqECIt8lToXhAGkdWKYHyCCL4sNlG4zC4UJAgQCBAUCDgEBBoFjOmtwcBU7gjMBATJSGQ+OIBmBDwEIgkOFFIJph3x1AjkCBwEKAQEDCYpqXgEB
IronPort-PHdr: A9a23:lBweCxyGDRcjUy3XCzMSngc9DxPP8539OgoTr50/hK0LKeKo/o/pO wrU4vA+xFPKXICO8/tfkKKWqKHvX2Uc/IyM+G4Pap1CVhIJyI0WkgUsDdTDCBjTJ//xZCt8F 8NHBxd+53/uCUFOA47lYkHK5Hi77DocABL6YBBqJ+DpHYj6hMWs3Of08JrWME1EgTOnauZqJ Q6t5UXJ49ALiJFrLLowzBaBrnpTLuJRw24pbV7GlBfn7cD295lmmxk=
IronPort-Data: A9a23:4BVGq6o3G0NrlNXtltPaIeew76ZeBmJgZRIvgKrLsJaIsI4StFCzt garIBmCPaveZGP2Lo0lOdyxpE4B68LWyNZiSVBlqiA3QXtGo+PIVI+TRqvS04x+DSFioGZPt Zh2hgzodZhsJpPkjk7xdOCn9xGQ7InQLlbGILas1htZG0k8EU/NtTo5w7Ri2tAy34Dga++wk YqaT/P3aQfNNwFcagr424rbwP+4lK2v0N+wlgVWicFj5DcypVFMZH4sDf3Zw0/Df2VhNrXSq 9AvY12O1jixEx8FUrtJm1tgG6EAaua60QOm0hK6V0U+6/RPjnRa70o1CBYTQUN+mi3SpNR+9 O1uqJ6ZRR50LoLJhPtIBnG0EwkmVUFH0LbDJX76usuJwgiYNXDt2P5pSkoxOOX0+M4uXjoIr qJecWtLN0vS7w616OrTpu1EnNsiKNXsOqsUu2prynfSCvNOrZXrHPWQvYcAhGlYasZmMLGAQ OcJYx1TajflbjBrYFU3DIIApbL97pX4W2QI9A3KzUYt2EDVwRB017TFMdfJdJqNX8o9o6qDj mvC+2K8CRYAOZnBjzGE6XmrwOTImEsXRb7+CpW83+9y22aXyVArKwAUfFei/OmWj1KhDoc3x 1MvxgIiqq079UqOR9b7XgGlrHPsgvL6c4cNewHdwFzTopc48zp1FUBfFG4cNIBOWNseAG10i w7Yx7sFEBQy6NWopWShGqB4RN9YEQccN2sLYyNsoeAtvIS7/NpbYv4isr9e/EOdh9nxH3T7x CqH6XZ4jLQIhslN3KK+lbwmv95OjsaQJuLWzlyINo5A0u+fTNX4D2BPwQOKhcus1K7DEjG8U IEswqByFtwmA5CXjzCqS+4QBryv7PvtGGSC0QExRMB9rG/3qy7LkWVsDNdWeRYB3iEsJ2eBX aMvkVg5CGJ7ZSHzNvYnP+pd9exzlPe/fTgaahwkRoMePscuHON21CpvfkWXl3v8i1QhlLpXB HtoWZjEMJruMow+lGDeb75EidcDn3lurUuNHsqT50r8jtKjiIu9FO1t3K2mNL5ptctpYWz9r r5iCid940QOALGuM3GMoOb+7zkidBAGOHw/kOQOHsarKQt9E2ZnAPjUqY7NsaQ/90iJvo8kJ k2AZ3I=
IronPort-HdrOrdr: A9a23:au/qpKqrUhFE+gerwpe92RAaV5uEL9V00zEX/kB9WHVpm5Oj9v xGzc506farslkssSkb6K+90cm7K0819fZOkO4s1MSZLXfbUQyTXc5fBOrZsnHd8kjFltK1up 0QCJSWZOeAaGSSyPyKnDVQcOxQjuVvkprY/9s2pk0FJWoHGsIQjTuRSDzrb3GeLzM2Y6bRYa Dsnvav0ADQAEj/AP7LYkXtWdKvm/T70LbdJTIWDR8u7weDyRmy7qThLhSe1hACFxtS3LYL6w H+4kzEz5Tml8v+5g7X1mfV4ZgTssDm0MF/CMuFjdVQAinwizyveJ9qV9S5zXMISaCUmRQXee v30lMd1vdImjTsl6aO0F3QMjzboXMTArnZuAalaDXY0JTErXkBert8bMpiA2vkAgwbzZBBOG Yh5RPCi3KRZimwxxgU67XzJmJXv1vxrnw4neEJiXtDFYMYdb9KtIQauFhYCZEaAUvBmcsa+c RVfYjhDcxtABunRmGcunMqzM2nX3w1EBvDSk8eutaN2zwTmHxi1UMXyMEWg39FrfsGOtR5zv WBNr4tmKBFT8cQY644DOAdQdGvAmiIRR7XKmqdLVnuCalCMXPQrJz85qkz+YiRCdY15Yp3nI 6EXEJTtGY0dU6rAcqS3IdT+hSIW2m5VSSF8LAp23G4gMyKeFPGC1z2dLl1qbrTnxw2OLyvZ8 qO
X-Talos-CUID: 9a23:fKvWTGtvOudsjj8zEikuUy5n6IshW2zFl0zULHOAKntrYbGMFE+//b97xp8=
X-Talos-MUID: 9a23:wKBOhwvuu0wT0ubqK82nqXY8E+p46YOSDmMonLgi4cukMTxOAmLI
X-IronPort-Anti-Spam-Filtered: true
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Jun 2023 12:01:30 +0000
Received: from alln-opgw-3.cisco.com (alln-opgw-3.cisco.com [173.37.147.251]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 35QC1UFW018265 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <netmod@ietf.org>; Mon, 26 Jun 2023 12:01:30 GMT
Authentication-Results: alln-opgw-3.cisco.com; dkim=pass (signature verified) header.i=@cisco.com; spf=Pass smtp.mailfrom=rwilton@cisco.com; dmarc=pass (p=quarantine dis=none) d=cisco.com
X-IronPort-AV: E=Sophos;i="6.01,159,1684800000"; d="scan'208";a="3472614"
Received: from mail-bn7nam10lp2104.outbound.protection.outlook.com (HELO NAM10-BN7-obe.outbound.protection.outlook.com) ([104.47.70.104]) by alln-opgw-3.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jun 2023 12:01:30 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=luRI88jKS9ZGtkfpRNIrFr0GDaCY78QSUvAvjU+tKP4mR9cDW8gsBisycr3ASz8WfTorwutd1FWNNQncM3FXrkUcprStKUdCJ1+SuGMJa9KzIaJFeDLASTqXNzWOAaD8uUNL0yynScdW2QClAQpXPC0qu+LUUczt9+9UrRXS6Zh386SvYXWAXji9ptEndxke7Pmple6fUxDDkwIouyg8WxvGXpEZJjuKxNxOOJwJDcFdXhv1tLE53fRQLJkOEStoBonI/weD6RT0fhConxb/NxQsnnyJ4RSG9ksZCO3qP84kuc8AMndaDY4emNd6o8HY2mVoc0jtW4AVljRuaEDJpw==
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=TJcVHkW8+Yc47Qm5CB53HNaIERe+MGJ2KrTaf86LlZk=; b=W8JHZdH81pC7NR4Ik11R7FmCYSqqdJVc4VnjqIS+NBRjQ/FBk1NxXbiHoD10UTh6jJCqD2C9e8lOwaYbZf9cjlL7YCpOHQDn6U5DNOP3eZnQK1479lLBXYO2+sM+N40KPukZ2/swsc8kBGVmp9iSbJmGrB1mr2uD0fj8x3JQAkKjsAJ9bC55JUMMb/FZbPmLzL4kKaxnGVIwSkJaZrbjpPNe4fukiCTv+F/ZbkOTyif6bmTYvUOR2f6zKHFlHCRevqo4LyHlethUPAGdQ1jg6XJ/wofw/W9VW+HI8u4CehfQ6u8vmb2l2i4i3aDXj7sE4mn8ICqgj37wF0PzVmm7hA==
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=TJcVHkW8+Yc47Qm5CB53HNaIERe+MGJ2KrTaf86LlZk=; b=dOs12gDN2WEr6sk29gSaqLY1Nbou7ypWf4t1iR3d0mmZQVW82EOvasslVrEZD3VDK+Tm6yKiDqyQE6W6u1pHBXGBHCtqKBT1ATI1zjLbVRXJhL9sbMn/y4/vj4rOHzf1YfnUbd7kwSqanZsULMmCSZIy7geJw8QP54JkAjGtSUs=
Received: from BY5PR11MB4196.namprd11.prod.outlook.com (2603:10b6:a03:1ce::13) by IA0PR11MB8334.namprd11.prod.outlook.com (2603:10b6:208:483::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6500.29; Mon, 26 Jun 2023 12:01:28 +0000
Received: from BY5PR11MB4196.namprd11.prod.outlook.com ([fe80::a6a3:7e3b:903b:2035]) by BY5PR11MB4196.namprd11.prod.outlook.com ([fe80::a6a3:7e3b:903b:2035%5]) with mapi id 15.20.6521.024; Mon, 26 Jun 2023 12:01:27 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: tom petch <ietfc@btconnect.com>, Martin Björklund <mbj+ietf@4668.se>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] Joint WGLC on "semver" and "module-versioning" drafts
Thread-Index: AQHZgf9ZTIoB2mIMGUefW9NRcWgTm69m804AgBPisICAACOwgIABJ6IAgAAnYoCAAAbOAIAAhk2AgACPmACAADI24IABheeAgAH2EPCAHDMFgIAAAIGg
Date: Mon, 26 Jun 2023 12:01:27 +0000
Message-ID: <BY5PR11MB4196F52F746956659C2CBADDB526A@BY5PR11MB4196.namprd11.prod.outlook.com>
References: <20230605.223251.336974778999487126.id@4668.se> <ykghe2tzoe2rqzh3brfbsuvvhswi7fzul5ygfnokuyih4t4emo@kpnvucchbed5> <BY5PR11MB41966AE860E22466F8037B6DB552A@BY5PR11MB4196.namprd11.prod.outlook.com> <20230607.092201.152004661869529702.id@4668.se> <BY5PR11MB4196D31C959323377AE83143B555A@BY5PR11MB4196.namprd11.prod.outlook.com> <AM7PR07MB6248887F284B2AA9DF105644A026A@AM7PR07MB6248.eurprd07.prod.outlook.com>
In-Reply-To: <AM7PR07MB6248887F284B2AA9DF105644A026A@AM7PR07MB6248.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BY5PR11MB4196:EE_|IA0PR11MB8334:EE_
x-ms-office365-filtering-correlation-id: 7a79388f-2411-4254-f4cf-08db763d123c
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: aa/oYWYTP8ML1qKOGpNvBB7kXGOWDXkY72S/8Wm+b0PG5m6Zo/uWDHuFst7pBlw4ap3EvsZ+YprldFYWKuMpg8lqEEhyJ4RsoG9UunBZikmv0CS0lZWgFaDcO14f7BVUmAGFr0Uh0wl8RdAAGocRT+X4x+Ywin2OG3VawnYtonVlvlpFzqPXbSnymYRH85nPph4kiczuP9181y4ktZYNcbIYABLNz5xojmIEAYJb8kNVCksiTh9IvlvYJ4MUDZ+VVJNp8vucZJbo3kRFdYA6zQZOtOZIVb4qD9RjTHaZ0k3Gn44+C3lYSHHPsmqYXZtzKTfMUslhY3FwPURd2MRLiGPzzp1CYI/uPtDlJEmuC24lzCGlOpm61QPrSiMIM0zoQ5uyXST9DOIp4+lbGpZI5DD6fBjcrf59i7BYFsSUgQy81mEi6fkYAo6rJOHLptLhYSK4qPsCvuwqSnIQ53YXyRYkctp1Z7EvHju4QfgafejPrn6q2Tn/licqByRk3rn+CRCUfGK6L6i0w3oNoSm80gkCncF0iWU1mVfDNJDpNjnSEbIPawQ4rnBb8LPzUKkzxxw4Z0WC4StWzCoA2mH8azbvPqvIfWP0AwF+llKJLFdHr8nIG/uaM3BY+t6vNU4wecw6WmFyJAA0mB9tkDogAg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4196.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(346002)(39860400002)(136003)(376002)(366004)(396003)(451199021)(66899021)(7696005)(966005)(110136005)(478600001)(83380400001)(66574015)(55016003)(38070700005)(86362001)(40140700001)(66476007)(64756008)(66446008)(2906002)(33656002)(53546011)(30864003)(6506007)(186003)(71200400001)(9686003)(4326008)(122000001)(8676002)(76116006)(316002)(296002)(66556008)(66946007)(8936002)(38100700002)(5660300002)(52536014)(41300700001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: xSakZVOvzQIoSEtK41XNpcq4vvJT6EZoHPDwT/V8AosMZqTcAkVHEl/bu8vpQPIsp/mOcegEMBwuW2y0ZgVTsrdb6QXtw4xmDcr5HEJFgqdpgcFqgioMKVyDI7JaRZH/QYIH8WcVoQ4CYWxuY6Q9vlLVV+Pyj0QLOhRNJaCqlDP0kkXC4ifhnjErkut2PzmEu76wxN+AMtqekV3qY9nk1/yyYy7NwqHVu7sYfTJUCBchBEwn6D/voZ5HDUfgsPVDsovQWbVrh99D7t9b5Wj3xnjkAWUvXrIGx0TfHU4XzAccru1M6Pd4l8RnZkaPDKjyIio5l+xQcIhZE/Pr+qjZ98mII21y/qPAOFCwMXjMFvTt4TUcEptzn37Kri9b4z78zseLnEp2uvvbiT3sZNJEVUsF4M4JnG1MmPcBFVDJYJxh77eMyN5LFyjrsM3SfBp1KSu3w6dfYV7gCVKpAyrYDNM7i8hj4HSnzCMpxSuQRdQRtqjZ0Q1r7Oz619ou6v+kfqXjjw+5MWwfGFF4szSGIT/jtnYsoYC9Xu6Sbbxnz3j0bH89f/DlZZq3VXC2oE/uSoYy2LmbzghBQJesD+WpYl1DUSQDFmdNitkXDHwsa/Z8N8NdOGM9nX13QM4PO0T4q8MD5Pk4tNSdIfQjJgBtc35H8tf3ydylG+F9o7jtPNGTkdkQWFW8q0PyuIpcUJGcDVdRb8QdhMfCMFx7iMJF/8omOe3y7D4idpeTKk9rRI688Zq8wSnwu8eenPLOoMNeElnjHRvgIFAbgK2BvqJDvsfsbzPqimGPM/iH2zSqUNGflAbM2ygicvwPe/HirQwhfW5OejY83PnoTe9wkDjKV40IzO2fXk+B3YTa/y1ZitFb3NsFjED96xtIVyVpOC15fnlzR5dy8NYCpm3wfdYzZCbJe79xuqkKIORUK+YO3qlDHKqJK+6M364UJyzqcC8g7oNqzBLCav0mIBOE5WjZWuYlQt6H/bULtkmkZU+nJy+lRNmvC1962LD/AzB8tmmHAIS/o1UgtcFNzumEpjjF1RXrUPkmGL3fHV0EMQwZA/3PjIMxEgXzLiDHGcVTaPweVaQ36dmLZ7zcpw0Lo/ngxJK0gusMOqgaf3z3D0QB3/CqtrFPWxpROu3l/Agj8PCG0r9mM38U+HW9LPROXPkZdhzJfuZBClAIjHwusOTOdXdvOmodNvHAlbi533tOM5NjET+n1EQXF7hDDm6c6qasbwTMtx9e/zu2fVmipgVuZE4ztEt46ka38yJoP4vpsxOi59EXr4GWxpX066nKKWzeD7oPRVdnLmobhXFy/ClrOWxxugoNyYCyS3KzW1KRAAU/8bGPFf6ltoPxudB+hakKC+6jlHbxFrcnJpiKdOu/GfAoSrK5erKMQp6MEqiLwJv4P97kNZejzXc+Jz4r0SUt4O7ItrFU7DYWBbjQ0/ck4pekzvD5EOpO3uDnZqFYerPEeIuVuHnOK4EFgAT6XQKxSO5mle8Q6EX2TVZRryKcekeLeTDOlANPcSRbXyBSCmw4X5408FTblu5iypJ1VYYWbmu4Rn8gIQDwxv+MTnlLvCDvZ+FpPJw786ssJR+4BXYM8bGW3kpanNX0liZqZ/4CpTpJJbd8Svp51QbPEHhC95Y=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: cisco.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4196.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7a79388f-2411-4254-f4cf-08db763d123c
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2023 12:01:27.3746 (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: xL2BTDgj/+dH4BK4nxvdNKGIKwVAr2tiLtKThKnMBKM4kHR/ShnGC2Nk46auc3b9IaGhgvKnKtShJJX3t1IB1g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR11MB8334
X-Outbound-SMTP-Client: 173.37.147.251, alln-opgw-3.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/dkBTgcLVsj97Z4F_dAC_Qp6mmMQ>
Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts
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, 26 Jun 2023 12:01:37 -0000
Hi Tom, > -----Original Message----- > From: tom petch <ietfc@btconnect.com> > Sent: 26 June 2023 12:57 > To: Rob Wilton (rwilton) <rwilton@cisco.com>; Martin Björklund > <mbj+ietf@4668.se> > Cc: netmod@ietf.org > Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts > > From: netmod <netmod-bounces@ietf.org> on behalf of Rob Wilton (rwilton) > <rwilton=40cisco.com@dmarc.ietf.org> > Sent: 13 June 2023 17:25 > > Hi Martin, > > > -----Original Message----- > > From: netmod <netmod-bounces@ietf.org> On Behalf Of Martin Björklund > > Sent: 07 June 2023 08:22 > > > > But the two drafts go way beyond fixing the problem your three > > examples illustrate. > [Rob Wilton (rwilton)] > > The actual goals of this work (i.e., the set of drafts) is aiming to address the > requirements stated here: https://datatracker.ietf.org/doc/html/draft-ietf- > netmod-yang-versioning-reqs-07. Although never taken to RFC, I believe was > effectively last called and achieved WG consensus for the NETMOD WG. > Hopefully the chairs can chime in and keep me honest if I'm wrong on this > point. > > <tp> > May be or may be not but there is no such I-D in the datatracker for NETMOD > nor can it be downloaded from the FTP site so effectively there are no > requirements to justify this substantial change. Based on what I can access, the > module versioning I-D does not look like a good idea. [Rob Wilton (rwilton)] Are you saying that you are unable to access the link above, i.e., https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-versioning-reqs-07 Or are you saying that because this is currently an expired draft it isn't valid, in which case, that would seem to be trivial to fix? Regards, Rob > > Tom Petch > > The shape/structure/content of the drafts is very similar to when these > documents were adopted in March 2020: > > Your comments on these document at adoption time are here > (https://mailarchive.ietf.org/arch/msg/netmod/r5TD0NDNgUbtX9EHZfB5hJJctN > 8/). From that email, it is clear that you didn't support the YANG Semver > scheme, but my reading is that you were broadly supportive of the YANG > module versioning draft. > > Here are your review comments of the YANG module versioning draft at > adoption time: > https://mailarchive.ietf.org/arch/msg/netmod/MTGomxcdyNOmB7mgsFhItLKN > Jgk/ > > Here is a thread where you are discussing supporting different revision label > schemes: > https://mailarchive.ietf.org/arch/msg/netmod/cEBiZKUSk0n7BeFwdiyaejc_Tsg/ > > I appreciate that everyone has the right to change their mind at any point, but > as stated previously, I don't think that the shape of the solution has really > changed substantially since they were adopted. > > > If the goal is to indicate that non-backwards > > compatible changes have occured, a single new extension statement > > could solve that. (As I probably have stated before, personally I > > don't think this is necessary). > > That is one goal. Another is to acknowledge that non-backwards-compatible > changes will occur, potentially even on branches. Another is to align with the > versioning scheme that is being broadly used by the industry (but with > extensions to support a branched history). > > > > > > Apart from the updates to RFC 7950 section 11, I am mostly concerned > > about the additional complexity the "pluggable" revision-label scheme > > brings. > [Rob Wilton (rwilton)] > > It feels like we are somewhat going in circles: > > 1.The original proposal was to embed regular Semver 2.0.0 for the version > numbers. > > 2. That scheme was extended to what is being labelled as "Yang Semver" > because regular Semver didn't support some level of branching that the > vendors require to support customers on older releases over a much longer > time period. Semver 2.0.0 works best when the updates are always committed > to the head of a linear sequence of versions, and if a bug needs to be fixed in > an older version then the user is forced to migrate to the latest version. > > 3. If I recall correctly, you didn't like YANG Semver (and possibly not even > Semver), and if I also recall correctly from a conversation then I think that it is > because you envisaged more advanced branching schemes and perhaps a > version number scheme that follows branch history (and hence cannot also > contain semantic meaning). Based on that feedback, and an in-person side > meeting, we moved to a revision label scheme, an nbc-marker, and > standardizing a versioning scheme to fit into the revision-label scheme > separately. This was all in place when these documents were adopted. > > Based on those who are or have participated in the weekly calls, I also believe > that the solution has reasonable industry support: > - Representatives from Cisco, Ericsson, Huawei, Juniper, Nokia have all > participated in the calls at various stages. > - Other SDOs (3GPP at least, and ITU?) are waiting for this work. > - OpenConfig is using Semver and has been for years. I don't know if they will > adopt IETF's particular solution, but I do think that we would at least be fairly > aligned. > > I want to find a way that we can just get this work finished and published so > that the authors and WG can move on to other, hopefully more interesting, > stuff. > > Is the solution perfect? No, but engineering solutions never are. > > Is the solution good enough? I believe so, yes. > > Regards, > Rob > > // As an author and participant in this work for 5+ years. > > > > > > > > > > > > /martin > > > > > > > > > > "Rob Wilton \(rwilton\)" <rwilton=40cisco.com@dmarc.ietf.org> wrote: > > > I'm wondering whether we are in the realm of missing the bigger > > > picture here, or perfection being the enemy of good enough. > > > > > > My first example: > > > > > > The sedate WG (https://datatracker.ietf.org/wg/sedate/about/) has > > > recently been rechartered to respecify the meaning of the date string > > > in a non-backwards compatible way. Yes, this same date string format > > > that is very widely implemented and deployed. I originally had a > > > block on the new charter until it was pointed out that the IETF > > > specification was being updated because it was inconsistent with the > > > ISO time specification and inconsistent with how the date string was > > > actually being used by implementations. I.e., the specification is > > > being updated to reflect reality. I.e., fixing the specification in a > > > non-backwards compatible way ends up being pragmatically the right > > > thing to do (and this is entirely allowed by the IETF process). > > > > > > Ideally, the date-and-time typedef in YANG would also be updated to > > > match the update to the definition in RFC 3339 by SEDATE. But this is > > > clearly not compliant with section 11 of RFC 7950 (because the value > > > space of allowed values is being narrowed). The only available choice > > > would be to define a new date-and-time-2 typedef which modules could > > > then update to. Of course, you cannot update the existing leaves to > > > use the new date-and-time-2 typedef because that also violates section > > > 11. So, you end up with two datetime leaves everywhere the > > > date-and-time typedef is used, hopefully with one deprecated (and at > > > some point, obsoleted). Of course, defining the new datetime version > > > leaves could also break any loosely related modules that may have > > > xpath expressions dependent on that date-time leaf (that the updating > > > module author may not even know about) which would need to be updated > > > to depend on either of the leaves. I also don't think that RFC 7950 > > > is clear about whether deprecated leaves must be implemented by all > > > implementations or not, so realistically clients will need to handle > > > setting either (or perhaps in some cases, both) of the datetime > > > leaves, depending on implementation, probably with a different mix > > > across modules (in vast stages of being updated). What happens if > > > some instances of those datetime leaves are mandatory configuration > > > and become obsolete? Is a client required to set it or not, the > > > pragmatic answer being that again RFC 7950 is unclear and again this > > > will likely be implementation dependent. What about if some of those > > > datetime leaves are list keys? I believe that the only solution that > > > RFC 7950 allows for would be to duplicate the list, deprecating the > > > old one, again requiring updates to all augmenting modules, and > > > corresponding impact and churn on clients and servers. > > > > > > I suspect that OpenConfig may also have a date-and-time typedef. I > > > can be certain about how they would handle this same issue - they will > > > just update the definition. Some clients/servers may have minor > > > impacts when they update to a new version of the model, but the impact > > > and effort required is minimal, and I think several orders of > > > magnitude less then the potential resultant churn than would happen by > > > strictly following the RFC 7950 section 11 rules. > > > > > > Some may argue that I'm not being pragmatic, and that this could just > > > be handled as a bugfix, changing the existing type. This is one of > > > the key things that the YANG versioning is trying to accomplish and > > > allow. It isn't aiming to say that module designers have carte blanch > > > to change modules in non-backwards compatible ways. Instead, it is > > > saying that in some cases, the pragmatic solution is to knowingly > > > break the RFC 7950 rules and make a breaking change because that > > > causes less impact. Further, a key aim of the versioning work is that > > > it is much better to be explicit that a breaking change has occurred > > > such that a client can easily be warned of that change and take any > > > mitigation necessary - which in the datetime instance above, is quite > > > possibly that no mitigation is required at all. > > > > > > Finally, I will note that rfc-6691-bis contains a change to the > > > datetime definition that is not backwards compatible with the existing > > > definition because the semantics of the leaf are being redefined. > > > > > > > > > A somewhat similar second example: > > > > > > The YANGs IP address type handling of zone information is very similar > > > to my first issue, where OpenConfig came to the pragmatic conclusion > > > that (in their models) 100% of the use cases of IP addresses only use > > > the numeric form without zone identifiers, and hence when someone sees > > > the typedef ip_address, this is what they are thinking of, so they > > > just pragmatically updated their definition of ip_address type. > > > > > > Somewhat related to this, I will note that rfc-6691-bis contains a > > > change to the ipv4-address and ipv6-address regex definition that is > > > not backwards compatible with the existing definition (it narrows the > > > valuespace for zone-ids restricting it to ASCII letters and digits > > > whereas previously it allowed for any language letters or digit > > > characters). I believe that this change is not strictly compatible > > > with RFC 7950 section 11, but I still think that this is the > > > pragmatically right change to make without introducing a new set of IP > > > address types, despite the fact that it could hypothetically break > > > some clients/servers, and we have no way of knowing in advance if that > > > will happen. > > > > > > > > > A third consideration: > > > > > > Yesterday, Jeff and Mahesh presented in a NETMOD interim on their > > > learnings from trying to write the IETF BGP model. One of their > > > outcomes is that they think that some of the other models recently > > > standardized by the IETF don't interoperate well with the BGP model > > > and will need to be revised. I've no idea whether those changes can > > > all be made cleanly in a backwards compatible way, but I suspect not. > > > Hence, my concern here is that the IETF doesn't really have a great > > > path to getting a viable set of YANG models that work together, > > > because just publishing modules working in isolation doesn't solve the > > > industry problems. > > > > > > Because lots of the IETF YANG models have been written without a lot > > > of implementation experience (chicken and egg problem), often my > > > people who know the protocols but are not experts on YANG, means that > > > we can be sure that there are likely to be many bugs and flaws in the > > > YANG module RFCs that will need to be fixed or improved. I would > > > expect that some of these cannot be pragmatically fixed in a backwards > > > compatible way. > > > > > > --- > > > > > > My interpretation of the recent last call review comments is the > > > suggestion that we pivot to find a fundamentally different solution or > > > approach to solving this problem as an RFC7950bis. I believe that > > > would be a mistake. > > > > > > In summary, a group of participants have been diligently working on > > > this problem space for 5+ years. > > > > > > We have had a design team working on this area, and that solution was > > > then adopted by the WG. The authors and interested individuals > > > working on this area has presented updated drafts and updates to the > > > work at every IETF meeting for the last, 4+ years. Feedback at the > > > various stages/reviews/etc has always been considered, the authors > > > meetings have always been open, and I don't believe that the solution > > > drafts being taken to WG LC are architecturally significantly > > > different from the direction agreed during WG adoption of the > > > documents, although I do think that the documents are much improved > > > based on the feedback received. > > > > > > I also appreciate that Juergen has always publicly stated that this > > > work should be done as an update to the YANG language, but my > > > recollection was that he was in the rough on this issue, i.e., during > > > WG adoption, and since, at least until this IETF WG LC review. > > > > > > Hence, my concern, as an AD, is that if, after 5 years, the WG now > > > wants to take a fundamentally different path to standardizing this > > > work then I have concerns that the NETMOD WG isn't really functioning > > > properly and cohesively as a WG, and I'm very concerned that we won't > > > find any viable way forward for this work. I doubt that it will be > > > possible to get any quick consensus by opening up RFC 7950. We may > > > also find that the individuals who have invested a significant amount > > > of time and effort on this work don't have the desire or energy to > > > start from scratch again, when they have a solution that is good > > > enough for their needs. > > > > > > If I understand correctly, the fundamental objection to the module > > > versioning draft is around the updates to section 11 of RFC 7950, > > > which effectively state that changes MUST be backwards compatible, > > > whereas this draft states SHOULD be backwards compatible, without a > > > change to the YANG version number. Is that correct? > > > > > > If the existing deployment and evolution of YANG modules among > > > vendors, OpenConfig, IETF, and other SDOs strictly followed the rules > > > in RFC 7950 then I would probably agree that an update from YANG 1.1 > > > to YANG 1.2 is needed. But I think that the reality is that tools > > > must handle non-backwards compatible changes frequently happening in > > > YANG 1.0 (OpenConfig) and YANG 1.1 YANG modules anyway. I.e., I don't > > > believe that the "YANG 1.1 no breaking change contract" is being > > > widely honoured anyway, and instead is being treated as a goal or > > > aspiration. What these documents attempt to do is to move YANG module > > > evolution from what we currently have now where clients don't have any > > > way of really knowing how a module has evolved and whether they are > > > impacted to one that they do, and as part of that process they are > > > aiming to update the YANG versioning rules to better reflect how is it > > > being deployed and used. > > > > > > Hence, as am author, I still of the opinion that the best pragmatic > > > path forward is to try and get these documents to a shape where they > > > achieve rough consensus and are acceptable to the WG to be published > > > now, in the short term, as a good enough solution. After that point, > > > then I think that it would be great for some folks to form an idea on > > > a what YANG 1.2/2.0 could look like, but I think that coupling these > > > goals together would be a mistake. > > > > > > Regards, > > > Rob > > > > > > // Who doesn't really know which hat he is wearing for this comment, > > > but is only trying to do the right thing for the wider industry ... > > > > > > > > > > -----Original Message----- > > > > From: netmod <netmod-bounces@ietf.org> On Behalf Of Jürgen > > Schönwälder > > > > Sent: 06 June 2023 06:07 > > > > To: Martin Björklund <mbj+ietf@4668.se> > > > > Cc: netmod@ietf.org > > > > Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning" > > > > drafts > > > > > > > > On Mon, Jun 05, 2023 at 10:32:51PM +0200, Martin Björklund wrote: > > > > > > > > > > > > If the goal is to produce YANG 1.2 which (i) integrates semantic > > > > > > versioning into YANG and (ii) fixes known bugs in YANG 1.1 and (iii) > > > > > > does not add any other new features, then having agreement on such > a > > > > > > statement will help to steer the process. > > > > > > > > > > I hope that (i) doesn't happen. I think it is the proposed changes in > > > > > draft-ietf-netmod-yang-module-versioning that require a new YANG > > > > > version. If this new YANG version allows for other versioning schemes > > > > > than revision-date, then we can keep the modified semver scheme > > > > > outside the core document. > > > > > > > > > > > > > I consider the module update rules a part of a versioning model. The > > > > current update rules were written to support the current versioning > > > > model. If we want to support multiple versioning models, then we have > > > > to refactor the update rules out of the YANG language specification > > > > into separate versioning specifications, i.e., traditional YANG > > > > versioning and the new semver versioning. There are some language > > > > mechanisms (like the import statement), that have to be flexible > > > > enough to support multiple versioning schemes. > > > > > > > > Is it worth factoring the versioning model out of the language? I > > > > guess the opinions vary widely on this, depending on the dynamics of > > > > the software environment people are working in. > > > > > > > > /js > > > > > > > > -- > > > > 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 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod
- [netmod] Joint WGLC on "semver" and "module-versi… Kent Watsen
- Re: [netmod] Joint WGLC on "semver" and "module-v… Robert Varga
- Re: [netmod] Joint WGLC on "semver" and "module-v… Alex Huang Feng
- Re: [netmod] Joint WGLC on "semver" and "module-v… Kent Watsen
- Re: [netmod] Joint WGLC on "semver" and "module-v… Andy Bierman
- [netmod] 答复: Joint WGLC on "semver" and "module-v… Fengchong (frank)
- [netmod] YANG filenames in module versioning Jason Sterne (Nokia)
- Re: [netmod] Joint WGLC on "semver" and "module-v… Joe Clarke (jclarke)
- Re: [netmod] Joint WGLC on "semver" and "module-v… Jürgen Schönwälder
- Re: [netmod] YANG filenames in module versioning Robert Varga
- Re: [netmod] Joint WGLC on "semver" and "module-v… Robert Varga
- Re: [netmod] Joint WGLC on "semver" and "module-v… Andy Bierman
- Re: [netmod] Joint WGLC on "semver" and "module-v… Jürgen Schönwälder
- Re: [netmod] Joint WGLC on "semver" and "module-v… Andy Bierman
- Re: [netmod] Joint WGLC on "semver" and "module-v… Andy Bierman
- Re: [netmod] Joint WGLC on "semver" and "module-v… Robert Varga
- Re: [netmod] Joint WGLC on "semver" and "module-v… Robert Varga
- Re: [netmod] Joint WGLC on "semver" and "module-v… Jürgen Schönwälder
- Re: [netmod] Joint WGLC on "semver" and "module-v… Kent Watsen
- Re: [netmod] Joint WGLC on "semver" and "module-v… Andy Bierman
- Re: [netmod] Joint WGLC on "semver" and "module-v… Carsten Bormann
- Re: [netmod] Joint WGLC on "semver" and "module-v… Jürgen Schönwälder
- Re: [netmod] Joint WGLC on "semver" and "module-v… tom petch
- Re: [netmod] Joint WGLC on "semver" and "module-v… Carsten Bormann
- Re: [netmod] Joint WGLC on "semver" and "module-v… Martin Björklund
- Re: [netmod] Joint WGLC on "semver" and "module-v… Kent Watsen
- Re: [netmod] Joint WGLC on "semver" and "module-v… Jürgen Schönwälder
- Re: [netmod] Joint WGLC on "semver" and "module-v… Andy Bierman
- Re: [netmod] Joint WGLC on "semver" and "module-v… Martin Björklund
- Re: [netmod] Joint WGLC on "semver" and "module-v… Jürgen Schönwälder
- Re: [netmod] Joint WGLC on "semver" and "module-v… Rob Wilton (rwilton)
- Re: [netmod] Joint WGLC on "semver" and "module-v… Martin Björklund
- Re: [netmod] Joint WGLC on "semver" and "module-v… tom petch
- Re: [netmod] Joint WGLC on "semver" and "module-v… Andy Bierman
- Re: [netmod] Joint WGLC on "semver" and "module-v… Joe Clarke (jclarke)
- Re: [netmod] Joint WGLC on "semver" and "module-v… Jürgen Schönwälder
- Re: [netmod] Joint WGLC on "semver" and "module-v… Robert Varga
- Re: [netmod] Joint WGLC on "semver" and "module-v… Ladislav Lhotka
- Re: [netmod] Joint WGLC on "semver" and "module-v… Jason Sterne (Nokia)
- Re: [netmod] Joint WGLC on "semver" and "module-v… Rob Wilton (rwilton)
- Re: [netmod] Joint WGLC on "semver" and "module-v… Andy Bierman
- Re: [netmod] Joint WGLC on "semver" and "module-v… Jason Sterne (Nokia)
- Re: [netmod] Joint WGLC on "semver" and "module-v… Andy Bierman
- Re: [netmod] Joint WGLC on "semver" and "module-v… Joe Clarke (jclarke)
- Re: [netmod] Joint WGLC on "semver" and "module-v… Jürgen Schönwälder
- Re: [netmod] Joint WGLC on "semver" and "module-v… Jürgen Schönwälder
- Re: [netmod] Joint WGLC on "semver" and "module-v… Martin Björklund
- Re: [netmod] Joint WGLC on "semver" and "module-v… Andy Bierman
- Re: [netmod] Joint WGLC on "semver" and "module-v… tom petch
- Re: [netmod] Joint WGLC on "semver" and "module-v… Rob Wilton (rwilton)
- Re: [netmod] Joint WGLC on "semver" and "module-v… tom petch
- Re: [netmod] Joint WGLC on "semver" and "module-v… Rob Wilton (rwilton)
- Re: [netmod] Joint WGLC on "semver" and "module-v… Robert Varga
- Re: [netmod] Joint WGLC on "semver" and "module-v… Kent Watsen