[Nml-wg] Summary of today (Mon,) discussion
Freek Dijkstra
fdijkstr at science.uva.nl
Wed Feb 27 02:05:36 CST 2008
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
More information about the nml-wg
mailing list