At Fri, 18 Jan 2019 18:55:16 +0100, Benno Overeinder <be...@nlnetlabs.nl> 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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
