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
response to a successful or failed Result TLV.
I believe this text is overly restrictive, and should be relaxed to say:
The Request-Action TLV MAY be sent by both the peer and the server.
The reason for this is as follows: if the server notices that the client
certificate is expiring, or if the server otherwise has need of the
client renewing its certificate early (say due to impending change to
trust anchors), the server should be able to issue a Request-Action TLV
upon successful TLS hellos, without the need for a Result or
Intermediate-Result frame.
Thanks,
Eliot
On 10.03.23 16:58, Joseph Salowey wrote:
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 appreciate earlier reviews so we can plan to
resolve issues during our Monday meeting on the 27th.
Thanks,
Peter and Joe
[1] https://datatracker.ietf.org/doc/draft-ietf-emu-rfc7170bis
[2] https://github.com/emu-wg/rfc7170bis/issues
_______________________________________________
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
