Hi all- Last week someone noticed that the names of the networks and STPs in the RDF/OWL files did not conform to the URNs described in the NSI CS spec. So in exploring this issue, I believe we have a conflict in the URNs. And since I do not want to distract any further from the development, I am specifying a Rio topology database that avoids the issue completely. We can discuss it in Rio after the demo:-) So to avoid a long discussion prior to Rio, I am circulating a new topology file. This file describes the Rio Ring as before but with the following changes: 1. The "http://glif.is/.../detox#" prefix has been removed from the all Resource names and references. 2. The names are NOT the URN form; they are just the simple strings that identify the object. The issues I found confusing are: - First, the NSI spec defines an STP to have a network identifier and an endpoint identifier of the form: urn:ogf:network:STP:<networkname>:<endpointname> ...an attempt to capture the NSI tuple notion we've been using for NSI. A similar URN exists to specify network names: urn:ogf:network:NSnetwork:<networkname> If we substitute the network URN as the <networkname> in the STP URN we get a rather unusual URN result: Example: urn:ogf:network:STP:urn:ogf:network;NSnetwork:Aruba:Aiden This funky URN is at least one interpretation of the spec. I don't think this is what was intended. The confusion comes from the <networkname> portion of the STP URN - is this *really* a "network" name? ...Or just another namespace qualifier that insures the unique scoping for the <endpointname> component? If it really is a network name, then you get the funky URN. If it is just meant to add additonal namespace scoping, then *any* tag could be used in the <networkname> component - i.e. it does not have to be a network name at all. Which is fine...except that the STP URN would no longer uniquely identify an STP, it would just be a unique endpointname that could belong to *any* network. I believe there is the assumption that the STP URN contains a valid network name that can be used to locate the NSA associated with that STP. IMO, this is a problem in the spec and is pretty fundamental to the protocol. - Second, the NSI CS spec governs what should be in the CS protocol messages, not what should be in a topology database. So we don't strictly need to have the URNs in the topologyDB as there is no topology model or standardized database structure that requires it. Therefore, as long as we know how to map a NSI-CS URN to the name of the desired object in the topoDB, or vice versa- construct a URL from the object name in the topoDB, we should be fine - at least for Rio. - Third, what is "best" for the topologyDB depends a lot on how the various NSAs intend to use or represent that topology. And its not clear to me how the various NSAs are using the STP and NSobject URNs. Example: the endpoint "A1" in network "Aruba". The namedindividual object for the STP A1 is now called just "A1"...not "http://glif.is/working-groups/tech/detox#A1", nor is it called "urn:ogf:network:STP:Aruba:A1" Likewise, the NSnetwork topo object is called "Aruba", not "http://glif.is/working-groups/tech/detox#Aruba", nor is it called "urn:ogf:network:NSnetwork:Aruba" Note: the resource /types/ were not modified. These still use the glif.is/...dtox prefix. (I wasn't sure if changing these would break the RDF) For Rio, I have insured that all objects will have unique short names ala A1, B2, M3, etc. across the global topology. Therefore, you can locate the STPs associated with a Network by: "Aruba hasSTP ?" and vice versa find the NSnetwork associated with an STP by "? hasSTP A1" Again, this is an expediency for Rio and will be an issue we need to discuss for future topo database. I know some will object to this (someone *always* objects)...but this is sufficient for Rio and will allow us to put the focus back on NSI - not the cobbled together hacked up topology database. As always, what we do in the name of Rio should not be considered anything but a temporary/interim approach to be reviewed afterward and done better. Questions? Let me know. Thanks Jerry