I have a lot of sympathy for the worry about boiling the ocean, but actually my fear is that if we do not enumerate all the problems and talk about what we have to give up to solve this one or that one, we will never reach consensus regardless of how small a teakettle we put on to boil, because we will have left out people who have a strong stake in those unaddressed problems, and they will not agree to the document, because despite us not having addressed those problems, nevertheless the resulting document will impact them.
On Tue, Sep 20, 2016 at 3:17 PM, Alain Durand <alain.dur...@icann.org> wrote: > > On Sep 20, 2016, at 7:46 AM, Suzanne Woolf <suzworldw...@gmail.com> wrote: > > The “toxic waste” names are a “use case” in the sense that people keep > asking about. The identified need for a default namespace in the homenet > protocols represents another use case. > > > > There are many use cases for reserving names under 6761 or an updated > version of it. We saw that last year: people have an unlimited imagination > on how to use such special names… good or bad, this is not the question. > > It could be tempting for the problem statement to list all of those use > cases. Actually, if 6761 did not exist, that might even have been the right > thing to do. But this is not where we are now. > > Where we are is that the iETF ran into a number of issues running both the > process and the registry described in RFC6761. Draft-adpkja is attempting > to list those issues, first by looking at process issues (section 3), then > issues related to the operation of the registry (section 4), and, at last, > looking at issues related to the strings under consideration themselves > (section 4). The perspective taken by the authors is that these set of > issues are real. Each of them need to, and can be, addressed. Hence a > problem statement that focuses narrowly on something that can be fixed as > opposed to boiling the ocean listing issues that, if the discussion from > the last 18 months is any guidance, the working group may never reach > consensus on. > > Alain, strictly speaking on my own behalf, not my employer’s. > > > > _______________________________________________ > 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
