Re: [DNSOP] Call for Adoption: draft-song-atr-large-resp

神明達哉 <> Thu, 24 January 2019 19:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 719B8128B01 for <>; Thu, 24 Jan 2019 11:43:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.918
X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jIm88NZRIcTn for <>; Thu, 24 Jan 2019 11:43:53 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 686711313EE for <>; Thu, 24 Jan 2019 11:43:53 -0800 (PST)
Received: by with SMTP id x10so7800749wrs.8 for <>; Thu, 24 Jan 2019 11:43:53 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=S+YfJiGd4hH6sOr5soIkOTKpAg+woqxBGVuVydk3i/k=; b=ZD7oqQtzOTNekHb0zKjJa8DacfdU7f5pGE80To/4fsHO6cYEybqfoGLYB9apdJGdXe /X5AmOUZDA6MJOnGp3DU1wRk/qXXM0iZxnSmRk9whZLeUZJ5mP+7p2oXUwbzo0gEsrtq qaZfcz6QoOLmkZ6E9TS2FYF2BPIykAwNhZck7a6YNBsteG79nnlJuAYJKxv02fpGLAKJ VE7Xu3CXfjo3oY6fCXoQt81C8tNg4u4Cbss+zjHHToVzvfmaDgL1tngRhNNL4WyrL4P6 qnaH8gKXvIPdJnsH5SD9r5Q/4jSTwwxV9Nmv1ruMqmtsGKfcKueJsrWhrIGLSyACfIzf K1/g==
X-Gm-Message-State: AJcUukdB1ZQCcg3IflxA8bywv4FUUhh6oldP1OwT/oFlLIGypNxJ+3so E7/YlA+FM+LABqM5VVEmoNw/F4xnwKdBtWpwyEE=
X-Google-Smtp-Source: ALg8bN6XJzTm73TV7RNvJZ3w54tipNYFqGLTCNf0Z27ZWUX2ncUxapQLwIXx6NhcMxPw0sVVcePWgRrHL2rml31p3PY=
X-Received: by 2002:a5d:4a8e:: with SMTP id o14mr8162201wrq.159.1548359031543; Thu, 24 Jan 2019 11:43:51 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: 神明達哉 <>
Date: Thu, 24 Jan 2019 11:43:39 -0800
Message-ID: <>
To: Benno Overeinder <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary="0000000000000f61510580396ecd"
Archived-At: <>
Subject: Re: [DNSOP] Call for Adoption: draft-song-atr-large-resp
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Jan 2019 19:43:55 -0000

At Fri, 18 Jan 2019 18:55:16 +0100,
Benno Overeinder <> wrote:

> We discussed this work (draft -01) in Montreal, and different opinions
wrt. adoption were expressed.  In the past months, the authors pushed a
draft version -02 that addressed and resolved some of these comments.
> This starts a Call for Adoption for:
> draft-song-atr-large-resp
> The draft is available here:
> Please review this draft to see if you think it is suitable for adoption
by DNSOP, and comments to the list, clearly stating your view.

I've read draft-song-atr-large-resp-02.  I support the adoption of
this doc, or at least of *some work* related to the "large response
drop" problem, by DNSOP.  If adopted I'm willing to review subsequent

I don't have empirical measurement results of my own on this topic,
but my general understanding of the discussion in the IETF is that the
concern (i.e., the bad effects of dropping fragmented large packets)
is seriously taken.  One of the latest efforts in this sense is
draft-ietf-intarea-frag-fragile, which is currently in an intarea WGLC
and talks about DNS implications (btw, those who dismiss
atr-large-resp because the concern is FUD may want to comment on
intarea-frag-fragile too).  The research result cited in
may still be anecdotal and artificial, but it also looks solid and
sufficiently broad to draw attention.  So I don't agree on dismissing
the work "because the problem doesn't exist".

I also don't agree on dismissing the work "because it's specific to
IPv6" (I don't know if it really is, but even if so), given the
commitment by the IETF to IPv6 deployment and related problems.

I see it's still debatable whether the particular proposal of "ATR" is
a good solution to the problem, however.  I admit that's a hack with
some obvious adverse effects such as increasing response traffic, so
if there's a better, cleaner solution, I'm happy to support that one
instead of ATR.  One aspect I like about ATR, however, is that it can
be deployed without changing resolvers.  In that sense I see it as
more promising compared to some other proposed DNS hacks, e.g., (the
ultimate form of) ANAME.

JINMEI, Tatuya