From nobody Wed Nov 18 09:05:52 2020 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0716F3A0CC1; Wed, 18 Nov 2020 09:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFYo7e21eh5n; Wed, 18 Nov 2020 09:05:49 -0800 (PST) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04A433A0CC4; Wed, 18 Nov 2020 09:05:48 -0800 (PST) Received: by mail-yb1-xb2f.google.com with SMTP id w5so2323838ybj.11; Wed, 18 Nov 2020 09:05:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=IingagdYCxoJhy7jbtONj2oVlOnDfEP0mpMHTT0xyEo=; b=Yh6T/sBiV1PAqdMknRkejj10V6KrAm+w4jpxKiYw2ge3ZJ68cinus5w+YZ07bZOjlM m6fblfeeTGrWqOsfmXTDLWBImJjNK1/9ppuTHJTw+pEdGxC+JEFk6L5YLxlKnMPO+95u 8K2RVP6D8VTPAXNYzAKNkejWIYIwMDzIq0OJsBEihsH0Ptxeh3rk3zMmhZwyPdCMJRRH fJQRxn97kyD8o5j4CaF8mYJCIQ8zEG5wfkvY5fVWmp/ThI3A3/DYCA6fD8HTgehKXFWg zMpdn7NcslsiJERDLJ9JH2IfJjpdd4F7GJ2dT9eV2pDgT+NyPMKyen1KPdJFnC1XRwxa wphg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=IingagdYCxoJhy7jbtONj2oVlOnDfEP0mpMHTT0xyEo=; b=mEoKGQKyH5a85m02FjIoyc8UwYSGSfvV/E38WPtsNsNgdMKtbR2WUHC7uT0YgULWOv ancqA7HX5p75I2VKDEs2hBB6e4E34RRJ42CQm+HDSZtGqbUiVrCQPt1/f77hUlwKK1wn Tixe91QSjCLGxjw3uKkIKNaYHa6pvSdiIO7+YvJFuvl26LY8TH4/ncUnnHUA96XgNfOd DIJxxvajc0ANvEF6PYoAHq+JnBQeLLtpFjG3cPqho8t6g95r2y2q4A5+XKS7vfcjvsra Cg4jkHDMGgMyP0U0mMxlOOseGpnBpyHLWqIeZAJODpqEp8wUHzX568yoqXR+s7lJcr75 oEGA== X-Gm-Message-State: AOAM530i3fLm4jmG3NnIHBNMyn+1swYwHHeXk7gWLQRpFW10Aq7oy24p 6R5CJd5h0wmf05whGePcnI3GsjiXh9Tzop/UhbI= X-Google-Smtp-Source: ABdhPJxc+BjIgQx/OoT4eDlMUgcp6lxPdcCVO1UrRmSYv2rkq9XMsrzWCHlDEOMmt7ENdM3L2Hw96V6Vlln/XKhXpBk= X-Received: by 2002:a05:6902:72e:: with SMTP id l14mr7551733ybt.175.1605719148131; Wed, 18 Nov 2020 09:05:48 -0800 (PST) MIME-Version: 1.0 References: <160563050450.18751.9577108468364180835@ietfa.amsl.com> <04e7357966734490f28f41a925f7be18f6c48050.camel@ericsson.com> In-Reply-To: Reply-To: sarikaya@ieee.org From: Behcet Sarikaya Date: Wed, 18 Nov 2020 11:05:36 -0600 Message-ID: Subject: Re: [Last-Call] Opsdir last call review of draft-ietf-quic-transport-32 To: Lucas Pardue Cc: Behcet Sarikaya , Magnus Westerlund , "draft-ietf-quic-transport.all@ietf.org" , "quic@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006ef8a005b4649f4b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 17:05:51 -0000 --0000000000006ef8a005b4649f4b Content-Type: text/plain; charset="UTF-8" On Wed, Nov 18, 2020 at 10:50 AM Lucas Pardue wrote: > Hi Behcet, > > On Wed, Nov 18, 2020 at 4:20 PM Behcet Sarikaya > wrote: > >> >> >> On Wed, Nov 18, 2020 at 2:22 AM Magnus Westerlund < >> magnus.westerlund@ericsson.com> 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 >>> >>> >>> --0000000000006ef8a005b4649f4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Nov 18, 2020 at 10:50 AM Luca= s Pardue <lucaspardue.24.7= @gmail.com> wrote:
= Hi Behcet,

On Wed, Nov 18, 2020 at 4:20 PM Behcet Sarikaya <sarikaya2012@gmail.com= > wrote:


On Wed, Nov 18, 2020 at 2:22 AM Magnus Westerlund <magnus.westerlund@erics= son.com> wrote:
On Tue, 2020-11-17 at 10:3= 4 -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 exis= ts 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 thi= s an
issue, rather the opposite.



I am not sure. I think = IESG could know. How many people that read protocol RFCs=C2=A0
go= ahead and implement them?=C2=A0
I for=C2=A0one read a lot of RFC= s but I have never implemented protocols, other teams do that, it is not my= job

Maybe many these days because QUI= C is being deployed. But later on=C2=A0
the statistics could dras= tically change.=C2=A0
Also as we know from Software Engineering, = the process does not go direct, i.e read the RFC and =C2=A0give it to the i= mplementation team.

In short, I think ADs, IESG sh= ould consider this issue seriously and I believe in the end, spec view will= win.
We need the implementation detail removed with a great than= k you to the editors.
=C2=A0That 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-fict= ion accounts of technology or layperson PR-friendly nutshell soundbites. If= you remove implementation detail there is no information for anyone to mak= e interoperable implementations.

There's a whole industry of fol= ks that do a fantastic job of turning these very detailed specs into deploy= ments, 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 su= ggest people go and read something like Daniel Stenberg's "HTTP/3 = explained" [1], Ilya Grigorik's "High-Performance Browser Net= working", or get a large pot of coffee and watch the 12+ hours of Vide= o-on-Demand content that I produced on the topic of QUIC & HTTP/3 [3].<= br>


=
Lucas,=C2=A0
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 bo= ok on Principles=C2=A0of Protocol Engineering and Conformance=C2=A0Testing<= /div>
in 1993 published by Ellis Horwood
which =C2=A0basicall= y discussed how to formally specify protocols (that time it was OSI protoco= ls, pre-IETF years) in a text book setting.

Behcet=
Cheers,
Lucas

=C2=A0


Behcet<= /div>
>From my perspective the QUIC documents are in the top percentile of doc= uments
when it comes to specification quality that I have seen during my soon 6 ye= ars
as AD from across the whole IETF.

Cheers

Magnus Westerlund
TSV AD


--0000000000006ef8a005b4649f4b--