Re: Proposed ietf.org email address policy
John C Klensin <john-ietf@jck.com> Sun, 13 June 2021 17:49 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637853A22DA for <ietf@ietfa.amsl.com>; Sun, 13 Jun 2021 10:49:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 gL3mwXT1LIGD for <ietf@ietfa.amsl.com>; Sun, 13 Jun 2021 10:49:05 -0700 (PDT)
Received: from bsa3.jck.com (static-65-175-133-136.nh.cpe.atlanticbb.net [65.175.133.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9EB33A22DE for <ietf@ietf.org>; Sun, 13 Jun 2021 10:49:04 -0700 (PDT)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1lsUCu-000GVd-0S; Sun, 13 Jun 2021 13:47:36 -0400
Date: Sun, 13 Jun 2021 13:47:15 -0400
From: John C Klensin <john-ietf@jck.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
cc: IETF list <ietf@ietf.org>
Subject: Re: Proposed ietf.org email address policy
Message-ID: <BB343401F7F2798A7EC7D196@JcK-HP5>
In-Reply-To: <26cf60f0-a007-a53f-f386-069526c31be4@cs.tcd.ie>
References: <2BF6EC60-8B32-4171-B236-D9D038B3135B@yahoo.co.uk> <20210611174521.CD568F22E4A@ary.qy> <20210611182604.GA36947@faui48e.informatik.uni-erlangen.de> <ff6d912d-b0c6-4550-8d16-a79348e45699@dogfood.fastmail.com> <CAKKJt-enK4XmMuapke9LX-3TVuyg9j12zS9RyWXqvOT6Vbk5Mw@mail.gmail.com> <7606DFCE59EA95E72625E0FF@PSB> <26cf60f0-a007-a53f-f386-069526c31be4@cs.tcd.ie>
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/EQFFiOpc28qcw5OTULioBfmsu6o>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Jun 2021 17:49:10 -0000
--On Sunday, 13 June, 2021 13:14 +0100 Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote: > > Hiya, > > On 12/06/2021 17:14, John C Klensin wrote: >> But that suggests that, at least for standards-track >> documents, having people ask questions directly of the >> authors and expect authoritative responses is something we >> should be discouraging, not encouraging. > > Disagree. One of the good things about the RFC series > and IETF specs is that they are written by sets of > contactable humans. often contactable. > I don't think there's a real problem with authors giving > secret advice that goes against IETF consensus so let's > not change/break anything for that reason. First, I don't see enough of a problem to justify a change in what we have been doing. I am only concerned that making it easier to find the authors of older RFCs might not be as good an idea as it might appear to be on first glance. I'm worried about two cases. And let me apologize in advance for saying what amounts to "this is part of a larger problem and a quick fix to part of it might make things worse". But it is and it could. (1) Assume someone wrote or co-wrote an RFC many years ago, but has subsequently dropped out of the IETF. In the intervening period and without that author being involved or knowing about it, the IETF consensus on what is specified and/or how it should be interpreted or applied has changed. That author, even with all good intentions, may not be the most reliable source of information. As a personal example, I think I mentioned that I recently received a query about what they believed to be an ambiguity in RFC 1425. Now I have stayed around, know what has happened since, and responded to the question by pointing the person who asked to 5321 and suggesting the EMAILCORE list if they believed there was still an ambiguity. But suppose that, sometime in late 1993, I had decided I had had enough of email specifications and the IETF generally, dropped out, and stopped paying attention to any of this. Would we really, really, want questions about variations on SMTP addressed to me in 2021? (2) I don't know about your experience but, at the direction of WGs for whom I've been acting as author/editor, I have sometimes written things into documents that became RFCs with which I profoundly disagree. In many cases, subsequent experience has proven the WG to have been correct. In others, similar experience shows that I was right in the first place. Now, with the understanding that, in such situations "what do you think I should do in case ABC?" and "what does the standard intend be done in case ABC?" are different questions and that even the person asking may not know the difference, how should the author, especially an author who believe that that should not write response more than 240 characters long, respond? "What is the history of that particular decision" is yet another question, one on which I'd assume the author would be authoritative. In both cases, if we were better at making notes when experience and/or consensus changes and in making it obvious which specifications, comments, updates, notes, etc., go together, we would have fewer problems. AFAICT, we know of two ways to provide that sort of information: (a) Figure out better ways to index, collect, and/or annotate the content of documents in ways that make relationships and current thinking clear. The late (and lamented by some) efforts of the NEWTRK WG proposed one or two ways to do this and, although I don't remember its being explicitly proposed, those documents could contain best current contact information for documents or sets of them. (b) More or less abandon the notion of static RFCs with fixed number assignments as representations of our standards. That could be done by adopting a model similar to ISO's in which (to use historical examples I would not recommend trying to change) the successor to specification 760:1980 would be 760:1981 (not 791) and the first update that does not completely replace the base specification would be 760:1980-Amendment1 (or "...-Amendment1(1992)", not 1349. Or we could go all the way to expressing standards as living documents, updated in place any time there was consensus about a change or correction and with no notion of static documents other than tracking history. Does that explain the concern better? best, john
- Re: Proposed ietf.org email address policy Salz, Rich
- Proposed ietf.org email address policy IETF Chair
- Re: Proposed ietf.org email address policy Fred Baker
- Re: Proposed ietf.org email address policy John C Klensin
- Re: Proposed ietf.org email address policy Keith Moore
- Re: Proposed ietf.org email address policy Lloyd W
- Re: Proposed ietf.org email address policy John C Klensin
- Re: Proposed ietf.org email address policy Michael Richardson
- Re: Proposed ietf.org email address policy John Levine
- Re: Proposed ietf.org email address policy Toerless Eckert
- Re: Proposed ietf.org email address policy Bron Gondwana
- Re: Proposed ietf.org email address policy Spencer Dawkins at IETF
- Re: Proposed ietf.org email address policy Michael Richardson
- Re: Proposed ietf.org email address policy John C Klensin
- Re: Proposed ietf.org email address policy Michael Richardson
- Re: Proposed ietf.org email address policy Brian E Carpenter
- Re: Proposed ietf.org email address policy Stephen Farrell
- Re: Proposed ietf.org email address policy Carsten Bormann
- Re: Proposed ietf.org email address policy John C Klensin
- Re: Proposed ietf.org email address policy Aqua Q Glass
- Re: Proposed ietf.org email address policy ned+ietf
- Re: Proposed ietf.org email address policy John C Klensin
- Re: Proposed ietf.org email address policy John C Klensin
- Re: Proposed ietf.org email address policy Adam Roach
- Re: Proposed ietf.org email address policy Carsten Bormann
- RE: Proposed ietf.org email address policy Larry Masinter
- Re: Proposed ietf.org email address policy Phillip Hallam-Baker
- Re: Proposed ietf.org email address policy Scott Bradner
- Re: Proposed ietf.org email address policy Spencer Dawkins at IETF