On Wed, Nov 18, 2020 at 10:50 AM Lucas Pardue <[email protected]> wrote:
> Hi Behcet, > > On Wed, Nov 18, 2020 at 4:20 PM Behcet Sarikaya <[email protected]> > wrote: > >> >> >> On Wed, Nov 18, 2020 at 2:22 AM Magnus Westerlund < >> [email protected]> 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 >>> >>> >>>
