[e2e] scheduled name space
Jon.Crowcroft at cl.cam.ac.uk
Fri Apr 16 15:23:56 PDT 2004
nope- this is orthogonal to the name space hieracrchy (or at least can be)
i might impleent a policy based on similar olocation (eg. using bloom filters on the source address space) or on
request similairity (using rabin fingerprints on query keys) or whatever, but the schedule can be different to the
result of the match...
In missive <4080189F.1030101 at isi.edu>, Joe Touch typed:
>>This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
>>Content-Type: text/plain; charset=us-ascii; format=flowed
>>Jon Crowcroft wrote:
>>> so here is an idea for you to kick around, smoke, generally abuse
>>> and send off to war without any socks
>>> name servers typically get massively gamed coz people acn do cool
>>> things with them like rotaries and so on - what if we add one more
>>> tweak to sometihing like the DNS, which i will call
>>> schedulable names
>>> this are names whose attributes dont just have a time to live- they
>>> have a simple rule on how to respond to users requests for them,
>>> and one of the attrbi/value in the responses is the rule
>>> perhaps another thing in the response could be where else might
>>> answer the request later...
>>Can't you already do this, at least if you delegate along the dots? I.e.:
>> - at time T0 (now) assume z.com says that
>> server grape.z.com answers for *.y.z.com
>> and has a TTL through time T1
>> - after time T1, you ask z.com who answers for *.y.z.com,
>> and it says 'apple.z.com'
>>The only difference, if I understand, is that you want to give out "info
>>to use now that expires at time T1" and "info to use after time T1 but
>>before time T2" (the second set has to expire too).
>>> this allows one to schedule name replacement, but distribute the
>>> load over clients/resolvers, and over lower level servers - i.e.
>>> delegate not responsibility for mapping, but for cacheing, but also
>>> for manageing the timeout behaviour...
>>What you're basically achieving is a way to delegate work independent of
>>the DNS depth, since doing so 'by the dots' is already easy (as per
>>above). However, why is this necessary? Is anyone's nameserver THAT
>>I.e., what does it achieve other than avoiding the refresh after time T1?
>>> combined with recursive or iterative lookup, this allows one to do
>>> much cleverer things with who gets to re-look up a name/address
>>> binding when.
>>> as if we dont have enough problems already with DNS:-)
>>Content-Type: application/pgp-signature; name="signature.asc"
>>Content-Description: OpenPGP digital signature
>>Content-Disposition: attachment; filename="signature.asc"
>>-----BEGIN PGP SIGNATURE-----
>>Version: GnuPG v1.2.4 (MingW32)
>>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>-----END PGP SIGNATURE-----
More information about the end2end-interest