Re: [netmod] Updated Content of Module Versioning - T8 (recommended-min for imports)
"Jason Sterne (Nokia)" <jason.sterne@nokia.com> Wed, 25 October 2023 18:51 UTC
Return-Path: <jason.sterne@nokia.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 DE715C180DD8 for <netmod@ietfa.amsl.com>; Wed, 25 Oct 2023 11:51:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nokia.com
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 sYn5HsnDJlQx for <netmod@ietfa.amsl.com>; Wed, 25 Oct 2023 11:51:17 -0700 (PDT)
Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam02on2121.outbound.protection.outlook.com [40.107.212.121]) (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 93F12C180DD7 for <netmod@ietf.org>; Wed, 25 Oct 2023 11:51:17 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HAAA9AA5Wpk5FkUB37lxH32aDbPgxBRe21g+Eemvsg1TVrbAi8SWmh1wTAMR/hSvuo+Z2FmjO+faQI144qWLspXBkKcqIq70v+SD6m+2Yv5k9jOjcwlo3Y+QGbqqIqpNjYCRKUaaSipeUV/q/1vJtYgui6N9AREWb4oyGUURG86wOiUFPO9z+TafXc5FRU3qy9Fxt0ULHFEPSD/V6XQNgAe/nMnl6oQmwmnNvFb0GKDs0KaF3MoDXKYRAwGtAtG/Avh9olGSBdtKXf7NWFd+KjaNRz0eMDsPmS4Sxyw+qNLKdm/shLpbHwMA16LGlrwhgZqhcIFkG8m8we+nsHs9Bw==
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=VTcLmNPaOzQTCF1YgzKnhSlUce/Z6cAuFa/iuEtHU6s=; b=OQRbsiw/8UJyexOrnWarYr6ifK+yn+wDabfXawIZ3HIeyEyHoUem7C31Cjr1erbYQ0dZQOz47Vcw+DkbLMVXbGLII7W2uAsNtwu0LdbYUTIvJ0xN2d+isDImZh7XBitv2Hpn5C8XPJMuoNaxTpPH4MZyVNOf8yVatIZFs4GehcUnuhgaF++oatHmfnPETa0rNmwLMAPIOH4hBQNih1UTwXEGwIMDcG4VrfoYLUeyEYfVNc0NSnr/rfj5qO7e8TJ5p57Es4pb/LlPT7yqpZl1OilqxEWL7rkrlsY96zmCGF12m1m+7FQFieusG996+w8mUvh3KF4DxWCcsJ4GgXT/sg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VTcLmNPaOzQTCF1YgzKnhSlUce/Z6cAuFa/iuEtHU6s=; b=awRzZDJ9CGhyPH+ylU9mZXUD86+USEEKLREC2Z3pW5Cd/bUnWIaxBh0EJIoZIGiiDvzZ3ruRGXUz1DsH49gyH5/kf7aIO/NpUWvGQQ0YxVfn+yZW9vYoWhtH4ucSa78bud89tnWx08jYZRSR+zFyHMeHiHFbTOp9iiuG4b/1Zli1KyvJ2Km33OgJVe5TZNFpF0HBcwdZLlLoTPBaa6VDpSwX8SoPcXV+R27xRX9gTA00eGeQWYlvPaJjf9DvQAgePg0tQHIyHMn9Y722KEMpFSjp5IyByopHcfhggVtrapqDrv2ZvwnDp2s2HwLiv2BrB6LJqo17fGfy0guKWcj/9A==
Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by PH0PR08MB7812.namprd08.prod.outlook.com (2603:10b6:510:f9::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6907.33; Wed, 25 Oct 2023 18:51:13 +0000
Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::6f8f:a6f0:6e58:40fa]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::6f8f:a6f0:6e58:40fa%4]) with mapi id 15.20.6907.032; Wed, 25 Oct 2023 18:51:12 +0000
From: "Jason Sterne (Nokia)" <jason.sterne@nokia.com>
To: Jürgen Schönwälder <jschoenwaelder@constructor.university>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] Updated Content of Module Versioning - T8 (recommended-min for imports)
Thread-Index: AQHaB3LYqkvogyUV2UuKLTnWhXeE3bBa188AgAAAQ4A=
Date: Wed, 25 Oct 2023 18:51:12 +0000
Message-ID: <DM6PR08MB5084E77F09A76DA00D5D34969BDEA@DM6PR08MB5084.namprd08.prod.outlook.com>
References: <DM6PR08MB508483A98537B82190016B0B9BDFA@DM6PR08MB5084.namprd08.prod.outlook.com> <DM6PR08MB50849A7A2F50322C9C374E0D9BDEA@DM6PR08MB5084.namprd08.prod.outlook.com> <ZTliKtYPTq249rqb@alice.eecs.jacobs-university.de>
In-Reply-To: <ZTliKtYPTq249rqb@alice.eecs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DM6PR08MB5084:EE_|PH0PR08MB7812:EE_
x-ms-office365-filtering-correlation-id: 54da4f6e-a18a-464b-b2e1-08dbd58b5c4a
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: FHH/F4WdxHNHQ07eERbGQyV3VxFKUv9mP4vi4ewkbFoAJ/eOi5aiIuRnBr5Uqzq6CqwWwAEPxq6tm1LXzjK/J5tSnA4jXgWpppI0Izm0gUbsPO+piTaZavwmENnmH4pWcCJu/ELn2kInuB0d45G/8TB7BvFkipu0yyJfsf0r5N3sXJe5AK1f3o0/BA0pZZxNth0TQ1R/r4wPJqGWj7YghIuiJvcSZbLga8PkQqsC/gBhJcNW1uNolsoh1eqZgKySbPBV0s4QYXiBxUAs223fAN/++0qXP92dQ01GGnh/5kOgmnXxpjNW8QqbXI2/nfScwS94VuTe12u+h6L/yzzJqQOOD/fd9FhabP3KPcsDuprt9wfKBA17kAqC0gL6bJgeZY6DkxVVLeLGhS8MLNpAv2Xo7P2sqZSpYODlH54mUZ42gbStOKo+AyLSj/nlPApSNC0oGMZaxYTHwdN37pL+Ti09Njqf9WC9NDa2OWbvaqEjdQc6X+hvsBGpSUguo9UfvdGUkl3qNz7YdbtQiH0rPb8E4sK1HLppKSq2DaM+Gx2Le91asdBP1sozd9gH0H1TWrZcxwaJAFxoIsze/yH4tD/lxadA5HX731HA+ZTUIjttnWR9evU/N/nZIWBIj2G6kst9Ifp3irINnIs17jvr8Q==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB5084.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(376002)(136003)(366004)(396003)(346002)(39860400002)(230922051799003)(186009)(1800799009)(451199024)(64100799003)(26005)(38070700009)(84970400001)(2906002)(38100700002)(5660300002)(6916009)(55016003)(41300700001)(86362001)(52536014)(15650500001)(122000001)(76116006)(8936002)(33656002)(8676002)(4326008)(82960400001)(7696005)(71200400001)(66556008)(478600001)(66446008)(6506007)(66476007)(40140700001)(64756008)(66946007)(66574015)(316002)(966005)(83380400001)(9686003)(53546011); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: oh9xSCgYJa9JK/5xlFJEviV/HTkzPTWyp7l0errSYJsPUl+eY4/HVOokXUH6CKs15ReAHWzQ/awJtwuF5++3gilROA35aaFHmpBGlVH8vr7jlUSsLroJK2tt4tbHlFJ60JJvWzCaimyacbAt/UlcnvOnh6NPULk16/du+nxduYq6FSNzUgg0MAyfMXssRoWArrRkRA32CBPNE9yfKaGJ2oE8VdaOlMliITEPcnrkWT7m9ed3xFCcIX4YYD9grh/9f/ngziTMz4v+2u8MRUwCoP2L1lTLg/raTKpdmme0gj1MhymwECzIHZcOx/v+DX13dcGlLQOT9p/IecQ4x8fwCdHnYC7QMHMOEqpq/QG+HuLoqIk2uqpIFCCuV1srXISTQFuBjet/Za43M3A9eoma026kNUzyRpdlzo8T18LY5qYOtmk5fSBhkN3sUToXAVyhMPfq7yx6TEiizkOeV594vNvgBmoKt+sj0uG3nfWB9h8bnmTSkqVP/B8UjDwYVzv+5DGJru8v1mY0tN6Qw82+xb4kLXsbaJtJ5KVOrJtxqAxAVs3Ags3wXP4484BMaw3MNnu2SiMVjI9/WMVTL+1nIPQ4bzO4RHu6CAKTwsBi/K8uSZ3Nvtulhn+Ze3HEkVM9QLW76Rb2hpp9bh/uKeRPNixlMq6rMKZgGXPjuiaULnCszGR7UYwwetKrROChSNdtu9H9aas/hQV5ajlYTc5MsXlqWckFw1W8BlTVbia/0JOX+WTbwQDvoicJp4OiZ6IX1+HD44GXEpBB8d06/hUJOc1V2Ie24oce6AMQy9i58LY+YnWPoNJrWiA9AcMU1C77OgGfgi/5I73t1XO6K1Y12/nmTmwG/5qrvP46e0fQEW29PWcGLAUPoJm/D0LQYs/lDg+IXR4UbW13TZs0RlXPqxF1o4IhPg1ydk/N4RscP4ivhSghdo4/ZfS6cQeoZBEtKZBgMq9/m92yF1SfiDnZJemBiNKqhE8lEB9Dn5oSymbGRFxo2SGnDGbXdULEf4tmR8WjbM0XHVy1dKvD8LdIkDILFLMAIEWkLKj9WsXmsza/h9QzZfMpKYBouPzHQ/VORYz0gQ0onTUXjYxMj3OsY6zvIQzlNuFkXLTP7wMHI1c0unn73eu/Q30POhEvH6YV0rVpybtDXdOOluzVqeZwuaSKT+RoLlMaMxCV4EhKNl78TVtp7wnjHtWEF66H9/Ns7ePC+TtxzNDczaYvLPs+bgH5efkiYtbyK1H81eZ2xBvkkEyVZ9jt06WXsesO/MBr/0+xnDJMaWjxbz4h2EBJZBr4AlMg+t8nRPEz1/Kr4KvHpGkJdGW80wNSbdubUlbrJd75U21LLYa3pbI6RL6pAPcKp2QvdHkMLB2xC+q0hBoZI4wcFelulPjowtuwHo0nfrAPcztFvCMC5s51hGNz5P50uy5JAtGan+OgM8ybsCfwzEYV20fpPwMFkIYM6JhaC2q3cVQe+8TYg9xecrI1Vmd8b3XW5ubnDz3rqvdHJZFVQwUEJbZgpbcMGN85m1BKjOFdvc9ZvkrnZLx0LWpJ4DSdp5J3UqwDB3Qz9YBco2RnVqJGLPHoFyj3WqrXSQyW
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB5084.namprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 54da4f6e-a18a-464b-b2e1-08dbd58b5c4a
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2023 18:51:12.8223 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 4X1/Gv5TObajZF95MBzkXcURcVlLsUuHK6mctYZY0gfDn1tKzr1mNQrBzgfBfSssl6m1mpTypxEUL6FXKDv5kQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR08MB7812
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Kn79WprNZhtNgdeNEn32pBgHdYY>
Subject: Re: [netmod] Updated Content of Module Versioning - T8 (recommended-min for imports)
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: Wed, 25 Oct 2023 18:51:22 -0000
Can you clarify what you'd recommend then if we don't have it? For example: - IETF module A needs to import ietf-yang-types to use hex-string (only added in the 2013-07-15 version) Use import but without a revision substatement? (i.e. avoid import by specific revision)? Add something to the description of module A to mention it needs at least 2013-07-15? Jason > -----Original Message----- > From: Jürgen Schönwälder <jschoenwaelder@constructor.university> > Sent: Wednesday, October 25, 2023 2:45 PM > To: Jason Sterne (Nokia) <jason.sterne@nokia.com> > Cc: netmod@ietf.org > Subject: Re: [netmod] Updated Content of Module Versioning - T8 > (recommended-min for imports) > > > 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. > > > > I am strongly against this. The import statement is used by tools. > Adding a recommendation for humans that existing and conforming tools > will not understand just causes confusion. > > /js > > On Wed, Oct 25, 2023 at 06:41:19PM +0000, Jason Sterne (Nokia) wrote: > > Hi all, > > > > Starting a dedicated thread for T8 recommended-min for imports > > > > These are my own personal opinions (not those of the > authors/contributors). > > > > It has been discussed before that import by a specific revision is > somewhat broken (not recommended). It is mentioned in section 2.5 of the > versioning requirements draft: https://www.ietf.org/archive/id/draft-ietf- > netmod-yang-versioning-reqs-08.html#name-no-good-way-to-specify-whic > > > > Based on previous WG LC discussions, we already changed from a > revision-or-derived extension (that did affect conformance & what a tool > could/should use), to a weaker recommended-min in order to avoid further > changes to the YANG language & conformance rules. The recommended- > min is pretty much purely a documentation tag that helps users of the > modules understand what versions of imports might be best to use (e.g. > when supporting multiple modules in a server, or constructing a "package" > of modules that work together). > > > > We could instead just say to put this information into a description field in > the module. But it is helpful if the field is broken out (i.e. structured data) > and more easily machine readable. > > > > So I'd like to see this stay as part of Module Versioning but be renamed to > recommended-min-date. Then in YANG Semver we should add > recommended-min-semver-label. > > > > Jason > > > > > > From: netmod <netmod-bounces@ietf.org> On Behalf Of Jason Sterne > (Nokia) > > Sent: Tuesday, October 24, 2023 9:58 AM > > To: netmod@ietf.org > > Subject: [netmod] Updated Content of Module Versioning > > > > Hello NETMOD WG, > > > > The YANG versioning authors and weekly call group members have been > discussing the next steps for the versioning drafts. > > > > We'd propose that the first step is to converge on what aspects of the > current Module Versioning draft should be retained, and which parts should > be removed. We can then work towards a final call on an updated version > with this revised scope. > > > > Below is a summary of the main topics in the Module Versioning draft. > We've divided the items T1-T10 into 2 groups: > > A) Baseline content of Module Versioning > > B) Items which need more WG discussion > > > > In addition to whatever discussions happen on this email list, we have also > created a hedgedoc where you can register your preference for items T7- > T10. It would be much appreciated if you can put your opinion in the > hedgedoc here: > > https://notes.ietf.org/CdKrT5kVSF6qbnRSY4KeSA?both > > > > > > GROUP A (Baseline content of Module Vesioning) > > ----------------------------------------------------------------- > > Based on resolution of WG LC comments and subsequent discussions, and > some feedback to reduce complexity and content in the Module Versioning > draft, here is a summary of items that will and won't be part of the next > update of the Module Versioning draft (also referred to as "this draft" > below). > > > > T1. The "ver:non-backwards-compatible" annotation (Sec 3.2): > > Retained. This top level (module level) extension (which can be ignored by > tools that don't understand it) is critical to include so that module readers > and tools can know when NBC changes have occurred. > > > > T2. Updated rules of what is NBC: (Sect 3.1.1, 3.1.2) > > Retained. These are updates/clarifications (i.e., changes) to the RFC 7950 > rules that are appropriate and helpful: > > (i) "status obsolete" > > - This draft changes RFC 7950 so that marking a data node as obsolete is > an NBC change because it can break clients. > > (ii) "extensions" > > - This draft changes the RFC 7950 rules to allow extensions to define the > backwards compatibility considerations for the extension itself. The existing > RFC 7950 rules only allow extensions to be added, not changed or removed. > > (iii) "import by revision-date" > > - This draft changes the RFC 7950 rules to allow the revision date of an > import-statement to be changed/added/removed. The imported module > must be versioned separately (i.e., by a YANG package/library defining the > schema). > > (iv) "whitespace": > > - This draft clarifies the existing RFC 7950 behaviour that changing > insignificant whitespace is classified as a backwards compatible change > > > > T3. revision-label-scheme extension (Sec 3.4.2) > > Removed. Based on WG LC discussions we will go back to a single > versioning scheme for YANG modules, and hence the revision-label-scheme > extension will be removed from this draft. > > > > T4. revision-label extension (Sec 3.4) > > Removed. Related to T3 above, given that a single versioning scheme is > sufficient, the revision-label extension will be moved to the YANG Semver > draft, and removed from Module Versioning. > > > > T5. Resolving ambiguous imports in YANG library (Sec 5.1) > > Removed. This will be removed from Module Versioning (could be > considered in YANG Next, although that is many years away). Note, RFC > 7950, section 5.6.5, paragraph 5 does consistently define how to build the > schema. The change in the draft was to always prioritise an implemented > module over the most recent implemented *or* import-only revision. But > this will be removed. > > > > T6. Advertisement for how deprecated & obsolete nodes are handled (Sec > 5.2.2) > > Retained. This information is important for clients to be able to accurately > construct the schema and hence it is retained in Module Versioning. > > > > GROUP B (Needs WG discussion) > > ------------------------------------------- > > For these items we don't have consensus within the WG - they need more > discussion and input. > > > > It is recommended to go back and look at the NETMOD emails on these > topics (from the WG LC discussions). > > > > Please add your name beside your preferred option in the poll: > https://notes.ietf.org/CdKrT5kVSF6qbnRSY4KeSA?both > > > > T7. filename changes (Sec 3.4.1) > > The authors/contributors are leaning towards suggesting that this moved > change be moved to YANG Next consideration. However, there isn't > complete consensus, with concerns that the vendors will each define their > own incompatible file naming schemes for YANG modules that use version > numbers. If we retain this work then this would likely move to the YANG > Semver draft. > > [See hedgedoc poll T7] > > > > T8. recommended-min for imports (Sec 4) > > The WG seems to be somewhat split on how urgent this is, and there isn't > consensus amongst authors/contributors for retaining this work or > deferring it. One option is to keep it, but renamed as recommended-min- > date. > > [See hedgedoc poll T8] > > > > T9. Versioning of YANG instance data (Sec 6) > > There wasn't any consensus among the authors/contributors as to > whether this should be retained or deferred to a new version of the YANG > instance data document. > > [See hedgedoc poll T9] > > > > T10. Do *all* whitespace changes (including whitespace between > statements) require a new revision to be published? Sec 3.1, last paragraph. > > The authors/contributors are somewhat split on whether to retain this. > The advantage of keeping this is that it makes it very easy to check (i.e., via a > simple text diff tool) whether two modules pertaining to be the same > version are in fact the same. It should also mean that it is easy to generate > a hash-based fingerprint of a module revision. The alternative gives more > flexibility to users to reformat modules (e.g., for different line-lengths), but > complicates the check to ensure that a YANG module revision hasn't been > changed or makes it slightly more expensive to generate a hash since the > module formatting would need to be normalized first. > > [See hedgedoc poll T10] > > > > Jason (he/him) > > > > > _______________________________________________ > > 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] Updated Content of Module Versioning Jason Sterne (Nokia)
- [netmod] Updated Content of Module Versioning - T… Jason Sterne (Nokia)
- Re: [netmod] Updated Content of Module Versioning… Jürgen Schönwälder
- Re: [netmod] Updated Content of Module Versioning… Jason Sterne (Nokia)
- Re: [netmod] Updated Content of Module Versioning… Jürgen Schönwälder
- Re: [netmod] Updated Content of Module Versioning… Jason Sterne (Nokia)
- Re: [netmod] Updated Content of Module Versioning… Joe Clarke (jclarke)
- Re: [netmod] Updated Content of Module Versioning… Andy Bierman
- Re: [netmod] Updated Content of Module Versioning… Jürgen Schönwälder
- Re: [netmod] Updated Content of Module Versioning… Andy Bierman
- Re: [netmod] Updated Content of Module Versioning… Jürgen Schönwälder
- Re: [netmod] Updated Content of Module Versioning… Jason Sterne (Nokia)
- Re: [netmod] Updated Content of Module Versioning… Andy Bierman
- [netmod] Updated Content of Module Versioning - T… Jason Sterne (Nokia)
- Re: [netmod] Updated Content of Module Versioning… Jürgen Schönwälder
- Re: [netmod] Updated Content of Module Versioning… Jason Sterne (Nokia)
- Re: [netmod] Updated Content of Module Versioning… Jürgen Schönwälder
- Re: [netmod] Updated Content of Module Versioning… Andy Bierman