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