Hi Guy, I have a few questions as well. First a remark.
I don't see why the localId needs to be a full URN. The full URN can be easily resolved by looking at both the localId and the NetworkId. Could you please explain this requirement further?
For NML compatibility, where the the Port ID is a single full URI, rather than a NetworkId, localID tuple. (As said earlier, if you like a tuple to quickly identify the Network, you can simply use two URIs -- there are admittedly more elegant solutions, like using DDNS to find the Network ID, but it is more flexible and the complaint that it looks uglier can easily be remedied by hiding the prefix part in a user interface). Now you need to translate between the localID and NML identifier. I am missing that mechanism in your proposal, and recommend to add that part.
"- Why has the definition of an STP changed? Last I heard these would be uni-directional to be able to map to NML Ports, and this would also solve the ERO direction ambiguity." I tried to pitch the STP as a grouping of 2 uni-directional ports, but no one in the working group liked this (except for NML to make their mapping easier), so it was dropped.
I must say I'm actually very disappointed with the current proposal. While I can see the point about the localID above, I just don't see any advantage over the previous proposal with a source Port and destination Port per STP. That proposal had three distinct advantages: * Direction is completely unambiguous * Supports all sorts of connections (bidirectional, unidirectional, point-to-multipoint, multipoint-to-multipoint, with and without ERO) * simple one-to-one mapping with NML (I frankly don't see a way to make this NML compatible) What was the rationale of this decision? Regards, Freek