> The point is that what I have specified in the architecture document is > what is minimally required to allow a homenet to function given ordinary > ISPs and ordinary users. I think trying to do some of the things on the > above laundry list would be very interesting work; trying to get it to > where end-users can use it without being experts and without being made > vulnerable to scams would be very cool, but is out of scope for this > document. > > Does that make sense?
Sure. I'm just not sure I agree that MPvD shouldn't also be on the "nice to have" list, rather than the "absolutely required" list. Perhaps it would help if you could explain (a) the details of "the CDN problem" (what mechanism is used to determine answers for a given prefix, and what is the failure mode if the wrong address is used?), and (b) how the client is supposed to actually work with this mechanism (seems to me an unmodified client will probably make a mess of things?). As for an "ideal" resolver behaviour, to me that would be full recursive resolution from the root inside the home, replicating all queries across all upstreams and picking the best reply (best being something like "first reply that passes DNSSEC validation"). With an "advanced configuration" option somewhere that allows the user to override arbitrary names/zones as they see fit. -Toke _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
