Paul - changes to existing practice is a _new_ document. You take the existing, coded, and deployed specification in as an informational RFC. Then you start a new working group document for the full “IETF version.”
We’ve done this for many other protocols over the last several decades. Why the push back? > On Mar 13, 2017, at 4:11 AM, Paul Wouters <p...@nohats.ca> wrote: > > On Sun, 12 Mar 2017, Dave Crocker wrote: > >> On 3/12/2017 4:23 PM, Paul Wouters wrote: >>> I do not want to adopt it unmodified >>> as informational RFC for running existing code. >> >> You do not want the IETF to document existing practice? >> >> Really? > > There is a fine line between "bringing existing things to IETF to > standardize" and "bringing existing things to IETF to document". > > The draft breaks DNSSEC. In its current form it would not have moved > forward if this work had been done from the start at the IETF. We would > have asked the authors to come up with a modified solution that does > not break DNSSEC. So documenting it now after the fact as RFC basically > bypasses the IETF purposefully. > > I have proposed a method that would not change the RPZ response for a > non-DNSSEC client, but would add data for DNSSEC capable clients to be > notified the DNSSEC data was modified (and possibly state why) giving > DNSSEC capable clients a method to act differently, knowing the data was > changed for a reason and is not simply a DNS spoofing attack. It can be > added without breaking existing deployments. If the authors aren't willing > to do this, why should IETF rubberstamp a DNS protocol that breaks DNSSEC? > > Paul > > _______________________________________________ > 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
