[Nml-wg] Schema changes

[Victor Reijs]

Hello Freek,

Was not at the meeting, but we plan to read very soon the document John 
V. sent (viewing from Stitching framework). And if necessary provide 
feedback.

Freek Dijkstra wrote:
 > - Freek: Port is unidirectional (not bidirectional. This suggestion is
 > based on experience with multicast, and complex adaptation stacks, which
 > were harder to describe using bidirectional Ports. Suggested by Guy)

Fully support that.

 > - Martin: Add time-based information. Each network object can point to
 > _multiple_ time intervals (with start time and end time). The meaning is
 > that if "the network object is available" during these time interval(s).
 > It was shortly discussed that time intervals can be used for both
 > inventory management as well as reservation data, though it is not yet
 > entirely clear if this can be described with the same type of relation
 > from network object to time interval.

Can understand this point. And it has some relation with the points I 
have (due to work in the Stitching Framework: 
http://www.geant2.net/upload/pdf/GN2-07-066v5-DJ3-5-3-Report_on_Testing_of_Technology_Stitching.pdf 
).

The below points have perhaps a lower level relation with the present 
work status in NML, but I still want to mention it.

The Stitching framework will be able to work with any definition 
language (like XML) as long as it has the concept that an object not 
only has properties like Name (e.g. 'Speed of interface') and Value 
(like "1 Gbit/s or 10 Gbit/s"), but that other semantic related 
properties can be attached to an object (like "What can adjust the 
Value?": For intance what can change the speed of an interface"; e.g. 
human, ethernet protocol, etc.).

In the stitching framework the Name of an object (which is also a 
property) does not have to be defined by the way. This make the 
framework open to new technologies (where standards are not yet set;in 
case of research/testing). The framework just looks for objects that 
have the same name in Peering domains and then using the other semantic 
properties determines if they can be stitched/connected and how.

That aspect of additional semantic properties is the most important part 
of the Stitching Framework and should be part of the semantics of a 
description language. This part is quite often missed the semantics in a 
network description languages, correct?

In the Stitching Framework has a few semantic properties for an object 
defined (section 2.3: who can change it, what are dependencies on other 
instantiations of objects, how a value changes in a domain, etc.). But 
in the future objects might need other properties, so flexibility is 
important.

Beside this concept of semantic properties for an object; the concept of 
abstraction is essential. So there should be a way how to abstract the 
intricate insides of a network into something that people want to export 
to others. Abstracting is important if one wants to allow people to hide 
certain things. This is analogous to for instance the reason of the 
existence of BGP.
Abstracting can be done outside the semantics of a description language 
or the Stitching Framework of course.

I don't know if the above helps, but the most important attributes of 
the languages are for me (related to your work) are:
. there are semantic related properties
. and the name of object does have to be known (allowing for 
extendibility and non-standard situations; like research/testing).


All the best,

Victor
-- 
Victor Reijs, Network Development Manager
HEAnet Limited, Ireland's Education and Research Network
1st Floor, 5 George's Dock, IFSC, Dublin 1
Registered in Ireland, no 275301
tel: +353-1-660 9040  fax: +353-1-660 3666
web: http://www.heanet.ie/