From nobody Sat Aug 10 21:48:17 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2615912086B; Sat, 10 Aug 2019 21:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 uUvxX_4t5xWg; Sat, 10 Aug 2019 21:47:21 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 1DE78120963; Sat, 10 Aug 2019 18:47:03 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id f17so11677400otq.4; Sat, 10 Aug 2019 18:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wm1pxdiIamoK8SmG37h3KjseWrN4IqXZiAEjZ/8hNPg=; b=YgfNP5QYQiq+q8COAsWTLu6MAv2b+XVFujOdWrmUb4IeBoT4kGUuevXvSBlYVZLud9 Vc8/QBkzo2Rzyo1AQYiDhEgazuO9XKOOn+6RmU00Drkkq5bpdczmq6Sz7b0zSQPWt69i TKIIM9T7XnqOnyrjHOhHQmk+x6VHrV8H2emXyMsrGL7b4htaRJVOXY2b/n1vdymDf5Z4 /gT0z7fRR7opoC6+nZPdhutsnSPh4qEpd6gSbkCG57bbpcYIAdbzcytcyn9qzrXkewGY 6ojqiKEo50t5JHkjodV6H5q6Y3U30jZwxXBf1DuZmszWF7RxTAYiMW4OLQMNhRv2SUma pdaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wm1pxdiIamoK8SmG37h3KjseWrN4IqXZiAEjZ/8hNPg=; b=aQpKSvl5IPJGehg358It+gwaqq0KMGFpWiYKA+UNHqOP1duqgXf2UAJyeN84ENkWgW aVfa3n80aDNUh72vl8s5R1c/PqxikryhoERwAX50jcOQMUuyf1aF9XkcNjNGs75o2aWv 14jg97Cn+iAWZBBNCBv+oQh7gkxuObqhNduGg9uQvKsYbvfisF94jrbXXMTj/BZn8egn cDEOU60xzBvdSIZB16Xov0N/rLGnB9AS2DbJK2bxdZsgF026oBb6RJWtM3bQYGDOLk// y+zSGpiJQZ1s1TyETdyFM1y9ASp33CGLzEK1BfEKezN2Z9mmz8U8Hf8PDDwDaXONB2po mXnA== X-Gm-Message-State: APjAAAWM/BDn8dc8VFTJf/TXnX1BnKw08vuR+EULp9LiuIKBNo/te7lb 3+qRYxaMsN+ltZJO6/JWkjRW0hhrR/hqWTSTUUw= X-Google-Smtp-Source: APXvYqyMz+5iIeR6Vkv6+ZMq4pcs1F+N0ggZFr6AgsL7J3JS5vE9r3r6dr8RmbiojHzzYQ7T7UEHVqo+iQC5F4Y1pZI= X-Received: by 2002:a54:4703:: with SMTP id k3mr10379358oik.143.1565488021266; Sat, 10 Aug 2019 18:47:01 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:4b14:0:0:0:0:0 with HTTP; Sat, 10 Aug 2019 18:47:00 -0700 (PDT) In-Reply-To: References: <791b33b8-4696-f69c-aca3-8838b2caafd8@sectigo.com> <77F8C1C2AAB5AE251285436F@172.20.2.211> <30deb3a8-c24f-1f38-2701-aa1d68b6adba@nostrum.com> From: Guntur Wiseno Putra Date: Sun, 11 Aug 2019 08:47:00 +0700 Message-ID: To: Adam Roach Cc: John C Klensin , "art@ietf.org" , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006865d9058fcd95e4" Archived-At: Subject: [arch-d] BCP 190, draft-nottingham-for-the-users, and a generalization X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2019 04:48:16 -0000 --0000000000006865d9058fcd95e4 Content-Type: text/plain; charset="UTF-8" Dear architecture-discuss, Such co-presences of which architecture is part of: if we attempt to think of its relation with other human experiences on poetry, on poetics, on a spirit invoked to make comprehensible a poetic fact, to get toward an understanding of cyberspace architecture, of "Liquid Architecture in Cyberspace" (Marcos Novak, 1991) I suggested as a reading to public-informationarchitecture@w3.org at which there is the web-address to the Novak's work (posted at 12 May 2019): http://www.w3.org/mid/CAKi_AEu%252BK6XUb94zR7-9fQDq0Hy9JP0ZyT5em5Tg9gBMJh0Aiw@mail.gmail.com;list=public-informationarchitecture Regard, Guntur Wiseno Putra Pada Rabu, 24 Juli 2019, Guntur Wiseno Putra menulis: > Dear architecture-discuss, > & John, > > To share what might be inspiring... > > In order to propose what should be understood as "concept", "percept" & > "affect", thus as "philosophy" & "art", Deleuze & Guattari ("What is > Philosophy?") mentioned architecture as the first art as art begins with > house: that of which "the most scientific architecture continually produces > and unifies planes and sections... it could be defined as "frame" with a > connection among various frames oriented differently, applied to other > arts...(There is) a composite system consisting of points and > counterpoints... (there is) a matter of sensations (percepts and affects) > combined... (While) the system still needs a composition plane run > "deframing" opening ways from house territory to city-cosmos, the system in > which there are cosmic forces to create new affects...". > > There is "asthetic composition" as the working of sensation which is, so > they said, the definition of art... > > Regard, > Guntur Wiseno Putra > > Pada Selasa, 23 Juli 2019, Adam Roach menulis: > >> John -- >> >> It's going to take a while for me to formulate my thoughts around what >> you say below. To make sure I understand the class of constraints you're >> concerned about below, can you clarify whether you think they apply to: >> >> - Documents like BCP 200, RFC 2804, and BCP 188? >> - Documents like BCP 9 and BCP 92? >> - Documents like BCP 25, BCP 54, and BCP 83? >> >> You might see an unstated agenda in the categories of documents I list >> above, so I'll state it explicitly: in the general case, one person's >> important protections against a tragedy of the commons is another person's >> annoying impediment to be ignored and defeated. I get that not all of the >> above read on protocol design; but they do share the common feature that >> they've gone through the IETF consensus process (at least to the degree >> that such a process existed at the time of their respective publications). >> If we're going to carefully parse out the meanings of some of them as the >> will of the community while treating others as light guidelines to be >> ignored when they become cumbersome, we're going to need to agree on a >> pretty bright line that divides those categories. >> >> /a >> >> On 7/23/19 08:37, John C Klensin wrote: >> >> (copying architecture-discuss because the comment I'm about to >> make is an architectural issue and because >> draft-nottingham-for-the-users is under discussion there.) >> >> >> A late colleague, much loved by some of us, used to claim (much >> more elegantly than I can manage) that one of the reasons the >> ARPANET and then the Internet protocols had succeeded and much >> of what was seen as competitive alternatives had not, was that >> our efforts focused on pragmatic, working protocols and >> implementations. >> >> The other folks had developed a culture of formalisms, models, >> and stated design principles. They then tried to develop >> protocols that fit into the boxes and categories of those >> formalisms, models, and design principles. When they >> discovered that something didn't fit, they needed to either >> invent kludges or other ways of getting square pegs into round >> holes, go back and revise models and guidance before moving >> forward, or consider and make exceptions (which often required >> first figuring out how to make an exception and developing >> procedures for that). >> >> One difficulty is that the above can waste a lot of time. >> Another is that it can distort protocol design, if only because >> forcing square pegs into round holes tends to be hard on both >> the pegs and the holes. >> >> In many or most fields of application, the nature of engineering >> involves seeing and understanding a range of tradeoffs and then >> doing design work that reflects a carefully-chosen balance among >> them. Give design elegance absolute priority over structural >> issues and buildings and bridges fall down. IMO, we need to >> think, and keep thinking, about systems and tradeoffs. That, in >> turn, means that statements like these that can be interpreted >> in absolute terms, even if we mostly agree with them, should be >> packaged as general guidelines and not BCPs to which everything >> done in the future is required to either conform or to try to >> figure out how to appeal to a higher authority. >> >> I'm not at all convinced that the proposal that was summarized >> an ARTAREA yesterday and that is seen as requiring an exception >> to BCP 190 is a good idea. But I think our time would be better >> spent, and the Internet more efficiently made better, discussing >> the strengths, weaknesses, and alternatives to that idea rather >> than debating the reach and appropriateness of BCP 190 under >> various circumstances. Long term and more generally, I think >> that suggests seeing BCP 190 not as a particular set of >> principles and rules but as an example of something we don't >> want to do to ourselves again as a BCP (or as something that >> gets enough of an IAB stamp of approval that people will later >> argue MUST (or SHOULD) be conformed to. Again, restated as >> general guidance with the assumption that there will be >> exceptions and cases not considered, I don't have much of a >> problem. If that shoe fits draft-nottingham-for-the-users, >> so be it. >> >> john >> >> p.s. I don't mean to pick on Mark here. While these two >> documents coming up at the same time was handy, I think the >> problem is general and that there are far worse examples >> (examples of which he is not an author) than either of them. >> >> _______________________________________________ >> art mailing listart@ietf.orghttps://www.ietf.org/mailman/listinfo/art >> >> >> --0000000000006865d9058fcd95e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss,

Such co-presences of which ar= chitecture is part of: if we attempt to think of its relation with other hu= man experiences on poetry, on poetics, on a spirit invoked to make comprehe= nsible a poetic fact, to get toward an understanding of cyberspace architec= ture, of "Liquid Architecture in Cyberspace" (Marcos Novak, 1991)=


Regard,

Guntur Wiseno = Putra

Pada Rabu, 24 Juli 2019, Guntur Wiseno Putra <gsenopu@gmail.com> menulis= :
Dear architecture-discuss,
& Jo= hn,

To share what might be inspiring...

In order to propose what should be understood as "con= cept", "percept" & "affect", thus as "phi= losophy" & "art", Deleuze & Guattari ("What is = Philosophy?") mentioned architecture as the first art as art begins wi= th house: that of which "the most scientific architecture continually = produces and unifies planes and sections... it could be defined as "fr= ame" with a connection among various frames oriented differently, appl= ied to other arts...(There is) a composite system consisting of points and = counterpoints... (there is) a matter of sensations (percepts and affects) c= ombined... (While) the system still needs a composition plane run "def= raming" opening ways from house territory to city-cosmos, the system i= n which there are cosmic forces to create new affects...".
<= br>
There is "asthetic composition" as the working of s= ensation which is, so they said, the definition of art...

Regard,
Guntur Wiseno Putra

Pada Selasa, 23 Juli 2= 019, Adam Roach <a= dam@nostrum.com> menulis:
=20 =20 =20
John --

It's going to take a while for me to formulate my thoughts around what you say below. To make sure I understand the class of constraints you're concerned about below, can you clarify whether you think they apply to:
  • Documents like BCP 200, RFC 2804, and BCP 188?
  • Documents like BCP 9 and BCP 92?
  • Documents like BCP 25, BCP 54, and BCP 83?

You might see an unstated agenda in the categories of documents I list above, so I'll state it explicitly: in the general case, one person's important protections against a tragedy of the commons is another person's annoying impediment to be ignored and defeated. I get that not all of the above read on protocol design; but they do share the common feature that they've gone through the IETF consensus process (at least to the degree that such a process existed at the time of their respective publications). If we're going to carefully parse out the meanings of some of them as the will of the community while treating others as light guidelines to be ignored when they become cumbersome, we're going to need to agree on a pretty bright line that divides those categories.

/a


On 7/23/19 08:37, John C Klensin wrote:
(copying architecture-discuss because the comment I'm about =
to
make is an architectural issue and because
draft-nottingham-for-the-users is under discussion there.)


A late colleague, much loved by some of us, used to claim (much
more elegantly than I can manage) that one of the reasons the
ARPANET and then the Internet protocols had succeeded and much
of what was seen as competitive alternatives had not, was that
our efforts focused on pragmatic, working protocols and
implementations. =20

The other folks had developed a culture of formalisms, models,
and stated design principles.  They then tried to develop
protocols that fit into the boxes and categories of those
formalisms, models, and design principles.    When they
discovered that something didn't fit, they needed to either
invent kludges or other ways of getting square pegs into round
holes, go back and revise models and guidance before moving
forward, or consider and make exceptions (which often required
first figuring out how to make an exception and developing
procedures for that).

One difficulty is that the above can waste a lot of time.
Another is that it can distort protocol design, if only because
forcing square pegs into round holes tends to be hard on both
the pegs and the holes.

In many or most fields of application, the nature of engineering
involves seeing and understanding a range of tradeoffs and then
doing design work that reflects a carefully-chosen balance among
them.  Give design elegance absolute priority over structural
issues and buildings and bridges fall down.  IMO, we need to
think, and keep thinking, about systems and tradeoffs.  That, in
turn, means that statements like these that can be interpreted
in absolute terms, even if we mostly agree with them, should be
packaged as general guidelines and not BCPs to which everything
done in the future is required to either conform or to try to
figure out how to appeal to a higher authority.

