[Nml-wg] URN urn:ogf:network

[Jeff W. Boote]

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.