One response inline. On Wed, Nov 18, 2020, 9:06 AM Behcet Sarikaya <[email protected]> wrote:
> > > 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. > Calling OSI "pre-IETF" is disingenuous. There were RFCs before the IETF itself was formalized, and there is a direct line of continuation for the culture of Internet standards going all the way back to RFC 1 from 1969. Core to this culture is specification involvement by implementers and fast feedback from running code. This is distinctly different from the classical engineering culture of standardization employed by bodies like the ISO, which lead to the OSI protocols. The undeniable success of the early ARPANET protocols and the eventual TCP/IP protocol and subsequent evolution of the Internet and networking in general is due to the difference in culture and practice of standardization. As Christian and others pointed out, QUIC as a working group and set of specifications embodies this ideal. The number and diversity of interoperating implementations is a testament to the quality and utility of the QUIC specifications. They may not match your expectations, but I would argue then that your expectations are not in line with what makes a successful RFC specification. > 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 >>>> >>> >>>>
