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
- Inverse queries on EID; autoconfiguration wollman
- Re: Inverse queries on EID; autoconfiguration William Allen Simpson
- Re: Inverse queries on EID; autoconfiguration Paul Francis--formerly Tsuchiya
- Re: Inverse queries on EID; autoconfiguration Bob Smart
- Re: Inverse queries on EID; autoconfiguration wollman
- Re: Inverse queries on EID; autoconfiguration Paul Francis--formerly Tsuchiya
- Re: Inverse queries on EID; autoconfiguration wollman