Hi, Just for clarity— no one is proposing standards track for this document; the intended status has been consistently discussed as “Informational”.
In discussing RPZ, as we’ve seen with other technology in the past, there’s a difference between “the consequences of having a controversial technology in widespread use” and “given a controversial technology in widespread use, the consequences of having an RFC about it.” As an IETF working group, DNSOP has a lot more to say about the latter than the former. In the past, the WG has sometimes taken the position that there’s value in an informational document on a widely-used and interoperable protocol extension, even if the goal isn’t to make it part of the formal standard. RPZ seems to be such a technology, in that it’s widely deployed in the operational internet— an RFC is obviously neither necessary nor sufficient for that. Users of such an informational RFC that’s separate from vendor documentation might include operators who want to deploy the feature responsibly, new implementers who need a reference on how to make new code interoperable, and operators who want to avoid use of a feature or simply understand its impact on their environment. If the question is “Does the existence of an Informational RFC mean the IETF is endorsing or promoting a technology or practice?” the answer is “No." If the question is “Does the existence of an Informational RFC mean people will think the IETF is endorsing or promoting a technology or practice, and are they more likely to use it as a result?” the answer is pretty subjective and tends to be “It depends”— on the technology, on whether the document includes warnings about shortcomings and side effects, and on the forces that got the technology invented and deployed in the first place. Suzanne > On Dec 21, 2016, at 2:14 AM, bert hubert <bert.hub...@powerdns.com> wrote: > > On Tue, Dec 20, 2016 at 10:46:40AM -0800, Paul Hoffman wrote: >>> Unbound is also slated to have support for RPZ. >> Unbound can document it or point to the ISC documentation. > > We might as well stop doing standards all together then. We have something > that works. It interoperates. There is an ecosystem of services around it. > > And what do people say? "Not going to standardize it". > > The thing is, RPZ is not actually something that was slapped together. It > makes sense. Vernon and Paul clearly were on to something when they wrote > it. > > In other words, it is not "documenting a configuration file". It is a great > thing to be able to point to and say this is the standard, this is how we do > things. > > But meanwhile I will now use TCP/IP to send this message, without having to > refer to some old BSD documentation. > > Bert > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
