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
like:
Www.google.com IL iiiiiiii iiiiiiii llllllll llllllll
Or
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.
Tony
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
