RE: NIM requirements/conventions (was Re: Methods in the NIM requ irements)

[Harald Tveit Alvestrand <Harald@Alvestrand.no>]

At 15:43 05.05.2000 -0400, Weiss, Walter wrote:
>My view here is that the model is not describing the system per se. Rather,
>it is describing the interfaces for interacting with (determining the status
>and changing the the operational characteristics of) the system.

to me, this is a system description that just happens to not include a 
description of what cannot be seen through the interfaces.

>If we bias the model strongly towards deployment through APIs, we
>would be inclined to use methods pervasively because programmatic interfaces
>are defined in terms of function calls. If we were to bias the model
>strongly towards repository oriented applications, we would strongly favor
>an attribute model.

Once we need to describe the characteristics of the system when a specific 
implementation strategy is used, that strategy is part of the 
characteristics of the system, not an implementation strategy.

It is (I think) not possible to implement a "pull" model and a "push" model 
of a network function that give a network with exactly the same external 
behaviour, unless that behaviour is very simple.

The typical modelling hierarchy is where

+-----------------------------------------+
| traffic-engineered network              |       "user"
|                                         |<------interface
+-----------------------------------------+

can typically be implemented as both

+-----------------------------------------+
| +------------+ SNMP    +-------------+  |       "user"
| | controller |-------> | routers     |  |<------interface
| +------------+         +-------------+  |
+-----------------------------------------+

and

+-----------------------------------------+
| +------------+  LDAP   +-------------+  |       "user"
| | repository |<------- | routers     |  |<------interface
| +------------+         +-------------+  |
+-----------------------------------------+

but the implementations will probably have characteristics that
are different, and observably so.

I think we need model description methods that fit well with both the
"inner" system and the "outer" system of all 3 drawings above.

>So we have to ask ourselves a question. Do we assume that the protocols (and
>paradigms) will be altered to fit the ideal info model or do we adjust the
>info model to optimize the mappings to the broadest cross-section of
>paradigms and protocols/repositories/programmatic interfaces.

I would posit that the issue is different:
The *world* will not change to accomodate our info model.
The info model needs to be able to describe real systems.
If we can abstract from that modelling exercise changes to the protocols we 
use that will make the world a better place, by making our networks easier 
to operate, those changes will hopefully be made.

But a modelling tool that cannot describe the real world at some level of 
abstraction is not terribly useful.

My opinion.

                         harald



--
Harald Tveit Alvestrand, EDB Maxware, Norway
Harald.Alvestrand@edb.maxware.no