Aaron suggested:
urn:ogf:network:domain=Internet2:node=packrat:port=eth0
Jeroen suggested:
The above examples both include *address* information in the *name*.
The URN syntax defines a relation between port and node (eth0 is in packrat), and between node and domain (packrat is in Internet2).
RDF defines a relation between name and lookup services (#packrat:eth0 can be looked up at http://www.internet2.org/i2.rdf).
Aaron replied:
NDL [mandates] that everything be defined in RDF files and that the identifiers contain pointers to the RDF files where the definitions occur.
We could do the same thing with a topology service URI: http://topology.internet2.edu:8080/perfSONAR_PS/services/topology#packrat:et.... If we did this, we'd be tying any external references (be they pathfinding, measurements, or whatever) to that specific instance of the definition. We'd not be able to move the topology service or split the data between multiple topology services or change the location of the RDF file without breaking external references.
Exactly my point. This name schema forces a relation between the *name* of an object and a lookup service, and if you move the lookup services, you are forced to rename (which is very inconvenient). I have the very same problem with the URN schema which says "urn:ogf:network:domain=Internet2:node=packrat:port=eth0". If I repatch a few devices or replace a broken node, I am forced to rename this identifier (which is very inconvenient). So again, I stress that I really like to see opaque identifiers for names. I dislike UUID as much as every other engineer, and as a human I rather see a more readable name. But as a programmer, and designer, I just don't want that name to have any semantical *meaning*. Now, thankfully there is a slight assertion error in your statement above:
NDL [mandates] that everything be defined in RDF files and that the identifiers contain pointers to the RDF files where the definitions occur.
First of all, NDL does not mandate that. Nowadays, some RDF gurus say that RDF does, but that is not in the original design. I could just as easily write in RDF: <Port id="urn:ogf:network:domain=Internet2:node=packrat:port=eth0"> <lookup-service>http://topology.internet2.edu:8080/perfSONAR_PS/services/topology</lookup-service> </Port>
Basically, this all comes down to (assuming I have this right), do we tie the identifiers to the location of the element's definition or do we tie the identifiers to a logical concept so that the identifiers are independent of the definition's location? And if the answer is both,
My preferred answer is none (don't tie identifier with anything) -- make it all explicit. For example, to make everything really explicit, you'll get: <Port identifier="urn:internet2.edu:UkRGIHN0aWxsIHJ1bGVzIQo"> <name>eth0</name> <lookup-service>http://topology.internet2.edu:8080/perfSONAR_PS/services/topology</lookup-service> <inDevice><ref identifier="urn:internet2.edu:UmVhbGx5IHNvCg"/></inDevice> <inDomain><ref identifier="urn:internet2.edu:a2lkZGluZy4uLgo"/></inDomain> </Port> <Node identifier="urn:internet2.edu:UmVhbGx5IHNvCg"> <name>packrat</name> </Node> <Domain identifier="urn:internet2.edu:a2lkZGluZy4uLgo"> <name>Internet2.edu</name> </Domain> Indeed, this is verbose. But you don't have to give out all information every time. Typically, a protocol should send the lookup service or domain information to a neighbour when it first mentions a port. With that, the neigbour can create its own local lookup table. So it's distributed and flexible. Regards, Freek