On 17/07/2019, 17:42, "Thomas Fossati" wrote:
> My suggestion is we move that section back and point to RRC for the
> "final" solution. This doesn't give complete internal coherency to
> conn-id -- which is indeed suboptimal -- but the recommendation to
> provide peer address update call-backs
Hiya,
Just spotted that:
opaque zeros[ESNIKeys.padded_length - length(sni)];
should I guess now be:
opaque zeros[ESNIKeys.padded_length - length(dns_name)];
And maybe s/PaddedServerNameList/PaddedDNSName/ would
also make sense.
Cheers,
S.
PS: sorry if this'd be easier to handle as a
The document s with the IESG, and it should soon be in IETF Last Call. I will
address these as early IETF Last Call comments when that happens.
Russ
> On Jul 18, 2019, at 12:01 PM, Hammell, Jonathan F
> wrote:
>
> <>Classification: UNCLASSIFIED
>
> I realize publication has been
Classification: UNCLASSIFIED
I realize publication has been requested for this draft, but I have a few
comments that the author might want to address, if still possible.
1. The draft says that if none of the PSKs provided by the client are
acceptable to the server, then the extension must be
