Re: [tao-discuss] [Gendispatch] Requests for IETF 114

Joel Halpern <jmh@joelhalpern.com> Fri, 03 June 2022 16:24 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: tao-discuss@ietfa.amsl.com
Delivered-To: tao-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0D1C14F737; Fri, 3 Jun 2022 09:24:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.005
X-Spam-Level:
X-Spam-Status: No, score=-4.005 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.876, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 ceG5g5TXxmzV; Fri, 3 Jun 2022 09:23:59 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3EB2C15AAFE; Fri, 3 Jun 2022 09:23:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4LF7Ty2mWYz1pVyp; Fri, 3 Jun 2022 09:23:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1654273398; bh=7UEQj7ce5StcUDl817KQ+T9zPIdsu35Zbh4BWtNKiX4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=BLJJae79Cs/HvmVXi/g0XOZhsQTnz8aLCbN9sl6z6rgwkmvsqUWEa9IXpVmq9bHbb aDbY8NTaHHGREb/etHJQeoYM76YfUOui2VN/E6g7eyTwc+TIRDL0ixkXoEp57/fzsN VAMVlgYIEbFWa0jOD7E4uKXpUcPYNmCBa9n7HLGs=
X-Quarantine-ID: <hre_7gnxCI40>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.23.181] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4LF7Tx4sQfz1ntwr; Fri, 3 Jun 2022 09:23:17 -0700 (PDT)
Message-ID: <0f536143-d344-5fe3-fa66-b39f88c13034@joelhalpern.com>
Date: Fri, 03 Jun 2022 12:23:16 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
Content-Language: en-US
To: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>
Cc: "gendispatch@ietf.org" <gendispatch@ietf.org>, "tao-discuss@ietf.org" <tao-discuss@ietf.org>
References: <CAC9wnY-03+ToGL4KjjRaXBquxV2DeBaax67bxJB9qZEj=PSELg@mail.gmail.com> <89DAA7D5-3DF6-4B42-A3F0-7698F550C5B0@eggert.org> <36AFC944-59F3-49CC-AFEF-4471476F1913@eggert.org> <CB175E16-812E-4288-886B-B7FC82756720@akamai.com> <5C314F03-0C3D-4E1C-9AFE-BBCE8F775D8F@brianrosen.net> <7712AEA2-DDB3-4915-A060-9F3CACA9435E@akamai.com> <EB02214C-8DCC-41C1-A266-08A042AE6318@brianrosen.net> <3951006C-21D8-4A04-9CC5-2D88B3A94778@akamai.com> <C5B7316E-97BE-4C52-8383-15F3BC3CC7ED@brianrosen.net> <248F3BD3-4A5F-42FE-849A-DB04415DE325@akamai.com>
From: Joel Halpern <jmh@joelhalpern.com>
In-Reply-To: <248F3BD3-4A5F-42FE-849A-DB04415DE325@akamai.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tao-discuss/ROLwJtLYS_jvnxnpgUydTy3gXnI>
Subject: Re: [tao-discuss] [Gendispatch] Requests for IETF 114
X-BeenThere: tao-discuss@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Discussion of the Tao of the IETF <tao-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tao-discuss>, <mailto:tao-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tao-discuss/>
List-Post: <mailto:tao-discuss@ietf.org>
List-Help: <mailto:tao-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tao-discuss>, <mailto:tao-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jun 2022 16:24:04 -0000

The latter part of this answer seems to conflate the means we use to 
develop and agree on the Tao content with the means we use to present 
that content.  I presume there is some reason you are combining those, 
but I do not understand what it is.  The suggestion from several of us 
is that the development and agreement process seems well suited to the 
informational RFC process.  The IESG's original motivation for doing 
something different was a hope / expectation that we would get more 
frequent and more useful updates to the Tao by going away from that 
process.  The data Lars cited suggests otherwise.  At which point the 
benefits of using our well-established and well-understood development 
process seem clear.   Given that even when we used the RFC process 
before we still made the pages visible and easily findable (we hoped) by 
newcomers.   So we would still do that.

Yours,

Joel

On 6/3/2022 12:12 PM, Salz, Rich wrote:
>>    I’m pretty sure most of us point any newcomers to the Tao.
> My experience is otherwise.  I have given the newcomer's talk more times than I can remember. I have attended the newcomer's coffee break, both real and via Gather at every IETF I have attended in the past several years. I have been a mentor/guide multiple times. I have participated in the "meet and greet" and "quick connections" multiple times. I am active in the "newcomer's planning" preparations before every IETF.  The Tao has never come up. No newcomer has ever asked me a question about it. It has never been more than a URL on a slide.
>
>>     Once we have the consensus on the words, you can render them in some pleasing way on the website.
> Some could take that tone as dismissive; I don't.
>
> Words matter. Appearance matters. Pedagogy matters. Providing an overview for newcomers is not the same as detailing all the bits on a wire and their semantics, and too many experienced IETF people seem to think being qualified for one makes you qualified for the other. I know it's not, except in very rare cases (we don't have any Feynman's or Knuth's here that I know about).
>
> Folks want to document what the IETF does and how it works?  I am not arguing against that -- I am totally in support of that; we need it.  Heck, I drafted 2028bis. Someone should take on BCP 9. But yet another version of those things as an overview? If you are arguing for that, then you are showing me that you are not qualified to do so.
>
>