Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03

Carolin Baumgartner <latze@angry-red-pla.net> Mon, 05 July 2021 14:20 UTC

Return-Path: <latze@angry-red-pla.net>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D90E3A1986 for <emu@ietfa.amsl.com>; Mon, 5 Jul 2021 07:20:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.237
X-Spam-Level:
X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 849lgl917Tzm for <emu@ietfa.amsl.com>; Mon, 5 Jul 2021 07:20:19 -0700 (PDT)
Received: from ans00.89grad.ch (ans00.89grad.ch [185.20.144.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DAD63A197F for <emu@ietf.org>; Mon, 5 Jul 2021 07:20:18 -0700 (PDT)
Received: from [83.222.129.243] (unknown [83.222.129.243]) by ans00.89grad.ch (Postfix) with ESMTPSA id 1C2B6DDF6D for <emu@ietf.org>; Mon, 5 Jul 2021 07:20:14 -0700 (PDT)
To: emu@ietf.org
References: <DB6D339A-710C-4EC4-9F8E-4B8602632AE1@deployingradius.com> <CABXxEz8EBUz_y1FmQTE9C8cpF+3vqy-mPCx8CnyUMZ72pNifAA@mail.gmail.com> <SJ0PR00MB1038767373E0DE9E3D7BE0DA95039@SJ0PR00MB1038.namprd00.prod.outlook.com> <C7DBE2EB-82BF-4229-B0AF-4BA48B2D45BC@deployingradius.com> <7332.1624927848@localhost> <4F79B7DB-7E55-4564-88AE-C6E2AF8FD293@deployingradius.com> <26359.1625006432@localhost> <BFA8E5C4-D368-41BF-AFA9-BAA35B666F8A@deployingradius.com> <a02d4815-dbfa-e0a0-99fb-0f53127f2fd1@lear.ch> <13DD39D5-57C4-48D2-868A-C4D530127095@deployingradius.com> <79e7dff7-c473-762f-b7f4-3d056b6953fe@lear.ch> <9235E3E6-1346-4481-A7C8-EEFEF4D56A7F@deployingradius.com> <SJ0PR00MB10384831490B8F890DE2FCC4951E9@SJ0PR00MB1038.namprd00.prod.outlook.com> <1A06136A-BA13-47A2-8C27-B6841F95D3CA@deployingradius.com> <9e71b858-d5c6-8265-3c11-95d7d75cdeae@lear.ch> <95D7A8DB-0FF0-4F7D-AA84-F146D820B0B4@deployingradius.com>
From: Carolin Baumgartner <latze@angry-red-pla.net>
Message-ID: <112317d3-4c26-caf9-3118-a8d58c1acfdf@angry-red-pla.net>
Date: Mon, 05 Jul 2021 16:20:13 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <95D7A8DB-0FF0-4F7D-AA84-F146D820B0B4@deployingradius.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/dcOrXrtGbWLWPyTmPMtgRxslP40>
Subject: Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Jul 2021 14:20:24 -0000


On 7/3/21 1:57 PM, Alan DeKok wrote:
> On Jul 3, 2021, at 7:47 AM, Eliot Lear <lear@lear.ch> wrote:
>> I don't think Tim could be blamed for holding the view that there is a separation between specifications and how they are used. There's good and bad to the practice.  The good is that the spec can be used in ways that the creators didn't intend, and thus perahsp there are fewer unnecessary constraints.
>>
>> On the other hand, not having a theory of operation section, as we do have in a good number of our specs, leads to people really not understanding when they are applicable, and perhaps more importantly, when they are not.
>    People don't even understand how to use the specs as intended. We're essentially telling people "EAP methods are applicable in these situations, but good luck actually trying to get them deployed, you're on your own".
I agree and out of experience everything that leaves just a little bit 
room of interpretation ("you can do it this way or that way") ends up in 
misinterpretions or gaps and causes good ideas to fail.