[ietf-smtp] Two requests: (was: Re: DANE / ...: Renew these Let's Encrypt certificates by March 4)

John C Klensin <john-ietf@jck.com> Sun, 08 March 2020 16:51 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5983A0D32 for <ietf-smtp@ietfa.amsl.com>; Sun, 8 Mar 2020 09:51:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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, SPF_HELO_NONE=0.001, SPF_NONE=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 Dczuuim0ayaM for <ietf-smtp@ietfa.amsl.com>; Sun, 8 Mar 2020 09:51:25 -0700 (PDT)
Received: from bsa3.jck.com (bsa3.jck.com [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDE173A0D2F for <ietf-smtp@ietf.org>; Sun, 8 Mar 2020 09:51:25 -0700 (PDT)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1jAz9A-000GvV-GW for ietf-smtp@ietf.org; Sun, 08 Mar 2020 12:51:24 -0400
Date: Sun, 08 Mar 2020 12:51:19 -0400
From: John C Klensin <john-ietf@jck.com>
To: ietf-smtp@ietf.org
Message-ID: <9F447D73C43087F1C49A1A7F@JcK-HP5.jck.com>
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
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/iZ1rtULNRo6VTnloYjixKir_ztA>
Subject: [ietf-smtp] Two requests: (was: Re: DANE / ...: Renew these Let's Encrypt certificates by March 4)
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Mar 2020 16:51:32 -0000

Hi.

This is a personal request (explained below [1]).  I do not
presume to determine the limits of scope for this list and would
not want that responsibility.  However...

Could we please confine postings to this list to discussions of
and issues with actual core IETF email protocols and keep
discussions of issues with, or applications of, protocols and
issues that have their own email lists on those lists?  

In the case of recent postings, I note the availability of
https://www.ietf.org/mailman/listinfo/dane for DANE issues.  For
DNSSEC, the DNSOP WG and its mailing list at
http://www.ietf.org/mailman/listinfo/dnsop would seem
appropriate.

A quick, "please do not reply here, reply there" note to this
list alerting people to the issue would seem appropriate; the
issue is with the extended discussions.   Pushing these things
onto the more specialized lists also has the advantage that
there may be more expertise there.  Most of the people on this
list who are really expert should probably be on those lists
anyway.

Also: if something is posted to this list, please edit "ACTION
REQUESTED" or or similar terms out of subject lines unless it is
actually something on which the list can take action or that
affects the content of those core specifications.

Postings here for things that might go into a possible
Applicability Statement are presumably appropriate too, but I'd
like to see those 
postings clearly identify that they are not intended for 5321bis
(or 5322bis) and I hope someone will post at least a preliminary
outline for such a document for use as a placeholder first.
(See next message.)

The reasons for this preference and request are in the first
endnote []1].  Those who don't care should probably just not
read it. 

thanks,
    john

   -----

[1] Why?   I, and I presume Pete, are trying very hard to track
issues that should be considered for inclusion in
5321bis/5322bis and/or would shape a WG charter and its scope
statement. If we don't do that in real time, it is likely that
the eventual WG (if it is being responsible) will have to track
through all of the postings to this list of the last dozen years
(since we decided that any further tuning of the documents could
wait for a revision, not the publication date) to identify
possibly-relevant issues.   I would not presume to claim
consensus, but I note that Barry, Dave, Pete, myself, and others
have all expressed (albeit with differences in specifics and
probably with perceptions about where the boundaries should lie)
for confining work on those documents to errata, clarifications,
and minor adjustments, rather than taking them in new (to them)
directions.  The recent thread about Message-IDs may be a good
example: if it implied that clarifications to the text in 5322
were needed (I'm personally convinced it, and RFC 2231, are
quite clear), that would, IMO, be a reasonable discussion for
this list.

However, I am busy and preoccupied with other things.  I won't
presume to speak for Pete, but I know he has other things on his
plate.  I, and probably others, use words like "ACTION
REQUESTED" (especially if they appear in all-caps) to prioritize
the order in which I read messages and a false alarm is likely
to drop a message to the bottom of the queue for action or
response.  And, in general, threads of postings that have little
or nothing to do with 5321, 5322, or other core email protocols
[2], are just noise that gets in the way of accurate issue
tracking and, potentially, even the willingness to do that work
in anticipation of a WG.


[2] I'd count the core MIME specs and there is probably a strong
argument for counting SMTPUTF8 ("EAI") SMTP and Mail Header
specs, but they do have their own mailing list.  YMMD and I hope
we don't need to discus that here, at least any time soon.