Re: [DNSOP] moving forward on special use names

Alain Durand <> Sun, 18 September 2016 00:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98D6112B093 for <>; Sat, 17 Sep 2016 17:30:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.616
X-Spam-Status: No, score=-4.616 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N0EkOOloE_xO for <>; Sat, 17 Sep 2016 17:30:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D5CA5127071 for <>; Sat, 17 Sep 2016 17:30:21 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 17 Sep 2016 17:30:19 -0700
Received: from ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.1178.000; Sat, 17 Sep 2016 17:30:19 -0700
From: Alain Durand <>
To: Ted Lemon <>
Thread-Topic: [DNSOP] moving forward on special use names
Date: Sun, 18 Sep 2016 00:30:17 +0000
Message-ID: <>
References: <20160917001036.71292.qmail@ary.lan> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_42CF65A8-A038-4881-876C-A3B8AB990836"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, John Levine <>, Ralph Droms <>
Subject: Re: [DNSOP] moving forward on special use names
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 18 Sep 2016 00:30:24 -0000

> On Sep 17, 2016, at 4:08 PM, Ted Lemon <> 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 ( <>, and IESG comments during the discussion of the draft at <>), 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.