I'm not at all convinced that the proposal that was summarized
an ARTAREA yesterday and that is seen as requiring an exception
to BCP 190 is a good idea.  But I think our time would be better
spent, and the Internet more efficiently made better, discussing
the strengths, weaknesses, and alternatives to that idea rather
than debating the reach and appropriateness of BCP 190 under
various circumstances.   Long term and more generally, I think
that suggests seeing BCP 190 not as a particular set of
principles and rules but as an example of something we don't
want to do to ourselves again as a BCP (or as something that
gets enough of an IAB stamp of approval that people will later
argue MUST (or SHOULD) be conformed to.  Again, restated as
general guidance with the assumption that there will be
exceptions and cases not considered, I don't have much of a
problem.    If that shoe fits  draft-nottingham-for-the-users,
so be it.

   john

p.s. I don't mean to pick on Mark here.   While these two
documents coming up at the same time was handy, I think the
problem is general and that there are far worse examples
(examples of which he is not an author) than either of them.

_______________________________________________
art mailing list
art@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/art


--0000000000006865d9058fcd95e4-- From nobody Sat Aug 10 23:37:54 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADD412084F; Sat, 10 Aug 2019 23:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 WyqjnJV69LXV; Sat, 10 Aug 2019 23:36:51 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 456FF120895; Sat, 10 Aug 2019 20:06:42 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id f17so11991289otq.4; Sat, 10 Aug 2019 20:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YNi1tLaD+tL97L6kx6ITpUjBB7XP5loFJ/mPxRcIFjg=; b=UVfDQ3ZijbTnsnUDAuywChfm5hTfzvR2+Atc3Kvdx2oCMLGX6+R3rfBOaHtVGzS5BV QW6yt7zF4YRYLQBZ2JCQHAZdUBmbPGx3hQ8JgpQpEr7++deV6+pDRD95SyqUUYAvb6vM VTXv4+XBouhjRmhYqYZ/PljSnUaQzXeKH27aucc76sj8sxvpj9DcA5nAgQ0jW+2mMMqO 27mCdlGnb3xELd4p8ZcT4pDJ6zgOtxZqoERyMTmh4eN55is//iu71SeQQM1lAeOMlVHh xl6EhFzqVaBxpbSAW+cK2n+jyN6udd3WXsu71f7Gefc4NZCJ9ao6xWXsy2gRL21VR/ng XmEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YNi1tLaD+tL97L6kx6ITpUjBB7XP5loFJ/mPxRcIFjg=; b=lD+irMAgXBKqTKRFyI3H6Bx3fmwMf2vp3sXCkaRyVimANZBWkPx63CqWeWLzSqVY2d t+TT71uSrfkI5LjmDueZtJ0A+EOdeYBI1mWLZpd3Yk/L4/NYISPn05S2TRETEEy+nPUn BWr/RQSJ13q2dwRCHgT8+ruWm4cHMjHQ9Gofqct0ZzszcXEdNHWGjug0wIvgtfTw9hLW RoupmfyQPf1YTvNZ2wIpMYfInxJYcsM/vz8oy6q8dcK428hgyG1gF63sCdXf6RFRyS7U 5woDJi2ncHOZq/+Fp797oKydB5xxhfkCzcjx33z8ulj6ryWB+bN2b2XQnLhFq+Y/tcG0 us9w== X-Gm-Message-State: APjAAAXxwfxc90Is3zhjSaB8AkKoMFc0cDo9JqBsj55Cv6XPisLVEAC+ IxrafHXvfxxYRpn9X3hi8Q36w/iyNvFbKcihBvY= X-Google-Smtp-Source: APXvYqye9SrId5sA0I4wgPRn+CjjgyC9hbiTzAQJnYE8dKoNllMIH3p+FhlwZK2DsndYS4VMHkgqo4/JDXezgXUqp5U= X-Received: by 2002:aca:b104:: with SMTP id a4mr10314516oif.90.1565492801328; Sat, 10 Aug 2019 20:06:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:4b14:0:0:0:0:0 with HTTP; Sat, 10 Aug 2019 20:06:40 -0700 (PDT) In-Reply-To: References: <791b33b8-4696-f69c-aca3-8838b2caafd8@sectigo.com> <77F8C1C2AAB5AE251285436F@172.20.2.211> <30deb3a8-c24f-1f38-2701-aa1d68b6adba@nostrum.com> From: Guntur Wiseno Putra Date: Sun, 11 Aug 2019 10:06:40 +0700 Message-ID: To: Adam Roach Cc: John C Klensin , "art@ietf.org" , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="000000000000525b10058fceb259" Archived-At: Subject: [arch-d] BCP 190, draft-nottingham-for-the-users, and a generalization X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2019 06:37:48 -0000 --000000000000525b10058fceb259 Content-Type: text/plain; charset="UTF-8" Dear architecture-discuss, An alternative link to the posting on Marcos Nocak'S "Liquid Architecture in Cyberspace" at public@informationarchitecture@w3.org I mentioned earlier is https://lists.w3.org/Archives/Public/public-informationarchitecture/2019May/0000.html (which was "403 Forbidden: Request forbidden by administrative rules" the last time I checked up minutes ago) Or, if going directly toward the text: https:///www.evl.uic.edu/datsoupi/coding/readings/Marcos_Novak_ Liquid.pdf Thank to Martin Dodge for suggesting Marcos Novak's architecture in www.cybergeography.org bringing me to Daria Tsoupukiva's lecture providing the reading... Regard, Gubtur Wiseno Putra Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra menulis: > Dear architecture-discuss, > > Such co-presences of which architecture is part of: if we attempt to think > of its relation with other human experiences on poetry, on poetics, on a > spirit invoked to make comprehensible a poetic fact, to get toward an > understanding of cyberspace architecture, of "Liquid Architecture in > Cyberspace" (Marcos Novak, 1991) > > I suggested as a reading to public-informationarchitecture@w3.org at > which there is the web-address to the Novak's work (posted at 12 May 2019): > > http://www.w3.org/mid/CAKi_AEu%252BK6XUb94zR7-9fQDq0Hy9JP0Zy > T5em5Tg9gBMJh0Aiw@mail.gmail.com;list=public-informationarchitecture > Regard, > > Guntur Wiseno Putra > > Pada Rabu, 24 Juli 2019, Guntur Wiseno Putra menulis: > >> Dear architecture-discuss, >> & John, >> >> To share what might be inspiring... >> >> In order to propose what should be understood as "concept", "percept" & >> "affect", thus as "philosophy" & "art", Deleuze & Guattari ("What is >> Philosophy?") mentioned architecture as the first art as art begins with >> house: that of which "the most scientific architecture continually produces >> and unifies planes and sections... it could be defined as "frame" with a >> connection among various frames oriented differently, applied to other >> arts...(There is) a composite system consisting of points and >> counterpoints... (there is) a matter of sensations (percepts and affects) >> combined... (While) the system still needs a composition plane run >> "deframing" opening ways from house territory to city-cosmos, the system in >> which there are cosmic forces to create new affects...". >> >> There is "asthetic composition" as the working of sensation which is, so >> they said, the definition of art... >> >> Regard, >> Guntur Wiseno Putra >> >> Pada Selasa, 23 Juli 2019, Adam Roach menulis: >> >>> John -- >>> >>> It's going to take a while for me to formulate my thoughts around what >>> you say below. To make sure I understand the class of constraints you're >>> concerned about below, can you clarify whether you think they apply to: >>> >>> - Documents like BCP 200, RFC 2804, and BCP 188? >>> - Documents like BCP 9 and BCP 92? >>> - Documents like BCP 25, BCP 54, and BCP 83? >>> >>> You might see an unstated agenda in the categories of documents I list >>> above, so I'll state it explicitly: in the general case, one person's >>> important protections against a tragedy of the commons is another person's >>> annoying impediment to be ignored and defeated. I get that not all of the >>> above read on protocol design; but they do share the common feature that >>> they've gone through the IETF consensus process (at least to the degree >>> that such a process existed at the time of their respective publications). >>> If we're going to carefully parse out the meanings of some of them as the >>> will of the community while treating others as light guidelines to be >>> ignored when they become cumbersome, we're going to need to agree on a >>> pretty bright line that divides those categories. >>> >>> /a >>> >>> On 7/23/19 08:37, John C Klensin wrote: >>> >>> (copying architecture-discuss because the comment I'm about to >>> make is an architectural issue and because >>> draft-nottingham-for-the-users is under discussion there.) >>> >>> >>> A late colleague, much loved by some of us, used to claim (much >>> more elegantly than I can manage) that one of the reasons the >>> ARPANET and then the Internet protocols had succeeded and much >>> of what was seen as competitive alternatives had not, was that >>> our efforts focused on pragmatic, working protocols and >>> implementations. >>> >>> The other folks had developed a culture of formalisms, models, >>> and stated design principles. They then tried to develop >>> protocols that fit into the boxes and categories of those >>> formalisms, models, and design principles. When they >>> discovered that something didn't fit, they needed to either >>> invent kludges or other ways of getting square pegs into round >>> holes, go back and revise models and guidance before moving >>> forward, or consider and make exceptions (which often required >>> first figuring out how to make an exception and developing >>> procedures for that). >>> >>> One difficulty is that the above can waste a lot of time. >>> Another is that it can distort protocol design, if only because >>> forcing square pegs into round holes tends to be hard on both >>> the pegs and the holes. >>> >>> In many or most fields of application, the nature of engineering >>> involves seeing and understanding a range of tradeoffs and then >>> doing design work that reflects a carefully-chosen balance among >>> them. Give design elegance absolute priority over structural >>> issues and buildings and bridges fall down. IMO, we need to >>> think, and keep thinking, about systems and tradeoffs. That, in >>> turn, means that statements like these that can be interpreted >>> in absolute terms, even if we mostly agree with them, should be >>> packaged as general guidelines and not BCPs to which everything >>> done in the future is required to either conform or to try to >>> figure out how to appeal to a higher authority. >>> >>> I'm not at all convinced that the proposal that was summarized >>> an ARTAREA yesterday and that is seen as requiring an exception >>> to BCP 190 is a good idea. But I think our time would be better >>> spent, and the Internet more efficiently made better, discussing >>> the strengths, weaknesses, and alternatives to that idea rather >>> than debating the reach and appropriateness of BCP 190 under >>> various circumstances. Long term and more generally, I think >>> that suggests seeing BCP 190 not as a particular set of >>> principles and rules but as an example of something we don't >>> want to do to ourselves again as a BCP (or as something that >>> gets enough of an IAB stamp of approval that people will later >>> argue MUST (or SHOULD) be conformed to. Again, restated as >>> general guidance with the assumption that there will be >>> exceptions and cases not considered, I don't have much of a >>> problem. If that shoe fits draft-nottingham-for-the-users, >>> so be it. >>> >>> john >>> >>> p.s. I don't mean to pick on Mark here. While these two >>> documents coming up at the same time was handy, I think the >>> problem is general and that there are far worse examples >>> (examples of which he is not an author) than either of them. >>> >>> _______________________________________________ >>> art mailing listart@ietf.orghttps://www.ietf.org/mailman/listinfo/art >>> >>> >>> --000000000000525b10058fceb259 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss,

An alternative link to the po= sting on Marcos Nocak'S "Liquid Architecture in Cyberspace" a= t public@informationarchitecture@w3.org=C2=A0 I mentioned earlier is


(which was = "403 Forbidden: Request forbidden by administrative rules" the la= st time I checked up minutes ago)

Or, if going dir= ectly toward the text:


=
Thank to Martin Dodge for suggesting Marcos Novak's architecture i= n www.cybergeography.org brin= ging me to Daria Tsoupukiva's lecture providing the reading...

Regard,
Gubtur Wiseno Putra

Pada Minggu, = 11 Agustus 2019, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
Dear architecture-discuss,

Such co-presen= ces of which architecture is part of: if we attempt to think of its relatio= n with other human experiences on poetry, on poetics, on a spirit invoked t= o make comprehensible a poetic fact, to get toward an understanding of cybe= rspace architecture, of "Liquid Architecture in Cyberspace" (Marc= os Novak, 1991)

I suggested as a reading to public= -informationarchitecture@w3.org at which there is the web-address = to the Novak's work (posted at 12 May 2019):

<= a href=3D"http://www.w3.org/mid/CAKi_AEu%252BK6XUb94zR7-9fQDq0Hy9JP0ZyT5em5= Tg9gBMJh0Aiw@mail.gmail.com;list=3Dpublic-informationarchitecture" target= =3D"_blank">http://www.w3.org/mid/CAKi_AEu%252BK6XUb94zR7-9fQDq0Hy9JP0= ZyT5em5Tg9gBMJh0Aiw@mail.gmail.com;list=3Dpublic-informationarchitecture
Regard,

Guntur Wise= no Putra

Pada Rabu, 24 Juli 2019, Guntur Wiseno Putra <gsenopu@gmail.com> menu= lis:
Dear architecture-discuss,
&= John,

To share what might be inspiring...
=

In order to propose what should be understood as "= concept", "percept" & "affect", thus as "= philosophy" & "art", Deleuze & Guattari ("What = is Philosophy?") mentioned architecture as the first art as art begins= with house: that of which "the most scientific architecture continual= ly produces and unifies planes and sections... it could be defined as "= ;frame" with a connection among various frames oriented differently, a= pplied to other arts...(There is) a composite system consisting of points a= nd counterpoints... (there is) a matter of sensations (percepts and affects= ) combined... (While) the system still needs a composition plane run "= deframing" opening ways from house territory to city-cosmos, the syste= m in which there are cosmic forces to create new affects...".

There is "asthetic composition" as the working o= f sensation which is, so they said, the definition of art...

=
Regard,
Guntur Wiseno Putra

Pada Selasa, 23 Jul= i 2019, Adam Roach <adam@nostrum.com> menulis:
=20 =20 =20
John --

It's going to take a while for me to formulate my thoughts around what you say below. To make sure I understand the class of constraints you're concerned about below, can you clarify whether you think they apply to:
  • Documents like BCP 200, RFC 2804, and BCP 188?
  • Documents like BCP 9 and BCP 92?
  • Documents like BCP 25, BCP 54, and BCP 83?

You might see an unstated agenda in the categories of documents I list above, so I'll state it explicitly: in the general case, one person's important protections against a tragedy of the commons is another person's annoying impediment to be ignored and defeated. I get that not all of the above read on protocol design; but they do share the common feature that they've gone through the IETF consensus process (at least to the degree that such a process existed at the time of their respective publications). If we're going to carefully parse out the meanings of some of them as the will of the community while treating others as light guidelines to be ignored when they become cumbersome, we're going to need to agree on a pretty bright line that divides those categories.

/a


On 7/23/19 08:37, John C Klensin wrote:
(copying architecture-discuss because the comment I'm about =
to
make is an architectural issue and because
draft-nottingham-for-the-users is under discussion there.)


A late colleague, much loved by some of us, used to claim (much
more elegantly than I can manage) that one of the reasons the
ARPANET and then the Internet protocols had succeeded and much
of what was seen as competitive alternatives had not, was that
our efforts focused on pragmatic, working protocols and
implementations. =20

The other folks had developed a culture of formalisms, models,
and stated design principles.  They then tried to develop
protocols that fit into the boxes and categories of those
formalisms, models, and design principles.    When they
discovered that something didn't fit, they needed to either
invent kludges or other ways of getting square pegs into round
holes, go back and revise models and guidance before moving
forward, or consider and make exceptions (which often required
first figuring out how to make an exception and developing
procedures for that).

One difficulty is that the above can waste a lot of time.
Another is that it can distort protocol design, if only because
forcing square pegs into round holes tends to be hard on both
the pegs and the holes.

In many or most fields of application, the nature of engineering
involves seeing and understanding a range of tradeoffs and then
doing design work that reflects a carefully-chosen balance among
them.  Give design elegance absolute priority over structural
issues and buildings and bridges fall down.  IMO, we need to
think, and keep thinking, about systems and tradeoffs.  That, in
turn, means that statements like these that can be interpreted
in absolute terms, even if we mostly agree with them, should be
packaged as general guidelines and not BCPs to which everything
done in the future is required to either conform or to try to
figure out how to appeal to a higher authority.

I'm not at all convinced that the proposal that was summarized
an ARTAREA yesterday and that is seen as requiring an exception
to BCP 190 is a good idea.  But I think our time would be better
spent, and the Internet more efficiently made better, discussing
the strengths, weaknesses, and alternatives to that idea rather
than debating the reach and appropriateness of BCP 190 under
various circumstances.   Long term and more generally, I think
that suggests seeing BCP 190 not as a particular set of
principles and rules but as an example of something we don't
want to do to ourselves again as a BCP (or as something that
gets enough of an IAB stamp of approval that people will later
argue MUST (or SHOULD) be conformed to.  Again, restated as
general guidance with the assumption that there will be
exceptions and cases not considered, I don't have much of a
problem.    If that shoe fits  draft-nottingham-for-the-users,
so be it.

   john

p.s. I don't mean to pick on Mark here.   While these two
documents coming up at the same time was handy, I think the
problem is general and that there are far worse examples
(examples of which he is not an author) than either of them.

_______________________________________________
art mailing list
art@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/art


--000000000000525b10058fceb259-- From nobody Sun Aug 11 00:01:09 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0AF9120A88; Sun, 11 Aug 2019 00:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 aJYiJwHr9eqR; Sun, 11 Aug 2019 00:00:00 -0700 (PDT) Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) (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 9FA741209A3; Sat, 10 Aug 2019 20:19:34 -0700 (PDT) Received: by mail-ot1-x342.google.com with SMTP id c34so7420708otb.7; Sat, 10 Aug 2019 20:19:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bjy+NdozKFHqXYH3JVWGJKqHq745Mb2Z37WWFdM9JWI=; b=fTM4bxjkzqOb3nn8WoH5w7adA5W8PZSjF//gYrosGJdmWAguF0uFTE+pAHPQ5hqQ+C 1Bf6dn/p+r7Yb23gji26yeoCz82uvcrEgdmtUJVcL/ZsBmv0wMrJxKnNzDofPs9d6Izq KBjNxsEKYi7Z4pjHHSoj4UhXuUZv7B5wacLYGSGOy1GJofmE88OCu6FANUJqlA+DxreU I+r9s47FvuV5YIvL89Ifspvp0RjZx+W0SjeOOigc3G7txJuse2yDY8WRtGWSVkwzoDBz b+Cr5jS7h0NJ5FR46gcvQaYdwPGtdWnvRzUPbsbunlk6Cb2VDoqMMTBKE4iIS5C4GqVY XgHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bjy+NdozKFHqXYH3JVWGJKqHq745Mb2Z37WWFdM9JWI=; b=CfNB9OkDLtih+sImau5VslSOQeD1FUu91rkYc9NNHYH2n9TGGQD5S58FDUWhHENJJn TtkIqCkNvIcb8n2SYmiGM3uOZD9dAjpM2hAXcD8K0z3J/yq2k17Sq8vYguHxUIortVg8 sbJ23ghpsdS+38gQ109FCjBaOj+7pTBJc72kDOI4c6L+eV+Xabk5PG43bhVvBy1O8Pn+ hp2v6PLWHtTuUj+2/rtWKFn+ckWOkaOwK9E9604FNkeEdLc7HjUTSOxP6wQbEeXMqLw2 96x0EmGPEXY1722M7KFXgVECg0f+z4meAY0D7rXytcTJiYNAsPouP9n+6rbBUhY01f8K Ocdg== X-Gm-Message-State: APjAAAVL6XoJw2jHc3t1nEyGkDgi+VyuwnoRkMoAIdMZ+gvFy2JX//jX lowPusXOgebR98F6JaHXtIDFUVm13XtXJWa2PhY= X-Google-Smtp-Source: APXvYqxAuXt9HYn5pOPVFwvi2Pd+GLSAAYfXOsUQCSVXeeGWKcngPiLyPUMdTidUy+YIP9zIoBBa3LnQhE0+UdFgqHA= X-Received: by 2002:aca:72c7:: with SMTP id p190mr7226909oic.9.1565493573825; Sat, 10 Aug 2019 20:19:33 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:4b14:0:0:0:0:0 with HTTP; Sat, 10 Aug 2019 20:19:33 -0700 (PDT) In-Reply-To: References: <791b33b8-4696-f69c-aca3-8838b2caafd8@sectigo.com> <77F8C1C2AAB5AE251285436F@172.20.2.211> <30deb3a8-c24f-1f38-2701-aa1d68b6adba@nostrum.com> From: Guntur Wiseno Putra Date: Sun, 11 Aug 2019 10:19:33 +0700 Message-ID: To: Adam Roach Cc: John C Klensin , "art@ietf.org" , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005db9dd058fcee067" Archived-At: Subject: Re: [arch-d] BCP 190, draft-nottingham-for-the-users, and a generalization X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2019 07:01:08 -0000 --0000000000005db9dd058fcee067 Content-Type: text/plain; charset="UTF-8" Dear architecture-discuss, Forgive me for typing errors in previous message... An alternative link to the posting on Marcos Novak's "Liquid Architecture in Cyberspace" at public@informationarchitecture@w3.org I mentioned earlier is https://lists.w3.org/Archives/Public/public-informationarchitecture/ 2019May/0000.html (which was "403 Forbidden: Request forbidden by administrative rules" the last time I checked up minutes ago) Or, if going directly toward the text: https://www.evl.uic.edu/datsoupi/coding/readings/1991_Novak_Liquid.pdf Thank to Martin Dodge for suggesting Marcos Novak's architecture in www.cybergeography.org bringing me to Daria Tsoupukiva's lecture providing the reading... Regard, Guntur Wiseno Putra Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra menulis: > Dear architecture-discuss, > > An alternative link to the posting on Marcos Nocak'S "Liquid Architecture > in Cyberspace" at public@informationarchitecture@w3.org I mentioned > earlier is > > https://lists.w3.org/Archives/Public/public-informationarchitecture/ > 2019May/0000.html > > (which was "403 Forbidden: Request forbidden by administrative rules" the > last time I checked up minutes ago) > > Or, if going directly toward the text: > > https:///www.evl.uic.edu/datsoupi/coding/readings/Marcos_Novak_ Liquid.pdf > > Thank to Martin Dodge for suggesting Marcos Novak's architecture in > www.cybergeography.org bringing me to Daria Tsoupukiva's lecture > providing the reading... > > Regard, > Gubtur Wiseno Putra > > Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra > menulis: > >> Dear architecture-discuss, >> >> Such co-presences of which architecture is part of: if we attempt to >> think of its relation with other human experiences on poetry, on poetics, >> on a spirit invoked to make comprehensible a poetic fact, to get toward an >> understanding of cyberspace architecture, of "Liquid Architecture in >> Cyberspace" (Marcos Novak, 1991) >> >> I suggested as a reading to public-informationarchitecture@w3.org at >> which there is the web-address to the Novak's work (posted at 12 May 2019): >> >> http://www.w3.org/mid/CAKi_AEu%252BK6XUb94zR7-9fQDq0Hy9JP0Zy >> T5em5Tg9gBMJh0Aiw@mail.gmail.com;list=public-informationarchitecture >> Regard, >> >> Guntur Wiseno Putra >> >> Pada Rabu, 24 Juli 2019, Guntur Wiseno Putra menulis: >> >>> Dear architecture-discuss, >>> & John, >>> >>> To share what might be inspiring... >>> >>> In order to propose what should be understood as "concept", "percept" & >>> "affect", thus as "philosophy" & "art", Deleuze & Guattari ("What is >>> Philosophy?") mentioned architecture as the first art as art begins with >>> house: that of which "the most scientific architecture continually produces >>> and unifies planes and sections... it could be defined as "frame" with a >>> connection among various frames oriented differently, applied to other >>> arts...(There is) a composite system consisting of points and >>> counterpoints... (there is) a matter of sensations (percepts and affects) >>> combined... (While) the system still needs a composition plane run >>> "deframing" opening ways from house territory to city-cosmos, the system in >>> which there are cosmic forces to create new affects...". >>> >>> There is "asthetic composition" as the working of sensation which is, so >>> they said, the definition of art... >>> >>> Regard, >>> Guntur Wiseno Putra >>> >>> Pada Selasa, 23 Juli 2019, Adam Roach menulis: >>> >>>> John -- >>>> >>>> It's going to take a while for me to formulate my thoughts around what >>>> you say below. To make sure I understand the class of constraints you're >>>> concerned about below, can you clarify whether you think they apply to: >>>> >>>> - Documents like BCP 200, RFC 2804, and BCP 188? >>>> - Documents like BCP 9 and BCP 92? >>>> - Documents like BCP 25, BCP 54, and BCP 83? >>>> >>>> You might see an unstated agenda in the categories of documents I list >>>> above, so I'll state it explicitly: in the general case, one person's >>>> important protections against a tragedy of the commons is another person's >>>> annoying impediment to be ignored and defeated. I get that not all of the >>>> above read on protocol design; but they do share the common feature that >>>> they've gone through the IETF consensus process (at least to the degree >>>> that such a process existed at the time of their respective publications). >>>> If we're going to carefully parse out the meanings of some of them as the >>>> will of the community while treating others as light guidelines to be >>>> ignored when they become cumbersome, we're going to need to agree on a >>>> pretty bright line that divides those categories. >>>> >>>> /a >>>> >>>> On 7/23/19 08:37, John C Klensin wrote: >>>> >>>> (copying architecture-discuss because the comment I'm about to >>>> make is an architectural issue and because >>>> draft-nottingham-for-the-users is under discussion there.) >>>> >>>> >>>> A late colleague, much loved by some of us, used to claim (much >>>> more elegantly than I can manage) that one of the reasons the >>>> ARPANET and then the Internet protocols had succeeded and much >>>> of what was seen as competitive alternatives had not, was that >>>> our efforts focused on pragmatic, working protocols and >>>> implementations. >>>> >>>> The other folks had developed a culture of formalisms, models, >>>> and stated design principles. They then tried to develop >>>> protocols that fit into the boxes and categories of those >>>> formalisms, models, and design principles. When they >>>> discovered that something didn't fit, they needed to either >>>> invent kludges or other ways of getting square pegs into round >>>> holes, go back and revise models and guidance before moving >>>> forward, or consider and make exceptions (which often required >>>> first figuring out how to make an exception and developing >>>> procedures for that). >>>> >>>> One difficulty is that the above can waste a lot of time. >>>> Another is that it can distort protocol design, if only because >>>> forcing square pegs into round holes tends to be hard on both >>>> the pegs and the holes. >>>> >>>> In many or most fields of application, the nature of engineering >>>> involves seeing and understanding a range of tradeoffs and then >>>> doing design work that reflects a carefully-chosen balance among >>>> them. Give design elegance absolute priority over structural >>>> issues and buildings and bridges fall down. IMO, we need to >>>> think, and keep thinking, about systems and tradeoffs. That, in >>>> turn, means that statements like these that can be interpreted >>>> in absolute terms, even if we mostly agree with them, should be >>>> packaged as general guidelines and not BCPs to which everything >>>> done in the future is required to either conform or to try to >>>> figure out how to appeal to a higher authority. >>>> >>>> I'm not at all convinced that the proposal that was summarized >>>> an ARTAREA yesterday and that is seen as requiring an exception >>>> to BCP 190 is a good idea. But I think our time would be better >>>> spent, and the Internet more efficiently made better, discussing >>>> the strengths, weaknesses, and alternatives to that idea rather >>>> than debating the reach and appropriateness of BCP 190 under >>>> various circumstances. Long term and more generally, I think >>>> that suggests seeing BCP 190 not as a particular set of >>>> principles and rules but as an example of something we don't >>>> want to do to ourselves again as a BCP (or as something that >>>> gets enough of an IAB stamp of approval that people will later >>>> argue MUST (or SHOULD) be conformed to. Again, restated as >>>> general guidance with the assumption that there will be >>>> exceptions and cases not considered, I don't have much of a >>>> problem. If that shoe fits draft-nottingham-for-the-users, >>>> so be it. >>>> >>>> john >>>> >>>> p.s. I don't mean to pick on Mark here. While these two >>>> documents coming up at the same time was handy, I think the >>>> problem is general and that there are far worse examples >>>> (examples of which he is not an author) than either of them. >>>> >>>> _______________________________________________ >>>> art mailing listart@ietf.orghttps://www.ietf.org/mailman/listinfo/art >>>> >>>> >>>> --0000000000005db9dd058fcee067 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss,

Forgive me for typing = errors in previous message...

An alternative link to the posting on Marcos Novak's "Liqu= id Architecture in Cyberspace" at public@informationarchitecture@w3.org=C2=A0I me= ntioned earlier is


=
(which was "403 Forbidden: Request forbidden by administra= tive rules" the last time I checked up minutes ago)

Or, if going directly toward the text:


=
Thank to Martin Dodge for suggesting Marcos Novak's archite= cture in=C2=A0= www.cybergeography.org=C2=A0bringing me to Daria Tsoupukiva's lectu= re providing the reading...


<= br>
Regard,
Guntur Wiseno Putra

Pada Minggu, 11 = Agustus 2019, Guntur Wiseno Putra <= gsenopu@gmail.com> menulis:
Dear a= rchitecture-discuss,

An alternative link to the posting = on Marcos Nocak'S "Liquid Architecture in Cyberspace" at publ= ic@informationarchitecture@w3.org=C2=A0 I mentioned earlier is


(which was "403 Forbidden: Request forbidden by admi= nistrative rules" the last time I checked up minutes ago)
Or, if going directly toward the text:


Thank to Mart= in Dodge for suggesting Marcos Novak's architecture in www.cybergeography.org brin= ging me to Daria Tsoupukiva's lecture providing the reading...

Regard,
Gubtur Wiseno Putra

Pada Minggu, = 11 Agustus 2019, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
Dear architecture-discuss,

Such co-presen= ces of which architecture is part of: if we attempt to think of its relatio= n with other human experiences on poetry, on poetics, on a spirit invoked t= o make comprehensible a poetic fact, to get toward an understanding of cybe= rspace architecture, of "Liquid Architecture in Cyberspace" (Marc= os Novak, 1991)

I suggested as a reading to public= -informationarchitecture@w3.org at which there is the web-address = to the Novak's work (posted at 12 May 2019):

<= a href=3D"http://www.w3.org/mid/CAKi_AEu%252BK6XUb94zR7-9fQDq0Hy9JP0ZyT5em5= Tg9gBMJh0Aiw@mail.gmail.com;list=3Dpublic-informationarchitecture" target= =3D"_blank">http://www.w3.org/mid/CAKi_AEu%252BK6XUb94zR7-9fQDq0Hy9JP0= ZyT5em5Tg9gBMJh0Aiw@mail.gmail.com;list=3Dpublic-informationarch<= wbr>itecture
Regard,

Guntur Wise= no Putra

Pada Rabu, 24 Juli 2019, Guntur Wiseno Putra <gsenopu@gmail.com> menu= lis:
Dear architecture-discuss,
&= John,

To share what might be inspiring...
=

In order to propose what should be understood as "= concept", "percept" & "affect", thus as "= philosophy" & "art", Deleuze & Guattari ("What = is Philosophy?") mentioned architecture as the first art as art begins= with house: that of which "the most scientific architecture continual= ly produces and unifies planes and sections... it could be defined as "= ;frame" with a connection among various frames oriented differently, a= pplied to other arts...(There is) a composite system consisting of points a= nd counterpoints... (there is) a matter of sensations (percepts and affects= ) combined... (While) the system still needs a composition plane run "= deframing" opening ways from house territory to city-cosmos, the syste= m in which there are cosmic forces to create new affects...".

There is "asthetic composition" as the working o= f sensation which is, so they said, the definition of art...

=
Regard,
Guntur Wiseno Putra

Pada Selasa, 23 Jul= i 2019, Adam Roach <adam@nostrum.com> menulis:
=20 =20 =20
John --

It's going to take a while for me to formulate my thoughts around what you say below. To make sure I understand the class of constraints you're concerned about below, can you clarify whether you think they apply to:
  • Documents like BCP 200, RFC 2804, and BCP 188?
  • Documents like BCP 9 and BCP 92?
  • Documents like BCP 25, BCP 54, and BCP 83?

You might see an unstated agenda in the categories of documents I list above, so I'll state it explicitly: in the general case, one person's important protections against a tragedy of the commons is another person's annoying impediment to be ignored and defeated. I get that not all of the above read on protocol design; but they do share the common feature that they've gone through the IETF consensus process (at least to the degree that such a process existed at the time of their respective publications). If we're going to carefully parse out the meanings of some of them as the will of the community while treating others as light guidelines to be ignored when they become cumbersome, we're going to need to agree on a pretty bright line that divides those categories.

/a


On 7/23/19 08:37, John C Klensin wrote:
(copying architecture-discuss because the comment I'm about =
to
make is an architectural issue and because
draft-nottingham-for-the-users is under discussion there.)


A late colleague, much loved by some of us, used to claim (much
more elegantly than I can manage) that one of the reasons the
ARPANET and then the Internet protocols had succeeded and much
of what was seen as competitive alternatives had not, was that
our efforts focused on pragmatic, working protocols and
implementations. =20

The other folks had developed a culture of formalisms, models,
and stated design principles.  They then tried to develop
protocols that fit into the boxes and categories of those
formalisms, models, and design principles.    When they
discovered that something didn't fit, they needed to either
invent kludges or other ways of getting square pegs into round
holes, go back and revise models and guidance before moving
forward, or consider and make exceptions (which often required
first figuring out how to make an exception and developing
procedures for that).

One difficulty is that the above can waste a lot of time.
Another is that it can distort protocol design, if only because
forcing square pegs into round holes tends to be hard on both
the pegs and the holes.

In many or most fields of application, the nature of engineering
involves seeing and understanding a range of tradeoffs and then
doing design work that reflects a carefully-chosen balance among
them.  Give design elegance absolute priority over structural
issues and buildings and bridges fall down.  IMO, we need to
think, and keep thinking, about systems and tradeoffs.  That, in
turn, means that statements like these that can be interpreted
in absolute terms, even if we mostly agree with them, should be
packaged as general guidelines and not BCPs to which everything
done in the future is required to either conform or to try to
figure out how to appeal to a higher authority.

I'm not at all convinced that the proposal that was summarized
an ARTAREA yesterday and that is seen as requiring an exception
to BCP 190 is a good idea.  But I think our time would be better
spent, and the Internet more efficiently made better, discussing
the strengths, weaknesses, and alternatives to that idea rather
than debating the reach and appropriateness of BCP 190 under
various circumstances.   Long term and more generally, I think
that suggests seeing BCP 190 not as a particular set of
principles and rules but as an example of something we don't
want to do to ourselves again as a BCP (or as something that
gets enough of an IAB stamp of approval that people will later
argue MUST (or SHOULD) be conformed to.  Again, restated as
general guidance with the assumption that there will be
exceptions and cases not considered, I don't have much of a
problem.    If that shoe fits  draft-nottingham-for-the-users,
so be it.

   john

p.s. I don't mean to pick on Mark here.   While these two
documents coming up at the same time was handy, I think the
problem is general and that there are far worse examples
(examples of which he is not an author) than either of them.

_______________________________________________
art mailing list
art@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/art


--0000000000005db9dd058fcee067-- From nobody Sun Aug 11 11:01:44 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16074120E5E; Sun, 11 Aug 2019 11:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Em8iKfh81vYS; Sun, 11 Aug 2019 11:00:40 -0700 (PDT) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 814A0120841; Sun, 11 Aug 2019 03:30:58 -0700 (PDT) Received: by mail-ot1-x330.google.com with SMTP id r21so143163214otq.6; Sun, 11 Aug 2019 03:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MlpopoR+CbVl3zsLx9A/OpcrDljjRFJW7cnPJLuDhZM=; b=kWJ+RuyA6I3958bOr/E8CctersfqB5jGTqPZKuZlnWbtbpkvoy6jOf7YG7daPIlM7C dZ5/toSFYaS9npNUqRsLHdkgiBU5CoewNI8TU/5Aol5S+xl6TWnYtFelIIkGeowFkYNY hwPSCJAllr7y4VMKSbQY2tuR35RTsIE+InMvpuGZvm/G6TPyjin71w1RQ1lRU35iOB4e uaAhOXK+O6ADYNkWRPXEVH49hNw8vPuTROA9c+Y71aC5nH5Ms/Rs0letV8ABq/oHFCuA DYBy7GDsx/mXtFev1rrcBu7LA+f2ze0zcncQGlkvFghQbr4jM1RguMbIA4GI8hQYTHNC 0s8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MlpopoR+CbVl3zsLx9A/OpcrDljjRFJW7cnPJLuDhZM=; b=eE8qLk4Y6+9IUIQwmFCcc887OTK+1K7noqE1jCFKunZVczEsonaAbIgdoEMb6NDtE/ fzTD3CeT7N8vgVh2cLVkyvBpP+nnrOx1FBlyy+WFGOO3WmQF4UP+ZK2+VPxRst1Nm4pE vh7ouUPVbEbh5b9RIb3Q9oT3N1GqEbCJ3coBZbK+RHDR2F42SIxlY7v93rjlbUTaQ4lX TNDPCz/v4RDEpsELkk3Czdr/e9g+f9+SgAcGNoWCGqh3ayFYN/74EpT6t7mm/9keMD97 ylXTkbAvzDeaI1Tu30vYDfr2+4A8F1NMDFM09pfQFZx30Jd4CFOToA0odr5yW640v2KZ BeTA== X-Gm-Message-State: APjAAAUmZ/mPyr4aIXMKBVrrkIcvtW41TYAN+Q9DZJRdMYNCNdLVz7bX If/FpbsTiIfmukLct9b0Xp4cF2waROgZQbHg3tk= X-Google-Smtp-Source: APXvYqxsk8+FEv1uvVaeE/2Wwxbv/Sz45QmiHBxM/3UDTIuRekfLt0vahkBK62XpqzSRqbuEUI2XC03WhUy+eanH//4= X-Received: by 2002:aca:72c7:: with SMTP id p190mr7926189oic.9.1565519457713; Sun, 11 Aug 2019 03:30:57 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:4b14:0:0:0:0:0 with HTTP; Sun, 11 Aug 2019 03:30:57 -0700 (PDT) In-Reply-To: References: <791b33b8-4696-f69c-aca3-8838b2caafd8@sectigo.com> <77F8C1C2AAB5AE251285436F@172.20.2.211> <30deb3a8-c24f-1f38-2701-aa1d68b6adba@nostrum.com> From: Guntur Wiseno Putra Date: Sun, 11 Aug 2019 17:30:57 +0700 Message-ID: To: Adam Roach Cc: John C Klensin , "art@ietf.org" , "architecture-discuss@ietf.org" , tsoupi@uic.edu Content-Type: multipart/alternative; boundary="0000000000002a82f5058fd4e766" Archived-At: Subject: Re: [arch-d] BCP 190, draft-nottingham-for-the-users, and a generalization X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2019 18:01:43 -0000 --0000000000002a82f5058fd4e766 Content-Type: text/plain; charset="UTF-8" Dear architecture-discuss, To share what I have found out: if such public installations inspire/is about exploring musicality of diferent architectural features --as it was attempted by "Building Music" of Electronic Visual Laboratory UIC: https://www.evl.uic.edu/entry.php?id=1985 *Note: There is a correction for Daria Tsoupikova e-mail address of my previous messages... Regard, Guntur Wiseno Putra Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra menulis: > Dear architecture-discuss, > > Forgive me for typing errors in previous message... > > An alternative link to the posting on Marcos Novak's "Liquid Architecture > in Cyberspace" at public@informationarchitecture@w3.org I mentioned > earlier is > > https://lists.w3.org/Archives/Public/public-informationarchi > tecture/2019May/0000.html > > (which was "403 Forbidden: Request forbidden by administrative rules" the > last time I checked up minutes ago) > > Or, if going directly toward the text: > > https://www.evl.uic.edu/datsoupi/coding/readings/1991_Novak_Liquid.pdf > > Thank to Martin Dodge for suggesting Marcos Novak's architecture in > www.cybergeography.org bringing me to Daria Tsoupukiva's lecture > providing the reading... > > > > Regard, > Guntur Wiseno Putra > > Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra > menulis: > >> Dear architecture-discuss, >> >> An alternative link to the posting on Marcos Nocak'S "Liquid Architecture >> in Cyberspace" at public@informationarchitecture@w3.org I mentioned >> earlier is >> >> https://lists.w3.org/Archives/Public/public-informationarchi >> tecture/2019May/0000.html >> >> (which was "403 Forbidden: Request forbidden by administrative rules" the >> last time I checked up minutes ago) >> >> Or, if going directly toward the text: >> >> https:///www.evl.uic.edu/datsoupi/coding/readings/Marcos_Novak_ >> Liquid.pdf >> >> Thank to Martin Dodge for suggesting Marcos Novak's architecture in >> www.cybergeography.org bringing me to Daria Tsoupukiva's lecture >> providing the reading... >> >> Regard, >> Gubtur Wiseno Putra >> >> Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra >> menulis: >> >>> Dear architecture-discuss, >>> >>> Such co-presences of which architecture is part of: if we attempt to >>> think of its relation with other human experiences on poetry, on poetics, >>> on a spirit invoked to make comprehensible a poetic fact, to get toward an >>> understanding of cyberspace architecture, of "Liquid Architecture in >>> Cyberspace" (Marcos Novak, 1991) >>> >>> I suggested as a reading to public-informationarchitecture@w3.org at >>> which there is the web-address to the Novak's work (posted at 12 May 2019): >>> >>> http://www.w3.org/mid/CAKi_AEu%252BK6XUb94zR7-9fQDq0Hy9JP0Zy >>> T5em5Tg9gBMJh0Aiw@mail.gmail.com;list=public-informationarchitecture >>> Regard, >>> >>> Guntur Wiseno Putra >>> >>> Pada Rabu, 24 Juli 2019, Guntur Wiseno Putra >>> menulis: >>> >>>> Dear architecture-discuss, >>>> & John, >>>> >>>> To share what might be inspiring... >>>> >>>> In order to propose what should be understood as "concept", "percept" & >>>> "affect", thus as "philosophy" & "art", Deleuze & Guattari ("What is >>>> Philosophy?") mentioned architecture as the first art as art begins with >>>> house: that of which "the most scientific architecture continually produces >>>> and unifies planes and sections... it could be defined as "frame" with a >>>> connection among various frames oriented differently, applied to other >>>> arts...(There is) a composite system consisting of points and >>>> counterpoints... (there is) a matter of sensations (percepts and affects) >>>> combined... (While) the system still needs a composition plane run >>>> "deframing" opening ways from house territory to city-cosmos, the system in >>>> which there are cosmic forces to create new affects...". >>>> >>>> There is "asthetic composition" as the working of sensation which is, >>>> so they said, the definition of art... >>>> >>>> Regard, >>>> Guntur Wiseno Putra >>>> >>>> Pada Selasa, 23 Juli 2019, Adam Roach menulis: >>>> >>>>> John -- >>>>> >>>>> It's going to take a while for me to formulate my thoughts around what >>>>> you say below. To make sure I understand the class of constraints you're >>>>> concerned about below, can you clarify whether you think they apply to: >>>>> >>>>> - Documents like BCP 200, RFC 2804, and BCP 188? >>>>> - Documents like BCP 9 and BCP 92? >>>>> - Documents like BCP 25, BCP 54, and BCP 83? >>>>> >>>>> You might see an unstated agenda in the categories of documents I list >>>>> above, so I'll state it explicitly: in the general case, one person's >>>>> important protections against a tragedy of the commons is another person's >>>>> annoying impediment to be ignored and defeated. I get that not all of the >>>>> above read on protocol design; but they do share the common feature that >>>>> they've gone through the IETF consensus process (at least to the degree >>>>> that such a process existed at the time of their respective publications). >>>>> If we're going to carefully parse out the meanings of some of them as the >>>>> will of the community while treating others as light guidelines to be >>>>> ignored when they become cumbersome, we're going to need to agree on a >>>>> pretty bright line that divides those categories. >>>>> >>>>> /a >>>>> >>>>> On 7/23/19 08:37, John C Klensin wrote: >>>>> >>>>> (copying architecture-discuss because the comment I'm about to >>>>> make is an architectural issue and because >>>>> draft-nottingham-for-the-users is under discussion there.) >>>>> >>>>> >>>>> A late colleague, much loved by some of us, used to claim (much >>>>> more elegantly than I can manage) that one of the reasons the >>>>> ARPANET and then the Internet protocols had succeeded and much >>>>> of what was seen as competitive alternatives had not, was that >>>>> our efforts focused on pragmatic, working protocols and >>>>> implementations. >>>>> >>>>> The other folks had developed a culture of formalisms, models, >>>>> and stated design principles. They then tried to develop >>>>> protocols that fit into the boxes and categories of those >>>>> formalisms, models, and design principles. When they >>>>> discovered that something didn't fit, they needed to either >>>>> invent kludges or other ways of getting square pegs into round >>>>> holes, go back and revise models and guidance before moving >>>>> forward, or consider and make exceptions (which often required >>>>> first figuring out how to make an exception and developing >>>>> procedures for that). >>>>> >>>>> One difficulty is that the above can waste a lot of time. >>>>> Another is that it can distort protocol design, if only because >>>>> forcing square pegs into round holes tends to be hard on both >>>>> the pegs and the holes. >>>>> >>>>> In many or most fields of application, the nature of engineering >>>>> involves seeing and understanding a range of tradeoffs and then >>>>> doing design work that reflects a carefully-chosen balance among >>>>> them. Give design elegance absolute priority over structural >>>>> issues and buildings and bridges fall down. IMO, we need to >>>>> think, and keep thinking, about systems and tradeoffs. That, in >>>>> turn, means that statements like these that can be interpreted >>>>> in absolute terms, even if we mostly agree with them, should be >>>>> packaged as general guidelines and not BCPs to which everything >>>>> done in the future is required to either conform or to try to >>>>> figure out how to appeal to a higher authority. >>>>> >>>>> I'm not at all convinced that the proposal that was summarized >>>>> an ARTAREA yesterday and that is seen as requiring an exception >>>>> to BCP 190 is a good idea. But I think our time would be better >>>>> spent, and the Internet more efficiently made better, discussing >>>>> the strengths, weaknesses, and alternatives to that idea rather >>>>> than debating the reach and appropriateness of BCP 190 under >>>>> various circumstances. Long term and more generally, I think >>>>> that suggests seeing BCP 190 not as a particular set of >>>>> principles and rules but as an example of something we don't >>>>> want to do to ourselves again as a BCP (or as something that >>>>> gets enough of an IAB stamp of approval that people will later >>>>> argue MUST (or SHOULD) be conformed to. Again, restated as >>>>> general guidance with the assumption that there will be >>>>> exceptions and cases not considered, I don't have much of a >>>>> problem. If that shoe fits draft-nottingham-for-the-users, >>>>> so be it. >>>>> >>>>> john >>>>> >>>>> p.s. I don't mean to pick on Mark here. While these two >>>>> documents coming up at the same time was handy, I think the >>>>> problem is general and that there are far worse examples >>>>> (examples of which he is not an author) than either of them. >>>>> >>>>> _______________________________________________ >>>>> art mailing listart@ietf.orghttps://www.ietf.org/mailman/listinfo/art >>>>> >>>>> >>>>> --0000000000002a82f5058fd4e766 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear architecture-discuss,



To share what I have found out: if such public installations inspire/is ab= out exploring musicality of diferent architectural features --as it was att= empted by "Building Music" of Electronic Visual Laboratory UIC:


https://www.evl.uic.edu/entry.php?id=3D1985


*Note: There is a correction for Daria= Tsoupikova e-mail address of my previous messages...

<= div>
Regard,
Guntur Wiseno Putra

Pada Minggu= , 11 Agustus 2019, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
D= ear architecture-discuss,

Forgive me for typing e= rrors in previous message...

= An alternative link to the posting on Marcos Novak's "Liqui= d Architecture in Cyberspace" at public@informationarchitecture= @w3.org=C2=A0I ment= ioned earlier is


(which was "403 Forbidden: Request forbidden by administrative rule= s" the last time I checked up minutes ago)

= Or, if going directly toward the text:


Thank to Martin Dodge for suggesting Marcos = Novak's architecture in=C2=A0www.cybergeography.org=C2=A0bringing me to Dari= a Tsoupukiva's lecture providing the reading...



Regard,
Guntur Wiseno Putra=

Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra <gsenopu@gmail.com> menulis= :
Dear architecture-discuss,

An alternative link to the posting on Marcos Nocak'S "Liqui= d Architecture in Cyberspace" at public@informationarchitecture@<= a href=3D"http://w3.org" target=3D"_blank">w3.org=C2=A0 I mentioned ear= lier is


(which was "403 F= orbidden: Request forbidden by administrative rules" the last time I c= hecked up minutes ago)

Or, if going directly towar= d the text:

https:///www.evl.= uic.edu/datsoupi/coding/readings/Marcos_Novak_ Liquid.pdf

Thank to Martin Dodge for suggesting Marcos Novak'= ;s architecture in www.cybergeography.org bringing me to Daria Tsoupukiva's lectur= e providing the reading...

Regard,

Regard,

Guntur Wiseno Putra

Pada Rabu, 24 Juli 2019, G= untur Wiseno Putra <gsenopu@gmail.com> menulis:
Dea= r architecture-discuss,
& John,

To sha= re what might be inspiring...

In order to propose wh= at should be understood as "concept", "percept" & &= quot;affect", thus as "philosophy" & "art", De= leuze & Guattari ("What is Philosophy?") mentioned architectu= re as the first art as art begins with house: that of which "the most = scientific architecture continually produces and unifies planes and section= s... it could be defined as "frame" with a connection among vario= us frames oriented differently, applied to other arts...(There is) a compos= ite system consisting of points and counterpoints... (there is) a matter of= sensations (percepts and affects) combined... (While) the system still nee= ds a composition plane run "deframing" opening ways from house te= rritory to city-cosmos, the system in which there are cosmic forces to crea= te new affects...".

There is "asthetic c= omposition" as the working of sensation which is, so they said, the de= finition of art...

Regard,
Guntur Wiseno= Putra

Pada Selasa, 23 Juli 2019, Adam Roach <adam@nostrum.com> menulis:
=20 =20 =20
John --

It's going to take a while for me to formulate my thoughts around what you say below. To make sure I understand the class of constraints you're concerned about below, can you clarify whether you think they apply to:
  • Documents like BCP 200, RFC 2804, and BCP 188?
  • Documents like BCP 9 and BCP 92?
  • Documents like BCP 25, BCP 54, and BCP 83?

You might see an unstated agenda in the categories of documents I list above, so I'll state it explicitly: in the general case, one person's important protections against a tragedy of the commons is another person's annoying impediment to be ignored and defeated. I get that not all of the above read on protocol design; but they do share the common feature that they've gone through the IETF consensus process (at least to the degree that such a process existed at the time of their respective publications). If we're going to carefully parse out the meanings of some of them as the will of the community while treating others as light guidelines to be ignored when they become cumbersome, we're going to need to agree on a pretty bright line that divides those categories.

/a


On 7/23/19 08:37, John C Klensin wrote:
(copying architecture-discuss because the comment I'm about =
to
make is an architectural issue and because
draft-nottingham-for-the-users is under discussion there.)


A late colleague, much loved by some of us, used to claim (much
more elegantly than I can manage) that one of the reasons the
ARPANET and then the Internet protocols had succeeded and much
of what was seen as competitive alternatives had not, was that
our efforts focused on pragmatic, working protocols and
implementations. =20

The other folks had developed a culture of formalisms, models,
and stated design principles.  They then tried to develop
protocols that fit into the boxes and categories of those
formalisms, models, and design principles.    When they
discovered that something didn't fit, they needed to either
invent kludges or other ways of getting square pegs into round
holes, go back and revise models and guidance before moving
forward, or consider and make exceptions (which often required
first figuring out how to make an exception and developing
procedures for that).

One difficulty is that the above can waste a lot of time.
Another is that it can distort protocol design, if only because
forcing square pegs into round holes tends to be hard on both
the pegs and the holes.

In many or most fields of application, the nature of engineering
involves seeing and understanding a range of tradeoffs and then
doing design work that reflects a carefully-chosen balance among
them.  Give design elegance absolute priority over structural
issues and buildings and bridges fall down.  IMO, we need to
think, and keep thinking, about systems and tradeoffs.  That, in
turn, means that statements like these that can be interpreted
in absolute terms, even if we mostly agree with them, should be
packaged as general guidelines and not BCPs to which everything
done in the future is required to either conform or to try to
figure out how to appeal to a higher authority.

I'm not at all convinced that the proposal that was summarized
an ARTAREA yesterday and that is seen as requiring an exception
to BCP 190 is a good idea.  But I think our time would be better
spent, and the Internet more efficiently made better, discussing
the strengths, weaknesses, and alternatives to that idea rather
than debating the reach and appropriateness of BCP 190 under
various circumstances.   Long term and more generally, I think
that suggests seeing BCP 190 not as a particular set of
principles and rules but as an example of something we don't
want to do to ourselves again as a BCP (or as something that
gets enough of an IAB stamp of approval that people will later
argue MUST (or SHOULD) be conformed to.  Again, restated as
general guidance with the assumption that there will be
exceptions and cases not considered, I don't have much of a
problem.    If that shoe fits  draft-nottingham-for-the-users,
so be it.

   john

p.s. I don't mean to pick on Mark here.   While these two
documents coming up at the same time was handy, I think the
problem is general and that there are far worse examples
(examples of which he is not an author) than either of them.

_______________________________________________
art mailing list
art@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/art


--0000000000002a82f5058fd4e766-- From nobody Sun Aug 11 11:18:24 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDAB1120988; Sun, 11 Aug 2019 11:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 mhoK6b9V6Eni; Sun, 11 Aug 2019 11:17:28 -0700 (PDT) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 EEF40120A3E; Sun, 11 Aug 2019 03:42:20 -0700 (PDT) Received: by mail-ot1-x32c.google.com with SMTP id z17so30693031otk.13; Sun, 11 Aug 2019 03:42:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lOpkauZtFKIBi1RhE7bb07RqEgTjeh9D87dDZ0vLJ/w=; b=rF3KuE+8bwInATZ6+EC9iuYcl5D3GhZ5Jbq3M7egqDUNkCECjLjayK5HgJmoe5Chze hUeKRLZ/kqtPA9YjOtKUtoi+kJQVgM7PSJ34hr26xILtSmKpx116QUji3kVSaPKeagLM MoNW3HHLOszlLIYtl3k5RFfcGM0lj2Ha3RSzzH8iI7bgQI0pXI1xgEFlvGRU1cCmdDUW zVlNNTjeZQS5h4PXBZqhH8Rt7q3oR5HA8hdDDTavMlUEO2rmKsyt8g+N+BHTmGSLZdkp mEvRj+hd05pidi7uThZNMadLdKrJXg0YjGzC4CATaMGte8L3uhIXtXO7SgiiHfrvKbQp gxlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lOpkauZtFKIBi1RhE7bb07RqEgTjeh9D87dDZ0vLJ/w=; b=YCFnbwCY+q+wNMAvBu0jIi0LyqBuXkaTL5knNCSinmkQEabadfhQ3XSaWnS2ZXM5Xq qlnkK2AXqY2BhdBO3M69xQNlbw59baixmYgvpWSSjXHmMHJr+moPpHHz+AQoznbZy2Rc Zd10h1+0YlMV3lFbeQjYAVgkO4MhtHwvww2suJ1aZZn4r0TVMBrKDBpJ9+R+jfq47c1E Lgy4sxUfFEFSOi9WDPjZqzHSJLoKHO41mVb1zxMuO82gRi5taNkIIYxcdjjzKgmplQFX bUpmUXgFDufgKa7IkL1gN+qD0ot1LHEXDW6kwXUT1nCaTl6f5++J/TJ731Ns4EpSao9X Sxyw== X-Gm-Message-State: APjAAAXf0EJ+EcFNDlgQJd2MoFIG0+sQBXRkXDHjSegGCG4YMqkSwY0o cFivkQLcDEFkzJibzZkq3/lAzmiu1Nm7D6bUP/E= X-Google-Smtp-Source: APXvYqwrYbHxbSfWLt8LVH0ZgNHobTEELJWvUhwBbBUjVjs18Ub/RsiJtEHSjTD+gOwmL66MTPYg49AZqPcuBa8YGpk= X-Received: by 2002:a54:4703:: with SMTP id k3mr11129535oik.143.1565520140145; Sun, 11 Aug 2019 03:42:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:4b14:0:0:0:0:0 with HTTP; Sun, 11 Aug 2019 03:42:19 -0700 (PDT) In-Reply-To: References: <791b33b8-4696-f69c-aca3-8838b2caafd8@sectigo.com> <77F8C1C2AAB5AE251285436F@172.20.2.211> <30deb3a8-c24f-1f38-2701-aa1d68b6adba@nostrum.com> From: Guntur Wiseno Putra Date: Sun, 11 Aug 2019 17:42:19 +0700 Message-ID: To: Adam Roach Cc: John C Klensin , "art@ietf.org" , "architecture-discuss@ietf.org" , "tsoupi@uic.edu" , info@playthemagic.com Content-Type: multipart/alternative; boundary="000000000000d79c57058fd50fd9" Archived-At: Subject: Re: [arch-d] BCP 190, draft-nottingham-for-the-users, and a generalization X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2019 18:18:23 -0000 --000000000000d79c57058fd50fd9 Content-Type: text/plain; charset="UTF-8" Dear architecture-discuss, (There are things need to correct on * Note) To share what I have found out: if such public installations inspire/is about exploring musicality of diferent architectural features --as it was attempted by "Building Music" of Electronic Visual Laboratory UIC: https://www.evl.uic.edu/entry.php?id=1985 *Note: - There is a correction for Daria Tsoupikova e-mail address of my previous messages on Marcos Novak'"Liquid Architecture in Cyberspace" - Should I add CC: info@playthemagic.com as it is of the "Building Music" page which may have importances. Regard, Guntur Wiseno Putra Dear architecture-discuss, To share what I have found out: if such public installations inspire/is about exploring musicality of diferent architectural features --as it was attempted by "Building Music" of Electronic Visual Laboratory UIC: https://www.evl.uic.edu/entry.php?id=1985 *Note: There is a correction for Daria Tsoupikova e-mail address of my previous messages... Regard, Guntur Wiseno Putra Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra menulis: > Dear architecture-discuss, > > > > To share what I have found out: if such public installations inspire/is > about exploring musicality of diferent architectural features --as it was > attempted by "Building Music" of Electronic Visual Laboratory UIC: > > > https://www.evl.uic.edu/entry.php?id=1985 > > > *Note: There is a correction for Daria Tsoupikova e-mail address of my > previous messages... > > > Regard, > Guntur Wiseno Putra > > Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra > menulis: > >> Dear architecture-discuss, >> >> Forgive me for typing errors in previous message... >> >> An alternative link to the posting on Marcos Novak's "Liquid Architecture >> in Cyberspace" at public@informationarchitecture@w3.org I mentioned >> earlier is >> >> https://lists.w3.org/Archives/Public/public-informationarchi >> tecture/2019May/0000.html >> >> (which was "403 Forbidden: Request forbidden by administrative rules" the >> last time I checked up minutes ago) >> >> Or, if going directly toward the text: >> >> https://www.evl.uic.edu/datsoupi/coding/readings/1991_Novak_Liquid.pdf >> >> Thank to Martin Dodge for suggesting Marcos Novak's architecture in >> www.cybergeography.org bringing me to Daria Tsoupukiva's lecture >> providing the reading... >> >> >> >> Regard, >> Guntur Wiseno Putra >> >> Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra >> menulis: >> >>> Dear architecture-discuss, >>> >>> An alternative link to the posting on Marcos Nocak'S "Liquid >>> Architecture in Cyberspace" at public@informationarchitecture@w3.org I >>> mentioned earlier is >>> >>> https://lists.w3.org/Archives/Public/public-informationarchi >>> tecture/2019May/0000.html >>> >>> (which was "403 Forbidden: Request forbidden by administrative rules" >>> the last time I checked up minutes ago) >>> >>> Or, if going directly toward the text: >>> >>> https:///www.evl.uic.edu/datsoupi/coding/readings/Marcos_Novak_ >>> Liquid.pdf >>> >>> Thank to Martin Dodge for suggesting Marcos Novak's architecture in >>> www.cybergeography.org bringing me to Daria Tsoupukiva's lecture >>> providing the reading... >>> >>> Regard, >>> Gubtur Wiseno Putra >>> >>> Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra >>> menulis: >>> >>>> Dear architecture-discuss, >>>> >>>> Such co-presences of which architecture is part of: if we attempt to >>>> think of its relation with other human experiences on poetry, on poetics, >>>> on a spirit invoked to make comprehensible a poetic fact, to get toward an >>>> understanding of cyberspace architecture, of "Liquid Architecture in >>>> Cyberspace" (Marcos Novak, 1991) >>>> >>>> I suggested as a reading to public-informationarchitecture@w3.org at >>>> which there is the web-address to the Novak's work (posted at 12 May 2019): >>>> >>>> http://www.w3.org/mid/CAKi_AEu%252BK6XUb94zR7-9fQDq0Hy9JP0Zy >>>> T5em5Tg9gBMJh0Aiw@mail.gmail.com;list=public-informationarchitecture >>>> Regard, >>>> >>>> Guntur Wiseno Putra >>>> >>>> Pada Rabu, 24 Juli 2019, Guntur Wiseno Putra >>>> menulis: >>>> >>>>> Dear architecture-discuss, >>>>> & John, >>>>> >>>>> To share what might be inspiring... >>>>> >>>>> In order to propose what should be understood as "concept", "percept" >>>>> & "affect", thus as "philosophy" & "art", Deleuze & Guattari ("What is >>>>> Philosophy?") mentioned architecture as the first art as art begins with >>>>> house: that of which "the most scientific architecture continually produces >>>>> and unifies planes and sections... it could be defined as "frame" with a >>>>> connection among various frames oriented differently, applied to other >>>>> arts...(There is) a composite system consisting of points and >>>>> counterpoints... (there is) a matter of sensations (percepts and affects) >>>>> combined... (While) the system still needs a composition plane run >>>>> "deframing" opening ways from house territory to city-cosmos, the system in >>>>> which there are cosmic forces to create new affects...". >>>>> >>>>> There is "asthetic composition" as the working of sensation which is, >>>>> so they said, the definition of art... >>>>> >>>>> Regard, >>>>> Guntur Wiseno Putra >>>>> >>>>> Pada Selasa, 23 Juli 2019, Adam Roach menulis: >>>>> >>>>>> John -- >>>>>> >>>>>> It's going to take a while for me to formulate my thoughts around >>>>>> what you say below. To make sure I understand the class of constraints >>>>>> you're concerned about below, can you clarify whether you think they apply >>>>>> to: >>>>>> >>>>>> - Documents like BCP 200, RFC 2804, and BCP 188? >>>>>> - Documents like BCP 9 and BCP 92? >>>>>> - Documents like BCP 25, BCP 54, and BCP 83? >>>>>> >>>>>> You might see an unstated agenda in the categories of documents I >>>>>> list above, so I'll state it explicitly: in the general case, one person's >>>>>> important protections against a tragedy of the commons is another person's >>>>>> annoying impediment to be ignored and defeated. I get that not all of the >>>>>> above read on protocol design; but they do share the common feature that >>>>>> they've gone through the IETF consensus process (at least to the degree >>>>>> that such a process existed at the time of their respective publications). >>>>>> If we're going to carefully parse out the meanings of some of them as the >>>>>> will of the community while treating others as light guidelines to be >>>>>> ignored when they become cumbersome, we're going to need to agree on a >>>>>> pretty bright line that divides those categories. >>>>>> >>>>>> /a >>>>>> >>>>>> On 7/23/19 08:37, John C Klensin wrote: >>>>>> >>>>>> (copying architecture-discuss because the comment I'm about to >>>>>> make is an architectural issue and because >>>>>> draft-nottingham-for-the-users is under discussion there.) >>>>>> >>>>>> >>>>>> A late colleague, much loved by some of us, used to claim (much >>>>>> more elegantly than I can manage) that one of the reasons the >>>>>> ARPANET and then the Internet protocols had succeeded and much >>>>>> of what was seen as competitive alternatives had not, was that >>>>>> our efforts focused on pragmatic, working protocols and >>>>>> implementations. >>>>>> >>>>>> The other folks had developed a culture of formalisms, models, >>>>>> and stated design principles. They then tried to develop >>>>>> protocols that fit into the boxes and categories of those >>>>>> formalisms, models, and design principles. When they >>>>>> discovered that something didn't fit, they needed to either >>>>>> invent kludges or other ways of getting square pegs into round >>>>>> holes, go back and revise models and guidance before moving >>>>>> forward, or consider and make exceptions (which often required >>>>>> first figuring out how to make an exception and developing >>>>>> procedures for that). >>>>>> >>>>>> One difficulty is that the above can waste a lot of time. >>>>>> Another is that it can distort protocol design, if only because >>>>>> forcing square pegs into round holes tends to be hard on both >>>>>> the pegs and the holes. >>>>>> >>>>>> In many or most fields of application, the nature of engineering >>>>>> involves seeing and understanding a range of tradeoffs and then >>>>>> doing design work that reflects a carefully-chosen balance among >>>>>> them. Give design elegance absolute priority over structural >>>>>> issues and buildings and bridges fall down. IMO, we need to >>>>>> think, and keep thinking, about systems and tradeoffs. That, in >>>>>> turn, means that statements like these that can be interpreted >>>>>> in absolute terms, even if we mostly agree with them, should be >>>>>> packaged as general guidelines and not BCPs to which everything >>>>>> done in the future is required to either conform or to try to >>>>>> figure out how to appeal to a higher authority. >>>>>> >>>>>> I'm not at all convinced that the proposal that was summarized >>>>>> an ARTAREA yesterday and that is seen as requiring an exception >>>>>> to BCP 190 is a good idea. But I think our time would be better >>>>>> spent, and the Internet more efficiently made better, discussing >>>>>> the strengths, weaknesses, and alternatives to that idea rather >>>>>> than debating the reach and appropriateness of BCP 190 under >>>>>> various circumstances. Long term and more generally, I think >>>>>> that suggests seeing BCP 190 not as a particular set of >>>>>> principles and rules but as an example of something we don't >>>>>> want to do to ourselves again as a BCP (or as something that >>>>>> gets enough of an IAB stamp of approval that people will later >>>>>> argue MUST (or SHOULD) be conformed to. Again, restated as >>>>>> general guidance with the assumption that there will be >>>>>> exceptions and cases not considered, I don't have much of a >>>>>> problem. If that shoe fits draft-nottingham-for-the-users, >>>>>> so be it. >>>>>> >>>>>> john >>>>>> >>>>>> p.s. I don't mean to pick on Mark here. While these two >>>>>> documents coming up at the same time was handy, I think the >>>>>> problem is general and that there are far worse examples >>>>>> (examples of which he is not an author) than either of them. >>>>>> >>>>>> _______________________________________________ >>>>>> art mailing listart@ietf.orghttps://www.ietf.org/mailman/listinfo/art >>>>>> >>>>>> >>>>>> --000000000000d79c57058fd50fd9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear architecture-discuss,

(There ar= e things need to correct on * Note)

To share what = I have found out: if such public installations inspire/is about exploring m= usicality of diferent architectural features --as it was attempted by "= ;Building Music" of Electronic Visual Laboratory UIC:




*Note:=C2=A0
- There= is a correction for Daria Tsoupikova e-mail address of my previous message= s on Marcos Novak'"Liquid Architecture in Cyberspace"
- Should I add CC: info@playthe= magic.com as it is of the "Building Music" page which may hav= e importances.


Regard,
Gu= ntur Wiseno Putra



<= div>

Dear architecture-discuss,

=


To share what I have found out: if such = public installations inspire/is about exploring musicality of diferent arch= itectural features --as it was attempted by "Building Music" of E= lectronic Visual Laboratory UIC:


htt= ps://www.evl.uic.edu/entry.php?id=3D1985

<= div>
*Note: There is a correction for Daria Tsoupikova e-mail= address of my previous messages...


Regard,
Guntur Wiseno Putra



Pa= da Minggu, 11 Agustus 2019, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
Dear architecture-discuss,



To share what I have found out: if such public installations inspi= re/is about exploring musicality of diferent architectural features --as it= was attempted by "Building Music" of Electronic Visual Laborator= y UIC:




*Note: = There is a correction for Daria Tsoupikova e-mail address of my previous me= ssages...


Regard,
Guntur = Wiseno Putra

Pada Minggu, 11 Agustus 2019, Guntur Wiseno Putra <<= a href=3D"mailto:gsenopu@gmail.com" target=3D"_blank">gsenopu@gmail.com= > menulis:
Dear architecture-discuss,<= div>
Forgive me for typing errors in previous message.= ..

An alternative link= to the posting on Marcos Novak's "Liquid Architecture in Cyberspa= ce" at public@informationarchitecture@w3.org=C2=A0I mentioned earlier is


(which was "403 Fo= rbidden: Request forbidden by administrative rules" the last time I ch= ecked up minutes ago)

Or, if going directly towa= rd the text:


=
Thank to Martin Dodge for suggesting Marcos Novak's architecture = in=C2=A0www.cy= bergeography.org=C2=A0bringing me to Daria Tsoupukiva's lectur= e providing the reading...


Regard,
Guntur Wiseno Putra

Pada Minggu, 11 A= gustus 2019, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
Dear architecture-discuss,

An alternative lin= k to the posting on Marcos Nocak'S "Liquid Architecture in Cybersp= ace" at public@informationarchitecture@w3.org=C2=A0 I mentioned earlier is


(which was "403 Forbidden: Request forbidd= en by administrative rules" the last time I checked up minutes ago)

Or, if going directly toward the text:


Tha= nk to Martin Dodge for suggesting Marcos Novak's architecture in www.cybergeography.or= g bringing me to Daria Tsoupukiva's lecture providing the reading..= .

Regard,
Gubtur Wiseno Putra

Pad= a Minggu, 11 Agustus 2019, Guntur Wiseno Putra <gsenopu@gmail.com> menulis:
Dear architecture-discuss,

Such= co-presences of which architecture is part of: if we attempt to think of i= ts relation with other human experiences on poetry, on poetics, on a spirit= invoked to make comprehensible a poetic fact, to get toward an understandi= ng of cyberspace architecture, of "Liquid Architecture in Cyberspace&q= uot; (Marcos Novak, 1991)

I suggested as a reading= to public-informationarchitecture@w3.org at which there is the we= b-address to the Novak's work (posted at 12 May 2019):

Regard,

Gun= tur Wiseno Putra

Pada Rabu, 24 Juli 2019, Guntur Wiseno Putra <gsenopu@gmail.com&= gt; menulis:
Dear architecture-discuss,& John,

To share what might be inspirin= g...

In order to propose what should be understood a= s "concept", "percept" & "affect", thus a= s "philosophy" & "art", Deleuze & Guattari (&qu= ot;What is Philosophy?") mentioned architecture as the first art as ar= t begins with house: that of which "the most scientific architecture c= ontinually produces and unifies planes and sections... it could be defined = as "frame" with a connection among various frames oriented differ= ently, applied to other arts...(There is) a composite system consisting of = points and counterpoints... (there is) a matter of sensations (percepts and= affects) combined... (While) the system still needs a composition plane ru= n "deframing" opening ways from house territory to city-cosmos, t= he system in which there are cosmic forces to create new affects...".<= /div>

There is "asthetic composition" as the w= orking of sensation which is, so they said, the definition of art...
<= div>
Regard,
Guntur Wiseno Putra

Pada Selasa= , 23 Juli 2019, Adam Roach <adam@nostrum.com> menulis:
=20 =20 =20
John --

It's going to take a while for me to formulate my thoughts around what you say below. To make sure I understand the class of constraints you're concerned about below, can you clarify whether you think they apply to:
  • Documents like BCP 200, RFC 2804, and BCP 188?
  • Documents like BCP 9 and BCP 92?
  • Documents like BCP 25, BCP 54, and BCP 83?

You might see an unstated agenda in the categories of documents I list above, so I'll state it explicitly: in the general case, one person's important protections against a tragedy of the commons is another person's annoying impediment to be ignored and defeated. I get that not all of the above read on protocol design; but they do share the common feature that they've gone through the IETF consensus process (at least to the degree that such a process existed at the time of their respective publications). If we're going to carefully parse out the meanings of some of them as the will of the community while treating others as light guidelines to be ignored when they become cumbersome, we're going to need to agree on a pretty bright line that divides those categories.

/a


On 7/23/19 08:37, John C Klensin wrote:
(copying architecture-discuss because the comment I'm about =
to
make is an architectural issue and because
draft-nottingham-for-the-users is under discussion there.)


A late colleague, much loved by some of us, used to claim (much
more elegantly than I can manage) that one of the reasons the
ARPANET and then the Internet protocols had succeeded and much
of what was seen as competitive alternatives had not, was that
our efforts focused on pragmatic, working protocols and
implementations. =20

The other folks had developed a culture of formalisms, models,
and stated design principles.  They then tried to develop
protocols that fit into the boxes and categories of those
formalisms, models, and design principles.    When they
discovered that something didn't fit, they needed to either
invent kludges or other ways of getting square pegs into round
holes, go back and revise models and guidance before moving
forward, or consider and make exceptions (which often required
first figuring out how to make an exception and developing
procedures for that).

One difficulty is that the above can waste a lot of time.
Another is that it can distort protocol design, if only because
forcing square pegs into round holes tends to be hard on both
the pegs and the holes.

In many or most fields of application, the nature of engineering
involves seeing and understanding a range of tradeoffs and then
doing design work that reflects a carefully-chosen balance among
them.  Give design elegance absolute priority over structural
issues and buildings and bridges fall down.  IMO, we need to
think, and keep thinking, about systems and tradeoffs.  That, in
turn, means that statements like these that can be interpreted
in absolute terms, even if we mostly agree with them, should be
packaged as general guidelines and not BCPs to which everything
done in the future is required to either conform or to try to
figure out how to appeal to a higher authority.

I'm not at all convinced that the proposal that was summarized
an ARTAREA yesterday and that is seen as requiring an exception
to BCP 190 is a good idea.  But I think our time would be better
spent, and the Internet more efficiently made better, discussing
the strengths, weaknesses, and alternatives to that idea rather
than debating the reach and appropriateness of BCP 190 under
various circumstances.   Long term and more generally, I think
that suggests seeing BCP 190 not as a particular set of
principles and rules but as an example of something we don't
want to do to ourselves again as a BCP (or as something that
gets enough of an IAB stamp of approval that people will later
argue MUST (or SHOULD) be conformed to.  Again, restated as
general guidance with the assumption that there will be
exceptions and cases not considered, I don't have much of a
problem.    If that shoe fits  draft-nottingham-for-the-users,
so be it.

   john

p.s. I don't mean to pick on Mark here.   While these two
documents coming up at the same time was handy, I think the
problem is general and that there are far worse examples
(examples of which he is not an author) than either of them.

_______________________________________________
art mailing list
art@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/art


--000000000000d79c57058fd50fd9-- From nobody Mon Aug 12 05:27:29 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F6C1215B0 for ; Mon, 12 Aug 2019 05:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.572 X-Spam-Level: X-Spam-Status: No, score=0.572 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, EMPTY_MESSAGE=2.32, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 L8DWMv6QnZVa for ; Mon, 12 Aug 2019 05:26:37 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 D384A120F24 for ; Sun, 11 Aug 2019 13:13:00 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id m97so18486006otm.12 for ; Sun, 11 Aug 2019 13:13:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=yfRkJjGOuYajIRoFq3QGSglzXhNpLCM+TV4p7u74eio=; b=DsmtIyviGxyHdgPIp7DHXfo/VfiF1JlnI1SXXUMuwz+6pr/yHGGhuPuPWWCnKxEzCv fRApn+yGJDZfQolRYO2KSxAAkJveVYjuWQWDsoWL0OovsLdVLvEwgveQTJ8L8F4PlcrG 10y3ssPlP6BBBfFuk8kbWgIg1Kez8Xnt9D32Bd5ozt6nwtPwxmBLdCOg4oc3Mg7RfKzY QoVs4Ipf1E1l0GlN+oJAw5Ri+qTfqCiVHLOdVzIV9kqj51kcddBl+acYvgUbIkMFNeFi MmtmkxqK//V2BwS9sBXYrc6ZhUtUypnLzBpM4O0CZWwVDXeHEw+pWtSL3CxP0P7QMbPU Hkow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yfRkJjGOuYajIRoFq3QGSglzXhNpLCM+TV4p7u74eio=; b=GeGeJOjuOdyRHmwiBCsmmUzbfswfsd4je+fs4tXOxqpCpZbiriDzkWCMMK+15hDSjl 3SCxCpiTJZEjGryNjwckgbUf19XGMzS0Jp4nnQY/mSCQh4ylhlCvLQsv6F8/o83Xevkr MkdCppv1nclX90KEox1ZYdlC8+PmcsLeYbroK60GSZBb/De8FPQ6OfEnDXnzyu21ADKT 48tHr/XrnPInzKu773/odrU9OvJql8E17qDQx33GSjdjISI+bgSgJQb3zYroaj2OQUMb 6pRuel+qRZsjHAYtavx5RzG4/6Nlj/dMwg2xdhGYQA2UuaNaVlJTLlbYcO+6QiF8z3nz ScMg== X-Gm-Message-State: APjAAAV1zkY/0+/XbWsZRI4Q2Hc5mC05R2ItEeRLLdVxRvAKjHBirNjl fXjJ3CDg8+1UlzmSubWd08/vM08IfONLD24FaOh+wA== X-Google-Smtp-Source: APXvYqzviMlSKI0gV/SWB8J7xqPDGZxcvj90eadMnDBPV88UVL7EjRWg0TGvlza6QUHmp0XIXN8ecdRV1lr2Ziwk5zc= X-Received: by 2002:a9d:68d7:: with SMTP id i23mr24458486oto.124.1565554380128; Sun, 11 Aug 2019 13:13:00 -0700 (PDT) MIME-Version: 1.0 From: Logan Kirk Date: Sun, 11 Aug 2019 16:12:48 -0400 Message-ID: To: architecture-discuss@iab.org Content-Type: multipart/alternative; boundary="000000000000b443bb058fdd0895" Archived-At: Subject: [arch-d] (no subject) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 12:27:28 -0000 --000000000000b443bb058fdd0895 Content-Type: text/plain; charset="UTF-8" --000000000000b443bb058fdd0895 Content-Type: text/html; charset="UTF-8"
--000000000000b443bb058fdd0895-- From nobody Mon Aug 12 14:06:24 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D5D120096 for ; Mon, 12 Aug 2019 14:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.572 X-Spam-Level: X-Spam-Status: No, score=0.572 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, EMPTY_MESSAGE=2.32, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 RGymI-BeuVX8 for ; Mon, 12 Aug 2019 14:06:21 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 1104A120CB1 for ; Sun, 11 Aug 2019 18:43:46 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id m24so481887otp.12 for ; Sun, 11 Aug 2019 18:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=dv8nmQe4NDYSVuZPPqMxe0SwNxgai8Y0epazFj5KQ/s=; b=poPb4RyzHebuTjXK27X7nbRl1NJUzJ3E3lZViZFVpAPLJYIKmBnfiMH1sOClE2uLwl 4SVYuMt0ilfCuZ7cUZmbK1fJHboGJCmzK1sMyV7dXG+hzsbAdFRyQSWc23ZepJEqN4kp 0e1gW/wSBgMRl1aaitV0RF5gs6C33Ivzlq9ylo7Pj+6gGV0tdf94FIyMZsaBMkclbMBH 4nqFPZurf3gA2gMnDBjJV18P0+vdOLO+l94GeI/ugEU7CxJHMZ8ihNoGEzNYAWl0msTl uetivXYrhuC09hu+Ehj5WfqoNL4uWuGhnBgpTxQTphdUQYvLtYukTF//k1+zvvLyXpfi krWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=dv8nmQe4NDYSVuZPPqMxe0SwNxgai8Y0epazFj5KQ/s=; b=NwRBclKK8QBukYwILNlFkx5ptdO1k0e9pVwJJZ74ol8RU3YQR2QrQ0cMkeL6JYDCAL u22zqXxruSVdzv4HsfeCquBBooe24ccms01Hadxz805IwBCIK6eoF3J7hjCgQCAeX10/ 4h553mS96Pycs/pwwN/FxvAsOkeWGxFOpmNiOOmX9PxZlsaf2QwNeUgLSDHtpvj6IPQH rKfmftKBf7cxZJW3/21CnWklWPMlaSAvkOla+a/122Ai7Y0Ky8hvfrNxeYlGGaKO1q8h Xb5LK2/HlaEA7PVo2hOaOs8xW2+dY5oyiEQQLOiYHhtvQlAaIDwU96xS9LupaKI4bydZ a4ig== X-Gm-Message-State: APjAAAWbg/uwZDV0Mvrg2zhXq6qDrKxPtL9XP80exr21Sjwdbj7ANDGN N4SeOyVjW2n0xh5s08dqlekYieyUP/bIavNKPKSDlQ== X-Google-Smtp-Source: APXvYqwYDY+pIg9i24qVCp3hMRuktFM1N51+w0C8OSC4sLlSZX0FVgaZkXq62WEdPqMtMc5aoIWUszNpV0jECEkKaW4= X-Received: by 2002:a5e:d618:: with SMTP id w24mr10245376iom.73.1565574225200; Sun, 11 Aug 2019 18:43:45 -0700 (PDT) MIME-Version: 1.0 From: Logan Kirk Date: Sun, 11 Aug 2019 21:43:32 -0400 Message-ID: To: architecture-discuss@iab.org Content-Type: multipart/alternative; boundary="000000000000900b99058fe1a7ba" Archived-At: Subject: [arch-d] (no subject) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 21:06:22 -0000 --000000000000900b99058fe1a7ba Content-Type: text/plain; charset="UTF-8" --000000000000900b99058fe1a7ba Content-Type: text/html; charset="UTF-8"
--000000000000900b99058fe1a7ba-- From nobody Thu Aug 22 11:00:28 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C821208F0 for ; Thu, 22 Aug 2019 11:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 LMnuQKpQ_8_8 for ; Thu, 22 Aug 2019 11:00:23 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 91D0C120A85 for ; Thu, 22 Aug 2019 11:00:23 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id v15so6512962wml.0 for ; Thu, 22 Aug 2019 11:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=j0H4NHhz79Mk8AsLii2esXflSrW2kQSHlHTcmw6Vcic=; b=ltSlQiHyfkKEfrNczjSjkgeRE3J0J5padre2IerfZdyiS3hd++pfER5My59nR1DoIa JNvfZ6w4z3fFwShk5A9OG0z1OKQbFKKmFygINbQT7rDHX2L4tw4m+QeT4kQywKFMZE+m g01RQyOKjnP4zazdiPaOGmO28ILe2Ovk2gpPtM3wNmfXB6HJtSyfixBWLSkH8BcWKLuN kINrC0Jv2e9YLm3zjIHub6Y2DGco5YTD9EvH68oX0IHyDZnUmCnthzbvmhYzbH0hiDmg LAMOvgoZm7uQQD4byiJuwy6D04kvfPolKgie6qrBAyf7AnWzuFwuLAqsdRC/LOIStpa7 gVvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=j0H4NHhz79Mk8AsLii2esXflSrW2kQSHlHTcmw6Vcic=; b=rApHLd1yfLaMQwA/6wWs5qU3S9RjJG2Y4FEEMd2MKms1IcIC5ducr3Rv8a7ScUqVye d+pgsgykgkKPnEg8Nty4twkH4ar6Q2aujBlBNRAEEiG3nwFWmWaQVt2Lshb5C1kssDwD B3rlqjao3PuZbbIirQQiSfx3Lqpw8tHtX2uX1jI4QxLNfhNv+z4qmHXEqXdt8tB3wFy0 QQ+71NMOYiiVCc2ZgkcGhVt0cnxsO6j7nM5Pv4V9D9lnCQau973T7W4KyhjwX5e5G+fg aRV6RBezc/PL/ux+QUoVfhyhbPtDiwtegTT5BqkB0ILayXws1TFNtW9ZsNCFiF5McyUO YQCA== X-Gm-Message-State: APjAAAWkXECm15oYRQAlQuH2CPowhj1NJLCBaD6c7z4aXxYYb9NopHuB WiHYVU1D9RPXgoNhcrHfYTUquqBa X-Google-Smtp-Source: APXvYqwF8cci21ERK4X676NPgSFgV71j4Uz+fjhvGTaO/uOIekDx39L8wevq3/8gieUVJ2h27Rh7TQ== X-Received: by 2002:a1c:eb0c:: with SMTP id j12mr321864wmh.132.1566496821869; Thu, 22 Aug 2019 11:00:21 -0700 (PDT) Received: from [10.0.0.199] (c-24-5-53-184.hsd1.ca.comcast.net. [24.5.53.184]) by smtp.gmail.com with ESMTPSA id g7sm434389wmg.8.2019.08.22.11.00.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Aug 2019 11:00:21 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1594A658-EDB9-45B7-BCE9-5B222558EE6F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 22 Aug 2019 11:00:17 -0700 In-Reply-To: <156641157393.25789.13597724381522897325.idtracker@ietfa.amsl.com> Cc: Bob Hinden , Internet Architecture Board To: architecture-discuss@ietf.org References: <156641157393.25789.13597724381522897325.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [arch-d] Call for Comment: (Defining the Role and Function of IETF Protocol Parameter Registry Operators) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2019 18:00:27 -0000 --Apple-Mail=_1594A658-EDB9-45B7-BCE9-5B222558EE6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Overall this looks good. Here is a link to a diff between the RFC and = current draft: = https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Dhttps://tools.iet= f.org/rfc/rfc6220.txt&url2=3Dhttps://tools.ietf.org/id/draft-ietf-iasa2-rf= c6220bis-03.txt A few comments: This draft says it obsoletes RFC6220, but that is not mentioned in the = abstract or in the Introduction. It should be. This was called out in = Idnits. Idnits also mentions some old references. After the abstract there is a [Cover Note]: [The IASA2 WG asks the IAB to publish this replacement for RFC 6220. This document is changed for alignment with the new structure for = the IETF Administrative Support Activity (IASA). ] Later in the document it asks the RFC Editor to remove this. I think the Abstract needs to include text that says this draft makes = changes relating to the IASA 2.0 model. For example something like = this: This document obsoletes RFC 6220 to replace all references to the = IASA and related structures with those defined by the IASA 2.0 Model. The something similar in the Introduction. This was done in the other = IASA 2.0 bis documents. Thanks Bob > On Aug 21, 2019, at 11:19 AM, IAB Executive Administrative Manager = wrote: >=20 > This is an announcement of an IETF-wide Call for Comment on > draft-ietf-iasa2-rfc6220bis-03. >=20 > The document is being considered for publication as an Informational = RFC > within the IAB stream, and is available for inspection at: > >=20 > The Call for Comment will last until 2019-09-18. Please send comments = to > architecture-discuss@ietf.org and iab@iab.org. >=20 > Abstract >=20 > Many Internet Engineering Task Force (IETF) protocols make use of > commonly defined values that are passed in messages or packets. To > ensure consistent interpretation of these values between independent > implementations, there is a need to ensure that the values and > associated semantic intent are uniquely defined. The IETF uses > registry functions to record assigned protocol parameter values and > their associated semantic intentions. For each IETF protocol > parameter, it is current practice for the IETF to delegate the role > of Protocol Parameter Registry Operator to a nominated entity. This > document provides a description of, and the requirements for, these > delegated functions. >=20 > [Cover Note] >=20 > [The IASA2 WG asks the IAB to publish this replacement for RFC 6220. > This document is changed for alignment with the new structure for = the > IETF Administrative Support Activity (IASA). ] >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail=_1594A658-EDB9-45B7-BCE9-5B222558EE6F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl1e2DEACgkQrut0EXfn u6hUtgf/aHdcBDCkOmY+2JcxUVQZs5XwUj0UEBO88lQhVUSa1vJsIVt4ZNFnNm0n gH1muSimuwiLxSdUaYYUXxCKe6w9kbIrLucN1DjiMfG9j/1HEwfPgB4r9dFVar2j JGqhF2r1NUNtN0X5YrpIvHs3cKXCPWW6hTWXglymnqKUnoFrj0Z7feZPxIAXSYpy pfsmo8ORr6pkiTDqQhD1Y8SmLDAOzlt5kns+8UDUAvU3FuCQLgwNF2HxunDAaDR8 mkgCGZwlcq5QwbIIKQMQsU2kcFecjwN79Tlg3X2Sye+vDYnmmsy+MHWLgn1gyrEx VhTcLWGRdxCk7LFe9Nt41d9OwoVOLw== =7cwl -----END PGP SIGNATURE----- --Apple-Mail=_1594A658-EDB9-45B7-BCE9-5B222558EE6F-- From nobody Fri Aug 23 02:07:26 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B772612021C for ; Fri, 23 Aug 2019 02:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 DElwsAAOIldr for ; Fri, 23 Aug 2019 02:07:22 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03D351201EF for ; Fri, 23 Aug 2019 02:07:21 -0700 (PDT) Received: from smtp7.infomaniak.ch (smtp7.infomaniak.ch [83.166.132.30]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x7N97IKs008197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 23 Aug 2019 11:07:19 +0200 Received: from [IPv6:2a00:79e0:42:206:58d9:bd07:f754:1847] ([IPv6:2a00:79e0:42:206:58d9:bd07:f754:1847]) (authenticated bits=0) by smtp7.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x7N97Ijp067186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 23 Aug 2019 11:07:18 +0200 From: "Brian Trammell (IETF)" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Fri, 23 Aug 2019 11:07:18 +0200 To: architecture-discuss@iab.org X-Mailer: Apple Mail (2.3445.104.11) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 09:07:25 -0000 Greetings, all, During the IETF 105 meeting in Montreal, the IAB decided to close the = Stack Evolution program in its present form.=20 The initial concept behind the IP Stack Evolution program was to = investigate how changes to the whole stack, especially to the transport = layer, could be deployed in the big-I Internet, and explore the impact = of encryption at the transport layer on evolution of the stack. At the = time the program started in 2014, there was not much work yet in and = around the IETF in this space.=20 That has changed. QUIC has demonstrated that it is possible to deploy a = new transport protocol at scale, and the QUIC WG has nearly finished an = IETF standard version of that protocol. TAPS was chartered, and is well = on its way to defining an abstract interface that reduces the rigidness = of the binding between interfaces and transports. Conversations (many = conversations) have started about the balance between measurability and = confidentiality, and some of these have found shape in protocols (e.g., = in the form of the QUIC spin bit). The discussion isn't over, though; the appropriate place for further = discussion on stackevo's topics (or adjacent ones) is here, on the = architecture-discuss list. Thanks, cheers, Brian (for the former IAB Stack Evolution Program)= From nobody Fri Aug 23 03:16:08 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BACB120807 for ; Fri, 23 Aug 2019 03:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 4wdLNtdeJNnJ for ; Fri, 23 Aug 2019 03:16:04 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1758F120804 for ; Fri, 23 Aug 2019 03:16:03 -0700 (PDT) Received: from [192.168.1.17] (ppp-94-69-228-254.home.otenet.gr [94.69.228.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id C37D8862AD; Fri, 23 Aug 2019 12:16:00 +0200 (CEST) To: "Brian Trammell (IETF)" , architecture-discuss@iab.org References: From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Fri, 23 Aug 2019 13:15:48 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 10:16:07 -0000 Hi, Brian, Thanks for the note! In-line... On 23/8/19 12:07, Brian Trammell (IETF) wrote: > Greetings, all, > > During the IETF 105 meeting in Montreal, the IAB decided to close the Stack Evolution program in its present form. > > The initial concept behind the IP Stack Evolution program was to investigate how changes to the whole stack, especially to the transport layer, could be deployed in the big-I Internet, and explore the impact of encryption at the transport layer on evolution of the stack. At the time the program started in 2014, there was not much work yet in and around the IETF in this space. > > That has changed. QUIC has demonstrated that it is possible to deploy a new transport protocol at scale, and the QUIC WG has nearly finished an IETF standard version of that protocol. I'm certainly not much of a QUIC expert, but... isn't QUIC tunneled over UDP? If so, then deployment of QUIC doesn't prove that it's possible to deploy new transport protocols in the big-I Internet. Actually, the decission to make QUIC run over UDP would seem to me quite the opposite: that you cannot deploy a new transport prootocol natively, and thus need to tunnel it on something that actually is known to work (TCP or UDP). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Aug 23 03:19:40 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C59120804 for ; Fri, 23 Aug 2019 03:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 a9_TrhJCDf3A for ; Fri, 23 Aug 2019 03:19:36 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FDFE1200B6 for ; Fri, 23 Aug 2019 03:19:35 -0700 (PDT) Received: from smtp8.infomaniak.ch (smtp8.infomaniak.ch [83.166.132.38]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x7NAJX0q027848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 23 Aug 2019 12:19:33 +0200 Received: from [IPv6:2a00:79e0:42:206:e804:7aae:a1b6:2e8b] ([IPv6:2a00:79e0:42:206:e804:7aae:a1b6:2e8b]) (authenticated bits=0) by smtp8.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x7NAJWCX132471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 23 Aug 2019 12:19:33 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Brian Trammell (IETF)" In-Reply-To: Date: Fri, 23 Aug 2019 12:19:32 +0200 Cc: architecture-discuss@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> References: To: Fernando Gont X-Mailer: Apple Mail (2.3445.104.11) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 10:19:38 -0000 hi Fernando, > On 23 Aug 2019, at 12:15, Fernando Gont wrote: >=20 > Hi, Brian, >=20 > Thanks for the note! In-line... >=20 > On 23/8/19 12:07, Brian Trammell (IETF) wrote: >> Greetings, all, >>=20 >> During the IETF 105 meeting in Montreal, the IAB decided to close the = Stack Evolution program in its present form.=20 >>=20 >> The initial concept behind the IP Stack Evolution program was to = investigate how changes to the whole stack, especially to the transport = layer, could be deployed in the big-I Internet, and explore the impact = of encryption at the transport layer on evolution of the stack. At the = time the program started in 2014, there was not much work yet in and = around the IETF in this space.=20 >>=20 >> That has changed. QUIC has demonstrated that it is possible to deploy = a new transport protocol at scale, and the QUIC WG has nearly finished = an IETF standard version of that protocol.=20 >=20 > I'm certainly not much of a QUIC expert, but... isn't QUIC tunneled = over > UDP? >=20 > If so, then deployment of QUIC doesn't prove that it's possible to > deploy new transport protocols in the big-I Internet. Actually, the > decission to make QUIC run over UDP would seem to me quite the = opposite: > that you cannot deploy a new transport prootocol natively, and thus = need > to tunnel it on something that actually is known to work (TCP or UDP). This is a well known discussion rabbithole, but.. no, QUIC is not = tunneled over UDP, it uses a UDP header as an encapsulation but is a = distinct transport protocol on its own. You're right that we can't = deploy new *headers* in the Internet because of middleboxes, but a key = insight behind QUIC is that you can run a new protocol over old headers. I would argue that thinking of UDP as a transport protocol is itself a = mistake; it is a UNIX sockets model friendly way to allow applications = to access an IP datagram service in a multiuser environment. But I think = I'm in the minority there. Cheers, Brian > Thanks, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 From nobody Fri Aug 23 04:00:14 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77225120809 for ; Fri, 23 Aug 2019 04:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 xvHYdJ5eFO0o for ; Fri, 23 Aug 2019 04:00:07 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 010E3120142 for ; Fri, 23 Aug 2019 04:00:06 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x7NB04M8139955 for ; Fri, 23 Aug 2019 13:00:04 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AB39E205432 for ; Fri, 23 Aug 2019 13:00:04 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A05B1205458 for ; Fri, 23 Aug 2019 13:00:04 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x7NB04ig015340 for ; Fri, 23 Aug 2019 13:00:04 +0200 To: architecture-discuss@ietf.org References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> From: Alexandre Petrescu Message-ID: Date: Fri, 23 Aug 2019 13:00:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 11:00:13 -0000 Le 23/08/2019 à 12:19, Brian Trammell (IETF) a écrit : > hi Fernando, > >> On 23 Aug 2019, at 12:15, Fernando Gont >> wrote: >> >> Hi, Brian, >> >> Thanks for the note! In-line... >> >> On 23/8/19 12:07, Brian Trammell (IETF) wrote: >>> Greetings, all, >>> >>> During the IETF 105 meeting in Montreal, the IAB decided to >>> close the Stack Evolution program in its present form. >>> >>> The initial concept behind the IP Stack Evolution program was to >>> investigate how changes to the whole stack, especially to the >>> transport layer, could be deployed in the big-I Internet, and >>> explore the impact of encryption at the transport layer on >>> evolution of the stack. At the time the program started in 2014, >>> there was not much work yet in and around the IETF in this >>> space. >>> >>> That has changed. QUIC has demonstrated that it is possible to >>> deploy a new transport protocol at scale, and the QUIC WG has >>> nearly finished an IETF standard version of that protocol. >> >> I'm certainly not much of a QUIC expert, but... isn't QUIC >> tunneled over UDP? >> >> If so, then deployment of QUIC doesn't prove that it's possible to >> deploy new transport protocols in the big-I Internet. Actually, >> the decission to make QUIC run over UDP would seem to me quite the >> opposite: that you cannot deploy a new transport prootocol >> natively, and thus need to tunnel it on something that actually is >> known to work (TCP or UDP). > > This is a well known discussion rabbithole, but.. no, QUIC is not > tunneled over UDP, it uses a UDP header as an encapsulation but is a > distinct transport protocol on its own. Sorry - it makes little sense. Or maybe we dont understand the same thing by 'being tunneled' over something. In my view, once there is an additional header that makes if for being tunneled. That additional header could be IP, UDP, TCP or even a Routing Header. I replied to this email because it popped into my regular inbox, not being catched by the normal filters. I dont understand why. > You're right that we can't deploy new *headers* in the Internet > because of middleboxes, but a key insight behind QUIC is that you can > run a new protocol over old headers. That is nothing new. There are so many people that run new protocols over old headers without even telling about this to other people. > I would argue that thinking of UDP as a transport protocol is itself > a mistake; it is a UNIX sockets model friendly way to allow > applications to access an IP datagram service in a multiuser > environment. But I think I'm in the minority there. It is an interesting view of thinking of UDP being more of a UNIX sockets model rather than a transport protocol. In that sense, I also see the raw sockets to be more powerful than UDP. And there is more. Alex > > Cheers, > > Brian > >> Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com >> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >> >> >> >> > > _______________________________________________ Architecture-discuss > mailing list Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > From nobody Fri Aug 23 04:45:32 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F08312081D for ; Fri, 23 Aug 2019 04:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ql3I8y0_rUjl for ; Fri, 23 Aug 2019 04:45:27 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6AE412081A for ; Fri, 23 Aug 2019 04:45:26 -0700 (PDT) Received: from [192.168.1.17] (ppp-94-69-228-254.home.otenet.gr [94.69.228.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 09FB78535B; Fri, 23 Aug 2019 13:45:20 +0200 (CEST) To: "Brian Trammell (IETF)" Cc: architecture-discuss@iab.org References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Fri, 23 Aug 2019 14:27:18 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 11:45:29 -0000 On 23/8/19 13:19, Brian Trammell (IETF) wrote: [....] >>> >>> That has changed. QUIC has demonstrated that it is possible to >>> deploy a new transport protocol at scale, and the QUIC WG has >>> nearly finished an IETF standard version of that protocol. >> >> I'm certainly not much of a QUIC expert, but... isn't QUIC tunneled >> over UDP? >> >> If so, then deployment of QUIC doesn't prove that it's possible to >> deploy new transport protocols in the big-I Internet. Actually, >> the decission to make QUIC run over UDP would seem to me quite the >> opposite: that you cannot deploy a new transport prootocol >> natively, and thus need to tunnel it on something that actually is >> known to work (TCP or UDP). > > This is a well known discussion rabbithole, but.. no, QUIC is not > tunneled over UDP, it uses a UDP header as an encapsulation but is a > distinct transport protocol on its own. Yes, you are tunneling one transport protocol into another. You could have also tunneled on QUIC on top of TCP. > You're right that we can't > deploy new *headers* in the Internet because of middleboxes, but a > key insight behind QUIC is that you can run a new protocol over old > headers. I guess I'm missing something here, but: isn't this the sort of thing we have been doing for ages? e.g., we tunnel IPsec over UDP (e.g. RFC3948) because of middleboxes, and I seem to remember being told that SCTP is also run at times over UDP. (at times we even go up even one more layer, and tunnel over HTTPS, when that's the only thing that works). > I would argue that thinking of UDP as a transport protocol is itself > a mistake; it is a UNIX sockets model friendly way to allow > applications to access an IP datagram service in a multiuser > environment. But I think I'm in the minority there. What would be the rationale for not considering UDP a transport protocol -- albeit one providing unreliable service? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Aug 23 08:08:09 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9945120046 for ; Fri, 23 Aug 2019 08:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=apple.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 m-D1q1IJzsMz for ; Fri, 23 Aug 2019 08:08:05 -0700 (PDT) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FEA612004A for ; Fri, 23 Aug 2019 08:08:05 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x7NF1sMm009460; Fri, 23 Aug 2019 08:08:04 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=nFBOilosqsnEgoSvHf4S/5lUjDukPg1a8Rf8AYUsAgQ=; b=X1bvceVao+pum0lgEODBBC1CnXX8atJ2M0c7OnWgQ0IIbDPPJedWCPWl9b/Yx40o+iJQ BNoj24VwtjB9WWGynwCQsxsFKixP2JrBWq71FQPM/q7eXFnG1fyoSPSD7PHjGmKilr4q WtD2YG9j21Ox/ePmpWkOskGAGRrgH3SHIXgBYcRSoRFP2orzn2gfSs3f1VD5/AlXVsk1 bzD/YddATILumwebRpBkRDKQMR3gHvKZI9EKdDv65AmxAJ95vI1IQZfRRx4lfAvc4COt Q5OlCV5b7FwdA8iFbstuM8W80qphddo1NO5LIJgZ6BDyBb0X3OsCdpgLzSrKQNIV+EhB xQ== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2uee5xg8g4-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 23 Aug 2019 08:08:04 -0700 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PWP0090V3DF2Q50@ma1-mtap-s03.corp.apple.com>; Fri, 23 Aug 2019 08:08:04 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PWP00C00366A300@nwk-mmpp-sz12.apple.com>; Fri, 23 Aug 2019 08:08:03 -0700 (PDT) X-Va-A: X-Va-T-CD: ca59bed23df3f788d3f801d0abd3820b X-Va-E-CD: dd1afc614a39dd0ea07087a02e889714 X-Va-R-CD: a76eefe8fdf227aa1290bbd803b8d89a X-Va-CD: 0 X-Va-ID: c388ee3d-bc85-483c-9a47-a86ac43e3b98 X-V-A: X-V-T-CD: ca59bed23df3f788d3f801d0abd3820b X-V-E-CD: dd1afc614a39dd0ea07087a02e889714 X-V-R-CD: a76eefe8fdf227aa1290bbd803b8d89a X-V-CD: 0 X-V-ID: 35f14bec-5ce9-4c01-a0b5-86114ff84d31 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-08-23_06:,, signatures=0 Received: from [17.234.47.92] by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PWP00M1Z3D2SY00@nwk-mmpp-sz12.apple.com>; Fri, 23 Aug 2019 08:08:03 -0700 (PDT) Sender: tpauly@apple.com Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) From: Tommy Pauly In-reply-to: Date: Fri, 23 Aug 2019 08:07:44 -0700 Cc: "Brian Trammell (IETF)" , architecture-discuss@iab.org Content-transfer-encoding: quoted-printable Message-id: <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> To: Fernando Gont X-Mailer: Apple Mail (2.3445.104.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-23_06:, , signatures=0 Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 15:08:08 -0000 > On Aug 23, 2019, at 4:27 AM, Fernando Gont = wrote: >=20 > On 23/8/19 13:19, Brian Trammell (IETF) wrote: > [....] >>>>=20 >>>> That has changed. QUIC has demonstrated that it is possible to >>>> deploy a new transport protocol at scale, and the QUIC WG has >>>> nearly finished an IETF standard version of that protocol. >>>=20 >>> I'm certainly not much of a QUIC expert, but... isn't QUIC tunneled >>> over UDP? >>>=20 >>> If so, then deployment of QUIC doesn't prove that it's possible to=20= >>> deploy new transport protocols in the big-I Internet. Actually, >>> the decission to make QUIC run over UDP would seem to me quite the >>> opposite: that you cannot deploy a new transport prootocol >>> natively, and thus need to tunnel it on something that actually is >>> known to work (TCP or UDP). >>=20 >> This is a well known discussion rabbithole, but.. no, QUIC is not >> tunneled over UDP, it uses a UDP header as an encapsulation but is a >> distinct transport protocol on its own. >=20 > Yes, you are tunneling one transport protocol into another. You could > have also tunneled on QUIC on top of TCP. It may become clearer if we look at what elements make up the various = protocols. In a typical HTTP/2 stack, you would see the following (I'm simplifying, = of course): HTTP/2: Application stream multiplexing + message encoding TLS: Encryption/authentication TCP: Port demultiplexing + reliability + congestion control IP: Addressing With HTTP/3 (the one over QUIC), you would see the same roles divided up = differently: HTTP/3: Message encoding QUIC: Application stream multiplexing + encryption/authentication + = reliability + congestion control UDP: Port demultiplexing IP: Addressing UDP alone is being used as a common way to encode port fields; it's not = providing true transport functionality. Moving QUIC over TCP, on the = other hand, is just like tunneling TCP over TCP, and comes with the many = costs and caveats of multiple layers of reliability, congestion control, = etc. Thanks, Tommy >=20 >=20 >=20 >> You're right that we can't >> deploy new *headers* in the Internet because of middleboxes, but a >> key insight behind QUIC is that you can run a new protocol over old >> headers. >=20 > I guess I'm missing something here, but: isn't this the sort of thing = we > have been doing for ages? e.g., we tunnel IPsec over UDP (e.g. = RFC3948) > because of middleboxes, and I seem to remember being told that SCTP is > also run at times over UDP. >=20 > (at times we even go up even one more layer, and tunnel over HTTPS, = when > that's the only thing that works). >=20 >=20 >> I would argue that thinking of UDP as a transport protocol is itself >> a mistake; it is a UNIX sockets model friendly way to allow >> applications to access an IP datagram service in a multiuser >> environment. But I think I'm in the minority there. >=20 > What would be the rationale for not considering UDP a transport = protocol > -- albeit one providing unreliable service? >=20 >=20 > Thanks, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Fri Aug 23 08:21:30 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F0B12085F for ; Fri, 23 Aug 2019 08:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 J0YdQTKPiPwo for ; Fri, 23 Aug 2019 08:21:26 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B9F512085C for ; Fri, 23 Aug 2019 08:21:23 -0700 (PDT) Received: from [192.168.1.17] (ppp-94-69-228-254.home.otenet.gr [94.69.228.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 0413B860FA; Fri, 23 Aug 2019 17:21:17 +0200 (CEST) To: Tommy Pauly Cc: "Brian Trammell (IETF)" , architecture-discuss@iab.org References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Fri, 23 Aug 2019 18:19:23 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 15:21:28 -0000 Hi, Tommy, On 23/8/19 18:07, Tommy Pauly wrote: > > >> On Aug 23, 2019, at 4:27 AM, Fernando Gont wrote: >> >> On 23/8/19 13:19, Brian Trammell (IETF) wrote: >> [....] [...] > > It may become clearer if we look at what elements make up the various protocols. > > In a typical HTTP/2 stack, you would see the following (I'm simplifying, of course): > > HTTP/2: Application stream multiplexing + message encoding > TLS: Encryption/authentication > TCP: Port demultiplexing + reliability + congestion control > IP: Addressing > > With HTTP/3 (the one over QUIC), you would see the same roles divided up differently: > > HTTP/3: Message encoding > QUIC: Application stream multiplexing + encryption/authentication + reliability + congestion control > UDP: Port demultiplexing > IP: Addressing > > UDP alone is being used as a common way to encode port fields; it's not providing true transport functionality. Moving QUIC over TCP, on the other hand, is just like tunneling TCP over TCP, and comes with the many costs and caveats of multiple layers of reliability, congestion control, etc. I go back to my original question: what functionality do you expect a transport protocol to ahve to call it a "transport protocol"? I agree that UDP provides probably implements very simply transport functionality. However, I fail to see why one wouldn't call it a transport protocol. (Some folks might exèct congestion control at the network layer... still we call IP an Internet Protocol...) Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Aug 23 11:48:12 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A15E1208AC for ; Fri, 23 Aug 2019 11:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 TlJlrSLpui9u for ; Fri, 23 Aug 2019 11:48:09 -0700 (PDT) Received: from relay.kvm02.ops-netman.net (relay.ops-netman.net [192.110.255.59]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3924E120899 for ; Fri, 23 Aug 2019 11:48:09 -0700 (PDT) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relay.kvm02.ops-netman.net (Postfix) with ESMTPS id 2E1353FDAA; Fri, 23 Aug 2019 18:48:06 +0000 (UTC) Received: from mailserver.ops-netman.net.ops-netman.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id E766742E; Fri, 23 Aug 2019 18:48:05 +0000 (UTC) Date: Fri, 23 Aug 2019 18:48:05 +0000 Message-ID: <87imqnvhui.wl-morrowc@ops-netman.net> From: Chris Morrow To: Fernando Gont Cc: Tommy Pauly , architecture-discuss@iab.org In-Reply-To: References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 18:48:11 -0000 On Fri, 23 Aug 2019 15:19:23 +0000, Fernando Gont wrote: > I agree that UDP provides probably implements very simply transport > functionality. However, I fail to see why one wouldn't call it a > transport protocol. I had figured quic was really an admission that: "Adding a new tcp/udp like protocol was much harder to swallow for the internet than just re-using an existing thing (UDP)." quic COULD have just as easily been done over tcp, esp, ah, icmp ... all of those come with some baggage though, which UDP didn't have. (admittedly udp has it's own baggage) From nobody Fri Aug 23 13:29:12 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07FEE12082E for ; Fri, 23 Aug 2019 13:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 sidJrapgfQQ1 for ; Fri, 23 Aug 2019 13:29:10 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 8954C120828 for ; Fri, 23 Aug 2019 13:29:10 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id q22so23020872iog.4 for ; Fri, 23 Aug 2019 13:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vaZ4BMtl0T+K9Yb+TzxecDfkX9O8BUuLqC+WMref8hw=; b=GOUbCKl1pKKWdTik8bGI+QP3QrIJeP+lyc7qb66sJvBYf4WPyMNC3+WskQxkYi8t/X kB4cUn7aXAwIVG+Dql9vOWwg2seaptgRLxM8tsBD1Daed3erWhV3DU2c3jhPwVwKwSwO PiVUk63ijh00rep0H6aBaL5HdflZZ8dy50UJ9igcs91tMoL9OFmFlFkTW9OrFI/OpIGF MGcxCMKirGAIgitN7pSfQOVA4a/vP/hsDUYqQ45Tp4hRRS2S3uEo2W6JNFU4Lu/nUXqO cHm2jI1N/GtRWM7jPNk92p1WtCGtT4jDnB5RA/V0lTqabz9T3EFoIKKM4bzzX6wWFtGx V53w== 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:from:date :message-id:subject:to:cc; bh=vaZ4BMtl0T+K9Yb+TzxecDfkX9O8BUuLqC+WMref8hw=; b=cqSS5g6UiFULtphGjpQS2OMOBbzZhLnq93r2E6fgVbc2pu6Lz61rYkVfhprXPpTDxh NjLFOv0olHxnXzOpwSOi1z+4szIvG8AXcB3y2q8E3Y7KEA9gkc+t5ihsVlGAAZJqXDTf K/jG2qR8M/G1iwkUX26ldnQ3M602AsYVC+sooVSlkAhFzg3amp/sUzcquYSCkCNaJk0/ tLXZEtvOJyGyiCusgHm8uGw1L/j2UNGcoecPDINXHZ++m1KU2QxKY1D5IC9G/3T1p0ee lLWPLO+Loe/Es+AlypGkxDC8hbJdRcK/kjOMLC41OlTI3sLhBgYi/2PXmWZ1Uigk6gMP FR+A== X-Gm-Message-State: APjAAAU5WJ3Z7fES2OuIXnX6nDwGdyu1MdCY9I21QqLaCOznCXMCnEUx Wl/9Np4gryJdvkUF5Cl6FpOihVUhxYnzGBwPHNs= X-Google-Smtp-Source: APXvYqzuVseHimrwHVrvBWbkSe+2mj2GnmOrFvxUT0hBSTLu7TCE1r1ZijYgr3IYmsse48UuuBB5ZxEBzE3V1Fp0CvE= X-Received: by 2002:a6b:790d:: with SMTP id i13mr8650840iop.27.1566592149759; Fri, 23 Aug 2019 13:29:09 -0700 (PDT) MIME-Version: 1.0 References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> In-Reply-To: <87imqnvhui.wl-morrowc@ops-netman.net> From: Ted Hardie Date: Fri, 23 Aug 2019 13:28:43 -0700 Message-ID: To: Chris Morrow Cc: Fernando Gont , architecture-discuss@iab.org Content-Type: multipart/alternative; boundary="000000000000982d970590cea85f" Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 20:29:12 -0000 --000000000000982d970590cea85f Content-Type: text/plain; charset="UTF-8" Howdy, On Fri, Aug 23, 2019 at 11:48 AM Chris Morrow wrote: > > I had figured quic was really an admission that: "Adding a new tcp/udp > like protocol was much harder to swallow for the internet than just > re-using an existing thing (UDP)." > > quic COULD have just as easily been done over tcp, esp, ah, icmp ... > all of those come with some baggage though, which UDP didn't have. > (admittedly udp has it's own baggage) > Changing TCP behavior on most systems requires modifying the kernel. Having something built so that it could be modified in user space really was important. UDP is just a demux for QUIC and that's a success because it enabled all of the other functionality to go up into the user space. Just my perspective, Ted --000000000000982d970590cea85f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

On Fri, Aug 23, 2019 at 11:48 AM Chris Morr= ow <morrowc@ops-netman.net= > wrote:

I had figured quic was really an admission that: "Adding a new tcp/udp=
like protocol was much harder to swallow for the internet than just
re-using an existing thing (UDP)."

quic COULD have just as easily been done over tcp, esp, ah, icmp ...
all of those come with some baggage though, which UDP didn't have.
(admittedly udp has it's own baggage)
=C2=A0
=
Changing TCP behavior on most systems requ= ires modifying the kernel.=C2=A0 Having something built so that it could be= modified in user space really was important.=C2=A0 UDP is just a demux for= QUIC and that's a success because it enabled all of the other function= ality to go up into the user space.
Just my perspective,

Ted
--000000000000982d970590cea85f-- From nobody Fri Aug 23 13:41:19 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99B2120878 for ; Fri, 23 Aug 2019 13:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=apple.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 xqsW5nTks_Bc for ; Fri, 23 Aug 2019 13:41:08 -0700 (PDT) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1956C120124 for ; Fri, 23 Aug 2019 13:41:02 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id x7NKb5Vv058731; Fri, 23 Aug 2019 13:40:59 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=5CNfteflmy81IAc0CJSEWkTugFuztQ2AdT1CW2B3CFo=; b=Mq6c3dixsp0XJIXLu711dak2DcCzk29A3VzZqVLBi/9mnVmcGuzFrupmLJ9I2wwThvUJ W2Mn1EYS8amxTlJS1xoQgHkw9qxri8zbZ2eW3XfOFHKPlbGuGQVQGdnKEXrDX6tUieZS fuXrjNaln7Mo51/nLR4IeBNRZ4xMCR7fpkQifzH+u09GLGuZxhaxdZhp34cIkyRmfuF+ Z9CdFC/xfiLjgsaoghYsHTpIqNTEci+Du89TQFE1sxQdork8JcPFPPOu+6MiH8mag/u2 Op7PZ7hdHCH3Lcp833UIuHsoA7HYnTgjkTwcUix4/y+7pJBddlEkuM8TwA4XuYA+qwEi pQ== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2uegkafwxa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 23 Aug 2019 13:40:59 -0700 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PWP00BHEISAYGC0@ma1-mtap-s03.corp.apple.com>; Fri, 23 Aug 2019 13:40:59 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PWP00300IRK7S00@nwk-mmpp-sz09.apple.com>; Fri, 23 Aug 2019 13:40:59 -0700 (PDT) X-Va-A: X-Va-T-CD: 0613c62973e0edaa536c346ace790f0c X-Va-E-CD: dd1afc614a39dd0ea07087a02e889714 X-Va-R-CD: a76eefe8fdf227aa1290bbd803b8d89a X-Va-CD: 0 X-Va-ID: 6c0905af-aff6-4a56-bf87-8c39f9230cb5 X-V-A: X-V-T-CD: 0613c62973e0edaa536c346ace790f0c X-V-E-CD: dd1afc614a39dd0ea07087a02e889714 X-V-R-CD: a76eefe8fdf227aa1290bbd803b8d89a X-V-CD: 0 X-V-ID: 20dbbece-270c-478e-b6d2-87a958cd5c6d X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-08-23_09:,, signatures=0 Received: from [17.234.101.126] by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PWP00LBUISBLI50@nwk-mmpp-sz09.apple.com>; Fri, 23 Aug 2019 13:40:59 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <458317DA-FC1C-4A24-B4CF-6F34DD579B1D@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_91B110BC-C8AE-4E2D-8CAF-60D7A49D285C" MIME-version: 1.0 (Mac OS X Mail 12.4 \(3445.104.2\)) Date: Fri, 23 Aug 2019 13:40:54 -0700 In-reply-to: Cc: Chris Morrow , architecture-discuss@iab.org To: Ted Hardie References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> X-Mailer: Apple Mail (2.3445.104.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-23_09:, , signatures=0 Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 20:41:17 -0000 --Apple-Mail=_91B110BC-C8AE-4E2D-8CAF-60D7A49D285C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Aug 23, 2019, at 1:28 PM, Ted Hardie wrote: >=20 > Howdy, >=20 > On Fri, Aug 23, 2019 at 11:48 AM Chris Morrow > wrote: >=20 > I had figured quic was really an admission that: "Adding a new tcp/udp > like protocol was much harder to swallow for the internet than just > re-using an existing thing (UDP)." >=20 > quic COULD have just as easily been done over tcp, esp, ah, icmp ... > all of those come with some baggage though, which UDP didn't have. > (admittedly udp has it's own baggage) > =20 > Changing TCP behavior on most systems requires modifying the kernel. = Having something built so that it could be modified in user space really = was important. UDP is just a demux for QUIC and that's a success = because it enabled all of the other functionality to go up into the user = space. +1 I think this argument goes even deeper than the convenience of being = able to easily modify kernel code or not, too. The platform I work on has support for TCP in user-space, so when we = want to do experiments, it's just as easy as modifying QUIC. Putting the = logic for flow control, congestion control, etc, in to a userspace = process is very convenient and a useful feature. However, the one bit of work that remains crucial for the kernel to do = in a multi-process system is demultiplexing inbound packets to the = correct processes responsible for flows by port. Having a reusable = protocol header that lets us demultiplex, rather than teaching the = kernel how to switch for a new kind of identifier for every new IP = protocol, is really important. If you want to define a new protocol on = bare IP, you either are stuck with the raw IP socket model, in which = either only one process gets everything for a protocol, or all processes = get everything; or you need to modify the kernel for every kind of = demultiplexing identifier you invent. What we've learned is that the = port-level demux is simple and reusable, and not useful to change much; = while the higher-order notions of richer transport protocols is useful = to be able to modify and evolve independently. Best, Tommy >=20 > Just my perspective, >=20 > Ted > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss --Apple-Mail=_91B110BC-C8AE-4E2D-8CAF-60D7A49D285C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Aug 23, 2019, at 1:28 PM, Ted Hardie <ted.ietf@gmail.com> = wrote:

Howdy,

On Fri, Aug 23, 2019 at 11:48 AM Chris Morrow = <morrowc@ops-netman.net> wrote:

I had figured quic was really an admission that: "Adding a new = tcp/udp
like protocol was much harder to swallow for the internet than just
re-using an existing thing (UDP)."

quic COULD have just as easily been done over tcp, esp, ah, icmp ...
all of those come with some baggage though, which UDP didn't have.
(admittedly udp has it's own baggage)
 
Changing TCP = behavior on most systems requires modifying the kernel.  Having = something built so that it could be modified in user space really was = important.  UDP is just a demux for QUIC and that's a success = because it enabled all of the other functionality to go up into the user = space.

+1

I think this = argument goes even deeper than the convenience of being able to easily = modify kernel code or not, too.

The = platform I work on has support for TCP in user-space, so when we want to = do experiments, it's just as easy as modifying QUIC. Putting the logic = for flow control, congestion control, etc, in to a userspace process is = very convenient and a useful feature.

However, the one bit of work that remains crucial = for the kernel to do in a multi-process system is demultiplexing inbound = packets to the correct processes responsible for flows by port. Having a = reusable protocol header that lets us demultiplex, rather than teaching = the kernel how to switch for a new kind of identifier for every new IP = protocol, is really important. If you want to define a new protocol on = bare IP, you either are stuck with the raw IP socket model, in which = either only one process gets everything for a protocol, or all processes = get everything; or you need to modify the kernel for every kind of = demultiplexing identifier you invent. What we've learned is that the = port-level demux is simple and reusable, and not useful to change much; = while the higher-order notions of richer transport protocols is useful = to be able to modify and evolve independently.

Best,
Tommy


Just my = perspective,

Ted
_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discuss

= --Apple-Mail=_91B110BC-C8AE-4E2D-8CAF-60D7A49D285C-- From nobody Fri Aug 23 13:41:48 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A4512023E for ; Fri, 23 Aug 2019 13:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 Doqw2YmHkDvn for ; Fri, 23 Aug 2019 13:41:45 -0700 (PDT) Received: from relay.kvm02.ops-netman.net (relay.kvm02.ops-netman.net [IPv6:2606:700:e:550:5c82:28ff:fe25:4960]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 075E3120128 for ; Fri, 23 Aug 2019 13:41:44 -0700 (PDT) Received: from mail.ops-netman.net (mailserver.ops-netman.net [199.168.90.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relay.kvm02.ops-netman.net (Postfix) with ESMTPS id C7A8A3FDAA; Fri, 23 Aug 2019 20:41:43 +0000 (UTC) Received: from mailserver.ops-netman.net.ops-netman.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 6DA853C2; Fri, 23 Aug 2019 20:41:43 +0000 (UTC) Date: Fri, 23 Aug 2019 20:41:43 +0000 Message-ID: <87ftlrvcl4.wl-morrowc@ops-netman.net> From: Chris Morrow To: Ted Hardie Cc: Chris Morrow , Fernando Gont , architecture-discuss@iab.org In-Reply-To: References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 20:41:46 -0000 On Fri, 23 Aug 2019 20:28:43 +0000, Ted Hardie wrote: > > [1 ] > Howdy, > > On Fri, Aug 23, 2019 at 11:48 AM Chris Morrow > wrote: > > > > > I had figured quic was really an admission that: "Adding a new tcp/udp > > like protocol was much harder to swallow for the internet than just > > re-using an existing thing (UDP)." > > > > quic COULD have just as easily been done over tcp, esp, ah, icmp ... > > all of those come with some baggage though, which UDP didn't have. > > (admittedly udp has it's own baggage) > > > > Changing TCP behavior on most systems requires modifying the kernel. sure, and permitting though/around/over/etc all the various 'firewall' things (not to mention that security NAT device) is also .. fun. > Having something built so that it could be modified in user space really > was important. UDP is just a demux for QUIC and that's a success because > it enabled all of the other functionality to go up into the user space. > agree, just saying that there are lots of reasons why: "picked udp, not X". but that really ... as fernando said any other number would have also worked... except that UDP has pretty universal access end-to-end without molestation AND it's not something kernels generally do much with except: "here ya go socket listener!" > Just my perspective, thanks! (I also have a perspective! which I hope gets better with new glasses) :) -chris From nobody Sat Aug 24 13:01:37 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3BD912006E; Sat, 24 Aug 2019 13:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 8VNGbL_SdLl2; Sat, 24 Aug 2019 13:01:32 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E421A120046; Sat, 24 Aug 2019 13:01:30 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7OK1Pjs000370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 24 Aug 2019 16:01:28 -0400 Date: Sat, 24 Aug 2019 15:01:25 -0500 From: Benjamin Kaduk To: architecture-discuss@ietf.org, iab@iab.org Message-ID: <20190824200124.GL60855@kduck.mit.edu> References: <156641157393.25789.13597724381522897325.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <156641157393.25789.13597724381522897325.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] Call for Comment: (Defining the Role and Function of IETF Protocol Parameter Registry Operators) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2019 20:01:35 -0000 On Wed, Aug 21, 2019 at 11:19:33AM -0700, IAB Executive Administrative Manager wrote: > This is an announcement of an IETF-wide Call for Comment on > draft-ietf-iasa2-rfc6220bis-03. > > The document is being considered for publication as an Informational RFC > within the IAB stream, and is available for inspection at: > > > The Call for Comment will last until 2019-09-18. Please send comments to > architecture-discuss@ietf.org and iab@iab.org. As preface, I note that the IAB is not formally constrained by the charter of the IASA 2.0 WG, but may choose to act consistently with it (in which case some of these comments are out of scope for being unrelated to the LLC transition). Section 1 references the "IETF Internet Standards Process [RFC2026]", which might be spelled better as BCP 9. Section 2 uses DHCP and IPsec as examples; are these sufficiently well-known that no informative reference to them is needed? Section 2.1 talks about IANA being direted to register values "as directed by [...] Proposed, Draft, and full Internet Standards", which is a bit stale with respect to "Draft" standards (though not strictly inaccurate in the full context). In Section 2.1: o Mailing Lists * The Registry Operator maintains public mailing lists as specified in IANA Considerations [RFC8126]. Such lists are It might be worth clarifying whether "public" means archives, subscription, and/or posting. Reporting * The Registry Operator will submit periodic reports to the IAB concerning the operational performance of the registry function. As an example of the requirements for such reports, the reader is referred to a supplement [MoU_SUPP2018] to the "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority" [RFC2860] that provides service level agreement (SLA) guidelines under which ICANN, the current protocol parameter registry, must operate. I did not think that ICANN was the current primary protocol parameter registry operator. o Intellectual Property Rights and the Registry Operator * All assigned values are to be published and made available free of any charges. * The assignment values may be redistributed without modification. These clauses seem to be in conflict with the earlier text about "special circumstances" that might allow for a closed registry. It's also unclear how this interacts with the Trust's role, as specified in Section 2.4: The IETF Trust may make such regulations as appropriate for the redistribution of assignment values and registry publications. In Section 2.5: In addition, the IETF LLC has the responsibility to ensure long-term access, stability, and uniqueness across all such registries. This Ensuring uniqueness seems rather different from the other two, and on the face of it would seem to require rather invasive interaction with the actual registry operator. Do I misunderstand the sense in which this is intended? Section 4 notes that there are no new protocols, and concludes that there are no new security considerations. To a large extent this is true, and even if there are security considerations to operating a public, available registry and maintaining the integrity of its contents, those concerns are arguably divorced from the administrative structure of how the registry operator is selected. Appendix A notes that the IASA 2.0 update was in 2018, though we're well into 2019 at this point. Thanks, Ben From nobody Sun Aug 25 08:58:05 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6024E1207FD for ; Sun, 25 Aug 2019 08:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 tvD6hdNqaA2J for ; Sun, 25 Aug 2019 08:58:02 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F50F1201DB for ; Sun, 25 Aug 2019 08:58:02 -0700 (PDT) Received: from [192.168.1.25] (ppp-94-69-228-106.home.otenet.gr [94.69.228.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 547DF862E5; Sun, 25 Aug 2019 17:57:57 +0200 (CEST) To: Ted Hardie , Chris Morrow Cc: architecture-discuss@iab.org References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Sun, 25 Aug 2019 16:59:57 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 15:58:05 -0000 On 23/8/19 23:28, Ted Hardie wrote: > Howdy, > > On Fri, Aug 23, 2019 at 11:48 AM Chris Morrow > wrote: > > > I had figured quic was really an admission that: "Adding a new tcp/udp > like protocol was much harder to swallow for the internet than just > re-using an existing thing (UDP)." > > quic COULD have just as easily been done over tcp, esp, ah, icmp ... > all of those come with some baggage though, which UDP didn't have. > (admittedly udp has it's own baggage) > >   > Changing TCP behavior on most systems requires modifying the kernel.  > Having something built so that it could be modified in user space really > was important.  UDP is just a demux for QUIC and that's a success > because it enabled all of the other functionality to go up into the user > space. I agree with the above, still, the reason for which QUIC employs UDP (rather than doing mux/demux by itself) is because you can't deploy new transport protocols on the Internet. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Aug 25 09:58:33 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653B3120033 for ; Sun, 25 Aug 2019 09:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 BaXVgPc_cn0s for ; Sun, 25 Aug 2019 09:58:17 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id BCF981200F7 for ; Sun, 25 Aug 2019 09:58:17 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 808DE908841; Sun, 25 Aug 2019 12:48:39 -0400 (EDT) Date: Sun, 25 Aug 2019 12:48:39 -0400 From: John Leslie To: Fernando Gont Cc: Ted Hardie , Chris Morrow , architecture-discuss@iab.org Message-ID: <20190825164839.GA77144@verdi> References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 16:58:19 -0000 Fernando Gont wrote: > > I agree with the above, still, the reason for which QUIC employs UDP > (rather than doing mux/demux by itself) is because you can't deploy new > transport protocols on the Internet. Yes, QUIC employs UDP because they despaired of deploying a new transport protocol. However, architecture-discuss@iab.org _really_shouldn't_ abandon hope of deploying a new transport protocol: it's _hard_; it may not happen in my lifetime; but the Internet, or its replacement, _will_ need a new transport procotol some day... -- John Leslie From nobody Sun Aug 25 10:07:44 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8250D12008B for ; Sun, 25 Aug 2019 10:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 W-YmfHN-fCqX for ; Sun, 25 Aug 2019 10:07:42 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11D41120033 for ; Sun, 25 Aug 2019 10:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=J1di768pwZXRiJ8sZ2e2zdvLVEjwxihzW22+mlCcvWY=; b=F8wnxoi0qFpyubHx48y5+kz/0 AZndl1cH6Co+HleWmYkRLWPNm6E276Yi6YcWlRjI9eY2+g4iGK8BVHvzBBRAW9BJlfuKEU2IGiegF ajQujLrftnDgn6YS5RxvCAhkNlKfsTJsBYSevTOIOfB46Bm+o5YzD/fs5g+zjHU1f/wFk2L4er6/U SJDA3npXb1O2y7Z1TcToqKtO0Mpo21RZjJpIzNE0gZA04c4qi0KYnmONwsCImRSTH59nzSlQk7v4G +SBGfKBTj17HS2NZvsdExFmBCcYq3EU2gG+F2PGxudVeTUZYrpT5uJFXpvU8RaNplCOCClAOWvq3A mkAGQ79xA==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:52326 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1i1vzL-000s1F-K4; Sun, 25 Aug 2019 13:07:40 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_C671DBED-C198-4279-80B2-264A8C32A675" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: <20190825164839.GA77144@verdi> Date: Sun, 25 Aug 2019 10:07:34 -0700 Cc: Fernando Gont , architecture-discuss@iab.org Message-Id: <715FF08E-9DD1-4052-BE1D-3C3AA614B560@strayalpha.com> References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> <20190825164839.GA77144@verdi> To: John Leslie X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 17:07:44 -0000 --Apple-Mail=_C671DBED-C198-4279-80B2-264A8C32A675 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 25, 2019, at 9:48 AM, John Leslie wrote: >=20 > Yes, QUIC employs UDP because they despaired of deploying a new > transport protocol. >=20 > However, architecture-discuss@iab.org = _really_shouldn't_ abandon hope > of deploying a new transport protocol: it's _hard_; it may not happen = in > my lifetime; but the Internet, or its replacement, _will_ need a new > transport procotol some day... IMO, it has a chance of happening when the IETF =E2=80=9Cgrows up=E2=80=9D= . Trust, but VERIFY. The IETF started with the assumption that everyone wanted to play = together and play nice. That ship sailed decades ago. The missing step is to create a validation suite and corresponding = official endorsement of compliance. Without that, we=E2=80=99re constantly stuck with the tragedy of the = commons, which drives us to the worst of all implementations. Joe= --Apple-Mail=_C671DBED-C198-4279-80B2-264A8C32A675 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 25, 2019, at 9:48 AM, John Leslie <john@jlc.net> = wrote:

  Yes, QUIC employs = UDP because they despaired of deploying a new
transport protocol.

  However, architecture-discuss@iab.org _really_shouldn't_ abandon = hope
of deploying = a new transport protocol: it's _hard_; it may not happen in
my lifetime; but the Internet, = or its replacement, _will_ need a new
transport procotol some = day...

IMO, = it has a chance of happening when the IETF =E2=80=9Cgrows = up=E2=80=9D.

Trust, but VERIFY.

The IETF started with the assumption = that everyone wanted to play together and play nice. That ship sailed = decades ago.

The= missing step is to create a validation suite and corresponding official = endorsement of compliance.

Without that, we=E2=80=99re constantly stuck with the tragedy = of the commons, which drives us to the worst of all = implementations.

Joe
= --Apple-Mail=_C671DBED-C198-4279-80B2-264A8C32A675-- From nobody Sun Aug 25 11:07:37 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45FF1200E6 for ; Sun, 25 Aug 2019 11:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 BJ0LyY9i0qgN for ; Sun, 25 Aug 2019 11:07:34 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D49312006B for ; Sun, 25 Aug 2019 11:07:33 -0700 (PDT) Received: from xse435.mail2web.com ([66.113.197.181] helo=xse.mail2web.com) by mx26.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1i1wvI-00016i-W5 for architecture-discuss@iab.org; Sun, 25 Aug 2019 20:07:30 +0200 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 46Gjlb6lrTz1NcW for ; Sun, 25 Aug 2019 11:07:23 -0700 (PDT) Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1i1wvD-0004vc-Qv for architecture-discuss@iab.org; Sun, 25 Aug 2019 11:07:23 -0700 Received: (qmail 14635 invoked from network); 25 Aug 2019 18:07:23 -0000 Received: from unknown (HELO [192.168.1.108]) (Authenticated-user:_huitema@huitema.net@[172.58.43.232]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Aug 2019 18:07:23 -0000 To: Fernando Gont Cc: architecture-discuss@iab.org References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <19058eaf-47e9-7cac-bf34-cfef646a9bd6@huitema.net> Date: Sun, 25 Aug 2019 11:07:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 66.113.197.181 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0ZMJr/TGkEWvNJbVmORegSypSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDeW3+HZ7LK0h6oEMb2VkOa5vM xCtZSe87wnSOA0YTnlDnx8yeplRO3sLIqUlSH7OGcUO7SezXDs54HThzUhdYc4MlhcTgOXSCz8qb ysTVYVkMDlXDa3aVnxGK2HywWN/na5BmpNDk1uVHURtICSxoJpnckpWaLvahyBjmQxBKOztp0ugt Zlkw9p/AQdIE0knw7cPlLc4mPp21O6mudLBF4/IRL+spW60mrWiAEnQcn/qslg3CoCHsPz6pr/Ao kdAPhX8u3xIOOtB59sWJ1mr0rcswIlm249d1OOo21hSM9tXB1/2M1shZO++tsIV90EPuboZD5vPF e84pJQGk5dfbFPdfcXgLzsY3kBHC+ZTZl3RnfVPTqI4dkGNDDD1o0bE1YTJl/Vbyro+qbGZaEKoG AcB9K/tfe8pLmJg0fcGy9gwRLqjTJeBPrTCjLL/wN7uMRUcRfS0hzbGRZdtpa0UZ/x9JJ5TIDkE1 afsdX6NhD5tQoXEoUQ5xBm1bXvz0ANWAG9EmxwCgp0YefUIP3QRByd8korn66oPlliJmYx7BhK0y kekYEOrHDP6AyZ4YcksZDfa4AYteW755iVMu5eF/Ep/BwjmOaPTuAXk5W6cBes0MhGfTGKeYohdq JlHBQlshpdq74RdZFEV+tExsF6fSu0vcvbjW7NQ6sDu9dQojc3MXDkSssrDzjdBxahkvbpl3ulfN 8uXxCZIbUCwvPJODHHLYM3A6BXfvel8OEFDbU52pkg3mxKYN7Bc5PdZURX84VV7AX8ZI+yNYzuQl HaWUqTVjn0ct4reaW46myUBetVNddn8KKfQU2n19Ayh48sIRmzvvJzEWC/ZHpFS+HYcdOon5y/vc IKE4+MoDT8NV3zdM7Ahub8TBeVhtYGLHDQnyEj+FTyUVIz4E3+N7ec+ThjDIZMcgCg0Vf6NxbsMa Z0R5yhTi9qm8IZJSHpFdJ5bb X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 18:07:35 -0000 On 8/25/2019 6:59 AM, Fernando Gont wrote: > I agree with the above, still, the reason for which QUIC employs UDP > (rather than doing mux/demux by itself) is because you can't deploy new= > transport protocols on the Internet. I think we are getting caught in disputes over vocabulary. Two things are true at the same time: 1) We cannot send packets in which the IP protocol or IPv6 payload type is set to a different value than TCP or UDP and expect them to reach destinations across the Internet. 2) QUIC, BitTorrent and SCTP demonstrate that you can run a protocol on top of UDP that has all the characteristics of a classic transport protocol, including error recovery and congestion control. ( QUIC can perform mux/demux by itself, using the "connection ID" field, but most deployments refrain from using multiple layers of multiplexing.) Using UDP causes 8 bytes of overhead per packet, which is unfortunate. You may call that a middle-box tax if you want. But as long as you are willing to pay that tax, you can of course deploy new transmission control protocols over the Internet. Most people will call them transport protocols. -- Christian Huitema From nobody Sun Aug 25 11:08:06 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA5D12080B for ; Sun, 25 Aug 2019 11:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 A9rdvWmhiotU for ; Sun, 25 Aug 2019 11:08:02 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B0512006B for ; Sun, 25 Aug 2019 11:08:01 -0700 (PDT) Received: from [192.168.1.2] (ppp-94-69-228-39.home.otenet.gr [94.69.228.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id B7A4D8636F; Sun, 25 Aug 2019 20:07:59 +0200 (CEST) To: John Leslie Cc: Ted Hardie , Chris Morrow , architecture-discuss@iab.org References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> <20190825164839.GA77144@verdi> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <1b872d8d-e932-d212-478d-4cc0da1255ec@si6networks.com> Date: Sun, 25 Aug 2019 21:05:28 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190825164839.GA77144@verdi> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 18:08:04 -0000 On 25/8/19 19:48, John Leslie wrote: > Fernando Gont wrote: >> >> I agree with the above, still, the reason for which QUIC employs UDP >> (rather than doing mux/demux by itself) is because you can't deploy new >> transport protocols on the Internet. > > Yes, QUIC employs UDP because they despaired of deploying a new > transport protocol. Well, that's my point. And me being puzzled about the IAB statement saying that it is possible to deploy new transport protocolon the *I*nternet, when it seems to be quite the oposite. > However, architecture-discuss@iab.org _really_shouldn't_ abandon hope > of deploying a new transport protocol: it's _hard_; it may not happen in > my lifetime; but the Internet, or its replacement, _will_ need a new > transport procotol some day... I tend to associate hope with religion, rather than engineering. :-) Certainly, hope will not get us there. Probably nothing will... but if there's any chance that something that will, it's certainly not 'hope' but some sort of action -- whatever it is. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Aug 25 11:08:17 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307A9120835 for ; Sun, 25 Aug 2019 11:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 1dVQsd81SQHE for ; Sun, 25 Aug 2019 11:08:08 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D166612081F for ; Sun, 25 Aug 2019 11:08:07 -0700 (PDT) Received: from [192.168.1.2] (ppp-94-69-228-39.home.otenet.gr [94.69.228.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id ECE228636B; Sun, 25 Aug 2019 20:08:02 +0200 (CEST) To: Joe Touch , John Leslie Cc: architecture-discuss@iab.org References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> <20190825164839.GA77144@verdi> <715FF08E-9DD1-4052-BE1D-3C3AA614B560@strayalpha.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Sun, 25 Aug 2019 21:07:05 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <715FF08E-9DD1-4052-BE1D-3C3AA614B560@strayalpha.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 18:08:16 -0000 On 25/8/19 20:07, Joe Touch wrote: > > >> On Aug 25, 2019, at 9:48 AM, John Leslie > > wrote: >> >>   Yes, QUIC employs UDP because they despaired of deploying a new >> transport protocol. >> >>   However, architecture-discuss@iab.org >>  _really_shouldn't_ abandon hope >> of deploying a new transport protocol: it's _hard_; it may not happen in >> my lifetime; but the Internet, or its replacement, _will_ need a new >> transport procotol some day... > > IMO, it has a chance of happening when the IETF “grows up”. > > Trust, but VERIFY. > > The IETF started with the assumption that everyone wanted to play > together and play nice. That ship sailed decades ago. > > The missing step is to create a validation suite and corresponding > official endorsement of compliance. You mean something along the lines of "If you want to claim you provide Internet connectivity, then you *must* support all this"? -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Aug 25 11:31:35 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5221200F7 for ; Sun, 25 Aug 2019 11:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.217 X-Spam-Level: X-Spam-Status: No, score=-1.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 FCUwjY3voTRd for ; Sun, 25 Aug 2019 11:31:33 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 559B21200B4 for ; Sun, 25 Aug 2019 11:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=eYN8nt0SFoUApC1Rp3t+yEsSFQiRDxPi8GYwSc1nXgo=; b=EhaNjxjso0krNkE4BujOMLxiE ZPQyhn8jODIe0awDE5Nohc9+jpylAFJbV7G2igaf0Vu/n69LuDHKiXwvp3b/3KoXUd7dASr8ksDSJ bF4WNPsARiWObO6WyiGiQVPRjYSxylDZiBE8IX3xqJ9SLocUP4Xs1R5ffKea5wkHZ0vIIrBgE6Hcf Gm6lIi+9xdDuRwYmX6j9C33eWzt9DtYwoDc55UDpmi4YYQQiRc2mXb7wxX5kRO8RaAgDVjcHzOOuE 22c4uOpS+Y3n2GDNI+fiBpIeDOvdkw9HyVDy9lRGjkUoJ+DOfIHPTbCMsFE9jQi9b8xFxI12uMGJo 7/+oDV14Q==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:57249 helo=[192.168.1.6]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1i1xIT-001sVk-Id; Sun, 25 Aug 2019 14:31:30 -0400 Content-Type: multipart/alternative; boundary=Apple-Mail-7BEEFD04-81B8-455B-B7B2-A507C05B6287 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (16G77) In-Reply-To: Date: Sun, 25 Aug 2019 11:31:25 -0700 Cc: John Leslie , architecture-discuss@iab.org Content-Transfer-Encoding: 7bit Message-Id: References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> <20190825164839.GA77144@verdi> <715FF08E-9DD1-4052-BE1D-3C3AA614B560@strayalpha.com> To: Fernando Gont X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 18:31:35 -0000 --Apple-Mail-7BEEFD04-81B8-455B-B7B2-A507C05B6287 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Aug 25, 2019, at 11:07 AM, Fernando Gont wrote:= >=20 >> On 25/8/19 20:07, Joe Touch wrote: >>=20 >>=20 >>> On Aug 25, 2019, at 9:48 AM, John Leslie >> > wrote: >>>=20 >>> Yes, QUIC employs UDP because they despaired of deploying a new >>> transport protocol. >>>=20 >>> However, architecture-discuss@iab.org >>> _really_shouldn't_ abandon hope >>> of deploying a new transport protocol: it's _hard_; it may not happen in= >>> my lifetime; but the Internet, or its replacement, _will_ need a new >>> transport procotol some day... >>=20 >> IMO, it has a chance of happening when the IETF =E2=80=9Cgrows up=E2=80=9D= . >>=20 >> Trust, but VERIFY. >>=20 >> The IETF started with the assumption that everyone wanted to play >> together and play nice. That ship sailed decades ago. >>=20 >> The missing step is to create a validation suite and corresponding >> official endorsement of compliance. >=20 > You mean something along the lines of "If you want to claim you provide > Internet connectivity, then you *must* support all this"? https://standards.ieee.org/content/ieee-standards/en/products-services/icap/= index.html >=20 >=20 > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 --Apple-Mail-7BEEFD04-81B8-455B-B7B2-A507C05B6287 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Aug 25, 2019, at 11:07 AM, Fernando Gont <= fgont@si6networks.com> wrote= :

On 25/8/19 2= 0:07, Joe Touch wrote:

=

On Aug 25, 2019, at 9:48 A= M, John Leslie <john@jlc.net
<mailto:john@jlc.net>>= ; wrote:

  Yes, QUIC employs U= DP because they despaired of deploying a new
transport pro= tocol.

  However, architecture-discuss@iab.org
<mailto:= architecture-discuss@iab.org> _really_shouldn't_ abandon hope
of deploying a new transport protocol: it's _hard_; it may n= ot happen in
<= blockquote type=3D"cite">my lifetime; but the Internet, or its replace= ment, _will_ need a new
transport procotol some day...

=
IMO, it has a chance of happeni= ng when the IETF =E2=80=9Cgrows up=E2=80=9D.

Trust, but VERIFY.

The IETF started w= ith the assumption that everyone wanted to play
together and play nice. That ship sailed decades a= go.

The missing step is to create a valid= ation suite and corresponding
official endorsement of compliance.

You mean something along the lines of "If you want to claim y= ou provide
Internet connectivity, then you *must* support al= l this"?






-- Fernando Gont
SI6 Networks
e-mail: <= a href=3D"mailto:fgont@si6networks.com">fgont@si6networks.com
= PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




<= /div>
= --Apple-Mail-7BEEFD04-81B8-455B-B7B2-A507C05B6287-- From nobody Sun Aug 25 12:17:23 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2951512010C for ; Sun, 25 Aug 2019 12:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 AFyBYyYnvJIP for ; Sun, 25 Aug 2019 12:17:19 -0700 (PDT) Received: from outprodmail02.cc.columbia.edu (outprodmail02.cc.columbia.edu [128.59.72.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A55120026 for ; Sun, 25 Aug 2019 12:17:18 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by outprodmail02.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id x7PJEq6d017587 for ; Sun, 25 Aug 2019 15:17:17 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 7BEF98A for ; Sun, 25 Aug 2019 15:17:17 -0400 (EDT) Received: from sendprodmail03.cc.columbia.edu (sendprodmail03.cc.columbia.edu [128.59.72.15]) by hazelnut (Postfix) with ESMTP id B2CC88D for ; Sun, 25 Aug 2019 15:17:16 -0400 (EDT) Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by sendprodmail03.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id x7PJHFrI017769 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sun, 25 Aug 2019 15:17:16 -0400 Received: by mail-qk1-f197.google.com with SMTP id d203so14127323qke.4 for ; Sun, 25 Aug 2019 12:17:15 -0700 (PDT) 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:from:date :message-id:subject:to:cc; bh=zNTJXp33m52fOEGfsuszGmAWGbzUutNFNVSMiluXRnY=; b=VKdBFCAQGzbm7T1YQFP/24k8jP5MsVxCpWEbeijTxCe+BiXNs2onsHKgKr27SMVNWn N6yZRVVMzKiEOk95bDRN7FGJynV2vzbMy6aTsyEyLbv+6CC0cXNdP8MKoDnlndhHMrDU JbD+Nkah8B/qUwp3YqgubaU9aeCXj5a0tCJOcdqjcYJWBY+2xZyyKqPKvemU0Gi5tn40 dXIk3V0sIBGeHoCBxidHVMgoLg4zxOw46lQrlPkTJC1c9k/UK55ClIh/UkK9UdwY98Jw 7LNuhsMjChz4xuNxkfFx/17fyzy4YLAG5jcROnSwCkme3+I2yQWrMKD8FumOuHOZHQ2w GczQ== X-Gm-Message-State: APjAAAXGetxRlzcjj8WCfO6mh4mvbCZwPW4BLgnzPJx03LTvb9vD0jju +uP5N1tmaF44IyTVGykvo9psAxKZdBkWttDCKKyTqc1d0mnX3oxCSBM0p22/I+NdAwq3n5VuJdS YzMARKZeOWuonJszbG9S5UmqFeUahZNnoXyJVd5xE7no9EwpL X-Received: by 2002:a05:620a:14bc:: with SMTP id x28mr12959439qkj.116.1566760635404; Sun, 25 Aug 2019 12:17:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqx+DfnKNarXRy1HNgbkVmRBYt8vJxLp5Cg1bJYpE6037/Cyi7SEvcmjFjyOVnITPu9lEvbv/6ZC+0noayXnqQo= X-Received: by 2002:a05:620a:14bc:: with SMTP id x28mr12959425qkj.116.1566760635076; Sun, 25 Aug 2019 12:17:15 -0700 (PDT) MIME-Version: 1.0 References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> <20190825164839.GA77144@verdi> <715FF08E-9DD1-4052-BE1D-3C3AA614B560@strayalpha.com> In-Reply-To: <715FF08E-9DD1-4052-BE1D-3C3AA614B560@strayalpha.com> From: Henning Schulzrinne Date: Sun, 25 Aug 2019 15:16:48 -0400 Message-ID: To: Joe Touch Cc: John Leslie , architecture-discuss@iab.org Content-Type: multipart/alternative; boundary="0000000000001a232c0590f5e398" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.84 on 128.59.72.15 Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 19:17:21 -0000 --0000000000001a232c0590f5e398 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Some of us who worked on the Open Internet (aka network neutrality) saw "protocol neutrality" as very much part of the same spirit and possibly a legal entitlement of customers. And the issue of naming "Internet access" implying some obligations was also part of the discussion. Experience seems to indicate that only legal or regulatory requirements are likely to lead there, given that many carriers have no economic interest to do this - and carrier-grade NATs make it painful or impossible to move beyond TCP and UDP= . Henning On Sun, Aug 25, 2019 at 1:07 PM Joe Touch wrote: > > > On Aug 25, 2019, at 9:48 AM, John Leslie wrote: > > Yes, QUIC employs UDP because they despaired of deploying a new > transport protocol. > > However, architecture-discuss@iab.org _really_shouldn't_ abandon hope > of deploying a new transport protocol: it's _hard_; it may not happen in > my lifetime; but the Internet, or its replacement, _will_ need a new > transport procotol some day... > > > IMO, it has a chance of happening when the IETF =E2=80=9Cgrows up=E2=80= =9D. > > Trust, but VERIFY. > > The IETF started with the assumption that everyone wanted to play togethe= r > and play nice. That ship sailed decades ago. > > The missing step is to create a validation suite and corresponding > official endorsement of compliance. > > Without that, we=E2=80=99re constantly stuck with the tragedy of the comm= ons, > which drives us to the worst of all implementations. > > Joe > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --0000000000001a232c0590f5e398 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Some of us who worked on the Open Internet (aka network ne= utrality) saw "protocol neutrality" as very much part of the same= spirit and possibly a legal entitlement of customers. And the issue of nam= ing "Internet access" implying some obligations was also part of = the discussion. Experience seems to indicate that only legal or regulatory = requirements are likely to lead there, given that many carriers have no eco= nomic interest to do this - and carrier-grade NATs make it painful or impos= sible to move beyond TCP and UDP.

Henning
On Sun, A= ug 25, 2019 at 1:07 PM Joe Touch <touch@strayalpha.com> wrote:

On Aug 25, 2019, at 9:48 AM, John Leslie &= lt;john@jlc.net> w= rote:

=C2=A0=C2=A0Yes, Q= UIC employs UDP because they despaired of deploying a new
transport protoc= ol.

=C2=A0=C2=A0However,=C2=A0architecture-discuss@iab.org=C2=A0_really_shouldn't_ aba= ndon hope
of deploying a new transport protocol: it's _hard_; it may not= happen in
my lifetime; but the Internet, or its replacement, _will_ need a = new
transport procotol some day...

I= MO, it has a chance of happening when the IETF =E2=80=9Cgrows up=E2=80=9D.<= /div>

Trust, but VERIFY.

The IE= TF started with the assumption that everyone wanted to play together and pl= ay nice. That ship sailed decades ago.

The missing= step is to create a validation suite and corresponding official endorsemen= t of compliance.

Without that, we=E2=80=99re const= antly stuck with the tragedy of the commons, which drives us to the worst o= f all implementations.

Joe
____________= ___________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--0000000000001a232c0590f5e398-- From nobody Sun Aug 25 12:27:07 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BDD120058 for ; Sun, 25 Aug 2019 12:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 TZsccHJs1Dnj for ; Sun, 25 Aug 2019 12:27:04 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4D74412004D for ; Sun, 25 Aug 2019 12:27:04 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 6123D908893; Sun, 25 Aug 2019 15:26:54 -0400 (EDT) Date: Sun, 25 Aug 2019 15:26:54 -0400 From: John Leslie To: Fernando Gont Cc: John Leslie , Ted Hardie , Chris Morrow , architecture-discuss@iab.org Message-ID: <20190825192654.GA78819@verdi> References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> <20190825164839.GA77144@verdi> <1b872d8d-e932-d212-478d-4cc0da1255ec@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1b872d8d-e932-d212-478d-4cc0da1255ec@si6networks.com> User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 19:27:06 -0000 Fernando Gont wrote: > On 25/8/19 19:48, John Leslie wrote: > > However, architecture-discuss@iab.org _really_shouldn't_ abandon hope >> of deploying a new transport protocol: it's _hard_; it may not happen in >> my lifetime; but the Internet, or its replacement, _will_ need a new >> transport procotol some day... > > I tend to associate hope with religion, rather than engineering. :-) Actually, religion is about "belief," not "hope". "Hope" is about imagining a future; and implies that it's a future we _might_ agree to work towards. (A religious person might pray for God's help; but _anyone_ could keep the idea in mind in case something changes.) > Certainly, hope will not get us there. Probably nothing will... but if > there's any chance that something that will, it's certainly not 'hope' > but some sort of action -- whatever it is. I won't argue lingustics here. You're welcome to substitute your own word. My point is that we shouldn't rule out a future where we _can_ deploy a new transport protocol, even if we believe it "too hard" right now. -- John Leslie From nobody Sun Aug 25 12:39:36 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E367C12004D for ; Sun, 25 Aug 2019 12:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 mtpUoa3h-nHF for ; Sun, 25 Aug 2019 12:39:32 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 594DB12004A for ; Sun, 25 Aug 2019 12:39:32 -0700 (PDT) Received: from [192.168.1.2] (ppp-94-69-228-39.home.otenet.gr [94.69.228.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id C7A7A8633D; Sun, 25 Aug 2019 21:39:28 +0200 (CEST) To: Henning Schulzrinne , Joe Touch Cc: architecture-discuss@iab.org References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> <20190825164839.GA77144@verdi> <715FF08E-9DD1-4052-BE1D-3C3AA614B560@strayalpha.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <8e8a8660-1b90-6fdb-af8f-dc545e12c7d4@si6networks.com> Date: Sun, 25 Aug 2019 22:31:40 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 19:39:35 -0000 On 25/8/19 22:16, Henning Schulzrinne wrote: > Some of us who worked on the Open Internet (aka network neutrality) saw > "protocol neutrality" as very much part of the same spirit and possibly > a legal entitlement of customers. And the issue of naming "Internet > access" implying some obligations was also part of the discussion. > Experience seems to indicate that only legal or regulatory requirements > are likely to lead there, given that many carriers have no economic > interest to do this - and carrier-grade NATs make it painful or > impossible to move beyond TCP and UDP. You probably wished to blame just CGNATs for that. Unfortunately, you can't: see RFC7872. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Aug 25 12:39:51 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DABB312081C for ; Sun, 25 Aug 2019 12:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 3DIzaARPoSBa for ; Sun, 25 Aug 2019 12:39:41 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5E3712082A for ; Sun, 25 Aug 2019 12:39:40 -0700 (PDT) Received: from [192.168.1.2] (ppp-94-69-228-39.home.otenet.gr [94.69.228.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 7ECF98636F; Sun, 25 Aug 2019 21:39:35 +0200 (CEST) To: John Leslie Cc: Ted Hardie , Chris Morrow , architecture-discuss@iab.org References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> <20190825164839.GA77144@verdi> <1b872d8d-e932-d212-478d-4cc0da1255ec@si6networks.com> <20190825192654.GA78819@verdi> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <69fce13d-8f43-d65f-63f4-9c514008dfe1@si6networks.com> Date: Sun, 25 Aug 2019 22:35:50 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190825192654.GA78819@verdi> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 19:39:50 -0000 On 25/8/19 22:26, John Leslie wrote: > Fernando Gont wrote: >> On 25/8/19 19:48, John Leslie wrote: >>> However, architecture-discuss@iab.org _really_shouldn't_ abandon hope >>> of deploying a new transport protocol: it's _hard_; it may not happen in >>> my lifetime; but the Internet, or its replacement, _will_ need a new >>> transport procotol some day... >> >> I tend to associate hope with religion, rather than engineering. :-) > > Actually, religion is about "belief," not "hope". With hope usually supported by a belief that just can't be scientifically proven. > "Hope" is about imagining a future; and implies that it's a future we > _might_ agree to work towards. (A religious person might pray for God's > help; but _anyone_ could keep the idea in mind in case something changes.) > >> Certainly, hope will not get us there. Probably nothing will... but if >> there's any chance that something that will, it's certainly not 'hope' >> but some sort of action -- whatever it is. > > I won't argue lingustics here. You're welcome to substitute your own > word. My point is that we shouldn't rule out a future where we _can_ > deploy a new transport protocol, even if we believe it "too hard" right > now. If you are to deploy a new transport protocol, you essentially have two options: 1) Deploy it as a "native" transport protocol, and fail miserably 2) Tunel/encapsulate it into something that actually works. I see why Google folks opted for 2), and don't seem to find a reason for folks doing 1). At the end of the day, if "it doesn't work", you can complain, and assign blames... but it still won't work. :-) -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Aug 25 12:41:39 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D841200F7 for ; Sun, 25 Aug 2019 12:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 42qbHqL1HFA3 for ; Sun, 25 Aug 2019 12:41:36 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4470E12004D for ; Sun, 25 Aug 2019 12:41:36 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id B4957908893; Sun, 25 Aug 2019 15:41:35 -0400 (EDT) Date: Sun, 25 Aug 2019 15:41:35 -0400 From: John Leslie To: Christian Huitema Cc: Fernando Gont , architecture-discuss@iab.org Message-ID: <20190825194135.GB78819@verdi> References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> <19058eaf-47e9-7cac-bf34-cfef646a9bd6@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19058eaf-47e9-7cac-bf34-cfef646a9bd6@huitema.net> User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 19:41:37 -0000 Christian Huitema wrote: > > I think we are getting caught in disputes over vocabulary. Two things > are true at the same time: > > 1) We cannot send packets in which the IP protocol or IPv6 payload type > is set to a different value than TCP or UDP and expect them to reach > destinations across the Internet. We certainly _can_ send different payload types. We _can_ design protocols which check whether those payload types are received. There are other approaches which _today_ seem much more practical. > 2) QUIC, BitTorrent and SCTP demonstrate that you can run a protocol on > top of UDP that has all the characteristics of a classic transport > protocol, including error recovery and congestion control. ( QUIC can > perform mux/demux by itself, using the "connection ID" field, but most > deployments refrain from using multiple layers of multiplexing.) Absolutely true! > Using UDP causes 8 bytes of overhead per packet, which is unfortunate. True. We chose the wrong size limits 25 years ago. Next time I hope we'll know better. (25 years ago, 8 bytes of overhead was significant by itself.) > You may call that a middle-box tax if you want. But as long as you are > willing to pay that tax, you can of course deploy new transmission > control protocols over the Internet. Most people will call them > transport protocols. Actually, what we call them _does_ make a real difference. I'd be happy to call them "transport protocols"... -- John Leslie From nobody Sun Aug 25 12:48:13 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B42212004D for ; Sun, 25 Aug 2019 12:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 scPV-PbXnfIH for ; Sun, 25 Aug 2019 12:48:09 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44C4412004A for ; Sun, 25 Aug 2019 12:48:09 -0700 (PDT) Received: from [192.168.1.2] (ppp-94-69-228-39.home.otenet.gr [94.69.228.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 4E151863AF; Sun, 25 Aug 2019 21:39:42 +0200 (CEST) To: Henning Schulzrinne , Joe Touch Cc: architecture-discuss@iab.org References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> <20190825164839.GA77144@verdi> <715FF08E-9DD1-4052-BE1D-3C3AA614B560@strayalpha.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <5afd2499-6fdb-3e15-4504-52a8f6435d98@si6networks.com> Date: Sun, 25 Aug 2019 22:37:46 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2019 19:48:11 -0000 On 25/8/19 22:16, Henning Schulzrinne wrote: > Some of us who worked on the Open Internet (aka network neutrality) saw > "protocol neutrality" as very much part of the same spirit and possibly > a legal entitlement of customers. That's easier said than done. See e.g.: https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops A big part of the solution is: who's willing to pay the associated bill? -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Aug 25 20:41:03 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0F51200E0 for ; Sun, 25 Aug 2019 20:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 XyOY57qIPNNZ for ; Sun, 25 Aug 2019 20:41:00 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A225B1200CE for ; Sun, 25 Aug 2019 20:40:59 -0700 (PDT) Received: from [192.168.1.2] (ppp-94-69-228-39.home.otenet.gr [94.69.228.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 796EA863FA; Mon, 26 Aug 2019 05:40:53 +0200 (CEST) To: Christian Huitema Cc: architecture-discuss@iab.org References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> <19058eaf-47e9-7cac-bf34-cfef646a9bd6@huitema.net> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <01b1dcd9-1acf-784e-1b71-f6e497a2f472@si6networks.com> Date: Mon, 26 Aug 2019 04:47:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <19058eaf-47e9-7cac-bf34-cfef646a9bd6@huitema.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 03:41:02 -0000 On 25/8/19 21:07, Christian Huitema wrote: > On 8/25/2019 6:59 AM, Fernando Gont wrote: > >> I agree with the above, still, the reason for which QUIC employs UDP >> (rather than doing mux/demux by itself) is because you can't deploy new >> transport protocols on the Internet. > > > I think we are getting caught in disputes over vocabulary. Two things > are true at the same time: > > 1) We cannot send packets in which the IP protocol or IPv6 payload type > is set to a different value than TCP or UDP and expect them to reach > destinations across the Internet. Agreed. But doesn't that mean that you cannot deploy new transport protocols natively? Architecturally-wise, in a non-recursive architecture transport runs over Internet, right? If IP is Internet, and QUIC is transport, what do you call the UDP that stis in between? > 2) QUIC, BitTorrent and SCTP demonstrate that you can run a protocol on > top of UDP that has all the characteristics of a classic transport > protocol, including error recovery and congestion control. ( QUIC can > perform mux/demux by itself, using the "connection ID" field, but most > deployments refrain from using multiple layers of multiplexing.) As long as UDP is not filtered, you can run anything you want on top of UDP. You can run IP or IPv6, too (I regularly do, indeed). (sixxs has done that for ages, openvpn and IPsec over UDP, too, and I seem to recall that sctp too) > Using UDP causes 8 bytes of overhead per packet, which is unfortunate. > You may call that a middle-box tax if you want. But as long as you are > willing to pay that tax, you can of course deploy new transmission > control protocols over the Internet. Most people will call them > transport protocols. The point of my original comment was this: 1) You cannot deploy new transport protocols natively. You need to encapsulate/tunnel, because otherwise the big-i internet will likely drop your packets. This is kind of well understood. 2) Of course you can always find some protocol that will work, to tunnel something you want to deploy (go up one layer if the current layer doesn't work). So I'm not sure there's any news here. -- that doesn't mean less credit for QUIC at all. I'm wondering if the fact of being able to find *something* over which a protocol (transport or otherwise) can work has been a new key finding. -- e.g. any of us have been doing OpenVPN over UDP and others for quite a while. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Aug 25 21:27:25 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 641561200A4 for ; Sun, 25 Aug 2019 21:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 EWDrqd3ZE4aP for ; Sun, 25 Aug 2019 21:27:21 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F4D6120822 for ; Sun, 25 Aug 2019 21:27:21 -0700 (PDT) Received: from [192.168.1.2] (ppp-94-69-228-39.home.otenet.gr [94.69.228.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id CA96D853F4; Mon, 26 Aug 2019 06:27:16 +0200 (CEST) To: John Leslie , Christian Huitema Cc: architecture-discuss@iab.org References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> <19058eaf-47e9-7cac-bf34-cfef646a9bd6@huitema.net> <20190825194135.GB78819@verdi> From: Fernando Gont Openpgp: preference=signencrypt Message-ID: <79a1a69e-5ffb-8022-e841-b0b447cd534d@gont.com.ar> Date: Mon, 26 Aug 2019 07:25:32 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190825194135.GB78819@verdi> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 04:27:23 -0000 On 25/8/19 22:41, John Leslie wrote: [,,,] > >> You may call that a middle-box tax if you want. But as long as you are >> willing to pay that tax, you can of course deploy new transmission >> control protocols over the Internet. Most people will call them >> transport protocols. > > Actually, what we call them _does_ make a real difference. I'd be happy > to call them "transport protocols"... If anything, QUIC without UDP encapsulation is as much of a transport protocol as IPv6 is as network layer protocol. If you tried to use IPv6 natively (i.e., a single network layer in the resulting stack) on the same network on which we employ IPv4, you just can't: there's only partial support for IPv6, and you need to tunnel it over something that works (IPv4) to overcome that. Yes, IPv6 is a network-layer protocol, but if folks assumed that it can be readily employed on the whole big-I Internet, that would be, of course, a false expectation: there's lots of parts of the network that simply lack support for it. The same analogy applies to transport protocols: lots of portions of the network just don't support anything else other than, say, TCP and UDP. In some cases, because of NATs, in others because of firewalls, or boxes that will drop packets if they cannot tell whether something is a transport protocol or unknown EH, etc. That's when you end up stacking one transport over another. I don't think this is a matter of vocabulary, but one of architecture: In away, protocols don't work because, for one reason or another, the layer you had has become broken (into islands, if you want), and you need to pile protocols of the same rank on top of each other for the system to work. In the case of transport, UDP is of course convenient, because it allows your packets to "get through" while doing as little as possible. But is a protocol, not a "tax". If you want to call UDP "middle-box tax", I guess we should also call IPv4 a "middle-box tax" (or similar name) when tunneling IPv6 over IPv4. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Sun Aug 25 21:45:13 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89B4120824 for ; Sun, 25 Aug 2019 21:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 5qxGyLpJE6ab for ; Sun, 25 Aug 2019 21:45:08 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AAC31200A4 for ; Sun, 25 Aug 2019 21:45:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=GcvAO7PXnPVLVtiFhI31gKGBw4NzNDkThjUY87JGYxw=; b=QU6iwjJfjN9ntc4iAvkOfU5xQ x72RLSn6xk/pit3MNaYUT54f3kNCT3Km5KMoLenzzMbsekkBSX8Jy8lbH8EwofDtKOKJOaasjL6tr j04qPYyMdmAHZ+JaXo/dsfGOFBtzBOGtZ3EipGW6CeC5HDU9blS0X0sLTXmgtWmaIAzVAc/zEVBNQ FZ9aTCqCU2sWhdpkzMPbv0pJYkIW2wZZBd4Gfiv9uKVPa4M97vRAuUssf0OXjCzOFjf1S/bAOo0Pa gmYzt4eldgEQNkH8zdgpOBoCL9Py0/O7oQ/NC6TvstToj/Y9m6BY76oun9QqenmAyF1Fqj/T1NVUV /GNJm/YMg==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:59530 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1i26sJ-000M1v-2k; Mon, 26 Aug 2019 00:45:07 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_9F707663-0E0F-4B35-A7D2-B046631385C4" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: <01b1dcd9-1acf-784e-1b71-f6e497a2f472@si6networks.com> Date: Sun, 25 Aug 2019 21:45:02 -0700 Cc: Christian Huitema , architecture-discuss@iab.org Message-Id: References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> <19058eaf-47e9-7cac-bf34-cfef646a9bd6@huitema.net> <01b1dcd9-1acf-784e-1b71-f6e497a2f472@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 04:45:10 -0000 --Apple-Mail=_9F707663-0E0F-4B35-A7D2-B046631385C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > If IP is Internet, and QUIC is transport, what do you call the UDP = that > stis in between? Therein lies the error. QUIC alone is not a transport. It=E2=80=99s not complete enough to be transport by itself. It doesn=E2=80= =99t provide the socket (as in RFC793=E2=80=99s idea of a socket) = demuxing. IMO, QUIC + UDP is a transport layer. A layer that provides a more = complex service than UDP alone. So yes, UDP is a transport layer - when operating by itself. But when = paired with QUIC, it is the pair that are the transport. UDP affords the ability to design new transports on top of a basic = muxing service. Those new transports CAN be inside user space, but = that=E2=80=99s not the point necessarily - they can easily also be = implemented inside an OS. (and IMO, UDP options help extend that muxing service without = necessarily completing all the features we call a transport, so that=E2=80= =99s consistent here too). Joe --Apple-Mail=_9F707663-0E0F-4B35-A7D2-B046631385C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

If IP is Internet, and QUIC is transport, what do you call = the UDP that
stis in between?

Therein lies the = error.

QUIC = alone is not a transport.

It=E2=80=99s not complete enough to be transport by itself. = It doesn=E2=80=99t provide the socket (as in RFC793=E2=80=99s idea of a = socket) demuxing.

IMO, QUIC + UDP is a transport layer. A layer that provides a = more complex service than UDP alone.

So yes, UDP is a transport layer - when = operating by itself. But when paired with QUIC, it is the pair that are = the transport.

UDP affords the ability to design new transports on top of a = basic muxing service. Those new transports CAN be inside user space, but = that=E2=80=99s not the point necessarily - they can easily also be = implemented inside an OS.

(and IMO, UDP options help extend that muxing service without = necessarily completing all the features we call a transport, so that=E2=80= =99s consistent here too).

Joe





= --Apple-Mail=_9F707663-0E0F-4B35-A7D2-B046631385C4-- From nobody Sun Aug 25 21:50:21 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDEB120822 for ; Sun, 25 Aug 2019 21:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 LBHZvpawjIWN for ; Sun, 25 Aug 2019 21:50:19 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69D851200A4 for ; Sun, 25 Aug 2019 21:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=I+0eLEUTi+got4VaXJIoS3vCaXVYyh/5PMcVKSl7ceI=; b=6SiHL6bjSlx60/ZIMlCnT7t+T k4arv1u53rBsmBNJNVG+HoTUmP89CEgZv9NubJGPOO7uxH1IPlg5jOiHj6x/J1YNkSy4qS1ySMkHu PADCGI4PUAqv04xKXatpAWsj7FldEEEU+VOICtZOQT8s+2y2IcYhQq0JCssLWxYcAjRidK3MnZWjk FPc87ysNZL8Dj/pKbRzHqb1QlnXQmxuXQ58X14xs6xm3ELg0SzBpvtCwWIa+89U6Lcs0JEmCLZw9/ f7aZBRJZ4rNL07sigj4686msQVJK0x7Kw6z+tf25mRHERJXfF0NkOp2otvvvIRe/+mC6IZPCn1fI8 Up/QOU3pg==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:59774 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1i26xI-000PTf-7J; Mon, 26 Aug 2019 00:50:16 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_C53EC71F-DE26-453D-BE9A-D4900BB30A3C" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: Date: Sun, 25 Aug 2019 21:50:11 -0700 Cc: John Leslie , architecture-discuss@iab.org Message-Id: References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> <20190825164839.GA77144@verdi> <715FF08E-9DD1-4052-BE1D-3C3AA614B560@strayalpha.com> To: Henning Schulzrinne X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 04:50:20 -0000 --Apple-Mail=_C53EC71F-DE26-453D-BE9A-D4900BB30A3C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 25, 2019, at 12:16 PM, Henning Schulzrinne = wrote: >=20 > Some of us who worked on the Open Internet (aka network neutrality) = saw "protocol neutrality" as very much part of the same spirit and = possibly a legal entitlement of customers. And the issue of naming = "Internet access" implying some obligations was also part of the = discussion. Experience seems to indicate that only legal or regulatory = requirements are likely to lead there, That hasn=E2=80=99t been the case for SONET, ATM, or Ethernet services. If we had a clear definition of =E2=80=9CISOC-certified Internet = service=E2=80=9D, then: a) customers might be willing to seek that b) customers who pay for that have a clear legal path if = that=E2=80=99s what was offered and it isn=E2=80=99t true People pay more for UL-listed equipment, for Good Housekeeping seals of = approval, etc. This isn=E2=80=99t any different, except the we have no = =E2=80=9Cseal=E2=80=9D authority - yet. > given that many carriers have no economic interest to do this - and = carrier-grade NATs make it painful or impossible to move beyond TCP and = UDP. >=20 > Henning We could have two versions of service - ISOC-certified true Internet and = ISOC-certified translated Internet (the latter so we don=E2=80=99t = freeze out carriers to start). People might pay more for the former. =E2=80=94=E2=80=94 The trouble with ignoring the need for this sort of certification at the = ISOC level is that we=E2=80=99ve basically dumped that work onto the = user at run-time - to confirm every feature before using it - and at the = protocol level (by adding complex =E2=80=9Care you sure=E2=80=9D = mechanisms). Joe --Apple-Mail=_C53EC71F-DE26-453D-BE9A-D4900BB30A3C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 25, 2019, at 12:16 PM, Henning Schulzrinne <hgs@cs.columbia.edu>= wrote:

Some of us who worked on the = Open Internet (aka network neutrality) saw "protocol neutrality" as very = much part of the same spirit and possibly a legal entitlement of = customers. And the issue of naming "Internet access" implying some = obligations was also part of the discussion. Experience seems to = indicate that only legal or regulatory requirements are likely to lead = there,

That = hasn=E2=80=99t been the case for SONET, ATM, or Ethernet = services.

If we had a clear = definition of =E2=80=9CISOC-certified Internet service=E2=80=9D, = then:
= a) customers might be willing to seek that
b) = customers who pay for that have a clear legal path if that=E2=80=99s = what was offered and it isn=E2=80=99t true

People pay more for UL-listed equipment, for Good = Housekeeping seals of approval, etc. This isn=E2=80=99t any different, = except the we have no =E2=80=9Cseal=E2=80=9D authority - yet.

given that many carriers have = no economic interest to do this - and carrier-grade NATs make it painful = or impossible to move beyond TCP and UDP.

Henning

We = could have two versions of service - ISOC-certified true Internet and = ISOC-certified translated Internet (the latter so we don=E2=80=99t = freeze out carriers to start). People might pay more for the = former.

=E2=80=94=E2=80=94
<= br class=3D"">
The trouble with ignoring the need for this = sort of certification at the ISOC level is that we=E2=80=99ve basically = dumped that work onto the user at run-time - to confirm every feature = before using it - and at the protocol level (by adding complex =E2=80=9Car= e you sure=E2=80=9D mechanisms).

Joe

= --Apple-Mail=_C53EC71F-DE26-453D-BE9A-D4900BB30A3C-- From nobody Sun Aug 25 22:20:13 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BCE120116 for ; Sun, 25 Aug 2019 22:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 4q5QZwj0orZ1 for ; Sun, 25 Aug 2019 22:20:09 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611E31200A4 for ; Sun, 25 Aug 2019 22:20:09 -0700 (PDT) Received: from [192.168.1.2] (ppp-94-69-228-39.home.otenet.gr [94.69.228.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 7CE2C8641F; Mon, 26 Aug 2019 07:20:04 +0200 (CEST) To: Joe Touch Cc: Christian Huitema , architecture-discuss@iab.org References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> <19058eaf-47e9-7cac-bf34-cfef646a9bd6@huitema.net> <01b1dcd9-1acf-784e-1b71-f6e497a2f472@si6networks.com> From: Fernando Gont Openpgp: preference=signencrypt Message-ID: <37056715-b52e-8fbe-ac0c-a2caefdb94bf@si6networks.com> Date: Mon, 26 Aug 2019 08:19:43 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 05:20:12 -0000 On 26/8/19 07:45, Joe Touch wrote: > > >> If IP is Internet, and QUIC is transport, what do you call the UDP that >> stis in between? > > Therein lies the error. > > QUIC alone is not a transport. > > It’s not complete enough to be transport by itself. It doesn’t provide > the socket (as in RFC793’s idea of a socket) demuxing. > > IMO, QUIC + UDP is a transport layer. A layer that provides a more > complex service than UDP alone.> > So yes, UDP is a transport layer - when operating by itself. But when > paired with QUIC, it is the pair that are the transport. Maybe one of the underlying issues here is that one would normally expect one transport service as a single layer (i.e. protocol layer). But since this is not feasible in the current Internet, you get two protocol layers to offer a transport service you'd normally implement in a single one. i.e., for QUIC you need two protocols to implement a specific transport service. You use one transport protocol (UDP) that doesn't provide the service you want (but get the packets through), and then stack abother protocol on top of it, that does all that is missing. So I'd argue that it is correct that you can implement new transport *services*. However, the statement that you can deploy new transport *protocols* seems to be misleading (you're actually relying on a very simple transport protocol, and use its services as a building block for implementing a different transport service). This is what my original message tried to point out. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Aug 25 22:24:24 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F427120827 for ; Sun, 25 Aug 2019 22:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 cobSNSVAZ4Dq for ; Sun, 25 Aug 2019 22:24:21 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 931D1120826 for ; Sun, 25 Aug 2019 22:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=grhHQvmCqt6fbWK8Qej2IcGum5bDZrUarLtxWVbWryg=; b=trkliqQYGo42ruDuFpUH/KdHn wA4GUjuPqF8qHbHi/mzH+p5F63MU2i1s0cAbiQBxOfGnKCJT+dXsEHmC1a7iqgiBvvf9Hvcj0FhbM 2dRJgwQwH1NeqZHo0prlf8RDcr/p2/vSKEsZyZWSyKoYG05Vs1OjXTZ35+yFZjSHaf0WGCjUjL/6H rw1RLcTp3kKdhitAbSonEZuWArKjP3ID8r2/Cv8Zqad9p4SuR5bKAKi8uJPSDyCez3NNWY68nkpEL eJrlZgrc5o1uCJaQCHQ62jgG638c6Bn5e+y19jjpiIdP0Pgngj5+FCHiy/3wXYrdFgzzYuQOeSCkD kpG0Byx4w==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:61208 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1i27UH-000qIN-3d; Mon, 26 Aug 2019 01:24:21 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_E0465512-2EBA-42E8-9C8A-25BD5C3E41A6" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: <37056715-b52e-8fbe-ac0c-a2caefdb94bf@si6networks.com> Date: Sun, 25 Aug 2019 22:24:15 -0700 Cc: Christian Huitema , architecture-discuss@iab.org Message-Id: <19B905FF-B09D-4D60-AB93-3D8ACCD7BB04@strayalpha.com> References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> <19058eaf-47e9-7cac-bf34-cfef646a9bd6@huitema.net> <01b1dcd9-1acf-784e-1b71-f6e497a2f472@si6networks.com> <37056715-b52e-8fbe-ac0c-a2caefdb94bf@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 05:24:23 -0000 --Apple-Mail=_E0465512-2EBA-42E8-9C8A-25BD5C3E41A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The only thing QUIC doesn=E2=80=99t do is demux via a single field of = the IP header called =E2=80=9Cprotocol=E2=80=9D. So? Maybe this is a good thing - maybe it just goes to show middleboxes how = incapable they are at actually knowing what=E2=80=99s going on. Joe > On Aug 25, 2019, at 10:19 PM, Fernando Gont = wrote: >=20 > On 26/8/19 07:45, Joe Touch wrote: >>=20 >>=20 >>> If IP is Internet, and QUIC is transport, what do you call the UDP = that >>> stis in between? >>=20 >> Therein lies the error. >>=20 >> QUIC alone is not a transport. >>=20 >> It=E2=80=99s not complete enough to be transport by itself. It = doesn=E2=80=99t provide >> the socket (as in RFC793=E2=80=99s idea of a socket) demuxing. >>=20 >> IMO, QUIC + UDP is a transport layer. A layer that provides a more >> complex service than UDP alone.> >> So yes, UDP is a transport layer - when operating by itself. But when >> paired with QUIC, it is the pair that are the transport. >=20 > Maybe one of the underlying issues here is that one would normally > expect one transport service as a single layer (i.e. protocol layer). > But since this is not feasible in the current Internet, you get two > protocol layers to offer a transport service you'd normally implement = in > a single one. >=20 > i.e., for QUIC you need two protocols to implement a specific = transport > service. You use one transport protocol (UDP) that doesn't provide the > service you want (but get the packets through), and then stack abother > protocol on top of it, that does all that is missing. >=20 > So I'd argue that it is correct that you can implement new transport > *services*. However, the statement that you can deploy new transport > *protocols* seems to be misleading (you're actually relying on a very > simple transport protocol, and use its services as a building block = for > implementing a different transport service). This is what my original > message tried to point out. >=20 > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 --Apple-Mail=_E0465512-2EBA-42E8-9C8A-25BD5C3E41A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = only thing QUIC doesn=E2=80=99t do is demux via a single field of the IP = header called =E2=80=9Cprotocol=E2=80=9D.

So?

Maybe this is a good thing - maybe it = just goes to show middleboxes how incapable they are at actually knowing = what=E2=80=99s going on.

Joe

On Aug 25, 2019, at 10:19 PM, Fernando Gont = <fgont@si6networks.com> wrote:

On 26/8/19 07:45, Joe Touch = wrote:


If IP is = Internet, and QUIC is transport, what do you call the UDP that
stis in between?

Therein lies the error.

QUIC = alone is not a transport.

It=E2=80=99s not = complete enough to be transport by itself. It doesn=E2=80=99t provide
the socket (as in RFC793=E2=80=99s idea of a socket) = demuxing.

IMO, QUIC + UDP is a transport = layer. A layer that provides a more
complex service than = UDP alone.>
So yes, UDP is a transport layer - when = operating by itself. But when
paired with QUIC, it is the = pair that are the transport.

Maybe one of the underlying = issues here is that one would normally
expect one transport service as a single layer (i.e. protocol = layer).
But since = this is not feasible in the current Internet, you get two
protocol layers to offer a = transport service you'd normally implement in
a single one.

i.e., for QUIC you need two = protocols to implement a specific transport
service. You use one transport = protocol (UDP) that doesn't provide the
service you want (but get the packets through), and then = stack abother
protocol on = top of it, that does all that is missing.

So I'd argue that it is correct that you can implement new = transport
*services*. = However, the statement that you can deploy new transport
*protocols* seems to be = misleading (you're actually relying on a very
simple transport protocol, and = use its services as a building block for
implementing a different transport service). This is what my = original
message tried = to point out.

-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 = 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

= --Apple-Mail=_E0465512-2EBA-42E8-9C8A-25BD5C3E41A6-- From nobody Sun Aug 25 22:30:52 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D874D120826 for ; Sun, 25 Aug 2019 22:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 9bH4q37zbczi for ; Sun, 25 Aug 2019 22:30:49 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4337A1200A4 for ; Sun, 25 Aug 2019 22:30:49 -0700 (PDT) Received: from [192.168.1.2] (ppp-94-69-228-39.home.otenet.gr [94.69.228.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 76B4286418; Mon, 26 Aug 2019 07:30:47 +0200 (CEST) To: Joe Touch , Henning Schulzrinne Cc: architecture-discuss@iab.org References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> <20190825164839.GA77144@verdi> <715FF08E-9DD1-4052-BE1D-3C3AA614B560@strayalpha.com> From: Fernando Gont Openpgp: preference=signencrypt Message-ID: <22eceb42-70a0-04ad-dc2c-4550f0cf87a5@si6networks.com> Date: Mon, 26 Aug 2019 08:30:41 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 05:30:51 -0000 On 26/8/19 07:50, Joe Touch wrote: > > >> On Aug 25, 2019, at 12:16 PM, Henning Schulzrinne > > wrote: >> >> Some of us who worked on the Open Internet (aka network neutrality) >> saw "protocol neutrality" as very much part of the same spirit and >> possibly a legal entitlement of customers. And the issue of naming >> "Internet access" implying some obligations was also part of the >> discussion. Experience seems to indicate that only legal or regulatory >> requirements are likely to lead there, > > That hasn’t been the case for SONET, ATM, or Ethernet services. > > If we had a clear definition of “ISOC-certified Internet service”, then: > a) customers might be willing to seek that > b) customers who pay for that have a clear legal path if that’s what was > offered and it isn’t true If one means to get on that path, I'd start with certified implementations -- at times, the service is a consequence of this. One of the most obvious cases is e.g. IPv6 implementations that are "IPv6 Ready", but then do an extremely lousy job (see "IPv6 Security Assessment and Benchmarking" at http://www.ipv6hackers.org/meetings/ipv6-hackers-1). >> given that many carriers have no economic interest to do this - and >> carrier-grade NATs make it painful or impossible to move beyond TCP >> and UDP. >> >> Henning > > We could have two versions of service - ISOC-certified true Internet and > ISOC-certified translated Internet (the latter so we don’t freeze out > carriers to start). People might pay more for the former. Without giving this a lot of thought, the problem with "certified Internet" is that one would expect that to apply to all destinations and paths. When should my ISP start billing me for the "true Internet" service? When it works with Google, or with everyone? If the former: Does it matter? If the latter: would it ever happen? (I bet many of us, nevertheless, when prompted with the question of which one we want to buy, would ask the question: what can I do with the expensive one that I can't with the other? (as opposed to "what one could *potentially* do). -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Aug 25 22:41:06 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9255F1200A1 for ; Sun, 25 Aug 2019 22:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 i_GjEKRJHkNh for ; Sun, 25 Aug 2019 22:41:03 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19C95120025 for ; Sun, 25 Aug 2019 22:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CaetCTWAX5CYeElUgId2yl83fbVEJLJogGjKeVoBHXM=; b=Gix7EGYFmVMqXYRKjOR04Zo/2 yVt70yo1KoGqPg4ft4ugBOOJ6+2VFeqZAKi4ziOZK9U+1wrch+gZD5nrbb4njJV738tqGj6YlymOh 4wiOr2ZETkq1UC3y3mEaFvThSXzLPA7YybjJOQZ5Zk0BrHh090ciYp0W9e72UYzoSCSZR/e6VQ91s /1HpLg4PrkwH7xpa32czElgfQ71wxyWNPebO97nLlC2TvMvFyCj2VCuOhD36T7wJk+AFfvLKO/gJ6 kvdKW4U+AgcZGULE3ExDf8p4vq9gVPmbBB94atP5GRs5cnnBpBuhJ30WbcsXW9O3jzaqks94T1ust WskptzTRA==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:62333 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1i27kQ-0010p4-85; Mon, 26 Aug 2019 01:41:02 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_D2C8A540-9B28-46E1-9EDD-3BE732AF5634" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: <22eceb42-70a0-04ad-dc2c-4550f0cf87a5@si6networks.com> Date: Sun, 25 Aug 2019 22:40:57 -0700 Cc: Henning Schulzrinne , architecture-discuss@iab.org Message-Id: <276F8587-603C-499A-A89F-3387589D6E6B@strayalpha.com> References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> <20190825164839.GA77144@verdi> <715FF08E-9DD1-4052-BE1D-3C3AA614B560@strayalpha.com> <22eceb42-70a0-04ad-dc2c-4550f0cf87a5@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 05:41:05 -0000 --Apple-Mail=_D2C8A540-9B28-46E1-9EDD-3BE732AF5634 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 25, 2019, at 10:30 PM, Fernando Gont = wrote: >=20 > When should my ISP start billing me for the "true Internet" service? > When it works with Google, or with everyone? If the former: Does it > matter? If the latter: would it ever happen? 1. provide endpoint services that use certified implementations 2. give me real Internet service, per below No, this won=E2=80=99t fix everything. But it=E2=80=99s the set of steps = we need to take first. The next step is to highlight where these rules don=E2=80=99t work as = not working. Not endorse them as =E2=80=9Cde facto changes to the = baseline=E2=80=9D. Joe Bill of Internet Access Rights Joe Touch USC/ISI June 21, 2006=20 (this is an update of a set of rules originally presented at "Preventing = the Internet Meltdown", Los Angeles CA 2004; the original is also = presented below)=20 Internet is an association of communicating parties. This necessarily = results in a number of rights which are required for consenting parties = to communicate. Consenting parties should be able to communicate in an = unrestricted fashion, insofar as they do not impinge on the = corresponding rights of other parties. The following is a list of = specific rights to that end: 1. REAL IP: Users have the right to obtain a real IP address, routable = from anywhere on the Internet. 2. REAL DNS (& REVERSE-DNS): Users have the right to obtain a valid = reverse DNS name for that IP address, and the forward lookup of that = name should match the same address. 3. RECEIVE ANY: Users have the right to receive any valid IP packet, = using any valid transport protocol on any valid port (if applicable), up = to the limits of your local resources and network connection. 4. SEND ANY: Users have the right to send any valid IP packet to any = valid real IP address, using any transport protocol, on any valid port = (if applicable), provided it uses an inconsequential amount of resources = of the network and potential receiver until mutual consent is = established. 5. ENFORCEMENT: Users have the right to know the ISP responsible for = traffic from any valid IP address, sufficient to register a complaint = regarding violations of any of these rules.= --Apple-Mail=_D2C8A540-9B28-46E1-9EDD-3BE732AF5634 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 25, 2019, at 10:30 PM, Fernando Gont <fgont@si6networks.com> wrote:

When should my ISP start billing = me for the "true Internet" service?
When it works with Google, or with everyone? If the former: = Does it
matter? If = the latter: would it ever happen?

1. provide endpoint services that use = certified implementations
2. give me real Internet = service, per below

No, this won=E2=80=99t fix everything. But it=E2=80=99s the = set of steps we need to take first.

The next step is to highlight where = these rules don=E2=80=99t work as not working. Not endorse them as =E2=80=9C= de facto changes to the baseline=E2=80=9D.

Joe

Bill of Internet Access = Rights

Joe Touch
USC/ISI
June 21, = 2006 
(this is an update of a set of rules originally = presented at "Preventing the Internet Meltdown", Los Angeles CA 2004; = the original is also presented below) 

Internet is an = association of communicating parties. This necessarily results in a = number of rights which are required for consenting parties to = communicate. Consenting parties should be able to communicate in an = unrestricted fashion, insofar as they do not impinge on the = corresponding rights of other parties. The following is a list of = specific rights to that end:

1. REAL IP: Users have the = right to obtain a real IP address, routable from anywhere on the = Internet.

2. REAL DNS (& REVERSE-DNS): Users have = the right to obtain a valid reverse DNS name for that IP address, and = the forward lookup of that name should match the same address.

3. RECEIVE ANY: Users have the right to receive any valid IP = packet, using any valid transport protocol on any valid port (if = applicable), up to the limits of your local resources and network = connection.

4. SEND ANY: Users have the right to send = any valid IP packet to any valid real IP address, using any transport = protocol, on any valid port (if applicable), provided it uses an = inconsequential amount of resources of the network and potential = receiver until mutual consent is established.

5. = ENFORCEMENT: Users have the right to know the ISP responsible for = traffic from any valid IP address, sufficient to register a complaint = regarding violations of any of these = rules.

= --Apple-Mail=_D2C8A540-9B28-46E1-9EDD-3BE732AF5634-- From nobody Sun Aug 25 22:48:40 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF8D1200FB for ; Sun, 25 Aug 2019 22:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 xsoXu_BsTQCW for ; Sun, 25 Aug 2019 22:48:37 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4E26120025 for ; Sun, 25 Aug 2019 22:48:37 -0700 (PDT) Received: from [192.168.1.2] (ppp-94-69-228-39.home.otenet.gr [94.69.228.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 8988B8624E; Mon, 26 Aug 2019 07:48:32 +0200 (CEST) To: Joe Touch Cc: Christian Huitema , architecture-discuss@iab.org References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> <19058eaf-47e9-7cac-bf34-cfef646a9bd6@huitema.net> <01b1dcd9-1acf-784e-1b71-f6e497a2f472@si6networks.com> <37056715-b52e-8fbe-ac0c-a2caefdb94bf@si6networks.com> <19B905FF-B09D-4D60-AB93-3D8ACCD7BB04@strayalpha.com> From: Fernando Gont Openpgp: preference=signencrypt Message-ID: <4fbd7366-6dfa-503d-50e0-0a860afa423d@si6networks.com> Date: Mon, 26 Aug 2019 08:48:26 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <19B905FF-B09D-4D60-AB93-3D8ACCD7BB04@strayalpha.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 05:48:39 -0000 On 26/8/19 08:24, Joe Touch wrote: > The only thing QUIC doesn’t do is demux via a single field of the IP > header called “protocol”. I go back to my original comment: that you can't deploy new transport protocols. Yes, you can stack as many layers as you want, but you can't deploy new transport protocols. You can deploy new transport protocols as much as you can deploy new internet protocols (you can do overlays as much as you want). To put it bluntly: you have UDP sitting below QUIC because you can't deploy new transport protocols on the Internet. (No need to mention that none of my previous comments was in detriment of QUIC -- they were very pragmatic, indeed). > Maybe this is a good thing - maybe it just goes to show middleboxes how > incapable they are at actually knowing what’s going on. I'd bet much of the brokenness has nothing to do with middle-boxes that want to know what's going on (e.g., firewalls enforcing security policies). A lot has to do with NATs (which need to be aware about the transport protocol to do the translation), and other boxes that at times need to drop packets as a side effect of doing something else (https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops). Let's also not just blame NATs: we were extremely close to ship what became RFC8200 with no comments about middle-box insertion of EHs, we also had SRv6 with in-the-network EH-insertion, and Linux currently ships with in-the-network SRv6 insertion (see man 8 ip-route). At times we don't seem to be consistent regarding wether we want middleboxes to fiddle with packets or not.... -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Aug 25 22:53:18 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AA2120103 for ; Sun, 25 Aug 2019 22:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 0gX4OZbwEutq for ; Sun, 25 Aug 2019 22:53:14 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 500121200FB for ; Sun, 25 Aug 2019 22:53:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=C/2Qo7Y1HyUMC8JlfakaZ+2AvY/ztdHeVS9tIaA/7OM=; b=uj0M36x3gllkj6pxTp3TPWrkd KQGOOufV53CGYQMzKzziwPY+RqSPZ/HMLUtRE+SZmqPbWO5VTDoj18XAc8XauzRJ+sGbJiO0w8tLT Ynn7oRw5Z7H1fXg+9EsvaQQREOkPLwZ8MyieYtRQrqRzZNWIFr5Xsp/VECGxvbr3ltqEMJK6QiR9e cIkx6O77dRL4nBspHGs63bEwSm3L97bQhqG6CjG2VzYpsSazbUjpdFR7b00ZUsTsSbL5Ty1gWYOVv 4EvsswZTOxfWS7Z7aN9xpZc5z/YNAzMX3MsfW97ds8AA6VzSZmRhel6X2cFRGzrdeoTPtQZereADg ermDLaeog==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:63231 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1i27wB-0018ZQ-8l; Mon, 26 Aug 2019 01:53:11 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_0871FFFC-2056-438E-8DC5-DCAD5D34EFAF" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: <4fbd7366-6dfa-503d-50e0-0a860afa423d@si6networks.com> Date: Sun, 25 Aug 2019 22:53:06 -0700 Cc: Christian Huitema , architecture-discuss@iab.org Message-Id: <90DA4646-C87B-460D-B11F-29CEF51B5100@strayalpha.com> References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> <19058eaf-47e9-7cac-bf34-cfef646a9bd6@huitema.net> <01b1dcd9-1acf-784e-1b71-f6e497a2f472@si6networks.com> <37056715-b52e-8fbe-ac0c-a2caefdb94bf@si6networks.com> <19B905FF-B09D-4D60-AB93-3D8ACCD7BB04@strayalpha.com> <4fbd7366-6dfa-503d-50e0-0a860afa423d@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 05:53:16 -0000 --Apple-Mail=_0871FFFC-2056-438E-8DC5-DCAD5D34EFAF Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On Aug 25, 2019, at 10:48 PM, Fernando Gont wrote: > > At times > we don't seem to be consistent regarding wether we want middleboxes to > fiddle with packets or not.... Fixing bad ideas in the IETF is a full time job that none of us want or have. Joe --Apple-Mail=_0871FFFC-2056-438E-8DC5-DCAD5D34EFAF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Aug 25, 2019, at 10:48 PM, Fernando Gont <fgont@si6networks.com> wrote:

At times
we don't seem to be consistent = regarding wether we want middleboxes to
fiddle with packets or = not....

Fixing bad ideas in the IETF is a full time job that none of = us want or have.

Joe
= --Apple-Mail=_0871FFFC-2056-438E-8DC5-DCAD5D34EFAF-- From nobody Sun Aug 25 23:01:16 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D68A12083F for ; Sun, 25 Aug 2019 23:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 njTadVxLSVbK for ; Sun, 25 Aug 2019 23:01:09 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A2A3120105 for ; Sun, 25 Aug 2019 23:01:09 -0700 (PDT) Received: from [192.168.1.2] (ppp-94-69-228-39.home.otenet.gr [94.69.228.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id E735C85F50; Mon, 26 Aug 2019 08:01:06 +0200 (CEST) To: Joe Touch Cc: Henning Schulzrinne , architecture-discuss@iab.org References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> <20190825164839.GA77144@verdi> <715FF08E-9DD1-4052-BE1D-3C3AA614B560@strayalpha.com> <22eceb42-70a0-04ad-dc2c-4550f0cf87a5@si6networks.com> <276F8587-603C-499A-A89F-3387589D6E6B@strayalpha.com> From: Fernando Gont Openpgp: preference=signencrypt Message-ID: <97146658-53b2-7317-879e-479fd70ca4c5@si6networks.com> Date: Mon, 26 Aug 2019 09:00:35 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <276F8587-603C-499A-A89F-3387589D6E6B@strayalpha.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 06:01:15 -0000 On 26/8/19 08:40, Joe Touch wrote: > > >> On Aug 25, 2019, at 10:30 PM, Fernando Gont > > wrote: >> >> When should my ISP start billing me for the "true Internet" service? >> When it works with Google, or with everyone? If the former: Does it >> matter? If the latter: would it ever happen? > > 1. provide endpoint services that use certified implementations > 2. give me real Internet service, per below > > No, this won’t fix everything. But it’s the set of steps we need to take > first. > > The next step is to highlight where these rules don’t work as not > working. Not endorse them as “de facto changes to the baseline”. Some comments: 1) With many current implementations, some of the packets you expect to pass-through will simply consume lots of resources. SO the will end up being dropped. 2) "real ip address" is, in many cases, just not feasible -- particularly for folks joining the business late -- unless you're assuming IPv6. 3) Some of the things you mention below go against current operational practices -- e.g. packet filtering by operators. -- even the lack of a dns reverse mapping may make mail-relaying fail (not taht it has proven to be affective to stop spam ;-), but..) 4) Regarding "SEND ANY", I assume you really mean "SEND". Now, where do you draw the line as whether filtering does not allow sending, or simply is a receive policy at some point? Note: I'm note necessarily arguing against the text you quoted, but rather arguing about its feasibility. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Aug 26 07:13:30 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB861200A3 for ; Mon, 26 Aug 2019 07:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 lvH6GyYK5F0a for ; Mon, 26 Aug 2019 07:13:25 -0700 (PDT) Received: from outprodmail02.cc.columbia.edu (outprodmail02.cc.columbia.edu [128.59.72.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46D9712012C for ; Mon, 26 Aug 2019 07:13:25 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by outprodmail02.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id x7QECv8Q010336 for ; Mon, 26 Aug 2019 10:13:23 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 2E91187 for ; Mon, 26 Aug 2019 10:13:23 -0400 (EDT) Received: from sendprodmail04.cc.columbia.edu (sendprodmail04.cc.columbia.edu [128.59.72.16]) by hazelnut (Postfix) with ESMTP id 00F6080 for ; Mon, 26 Aug 2019 10:13:17 -0400 (EDT) Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by sendprodmail04.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id x7QEDHVH064381 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 26 Aug 2019 10:13:17 -0400 Received: by mail-qt1-f197.google.com with SMTP id f28so17683944qtg.2 for ; Mon, 26 Aug 2019 07:13:17 -0700 (PDT) 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:from:date :message-id:subject:to:cc; bh=C6B6lYb1PXKRbdk6qfq04CpUvgB/7jM17D2hUBvtCj0=; b=gT9S/kIrqQpa1zEVd4RDrVz6ofKsQsdy1djp9F0mEZ9IUVEaITgxcIZgn87Bl032lI wIMSSg64CHqaYjeYGZZuhgALJ96wolalyr7hdNT7BT7yPVVyadtlppOdYPkWyryyWkIp K3u+2975XBW2Z0e7Zy9HzIRsU5E3lTgDMIQLhjNCL8kEY+szlkHJyH8cvn9ZmFOmiQ7I JtG0t+xvmEPHumLGGsLkJQ08DFd7iuJehZtunAVACRC8D2QSZQSX4YAi0b0k9ypqHc0j 704iArxedTCpRf2/wOmBkFd/56+gUZItBY0K/uH2Ye+Cww8lmQlCv9L3Mndy71yrNYvL 5plA== X-Gm-Message-State: APjAAAXaGUzoIZVCrK5SV3W2iuwJ7OrEuyBkzGxxw0PV31ncxJS9YqNv affYVtMj1SVPW4zn7C9ckTr8fvG9bb5YdTKnYTWhDLw+9d4swIPHliAm8wfDTew6M3PpssUW1V5 bYu7+RiH43wpN1HwSbrkSJV1cCG2H9H7l2/AfdG9Y6AUvMMoW X-Received: by 2002:a0c:e7cb:: with SMTP id c11mr15422089qvo.8.1566828797174; Mon, 26 Aug 2019 07:13:17 -0700 (PDT) X-Google-Smtp-Source: APXvYqyp9qGDUSC6vXKGYuDA5/DdcPGEOAOlETDdKVvl80UT2GC0qSTGWmuHxpZNCWAn5PNqzglQuT05v3v8DzUTlzw= X-Received: by 2002:a0c:e7cb:: with SMTP id c11mr15422056qvo.8.1566828796826; Mon, 26 Aug 2019 07:13:16 -0700 (PDT) MIME-Version: 1.0 References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> <20190825164839.GA77144@verdi> <715FF08E-9DD1-4052-BE1D-3C3AA614B560@strayalpha.com> <22eceb42-70a0-04ad-dc2c-4550f0cf87a5@si6networks.com> <276F8587-603C-499A-A89F-3387589D6E6B@strayalpha.com> In-Reply-To: <276F8587-603C-499A-A89F-3387589D6E6B@strayalpha.com> From: Henning Schulzrinne Date: Mon, 26 Aug 2019 10:12:49 -0400 Message-ID: To: Joe Touch Cc: Fernando Gont , architecture-discuss@iab.org Content-Type: multipart/alternative; boundary="000000000000dbe9e9059105c14a" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.84 on 128.59.72.16 Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 14:13:29 -0000 --000000000000dbe9e9059105c14a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Given that the economic incentives are against providing such services, and competition in most jurisdictions is weak or largely non-existent (US) and that competition for user-invisible features is difficult, you are asking for regulatory intervention. (Nothing wrong with that - you could consider this a version of a market failure.) The additional problem is that you need near-100% compliance to allow systems designers to rely on these capabilities. Thus, unless almost every ISP allows non-UDP/TCP transport layers, nobody is going to be building such layers. As a matter of terminology, we also seem to be re-iterating the old discussion that layers are no longer quite as simple as they used to be in the 1980s, where the function of a layer can now be broken up into multiple sub-layers, shims or whatever else you'd want to call them. As an older example, you could argue that RTP is a (specialized) transport protocol, used with UDP or TCP, for timing-sensitive applications. Henning On Mon, Aug 26, 2019 at 1:41 AM Joe Touch wrote: > > > On Aug 25, 2019, at 10:30 PM, Fernando Gont wrote= : > > When should my ISP start billing me for the "true Internet" service? > When it works with Google, or with everyone? If the former: Does it > matter? If the latter: would it ever happen? > > > 1. provide endpoint services that use certified implementations > 2. give me real Internet service, per below > > No, this won=E2=80=99t fix everything. But it=E2=80=99s the set of steps = we need to take > first. > > The next step is to highlight where these rules don=E2=80=99t work as not= working. > Not endorse them as =E2=80=9Cde facto changes to the baseline=E2=80=9D. > > Joe > > Bill of Internet Access Rights > > Joe Touch > USC/ISI > June 21, 2006 > (this is an update of a set of rules originally presented at "Preventing > the Internet Meltdown", Los Angeles CA 2004; the original is also present= ed > below) > > Internet is an association of communicating parties. This necessarily > results in a number of rights which are required for consenting parties t= o > communicate. Consenting parties should be able to communicate in an > unrestricted fashion, insofar as they do not impinge on the corresponding > rights of other parties. The following is a list of specific rights to th= at > end: > > 1. REAL IP: Users have the right to obtain a real IP address, routable > from anywhere on the Internet. > > 2. REAL DNS (& REVERSE-DNS): Users have the right to obtain a valid > reverse DNS name for that IP address, and the forward lookup of that name > should match the same address. > > 3. RECEIVE ANY: Users have the right to receive any valid IP packet, usin= g > any valid transport protocol on any valid port (if applicable), up to the > limits of your local resources and network connection. > > 4. SEND ANY: Users have the right to send any valid IP packet to any vali= d > real IP address, using any transport protocol, on any valid port (if > applicable), provided it uses an inconsequential amount of resources of t= he > network and potential receiver until mutual consent is established. > > 5. ENFORCEMENT: Users have the right to know the ISP responsible for > traffic from any valid IP address, sufficient to register a complaint > regarding violations of any of these rules. > > --000000000000dbe9e9059105c14a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Given that the economic incentives are against provid= ing such services, and competition in most jurisdictions is weak or largely= non-existent (US) and that competition for user-invisible features is diff= icult, you are asking for regulatory intervention. (Nothing wrong with that= - you could consider this a version of a market failure.)

The additional problem is that you need near-100% compliance to al= low systems designers to rely on these capabilities. Thus, unless almost ev= ery ISP allows non-UDP/TCP transport layers, nobody is going to be building= such layers.

As a matter of terminology, we also = seem to be re-iterating the old discussion that layers are no longer quite = as simple as they used to be in the 1980s, where the function of a layer ca= n now be broken up into multiple sub-layers, shims or whatever else you'= ;d want to call them. As an older example, you could argue that RTP is a (s= pecialized) transport protocol, used with UDP or TCP, for timing-sensitive = applications.

Henning

On Mon, Aug 26, 2019 at 1:41 = AM Joe Touch <touch@strayalpha.c= om> wrote:


On Aug 25, 2019, at 10:30 PM, Fernando Gont <fgont@si6networks.com>= ; wrote:

When should my I= SP start billing me for the "true Internet" service?
When it works= with Google, or with everyone? If the former: Does it
matter? If the latter= : would it ever happen?

1. provide = endpoint services that use certified implementations
2. give me r= eal Internet service, per below

No, this won=E2=80= =99t fix everything. But it=E2=80=99s the set of steps we need to take firs= t.

The next step is to highlight where these rules= don=E2=80=99t work as not working. Not endorse them as =E2=80=9Cde facto c= hanges to the baseline=E2=80=9D.

Joe

Bill of Internet Access Rights

Joe Touch
USC/ISI
June 21, 2006=C2=A0
= (this is an update of a set of rules originally presented at "Preventi= ng the Internet Meltdown", Los Angeles CA 2004; the original is also p= resented below)=C2=A0

Inte= rnet is an association of communicating parties. This necessarily results i= n a number of rights which are required for consenting parties to communica= te. Consenting parties should be able to communicate in an unrestricted fas= hion, insofar as they do not impinge on the corresponding rights of other p= arties. The following is a list of specific rights to that end:

1. REAL IP: Users have the ri= ght to obtain a real IP address, routable from anywhere on the Internet.

2. REAL DNS (& REVERSE-DNS): Users have the right to obtain a valid= reverse DNS name for that IP address, and the forward lookup of that name = should match the same address.

3. RECEIVE ANY: Users have the right t= o receive any valid IP packet, using any valid transport protocol on any va= lid port (if applicable), up to the limits of your local resources and netw= ork connection.

4. SEND ANY: Users have the right to send any valid I= P packet to any valid real IP address, using any transport protocol, on any= valid port (if applicable), provided it uses an inconsequential amount of = resources of the network and potential receiver until mutual consent is est= ablished.

5. ENFORCEMENT: Users have the right to know the ISP respon= sible for traffic from any valid IP address, sufficient to register a compl= aint regarding violations of any of these rules.

--000000000000dbe9e9059105c14a-- From nobody Mon Aug 26 09:23:21 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836AD120978 for ; Mon, 26 Aug 2019 09:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ffvx7daXEQuu for ; Mon, 26 Aug 2019 09:23:17 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id AC04E12096A for ; Mon, 26 Aug 2019 09:23:17 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 78332908BFA; Mon, 26 Aug 2019 12:07:18 -0400 (EDT) Date: Mon, 26 Aug 2019 12:07:18 -0400 From: John Leslie To: Henning Schulzrinne Cc: Joe Touch , architecture-discuss@iab.org Message-ID: <20190826160718.GA92015@verdi> References: <87imqnvhui.wl-morrowc@ops-netman.net> <20190825164839.GA77144@verdi> <715FF08E-9DD1-4052-BE1D-3C3AA614B560@strayalpha.com> <22eceb42-70a0-04ad-dc2c-4550f0cf87a5@si6networks.com> <276F8587-603C-499A-A89F-3387589D6E6B@strayalpha.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 16:23:20 -0000 Henning Schulzrinne wrote: > > Given that the economic incentives are against providing such services, > and competition in most jurisdictions is weak or largely non-existent > (US) and that competition for user-invisible features is difficult, > you are asking for regulatory intervention. (Nothing wrong with that - > you could consider this a version of a market failure.) It _is_ a market failure, of course; but hardly a failure of a _free_ market. There is no such thing in communication services. The proper question, of course isn't whether it's "wrong," but rather whether "regulatory intervention" is likely to improve things. > The additional problem is that you need near-100% compliance to allow > systems designers to rely on these capabilities. ROTFL. > Thus, unless almost every ISP allows non-UDP/TCP transport layers, > nobody is going to be building such layers. The classic statement, of course, is that may be considered "damage" and we "route around it." (I thought that was well-known; and we agreed upon it. But I may be wrong!) There is already quite an infrastructure of "virtual private networks" to bypass censorship choke-points. The same solution can be set up to bypass other internet choke-points; and I wouldn't be surprised to see these become popular... ... when individual users feel the pain. Alas, too many of _us_ expect to replace sub-optimal government policies with good government policies. (I was guilty of that myself fifty years ago.) Others of us place our faith in government incompetence (which faith seems well-founded) and think we can use international organizations such as IETF.org to trump their incompetence. YMMV... My attitude is that our salvation lies in numbers: that traffic _will_ increase, and overheads which were intolerable thirty years ago will pale into insignificance and no government will be able to search for them. Thus "tunneling" in the generic sense will become our favored tool. But I'm not wasting my time trying to define the perfect tunneling tool; least of all chasing the "perfect" tunneling architecture. (Right now, alas, I'm looking for a way to "tunnel" around 30% packet loss, which is this week's "damage" being inflicted upon New Hampshire by the incompetence of our too-few home Internet services.) > As a matter of terminology, we also seem to be re-iterating the old > discussion that layers are no longer quite as simple as they used to > be in the 1980s, where the function of a layer can now be broken up > into multiple sub-layers, shims or whatever else you'd want to call > them. "shims" is a good name. I'd love to facilitate that discussion. I'm not sure I can, since the backgrounds of our participants vary so much. > As an older example, you could argue that RTP is a (specialized) > transport protocol, used with UDP or TCP, for timing-sensitive > applications. ;^) -- John Leslie From nobody Tue Aug 27 17:35:00 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B736F120863 for ; Tue, 27 Aug 2019 17:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ztgcYvDSLE-2 for ; Tue, 27 Aug 2019 17:34:49 -0700 (PDT) Received: from outprodmail02.cc.columbia.edu (outprodmail02.cc.columbia.edu [128.59.72.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBFDE120835 for ; Tue, 27 Aug 2019 17:34:49 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by outprodmail02.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id x7S0YhNi015979 for ; Tue, 27 Aug 2019 20:34:48 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 52C9E6D for ; Tue, 27 Aug 2019 20:34:48 -0400 (EDT) Received: from sendprodmail02.cc.columbia.edu (sendprodmail02.cc.columbia.edu [128.59.72.14]) by hazelnut (Postfix) with ESMTP id 0C2996D for ; Tue, 27 Aug 2019 20:34:48 -0400 (EDT) Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by sendprodmail02.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id x7S0YlBB031134 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 27 Aug 2019 20:34:47 -0400 Received: by mail-qt1-f197.google.com with SMTP id k13so724082qtp.15 for ; Tue, 27 Aug 2019 17:34:47 -0700 (PDT) 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:from:date :message-id:subject:to:cc; bh=RYAAWADPrCYtwGDIosxF5qKeH/z9Du6RApZAvdylflg=; b=Ej+HyUGWy0IJuEJGA2nLDzEC8/hw+RXlYtrdZKt3Wi/D6g2DF+kLLg35yV0rN0yo5U PZewFExRoTxekwCQ3d5F99lzDoaz3rFQMhiy5RHGZZi4oPDtr7uyGcAG487wQBc+ytVz iFwKiUO1f2mPq7d6AN9I/TKItQSMop4Voua6aMi43hNkAdlbmsV9d9mIObFzNekR4iaI LBNpakjiDdXQq+EIihU8K2k9Tfmv5UzD0CEJYGN4ntB6LvPlBOtJwaALNhFpjX/I6PjS JCJNwHhs4Zomjh3oxZxecfpepMvVnS/fG8vTh6G9dIY/MDfMUV+Ly1YgCsCZUVuKaeCg DQ3Q== X-Gm-Message-State: APjAAAX3M7vPeOYYvteiUlVG+GxGsXn2UZhgGvsOiJa4kZOK64tXsWOm XPKWszJKAsbCtBCBcGlQJnfIbe/tjvlANCZslc2yFfxH78tvcbxioNpfuCMqCoQJDjgRJ8DM3su Xmu3S/2P+LuaG/OEkgMGtpQahe9KdDFhHkhZ9MscpCknbEvuJ X-Received: by 2002:ac8:1195:: with SMTP id d21mr1766345qtj.164.1566952487115; Tue, 27 Aug 2019 17:34:47 -0700 (PDT) X-Google-Smtp-Source: APXvYqw7bOKy6RrstIPNcCDJeVrS6GtTs4K/h47skH+MiIMNF0xljEMkMuxJkX3j3kz05ujD2QCAgBJNG7wSwJCGhnE= X-Received: by 2002:ac8:1195:: with SMTP id d21mr1766324qtj.164.1566952486802; Tue, 27 Aug 2019 17:34:46 -0700 (PDT) MIME-Version: 1.0 References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> <20190825164839.GA77144@verdi> <715FF08E-9DD1-4052-BE1D-3C3AA614B560@strayalpha.com> <22eceb42-70a0-04ad-dc2c-4550f0cf87a5@si6networks.com> In-Reply-To: <22eceb42-70a0-04ad-dc2c-4550f0cf87a5@si6networks.com> From: Henning Schulzrinne Date: Tue, 27 Aug 2019 20:34:20 -0400 Message-ID: To: Fernando Gont Cc: Joe Touch , architecture-discuss@iab.org Content-Type: multipart/alternative; boundary="0000000000005b22300591228e94" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.84 on 128.59.72.14 Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 00:35:00 -0000 --0000000000005b22300591228e94 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable When the US regulatory landscape was friendlier to Open Internet ideas, BITAG (https://bitag.org/) was created to look at related issues and make recommendations. Unless you can convince people that this yields shorter ping times for FPS games or "cyber security!", I doubt that this will get much consumer traction, except from the subscribers of the IETF mailing list. That said, my sense is that smaller, regional ISPs (such as the emerging community and rural electric fiber networks in the US) are actually pretty protocol-transparent - mostly because they run plain-vanilla configurations of network routers and don't have the in-house engineering resources to do fancy traffic management. They also generally advertise themselves as supporters of network neutrality, partially as a differentiator from their traditional corporate competitors. Having a "good Internet housekeeping" badge for them that they can readily self-certify for by running some tool could be quite useful. Henning On Mon, Aug 26, 2019 at 1:30 AM Fernando Gont wrote= : > On 26/8/19 07:50, Joe Touch wrote: > > > > > >> On Aug 25, 2019, at 12:16 PM, Henning Schulzrinne >> > wrote: > >> > >> Some of us who worked on the Open Internet (aka network neutrality) > >> saw "protocol neutrality" as very much part of the same spirit and > >> possibly a legal entitlement of customers. And the issue of naming > >> "Internet access" implying some obligations was also part of the > >> discussion. Experience seems to indicate that only legal or regulatory > >> requirements are likely to lead there, > > > > That hasn=E2=80=99t been the case for SONET, ATM, or Ethernet services. > > > > If we had a clear definition of =E2=80=9CISOC-certified Internet servic= e=E2=80=9D, then: > > a) customers might be willing to seek that > > b) customers who pay for that have a clear legal path if that=E2=80=99s= what was > > offered and it isn=E2=80=99t true > > If one means to get on that path, I'd start with certified > implementations -- at times, the service is a consequence of this. > > One of the most obvious cases is e.g. IPv6 implementations that are > "IPv6 Ready", but then do an extremely lousy job (see "IPv6 Security > Assessment and Benchmarking" at > http://www.ipv6hackers.org/meetings/ipv6-hackers-1). > > > > >> given that many carriers have no economic interest to do this - and > >> carrier-grade NATs make it painful or impossible to move beyond TCP > >> and UDP. > >> > >> Henning > > > > We could have two versions of service - ISOC-certified true Internet an= d > > ISOC-certified translated Internet (the latter so we don=E2=80=99t free= ze out > > carriers to start). People might pay more for the former. > > Without giving this a lot of thought, the problem with "certified > Internet" is that one would expect that to apply to all destinations and > paths. > > When should my ISP start billing me for the "true Internet" service? > When it works with Google, or with everyone? If the former: Does it > matter? If the latter: would it ever happen? > > (I bet many of us, nevertheless, when prompted with the question of > which one we want to buy, would ask the question: what can I do with the > expensive one that I can't with the other? (as opposed to "what one > could *potentially* do). > > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > --0000000000005b22300591228e94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
When the US regulatory landscape was friendlier to Op= en Internet ideas, BITAG (https://bitag.org/= ) was created to look at related issues and make recommendations.
=

Unless you can convince people that this yields shorter= ping times for FPS games or "cyber security!", I doubt that this= will get much consumer traction, except from the subscribers of the IETF m= ailing list.

That said, my sense is that smaller, = regional ISPs (such as the emerging community and rural electric fiber netw= orks in the US) are actually pretty protocol-transparent - mostly because t= hey run plain-vanilla configurations of network routers and don't have = the in-house engineering resources to do fancy traffic management. They als= o generally advertise themselves as supporters of network neutrality, parti= ally as a differentiator from their traditional corporate competitors. Havi= ng a "good Internet housekeeping" badge for them that they can re= adily self-certify for by running some tool could be quite useful.

Henning

On Mon, Aug 26, 2019 at 1:30 AM Fernando Gont <<= a href=3D"mailto:fgont@si6networks.com">fgont@si6networks.com> wrote= :
On 26/8/19 07:= 50, Joe Touch wrote:
>
>
>> On Aug 25, 2019, at 12:16 PM, Henning Schulzrinne <hgs@cs.columbia.edu
>> <mailto:hgs@cs.columbia.edu>> wrote:
>>
>> Some of us who worked on the Open Internet (aka network neutrality= )
>> saw "protocol neutrality" as very much part of the same = spirit and
>> possibly a legal entitlement of customers. And the issue of naming=
>> "Internet access" implying some obligations was also par= t of the
>> discussion. Experience seems to indicate that only legal or regula= tory
>> requirements are likely to lead there,
>
> That hasn=E2=80=99t been the case for SONET, ATM, or Ethernet services= .
>
> If we had a clear definition of =E2=80=9CISOC-certified Internet servi= ce=E2=80=9D, then:
> a) customers might be willing to seek that
> b) customers who pay for that have a clear legal path if that=E2=80=99= s what was
> offered and it isn=E2=80=99t true

If one means to get on that path, I'd start with certified
implementations -- at times, the service is a consequence of this.

One of the most obvious cases is e.g. IPv6 implementations that are
"IPv6 Ready", but then do an extremely lousy job (see "IPv6 = Security
Assessment and Benchmarking" at
http://www.ipv6hackers.org/meetings/ipv6-hackers-1= ).



>> given that many carriers have no economic interest to do this - an= d
>> carrier-grade NATs make it painful or impossible to move beyond TC= P
>> and UDP.
>>
>> Henning
>
> We could have two versions of service - ISOC-certified true Internet a= nd
> ISOC-certified translated Internet (the latter so we don=E2=80=99t fre= eze out
> carriers to start). People might pay more for the former.

Without giving this a lot of thought, the problem with "certified
Internet" is that one would expect that to apply to all destinations a= nd
paths.

When should my ISP start billing me for the "true Internet" servi= ce?
When it works with Google, or with everyone? If the former: Does it
matter? If the latter: would it ever happen?

(I bet many of us, nevertheless, when prompted with the question of
which one we want to buy, would ask the question: what can I do with the expensive one that I can't with the other? (as opposed to "what on= e
could *potentially* do).

--
Fernando Gont
SI6 Networks
e-mail: fgont@si= 6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




--0000000000005b22300591228e94-- From nobody Tue Aug 27 17:38:39 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053DA120824 for ; Tue, 27 Aug 2019 17:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 fC1yxLPXMzc7 for ; Tue, 27 Aug 2019 17:38:36 -0700 (PDT) Received: from outprodmail01.cc.columbia.edu (outprodmail01.cc.columbia.edu [128.59.72.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45367120026 for ; Tue, 27 Aug 2019 17:38:36 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by outprodmail01.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id x7S0Yh65020620 for ; Tue, 27 Aug 2019 20:38:35 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 356259D for ; Tue, 27 Aug 2019 20:38:35 -0400 (EDT) Received: from sendprodmail01.cc.columbia.edu (sendprodmail01.cc.columbia.edu [128.59.72.13]) by hazelnut (Postfix) with ESMTP id E396C80 for ; Tue, 27 Aug 2019 20:38:33 -0400 (EDT) Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by sendprodmail01.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id x7S0cXM9014147 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 27 Aug 2019 20:38:33 -0400 Received: by mail-qk1-f199.google.com with SMTP id x28so827698qki.21 for ; Tue, 27 Aug 2019 17:38:33 -0700 (PDT) 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:from:date :message-id:subject:to:cc; bh=gd1WVeMfJBr81DxmKm5cjzEP2o2XazvSWUcRJYMVCcc=; b=dyj4oiH9WdSHYIoQqjEHTStMTIhJDuV68gic0Z3b22QEdH6LcibRSvdeLRs4/ZPzxn HmsV/TN3PtqTDNhidEe2yjv4eLaQ2ZaO1KXmkbGDDnhFm00OAP7xIKJGZyue8daoKsD3 VOqOg1iwA5bFwnlXuqC7brRkv5AcnMZCTj66BVghFooXXjvqsIGoqq7BqpuGSb4hDtj+ rJMPHTTq0XQJG8MtHiHTNKqIyV1LV5UTAPxpFcHO8VGh/MnkxIE402AMevcVL2X2s94D Lez+V/Ia6c6ydpLYIoxhB4slb4INCexU9vUyEe2gC8ogqZa5QEEtDvoAMxuGKcw0r6AX Wl2A== X-Gm-Message-State: APjAAAWKM1utu421SIV8KYVIEQGHnPJUCyw+/Z/7JinGJQzel2FwOGV7 YKOPuubHHvHKtZkcPXq22VkDl0SyNBVXwJixKQUSNFtDBktEIarji4N54CRCH+Q3o0SdDghloA7 mUtufqYQmvlvAqcl8Rs5faj5XVmLv58CJtKy8BvhUbu1CJbbG X-Received: by 2002:a0c:ea8d:: with SMTP id d13mr1086055qvp.222.1566952712960; Tue, 27 Aug 2019 17:38:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqyPpqlB8QQQMKeVYj7pf5Q7wpA1ESXlfVyTpLFEwsdWWlXWuEYDD0KtCNnmaQRM15zJ9r6gwp0IdJg1koC47rA= X-Received: by 2002:a0c:ea8d:: with SMTP id d13mr1086042qvp.222.1566952712624; Tue, 27 Aug 2019 17:38:32 -0700 (PDT) MIME-Version: 1.0 References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> <20190825164839.GA77144@verdi> <715FF08E-9DD1-4052-BE1D-3C3AA614B560@strayalpha.com> In-Reply-To: From: Henning Schulzrinne Date: Tue, 27 Aug 2019 20:38:06 -0400 Message-ID: To: Joe Touch Cc: John Leslie , architecture-discuss@iab.org Content-Type: multipart/alternative; boundary="000000000000d0f1b00591229bc7" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.84 on 128.59.72.13 Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 00:38:38 -0000 --000000000000d0f1b00591229bc7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > > That hasn=E2=80=99t been the case for SONET, ATM, or Ethernet services. > Those services were purchases as telecommunication services by professionals, including other carriers, who wanted as much flexibility as possible to run random higher-layer protocols (IPX! Netbios! various versions of IP) on these networks. Each of these purchasers had significant bargaining power. They are sold by the thousands, at best, not to home users by the millions. Plus, they are closed, private networks, with no addressing issues (i.e., no NATs) and relatively simple delivery models. Thus, I don't think they can teach us much. Henning --000000000000d0f1b00591229bc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

=
That hasn=E2=80=99t been the case for SONET, ATM, or Ethernet se= rvices.

Those services we= re purchases as telecommunication services by professionals, including othe= r carriers, who wanted as much flexibility as possible to run random higher= -layer protocols (IPX! Netbios! various versions of IP) on these networks. = Each of these purchasers had significant bargaining power. They are sold by= the thousands, at best, not to home users by the millions. Plus, they are = closed, private networks, with no addressing issues (i.e., no NATs) and rel= atively simple delivery models. Thus, I don't think they can teach us m= uch.

Henning
=C2=A0
--000000000000d0f1b00591229bc7-- From nobody Tue Aug 27 19:29:02 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E493812081A for ; Tue, 27 Aug 2019 19:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.217 X-Spam-Level: X-Spam-Status: No, score=-1.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 7Yq6evi_uQBU for ; Tue, 27 Aug 2019 19:28:59 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF93C120807 for ; Tue, 27 Aug 2019 19:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zz+v6/xtGZ+M4yow2tANtzqSQ0iX/S3m2qNbVWl4tbU=; b=stO31E+XBGlw08cWFg5Ajj5Pa TDg2mLhZCeB7LTrcKJuLGCWrKZOynkxC9uiNuANmzSGrqtQFRjlNVv2wKOAfUL+s5WX0sqYaNHHDB YxIyfTkr/1x55LkgDmY3pTgxRT6hyS+5oXqxE9eQB+moCvOPoVrZ4gGhhtambEHwOWs8sQmiNyzwJ coSh1dWgqCsles9J+EtvayiwoH+/cpZXFsEajoLamrf7Rq6O1j0udy4pvpOjmqS6c+CD7Jf1fRejV fpXQ4k84RO0PCq7MuGU1Q37kxM6h0LRGr3wfdMJvFLEiDR7dKfGtNsENF6MDt+XJpaicMx98CT7DK 0X7L9u6ew==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:49487 helo=[192.168.1.4]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1i2nhZ-0015d0-SQ; Tue, 27 Aug 2019 22:28:54 -0400 Content-Type: multipart/alternative; boundary=Apple-Mail-62B83BB7-4D84-4E13-8E0F-33CBE6CDE963 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (16G102) In-Reply-To: Date: Tue, 27 Aug 2019 19:28:49 -0700 Cc: John Leslie , architecture-discuss@iab.org Content-Transfer-Encoding: 7bit Message-Id: References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> <20190825164839.GA77144@verdi> <715FF08E-9DD1-4052-BE1D-3C3AA614B560@strayalpha.com> To: Henning Schulzrinne X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 02:29:01 -0000 --Apple-Mail-62B83BB7-4D84-4E13-8E0F-33CBE6CDE963 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Aug 27, 2019, at 5:38 PM, Henning Schulzrinne wrote= : >>=20 >> That hasn=E2=80=99t been the case for SONET, ATM, or Ethernet services. >=20 > Those services were purchases as telecommunication services by professiona= ls, including other carriers, who wanted as much flexibility as possible to r= un random higher-layer protocols (IPX! Netbios! various versions of IP) on t= hese networks. Each of these purchasers had significant bargaining power. Th= ey are sold by the thousands, at best, not to home users by the millions. Pl= us, they are closed, private networks, with no addressing issues (i.e., no N= ATs) and relatively simple delivery models. Thus, I don't think they can tea= ch us much. Standards compliance means known full behavior. Not lowest common denominato= r behavior.=20 And I doubt there are only just thousands of either SONET or especially Ethe= rnet. =20 Joe >=20 > Henning > =20 --Apple-Mail-62B83BB7-4D84-4E13-8E0F-33CBE6CDE963 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Aug 27, 2019, at 5:38 PM, Henning Schulzrinne= <hgs@cs.columbia.edu> wrot= e:

=
=

That hasn= =E2=80=99t been the case for SONET, ATM, or Ethernet services.

Those services were purchases as teleco= mmunication services by professionals, including other carriers, who wanted a= s much flexibility as possible to run random higher-layer protocols (IPX! Ne= tbios! various versions of IP) on these networks. Each of these purchasers h= ad significant bargaining power. They are sold by the thousands, at best, no= t to home users by the millions. Plus, they are closed, private networks, wi= th no addressing issues (i.e., no NATs) and relatively simple delivery model= s. Thus, I don't think they can teach us much.

Standards compliance means known full behavior. N= ot lowest common denominator behavior. 

And I d= oubt there are only just thousands of either SONET or especially Ethernet. &= nbsp;

Joe


H= enning
 
= --Apple-Mail-62B83BB7-4D84-4E13-8E0F-33CBE6CDE963-- From nobody Tue Aug 27 19:38:41 2019 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB0D120806 for ; Tue, 27 Aug 2019 19:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 VQSZQXZhACl4 for ; Tue, 27 Aug 2019 19:38:38 -0700 (PDT) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 6028D120052 for ; Tue, 27 Aug 2019 19:38:38 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id y8so463495plr.12 for ; Tue, 27 Aug 2019 19:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8dgFI/3ghkpVSe/mY9eiCGEUOZST14bLH0JkUdzbMAE=; b=nzEEFRSBysKcc0XvPTHTgZlYuy2wnpVidQwr/WuoTiEfsxVcrKU28hwsdL29cCi8vD wJ7XF7rf0oL1rRRsNAvdCgFMCHsDWzQgoWk3KxDuzUUCTCyWv63T7Lzdx2JstfiH5mF5 VaLFcXT/lZOI5z0jV8zjry95mW8gedWz/LvQ8iiGEPuwkioOjzhqjWHS8jCDAoNhY0dP k2L0iSEIvAETSdxpwdrcqG+kurcbCE3Rrnb3LQN9gHyoRNvPOVbt1XARkkrPwzjLueNo RynFAASskeDDGhK2HZM5wdplcg438FZ7O8ycBA3j4RifgsIPnb+YaJGn479PUy0aOdZS 3BFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8dgFI/3ghkpVSe/mY9eiCGEUOZST14bLH0JkUdzbMAE=; b=QpgZtNxVqgfvgBJJKHr2g8DlFtDIlVxOEDLvvhGEDFoZC3pBDmY2u+z2J9l0g0S1KM bKZbKF5LNRQOqRakXis5UTA4nZqM8/TkijJEgWEFiFQOQsJHd6hniwOJLV77VZSTSZ4s C9fikouGEtb5zmtNBuLO4OOoA25MRYmuKJRx63uF6oDd8nWH0LtaQPjxqyvySWgOZJX0 zdSVYh2m2GMctPkIuE19fD1qg9LI+jSusdbbtHVdG9adhORBHFoqIPVUlcKYvR9j8OcL sJ7lyGrb+X3PhyyQkjU0i1vH9mN5JuZlzEMs2Ics0yr11J5JWDB1G6fZHp/sWX+lV+6l 4A3A== X-Gm-Message-State: APjAAAXOcBtwI+jtDR6LR4wfIKytk52bXFskRED+n/PCKpO5ndjub+yO YcTzzp9gk5A1gvmVDK++K/xCQpfd X-Google-Smtp-Source: APXvYqwF3YkFcSKEHUzIDuOUCFOwSlTterdIarmn7lVywlsLEP/LMA70Axv0XMPe+wo6V/9Ic0TaJw== X-Received: by 2002:a17:902:d917:: with SMTP id c23mr2076760plz.248.1566959917814; Tue, 27 Aug 2019 19:38:37 -0700 (PDT) Received: from [192.168.1.3] (c-73-158-115-137.hsd1.ca.comcast.net. [73.158.115.137]) by smtp.gmail.com with ESMTPSA id c71sm737970pfc.106.2019.08.27.19.38.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Aug 2019 19:38:37 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Tony Li In-Reply-To: Date: Tue, 27 Aug 2019 19:38:35 -0700 Cc: Henning Schulzrinne , architecture-discuss@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <7A175A31-64FE-44FE-971A-ADB2805EBC72@gmail.com> References: <770822F2-688F-44EA-A6A1-7E7EDBFAA989@trammell.ch> <64E3A59C-8709-41E0-B74F-C036E4481AE4@apple.com> <87imqnvhui.wl-morrowc@ops-netman.net> <20190825164839.GA77144@verdi> <715FF08E-9DD1-4052-BE1D-3C3AA614B560@strayalpha.com> To: Joe Touch X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [arch-d] FYI: closure of the IAB Stack Evolution program X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2019 02:38:39 -0000 > And I doubt there are only just thousands of either SONET or = especially Ethernet. =20 If you=E2=80=99re thinking that SONET or Ethernet compliance testing is = at all meaningful, please think again. Those systems interoperated due to the exact same market pressures that = exist at the protocol level: gear that does not interoperate gets = returned. If a vendor achieves market dominance and their implementation has = =E2=80=98quirks=E2=80=99, the rest of the market is forced to work = around those quirks. Tony