Aaron Brown wrote:
I'm thinking beyond simply path finding. What do we do when a user wants to get the status of all links along the circuit and check what's going on with the routers connecting those links? He's given back a list of identifiers for each link in the path of the form URN "urn:internet2.edu:UkRGIHN0aWxsIHJ1bGVzIQo". Who does he contact to find out where he can get monitoring information about that link let alone the routers?
Of course not. He is given a back a list of identifiers as well as a list of domains and services to contact for more information. Why not put it in the name than, you may ask. Well, for example because now a neighbour can later send an update ("hey, remember port urn:internet2.edu:UkRGIHN0aWxsIHJ1bGVzIQo? I already told you about the the lookup service. That is down now. Use <http....> in the future. And by the way, here is some more details about the bit error rates you requested."). In future years, protocol developers may want to build upon our ideas. Perhaps they figure that it is a good idea that a user first authenticates before it gets detailed information like domain or services. If we put that information in the name itself, they can't use our ideas anymore. On the other hand, if we make the relation explicit, we can handle such changes. Like you, I am also thinking beyond simply path finding. That's why I want to be so flexible.
Do we return the lookup service for each element every time?
Just the first time. Or after authentication. Or indeed, every time (after all, if you put that info in the name itself, you also give that information every time). Here comes the great part: we actually shouldn't define that. I think the goal of the NML-WG is not to dive in protocol and implementation details, like this. All we should do is come up with a good model, or ontology to describe networks. Regards, Freek