Thanks very much for your review. > From: "to...@strayalpha.com" <to...@strayalpha.com> > Some comments: > > The doc starts by grouping ICMP-based path MTU discovery (PMTUD) with in-band > discovery (PLPMTUD), but asserts (in the > first paragraph) that the group term “path MTU discovery” isn’t deployed due > to security concerns. I have seen no such > concerns about PLPMTUD - if you are aware of them, they should be cited. More > broadly, however, these two mechanisms > should NOT be lumped together.
I will remove "Path MTU discovery remains widely undeployed due to security issues" from abstract. > IP fragmentation is controlled at both the system (as a default for all new > sockets) and per-socket level; this should > be discussed. > > I disagree with “MAY probe to find path MTU”; IMO, they SHOULD. I will consider changing to "SHOULD" at recommendations to UDP requestors (DNS clients). For UDP responders (DNS servers), I would like to remain "MAY". > Appendix C implies that there is a way to know the path MTU by direct > request. Unless this is verified with probes (as > in PLPMTUD), any value returned is at best a hint and could be incorrect. > This should be noted. > > It wouldn’t hurt (IMO) to point out the potential to use higher level > fragmentation that avoids the issues with IP > fragmentation. I’m not a DNS wonk but I’m surprised to see this doc imply > that there isn’t such a mechanism at the > application layer. Additionally, we are working on a mechanism at the UDP > layer (UDP options) that may be useful in > the future (not to recommend now, of course). I will consider removing Appenxding C. (and aosl D). -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
