[secdir] Re: SECDIR review of draft-ietf-emailcore-rfc5321bis-42

John C Klensin <john-ietf@jck.com> Fri, 04 April 2025 19:29 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: secdir@mail2.ietf.org
Delivered-To: secdir@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 06D3817B5AC9; Fri, 4 Apr 2025 12:29:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VioONYepCYic; Fri, 4 Apr 2025 12:29:55 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by mail2.ietf.org (Postfix) with ESMTP id 7AEDE17B59D4; Fri, 4 Apr 2025 12:29:43 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1u0mjV-0002tD-18; Fri, 04 Apr 2025 15:29:41 -0400
Date: Fri, 04 Apr 2025 15:29:34 -0400
From: John C Klensin <john-ietf@jck.com>
To: Donald Eastlake <d3e3e3@gmail.com>, iesg@ietf.org
Message-ID: <C10CF7596D234BF187260286@PSB>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Message-ID-Hash: W54SQEDO7IJWP5RWVKQB773QQNGDAWWO
X-Message-ID-Hash: W54SQEDO7IJWP5RWVKQB773QQNGDAWWO
X-MailFrom: john-ietf@jck.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-secdir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: secdir <secdir@ietf.org>, draft-ietf-emailcore-rfc5321bis.all@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [secdir] Re: SECDIR review of draft-ietf-emailcore-rfc5321bis-42
List-Id: Security Area Directorate <secdir.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/QitxUMcjSAjceRedb8rk3OcyD5E>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Owner: <mailto:secdir-owner@ietf.org>
List-Post: <mailto:secdir@ietf.org>
List-Subscribe: <mailto:secdir-join@ietf.org>
List-Unsubscribe: <mailto:secdir-leave@ietf.org>

(sorry -- hit "send" too soon.  One additional comment below.)

Donald,

Thanks for the careful reading.  All of these seem appropriate for
action by the RPC (one or two stylistic issues that may require
discussion with them) rather than anything security-specific as
called for in the now-closed recent Last Call.

FWIW and while nits are being picked, like at least one of its
predecessors, this review was posted many hours after the
notification from the datatracker that the Last Call had closed. 

No idea where the first one listed came from, but presumably some
sort of pasting error -- corrections made in the working version of
the RFCXML file.

The use of "in principle" appears, in both of the contexts you
observed, in RFC 5321 and the first usage is in RFC 2821.  Changing
it interacts with "minimal change" principle established by the WG
and its charter.  Independent of that procedural issue, the phrasing
was used in 2008 and earlier to indicate that the changes to code
definitions referred to in 4.3.2 and the possible separate registries
referred to in 8.1.4 would be bad ideas under any circumstances the
WG could determine.  While "in principle" is, in a way, hand waving,
the alternative would have been to say, explicitly, something like
"we don't want to prohibit that possibility, but any attempt to do it
should be scrutinized very carefully" or a normative "such things
SHOULD NOT be done".   The experience in 2007-2008 and predictions
from several of the comments made during the review of 5321bis
strongly suggests that anything appearing to be a statement along
those lines would produce demands to spell out the circumstances
under which such actions should be allowed or prohibited, something
the WG could not do because those circumstances cannot be foreseen.
So, "in principle" appeared to be, not useless noise as your note
implies, but a deliberate, least-bad, choice.

thanks again,
   john


--On Friday, April 4, 2025 14:15 -0400 Donald Eastlake
<d3e3e3@gmail.com> wrote:

> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG. Document editors and WG chairs should treat these comments
> just like any other last call comments.
> 
> The summary of the review is Ready with nits.
> 
> This is a re-review for version -42. I previously reviewed versions
> -38 and -32 of this draft.
> 
> All good enough except for a few nits.
> 
> Nits:
> 
> When I look at Section 4.1.1.3, I see three unknown character
> glyphs: two right after the end of the 1st sentence in the 2nd
> paragraph and one between "destination" and "mailbox" later in that
> paragraph.
> 
> Section 8.1.1.3, 2nd paragraph, 1st sentence, "is required" -> "are
> required"
> 
> Section 8.1.1.3, item (1), "non terminal" -> "nonterminal"
> 
> Section 8.1.1.3, item (2), "a server and client  SMTP" -> "an SMTP
> server and client"
> 
> Suggest deleting both occurrences of "in principle". Either
> something applies or it doesn't. Asserting something qualified by
> "in principle" does not seem useful.
> 
> 
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e3e3@gmail.com