Hi Mike,
Thanks for your review. Responses inline…..
Ron
From: C. M. Heard <he...@pobox.com>
Sent: Saturday, March 17, 2018 5:40 PM
To: draft-intarea-frag authors <draft-bonica-intarea-frag-frag...@ietf.org>
Cc: int-area <int-area@ietf.org>
Subject: draft-bonica-intarea-frag-fragile-01
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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtsvwg-2Dudp-2Doptions&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=J_pOJLHC_gbCzzfyeW8omX8B8j4T6I07igUCmsA7vPg&s=l9Z0Kh7PKrF4seGUMRn2kViHzJspMRaoNPTKtZ62uIs&e=>.
RB> Agree. Added in next revision.
In Section 6.1, DNS, please note that
draft-ietf-tsvwg-udp-options<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtsvwg-2Dudp-2Doptions&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=J_pOJLHC_gbCzzfyeW8omX8B8j4T6I07igUCmsA7vPg&s=l9Z0Kh7PKrF4seGUMRn2kViHzJspMRaoNPTKtZ62uIs&e=>
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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtsvwg-2Dudp-2Doptions-2D02-23page-2D15&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=J_pOJLHC_gbCzzfyeW8omX8B8j4T6I07igUCmsA7vPg&s=VyqM-WCNZiwxsDRAU9buCv7rxPTo9FyDxsWRLlwh_T8&e=>
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.
RB> While I agree, such a recommendation might be overstepping my charter.
Isn’t that a decision for another WG?
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.
RB> Agree. Fixed in next version.
Section 4.4, Security Vulnerabilities: please cite RFC 3828 in addition to RFC
1858 in both places where the latter is cited.
RB> Are you sure that you want me to reference 3828 (UDP lite)? I don’t see the
connection.
Ron
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
