Re: [netmod] Does defining a feature require the module be implemented?

Robert Varga <> Wed, 08 June 2022 21:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 87CFAC15AACA for <>; Wed, 8 Jun 2022 14:19:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.985
X-Spam-Status: No, score=-3.985 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.876, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vfd7pNVqybDm for <>; Wed, 8 Jun 2022 14:19:42 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 9800BC15AADB for <>; Wed, 8 Jun 2022 14:19:07 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 272B9246D60; Wed, 8 Jun 2022 23:19:03 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1654723143; bh=ZkabtR0PxOrh4ppo1ta1QWkXM0yzFkdfRXpGgAvQkZI=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=QpJWEjLm/BDk1NeFb/hb89g3RfSIE3XSCVBBg6AaTcvm9AkeAEwlbZuso98XE1LsU UzVjuvODxgmAKYhud9szhoLsPxpA7LsX5bhuFlGJ2KU4GgrTGmpA399KWnM1nVDy5S ewlTtmU5EvCg/HelXoJZ/nhjdIgnfUpedLlBCmtI=
Message-ID: <>
Date: Wed, 08 Jun 2022 23:19:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: Kent Watsen <>
Cc: Martin Björklund <>, "" <>
References: <> <> <> <> <>
From: Robert Varga <>
In-Reply-To: <>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------sC39KUryQvM4zGkwm6oPH1wh"
Archived-At: <>
Subject: Re: [netmod] Does defining a feature require the module be implemented?
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: Wed, 08 Jun 2022 21:19:46 -0000

On 04/06/2022 22:57, Kent Watsen wrote:
> 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.

Right, so the problem really is a combination 4) and 5). 4 is dictating 
use of some ACL model where you (warning: conjecture) can filter on a 
global prefix. 5 dictates that prefix is not formed through the use of 
RFC8528 schema mount -- hence you form that via something like

   import ietf-network { prefix nw; }

   list tenants {
     key name;

     uses nw:networks;

Two issues with addressing this issue through remodeling as groupings are:

1. leafrefs cannot use absolute addressing, opening a can of interop worms

2. technology-specific augments no longer have a single target, leading 
to an NxM explosion (N = technologies, M = ietf-network grouping 

The first is an annoyance, the second is a major problem solved 
(semi-reasonably?) through RFC8528...

The thing is: RFC8345 is very much a 'turtles all the way down' modeling 
exercice. Turning 'container networks' into 'grouping networks' still 
leaves you with that gap we call "augments target instantiations, not 
definitions" -- e.g. after introducing those groupings you mentioned you 
then proceeded to duplicate all technology augments to make them work 
with all them instantiations, right?

I really think you should fix your server (to supported at least 4) :)