September 2012 - nml-wg - lists.ogf.org

References
by Jeroen van der Ham 12 Oct '12

12 Oct '12

Hi, We've been discussing references, meaning things that are not defined locally, but you do want to provide additional information about them. For XML there has been a proposal to use id / idRef to denote something like that. Unfortunately it is not very easy to port that construct to RDF/OWL. The only way to express something like that in RDF/OWL is by using a relation. Fortunately a relation like that already exists in the form of rdfs:isDefinedBy. This states that an object is actually defined by another description, and conveniently provides the URL of that description to reference it. Could we perhaps use the isDefinedBy construct also in XML to make the reference definition somewhat more explicit? This would really help keeping the difference between the two syntaxes at a minimum also. Jeroen.

6 26

atributes of Services
by Freek Dijkstra 05 Oct '12

05 Oct '12

Hi, I'm reviewing the NML document a few times in detail, adding notes what examples are useful. One thing I can't seem to do is distinguish between the Ports that can be configured by an AdaptationService and the Ports are are already configured. The providesPort relation seem to aim the ports that are already configured, akin to providesLink for the SwitchingService. Current situation ================= Here are the current attributes and relations for SwitchingService: - associate with static component: Node|Topology --(hasService)--> SwitchingService - associate (between) which (ports a) link CAN be created: SwitchingService --(hasOutboundPort)--> Port|PortGroup SwitchingService --(hasInboundPort)--> Port|PortGroup - associate which links are already configured: SwitchingService --(providesLink)--> Link|LinkGroup Here are the current attributes and relations for AdaptationService: - associate with static component: Port --(hasService)--> AdaptationService - associate which (client layer) ports CAN be created: AdaptationService --adaptationfunction--> URI (*) N/A - associate which ports are already configured: AdaptationService --(providesPort)--> Port|PortGroup (* The adaptationfunction attribute can be used to determine client layer encoding, but not the available labels) Here are three (3) proposals to rectify this omission and subsequently align the SwitchingService and AdaptationService definitions: Proposal 1: encoding and hasLabelGroup ====================================== For SwitchingService (same as current situation): - associate with static component: Node|Topology --(hasService)--> SwitchingService - associate (between) which (ports a) link CAN be created: SwitchingService --(hasOutboundPort)--> Port|PortGroup SwitchingService --(hasInboundPort)--> Port|PortGroup - associate which links are already configured: SwitchingService --(providesLink)--> Link|LinkGroup For AdaptationService (add attribute and relation): - associate with static component: Port --(hasService)--> AdaptationService - associate which (client layer) ports CAN be created: AdaptationService --encoding--> URI AdaptationService --hasLabelGroup--> LabelGroup - associate which ports are already configured: AdaptationService --(providesPort)--> Port|PortGroup Proposal 2: canProvidePort ========================== For SwitchingService (same as current situation): - associate with static component: Node|Topology --(hasService)--> SwitchingService - associate (between) which (ports a) link CAN be created: SwitchingService --(hasOutboundPort)--> Port|PortGroup SwitchingService --(hasInboundPort)--> Port|PortGroup - associate which links are already configured: SwitchingService --(providesLink)--> Link|LinkGroup For AdaptationService (add canProve): - associate with static component: Port --(hasService)--> AdaptationService - associate which (client layer) ports CAN be created: AdaptationService --canProvidePort--> Port|PortGroup - associate which ports are already configured: AdaptationService --(providesPort)--> Port|PortGroup Proposal 2: canProvidePort ========================== For SwitchingService (same as current situation): - associate with static component: Node|Topology --(hasService)--> SwitchingService - associate (between) which (ports a) link CAN be created: SwitchingService --(hasOutboundPort)--> Port|PortGroup SwitchingService --(hasInboundPort)--> Port|PortGroup - associate which links are already configured: SwitchingService --(providesLink)--> Link|LinkGroup For AdaptationService (add canProvidePort): - associate with static component: Port --(hasService)--> AdaptationService - associate which (client layer) ports CAN be created: AdaptationService --canProvidePort--> Port|PortGroup - associate which ports are already configured: AdaptationService --(providesPort)--> Port|PortGroup Proposal 3: Behave like a SwitchingService ========================================== For SwitchingService (has[In|Out]boundPort is replaced with canConnect[Sink|Source]Port): - associate with static component: Node|Topology --(hasService)--> SwitchingService - associate (between) which (ports a) link CAN be created: SwitchingService --(canConnectSinkPort)--> Port|PortGroup SwitchingService --(canConnectSourcePort)--> Port|PortGroup - associate which links are already configured: SwitchingService --(providesLink)--> Link|LinkGroup For AdaptationService (it now is provided by a Node or Topology): - associate with static component: Node|Topology --(hasService)--> AdaptationService AdaptationService --(hasServerSinkPort)--> Port AdaptationService --(hasServerSourcePort)--> Port - associate which client AND server layer ports CAN be created: AdaptationService --(canConnectClientSinkPort)--> Port|PortGroup AdaptationService --(canConnectClientSourcePort)--> Port|PortGroup - associate which ports are already configured: AdaptationService --(providesClientSinkPort)--> Port|PortGroup AdaptationService --(providesClientSourcePort)--> Port|PortGroup The advantage of the later configuration is that is allows bidirectional adaptations services (no more distinction between AdaptationService and DeAdaptationService). With only minor modifications it is also possible to support inverse multiplexing adaptation. I did not add this, because I'm not a big fan (it adds more complexity, which can be provided with the more simple experimental isParallelCompoundLink relation.) My opinion ========== I would say proposal #2 is cleanest. What do you think? Freek

