Re: [Last-Call] Opsdir last call review of draft-ietf-quic-transport-32

[Behcet Sarikaya <[e-mail]>]

On Wed, Nov 18, 2020 at 10:50 AM Lucas Pardue <[e-mail]>
wrote:

> Hi Behcet,
>
> On Wed, Nov 18, 2020 at 4:20 PM Behcet Sarikaya <[e-mail]>
> wrote:
>
>>
>>
>> On Wed, Nov 18, 2020 at 2:22 AM Magnus Westerlund <
>> [e-mail]> wrote:
>>
>>> On Tue, 2020-11-17 at 10:34 -0600, Behcet Sarikaya wrote:
>>> >
>>> > I think this is a problem generally in Quic specs.
>>> > They are written for implementers.
>>> >
>>> > A protocol specification should not be an implementation spec.
>>> > I think this is a deep issue maybe most Quic people do not appreciate
>>> because
>>> > it seems those people are mostly implementers.
>>>
>>> As responsible AD I do want to respond to this. Protocol specification
>>> exists to
>>> enable implementation. And that it is written for implementors are
>>> actually
>>> great as it will avoid many interoperability issues. Other usage of the
>>> specification I think will not be greately challenged by the detail
>>> level. This
>>> is not a novel, it is a protocol specification. So I don't consider this
>>> an
>>> issue, rather the opposite.
>>>
>>>
>>
>> I am not sure. I think IESG could know. How many people that read
>> protocol RFCs
>> go ahead and implement them?
>> I for one read a lot of RFCs but I have never implemented protocols,
>> other teams do that, it is not my job
>>
>
>> Maybe many these days because QUIC is being deployed. But later on
>> the statistics could drastically change.
>> Also as we know from Software Engineering, the process does not go
>> direct, i.e read the RFC and  give it to the implementation team.
>>
>> In short, I think ADs, IESG should consider this issue seriously and I
>> believe in the end, spec view will win.
>> We need the implementation detail removed with a great thank you to the
>> editors.
>>  That said, I am not going to fight in this as I have no dog in this
>> fight :)
>>
>
> I have to agree with Magnus. The specs are not non-fiction accounts of
> technology or layperson PR-friendly nutshell soundbites. If you remove
> implementation detail there is no information for anyone to make
> interoperable implementations.
>
> There's a whole industry of folks that do a fantastic job of turning these
> very detailed specs into deployments, products, books, video and podcasts
> that suit end-users, explaining things more user-firendly terms. Dumbing
> down specification just duplicates that work and is a disservice to
> engineers. Rather than reading RFCs, I suggest people go and read something
> like Daniel Stenberg's "HTTP/3 explained" [1], Ilya Grigorik's
> "High-Performance Browser Networking", or get a large pot of coffee and
> watch the 12+ hours of Video-on-Demand content that I produced on the topic
> of QUIC & HTTP/3 [3].
>
>

Lucas,
Please stop this. I have not made any personal "attacks" like this to
anyone on this list or elsewhere in IETF.

I am an ex-academic who has written a book on Principles of Protocol
Engineering and Conformance Testing
in 1993 published by Ellis Horwood
which  basically discussed how to formally specify protocols (that time it
was OSI protocols, pre-IETF years) in a text book setting.

Behcet

> Cheers,
> Lucas
>
> [1] - https://daniel.haxx.se/http3-explained/
> [2] - https://hpbn.co/
> [3] - https://blog.cloudflare.com/last-call-for-quic/
>
>
>>
>>
>> Behcet
>>
>>> >From my perspective the QUIC documents are in the top percentile of
>>> documents
>>> when it comes to specification quality that I have seen during my soon 6
>>> years
>>> as AD from across the whole IETF.
>>>
>>> Cheers
>>>
>>> Magnus Westerlund
>>> TSV AD
>>>
>>>
>>>