thanks rob for your long service. we'll do as you suggest.
Rob Wilton (rwilton) wrote on 2024-01-29 02:48:
Hi Authors,
Just a note/reminder that I am stepping down as an AD in March. I don’t
think that I’ve seen any reply to my DISCUSS comments (perhaps the
authors and/or WG are still discussing the resolution), but if you are
able to speed this up at all so that I can clear my discuss before I
step down that would be preferable. Actually, if you manage to clear
all the DISCUSSes on this doc before March, so that Warren can approve
it before the new IESG is seated, that would probably make both yours
and Warren’s lives slightly easier at the transition.
Regards,
Rob
*From: *DNSOP <dnsop-boun...@ietf.org> on behalf of Robert Wilton via
Datatracker <nore...@ietf.org>
*Date: *Tuesday, 2 January 2024 at 15:41
*To: *The IESG <i...@ietf.org>
*Cc: *draft-ietf-dnsop-avoid-fragmentat...@ietf.org
<draft-ietf-dnsop-avoid-fragmentat...@ietf.org>, dnsop-cha...@ietf.org
<dnsop-cha...@ietf.org>, dnsop@ietf.org <dnsop@ietf.org>,
be...@nlnetlabs.nl <be...@nlnetlabs.nl>, swo...@pir.org
<swo...@pir.org>, tjw.i...@gmail.com <tjw.i...@gmail.com>,
tjw.i...@gmail.com <tjw.i...@gmail.com>
*Subject: *[DNSOP] Robert Wilton's Discuss on
draft-ietf-dnsop-avoid-fragmentation-16: (with DISCUSS)
Robert Wilton has entered the following ballot position for
draft-ietf-dnsop-avoid-fragmentation-16: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
Hi,
Thanks for this document.
I'm echoing Paul's and the SECDIR review comments here on the use of MAY in
recommendations (since everywhere you see MAY it is equally valid for an
interpretation to treat it as "MAY NOT"), but I think that this makes the
document, as a proposed BCP, unclear enough that I'm raising this to
level of a
DISCUSS.
(1) p 3, sec 3.1. Recommendations for UDP responders
At the time of writing, most DNS server software did not set the DF
bit for IPv4, and many OS kernel constraints make it difficult to set
the DF bit in all cases. Best Current Practice documents should not
specify what is currently impossible, so R2, which is setting the DF
bit, is "MAY" rather than "SHOULD".
I think that this recommendation, particularly because it is using RFC 2119
language, is unclear. I would suggest rephasing this to something like:
R2. Where supported, UDP responders SHOULD set IP "Don't Fragment
flag (DF) bit" [RFC0791] on IPv4.
(2) p 3, sec 3.2. Recommendations for UDP requestors
R6. UDP requestors SHOULD limit the requestor's maximum UDP payload
size to the RECOMMENDED size of 1400 or a smaller size.
I find this recommendation to be unclear because it mixes both a
"SHOULD" and
"RECOMMENDED", i.e., I find it unclear as to what the "SHOULD" applies
to. Is
the recommendation (i) that UDP requestors should limit the maximum UDP
payload. Or (ii) is the recommendation that a limit of 1400 be used, or
(iii)
perhaps both. Maybe rewording this to something like the following
would help:
R6. UDP requestors SHOULD limit the requestor's maximum UDP payload
size to 1400 bytes, but MAY limit the maximum UDP payload size to a
smaller size on small MTU (less than 1500 bytes) networks.
or,
R6. UDP requestors SHOULD limit the requestor's maximum UDP payload
size. It is RECOMMENDED to use a limit of 1400 bytes, but a smaller
limit MAY be used.
(3) p 3, sec 3.2. Recommendations for UDP requestors
R7. UDP requestors MAY drop fragmented DNS/UDP responses without IP
reassembly to avoid cache poisoning attacks.
As written, I don't think that this is really a recommendation. Either
it is a
just a statement or fact (in which case it is not a recommendation), or it
should be upgraded to a SHOULD.
(4) p 4, sec 3.2. Recommendations for UDP requestors
R7. UDP requestors MAY drop fragmented DNS/UDP responses without IP
reassembly to avoid cache poisoning attacks.
R8. DNS responses may be dropped by IP fragmentation. Upon a
timeout, to avoid resolution failures, UDP requestors MAY retry using
TCP or UDP with a smaller EDNS requestor's maximum UDP payload size
per local policy.
Again, I think that this document would be clearer if this was a SHOULD
rather
than a MAY.
Regards,
Rob
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
