A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the EAP Method Update (EMU)
WG of the IETF.
Title : Tunnel Extensible Authentication Protocol (TEAP) Version 1
Author : Alan DeKok
Filename: d
This is the working group last call for draft-ietf-emu-rfc7170bis-05 [1].
Please review the draft and send comments to the list or open issues in
GitHub [2]. Further discussion on the open issues will be considered as
part of the last call. The last call ends March 24, 2023. The chairs would
app
Hi Joe,
First and foremost, I'd like to again thank Alan for taking this on.
Second, because I expect to have a few comments, to keep them separate,
I'll start different threads.
In Section 4.2.9, the beginning text reads:
The Request-Action TLV MAY be sent by both the peer and the server in
I'm sorry- the subject is wrong. The IMCK derivation IS clear. This is
related solely to Request-Action (doh!).
On 10.03.23 17:17, Eliot Lear wrote:
Hi Joe,
First and foremost, I'd like to again thank Alan for taking this on.
Second, because I expect to have a few comments, to keep them
sep
This is the second issue that I'd like to address:
As discussed early in the development of this document, TEAP currently
doesn't support a CSR Attributes TLV. I propose that it be added, and
that its form be the same used in EST (RFC 7030 and
draft-ietf-lamps-rfc7030-csrattrs-01) Section 4.5
On Fri, 10 Mar 2023, at 16:17, Eliot Lear wrote:
> In Section 4.2.9, the beginning text reads:
>
>> The Request-Action TLV MAY be sent by both the peer and the server in
>> response to a successful or failed Result TLV.
>
> I believe this text is overly restrictive, and should be relaxed to say:
>
