Hi all,

...

Again, for class identifier, I don't have a preference for either URL or URN in some OGF namespace (urn:ogf:network, or http://ogf.org/ns/network , or similar).

I agree with URLs to identify classes. As Aaron said, we'd only been thinking of the URN style as instance identifiers.

...

As for instance identifiers, I have two major objections against "urn:ogf:network:domain=glif.is:3267 [...] So the best choice in my view is to use "glif.is:3267" as an identifier. It is short. It is unique. It is transparent to a program (a unique string). It is easy to query ("WHERE domain STARTS WITH "glif.is:". It is human readable -- in short, it is all an identifier has to be. Why make it more complex?

The real reason to type it is to you can refer to different types. In the GLIF proposal, the thing after the domain (which you didn't include in your example, but which is there if I'm reading it right) is a circuit identifier, and only that. With types, and edge can refer to a distant node using as much information as it has. One side might only know the domain of the other side, or it might know the node and port IDs. That was one of the use cases that motivated the attribute/value style in the URN.

There are reasons for a bulkier, less context-sensitive identifier scheme, but I'm not sure the NML list is the right place to hash this out since the identifier schemes are relevant more for lookup and distribution than basic description. For the sake of NML, i'd prefer to leave it at "identifiers are globally unique strings".

I think that it is in scope for NML. We might end up with more than one way to do it, but I think that leaving it as just a string limits what we can do. best, martin

On Sep 23, 2008, at 6:47 PM, Jeff W. Boote wrote:

First, I'm against coming up with multiple ways to do it, unless the multiple ways are based on completely different uses of the schema that will never interact. (Or unless we absolutely can't agree - which would seem a shame.) Lets not make interoperability any harder than we have to.

You're presuming a lot regarding our ability to agree. If we need to have one way to do it for NDL and GLIF compatibility and one way for perfSONAR and DCN, and there are ways to tell them apart and to translate between them, if necessary, then I don't see the harm. Agreeing on a small set is better than no agreement at all.

Second, I agree that it is in-scope for NML. However, it is just as in-scope for the other groups Aaron mentioned.

At a bare minimum the other groups Aaron mentioned (and probably others) should be invited in on the discussion.

They're been invited to the discussion as far as I know! If they haven't been, then let's invite them! martin

On Sep 24, 2008, at 2:08 AM, Jeroen van der Ham wrote:

Aaron Brown wrote:

...

There are reasons for a bulkier, less context-sensitive identifier scheme, but I'm not sure the NML list is the right place to hash this out since the identifier schemes are relevant more for lookup and distribution than basic description.

What do you mean by distribution in this case?

If this is going to be used in a global context, and not just from a local one - then the information that it 'exists' may need to be propagated to other places. (Consider path finding.)

...

For the sake of NML, i'd prefer to leave it at "identifiers are globally unique strings".

I compeletely agree with that. I've tried to hammer this point down at a GLIF meeting last year as well. I am all for leaving the form of the identifiers up to the people creating them. There are lots and lots of ways to create a globally unique identifier and everybody has their preference. I really don't care what they choose as long as it is *globally unique*.

They become much more useful if everyone is using the same algorithms to produce them.

But, I do have to add one restriction to that clause. The globally unique string should be just an identifier, nothing more. That means no implicit type information, no implicit location information, no implicit source information, nothing. The globally unique string must identify a resource, about which more things can be stated using NML.

Here I disagree 100%. That is like saying that FQDN's should not have any structure or implicit type information etc... If a circuit exists, but no one can find it, is it useful? Obviously you could come up with a central repository of all circuit id's and relate them to location information. But, that has pretty annoying scaling issues. Especially, when we have a fairly clear topological model available for how to distribute this information. jeff

On Sep 24, 2008, at 11:00 AM, Jeroen van der Ham wrote:

Jeff W. Boote wrote:

...

Here I disagree 100%. That is like saying that FQDN's should not have any structure or implicit type information etc...

Ah! So what actually underlies this whole discussion is the issue of naming and addressing. Please, take the time to read: http://ana-3.lcs.mit.edu/~jnc/tech/ien/ien19.txt

Not at all. I think you misunderstand my point. I do not for a moment want to combine names and addresses. That is a useful and needed layer of indirection that I want to make use of. From example #1 in that document - the first step is to look up the name in the phone book. My point is that I don't want a single phone book because that does not scale well and does not allow each 'publisher' the ability to control who they share addresses with. Therefore, the name needs to have enough information to direct you to the correct phone book. This is not about finding the address (yet), it is about finding the correct phone book.

The important point there is:

...

The 'name' of a resource indicates *what* we seek, an 'address' indicates *where* it is, and a 'route' tells us *how to get there*.

But to come back to FQDNs, yes, they do have a very slight amount of implicit information. They contain exactly enough information so that, given a root server, you can resolve the *address* that is associated with that. Using the addres, you can then figure out a route to it, and actually get some useful information.

Now, with FQDNs there is no choice, the lookup information has to be contained within that same term. I argue that in NML there is no need for this. The lookup part, or any other kind of implicit information, can be given using a separate property. The thing is, you are not going to see NML identifiers being handled out of context. Computer programs are going to need the context to make sense of it all.

