Re: Inverse queries on EID; autoconfiguration

Bob Smart <smart@mel.dit.csiro.au> Tue, 03 August 1993 20:42 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12660; 3 Aug 93 16:42 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12656; 3 Aug 93 16:42 EDT
Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa16753; 3 Aug 93 16:42 EDT
Received: by thumper.bellcore.com (4.1/4.7) id <AA23194> for ietf-archive@nri.reston.va.us; Tue, 3 Aug 93 16:41:17 EDT
Received: from shark.mel.dit.csiro.au by thumper.bellcore.com (4.1/4.7) id <AA23013> for /usr/lib/sendmail -oi -fowner-pip X-pip; Tue, 3 Aug 93 16:39:51 EDT
Received: from squid.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA03464 (5.65c/IDA-1.4.4/DIT-1.3); Wed, 4 Aug 1993 06:40:04 +1000
Received: by squid.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA01133; Wed, 4 Aug 93 06:39:46 EST
Message-Id: <9308032039.AA01133@squid.mel.dit.CSIRO.AU>
To: Paul Francis--formerly Tsuchiya <francis@thumper.bellcore.com>
Cc: pip@thumper.bellcore.com, wollman@uvm-gen.emba.uvm.edu, smart@mel.dit.csiro.au
Subject: Re: Inverse queries on EID; autoconfiguration
In-Reply-To: Your message of "Tue, 03 Aug 93 12:31:48 EDT." <9308031631.AA18812@latour.bellcore.com>
Date: Wed, 04 Aug 1993 06:39:46 +1000
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Bob Smart <smart@mel.dit.csiro.au>

>Clearly a "flat" ID can't be used as effeciently as a hierarchical one
>for inverse lookups.  My hope is that the Pip address would nearly 
>always be carried around with a pip id and therefore inverse lookups
>could usually be done on pip address.

If you can deduce the id from the address then the id doesn't need to be in
the packet.

An id is meant (as I understand it) to be in 1-1 correspondence with
the set of domain names representing hosts. An id is just like a name.
Names aren't (directly) organizational. For example machines in
the mel.dit.csiro.au domain don't have to be in Melbourne, or in DIT,
or in CSIRO or in Australia. The hierarchy is about structuring and
controlling the namespace, but once a name is allocated it is just a
name. Same with an ID.

It would be really nice if we could get the IDs out of the packets. But
there were uses of FTIFs in the original document which wouldn't easily
lead to working out who the other end is. We could go back to the
original idea that the ID is carried sometimes in packets as an option.
This could be in the form of a "signed document". And if it is only
there ocassionally its length becomes less important and we could use
the domain name as the ID: the less name spaces the better. Oops I 
think I'm repeating myself here so I'll return to hibernating (it's
cold down here).

Bob Smart