Hello Martin, thank you for your review. > 1) Sec 3.2 says that a DNS server MAY choose to explicitly use MTU > path discovery. The example suggests setting the MTU to the minimum > MTU. But this is the only way, correct? With anything larger, one > must use discovery, no? It's not an example, it's the only case.
Thanks for pointing this out. It is a remnant from some editing work on the section. Took over your suggestion and removed the example part. > 2) The end of Sec 3.2 provides DoT and DoQ as examples of alternative > transports, and implies that they have other means of fragmentation > avoidance. > In the case of QUIC, this is just PLPMTUD!! Just as with TCP, this is > not something the DNS layer needs to worry about if the transport is > competently implemented. But the level of service there is exactly > the same as TCP modulo some security properties -- there is no > additional magic in these protocols. This point was explicitly requested in the WG. I am personally not attached to the text, and would be happy to remove it. The rational behind it is that it makes the document more future-proof, i.e., in case something comes up that is not yet defined today: https://mailarchive.ietf.org/arch/msg/dnsop/QqbHMS02ZSLvLtQ5FI6rkajJS2o/ I sadly cannot think of a good way to phrase this without adding a lot of additional text. I would appreciate a suggestion here on how this could be made more clear. What i can currently think of is: - Remove the whole paragraph (not really in sync with the WG) - Remove the examples - Reword to make sure that the implication does not arise. Sadly, I am not sure how. Would really appreciate a suggestion there. With best regards, Tobias -- My working day may not be your working day. Please do not feel obliged to reply to my email outside of your normal working hours. ----------------------------------------------------------------- Tobias Fiebig, Forschungsgruppe Internet Architecture (INET) Max-Planck-Institut für Informatik, Campus E14, 66123 Saarbrücken E1 4 - Raum 517 mobil: +31 616 80 98 99 _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
