Hi Martin,
Thanks for pointing this out. I think Ben also mentioned this in his
review. I am not sure if it is necessary to add the type-code to the
label when it is already part of the label string as 'EAP_TLS'. Other
TLS based EAP methods should ideally register labels of the form
On Thu, Jan 7, 2021 at 4:39 PM Benjamin Kaduk wrote:
> On Mon, Jan 04, 2021 at 03:40:34PM -0800, Martin Duke via Datatracker
> wrote:
> > Martin Duke has entered the following ballot position for
> > draft-ietf-tls-external-psk-importer-06: Discuss
> >
> > When responding, please keep the
On Mon, Jan 04, 2021 at 03:40:34PM -0800, Martin Duke via Datatracker wrote:
> Martin Duke has entered the following ballot position for
> draft-ietf-tls-external-psk-importer-06: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the
Hi Joe,
Thanks for doing this, I think that this is a distinct improvement (and I will
take your word for the difficulties involved with further splits).
One point that I made poorly perhaps, and was dismissed, might be worth
restating:
MSK = TLS-Exporter("EXPORTER_EAP_TLS_MSK", Type-Code,
Adding one more to this list:
- Added text regarding the legacy_session_id field (#202)
Best,
Chris
On Mon, Jan 4, 2021, at 8:21 PM, Christopher Wood wrote:
> There are currently 12 open PRs [1] against the DTLS 1.3 specification
> generated in response to Ben's review [2]:
>
> - Require that
> On 7 Jan 2021, at 07.26, Benjamin Kaduk wrote:
>
> It seems like only QUIC internals would have to change, not TLS internals?
>
> My expectation is roughly that, if we were to compare the work needed to go
> from (has TLS 1.3 implementation) to (has QUIC implementation that uses
>
