IETF Logo Mail Archive

Re: [Emu] Adoption call for EAP-DPP

Eliot Lear <lear@lear.ch> Thu, 18 August 2022 08:16 UTC

Return-Path: <lear@lear.ch>
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 28D6BC14CF04 for <emu@ietfa.amsl.com>; Thu, 18 Aug 2022 01:16:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
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 U-h-w-T3EZIS for <emu@ietfa.amsl.com>; Thu, 18 Aug 2022 01:16:30 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 E962CC14CF09 for <emu@ietf.org>; Thu, 18 Aug 2022 01:16:28 -0700 (PDT)
Received: from [192.168.0.130] (77-58-144-232.dclient.hispeed.ch [77.58.144.232]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 27I8GFbK808546 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 18 Aug 2022 10:16:16 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1660810577; bh=+VCypNUnrJAjkqlyj3pFA/l5qFYzaWR2lW91O6akRRs=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=eC3uHLVoGcp2a/Z4DiV87hFWdqHdg25p8+X1ciCzXW2Hct4cCQRzstzhVAO6eW/dt pMZrZHp0vvpVy7ZQKgX48ALk1jal3IKNgPu7200UzwXtdenAZlN/L/sQ68KHbLGqhg RmcxV0Xf2s8igyrtSDIRy7YP9STIaLqNPpkrKOms=
Message-ID: <44b1271b-8fc7-e0ed-69af-d406af6f1ab0@lear.ch>
Date: Thu, 18 Aug 2022 10:16:13 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.12.0
Content-Language: en-US
To: sarikaya@ieee.org, Peter Yee <peter@akayla.com>
Cc: emu@ietf.org
References: <01bf01d8b1ac$81233890$8369a9b0$@akayla.com> <CAC8QAcfzQHQg4GQNaqG5k9QJ00-CBCPnwdseLUSYQ=me4rGXEQ@mail.gmail.com>
From: Eliot Lear <lear@lear.ch>
In-Reply-To: <CAC8QAcfzQHQg4GQNaqG5k9QJ00-CBCPnwdseLUSYQ=me4rGXEQ@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------0iWfZGmUUuxjZt4geBQcY7uq"
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/uK0YyZTs_EIdvMcSTFa2v5xS2Tc>
Subject: Re: [Emu] Adoption call for EAP-DPP
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 18 Aug 2022 08:16:34 -0000

I agree with Behcet's comments, but otherwise support the work's adoption.

Eliot

On 17.08.22 23:36, Behcet Sarikaya wrote:
> Hi Peter,
>
> I quickly read this short document and have some comments.
>
> In the informative references section, DPP is listed as Device 
> Provisioning Profile while it should be Device Provisioning Protocol.
> Actually, in the acronyms section the name is correctly given. 
> However, the DPP acronym is not properly expanded in the first use of 
> the acronym which is in Section 1. Also the same could be said of the 
> other acronyms.
>
> Also the date of DPP document seems to be wrong, I think the version 
> 1.1 was dated 2018.
>
> Probably more seriously though, the document says DPP does not support 
> wired network access in Section 1 but maybe the authors are not aware 
> that there is something called wired only DPP which is defined in 
> another WiFi Alliance document in Section 2.3.5 of
>
> Wi-Fi Easy ConnectTM Specification v2.0
>
> This document is dated 2020, maybe the authors should reference this 
> document then the date will be correct 👍🏻.
>
> Behcet
>
> On Tue, Aug 16, 2022 at 3:12 PM Peter Yee <peter@akayla.com> wrote:
>
>     This is an adoption call for EAP-DPP
>     (draft-friel-tls-eap-dpp-05)[1]. This
>     document aligns with the charter item to "Define mechanisms by
>     which EAP
>     methods can support creation of long-term credentials for the peer
>     based on
>     initial limited-use credentials." The latest revision incorporates
>     feedback
>     from both the TLS and EMU working groups. Please review and
>     respond to the
>     list if you think this document is or is not an appropriate
>     working group
>     item for EMU by September 1, 2022.
>
>     Thanks,
>
>     Peter and Joe
>
>     [1] https://datatracker.ietf.org/doc/draft-friel-tls-eap-dpp/
>
>
>     _______________________________________________
>     Emu mailing list
>     Emu@ietf.org
>     https://www.ietf.org/mailman/listinfo/emu
>
>
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu

v2.23.0 | Report a Bug | By Email