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

[Robert Varga <[e-mail]>]

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 
instantiations)

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) :)

Regards,
Robert