Re: [DNSOP] List conduct
Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Sun, 24 April 2022 13:45 UTC
Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 965B33A1A24
for <dnsop@ietfa.amsl.com>; Sun, 24 Apr 2022 06:45:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001,
RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001,
T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001,
URIBL_DBL_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44])
by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id fidO8EFJILdl for <dnsop@ietfa.amsl.com>;
Sun, 24 Apr 2022 06:45:52 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp
[131.112.32.132])
by ietfa.amsl.com (Postfix) with SMTP id B2F373A1A26
for <dnsop@ietf.org>; Sun, 24 Apr 2022 06:45:49 -0700 (PDT)
Received: (qmail 74204 invoked from network); 24 Apr 2022 13:41:22 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132)
by necom830.hpcl.titech.ac.jp with SMTP; 24 Apr 2022 13:41:22 -0000
Message-ID: <eb153d19-3b6d-eaf6-ae44-4a5902f24cf7@necom830.hpcl.titech.ac.jp>
Date: Sun, 24 Apr 2022 22:45:44 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.1
Content-Language: en-US
To: Paul Vixie <paul@redbarn.org>, dnsop@ietf.org
References: <6818F50A-AF06-4EA5-AD47-2F8BC3CD2A31@pir.org>
<d4e5a968-b41e-d5b3-6576-32d52d93b345@necom830.hpcl.titech.ac.jp>
<4bef1c62-d18d-7379-d627-aa0d3ec6b30d@redbarn.org>
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: <4bef1c62-d18d-7379-d627-aa0d3ec6b30d@redbarn.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/v4M_-LSW3FIO9XOLREDTE7xhAGM>
Subject: Re: [DNSOP] List conduct
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>,
<mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
<mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Apr 2022 13:45:57 -0000
Paul Vixie wrote: > we should make the best case we can for the positions we hope the WG > will adopt, and answer any questions or misunderstandings of those > positions during any subsequent debate. OK. > for example, here is my > statement on the quality and utility of DNSSEC, along with others': > > https://dnssec.net/why-deploy-dnssec That page is dated before diginotar (2011), when almost all, if not all expect me, believed PKI were cryptographically secure. That is, that a false statement of "PKI is cryptographically secure" was a reason acceptable by most why DNSSEC should be deployed. Note that, that page titled as "DNSSEC Advantage: Reasons for deploying DNSSEC" is rather an operational proof that most people did not and still are not interested in DNSSEC, primarily because its operational complexity caused by lack of cryptographic security. > here, you demonstrate a commitment to nonconstructive commentary > ("obviously impossible for poor IPv6 and LISP") As I wrote to Suzanne Woolf; : Recognizing unproductive protocols such as DNSSEC as unproductive : protocols is, though may be to your surprise, productive. nonconstructive commentary on nonconstructive protocols is rather constructive. Moreover, that IPv4 with NAT is better than IPv6 is a constructive statement. Similarly, in my first message of the thread, I wrote: > Constructive thing to do to make DNS secure is to totally abandon > DNSSEC and rely on DNS cookie or something like that. That is, "totally abandon DNSSEC and rely on DNS cookie or something like that." is a constructive proposal. Masataka Ohta
- [DNSOP] List conduct (was: Re: DNSSEC as a Best C… Suzanne Woolf
- Re: [DNSOP] List conduct (was: Re: DNSSEC as a Be… Masataka Ohta
- Re: [DNSOP] List conduct Paul Vixie
- Re: [DNSOP] List conduct Masataka Ohta
- Re: [DNSOP] List conduct (was: Re: DNSSEC as a Be… Warren Kumari
- Re: [DNSOP] List conduct Paul Vixie
- Re: [DNSOP] List conduct Masataka Ohta
- Re: [DNSOP] List conduct (was: Re: DNSSEC as a Be… Masataka Ohta