On Mar 27, 2008, at 11:25 AM, Aaron Brown wrote:
Things had gotten a bit quiet so I figure I should open up a can of worms :-) .
Freek Dijkstra wrote:
In short: name MUST NOT be context-sensitive. I think it is bad if I can only describe an interface as "eth0 of host3 in network 8". I much rather say interface "intf639" and only if required tell that it is in "host3" and that "host3" is in "network8".
Of course, this requires that names are globally unique. I prefer to use opaque names (any string, without syntax requirements), as long as it is unique. URIs come to mind.
If we mandate that *all* naming is completely context independent, then when given a random identifier, users are completely at a loss (since no context implies no domain information) as to where to get information on an element. If the only context it has is "this domain contains [uuid]", our schema can work like that except it adds a bit of extra information on it so you can type-check a given id. For example, if you didn't want any hierarchy below domain, you could just label everything like:
urn:ogf:network:domain=Internet2.edu:node=node1345 urn:ogf:network:domain=Internet2.edu:port=intf639 urn:ogf:network:domain=Internet2.edu:link=link23
My take on this is that all elements should have a meaningless, globally unique identifier with no hierarchical information in it at all. We do need human readable information but that can be pushed to other attributes or be inferred by relationships. An example interface: id = "1311477AD25" "interfaceName" => "TenGigabitEthernet1/1" How do we know which specific device it belongs to? Well, the device is a group so it'd look like: id = "98821CA88" "hostname" => "chic-sdn1.es.net" interfaces: 1311477AD25 .... And the domain is a group too, like: id = "12198DAC" "name" => "ESnet" devices: 98821CA88 .... Etc, etc. If our application needs to find out the "domain:device:interface" URN format for that interface, it can easily do that if it has the information above - and it can also easily resolve to the global identifier if it is given a urn- style "identifier". Advantage: if you are looking at just the Interface object you'll only be able to find stuff in the scope of the object itself, you won't get the network hierarchy or anything like that. This would help us have a nice and clean design with well-defined boundaries between objects. And, as a bonus, it'll make it easier to anonymize topology data; we can just push out ids and relationships rather than hierarchical names, and the mapping to the internal stuff would be trivial if we kept the same object ids. Disadvantage: It'll be a bit more cumbersome to look things up - users won't be able to just look at an id and immediately know stuff about it. But well, we'll have identifier lookup services and tools for that.