Re: [DNSOP] Robert Wilton's Discuss on draft-ietf-dnsop-avoid-fragmentation-16: (with DISCUSS)

[Paul Vixie <[e-mail]>]

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 <[e-mail]> on behalf of Robert Wilton via 
> Datatracker <[e-mail]>
> *Date: *Tuesday, 2 January 2024 at 15:41
> *To: *The IESG <[e-mail]>
> *Cc: *[e-mail] 
> <[e-mail]>, [e-mail] 
> <[e-mail]>, [e-mail] <[e-mail]>, 
> [e-mail] <[e-mail]>, [e-mail] 
> <[e-mail]>, [e-mail] <[e-mail]>, 
> [e-mail] <[e-mail]>
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
> 


-- 
P Vixie