[Nml-wg] Naming

[Aaron Brown]

Freek Dijkstra wrote:
>> urn:ogf:network:domain=Internet2:node=packrat:port=eth0
>
> Jeroen suggested:
>
>> http://www.internet2.org/i2.rdf#packrat:eth0
>
> 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).
>
> We should be careful not to enforce users to include all kinds of 
> relationships in a name. I would advocate a transport protocol (or 
> database specification) that not only transmit (defines) names of 
> objects, but also the explicit relations between different objects.
I think I see the issue here. One of the goals of the URN schema was to 
not put the location of the element's definition into the identifier. 
The benefit of this is that it doesn't matter if the identifier's 
defiintion appears in an RDF file, on a topology service or wherever. It 
also doesn't matter if you move the location where the definitions 
occur. You could even switch between RDF and a topology service. NDL 
gets around this by mandating 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:eth0. 
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. Currently, we can just 
email around if a change occurs, but if this does have widespread use, 
the email and update approach will quickly become unwieldy.

To get around this, we would create a lookup service to convert an 
identifier into the location where its definition can be. If the 
identifiers are completely random, globally unique strings, all 
identifiers from all networks would need to be in the lookup service or 
they wouldn't be resolvable (and not just the external ones if clients 
want to lookup measurements for each element in the circuit that they've 
just allocated). To keep every lookup service from having to know every 
identifier, we have the domain portion of our ids. This allows the 
creation of an authoritative lookup service for the given domain 
(similar to DNS). The lookup services would then just have to know which 
lookup service is authoritative for each domain instead of knowing all 
the element identifiers in each domain. When clients wish to lookup the 
definition for a given id, they could consult their local lookup service 
who would redirect them to the authoritative lookup service for that 
domain. That is the only hierarchical mapping that would be required. 
Anything past that could be a uuid (i.e. domain identifier:uuid). Our 
URN structure does define a hierarchy below the domain that people can 
use so that identifier could make sense to outside parties, but doing so 
is not mandated at all.

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, 
we'll need to somehow encode this difference in the identifier scheme. 
Even in the case where we include the location directly, we'll need to 
differentiate between the various identifiers we might have (e.g. RDF 
identifier, Topology Service identifier, etc). Also, if we use the 
logical concept method, what approach should be used? domain? something 
else?

Cheers,
Aaron