Hi Xiaohu,

> Yes, the ILNP DNS SHOULD have worked as what you said. However, it can't do
> that since there is no direct association between I record and L record,
> instead, both I record and L record are only associated with a FQDN.

Agreed, this is a bug, however there is a trivial fix.  Note that this isn't
architectural, it's simply a mechanism change.

Note that Ran still needs to confirm this bug.

What's needed is a mapping from FQDN -> (I, {L}) and FQDN -> (I, {LP}).
These are actually combined, but writing FQDN -> { (I, {L | LP } ) } seems
like a bit much to parse.  ;-)

Implementing this is not hard.  Let me propose a fix:

An IL record that provides a FQDN -> (I, L) mapping and an ILP record that
provides a FQDN -> (I, LP) mapping.   Thus, the records would look something

Www.google.com  IL  iiiiiiii iiiiiiii llllllll llllllll


Www.google.com ILP  iiiiiiii iiiiiiii myfavorite.subnet.com

Note that in the latter case, L records as proposed are still useful.

Ran is welcome to adopt this fix (or not ;-).

> By the way, IMHO, maintaining the FQDN->ID mappings and ID->Locator mappings
> in two separate tables respectively is a better choice from the database
> design (e.g., table structure and the relationship between tables)
> perspective.

Except that identifiers aren't globally unique, so that doesn't work.


rrg mailing list

Reply via email to