[netmod] Re: Defining groupings after the fact? draft-jouqui-netmod-yang-full-include and the reuse of definitions
"Robert Peschi (Nokia)" <robert.peschi@nokia.com> Tue, 30 July 2024 12:37 UTC
Return-Path: <robert.peschi@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 7A734C180B55 for <netmod@ietfa.amsl.com>; Tue, 30 Jul 2024 05:37:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.243
X-Spam-Level:
X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.148, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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 nKmd-dOADlnz for <netmod@ietfa.amsl.com>; Tue, 30 Jul 2024 05:37:04 -0700 (PDT)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2043.outbound.protection.outlook.com [40.107.22.43]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92FDDC1519BA for <netmod@ietf.org>; Tue, 30 Jul 2024 05:37:03 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=vq8veHbIrGxcAU1G5VJzWu549IyNr5dX4ZZs1rleXPH7xQHGDw1qI8OYPSTh7Mch2Viz9SIFNZ3JQLdx1iatQjHYCpGiR1PF7XIBXOs6SrEw0ijcR51KEtJPims8LaCx5bHbzgApiPnkD/c6Vih3ocr9XKYUGh5x9IiZ90BxWxRaxtsIWZq4Xm0fDhaL91qO/SnFH8xBAI3NzxRrgRH2Sv4gxPDa0HsE1K5e6ODpJ50tYKqHhOaCl1Vw5DGqPjZhoRc1e4Yq+XPRp3+3/im6uoBAfTvpvm6NQocn78I0YwaI9hTMNXMgwcV5uWHuKMjBcD/YRUDohJF99NBwkn3Pog==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=5/2ZTzz/pPJRABaRcmuTpqVT93BN//EGhLg2idzpIFc=; b=J/69M2ED1j11dEDo7f6AWKFOS87GV4lWCB1DOThMx0HanamW7be6vbokXIyUQsIFc4eb3rc7mWawEbtoinxySok1H8JbJjFOmsUrq995WGScDiOBT+sUs1vKfCt32/nEaFnARrnECikhzgym4wkUh4DjTzPKhyeS3TtV0qdPC+ygu28vyAV8lAHSkLAq9MvcJQhbIZ2PWHFvqVA2WZCuYHDmcNMeCOIpD9DTFkApRIWs1xjkGGe/y5q5QfIh6l81yliBE89NLyrdi48dpYEDOm45+eqdy1xzNDWbXSvnV73ULpZb7Sl4F1jjVJSlYH1spC2qme/jLPupQ6hhrKWuUg==
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=5/2ZTzz/pPJRABaRcmuTpqVT93BN//EGhLg2idzpIFc=; b=Eibh8GdFRwmZO1aGeW9Oz4C9hKTLQNlIkBiNDL+tuYiX6PTbA7NWutbfQUfXS+OTL9v6EkVFcWcHngpcOzG2u8IOsJDVkjhlYkuinJk0YvbfJrTH1Iz5RG7YF85BKcBlWsQhhCLUY9evsQNZFNm2kMbTubEtD/oluvhoSU5vNiUdBl/wdSMsGS/IIya0rE3H6L8kbKbahLz7OqYlFCu5Rxuu1FS3ZAV0Gj1OMNRTlz4gH6BsPaEiaoIWohZPVuzv6TwrbpUQn/HJbyyzcPfDc0qVi7niHmnKZwxfbs0ZonKb33exzKT5Mc4vDwdb5pdIDU3DPGDWMxHRKXAO3ZyFaQ==
Received: from VI1PR07MB10115.eurprd07.prod.outlook.com (2603:10a6:800:1de::9) by GVXPR07MB9703.eurprd07.prod.outlook.com (2603:10a6:150:111::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7828.17; Tue, 30 Jul 2024 12:37:00 +0000
Received: from VI1PR07MB10115.eurprd07.prod.outlook.com ([fe80::19ca:7f7b:ad19:7726]) by VI1PR07MB10115.eurprd07.prod.outlook.com ([fe80::19ca:7f7b:ad19:7726%4]) with mapi id 15.20.7828.016; Tue, 30 Jul 2024 12:37:00 +0000
From: "Robert Peschi (Nokia)" <robert.peschi@nokia.com>
To: Jean Quilbeuf <jean.quilbeuf=40huawei.com@dmarc.ietf.org>, Alexander L Clemm <ludwig=40clemm.org@dmarc.ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] Re: Defining groupings after the fact? draft-jouqui-netmod-yang-full-include and the reuse of definitions
Thread-Index: AQHa4mPVD3Q+2/+WpkyFHVC7BwWUTLIPM9fw
Date: Tue, 30 Jul 2024 12:37:00 +0000
Message-ID: <VI1PR07MB101154883E4D68E33A331FD57E1B02@VI1PR07MB10115.eurprd07.prod.outlook.com>
References: <e111be29-e825-4357-88e3-19c9b3f87930@clemm.org> <b0780aa0c8504c93b7d5ff6c837ea697@huawei.com>
In-Reply-To: <b0780aa0c8504c93b7d5ff6c837ea697@huawei.com>
Accept-Language: en-GB, 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: VI1PR07MB10115:EE_|GVXPR07MB9703:EE_
x-ms-office365-filtering-correlation-id: bc510edc-e99c-441d-627a-08dcb0944ee5
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|4022899009|1800799024|38070700018;
x-microsoft-antispam-message-info: hJ0vyXYpykfvMKcAX2BFUw4/hyik++O9RaWyVveXUgFRm5nTdIWGWZ1m0+Qu/lDJ4kSKlXvvoPRHzQXTF2SH2ce4UU954H/aHgE1XDyleFiG/ai1wpVxwfGSJOvQWzTcDcAGobWuRaiPjAXHc9ogPXuUoUoEwYnslLkktgwHWNTp7UfXtyu1idJ5XRZ/Dpd/1BW2nEkfQg1xTCezcZXjWGZlV1oqmAk9hsEknABYPaQgwUyEGk7ML/HNqRBpmFpjODLmplluuY257kpxZC7ooq5o4C1DqvxIhMnf96epcdOTN2S6snCz82Lb5nM+v46ig66sJgi7YKLZoTZ6GL7yHJGbbFNJAd+2MLn/cWKfSB+2f6IHPNvOZMbMUhs6KjxTlI5gclyK093LAEq0E6BcmaUSuhmhO5G/vxEfF4ZYk3X66wh61RpA2WtdqjB29mzwRAMJgA/Y5+nDx1+Tw55cggZRIHxWqPD4ICMBtORwlR5L/4xP8AUgtYvS3ddhb14n5Z0B0rpo/kN+30rQvL0lf9BL/atlE1DkB1lsCdEIsNCAMs0dUR955dpgYs1GSYPy9F5Cd52cqBVqenvENiJBK5jEwfs4EyTUJ/N/QQrK9ySP9uXt22DKRv4xBzZLEXm41H1yjWd04uyKQZaDZIF2t6FoSZQbrtn4AactVa6XNWqk7nofU+0R79Ylr/IyNH7VqmofPRyX169qLuoaY2ufRznrky/yqZX1/YDfNVF1N3UchzSJUL029YBnOifEyZJbbYj9N3qVCwoN+yqGvbHwhkoG9xo51GCOmxCTDUXxrIFid5cVbuS5WSKyIfD/1k664bXS+7PutoFltLsKuBRgoJDIxlzkDwXrVTei4AMChpPL+oriowN4ahYCszewe83i7lf2hIWIOwIgVGdgVZrxKBBV7Nnz6z6RJX/lENYf2MUKEs4E81SoQsx/tGtXwIiPE5zQRzDrkY5e7ORwtHAGamXs66vUBbLCITBzKXkvbCpna3Upo9ECySbqFZE+YYhvePIr2MmgDC9WGQjQOp8H6q+TKdfaPFknXYoeg83Cz5/ukaQPTiWUOC+wDA6BVKMQOdPP45+yPisRycoPi71lucysxqRN1m4cYBuuyOe4DJQvCi4e+/H+CLLkoVZzgjccVQnoJiM1t/yMLIbLTPflxQzy7Csn94Vy6kXKwuFhLTbPUtQXS3wae8lA7LDpPojPEJZAyWqo//nnx6m+t3VlbfSuK3wkF0vIXYO3Nz7HUx4ODlZTEfHHCuZ2j3dq9zf6PjzH+HW4tYLidQeBy34JgqGuoKt1DcQHaSQjQuNtvTRcF4L9INyLEIKlxskN/p3IkSMB0MLLW7mf50EXNJbrMVO9ba9hsGNJ2fzCt/LRNKs=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR07MB10115.eurprd07.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(4022899009)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: zK8y9+epErk9xpVldsbulJJXRGPBQPCzWLnzyMg+FHNFFKj7cCusJtFckj0vO/gF6NJryxKOyaY3CSbJSlEdKE1W6LqOJ4N6GI2J7QRRsZVMFSRVb4kuphQdfxhjIbAi2wynX8KWlhYM/Tc+fSqCmoVX3c5nnR6kBGLeg1T7Id2cXC+lnEEm57EV0/QIdvu6MeCJJ1FZFktJuhBPzJzCCc7TpAhQe1mj2TGd3WjRYzWvaLJW+r5sEjp3Y4t3jTei0z1cLjXA3mW7D2F7oHQsS89RBAoTJwX4tCeVFph0Na5vGliBm1g3zZpse3hSLxqntIzmnVSt/wT13o/1ykqi5fSFBY053/8azdk7eSVqgfw/gfLVh+teOLZdqoRZWVmGGot2NKy7Hj3yMYkSRhbag7G7HdGuJ7K251vIQ4OhEUOMBzaaZoBUchJLKBow+8JiMbgYZ4GPfi7WL83I5S3HqX/tQhtoTUA5e0FbKp5+t7dJlQZscSF9Ip5TN/+1jSzNP70BSnANftokXyMgZqKPW7Kc6nKavggKef/qro0eI05POlvzX0JwX2Hn92W77VMOSJzUlsRHDqlywgMULtOVOOjyWG1JB87NS4/bEYifEPjKnlVqun6x6oL/V6/kV/StyIWEKguJPZvpiEozsXK7gtf2ymjvLwHtVYSLR9z5fJPirl4Rq5V+VE/4xWo0QBJOGtDnMfDJXY8oUtOyZ52YlpsltLdS5MSjgu9riqcd0JpAdtQn+wOjsL+IweWhjDcgBkNidtBqHD46VoKUoPX0c3GbwKg1oRtdPA0F5Zqi7DvonKN5Te+Smln0OjexV6rOXgKgA20DsmBLiX3oCaRQ5UffLCOak1PJYgkHRY52I/FVN+6pi2tJrTzZJQp0Zh7LB5w+qM2gofyU6I0FvchsBycuUFWQQqPl5l+8iyI4CRPCpWGmKrWP6VKvMO8z0vXbiteuYDdUBhEmMahYAv1wF3anK9VZj4I8RQDxd69JbOOirICiSC4BdrNazB3LMj2OUPlw1B1xHJCuTscMB4E8ukOoyd6CFraevP6S7fVTLQUvJBbLovabvwhbGdbK3QJ1FefRDe5irBXBbJVUlfXBssFcmbg7CMAaGknPcVW0GUGdz2yAv99Icm2vqZbB09POpjYyMrCMxEftzxkFNj9hd+kERcGLRjO2zOfnA9t6C8h/N9e22SaNkIMk9MR//54eEqVhWagmiByqOtDojVWtx6z8UL6pc3+oLnjWqrvqowSP6iXb3y5Xz6M6WjQ6vr+Yxc6w7sZ3buESz3vH2lbZkp7yY6l93HasPKei3JtaX+EVi2IPqdASbDXnWFYHG9+TlAb8ioGFPbdqVcb7mHw5BUWgmo+Jpky1uCt3CTcF0Sl4lPMbBejxOOco7LSnkVl3bvgcq0TJAns2QX3/ViRNnBE4GGtxXljpbh/834dn2WZ1qLdIsNaZw1gESaqfrDcb7Vtkp7RP6Acah7xpZzA54tDGmwNcLjm+midiVmGvGU+NFCYf/C1UClMfLeOJOLFTKbZLsmwW+rQp4FPttaMR9OPyP5A+dQgcdSYQvIjvXjjKoNakWUisHwOK5wwsDdDN
Content-Type: multipart/alternative; boundary="_000_VI1PR07MB101154883E4D68E33A331FD57E1B02VI1PR07MB10115eu_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB10115.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bc510edc-e99c-441d-627a-08dcb0944ee5
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2024 12:37:00.4869 (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: f1rEzvmMdEkBV6KwlH/B703qUIakTuVo7lvaCkgz3LRQ4qiTrs1GvEUy9/JC/XvP26iJypDpufD/VO5/1EUetw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GVXPR07MB9703
Message-ID-Hash: VJOPXYNPMVBZNY34SWQ5Y3BNM6PYUC2W
X-Message-ID-Hash: VJOPXYNPMVBZNY34SWQ5Y3BNM6PYUC2W
X-MailFrom: robert.peschi@nokia.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-netmod.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [netmod] Re: Defining groupings after the fact? draft-jouqui-netmod-yang-full-include and the reuse of definitions
List-Id: NETMOD WG list <netmod.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/GCDoGJzlXOJWkdmsU9KIGbNNA3g>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Owner: <mailto:netmod-owner@ietf.org>
List-Post: <mailto:netmod@ietf.org>
List-Subscribe: <mailto:netmod-join@ietf.org>
List-Unsubscribe: <mailto:netmod-leave@ietf.org>
Hello Alexander, Jean, all, I fully agree with Alexander that groupings have great potential. > On a more general note, it strikes me that there is an increased need > in reusing definitions. In various forms, we see this in your use > cases, in network inventory use cases, in schema-mount, in peer-mount > When it comes to reusing parts of definitions, it seems that a lot of > grief could be avoided if portions that are to be reused would have been > defined as groupings, which could then be used wherever needed. > The problem is that the grouping construct is rarely used, so many > YANG definitions are not available for reuse that otherwise might be. > > As a thought, it might be useful to introduce a construct that will > allow to define a _grouping_ after-the-fact, for later reuse. I.e., > allow groupings to be defined in a way that the new grouping embeds an > existing definition, then simply make use of that grouping. That > would seem perhaps cleanest, able to address many of the use >cases and have the additional advantage that the semantics here will > be very clear since part of the existing YANG framework. Doing so would indeed be very useful. Actually, when experimenting on supporting templates as introduced in slides-120-netmod-10-bbf-liaison-on-management-at-scale-projects<https://datatracker.ietf.org/meeting/120/materials/slides-120-netmod-10-bbf-liaison-on-management-at-scale-projects> last week, we found that defining grouping for standard data nodes would allow applying "refine" statements to them in order to easily control mandatory and default statements of data nodes - a flexibility required by template methods, as explained. Moreover, with such groupings, one could think at solutions available very quickly, still with current YANG 1.1. > Grouping does not solve everything, you cannot augment a grouping so any > augmentation would have to be repeated for each use of the grouping. Jean, I agree with you that groupings have their own limitations and attention points (e.g. xpaths !) but I find that their "refine" capability can be a great advantage in the above context, though. The issue you raise about augments could be alleviated by defining new augments in new groupings, leaving the original groupings untouched. If these new augments are to be used elsewhere, it would just boil down to adding a use statement for this new grouping at the target place. > I think the semantics for Schema Mount as defined in RFC8525 > is the key to reuse the full semantics of YANG (i.e. not only groupings > but also augmentations, rpcs ...) without having to modify existing modules. > What we propose in full embed is just to enable a simplified version of > schema mount, for design time. I fully agree that the "full embed" design time proposal offer key perspectives in the long term when it comes to reusability of existing YANG data nodes/modules. On the other side flexibility in mandatory and default statements (call it "tuned reusability") is something it should also support to enable templates, though. My point is that groupings that contain standard data nodes could be one way to ease such a "tuned reusability" - to be further discussed. Thanks, Best regards, Robert -----Original Message----- From: Jean Quilbeuf <jean.quilbeuf=40huawei.com@dmarc.ietf.org> Sent: Tuesday, July 30, 2024 11:35 AM To: Alexander L Clemm <ludwig=40clemm.org@dmarc.ietf.org>; netmod@ietf.org Subject: [netmod] Re: Defining groupings after the fact? draft-jouqui-netmod-yang-full-include and the reuse of definitions [You don't often get email from jean.quilbeuf=40huawei.com@dmarc.ietf.org<mailto:jean.quilbeuf=40huawei.com@dmarc.ietf.org>. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] 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. Hello Alexander, I put some answers inline. > -----Original Message----- > From: Alexander L Clemm <ludwig=40clemm.org@dmarc.ietf.org<mailto:ludwig=40clemm.org@dmarc.ietf.org>> > Sent: Monday, July 29, 2024 8:22 PM > To: netmod@ietf.org<mailto:netmod@ietf.org> > Subject: [netmod] Defining groupings after the fact? > draft-jouqui-netmod-yang- full-include and the reuse of definitions > > Hello Jean, Benoit, Thomas, > > After your presentation at IETF 120, I looked at your draft > https://datatracker.ietf.org/doc/html/draft-jouqui-netmod-yang-full-in > clude- > 02. > > > I do have some questions regarding what happens if the embedded module > is being augmented. Is the augmentation automatically embedded as > well; does such embedding need to be explicitly stated? Is there a > way to augment an embedded module only within the context of the embedding module? Yes, as per the example in the slides: if you want ietf-interfaces augmented by ietf-ip, you have to embed them both. > On a more general note, it strikes me that there is an increased need > in reusing definitions. In various forms, we see this in your use > cases, in network inventory use cases, in schema-mount, in peer-mount. > YANG does not provide good support for that, which is somewhat ironic > in that it does actually support several constructs with reuse and > extensibility in mind, from identities to groupings. Hopefully the > YANG-next effort will go a long ways towards improving definition > reuse to that the need for after-the-fact bandaids can be avoided. Fully agree, the full embed as defined here should be a keyword in YANG-next. Similar constructs exist in protobuf and json-schema for instance. > When it comes to reusing parts of definitions, it seems that a lot of > grief could be avoided if portions that are to be reused would have > been defined as groupings, which could then be used wherever needed. > The problem is that the grouping construct is rarely used, so many > YANG definitions are not available for reuse that otherwise might be. Grouping does not solve everything, you cannot augment a grouping so any augmentation would have to be repeated for each use of the grouping. I recommend reading the intro of RFC8528 YANG Schema Mount for a detailed description of these reuse issues. > As a thought, it might be useful to introduce a construct that will > allow to define a _grouping_ after-the-fact, for later reuse. I.e., > allow groupings to be defined in a way that the new grouping embeds an > existing definition, then simply make use of that grouping. That > would seem perhaps cleanest, able to address many of the use cases and > have the additional advantage that the semantics here will be very clear since part of the exising YANG framework. There is still the augment issue from above, we have it in draft-ietf-opsawg-collected-data-manifest when reusing ietf-yang-push which augments ietf-subscribed-notifications. All these augments have to be rewritten with paths corresponding to the new location of the uses. I think the semantics for Schema Mount as defined in RFC8525 is the key to reuse the full semantics of YANG (i.e. not only groupings but also augmentations, rpcs ...) without having to modify existing modules. What we propose in full embed is just to enable a simplified version of schema mount, for design time. Best, Jean > --- Alex > > > > _______________________________________________ > netmod mailing list -- netmod@ietf.org<mailto:netmod@ietf.org> To unsubscribe send an email to > netmod-leave@ietf.org<mailto:netmod-leave@ietf.org> _______________________________________________ netmod mailing list -- netmod@ietf.org<mailto:netmod@ietf.org> To unsubscribe send an email to netmod-leave@ietf.org<mailto:netmod-leave@ietf.org>
- [netmod] Defining groupings after the fact? draft… Alexander L Clemm
- [netmod] Re: Defining groupings after the fact? d… Jean Quilbeuf
- [netmod] Re: Defining groupings after the fact? d… Robert Peschi (Nokia)
- [netmod] Re: Defining groupings after the fact? d… Alexander L Clemm
- [netmod] Re: Defining groupings after the fact? d… William Lupton
- [netmod] Re: Defining groupings after the fact? d… Alexander L Clemm
- [netmod] Re: Defining groupings after the fact? d… Shiya Ashraf (Nokia)
- [netmod] Re: Defining groupings after the fact? d… Alexander L Clemm
- [netmod] Re: Defining groupings after the fact? d… Kent Watsen
- [netmod] Re: Defining groupings after the fact? d… Shiya Ashraf (Nokia)
- [netmod] Re: Defining groupings after the fact? d… Kent Watsen
- [netmod] Re: Defining groupings after the fact? d… Rob Wilton (rwilton)
- [netmod] Re: Defining groupings after the fact? d… Andy Bierman