Re: [Tools-discuss] I-Ds, submission, and preferred formats
John C Klensin <john-ietf@jck.com> Sat, 28 May 2022 22:33 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC509C15AE2A; Sat, 28 May 2022 15:33:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQ6PSjMc-ULo; Sat, 28 May 2022 15:33:07 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A333C157B49; Sat, 28 May 2022 15:33:06 -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 1nv4zZ-000HRG-2S; Sat, 28 May 2022 18:33:05 -0400
Date: Sat, 28 May 2022 18:32:59 -0400
From: John C Klensin <john-ietf@jck.com>
To: Jay Daley <exec-director@ietf.org>
cc: tools-discuss@ietf.org
Message-ID: <78DC6E412E96CB60F3B6483C@PSB>
In-Reply-To: <6C91E258-B5F5-400B-9400-E8416056969A@ietf.org>
References: <965BB042359713525F06D6D3@PSB> <6C91E258-B5F5-400B-9400-E8416056969A@ietf.org>
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
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-discuss/_5qXJ4xRcEDuI-IHN2JMy47r0dY>
Subject: Re: [Tools-discuss] I-Ds, submission, and preferred formats
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: IETF Tools Discussion <tools-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-discuss/>
List-Post: <mailto:tools-discuss@ietf.org>
List-Help: <mailto:tools-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 May 2022 22:33:08 -0000
Hi Jay, Thanks for the detailed and careful response [1] to my mid-week note on this subject, a note that I made the mistake of thinking was raising simple issues. I have been working intermittently since then, during a busy and difficult week, on an equally careful, item-by-item, response but, upon nearly finishing it, realized that it was going to be long and detailed enough that few people would read it. Therefore, this note (which may still be too long for some but breaking it up does not seem helpful) is a summary of my main points/ concerns after reviewing your message and writing the (forthcoming) other one. Apologies if several of the points sound like echoes of sections of "UX Design 101" -- I don't want to make assumptions about who has studied that sort of material. I will post the longer version soon, but this overview will be the important message for those who don't want to deeply in the details. Key Issues: (a) On IETF pages that interact with people trying to get work done, it should be obvious how to contact someone to make reports of problems or suggestions. (b) Finding that the tools that were selected make doing something hard, should often be cause for review of the choices, not for rejecting a user suggestion. (c) Broad and extensive discussion, and even agreement, on this list does not equal IETF consensus, especially if there is no strong evidence that those who follow the list are a representative sample of IETF participants and would-be participants, including newcomers. It is also not equivalent to informing the broader IETF community about changes made and the reasons for them. (d) However good a "getting started", TOC, or index page is, the nature of the web and availability of search functions guarantees that people looking for information will sometimes reach a page that appears to have that information directly. It is important that it be obvious how to navigate from that information to closely related materials (possibly including the sought-for answers) when they are on other pages. (e) Changes in long-used terminology can be a source of considerable confusion to those who are used to the original terms, no matter how ill-conceived those terms were and how much better the new terms would be if they had been used initially. It may still be worth making the changes, but careful and readily available explanations and pointers are important. Much the same comment sometimes applies to user interfaces. (f) If one has a community that includes old dogs who are unable or reluctant to learn new tricks, forcing those new tricks on them or disparaging the old ways of doing things may be equivalent to telling said old dogs to retire. One may not need to be very far along chronologically to qualify as an "old dog" in this sense -- just "very busy" may be sufficient. Sometimes, such a change may [still] be a good choice. On other occasions, it may cost the community important resources and contributors. Except in autocracies, the decision should normally be made consciously and by the whole community. (g) Authors or editors of I-Ds may sometimes use comments in the [RFC]XML to manage documents in transition, temporarily retain text that was removed and the reason for removing it, comment for personal reference on particular suggestions, maintain synchronization between I-D text and tracking/ticket systems, and so on. Those comments almost certainly do not belong in the archival RFC version of the XML that will evolve from the I-D. Many of them are private notes and should not be public at all: they might be inflammatory and/or confuse WG discussions. Other comments, of course, may be helpful in a version that goes to the RPC or even in the permanent/archival RFC version. Expecting the author/editor to remove some comments and not others before posting an I-D may be unreasonably burdensome and may discourage some people from taking on those roles. thanks, john [1] https://mailarchive.ietf.org/arch/msg/tools-discuss/P2utPk_fWCTPNgHoUfjrOtOOln8
- [Tools-discuss] I-Ds, submission, and preferred f… John C Klensin
- Re: [Tools-discuss] I-Ds, submission, and preferr… Jay Daley
- Re: [Tools-discuss] I-Ds, submission, and preferr… John C Klensin
- Re: [Tools-discuss] I-Ds, submission, and preferr… John C Klensin