Draft authors, Thanks for putting this draft together.
*Major comments*: In Section 5.1, Transport Layer Solutions, please note that there is work in progress on fragmentation at the UDP layer and cite draft-ietf-tsvwg-udp-options <https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options>. In Section 6.1, DNS, please note that draft-ietf-tsvwg-udp-options <https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options> may offer an *incrementally deployable* solution to the problem of oversize DNS responses. As far as I know, this specific use case is not yet documented in any I-D, but the basic idea is that a client would indicate its willingness to accept a UDP-fragmented response by including in its (unfragmented) request a UDP options trailer with the FRAG option as specified on page-15 <https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-02#page-15> of draft-ietf-tsvwg-udp-options. A server that does not implemented UDP options would ignore the options trailer and use IP-layer fragmentation for large responses; a server that implements UDP options would use UDP-layer fragmentation for large responses. *Minor Comments*: Section 2.2, Upper-layer Protocols, says: Upper-layer protocols can operate in the following modes: o Do not rely on IP fragmentation. o Rely on IP source fragmentation only (i.e., fragmentation at the source node). o Rely on IP source fragmentation and downstream fragmentation (i.e., fragmentation at any node along the path). Upper-layer protocols running over IPv4 can operate in the first and third modes (above). Upper-layer protocols running over IPv6 can operate in the first and second modes (above). The first sentence of the last paragraph above is incorrect. In fact upper layer protocols running over IPv4 can operate in the second mode by instructing the IP layer to do source fragmentation and set the DF bit on outgoing packets. I won't argue if you point out that most APIs don't support this mode, but the fact is that the protocol allows for it. Section 4.4, Security Vulnerabilities: please cite RFC 3828 in addition to RFC 1858 in both places where the latter is cited. I have (belatedly) read the comments on the int-area list and I think that both Joe Touch and Mikael Abrahamsson make some very good points. Again, thanks for putting the draft together. Mike Heard
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
