Andrew Sullivan wrote: > Dear Uncle Ben,
keep it civil, please. > On Wed, May 07, 2014 at 07:26:51PM +0200, P Vixie wrote: >> The architectural context of a feature should not be divorced from its >> specification. RFC is an imprimatur. With great power comes great >> responsibility. >> > > I disagree with this point of view. I see nothing at all wrong with > one thing that states clearly and precisely how a feature works, and > another one that says, "Here is the wider environment in which > such-and-thus thing works." 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. we can (and i do) criticize uneducated people making appeals to authority, but that's a far cry from pretending it won't happen or that any undesirable result from its happening is not the responsibility of those who write and edit and approve RFC documents. the current thrust is to move from "ietf should do good engineering" to "ietf should document anything that has to be interoperable", and in that move we have to plan on being quite detailed in our "applicability statement" sections. my draft for that section of a client subnet option goes more or less like this: << APPLICABILITY STATEMENT The method described in this document is controversial, as is the use of wide area anycasting for Full Service Resolvers (recursive DNS servers). 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. In that scenario, the need for something like the client subnet option does not arise. Since at the time of this writing, personal electronics are far more complex and resource intense than a Full Service Resolver, even when including DNSSEC validation and DNS "firewall" policy. The purpose of this document is to describe the client subnet option so that cooperating systems can interoperate. No recommendation is expressed or should be implied as to whether this method should be used, or that its antecedent, wide area anycasted Full Service Resolvers (recursive DNS servers) should be used. >> if i thought i could get consensus on an addition, i'd add: << The client subnet option is only useful when other earlier assumptions about Internet architecture are violated. Specifically, it's when a market driven CDN (content delivery system) desires to "tune" DNS authority responses to control end-user web performance, is reached by an end user who uses a market driven anycast recursive DNS service. Neither the described authority DNS tuning nor the described anycasted recursive DNS service are Internet architecture requirements, or even recommendations. A web site without a CDN front end will still work, as will a CDN who has no insight into each requestor's actual address at the time it receives an authority DNS request. End users who use local recursive name servers will receive faster service per query due to the reduced round trip time (one millisecond instead of a dozen or more milliseconds) and will be less affected by "cloud outages". Design by "market force" can lead to unnecessary features and not always to "good engineering". >> obviously i'm miffed that Stupid DNS Tricks ultimately demands more complexity for the DNS, and so on. > Even the DNS protocol itself has this > separation of duties, between 1034 and 1035 (though heaven knows the > actual protocol specification could use some attention). that's a terrible example since neither one of them talks about the limited applicability of the other. > If this were not the case, then in fact we'd have had to discuss the > entire architectural context of any DNS feature. It only seems like > the DNS RFCs are infinitely long. that's a terrible example since any internet draft describing a controversial technique either failed or got an applicability statement. if you think there are cases where RFC 2136 should not be used, over and above the IAB-demanded statement about authentication, speak on. vixie
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
