Re: [Ace] call for adoption for draft-marin-ace-wg-coap-eap

Alexandre Petrescu <alexandre.petrescu@gmail.com> Tue, 02 February 2021 11:33 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C628B3A19B9 for <ace@ietfa.amsl.com>; Tue, 2 Feb 2021 03:33:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.465
X-Spam-Level: ***
X-Spam-Status: No, score=3.465 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FAKE_REPLY_A1=2.796, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 bMB4evOv7mjc for <ace@ietfa.amsl.com>; Tue, 2 Feb 2021 03:33:45 -0800 (PST)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 4DF553A19B8 for <ace@ietf.org>; Tue, 2 Feb 2021 03:33:45 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 112BXfPB026797 for <ace@ietf.org>; Tue, 2 Feb 2021 12:33:41 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 71A46204BB3 for <ace@ietf.org>; Tue, 2 Feb 2021 12:33:41 +0100 (CET)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6824D204A3B for <ace@ietf.org>; Tue, 2 Feb 2021 12:33:41 +0100 (CET)
Received: from [10.14.0.67] ([10.14.0.67]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 112BXfQf021224 for <ace@ietf.org>; Tue, 2 Feb 2021 12:33:41 +0100
To: ace@ietf.org
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <347c90e4-ba17-653c-1479-c260d96eb801@gmail.com>
Date: Tue, 2 Feb 2021 12:33:40 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/pZxOvVEl_944d3V6lW2ahPlwWSg>
Subject: Re: [Ace] call for adoption for draft-marin-ace-wg-coap-eap
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Feb 2021 11:33:47 -0000

> Daniel Migault <mglt.ietf@gmail.com> Thu, 21 January 2021 13:13 UTC
> 
> Hi,
> 
> The charter approval by the IESG is expected to be approved in the
> coming weeks. In the meanwhile, this email starts a call for adoption
> on work that has been included in the charter. Of course, adoption is
> contingent on the rechartering succeeding.
> 
> The document called for adoption is draft-marin-ace-wg-coap-eap
> available here: 
> https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-07
> 
> Please state your opinion on whether this work should not or should
> be adopted by the WG and express your motivation for such a
> statement. The call for adoption closes on February 4.
> 
> Yours, Daniel
> 
> 
> -- Daniel Migault Ericsson
> 

Hi,

This is my first post to this list.

We agreed internally that we at CEA support the adoption of this draft.

We have a few comments:

> ·        §3 “two different sequence _flow_” (typo: ‘s’ missing);
> 
> ·        §3 “_should_ be valid”: I do not like the feeling of
> uncertainty given by this lowercase ‘should’. What would be the
> restraints to this statement? Which key-deriving methods would not be
> acceptable?
> 
> ·        Page 5 “_on the contrary_, if DTLS”. I would replace « on
> the contrary » with “on the other hand” or “alternatively”… DTLS is
> not the opposite of OSCORE ;)
> 
> ·        PANA RFC is referenced but not quoted. I have to admit that
> my knowledge of IETF edition rules is now almost inexistent, so maybe
> it is acceptable to reference background RFCs that one does not
> actually quote in the text;
> 
> ·        You could find worthwhile to quote RFC6677, which seems (I
> may be wrong) relevant to the topic you address.

Yours,

Alexandre PETRESCU