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

Brian Rosen <br@brianrosen.net> Fri, 03 June 2022 15:50 UTC

Return-Path: <br@brianrosen.net>
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 92391C15AAD7 for <tao-discuss@ietfa.amsl.com>; Fri, 3 Jun 2022 08:50:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20210112.gappssmtp.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 JBd6I6dI6QyF for <tao-discuss@ietfa.amsl.com>; Fri, 3 Jun 2022 08:50:08 -0700 (PDT)
Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C4D3C15AAE0 for <tao-discuss@ietf.org>; Fri, 3 Jun 2022 08:50:08 -0700 (PDT)
Received: by mail-il1-x136.google.com with SMTP id a15so7208153ilq.12 for <tao-discuss@ietf.org>; Fri, 03 Jun 2022 08:50:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20210112.gappssmtp.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ua6S50ilvugUmGnlybod9aMvz9yjQFyU0yRkmNjitAo=; b=h3oz7UL0j8SCLGVJGNo8+JLseFxXv0CEimWsYefeFpz89wUMLjvYPJ5SmRFlCSpE6j xRw28e8cTiXvzmLr3ytHIK/6b3XyMpMsuDjyXMjQnWQiBOvNWm1CATixxZG/ZlQfXhwh iXvnkGIrjuQ2AUFEvnqiUHorY1rRplEbOjaomZY326Sm1tu3YiXTBI1c/HtfaeXEh8GN t/LfohzBd3p17a5Q+uqhspXqvGnqtgSzqW/kcf2fx776MiTW+RVc6DeMf9fI58XKl7LA sX8q7gWVlKxXrk9J3lqqeGX5RALLfoHUGHrrYqw5bcPnUk2Ap6Fsg5oejvBAPvGKZIWX YvgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ua6S50ilvugUmGnlybod9aMvz9yjQFyU0yRkmNjitAo=; b=GVYBpG4lXNt16Nb5F+Azy61yzEXm/mq1hPTiIVB6yztZ9xmmzvydoaA/AGL6IJBDWp Eb/QmVQL3XGkGnBCFxSZ14Rl5OHOdkF8yQOYE2CLZ3b3NA7xMWmE6LokJEWBGpe7LnTL h3S3fQGqcSYV0NzgsYkt7TdzBmtW10h4k1shrv9rKYEBMOyEuJXlS6eb2E6Xqmd5whDR A3/OPLOel+fSmWPDNDkHAJKd6bN2e2cZFv8q4U9N0BTmANuQ42QkZ5KkJGZ3twXZTGEQ 7WxyO06V2aArIMzhwKJzKVluCSISvrvoMDTwknW3dl8koBegAPadwPIy9Giv0/BM1tfT TjpA==
X-Gm-Message-State: AOAM53152QzpM/tzSQRm/jsosNw3rMxRjMyx16ohfl8UH23ZzfKbUsLM 4U0qicY81rgkfrywtHQfs226jG2j6Q4xrVqv
X-Google-Smtp-Source: ABdhPJyMRkHPwkCDwotzYtFXRzhtg18ffFX+eDroLuMxOf5okQLpKj/aTBkBprErgyOMVarPuQptMA==
X-Received: by 2002:a05:6638:248c:b0:32e:be23:7160 with SMTP id x12-20020a056638248c00b0032ebe237160mr6289418jat.311.1654271407621; Fri, 03 Jun 2022 08:50:07 -0700 (PDT)
Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id ce6-20020a0566381a8600b0032b3a7817cfsm2638158jab.147.2022.06.03.08.50.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Jun 2022 08:50:07 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
From: Brian Rosen <br@brianrosen.net>
In-Reply-To: <3951006C-21D8-4A04-9CC5-2D88B3A94778@akamai.com>
Date: Fri, 03 Jun 2022 11:50:05 -0400
Cc: Lars Eggert <lars@eggert.org>, Kirsty Paine <kirsty.ietf@gmail.com>, "gendispatch@ietf.org" <gendispatch@ietf.org>, "gendispatch-chairs@ietf.org" <gendispatch-chairs@ietf.org>, "tao-discuss@ietf.org" <tao-discuss@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C5B7316E-97BE-4C52-8383-15F3BC3CC7ED@brianrosen.net>
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>
To: Rich Salz <rsalz@akamai.com>
X-Mailer: Apple Mail (2.3696.100.31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tao-discuss/JnMyXFTwe3ql398V4_l7UOedT4c>
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 15:50:11 -0000

That’s a rendering decision, not a content decision.

I’m pretty sure most of us point any newcomers to the Tao.  

I do that because I think it represents the consensus (key word) of who we are and how we work.  I do not trust a website content creator to get that right.  And I’d prefer not to have to trust a self-selected group (a work group) to get that right without review.  It’s a small stretch to say the IESG has to review and approve, but I think that just using the RFC process is the best way forward.  

Once we have the consensus on the words, you can render them in some pleasing way on the website.

Brian


> On Jun 3, 2022, at 11:43 AM, Salz, Rich <rsalz@akamai.com> wrote:
> 
>>>  Dunno, ISTM that the simplest, most straightforward solution is just make the TAO an RFC again.
>> 
>> I very strongly believe that this misses the point.  "It is not a formal IETF process document but instead an informational overview."
> 
>>  That seems to be a distinction without a difference, because, I think, it ought to get an IETF-wide review, and, I think, the IESG should review it.
> 
> You are comparing "Tao as RFC" with "Tao under the current process (RFC 6722)" and I mostly agree that there is no effective difference between those two.  The proper evolution of 6722 is to just make it a web page, developed by professionals. 
>