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 rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg