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

[Evangelos Chaniotakis]

To comment a bit myself on the slides and on Freek's response:

Freek Dijkstra wrote:
> Paola Grosso wrote:
>
>   
>> In essence, we have tried to define the basic classes that go into the 
>> NML-WG schema, and began to define each class in more detail.
>> We will use this as starting point for tomorrow discussion.
>>     
>
> This work was presumably done after the formal meeting?
> My compliments!!!! You seem to have been doing some real substantial work!
>
>
> I have a few random comments (well, not truly random).
>
> slide 2: Why this specific list of NDL basic classes? I personally would 
> not say Service is a basic class, while Layer, AdaptationFunction and 
> AdaptationProperty are.
>   
I will disagree with Freek here, I think that even though  services are not
really the main focus of the effort, we should have at least a rudimentary
service element in there.

> slide 5: I recommend to distinguish between a device (the physical 
> thing) and its (switching) capabilities. That would allow us to describe 
> the (switching) capabilities of a domain without describing all details 
> of each physical device (which IMHO is a scalability nightmare). I like 
> to list that concept here.
>   
I very very much agree with Freek here. See also comments about object 
composition later.

> slide 6: NOT every interface belongs to a node: it may also be useful to 
> describe an interface of a domain, without telling the details of which 
> devices it is connected to.
> (I'll knowingly skip other problems like the description of a port in a 
> patch panel, which may not be considered a device -- for our purpose 
> it's not relevant, although if you want to use this schema for inventory 
> management, it may be important.)
>   
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.


> slide 6: I strongly recommend to put as MUCH information in the generic 
> Interface class as possible, and only rely on subclassing if all else 
> fails. This is important to keep the schema as technology-agnostic as 
> possible.
> Do we really need to subclass Interfaces? Do we really need to subclass 
> Devices? Do we really need to subclass Links? etc. etc. Perhaps the 
> answer is yes to two of these questions, or perhaps to all three. But I 
> like to remind people that in NDL we did NOT have to subclass ANY of the 
> these! Still, we are able to find paths through nearly all technologies, 
> including fiber, WDM, TDM, and VLANs. The only thing I needed subclasses 
> for are for Ethernet MTU size, and for fiber physical properties 
> (cladding of the fiber: multimode/singlemode, etc.).
>
> slide 6: Note that rather than subclassing interfaces, subclassing link, 
> subclassing switch matrices (/devices) all to technology-specific 
> subclasses, I tried to come up with the notion of some sort of mix-in 
> class. E.g. WDMNetworkElement, with a WDMInterface a subclass of both 
> Interface and WDMNetworkElement, and a WDMDevice a subclass of both 
> Device and WDMNetworkElemenet, etc. My experience: while this idea 
> sounded nice, it didn't really work in practice. But again, do we really 
> need all subclasses?
>   
Again, agreeing with Freek here. 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.


> slide 8: what is a node? Is a device a node? Is a domain a node? If a 
> domain can be a node, the second bullet is not true anymore.
>   
I think we're talking about device == node.

> slide 9: I would recommend to the working group not to define services 
> for the time being. That concept is part of the control plane, while I 
> think our focus should be on the data plane for now. That said, by all 
> means do include it if there are good counter arguments to do so. The 
> same argument more or less holds for defining Locations: I'm not opposed 
> to defining them (we did in NDL), but I much rather refer to work of 
> other specialized groups, rather than reinventing the wheel here.
>   
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,

> slide 11: I very much applaud the choice for UML diagrams, with both an 
> RDF and XML schema. The use of UML prevents me from suggesting some 
> Really Neat Features of RDF, but for interoperability it would be a Good 
> Thing if I'm restricted in that sense ;-). That said, I'll gladly battle 
> for the use of opaque URI's as identifiers for all class instances!
>   
Agreed here on the UML adoption, great choice. And let's not do Really Neat
RDF stuff; I think that it will raise the entry barrier quite a bit.