[DNSOP] Murray Kucherawy's No Objection on draft-ietf-dnsop-avoid-fragmentation-17: (with COMMENT)

Murray Kucherawy via Datatracker <noreply@ietf.org> Mon, 18 March 2024 05:58 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Murray Kucherawy via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dnsop-avoid-fragmentation@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, benno@NLnetLabs.nl, swoolf@pir.org, tjw.ietf@gmail.com
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Murray Kucherawy <superuser@gmail.com>
Message-ID: <171074148020.33112.4933316910757929657@ietfa.amsl.com>
Date: Sun, 17 Mar 2024 22:58:00 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DvRlZOr_XvwQvy-sUhLLyigKnZ0>
Subject: [DNSOP] Murray Kucherawy's No Objection on draft-ietf-dnsop-avoid-fragmentation-17: (with COMMENT)

Murray Kucherawy has entered the following ballot position for
draft-ietf-dnsop-avoid-fragmentation-17: No Objection

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/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for addressing my DISCUSS and Barry's remaining ARTART review point.

I support Rob Wilton's DISCUSS position. Piling on a bit, in reference to:

R6. UDP requestors SHOULD limit the requestor's maximum UDP payload
size to the RECOMMENDED size of 1400 or a smaller size.

I think the "RECOMMENDED" here is just carrying forward a "RECOMMENDED" from
someplace else. If that's correct, I suggest changing it to "recommended" or,
if you want to be more precise, "... to the size recommended by RFCXXXX of 1400
or smaller." Now it's clear what the SHOULD is referencing, and you don't own
the RECOMMENDED part here.

I suggest defining "EMSGSIZE" in Section 2 to be the UNIX error code of the
same name. Otherwise, we encounter it in Section 3.1 in a way that could mean
it's an error code (which is how I think you intend it) or as a symbolic name
for the path MTU size.

Forwarded comments from Orie Steele, incoming ART Area Director:

"Recommendations for zone operators and DNS server operators"

* Define "large / small" better.

"Protocol compliance considerations"

* Would be nice to see reporting recommendations, perhaps that make the failure
an internal cost for the failing component?... would not want a repeat of dmarc
though.

[DNSOP] Murray Kucherawy's No Objection on draft-… Murray Kucherawy via Datatracker