Hi On Wed, 27 Nov 2013, John MacAuley wrote:
To compare the content of the two, here is an example of an STP from the Netherlight topology:
<sourceStp> <networkId>urn:ogf:network:netherlight.net:2013:topology:a-gole:testbed</networkId> <localId>urn:ogf:network:netherlight.net:2013:port:a-gole:testbed:uva:1</localId> <label type="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">1781</label> </sourceStp>
versus something like this:
urn:ogf:network:netherlight.net:2013:a-gole:testbed:port:uva:1?vlan=1781
where "urn:ogf:network:netherlight.net:2013:a-gole:testbed:" is the network portion, and "port:uva:1?vlan=1781" is the local portion.
This wouldn't work with the current NML structure, as you cannot encode network (topology) id and port id in the same urn, unless you restrict the naming somehow.
I must admit I am questioning the value of our complex STP definition. I understand the value of the being able to route on networkId, and the issue with URN opaqueness, but if we are constructing the URN following a specific set of rules, could we also not parse it similarly?
So, I can argue for both things here, and we have discussed this issue at least once before AFAIK. However, as I see it, this does not change anything fundemental in the protocol. So I don't really see a reason for it, as the current moment. I'd much rather try and get this thing out the door. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet