[e2e] scheduled name space

[Joe Touch]

Jon Crowcroft wrote:

> 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...

Sure - it's OK if you give different replies to different sources, but 
the answers have to provide (ultimately) consistent content, or you're 
changing what a DNS query means.

Otherwise, it may be a lookup service, but it's not DNS, IMO ;-)

Joe

> 
> In missive <4080189F.1030101 at isi.edu>, Joe Touch typed:
> 
>  >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
>  >>--------------enig0819A8E9CAED1DF6A3A1827C
>  >>Content-Type: text/plain; charset=us-ascii; format=flowed
>  >>Content-Transfer-Encoding: 7bit
>  >>
>  >>
>  >>
>  >>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...
>  >>
>  >>Hi, Jon,
>  >>
>  >>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 
>  >>overloaded?
>  >>
>  >>I.e., what does it achieve other than avoiding the refresh after time T1?
>  >>
>  >>Joe
>  >>
>  >>> 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:-)
>  >>> 
>  >>> j.
>  >>
>  >>--------------enig0819A8E9CAED1DF6A3A1827C
>  >>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
>  >>
>  >>iD8DBQFAgBifE5f5cImnZrsRAgdWAJ9w6VeGZO0+xSBEgyPJ+YN3wmKe2gCeK9vj
>  >>0LSgFH1Ygnz9V5tc20VTi0A=
>  >>=QyLl
>  >>-----END PGP SIGNATURE-----
>  >>
>  >>--------------enig0819A8E9CAED1DF6A3A1827C--
> 
>  cheers
> 
>    jon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20040416/1c46e748/signature.bin