On Sep 29, 2011, at 7:40 AM, Masataka Ohta wrote: >> >> And we're already seeing today, and expect more in the future, >> systems where the front-line support instructions include >> "run a one-click or two-click tool", rather than "run dig". > > It means those who can use "run a one-click or two-click tool" > have no idea on how to bypass intermediate entities, which > means call center operators as a firewall is definitely > necessary.
I think you're missing something subtle here, both in this comment and in the "Do it in IP layer" comment. Well constructed tools like Netalyzr are able to infer properties about paths that they don't have direct access to, based on how traffic is passed through them: making sure that the traffic will reveal desired information. This proposal allows debuging information about the "recursive resolver TO anycast authority" path, a path which the user AND anycast operator do not otherwise have direct access to. Only the recursive resolver operator has access to that path, and for much debugging, the recursive resolver OPERATOR is not a participant in the process. And the end user running the tool, combined with the tech support person on the other end who sees the results, CAN often bypass the broken intermediate entitites, depending on what the results are that the tool spits out: a: If its their NAT or local CPE being very lame: blocking requests AND with a bad proxy, tell the user to replace it. b: If the CPE is giving its own lame proxy but can be bypassed, instruct the user how to use Google Public DNS: problem solved for the user without needing a forklift upgrade. c: If the recursive resolver itself is being lame (eg, how Earthlink's was the other day), either instruct the user how to bypass it, OR start applying various pressures to the resolver operator to get it fixed ASAP. d: If its a path problem between the recursive resolver and the authority, tech support escalates it internally. a, b, and c you can get today with some care (we don't package it up in Netalyzr, but we can distinguish between the three cases in the data), but D is hard, and this requires tools such as the proposal. > PS > > Before developing tools, you should better learn to wrap > your lines well below 72 characters. That your mail reader can't word wrap properly on received messages is not my problem. Word wrapping MUST be done on the recipient side, not on the sender side, unless you want to maintain ridiculous conventions like "text lines are at most 72 characters, monospaced" which were obsolete two decades ago. And in this case particular case, blame Microsoft. Apple on their mailer for the longest time implemented a standard method, format=flowed, intended to please BOTH mail readers that can word-wrap and mail readers that can't. But they dropped this way back in 10.6.2, because Microsoft never recognized it right. Given the choice between pleasing a few recipients who cling to an obsolete convention with obsolete tools and pleasing the very large population of recipients with a tool unwilling to accept a standard which could please both, Apple went with the natural choice: it is the mail reader's responsibility to word wrap to the reader's own display parameters. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
