Re: [DNSOP] 答复: Fwd: I-D Action: draft-song-atr-large-resp-00.txt

Andrew Sullivan <ajs@anvilwalrusden.com> Thu, 21 September 2017 12:52 UTC

Return-Path: <ajs@anvilwalrusden.com>
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 000B613305E for <dnsop@ietfa.amsl.com>; Thu, 21 Sep 2017 05:52:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=kAhWopvZ; dkim=pass (1024-bit key) header.d=yitter.info header.b=URdGGWpH
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 445CXMtNfS44 for <dnsop@ietfa.amsl.com>; Thu, 21 Sep 2017 05:52:46 -0700 (PDT)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FF10132351 for <dnsop@ietf.org>; Thu, 21 Sep 2017 05:52:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 678A8BEDA1 for <dnsop@ietf.org>; Thu, 21 Sep 2017 12:52:45 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1505998365; bh=fRfcQtpfAIfoGeRv8Nr2UQXT48I32pJ0AYJ7w5MNp3c=; h=Date:From:To:Subject:References:In-Reply-To:From; b=kAhWopvZH0/7qEpQpYVNw8BCs+Oa2qmcyk5/gCR0bL7R4T29+FeJD72CCQyfDn9W6 lxrHOFmKVZhUSNZmjUDg10Hs1WIUg5XoJCCgmuykgHO/8nCyRIi6VclrabcuY0E4Ar gC2zXG2a956d2bKVLc5mclwUMqj80XvfkPrBRiN4=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_CIWa6s39WH for <dnsop@ietf.org>; Thu, 21 Sep 2017 12:52:43 +0000 (UTC)
Date: Thu, 21 Sep 2017 08:52:42 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1505998363; bh=fRfcQtpfAIfoGeRv8Nr2UQXT48I32pJ0AYJ7w5MNp3c=; h=Date:From:To:Subject:References:In-Reply-To:From; b=URdGGWpHrmAMyjBQy+F56CE//Vejgbn2M9DYjKYx5w0zIXloN6WftRB2U66wsAdOG 0oF4+PcZ91iFdROX7j57cFF/ERPjJyh2HAO6oCCeZqO0S/4Ba+WgdGz90PHUpOBFZ3 gA2bXz3fxgTIRAJUXMNw+Y1/SqLf8rKnhPhWVSc0=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsop@ietf.org
Message-ID: <20170921125242.73apv3b434zmejzb@mx4.yitter.info>
References: <150509601027.9852.16967877638602485585@ietfa.amsl.com> <CAAObRXJ6wJGCXkbKVkNmQCJ8NccBT63A8-9-LiRVZCFsDicchw@mail.gmail.com> <CACfw2hhaKTyfJfjQ5-_kfqiHX1oX+9P6mUWD06B87y_2ysdztA@mail.gmail.com> <045b01d33288$d3fadad0$7bf09070$@cn> <59C34510.4080705@redbarn.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <59C34510.4080705@redbarn.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/rS_0Dv52adN4DrNWX1tJiXIGzjA>
Subject: Re: [DNSOP] =?utf-8?b?562U5aSNOiBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LXNv?= =?utf-8?q?ng-atr-large-resp-00=2Etxt?=
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 21 Sep 2017 12:52:48 -0000

Hi,

On Wed, Sep 20, 2017 at 09:50:24PM -0700, Paul Vixie wrote:
> 
>  what we have to do is arrange to fragment, using the
> ipv6 extension header, all ipv6 udp, for a period of not less than five
> years. noone who blocks ipv6 extension headers should be able to get
> reliable ipv6 udp services. we have to make this problem felt where it is
> made. we must NOT work around it to insulate the makers of the problem from
> the costs of their actions.

I think that the above suggestion needs to define carefully who "we"
is in each sentence.  Because I am very far from convinced that the
"we" in each case is the same people, and also very far from convinced
that we are going to be able to "make" this happen, given our lack of
protocol police.  Operators have one incentive, which is to make their
customers stop calling; if our plan is to make IPv6 even less reliable
than it has been historically, I think the operators are going to point
us to the nearest short pier and tell us to take a long walk.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com