[Nml-wg] Summary of today (Mon,) discussion

[Freek Dijkstra]

Evangelos Chaniotakis wrote:

> There is a slight advantage in not placing Interfaces under Domain 
> (which is in my opinion the only other place you could conceivably 
> put an Interface), and that is a stricter hierarchy that might
> be easier to work with and populate.

Would it be possible to place an Interface both under a device as well 
as under a domain? I guess we may have to do the same for switching 
capabilities: that may be "part of" either a device or a domain.

(This is one of those Really Neat Features of RDF: those relations are 
so loose it is really trivial to allow this.)

But your last point surely stands: a lot of flexibility makes it harder 
to work with a model. I think the flexibility is warranted here, but it 
has drawbacks.

> Subclassing is neat on paper, but in practice turns out to be 
> really awkward and difficult to work with. It's usually better
> to create composite objects, using "has-a" relationships rather 
> than "is-a".
> 
> To continue the example above, a WDMDevice would have-a
> WDMNetworkElement aspect and have-a Device aspect rather than
> *be* both of those things.

Thank you for phrasing it so clearly!

I hadn't thought of it in this way, but it certainly makes sense!
(Chapter 1 of my design patterns book indeed says "has-a is better than 
is-a")


> I think that both services and locations are quite useful and will 
> not detract from the main effort as long as we don't try to do 
> anything too fancy. Though in my opinion it would be best if we
> could reuse other established schemas for these,

That brings us to the natural question: are there already established 
(or not-so-established-yet) schemas out there?

Or should we first establish what we mean with "service"?
I think a good use case for services is the ability to point to other 
information or services required by the control plane. For example, NML 
may describe a topology, and technology restrictions, but there may be 
another service that describes (or negotiates) policies, or current 
reservations/usage. It may useful that these descriptions can refer to 
each other (though I may argue that only other services need to point to 
network elements, not the other way around).

As for locations -- do we want to describe geographic coordinates (wgs84 
= "GPS" coordinates, for network visualization) or organizational 
location (address, facility, room, rack, location - for inventory 
management)? Or both? Or are they the same thing?

Again, are there established descriptions for this? If not, I would 
recommend two separate tables: one for wgs84 coordinates, and one for 
organizational coordinates ("location"), and the ability to say that a 
location is part of/inside another location. Thus location "rack 23E" 
and location "rack 45A" could be part of location "room 2.12". A side- 
advantage is that this would not force a certain hierarchy (one 
organization may describe "facility NetherLight" as part of "room 2.12", 
while another organization may describe "room 314" as part of "facility 
StarLight")


Regards,
Freek