Hi Ben,
Thanks for your reply. But we understand may not be the same.
Since ACK messages are not retransmitted, I think they should not consume
message_seqs.
If an ACK really use a message_seq and it is lost in network, new handshake
records will
always use a larger message_seq than the peer expe
Sorry for my mistake.
The HelloVerifyRequest in the previous email should be replace with
"HelloRetryRequest".
On Mon, Dec 2, 2019 at 7:17 PM Xuan k wrote:
> Hi Ben,
>
> Thanks for your reply. But we understand may not be the same.
>
> Since ACK messages are not retransmitted, I think they sho
U
On Wed, Nov 27, 2019 at 11:16 PM Xuan k wrote:
> Hi Ekr,
>
> Thanks for your help.
>
> I have another question about the "message_seq" in section "6. Example of
> Handshake with Timeout and Retransmission".
> Could you please explain it?
>
> In the secion 6, the Client send message_seq = 0 in
Thanks David, understood.
It sounds that it would be easier to switch away from RSA to avoid the extra
complications of batching, but I understand that is not always possible. Given
that this is an Experimental draft, I am ok with the WG adopting it, given that
it has merit for some vendors’ us
On Mon, Dec 02, 2019 at 07:17:32PM +0800, Xuan k wrote:
> Hi Ben,
>
> Thanks for your reply. But we understand may not be the same.
>
> Since ACK messages are not retransmitted, I think they should not consume
> message_seqs.
> If an ACK really use a message_seq and it is lost in network, new han
Reviewer: Ines Robles
Review result: Ready
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information
