From nobody Sat Jun 4 13:57:47 2022 Return-Path: <010001813082732c-b45d92df-5815-481b-a86c-476a3f139d25-000000@amazonses.watsen.net> 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 4F8FFC14CF00 for ; Sat, 4 Jun 2022 13:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 EQBzXrVPIOLh for ; Sat, 4 Jun 2022 13:57:45 -0700 (PDT) Received: from a48-93.smtp-out.amazonses.com (a48-93.smtp-out.amazonses.com [54.240.48.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A64A7C14F75F for ; Sat, 4 Jun 2022 13:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1654376264; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=oOSB1E0V4Qn/lx0ie7u8blhc90lldYwFBXnoKwjgZXc=; b=YkBlL/VEr0hNk+1meqzYKmNGW3KdNTp3u7Uy1febHTbyFVxchXGueqz7KXTInv78 4PWZjhfxQBYZFQXJeQHAcXBQtaWc8+FaNvImw7q6tI6DMEMcWAu8tyH04+/3bw8eMxL BFLzz0gBBLq4kbG4/RIM+PN9W99x+PdcEUfUT0is= From: Kent Watsen Message-ID: <010001813082732c-b45d92df-5815-481b-a86c-476a3f139d25-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C9A6960E-77A1-4D2A-8503-45FE477DCDBA" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) Date: Sat, 4 Jun 2022 20:57:44 +0000 In-Reply-To: <01a1b2f3-acc2-8378-ffea-9670e2d51b12@hq.sk> Cc: =?utf-8?Q?Martin_Bj=C3=B6rklund?= , "netmod@ietf.org" To: Robert Varga References: <01000180a9eb37cb-85b9c576-c1eb-425a-b42c-b3cabe548fbb-000000@email.amazonses.com> <20220518.080543.825575420363032441.id@4668.se> <01000180d793d6ee-f82a4a03-28d8-4f8b-909e-7306a7fc565b-000000@email.amazonses.com> <01a1b2f3-acc2-8378-ffea-9670e2d51b12@hq.sk> X-Mailer: Apple Mail (2.3693.60.0.1.1) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2022.06.04-54.240.48.93 Archived-At: Subject: Re: [netmod] Does defining a feature require the module be implemented? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2022 20:57:46 -0000 --Apple-Mail=_C9A6960E-77A1-4D2A-8503-45FE477DCDBA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Robert, >> 3) I wish more modules would following the pattern of having the = global protocol accessible tree be defined via a "uses" of a grouping = defined in the module. In another recent project, I had to hack the = topology modules defined in RFC 8345 (to convert the containers to = groupings) to enable a multiplicity of "abstract network topologies" to = be configured. The assumption that only a single global instance is = ever needed is proving to be invalid in my work time and again. >=20 > /me puts the co-author hat on. >=20 > The multiplicity is already built-in into the model by the fact that = network topologies is a top-level list. >=20 > Would you mind sharing the use case what requires multiplicity of the = built-in multiplicity? >=20 > I know this sort-of is a re-hash of the ietf-interfaces discussion, = but while there the use-case is well understood, I wonder what = equivalent is there for networks/topologies. I appreciate that the model supports a multiplicity of topologies, and = can see that it could support my needs, but my issue seems to arise in = the intersection of the following desires: 1) a server that supports multi-tenancy 2) each tenant being able to define a number of topologies 3) each tenant only being able to see their own topologies 4) the server not supporting object-level access control 5) the data-model being schema-mount like, whereby each = tenant-instance contains *all* tenant nodes (e.g., all leafrefs are = relative paths that never go above the tenant's subtree. Kent --Apple-Mail=_C9A6960E-77A1-4D2A-8503-45FE477DCDBA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Robert,


3) I wish more modules = would following the pattern of having the global protocol accessible = tree be defined via a "uses" of a grouping defined in the module.   = In another recent project, I had to hack the topology modules defined = in RFC 8345 (to convert the containers to groupings) to enable a = multiplicity of "abstract network topologies" to be configured. =   The assumption that only a single global instance is ever = needed is proving to be invalid in my work time and again.

/me puts the co-author hat on.

The multiplicity is already built-in into the = model by the fact that network topologies is a top-level list.

Would you mind sharing the use case what = requires multiplicity of the built-in multiplicity?

I know this sort-of is a re-hash of the ietf-interfaces = discussion, but while there the use-case is well understood, I wonder = what equivalent is there for networks/topologies.


I appreciate that the = model supports a multiplicity of topologies, and can see that it could = support my needs, but my issue seems to arise in the intersection of the = following desires:

= 1) a server that supports multi-tenancy
2) each = tenant being able to define a number of topologies
= 3) each tenant only being able to see their own = topologies
4) the server not supporting = object-level access control
5) the = data-model being schema-mount like, whereby each tenant-instance = contains *all* tenant nodes (e.g., all leafrefs are relative paths that = never go above the tenant's subtree.

Kent

= --Apple-Mail=_C9A6960E-77A1-4D2A-8503-45FE477DCDBA--