Alain, here's an example, from the abstract: When an end-user triggers resolution of a name on a system that supports multiple, different protocols or resolution mechanisms, it is desirable that the protocol used is unambiguous, and that requests intended for one protocol are not inadvertently answered using another protocol.
This is a solution described in terms of a problem, not a problem statement. This problem pervades the document. You haven't stepped back and wiped the slate clean and tried to explain the problem that we have--you've just described the problem with 6761. You've retrofitted some of what's described in the tldr document, so that the document as it is now is in a sense more comprehensive, but it's still structured on the basis of the set of assumptions you started with, so that it tends to drive in a particular direction, rather than trying to neutrally describe the problems. If you look at the tldr document, you will see that the set of problems that are stated there imply _contradictory_ solutions. This is because that's the problem we face: there is no easy solution to this problem, and we need to consider the tradeoffs. If I were to read your document without considering the larger problem space, the solution it implies would be very clear. That's not the case for the tldr document. There is no one clear solution implied by the tldr document. That was a deliberate choice. We, as a working group, need to think about the tradeoffs, and not just go in a particular direction.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
