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

william manning <chinese.apricot@gmail.com> Sat, 23 September 2017 12:34 UTC

Return-Path: <chinese.apricot@gmail.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 9FE8C13336A for <dnsop@ietfa.amsl.com>; Sat, 23 Sep 2017 05:34:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 HCl1P7s5rrcG for <dnsop@ietfa.amsl.com>; Sat, 23 Sep 2017 05:34:55 -0700 (PDT)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C6EE133352 for <dnsop@ietf.org>; Sat, 23 Sep 2017 05:34:55 -0700 (PDT)
Received: by mail-it0-x22b.google.com with SMTP id o200so3365078itg.0 for <dnsop@ietf.org>; Sat, 23 Sep 2017 05:34:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=svBoSKuEM8/LDOtQVttRubuau9/78Yz6wVSmXmLQx6g=; b=vSTCgf8rH2Zd5dpBKEPtsmkK3Nmx4l+YD2N9dUOyXNFbQNkWmUsmEmy04IOQuiVLI1 UwXIlP7KdaDZ7y76mwG850qkP0OyOt6N3B9wmvLsZfqGK8bjtYgO4QD7Z73vGLDx86o+ ZeANLspieETK2MYphZbwlCF7aYmeY5obg1sbpmqtyKNx17fmB+pnMes0K1x7KEeh78kJ mAdsK4mE9MIydVuCnSgTIkuni6SolxwAo8sll/fBpQK4u29+DRuYgN36tZGJss4LyL74 qM7RSlU6XPOzCGB87XJfgV9GvPssJqLM0r00qjYU8zaaB6Ue2xYDWucpKEK0kSEOdKkK rtNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=svBoSKuEM8/LDOtQVttRubuau9/78Yz6wVSmXmLQx6g=; b=psPRKmnSDJ3pE9p5S0YOO+bxCMGSQ2ZqHYlEvLi3MUYRFLceR6zlx1Dbvi9OS72wIO rROLY/BGDUjhGFsAJCJ0J557MENsX2x1jnwtfJPAjw1DzSS9ID6PmugL98OJ4Gj1tAaD uHHTq13mvTD5zeX+sudkXZh6Aufbgs3h3/iCzxbzkkbtOi7gfhPpbJgHyp0rc4vaCt0y R/7asJvR2DVQkbXTSGo9jxXdkfnsLQyJ51mSAOSKnLNBXDGBEcD6Si4jW5LXo17u5OsG iTwAvbsQdE6cxYBx+6/eNNOp+W6lR9MPXFYTZ8/i+6haGi9HV8cyiJY2AT4AovA2qSHq GqRA==
X-Gm-Message-State: AHPjjUgJNHXMCHwibAJbIXHNEEkbZF1TfSp+fSnD0u0deOnkn8BSCxHk FlVKt1p4lEbo2+yAjf7HBn470nTZ8J6coDbY6h0=
X-Google-Smtp-Source: AOwi7QDv8TCnl5dG0Go/Ax/ENaDVYRDnJtO0QFIXgEuGcSV8gPwXa8q21yNzrAacCMWmvdaIjJyA1S6U9GLaDGM8f1Q=
X-Received: by 10.36.31.200 with SMTP id d191mr10930141itd.81.1506170094674; Sat, 23 Sep 2017 05:34:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.22.2 with HTTP; Sat, 23 Sep 2017 05:34:54 -0700 (PDT)
In-Reply-To: <59C47601.5030804@redbarn.org>
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> <048701d332a8$6f944980$4ebcdc80$@cn> <59C47601.5030804@redbarn.org>
From: william manning <chinese.apricot@gmail.com>
Date: Sat, 23 Sep 2017 05:34:54 -0700
Message-ID: <CACfw2hjAEEKw53O8jL_Dj0uuumqQZ1mYpWPii66K-gnkywbsKQ@mail.gmail.com>
To: Paul Vixie <paul@redbarn.org>
Cc: "Davey Song(宋林健)" <ljsong@biigroup.cn>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="001a11446e8676e6070559da8dc3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/hFeL3rcdjZsQ0RSeI6Zqatrvr1A>
Subject: Re: [DNSOP] 答复: 答复: Fwd: I-D Action: draft-song-atr-large-resp-00.txt
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: Sat, 23 Sep 2017 12:34:58 -0000

You wrote; "we can, if we wish, continue to standardize one protocol, watch
as the world deploys a different one, and still pretent that our effort was
worthwhile. however, this would fit the technical definition of "insanity",
and i urge that we avoid this course of action."

The IETF has been doing this for years, why stop now?   Pragmatically, this
is why Randy Bush refers to the IETF as the IVTF.

On Thu, Sep 21, 2017 at 7:31 PM, Paul Vixie <paul@redbarn.org> wrote:

>
>
> Davey Song(宋林健) wrote:
>
>> Hi Paul,
>>
>> I know you suggest expose the problem and let the trouble maker
>> feeling the pain themselves. But return to the specific issue, from
>> APNIC's measurement the ASes in the path are dropping the fragments,
>> rather than end ASes. From these ASes' view , it's your pain not
>> theirs.
>>
>
> it's a question of first mover advantage. EDNS will never be fully
> deployed, because of the middleboxes built before 1999 who "know" what a
> UDP/53 datagram has to look like, and which disallow ADCOUNT>0 && QR=0.
>
> we can, if we wish, continue to standardize one protocol, watch as the
> world deploys a different one, and still pretent that our effort was
> worthwhile. however, this would fit the technical definition of "insanity",
> and i urge that we avoid this course of action.
>
> In another word, we are facing the fragmented and uncooperative
>> Internet. What should we do ? It is very hard to coordinate all parts
>> and networks. DNS is a field with lots of tussle.
>>
>
> we need a kernel option for various open source operating systems which
> causes all UDP to be fragmented at 512 octets of payload. for ipv4, so that
> we can hard-smash every middlebox which still prevents EDNS from being
> deployed, and for ipv6 also, so that we can hard-smash any middle or edge
> network who won't carry ipv6 extension headers.
>
> and we need to turn this on everywhere. root, gtld, cctld, recursives,
> authoriatives, 8.8.8.8, opendns... Everywhere. with a press release to
> pre-announce the flag day.
>
> if we're not going to stand up for the standards we write, then we should
> admit that nothing except tcp/80 will work, and avoid all else.
>
> --
> P Vixie
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>