Re: [tcpm] [Editorial Errata Reported] RFC7323 (6798)

Carsten Bormann <cabo@tzi.org> Sun, 26 December 2021 14:40 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7223A047D for <tcpm@ietfa.amsl.com>; Sun, 26 Dec 2021 06:40:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seAWDgdrBR_7 for <tcpm@ietfa.amsl.com>; Sun, 26 Dec 2021 06:40:00 -0800 (PST)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF1053A046E for <tcpm@ietf.org>; Sun, 26 Dec 2021 06:39:58 -0800 (PST)
Received: from smtpclient.apple (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4JMNk34NhkzDCby; Sun, 26 Dec 2021 15:39:55 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <61C84CAD.8040300@btconnect.com>
Date: Sun, 26 Dec 2021 15:39:54 +0100
Cc: RFC Errata System <rfc-editor@rfc-editor.org>, rs@netapp.com, tcpm@ietf.org, yaakovjstein@gmail.com, braden@isi.edu, vanj@google.com, david.borman@quantum.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <5152DC2D-1E40-4011-94D7-EE7CBB851C6E@tzi.org>
References: <20211226085938.97471F0F1F@rfc-editor.org> <61C84CAD.8040300@btconnect.com>
To: t petch <ietfa@btconnect.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/DJidQslv-iU2RRs5OV2kJnSh_uM>
Subject: Re: [tcpm] [Editorial Errata Reported] RFC7323 (6798)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Dec 2021 14:40:05 -0000

On 26. Dec 2021, at 12:06, t petch <ietfa@btconnect.com> wrote:
> 
> One AD once said that a MAY is the same as a MAY NOT and therefore is pointless.  Makes sense to me.  I find it hard to come up with a situation where 'MAY' has any value.

A MAY for one party means that the other party MUST be able to handle the allowed behavior.
(I.e., not crash, not delete all your files, MAYbe even do something meaningful with the first party’s behavior.)

Not at all pointless, if used correctly.

Grüße, Carsten