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

Reply via email to