|
Jeroen van der Ham: 11/30/2012 8:05 AM EST
|
|
Action: |
Update
Closed set to 11/30/2012
Status changed from Last Call to Completed
|
|
Freek Dijkstra: 09/07/2012 3:29 AM EDT
|
|
Action: |
Update
Status changed from Under discussion to Last Call
|
|
|
Jason Zurawski: 08/16/2012 7:40 AM EDT
|
|
Comment: |
Beyond the debate of artf6577, the XML syntax is fine with me. I am not an RDF expert, but I agree with Jeroen's reasoning.
|
|
Action: |
Update
|
|
Jeroen van der Ham: 08/10/2012 4:37 AM EDT
|
|
Comment: |
I dislike the unnamed object approach, because it's messy.
On the one hand I would prefer the 3rd alternative, because it's clean and makes for a simple "label" approach.
On the other hand, I'm afraid that this makes it to easy to just "forget" to add the layerencoding property. Also, it would make it impossible to have
a Port with different layerencodings.
All in all, I think the 2nd alternative is best, it makes it impossible to leave out the encoding.
|
|
Action: |
Update
|
|
Freek Dijkstra: 08/08/2012 8:14 AM EDT
|
|
Action: |
Update
Priority changed from 3 to 1
|
|
Freek Dijkstra: 08/08/2012 8:12 AM EDT
|
|
Comment: |
There seems consensus on the XML syntax, but I came up with a few RDF alternatives. Please post your preferences here.
|
|
Action: |
Update
Status changed from Wait for Other to Under discussion
|
|
|
Freek Dijkstra: 08/07/2012 6:19 PM EDT
|
|
Comment: |
This ought to be decided upon. I'm inclined to put this in last call with proposal #2 as the choice. However, I'm waiting for our choice on artf6577.
|
|
Action: |
Update
Assigned To changed from Freek Dijkstra to none (no value)
Status changed from Need proposal to Wait for Other
|
|
|
|
Freek Dijkstra: 07/11/2012 7:44 AM EDT
|
|
Action: |
Update
Title changed from Define Label concept to Define Label syntax
|
|
Freek Dijkstra: 07/10/2012 8:33 AM EDT
|
|
Comment: |
I have recently distributed some NML example topologies to people outside of the NML developers. This included label definitions like:
<nml:label>
<nml:parameter name="type">http://schemas.ogf.org/nml/2013/10/ethernet/vlan</nml:parameter>;
<nml:parameter name="values">1780-1783</nml:parameter>
</nml:label>
Some of the feedback was that the label syntax was too verbose, and the alternative was akin to the original proposal:
<nml:label labelType="http://schemas.ogf.org/nml/2013/10/ethernet/vlan">1780-1783</nml:label>
This in combination with a recent majority on the NML mailing list who favoured a relative flat syntax for label ranges ("1780-1783" instead of <start
>1780</start><end>1783</end>) has prompted me to see if a more simple alternative is possible. To that end, I posed two complex label definitions, to
see how those can be described:
1. IP does not describe resource labels, but a source + destination label pair. How to describe a label pair with "source IP 145.100.124.38 and
destination IP 193.10.252.66"?
2. WDM channel not only have a (central) frequency (or central wavelength) but also a given frequency bandwidth, the spacing. How to specify the these
(ITU-gridless) wavelengths: "The wavelengths with 193.0, 193.1 and 193.2 central frequency with 100 GHz spacing, and another wavelength at 193.275
central frequency with 50 GHz spacing".
After some thinking, here is a proposal:
1. <nml:label labeltype="http://schemas.ogf.org/nml/2013/10/ip/ipv4"><source>145.100.124.38</source><destination>193.10.252.66</destination></nml:
label>
2. <nml:labelgroup labeltype="http://schemas.ogf.org/nml/2013/10/dwdm/frequency">193.0-193.2±0.05,193.275±0.025</nml:label>
(or the alternative if we don't want a non-ASCII "±" sign, and like to see the spacing rather than half the spacing):
<nml:labelgroup labeltype="http://schemas.ogf.org/nml/2013/10/dwdm/frequency">193.0-193.2~0.1,193.275~0.05</nml:label>
In conclusion, while the above surely needs tuning, I think that the shorter variant can be done, and I don't see why not to take that approach. We
just need to specify per labeltype what the syntax is (but we needed to do that anyway). I recommend to distinguish between nml:label and nml:
labelgroup, now that the type="value"/type="values" is no longer there to distinguish between a label and a label group.
|
|
Action: |
Update
|
|
Freek Dijkstra: 05/09/2012 6:01 PM EDT
|
|
Comment: |
Here is the proposal by Roman Łapacz:
The proposal how the labels could look like is as follows (RNC format):
Label =
element nml:label {
element nml:parameter {
attribute name { "type" } &
text
} &
(
element nml:parameter {
attribute name { text } &
text
} +
) |
anyElement+
} +
### taken from nmc base schema
anyElement = element * {anyThing }
anyAttribute = attribute * { text }
anyThing =
(
anyElement |
anyAttribute |
text
)*
an example:
<nml:label>
<nml:parameter name="type">c-vlan</nml:parameter>
<nml:parameter name="value>42</nml:parameter>
</nml:label>
<nml:label>
<nml:parameter name="type">wavelength</nml:parameter>
<nml:parameter name="unit">nm</nml:parameter>
<nml:parameter name="spacing">25GHz</nml:parameter>
<nml:parameter name="value">1500</nml:parameter>
</nml:label>
By default, other nemaspaces than nml basic one are not needed but I would not forbid them. Use of a set of nml:parameter elements (flat structure)
seems to be enough flexible to cover almost all possible cases but I can imagine a very rare requirement to have a nested structure inside nml:label,
for example:
<nml:label>
<nml:paremeter name="type">xyz</nml:parameter>
<nml-ext:something_1>
<nml-ext:something_2>
...
</nml-ext:something_2>
</nml-ext:something_1>
</nml:label>
(that is why I've added anyElement in the RNC snippet)
If you are 100% sure that such a requirement will not come up I'm fine to remove this extension possibility.
|
|
Action: |
Update
|
|
Freek Dijkstra: 03/29/2012 12:37 PM EDT
|
|
Action: |
Update
Description changed from Define Label and LabelType concepts in uML schemU to Define label and the type of label concepts in UML, and provide examples.
Proposal is: attribute of Link or Port, with type and optional unit value. E.g.
<nml:label type="c-vlan">42</nml:label>
<nml:label type="wavelength" unit="nm">1500</nml:label>
|
|
|
Freek Dijkstra: 03/28/2012 10:42 AM EDT
|
|
Action: |
Update
Status changed from Under discussion to Need proposal
|
|
Jeroen van der Ham: 09/20/2011 9:29 AM EDT
|
|
Action: |
Update
Status changed from New to Work in Progress
|
|
|
Freek Dijkstra: 09/19/2011 10:16 PM EDT
|
|
Comment: |
FYI, a picture of G.800 on Port Forwarding.
How does this map to NML “Port”?
How does this relate to NSI “STP”?
|
|
Attachment: |
g800.png
(30.71 KB)
|
|
Action: |
Update
Added an attachment.
|
|
Freek Dijkstra: 09/19/2011 9:39 PM EDT
|
|
Action: |
Update
Priority changed from 4 to 3
|
|
|