> On Sep 17, 2016, at 4:08 PM, Ted Lemon <mel...@fugue.com> wrote: > > 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.
Seriously? I don’t see any solution being described here. Plus, this is an abstract, not the meat of the document. > 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. On October 8th, 2016, the chairs asked the design team to work on a 6761 problem statement, Here is the text from Susanne: ""Efforts by the IETF to administer the Special Use Names registry under the provisions of RFC 6761 have proven to be controversial, consume large amounts of time and attention, and lead to outcomes that are confusing, unsatisfying, or both to operators and implementers. As a first stage towards implementing the guidance of the IESG on this subject (http://www.ietf.org/blog/2015/09/onion/ <http://www.ietf.org/blog/2015/09/onion/>, and IESG comments during the discussion of the draft at http://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/ballot/ <http://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/ballot/>), the DT is asked to produce a brief internet-draft for Yokohama, outlining the issues. It's expected to be structured as a problem statement to the extent practical, as we've come to the preliminary conclusion that one of the challenges in applying RFC 6761 is that it's unclear on what problem it's intended to solve and what criteria to consider.” It is pretty clear to me that the problem statement was to be limited to RFC6761, which we executed on. You are perfectly free to believe we were wrong in our understanding of the chair’s directions, or that, the chairs were wrong in their direction. The working group now need to decide if they’d rather like a limited and concise description of issues surrounding 6761 or if they rather like a discussion of the larger issues surrounding special names in general. Now, I will pause and give space to other working group participants to express their opinion. Alain.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
