[Nml-wg] Naming

Freek Dijkstra fdijkstr at science.uva.nl
Fri Mar 28 08:30:48 CDT 2008


>> Aaron suggested:
>> 
>>> 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).

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: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.

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://www.ogf.org/pipermail/nml-wg/attachments/20080328/8ba58f02/attachment.bin 


More information about the nml-wg mailing list