On 28 Sep 2011, at 16:54, Peter Koch wrote:
If you are able and willing to devote some time and energy on a thorough
review of this draft, especially the use of the DNS reverse tree as
a hook for service discovery and its applicability in today's (and,
for that matter, tomorrow's)
Nicholas Weaver wrote:
Note: The following is manually formatted because
because you choose not to use a feature of modern mail
composers?
As for subtlety, what if, the information is cached and stale?
Good point, but there are easy solutions:
You are still missing the subtlety.
a: Do
Your technical comments:
b: These should have a TTL of 0 seconds and/or support a
prepended, cache-busting wildcard.
Loss of synchronization can occur between cached normal data
and uncached identification data. And, as I already mentioned
what is broken may be the caching server.
On 30/09/2011 14:22, Nicholas Weaver wrote:
The Old Fashoned Mail Reader Flame War below: Everyone else just
stop reading now and save your eyeballs.
By all means carry on with the discussion of the identification of
anycast nameserver instances, but Mail Reader Flame Wars are not in
the
Dear all
Based on 1st round WG LC, the authors have received significant advice about
revision and submited a new version accordingly:
http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-05.txt
And we plan to issue a second round WG LC, and cc to DHCWG, DNSEXT, DNSOP
Nicholas Weaver wrote:
Correct. But this is why you need to have queries that check the
caching server AS WELL. The CHAOS queries are useful here, as
are queries for the cached normal data, and queries which infer
glue policy so you can know if/what the cached normal data is being
used.
On Sep 30, 2011, at 5:56 PM, Masataka Ohta wrote:
Nicholas Weaver wrote:
Correct. But this is why you need to have queries that check the
caching server AS WELL. The CHAOS queries are useful here, as
are queries for the cached normal data, and queries which infer
glue policy so you can
