[Nml-wg] URN urn:ogf:network
Jeff W. Boote
boote at internet2.edu
Wed Sep 24 15:58:07 CDT 2008
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.
More information about the nml-wg
mailing list