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

[神明達哉 <[e-mail]>]

At Fri, 18 Jan 2019 18:55:16 +0100,
Benno Overeinder <[e-mail]> 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:
> https://datatracker.ietf.org/doc/draft-song-atr-large-resp/
>
> 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
versions.

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
draft-song-atr-large-resp
(https://blog.apnic.net/2017/08/22/dealing-ipv6-fragmentation-dns)
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