RE: Add extension work to Interop matrix

["Lubashev, Igor" <[e-mail]>]

Lucas, I think you are worried that letters were used to identify required features of QUIC V1, and adding optional “extension” letters to the mix would cause confusion.  Is that correct?

A single matrix with letters proved to be an effective way to summarize and report on the interop, so it is pretty clear why people interested in implementing extensions want to record their progress in this way.  Would it make more sense to you if there was a clear separation of QUIC V1 feature interop from Extension interop results?  Like two matrices: “QUIC V1” and “Extensions”?


  *   Igor


From: Lucas Pardue <[e-mail]>

On Tue, Jan 7, 2020 at 6:49 PM Dmitri Tikhonov <[e-mail]<mailto:[e-mail]>> wrote:

I get the feeling we are talking past each other.  Do you not
acknowledge the evanescent nature of the Interop matrix

You want to impose artificial strictures on the way the Interop
results are recorded because it may scale poorly, but this argument
is invalid:  To "scale," we can simply choose to do record things
differently for the next Interop.

The standardisation process is iterative but to date we've followed a fairly rudimentary pattern where each incarnation of the matrix relates to a specific implementation draft, which in turn relates to some set of versioned drafts. The proposal changes the pattern to now consider extensions. Across the sheets we have little evidence of burning or substituted letters, so its not clear how people would read into such a occurrence.

The scaling problem is not invalid. Parsing the interop matrix, even in its current form, is not user-friendly, especially for those not actively engaged in the process.

We all share the matrix. Adding letters might help you but it doesn't help me.

Lucas


  - Dmitri.