Hi Paul, Murray & Warren, Paul, Sorry, I had missed your update. Thanks for addressing my concerns. I have now cleared.
Murray, I think that this is now with you to check if your concerns have been addressed before Warren can approve. Regards, Rob From: Paul Vixie <p...@redbarn.org> Date: Thursday, 1 February 2024 at 02:56 To: Rob Wilton (rwilton) <rwil...@cisco.com> Cc: draft-ietf-dnsop-avoid-fragmentat...@ietf.org <draft-ietf-dnsop-avoid-fragmentat...@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>, The IESG <i...@ietf.org>, Mahesh Jethanandani <mjethanand...@gmail.com>, dnsop-cha...@ietf.org <dnsop-cha...@ietf.org>, Warren Kumari <war...@kumari.net> Subject: Re: [DNSOP] Robert Wilton's Discuss on draft-ietf-dnsop-avoid-fragmentation-16: (with DISCUSS) 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