With FQDNs, the important thing to find out is the authoritative-NS. That is what the structure of the names gives you. Then you can query to find the address. (I ignore recursive queries in this because what is really important is who controls the information, not specifically where the client actually queries.) The kind of structure I'm looking for in the names (circuit identifiers) is the ability to find the correct publisher of the information. The ability to know *where* to look up the address.* We can of course create a global directory (in fact, we are). However, without some structure in the names - you loose the ability to allow specific institutions to more tightly control the flow of information. For example, with no structure in the names you either need a DHT or a single global directory. This means if you want to publicize the name using this structure, you have no control over *where* that information flows to. However, if you add structure to the name. You can say: This name was allocated by entity X and you have to go to the directory that holds the name<->address mappings for entity X. This allows entity X to implement policy controls on queries for that information(name/address). Another possibility here is of course to add *another* layer of indirection. Basically use a DHT to publish the phone book for each identifier. But, that is adding a few too many RTT's and infrastructure for my liking. At the end of the day, this should all be about coming up with the best set of engineering trade-offs. jeff * We will also need to make reverse mapping queries as well: given the full definition of a circuit, come up with the identifier. Because of this, it is likely that some of the same structure that defines the circuit can be useful in defining the identifier. i.e. We will want to point queries at the same phone book for forward queries as reverse ones since the publisher is the same entity. Just because some of the structure looks similar doesn't mean we are not maintaining the distinction between name and address.

On Sep 24, 2008, at 3:45 PM, Jeroen van der Ham wrote:

Jeff W. Boote wrote:

...

...

Jeff W. Boote wrote:

...

Here I disagree 100%. That is like saying that FQDN's should not have any structure or implicit type information etc...

Ah! So what actually underlies this whole discussion is the issue of naming and addressing. Please, take the time to read: http://ana-3.lcs.mit.edu/~jnc/tech/ien/ien19.txt Not at all. I think you misunderstand my point. I do not for a moment want to combine names and addresses. That is a useful and needed layer of indirection that I want to make use of. From example #1 in that document - the first step is to look up the name in the phone book. My point is that I don't want a single

On Sep 24, 2008, at 11:00 AM, Jeroen van der Ham wrote: phone book because that does not scale well and does not allow each 'publisher' the ability to control who they share addresses with. Therefore, the name needs to have enough information to direct you to the correct phone book. This is not about finding the address (yet), it is about finding the correct phone book.

Okay, I agree that finding the correct phone book is the next step once you have an identifier. However, unlike FQDNs, we can give the location of the phonebook along with the identifier that we're sending. There is no necessity to encode that information in the identifier itself.

Note that this also allows you to have two completely different identifiers, each defined by their own domain, yet pointing to the same thing (and they'll probably have an equality relation to each other as well).

This would in effect be adding that additional level of indirection I was trying to avoid. (Where do you find these equality relationships?) I agree this can work. But, I'm curious what functionality are you trying to preserve by 'not' including some structure in the identifier? Just the ability of individual entities to define the identifiers in their own way? Can you tell me why this is important? As I said in the previous message, I think this is about making appropriate engineering trade-offs. For a global distributed directory, I think performance would be better if locally defined names were mapped to a global name with this 'context' before using it in the distributed system. This method would also preserves local names since you only need to convert to the global identifier when interacting with the 'global' infrastructure. But, I recognize that there may be other constraints on these identifiers in other spaces. So, I ask - what are those *engineering* constraints? jeff

Hi Freek,

If the owner is part of the identifier (as I just suggested in my previous mail; e.g. identifier=glif.is:2678), and there is another mapping from owner (glif.is) to phonebook (e.g. https://idc.internet2.edu/ws/status.cgi), then each domain can only have one phone book.

I think that in both cases (domain + opaque local ID and attribute/value pairs including domain=) the owner is part of the ID. That seems to be necessary to avoid another level of indirection.

In Jeroen's proposal, each identifier is just a string, and there is a direct mapping from identifier to each phone book. So without the intermediate mapping of the identifier to owner to phonebook. The advantage is that a domain can have two phonebooks. E.g. the phonebook for glif.is:2678 may be https://idc.internet2.edu/ws/status.cgi. while the phonebook for glif.is:2679 may be http://glif.is/ws/status.cgi.

Something has to know that information for all of glif,is, right?

So Jeroen's proposal is even more flexible.

I don't agree that untyped, flat identifiers are more flexible. In our scheme, the opaque version could be: domain=glif.is, id=2678 But one could also have domain=glif.is, gole=foo domain=glif.is, node=rembrandt domain=glif, subdomain=something The attributed syntax allows you more flexibility to encode semantic info. martin

On Sep 25, 2008, at 9:14 AM, Freek Dijkstra wrote:

Consider: path identifier glif.is:2678 glif.is:2678 node rembrandt (Two statements)

And: path identifier "domain=glif.is, node=rembrandt"

In the second case, if the node changes (while the path remains), the identifier has to change as well. In the first case, the identifier can remain the same, while a property of the path changes.

Therefor, the first solution is more flexible.

A path doesn't actually have node= in its ID in the current scheme we're using. It would just be domain=X, path=Y and it would not need to change. martin