From nobody Sun Dec 26 06:40:06 2021
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:
>=20
> 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=E2=80=99s behavior.)

Not at all pointless, if used correctly.

Gr=C3=BC=C3=9Fe, Carsten