Naming convention changes

[a-thieme]

On emails, the CAs will give an option for the /<ca-prefix>/<raw email> name. For example, the email user@sub.domain.tld for a CA with prefix /ndn/ca-prefix will be given the option to request the name /ndn/ca-prefix/user@sub.domain.tld.

As a side note, the @ will convert into %40 in the encoding, so it's a bit less human readable/typable.

Sites now have the name /ndn/<DNS name>

[Pesa]

Sites now have the name /ndn/<DNS name>

Why?

[a-thieme]

Sites now have the name /ndn/<DNS name>

Why?

We don't want to have a separate namespace from DNS, so this is a step in that direction. We also have code for ndncert (which we'll merge once it's finished) that can use x509 certs as proof of name possession (DNS names in this case).

[Pesa]

Understood. Yeah, we've been talking about that (not having a separate namespace) for quite some time. Still, I don't see how (to make an example) /ndn/hobo.cs.arizona.edu is a step in that direction. Domains are hierarchical, so isn't /edu/arizona/cs/hobo the eventual goal? Why are we flattening the domain?

[pulsejet]

It's a bit confusing what's the right thing to do here is. The name hierarchy should reflect some administrative / ownership hierarchy. DNS covers some aspects of this but not necessarily. For example, /edu/arizona/cs/... puts this namespace under /edu but that reflects no real-world hierarchy (whoever runs .edu should have no control over Arizona). Maybe a better example is google.co.uk - in this case the top level administrative domain is two components down.

IMO a better naming scheme might be something like /arizona.edu/cs/hobo which accurately reflects the ownership hierarchy.

There are some engineering decisions to make here. But I feel like flattening name of a site down to a single machine is not the right thing to do. Perhaps we need to more clearly define what a "site" on the testbed is.

[Pesa]

For example, /edu/arizona/cs/... puts this namespace under /edu but that reflects no real-world hierarchy

There definitely is a hierarchy. In your example, Educause manages the .edu TLD on behalf of the US Department of Commerce, and there are specific requirements for entities to obtain a .edu domain.

(whoever runs .edu should have no control over Arizona).

What do you mean by "control"? We're talking about names here, so that's the extent of "control" that is relevant to this discussion IMHO. I'm guessing you're talking about more than that?

[pulsejet]

There definitely is a hierarchy. In your example, Educause manages the .edu TLD on behalf of the US Department of Commerce, and there are specific requirements for entities to obtain a .edu domain.

Yes, that's why edu isn't a good example, .com or .co.uk is more appropriate. E.g. google.com doesn't mean the owner of .com has any control over google, or in other words the only entity in question here is google.com in itself.

What do you mean by "control"? We're talking about names here, so that's the extent of "control" that is relevant to this discussion IMHO. I'm guessing you're talking about more than that?

If the name has a structure, the structure needs to be meaningful, i.e. reflect some real-world semantics. Translating google.com -> /com/google has no real-world semantics, because /com has no meaning. We shouldn't break up names at DNS components just because DNS does it that way.

[Pesa]

I don't see how the latest commits are related to this PR. @a-thieme, I assume you pushed to the wrong branch?

[a-thieme]

I don't see how the latest commits are related to this PR. @a-thieme, I assume you pushed to the wrong branch?

yeah I forgot this branch was connected to a PR. once we have the new NLSR patch merged, I'll clean this up

[a-thieme]

i'll mark it as closed for now, since it doesn't seem like we have progress on it. If a need comes up, we can reopen later.