Thomas, thank you for your review. I have entered a No Objection ballot for
this document.
Lars
> On Jan 24, 2023, at 20:35, Thomas Fossati via Datatracker
> wrote:
>
> Reviewer: Thomas Fossati
> Review result: Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
>
Lars Eggert has entered the following ballot position for
draft-ietf-emu-tls-eap-types-11: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
John Scudder has entered the following ballot position for
draft-ietf-emu-tls-eap-types-11: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
On Feb 14, 2023, at 4:24 PM, John Scudder via Datatracker
wrote:
> ### Section 3
>
> ```
> Earlier TLS versions did not always send application data along with
> the Finished message. It was then possible for implementations to
> assume that a receipt of a Finished message also meant that
Hi Alan,
The first two edits sound good to me, no notes. On the last one —
> On Feb 14, 2023, at 5:11 PM, Alan DeKok wrote:
...
> It's left over bits from multiple edits. Perhaps:
>
> There MAY be
> additional protocol exchanges which could still cause failure, so we
> cannot mandate sending
On Feb 14, 2023, at 5:51 PM, John Scudder wrote:
> The RFC 2119-style MAY seems a little out of place, it seems like it’s
> expressing an expectation rather than giving permission to an implementation
> that the inner protocol is allowed to do certain things (which seems beyond
> the scope of t
