I was thinking the same thing during the presentation. An extension for SCVP
seems fine to me. Then in the future, if another validation comes along some
day, a new extension can be assigned for that protocol.
Russ
> On Jul 25, 2022, at 4:13 PM, Martin Thomson <m...@lowentropy.net> wrote:
>
> Take this:
>
> struct {
> PathValidationType path_validation_type;
> select (path_validation_type) {
> case scvp: SCVPValidationRequest;
> } request;
> } PathValidationRequest;
> enum { scvp(1), (255) } PathValidationType;
>
> This adds a layer of extensibility that doesn't do a lot. Please consider
> making this less generic. If we want a different validation design, then
> another extension can be defined. We have a poor track record of being able
> to use these nested extension points and it will be more efficient to just
> put the SCVP pieces in their own extension.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