3 3

urn:ogf:network specification
by Freek Dijkstra 24 Sep '12

24 Sep '12

Dear members of the NML and NSI working groups, A draft specification of the urn:ogf:network namespace is available at https://forge.ogf.org/sf/go/doc16260 Please be aware that this specification is NOT fully backwards compatible with the three existing uses: * GLIF * PerfSONAR * AutoGOLE For details, see section 8 in the document. This draft constitutes discussion with different interested parties over the last few years. We are pleased to place this draft into working group last call. Please leave any comments you may have on list. The plan is to place this document in public last call right after OGF 36. Any comments received before Sun Sep 30 will be taken into account before OGF 36. We like to thank the members of the working groups for their input so far. Regards, Freek Dijkstra Jeroen van der Ham

1 1

XSD for NML
by Roman Łapacz 10 Sep '12

10 Sep '12

Hi, XSD schema is available in the svn repo (https://forge.ogf.org/svn/repos/nml-base/schemas) Any comments are welcome. Roman

2 2

Artifacts going in Last Call
by Freek Dijkstra 06 Sep '12

06 Sep '12

After today's call, I like to move the following artifacts to Last Call: artf6570: NML schema namespace URI artf6575: NML relation in RDF artf6495: Define Label syntax artf6577: layer and label encoding terminology And this one to Reject: artf6573: Make Location a subclass of Network Object artf6577 - Opinions were divided between "label type=..." and "label labeltype=...". Although there seemed a 2:2 standoff, I picked labeltype for no particular reason (Both sides had valid arguments). I mostly just like to move it forward. artf6495 - RDF syntax proposals #2 was picked based on Jeroen's suggestion. I think that concludes this artifact. artf6570 and artf6575 have already been mentioned in an email yesterday. There has been a small change from "nml:hasInboundPort a nml:Relation" to "nml:hasInboundPort rdfs:subPropertyOf nml:Relation" in artf6575. Last, I do like to decide on artf6583 - isReference and idRef shortly, but that will have to wait till Aaron is back from holiday. Regards, Freek

1 0

http://schemas.ogf.org/nml/2012/10/base#
by Freek Dijkstra 05 Sep '12

05 Sep '12

Hi, I like to draw your attention to two artefacts: In https://forge.ogf.org/sf/go/artf6570 and https://forge.ogf.org/sf/go/artf6575. * artf6570 proposes to pick the following URI for NML base schema: For the base schema: http://schemas.ogf.org/nml/2012/10/base# For subordinate schemas: http://schemas.ogf.org/nml/2012/10/ethernet# After publication, we will publish a HTML document at this schema pointing to (a) the GFD standard, (b) the XML schema and (c) the RDF schema. Pointers are -if possible- augmented with computer readable (e.g. RDDL ) pointers. Furthermore, I propose to stick with "2012/10" as the date, so implementations can start using that. Schemas that are published before the NML-base document is ratified MUST contain a large warning "DRAFT SCHEMA", but can use these URIs. * artf6575 proposes to use "http://schemas.ogf.org/nml/2012/10/base#" for Relations (instead of a seperate namespace). It explains how RDF should distinguish between NML relations and non-NML relations using the following triplet: nml:hasInboundPort a nml:Relation . If there are any issues with these two proposals, please reply on-list. Otherwise, I like to move these forward quickly. Freek

1 0

NML conf call Thu Sep 6
by Freek Dijkstra 04 Sep '12

04 Sep '12

Hi all, We have a call today at the usual time and place: Thursday Sep 6 UTC 15:00 - CEST 17:00 - Eastern 11:00 - Pacific 8:00 Call: +1-734-615-7474 (Please use if you do not pay for Long Distance) or +1-866-411-0013 (toll free US/Canada Only) Enter access code: 0186145 Agenda to be announced. Last two weeks we had a short call, despite that no formal announcements have been sent to the list. Roman made some modifications to the base document, and asked others to review them.

1 0