That is a fair point. I will make the update and submit a new draft.
Thank you for the feedback.
Ashley Kopman
>
> On Jul 25, 2022, at 4:25 PM, Russ Housley <hous...@vigilsec.com> wrote:
>
> 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
