Hi Paul, On Wed, May 07, 2014 at 03:37:45PM -0700, Paul Vixie wrote:
> keep it civil, please. I think I was being civil. If you're going to quote simplistic bromides from the pages of a comic book as the basis of your argument, you should expect to be teased. > let me show you something wrong with that, then. > > http://www.cisco.com/c/en/us/products/collateral/wireless/5700-series-wireless-lan-controllers/data_sheet_c78-722607.html > > an rfc is seen by sellers and buyers as an unalloyed good. I'm not sure what you think is wrong with that page. It is a product page. It tells you what it implements. You are presumably supposed to be an educated consumer who can make decisions about whether a given feature is one you want. Certainly, I do not believe everything Cisco says, so I'm unlikely to believe them when they say, "Bees' knees, man! Just have some of this RFC!" Is it the case that people often use, "It's an RFC," to be evidence for, "It is good"? Sure. But first, http://tools.ietf.org/html/rfc1796. Second, people who are looking for an excuse not to think do not have to work very hard at it. Moreover, defending against the impulse you're worried about is one of the reasons that nobody can ever get anything published around the IETF, a problem that you have frequently complained about in public. > the current thrust is to move from "ietf should do good engineering" to > "ietf should document anything that has to be interoperable" That is at once a straw person and a false dichotomy. First, some of us are arguing that part of good Internet engineering is in fact to document stuff that we know people are deploying and that needs interoperability. That doesn't seem like such a controversial proposition to me, so I'd be interested to hear why you think it to be false. Second, I don't think anyone is arguing that the IETF should document _anything_ that has to be interoperable -- unless by "has to" you mean something critical enough to the Internet (such as the DNS) that, again, I'd have thought the proposition uncontroversial. > The Domain Name System as originally contemplated and implemented made > the assumption that a Full Service Resolver would either share a host > with, or a LAN with, or a campus with its end-user stub resolvers. I just had a quick look through 1034 and 1035, and I do not think that the text offers very strong evidence for your claim there. There is admittedly the text in section 5.3.1 of 1034, "or can centralize the cache for a whole local network or organization." On the other hand, there is the text in 5.1, "A very important goal of the resolver is to eliminate network delay and name server load from most requests by answering them from its cache of prior results. It follows that caches which are shared by multiple processes, users, machines, etc., are more efficient than non-shared caches." This latter text militates toward broadening the scope of a resolver. Since many of the "wide area full service resolvers" are in fact anycast and therefore topologically close, and therefore able to eliminate "network delay and name server load", it seems to me that the architecture is entirely ambivalent on this topic. So I'd appreciate a citation. Or, you know, a draft, "Wide Area Recursive Service Considered Icky", or something. > that's a terrible example since any internet draft describing a > controversial technique either failed or got an applicability statement. Really? We had a _whole working group_ whose entire output was about NAT and its tricks. We have another one (MIF) that has suggested all manner of hideous hacks in order to figure out which network you're in. And so on. I dearly wish you were right that controversial techniques always fail or get an AS. Anyway, I think I should be embarrassed to have a meta-argument about whether we even ought to work on a draft. Those of us who think edns0-client-subnet ought to be documented can work on it, so that's what I'm off to do. Best regards, A -- Andrew Sullivan [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
