[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS]  =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?=
From:       Benjamin Kaduk <kaduk () mit ! edu>
Date:       2018-07-25 15:08:02
Message-ID: 20180725150802.GS92448 () kduck ! kaduk ! org
[Download RAW message or body]

On Wed, Jul 25, 2018 at 07:32:17AM -0700, Mirja Kühlewind wrote:
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-tls-tls13-vectors-06: 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Why is it really necessary to publish the test vectors in an RFC?

Well, hopefully we can avoid being caught in a catch-22.  That is, a lot of
the time when processing-heavy (especially crypto-heavy) documents come
through, we ask for test vectors at IESG review if they are not already
present.  So in the case when the base document is already long, it seemed
pretty natural to keep the test vectors in an adjacent place and the same
format, just as a separate document to keep the individual document sizes
down.

So, I'm generally of the opinion that it's better to have test vectors than
to not; it provides concrete guidance in the case when the wording of the
spec is potentially unclear and it helps new implementations develop
interoperability during development instead of being presented with a vague
"it doesn't work" once all the pieces are implemented.  We could certainly
debate what the best place for documenting the test vectors is, but I think
there is both precedent and a reasonable set of advantages to including
them in the RFC series.

-Benjamin


[prev in list] [next in list] [prev in thread] [next in thread]