Message-ID: <9079b95c-ff82-4501-8f90-adfac6b5b2aa@inria.fr>
Date: Tue, 26 May 2026 16:15:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: draft-ietf-lake-app-profiles@ietf.org, lake-chairs@ietf.org,
 lake <lake@ietf.org>
References: 
 <177918251707.659690.4519691046419577095@dt-datatracker-7688897f84-l74h4>
Content-Language: en-US
From: Elsa Lopez Perez <elsa.lopez-perez@inria.fr>
In-Reply-To: 
 <177918251707.659690.4519691046419577095@dt-datatracker-7688897f84-l74h4>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID-Hash: BVJXJET7UH4VBTHN7WX2RAINR6QXFTLY
Precedence: list
Subject: =?utf-8?q?=5BLake=5D_Re=3A_WG_Last_Call=3A_draft-ietf-lake-app-profiles-04_?=
 =?utf-8?q?=28Ends_2026-06-02=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/lake/Fv0W_YstOf1EtYhz2DSGLWv9Ivg>

Hi all,

I have reviewed the document and support progressing it towards 
publication. A few comments:

- Same as was already mentioned by Yuxuan, the app_prof name and label 
means three different things depending on the context. Maybe it would be 
worth clarifying it or using a different name.

- EDHOC-PSK resumption introduces two new EDHOC Exporter Labels 
(TBD2/TBD3) with default output lengths. Is app-profiles' 
exporter_out_len intended to cover these? Moreover, is "supports PSK 
resumption" meant to be an advertisable profile capability?

Thanks for the work!

BR,

Elsa


On 5/19/26 11:21, Mališa Vučinić via Datatracker wrote:
> As discussed during the IETF 125 in Shenzhen, this message starts a WG
> last call for  draft-ietf-lake-app-profiles-04.
>
> This Working Group Last Call ends on 2026-06-02.
>
> Abstract:
>     The lightweight authenticated key exchange protocol Ephemeral Diffie-
>     Hellman Over COSE (EDHOC) requires certain parameters to be agreed
>     out-of-band, in order to ensure its successful completion.  To this
>     end, application profiles specify the intended use of EDHOC to allow
>     for the relevant processing and verifications to be made.  In order
>     to ensure the applicability of such parameters and information beyond
>     transport- or setup-specific scenarios, this document defines a
>     canonical, CBOR-based representation that can be used to describe,
>     distribute, and store EDHOC application profiles.  Furthermore, in
>     order to facilitate interoperability between EDHOC implementations
>     and support EDHOC extensibility for additional integrations, this
>     document defines a number of means to coordinate the use of EDHOC
>     application profiles.  Finally, this document defines a set of well-
>     known EDHOC application profiles.
>
> File can be retrieved from:
>
> Please review and indicate your support or objection to proceed with the
> publication of this document by replying to this email keeping lake@ietf.org
> in copy. Objections should be explained and suggestions to resolve them are
> highly appreciated.
>
> Authors, and WG participants in general, are reminded of the Intellectual
> Property Rights (IPR) disclosure obligations described in BCP 79 [1].
> Appropriate IPR disclosures required for full conformance with the provisions
> of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
> Sanctions available for application to violators of IETF IPR Policy can be
> found at [3].
>
> Thank you.
>
> [1] https://datatracker.ietf.org/doc/bcp78/
> [2] https://datatracker.ietf.org/doc/bcp79/
> [3] https://datatracker.ietf.org/doc/rfc6701/
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lake-app-profiles/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-lake-app-profiles-04.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lake-app-profiles-04
>