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

["Rob Wilton (rwilton)" <[e-mail]>]

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 <[e-mail]>
Date: Thursday, 1 February 2024 at 02:56
To: Rob Wilton (rwilton) <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, The IESG <[e-mail]>, Mahesh Jethanandani <[e-mail]>, [e-mail] <[e-mail]>, Warren Kumari <[e-mail]>
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 <[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