From nobody Wed Apr 1 04:11:48 2020 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 878B53A0906 for ; Wed, 1 Apr 2020 04:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=lastpresslabel-com.20150623.gappssmtp.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 ICHt3Xgt-5ko for ; Wed, 1 Apr 2020 04:11:45 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 2A10F3A0902 for ; Wed, 1 Apr 2020 04:11:45 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id m17so30003304wrw.11 for ; Wed, 01 Apr 2020 04:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lastpresslabel-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=rkqptKmSK8NKojeFug+mmS8U3NGeBTR4jBWGYZyWbrg=; b=fbWQyldqDR/jghMwHp5yop+oDBLXVFMiJ4WdkKRy4vkTpkqdi9L/9f7vL+oJzATBfV FiMldl+dLG2ipwXhg9634b8rtmL/PoXioUdC+S7rtA4FChVQ7euMWPxStyeD3AmG0cgt LM7EhvdFbN32XarL1zfAwMIeqFCmOnw59vXBurmZUVjvFWU9bw+zh610sC4/QmUYmINH k547Q81wEWXr8WAZt2JA3jzV02dIwwLOoK6WFepQgVpMTjGLSEYgxW7JbTXWXbio4mkF bYHkWSANlTyyRVOUQGoDOX9fqPQuDRsi+72NtxRxZtKUFxXnOt8SFLZoUBfwpbynO+V5 dK3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=rkqptKmSK8NKojeFug+mmS8U3NGeBTR4jBWGYZyWbrg=; b=UqppK4EmcCb2o99kgl/ePTLtIeCi+LKKk3QpjOMQuY/KGklFwcKbj4YB64oWMPXjp8 HkrJpaHwz5tMmtxuNpQEhTz79zyNniGElwVB252ryo6YzjsETkfoOgnqTKwgGgcBIWNU 38a96ZGpgTBNt2Jg/2KshLeIiVb9Y0+VbLkKBsHTUI8O3rJ3H70ZrBmh8r32DXOCqzD1 Sao+xW/wNkuezgFi0Z3cBNnZwJTln0seV6uP2h2jN+5orEBSmdWrmu29/iaWXgv3t9nW TrgPN1GCA7q5Ht9uprpZUU3VGz+c9ODjIRC3czGDVY4V115ozlE+a61LezpQl+/EY4G3 aZ/w== X-Gm-Message-State: ANhLgQ0pnSCakfAHRqqyjHky9RUSzu7tFQE7KX00EEYyBZEzU5cqmvqe 7OVIRpVf5QQn4P1LNgIpPyiEyccJnEJvQA== X-Google-Smtp-Source: ADFU+vuXaUcLPSr4HjTQmAjp5ycLLKieFL8AyYc2BXfogGlTm5bEtliTiIBFv2FUfxgdDbUCi3lVvA== X-Received: by 2002:adf:80af:: with SMTP id 44mr26159864wrl.241.1585739503292; Wed, 01 Apr 2020 04:11:43 -0700 (PDT) Received: from [10.8.2.2] ([89.34.98.95]) by smtp.gmail.com with ESMTPSA id r15sm2647050wra.19.2020.04.01.04.11.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2020 04:11:42 -0700 (PDT) From: Dominique Lazanski Content-Type: multipart/alternative; boundary="Apple-Mail=_5972FD15-3490-42D7-987E-EE6556DE5600" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Wed, 1 Apr 2020 13:11:40 +0200 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [arch-d] Internet consolidation draft expired 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, 01 Apr 2020 11:11:47 -0000 --Apple-Mail=_5972FD15-3490-42D7-987E-EE6556DE5600 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hiya, I just noticed that the draft-arkko-iab-internet-consolidation-02 has = expired. https://tools.ietf.org/html/draft-arkko-iab-internet-consolidation-02 = I think that this is an important issue, even in light of recent = discussions on this list. Happy to contribute if there is a plan to = continue this work. Dominique= --Apple-Mail=_5972FD15-3490-42D7-987E-EE6556DE5600 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hiya,

I just noticed that the draft-arkko-iab-internet-consolidation-02 has expired.


I think that this is an important issue, even in light of recent discussions on this list. Happy to contribute if there is a plan to continue this work.

Dominique
--Apple-Mail=_5972FD15-3490-42D7-987E-EE6556DE5600-- From nobody Wed Apr 1 05:19:43 2020 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 6E0533A0D3C for ; Wed, 1 Apr 2020 05:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KV59NoxJ8sF5 for ; Wed, 1 Apr 2020 05:19:39 -0700 (PDT) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 989863A0D3A for ; Wed, 1 Apr 2020 05:19:39 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id 22so25668497otf.0 for ; Wed, 01 Apr 2020 05:19:39 -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=SsQARYBAR+pYcxUKh/KRRZfVXLm2XbZ2qXSl9w3JoTE=; b=dIWmrI26f8yBQz1/3/hGxFFBN7bIJGYg7S8XOeQFmQVP5JQzQULI8y//QeuwbIbxRm dUic7bjxfljPlSA11s9VpQ2QmB7bw2MX09nPK/pU4pqc7fPYM3YT25j9YiVXYmBEcb24 nJPfXrCegAs0HSMRhUswROxhWSiirooCiWUU+7RUjKKhxV1J5xJLyHWPH/ar5HxcKIgl CyafCAgZZt4LA7kWHfeT4H8nHxGaCzsktfAwJBGvVdturzHCddEwK+56gKr+iHhNuMLK 1+ORn74gG8OZJw+oU3DCj18miCMZ57Odhal6gAnfdm+HVNuEzEvU9QXZhWmxoRzc2noH /lGw== 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=SsQARYBAR+pYcxUKh/KRRZfVXLm2XbZ2qXSl9w3JoTE=; b=BxMRIMh56maa1ccgJPwkW/ASWs2v9lCTZpxx72/u22BwdfkDf9WLzKfPpLjg/vtoca MnSa3qy8MhatOOt7dSeECsJG1U02gcLiMXHSCnlbxpDml5FkWJd+44ckzT/KYNYyYQr/ 6JPbAZlDvM8vdEteBOKyjWnH+U0wt4R0Y8vQ6+ZkQZa3SelKS9A0GqHn82P3jIhlG+EI 56dG24TXtuOnb57AWgcTi8gqHJG3ldnC0VXHshQzblvBlV9MENGIUtzMCucF8D216whH VPYOq9/r+xZWpSPlBYl398a/eDYTGNpHmKZec90nUdeEk7ZakPgar7dHSSu2lHV4zDYo qXuA== X-Gm-Message-State: ANhLgQ1bbd3ZVjbXwCwXZco8bEz6c20xkpaYArj5RLV1Wl6RqFnnp9MU oFlhI/Sdz7jO9oq/QxCXpVZxiAnpxl46Ww9Y0Yg= X-Google-Smtp-Source: ADFU+vtjmoalkp8vS8NIoQ6+QOPWobTThK5ju/mLbNZkAg1bDaDWzK9xuCxK1dFuWhAmBXWyh4GcBC4O6U88B0Tnbgs= X-Received: by 2002:a9d:69d5:: with SMTP id v21mr17260902oto.197.1585743578826; Wed, 01 Apr 2020 05:19:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a05:6830:13ce:0:0:0:0 with HTTP; Wed, 1 Apr 2020 05:19:38 -0700 (PDT) In-Reply-To: References: <20200331192101.GT30574@faui48f.informatik.uni-erlangen.de> <1E6F4BFD-C940-4490-8727-3E29DC21B70D@daley.org.nz> <20200331194000.GA28965@faui48f.informatik.uni-erlangen.de> From: Guntur Wiseno Putra Date: Wed, 1 Apr 2020 19:19:38 +0700 Message-ID: To: Eric Rescorla Cc: Toerless Eckert , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b88bbf05a239b2ac" Archived-At: Subject: Re: [arch-d] A Course on Network Engineering by the Internet Society 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, 01 Apr 2020 12:19:42 -0000 --000000000000b88bbf05a239b2ac Content-Type: text/plain; charset="UTF-8" Dear Eric & architecture-discuss, Concerning with the "Internet Architecture": I am thinking that/whether/if things are relevant, that/whether/if things are irrelevant: then I am thinking to let people choose/decide and keep thinking on their relevancy (-es)/irrelevancy(-es) as times run at architecture-discuss@ietf.org --as I tried to explain in the previous messages of mine in this threads. Thank you for caring of my posts... Regard, Guntur Wiseno Putra Pada Rabu, 01 April 2020, Eric Rescorla menulis: > n Tue, Mar 31, 2020 at 6:56 PM Guntur Wiseno Putra > wrote: > >> Dear Toerless, Jay, Mirja, Lars, Eric & >> architecture-discuss, >> >> Thank you, I am reading yours >> >> So, should we ingnore irrelevant things...? >> > > Yes, we should ignore irrelevant material but you should also stop posting > irrelevant material to this list. > > -Ekr > > >> >> >> >> >> Regard, >> Guntur Wiseno Putra >> >> Pada Rabu, 01 April 2020, Toerless Eckert menulis: >> >>> Thanks. I got a message that it was awaiting moderator >>> approval, and for usually non-moderated lists that typically means >>> it won't get processed. Sorry if i double posted because of that >>> problem. >>> >>> On Wed, Apr 01, 2020 at 08:27:03AM +1300, Jay Daley wrote: >>> > >>> > >>> > > On 1/04/2020, at 8:21 AM, Toerless Eckert wrote: >>> > > >>> > > architecture-discuss mailing list seems to be configured as to not >>> allow >>> > > it to be Bcc'ed, so not easy to move a discussion. Appended her what >>> > > i sent. >>> > >>> > Your bcc worked. >>> > >>> > Jay >>> > >>> > > >>> > > Cheers >>> > > Toerless >>> > > >>> > >> From tte@cs.fau.de Tue Mar 31 21:08:45 2020 >>> > > Date: Tue, 31 Mar 2020 21:08:45 +0200 >>> > > From: Toerless Eckert > >>> > > To: opsawg@ietf.org >>> > > Cc: Guntur Wiseno Putra >>> > > Bcc: architecture-discuss@ietf.org >>> > > In-Reply-To: >> ngWDPoXRA@mail.gmail.com> >>> > > >>> > > [Bcc: architecture-discuss] >>> > > [Thanks, Guntur for forwarding] >>> > > >>> > > Guntur got some negative responses on architecture-discuss for >>> posting >>> > > the info below, i hope questions about this to opsawg will find a >>> > > friendlier reception: >>> > > >>> > > - I thought it was great to see that ISOC engages in supporting >>> > > operations, i was not aware of this. >>> > > >>> > > - where would i have found an original announcement about something >>> like >>> > > this ? isoc mailing list(s) i can subscribe to without personally >>> > > being a member to ISOC personally ? >>> > > >>> > > - I was wondering if there are actually any i* mailing lists for >>> > > operators to discuss ops, e.g.: whoever would take this course >>> before >>> > > or after (certainly beyond scope of opsawg). >>> > > >>> > > I asked the email given on the isoc page, but got no response >>> > > (learning@isoc.org). >>> > > >>> > > Cheers >>> > > Toerless >>> > > >>> > >> _______________________________________________ >>> > >> Architecture-discuss mailing list >>> > >> Architecture-discuss@ietf.org >>> > >> https://www.ietf.org/mailman/listinfo/architecture-discuss >>> > > >>> > > On Mon, Mar 30, 2020 at 11:05:24PM +0700, Guntur Wiseno Putra wrote: >>> > >> Dear architecture-discuss, >>> > >> >>> > >> >>> > >> An update on "Network Engineering" released by the Internet Society >>> --this >>> > >> information I formerly got from Kevin Chege, Internet Society.. >>> > >> >>> > >> >>> > >> >>> > >> Online Course: Introduction to Network OperationsUNIX/Linux, >>> Networking & >>> > >> Domain Name System (DNS)The deadline for applications is 2 April >>> 2020. >>> > >> >>> > >> https://www.internetsociety.org/learning/network-operations/ >>> > >> >>> > >> >>> > >> Regard, >>> > >> Guntur Wiseno Putra >>> > > >>> > > _______________________________________________ >>> > > Architecture-discuss mailing list >>> > > Architecture-discuss@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/architecture-discuss >>> > >>> > -- >>> > Jay Daley >>> > jay@daley.org.nz >>> > +64 21 678840 >>> > >>> >>> _______________________________________________ >>> Architecture-discuss mailing list >>> Architecture-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/architecture-discuss >>> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >> > --000000000000b88bbf05a239b2ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Eric &
architecture-di= scuss,

Concerning with the "Int= ernet Architecture": I am thinking that/whether/if things are relevant= , that/whether/if things are irrelevant: then I am thinking to let people c= hoose/decide and keep thinking on their relevancy (-es)/irrelevancy(-es) as= times run at=C2=A0architecture-discuss@ietf.org=C2=A0--as I tried to exp= lain in the previous messages of mine in this threads.

Thank you for caring of my posts...


=
Regard,
Guntur Wiseno Putra





Pada Rabu, 01 April 2020, Eric Resc= orla <ekr@rtfm.com> menulis:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
n Tue, Mar 31, 2020 at 6:56 = PM Guntur Wiseno Putra <gsenopu@gmail.com> wrote:
Dear Toerless, Jay, Mirja, Lar= s, Eric &
architecture-discuss,

Thank you,= I am reading yours=C2=A0

So, should we ingnore ir= relevant things...?

=
Yes, we should ignore irrelevant material = but you should also stop posting irrelevant material to this list.

=
-Ekr






Regard,
Guntur Wiseno Putra

Pada Rabu, 01 = April 2020, Toerless Eckert <tte@cs.fau.de> menulis:
Thanks. I got a message that it was awaiting moderator
approval, and for usually non-moderated lists that typically means
it won't get processed. Sorry if i double posted because of that
problem.

On Wed, Apr 01, 2020 at 08:27:03AM +1300, Jay Daley wrote:
>
>
> > On 1/04/2020, at 8:21 AM, Toerless Eckert <tte@cs.fau.de> wrote:
> >
> > architecture-discuss mailing list seems to be configured as to no= t allow
> > it to be Bcc'ed, so not easy to move a discussion. Appended h= er what
> > i sent.
>
> Your bcc worked.
>
> Jay
>
> >
> > Cheers
> >=C2=A0 =C2=A0 Toerless
> >
> >> From tte@c= s.fau.de Tue Mar 31 21:08:45 2020
> > Date: Tue, 31 Mar 2020 21:08:45 +0200
> > From: Toerless Eckert <tte@cs..fau.de>
> > To: opsawg@i= etf.org
> > Cc: Guntur Wiseno Putra <gsenopu@gmail.com>
> > Bcc: architecture-discuss@ietf.org
> > In-Reply-To: <CAKi_AEuTOBDsUqqN-<= wbr>0dOGiwXriSyf9zYrDrabx0e-ngWDPoXRA@mail.gmail.com>
> >
> > [Bcc: architecture-discuss]
> > [Thanks, Guntur for forwarding]
> >
> > Guntur got some negative responses on architecture-discuss for po= sting
> > the info below, i hope questions about this to opsawg will find a=
> > friendlier reception:
> >
> > - I thought it was great to see that ISOC engages in supporting > >=C2=A0 operations, i was not aware of this.
> >
> > - where would i have found an original announcement about somethi= ng like
> >=C2=A0 this ? isoc mailing list(s) i can subscribe to without pers= onally
> >=C2=A0 being a member to ISOC personally ?
> >
> > - I was wondering if there are actually any i* mailing lists for<= br> > >=C2=A0 operators to discuss ops, e.g.: whoever would take this cou= rse before
> >=C2=A0 or after (certainly beyond scope of opsawg).
> >
> >=C2=A0 I asked the email given on the isoc page, but got no respon= se
> >=C2=A0 (lea= rning@isoc.org).
> >
> > Cheers
> >=C2=A0 =C2=A0 Toerless
> >
> >> _______________________________________________
> >> Architecture-discuss mailing list
> >> Architecture-discuss@ietf.org
> >> https://www.ietf.org/mailman/listinfo/arch= itecture-discuss
> >
> > On Mon, Mar 30, 2020 at 11:05:24PM +0700, Guntur Wiseno Putra wro= te:
> >> Dear architecture-discuss,
> >>
> >>
> >> An update on "Network Engineering" released by the = Internet Society --this
> >> information I formerly got from Kevin Chege, Internet Society= ..
> >>
> >>
> >>
> >> Online Course: Introduction to Network OperationsUNIX/Linux, = Networking &
> >> Domain Name System (DNS)The deadline for applications is 2 Ap= ril 2020.
> >>
> >> https://www.internetsociety.org/learning= /network-operations/
> >>
> >>
> >> Regard,
> >> Guntur Wiseno Putra
> >
> > _______________________________________________
> > Architecture-discuss mailing list
> > Architecture-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/architec= ture-discuss
>
> --
> Jay Daley
> jay@daley.org.nz=
> +64 21 678840
>

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discu= ss
_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinf= o/architecture-discuss
--000000000000b88bbf05a239b2ac-- From nobody Wed Apr 1 19:04:56 2020 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 3D0D93A09C2 for ; Wed, 1 Apr 2020 19:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbfMAE-_v10i for ; Wed, 1 Apr 2020 19:04:51 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 71A7E3A09C6 for ; Wed, 1 Apr 2020 19:04:51 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id r19so1832162otn.7 for ; Wed, 01 Apr 2020 19:04:51 -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=WaB7m1XnoXugezGfic3srqu18JlzWvv9NEmi35YfG+s=; b=Aj8S2KWc9NCKtXbjcWOvf/tVB0gWej/0bWUksoCzxrZDjS+9djxjxLPOyO8X/K24sI ckRUSfNR9VPcUTsHfygSRu2xE+Azj/JfBQheiMEUIkuNj1VH2+8A4qNCWxMDPeCfg/Ob dSDM4cVGA01VMNK/717/U2FI2pQFVw8Upwm+ps/xBpSbrSTDgJDd4zVQFQtjvcpn7KrN TdtSiKejpQ8eUbvdztb3SLEIb/ESI2bIGey3iLVdNFgV321ueXfUdm9eV98Hx/yf8+S9 MCYyI0uBElgFgzmD9YpAhSxRkwtrUGu6/YdTXRu3vrK7oWTjLAeU01j/YUmya/OKqUW/ /QWQ== 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=WaB7m1XnoXugezGfic3srqu18JlzWvv9NEmi35YfG+s=; b=W/7NY8XM3BFXT6I3gYIEEN/cYDs6SGs0NhHVQIi6A/w03YVeua36DF1K6gYQpHoW42 jEbxyQjGtuksHA+CyoWfh4MxrC3K7bDBuOS/e09LOpnglBSyePubPMpKqhFBxxRM3IQE OPrR04l4d+rjwFcIOZC1/ADoZsxN/o8G9ealanXlHn/2GTmTt5IAVuU9mog41IEH5qPK mJqycFDXNj1SoJttUFMGs/t9uch6OJQqPn9q7nwyVbm2UstPzTVbtdMMfH1OS7F6dPRM 6h4dgqOqOp5TjTQBPBXbGCTF0oCcEvEKgi6Mlt6PiygIZUi+2Gz/2BAdm2friSU3zR0q tnYQ== X-Gm-Message-State: AGi0Puaaf7iz2UMRPWgMW1iMP5kLT8YHWiqH2vB98eF1HDtaCML5cuCE p14bLDHJH6iHWbr6cD83ryY/vahsqmvebM/8L6voLA== X-Google-Smtp-Source: APiQypKJGKcMBenYaZcRYdARAVDb0XDAgHk1cbExMtTS/8Ll+wEL7cwipuhH7iZyFfy9r6X1MqJqZWnjM53Ekk2iNBM= X-Received: by 2002:a9d:798f:: with SMTP id h15mr668676otm.284.1585793090513; Wed, 01 Apr 2020 19:04:50 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a05:6830:13ce:0:0:0:0 with HTTP; Wed, 1 Apr 2020 19:04:50 -0700 (PDT) In-Reply-To: References: <20200331192101.GT30574@faui48f.informatik.uni-erlangen.de> <1E6F4BFD-C940-4490-8727-3E29DC21B70D@daley.org.nz> <20200331194000.GA28965@faui48f.informatik.uni-erlangen.de> From: Guntur Wiseno Putra Date: Thu, 2 Apr 2020 09:04:50 +0700 Message-ID: To: Eric Rescorla , "ietf@kuehlewind.net" Cc: Toerless Eckert , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d8ef5305a245395c" Archived-At: Subject: [arch-d] A Course on Network Engineering by the Internet Society 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, 02 Apr 2020 02:04:55 -0000 --000000000000d8ef5305a245395c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Eric, Toerless, Mirja & Architecture-discuss, Concerning with this architecture-discuss(@ietf/iab.org) mailing list: I remember that I ever red this article of the IETF Journal: "Reflections on Architecture" by Pekka Nikander 2005 By opening files at www.ietfjournal.org I finded this out: Among others this is one worked on by the IETF publication on "architecture" which mentioned also about "architecture-discuss" in the time of its beginning --I then made it part of the entry on "Consolidation of the Internet..." at the Internet Society's Open Forum Library: "I happen to have an architect=E2=80=99s mind. Looking at the network of to= day, I strongly feel the pain of the current architecture=E2=80=99s cracking and squeaking. Consequently, I believe that we =E2=80=93 the wider IETF communi= ty responsible for Internet technology =E2=80=93 need to re-think the architec= ture. We need to find a way to re-create the core of the Internet in a way that leads to a new era of innovation and intellectual prosperity. The highlight of my IETF64 meeting in Vancouver was that I started to see signs of interest and activity in the broader community to pursue such a goal. ... The IAB has recently created a new mailing list, architecture-discuss [15], for wider discussion of architectural issues, which I hope will develop into a valuable forum over time. I hope to see you there". https://www.ietfjournal.org/reflections-on-architecture Regard, Guntur Wiseno Putra Pada Rabu, 01 April 2020, Eric Rescorla menulis: > n Tue, Mar 31, 2020 at 6:56 PM Guntur Wiseno Putra > wrote: > >> Dear Toerless, Jay, Mirja, Lars, Eric & >> architecture-discuss, >> >> Thank you, I am reading yours >> >> So, should we ingnore irrelevant things...? >> > > Yes, we should ignore irrelevant material but you should also stop postin= g > irrelevant material to this list. > > -Ekr > > >> >> >> >> >> Regard, >> Guntur Wiseno Putra >> >> Pada Rabu, 01 April 2020, Toerless Eckert menulis: >> >>> Thanks. I got a message that it was awaiting moderator >>> approval, and for usually non-moderated lists that typically means >>> it won't get processed. Sorry if i double posted because of that >>> problem. >>> >>> On Wed, Apr 01, 2020 at 08:27:03AM +1300, Jay Daley wrote: >>> > >>> > >>> > > On 1/04/2020, at 8:21 AM, Toerless Eckert wrote: >>> > > >>> > > architecture-discuss mailing list seems to be configured as to not >>> allow >>> > > it to be Bcc'ed, so not easy to move a discussion. Appended her wha= t >>> > > i sent. >>> > >>> > Your bcc worked. >>> > >>> > Jay >>> > >>> > > >>> > > Cheers >>> > > Toerless >>> > > >>> > >> From tte@cs.fau.de Tue Mar 31 21:08:45 2020 >>> > > Date: Tue, 31 Mar 2020 21:08:45 +0200 >>> > > From: Toerless Eckert > >>> > > To: opsawg@ietf.org >>> > > Cc: Guntur Wiseno Putra >>> > > Bcc: architecture-discuss@ietf.org >>> > > In-Reply-To: >> f9zYrDrabx0e-ngWDPoXRA@mail.gmail.com> >>> > > >>> > > [Bcc: architecture-discuss] >>> > > [Thanks, Guntur for forwarding] >>> > > >>> > > Guntur got some negative responses on architecture-discuss for >>> posting >>> > > the info below, i hope questions about this to opsawg will find a >>> > > friendlier reception: >>> > > >>> > > - I thought it was great to see that ISOC engages in supporting >>> > > operations, i was not aware of this. >>> > > >>> > > - where would i have found an original announcement about something >>> like >>> > > this ? isoc mailing list(s) i can subscribe to without personally >>> > > being a member to ISOC personally ? >>> > > >>> > > - I was wondering if there are actually any i* mailing lists for >>> > > operators to discuss ops, e.g.: whoever would take this course >>> before >>> > > or after (certainly beyond scope of opsawg). >>> > > >>> > > I asked the email given on the isoc page, but got no response >>> > > (learning@isoc.org). >>> > > >>> > > Cheers >>> > > Toerless >>> > > >>> > >> _______________________________________________ >>> > >> Architecture-discuss mailing list >>> > >> Architecture-discuss@ietf.org >>> > >> https://www.ietf.org/mailman/listinfo/architecture-discuss >>> > > >>> > > On Mon, Mar 30, 2020 at 11:05:24PM +0700, Guntur Wiseno Putra wrote= : >>> > >> Dear architecture-discuss, >>> > >> >>> > >> >>> > >> An update on "Network Engineering" released by the Internet Societ= y >>> --this >>> > >> information I formerly got from Kevin Chege, Internet Society.. >>> > >> >>> > >> >>> > >> >>> > >> Online Course: Introduction to Network OperationsUNIX/Linux, >>> Networking & >>> > >> Domain Name System (DNS)The deadline for applications is 2 April >>> 2020. >>> > >> >>> > >> https://www.internetsociety.org/learning/network-operations/ >>> > >> >>> > >> >>> > >> Regard, >>> > >> Guntur Wiseno Putra >>> > > >>> > > _______________________________________________ >>> > > Architecture-discuss mailing list >>> > > Architecture-discuss@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/architecture-discuss >>> > >>> > -- >>> > Jay Daley >>> > jay@daley.org.nz >>> > +64 21 678840 >>> > >>> >>> _______________________________________________ >>> Architecture-discuss mailing list >>> Architecture-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/architecture-discuss >>> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >> > --000000000000d8ef5305a245395c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Eric, Toerless, Mirja &
Architecture-discuss,


Concerning with this architecture-discuss(@ietf/iab.org) mailing list: I remember that I ever r= ed this article of the IETF Journal:

"Reflect= ions on Architecture" by Pekka Nikander 2005

=

By opening files at=C2=A0www.ietfjournal.org=C2=A0I finded this ou= t: Among others this is one worked on by the IETF publication on "arch= itecture" which mentioned also about "architecture-discuss" = in the time of its beginning --I then made it part of the entry on "Co= nsolidation of the Internet..." at the Internet Society's Open For= um Library:


"I happen to have an architect=E2= =80=99s mind. Looking at the network of today, I strongly feel the pain of = the current architecture=E2=80=99s cracking and squeaking. Consequently, I = believe that we =E2=80=93 the wider IETF community responsible for Internet= technology =E2=80=93 need to re-think the architecture. We need to find a = way to re-create the core of the Internet in a way that leads to a new era = of innovation and intellectual prosperity. The highlight of my IETF64 meeti= ng in Vancouver was that I started to see signs of interest and activity in= the broader community to pursue such a goal.

=

...

The IAB has recently= created a new mailing list, architecture-discuss [15], for wider discussio= n of architectural issues, which I hope will develop into a valuable forum = over time. I hope to see you there".

https://www.iet= fjournal.org/reflections-on-architecture



Regard,
Guntur Wiseno P= utra

Pada Rabu, 01 April 2020, Eric Rescorla <ekr@rtfm.com> menulis:
n Tue, Mar 31, 2020 at 6:56 PM Guntur = Wiseno Putra <gse= nopu@gmail.com> wrote:
Dear Toerless, Jay, Mirja, Lars, Eric &a= mp;
architecture-discuss,

Thank you, I am read= ing yours=C2=A0

So, should we ingnore irrelevant t= hings...?

Yes, we should ignore irrelevant material but you sh= ould also stop posting irrelevant material to this list.

-Ekr






Regard,
Guntur Wiseno Putra

Pada Rabu, 01 April 2020= , Toerless Eckert <tt= e@cs.fau.de> menulis:
Thanks. I got a message that it was awaiting moderator
approval, and for usually non-moderated lists that typically means
it won't get processed. Sorry if i double posted because of that
problem.

On Wed, Apr 01, 2020 at 08:27:03AM +1300, Jay Daley wrote:
>
>
> > On 1/04/2020, at 8:21 AM, Toerless Eckert <tte@cs.fau.de> wrote:
> >
> > architecture-discuss mailing list seems to be configured as to no= t allow
> > it to be Bcc'ed, so not easy to move a discussion. Appended h= er what
> > i sent.
>
> Your bcc worked.
>
> Jay
>
> >
> > Cheers
> >=C2=A0 =C2=A0 Toerless
> >
> >> From tte@c= s.fau.de Tue Mar 31 21:08:45 2020
> > Date: Tue, 31 Mar 2020 21:08:45 +0200
> > From: Toerless Eckert <tte@cs..fau.de>
> > To: opsawg@i= etf.org
> > Cc: Guntur Wiseno Putra <gsenopu@gmail.com>
> > Bcc: architecture-discuss@ietf.org
> > In-Reply-To: <CAKi_AEuTOBDsUqqN-0= dOGiwXriSyf9zYrDrabx0e-ngWDPoXRA@mail.gmail.com>
> >
> > [Bcc: architecture-discuss]
> > [Thanks, Guntur for forwarding]
> >
> > Guntur got some negative responses on architecture-discuss for po= sting
> > the info below, i hope questions about this to opsawg will find a=
> > friendlier reception:
> >
> > - I thought it was great to see that ISOC engages in supporting > >=C2=A0 operations, i was not aware of this.
> >
> > - where would i have found an original announcement about somethi= ng like
> >=C2=A0 this ? isoc mailing list(s) i can subscribe to without pers= onally
> >=C2=A0 being a member to ISOC personally ?
> >
> > - I was wondering if there are actually any i* mailing lists for<= br> > >=C2=A0 operators to discuss ops, e.g.: whoever would take this cou= rse before
> >=C2=A0 or after (certainly beyond scope of opsawg).
> >
> >=C2=A0 I asked the email given on the isoc page, but got no respon= se
> >=C2=A0 (lea= rning@isoc.org).
> >
> > Cheers
> >=C2=A0 =C2=A0 Toerless
> >
> >> _______________________________________________
> >> Architecture-discuss mailing list
> >> Architecture-discuss@ietf.org
> >> https://www.ietf.org/mailman/listinfo/arch= itecture-discuss
> >
> > On Mon, Mar 30, 2020 at 11:05:24PM +0700, Guntur Wiseno Putra wro= te:
> >> Dear architecture-discuss,
> >>
> >>
> >> An update on "Network Engineering" released by the = Internet Society --this
> >> information I formerly got from Kevin Chege, Internet Society= ..
> >>
> >>
> >>
> >> Online Course: Introduction to Network OperationsUNIX/Linux, = Networking &
> >> Domain Name System (DNS)The deadline for applications is 2 Ap= ril 2020.
> >>
> >> https://www.internetsociety.org/learning= /network-operations/
> >>
> >>
> >> Regard,
> >> Guntur Wiseno Putra
> >
> > _______________________________________________
> > Architecture-discuss mailing list
> > Architecture-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/architec= ture-discuss
>
> --
> Jay Daley
> jay@daley.org.nz=
> +64 21 678840
>

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discu= ss
_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinf= o/architecture-discuss
--000000000000d8ef5305a245395c-- From nobody Wed Apr 1 19:17:35 2020 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 2DB523A0A41 for ; Wed, 1 Apr 2020 19:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=mnot.net header.b=gKj2U4AP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BeIsGEqP 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 Jakqv9fP2jcM for ; Wed, 1 Apr 2020 19:17:29 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F58C3A0A3E for ; Wed, 1 Apr 2020 19:17:29 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 57F1C680; Wed, 1 Apr 2020 22:17:28 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 01 Apr 2020 22:17:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=x cSCAAdv9KTtDCmxp+VJLe2xFR6A82IJvMl1o2N9Y2M=; b=gKj2U4APS+4IZfAxh 1KLjJVNYhN8nCt39CdszLZ66fNibqWvSwCv0AX06LQl2vCsLuteHqFN0GRoWhMlm JBV/TkGHztm+QkukOS9l3vB0DmR60pQdAjmXXEJ+wQDPdlX3KCycAFTNcM3c42wM 8Fs8QoNSoJVQPT19zRZ8NjsEgr1iPbbdL4AwA/w05sUKl+KT0U8nynQ5lg2akxta U9shihrEzQfy+RvyyJqCtiVqN5lndAfE+035W5EXUwWfjMXFPhYO3MItWXApGAYq nBvK/Bp2jUE++gSZi3aIKzNkuFiPqA7FhTFP89t3b75/vBok/iF2yNR8gVPLBW2A 5F/Cg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=xcSCAAdv9KTtDCmxp+VJLe2xFR6A82IJvMl1o2N9Y 2M=; b=BeIsGEqPS2mRUEiCMxxUq7QVCTGeEfibP21U51x4jLHNA17UHkmNtSAJQ xum2ivkw7HAwj8aRmb/ixuxvUYWA8n9qMzauzNvfnu4EsFFiA12r/Ej8FiyaNw1O 08RCRJTPwf9c+AiPiif1Zhm2SKgGBrZ4LdQaEYq445tht9eXPsCZp2zSwhAkAJom t2yCp38uViFecqt1qXHeoo2OYPYEkapjlFq7UkULwEjnyjZhSaJdLRFsWEIQCZiA 7WtoOkPlDJgqyWh2yS/S2RwWOIme37MNJDC3Z108vwuiW/yFOqtx7rl6RYRLaMTz njjbocfZ03RXXlBWhLVJjRfvCn0FQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrtdefgdehkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmh dthhdtjeenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhn ohhtrdhnvghtqeenucffohhmrghinhepihgrsgdrohhrghdpihgvthhfjhhouhhrnhgrlh drohhrghdpihgvthhfrdhorhhgpdhinhhtvghrnhgvthhsohgtihgvthihrdhorhhgpdhm nhhothdrnhgvthenucfkphepudduledrudejrdduheekrddvhedunecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgv th X-ME-Proxy: Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 1B7FD328005A; Wed, 1 Apr 2020 22:17:23 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: Date: Thu, 2 Apr 2020 13:17:21 +1100 Cc: Eric Rescorla , "ietf@kuehlewind.net" , Toerless Eckert , "architecture-discuss@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200331192101.GT30574@faui48f.informatik.uni-erlangen.de> <1E6F4BFD-C940-4490-8727-3E29DC21B70D@daley.org.nz> <20200331194000.GA28965@faui48f.informatik.uni-erlangen.de> To: Guntur Wiseno Putra X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [arch-d] A Course on Network Engineering by the Internet Society 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, 02 Apr 2020 02:17:33 -0000 Gunter, I think the reason you're seeing pushback on the messages you send is = that they typically do NOT discuss architecture; instead, you tend to = send messages with one or more links and quotes that are often only = loosely related to Internet architecture (occasionally, with no obvious = linkage), or making vague pleas for ill-defined goals to be worked = towards. You would do better to assume that the people on this list are = reasonably well-informed about the field; i.e., as I understand it, this = is not a link-sharing list, but instead, it's a list for developing the = Internet architecture through discussion and original contributions. Please take this feedback in the spirit it was offered. Be warned, = however, that I'm not interested in a prolonged meta-discussion of the = nature of discussion, architecture, etc.; if you follow up to this = message as you have others, I'm afraid I'll be blocking your e-mail = address. Kind regards, > On 2 Apr 2020, at 1:04 pm, Guntur Wiseno Putra = wrote: >=20 > Dear Eric, Toerless, Mirja & > Architecture-discuss, >=20 >=20 > Concerning with this architecture-discuss(@ietf/iab.org) mailing list: = I remember that I ever red this article of the IETF Journal: >=20 > "Reflections on Architecture" by Pekka Nikander 2005 >=20 >=20 > By opening files at www.ietfjournal.org I finded this out: Among = others this is one worked on by the IETF publication on "architecture" = which mentioned also about "architecture-discuss" in the time of its = beginning --I then made it part of the entry on "Consolidation of the = Internet..." at the Internet Society's Open Forum Library: >=20 > "I happen to have an architect=E2=80=99s mind. Looking at the network = of today, I strongly feel the pain of the current architecture=E2=80=99s = cracking and squeaking. Consequently, I believe that we =E2=80=93 the = wider IETF community responsible for Internet technology =E2=80=93 need = to re-think the architecture. We need to find a way to re-create the = core of the Internet in a way that leads to a new era of innovation and = intellectual prosperity. The highlight of my IETF64 meeting in Vancouver = was that I started to see signs of interest and activity in the broader = community to pursue such a goal. > ... >=20 > The IAB has recently created a new mailing list, architecture-discuss = [15], for wider discussion of architectural issues, which I hope will = develop into a valuable forum over time. I hope to see you there". >=20 > https://www.ietfjournal.org/reflections-on-architecture >=20 >=20 >=20 > Regard, > Guntur Wiseno Putra >=20 > Pada Rabu, 01 April 2020, Eric Rescorla menulis: > n Tue, Mar 31, 2020 at 6:56 PM Guntur Wiseno Putra = wrote: > Dear Toerless, Jay, Mirja, Lars, Eric & > architecture-discuss, >=20 > Thank you, I am reading yours=20 >=20 > So, should we ingnore irrelevant things...? >=20 > Yes, we should ignore irrelevant material but you should also stop = posting irrelevant material to this list. >=20 > -Ekr >=20 >=20 >=20 >=20 >=20 >=20 > Regard, > Guntur Wiseno Putra >=20 > Pada Rabu, 01 April 2020, Toerless Eckert menulis: > Thanks. I got a message that it was awaiting moderator > approval, and for usually non-moderated lists that typically means > it won't get processed. Sorry if i double posted because of that > problem. >=20 > On Wed, Apr 01, 2020 at 08:27:03AM +1300, Jay Daley wrote: > >=20 > >=20 > > > On 1/04/2020, at 8:21 AM, Toerless Eckert wrote: > > >=20 > > > architecture-discuss mailing list seems to be configured as to not = allow > > > it to be Bcc'ed, so not easy to move a discussion. Appended her = what > > > i sent. > >=20 > > Your bcc worked. > >=20 > > Jay > >=20 > > >=20 > > > Cheers > > > Toerless > > >=20 > > >> =46rom tte@cs.fau.de Tue Mar 31 21:08:45 2020 > > > Date: Tue, 31 Mar 2020 21:08:45 +0200 > > > From: Toerless Eckert > > > To: opsawg@ietf.org > > > Cc: Guntur Wiseno Putra > > > Bcc: architecture-discuss@ietf.org > > > In-Reply-To: = > > >=20 > > > [Bcc: architecture-discuss] > > > [Thanks, Guntur for forwarding] > > >=20 > > > Guntur got some negative responses on architecture-discuss for = posting > > > the info below, i hope questions about this to opsawg will find a=20= > > > friendlier reception: > > >=20 > > > - I thought it was great to see that ISOC engages in supporting > > > operations, i was not aware of this. > > >=20 > > > - where would i have found an original announcement about = something like > > > this ? isoc mailing list(s) i can subscribe to without personally > > > being a member to ISOC personally ? > > >=20 > > > - I was wondering if there are actually any i* mailing lists for > > > operators to discuss ops, e.g.: whoever would take this course = before > > > or after (certainly beyond scope of opsawg). > > >=20 > > > I asked the email given on the isoc page, but got no response > > > (learning@isoc.org). > > >=20 > > > Cheers > > > Toerless > > >=20 > > >> _______________________________________________ > > >> Architecture-discuss mailing list > > >> Architecture-discuss@ietf.org > > >> https://www.ietf.org/mailman/listinfo/architecture-discuss > > >=20 > > > On Mon, Mar 30, 2020 at 11:05:24PM +0700, Guntur Wiseno Putra = wrote: > > >> Dear architecture-discuss, > > >>=20 > > >>=20 > > >> An update on "Network Engineering" released by the Internet = Society --this > > >> information I formerly got from Kevin Chege, Internet Society... > > >>=20 > > >>=20 > > >>=20 > > >> Online Course: Introduction to Network OperationsUNIX/Linux, = Networking & > > >> Domain Name System (DNS)The deadline for applications is 2 April = 2020. > > >>=20 > > >> https://www.internetsociety.org/learning/network-operations/ > > >>=20 > > >>=20 > > >> Regard, > > >> Guntur Wiseno Putra > > >=20 > > > _______________________________________________ > > > Architecture-discuss mailing list > > > Architecture-discuss@ietf.org > > > https://www.ietf.org/mailman/listinfo/architecture-discuss > >=20 > > --=20 > > Jay Daley > > jay@daley.org.nz > > +64 21 678840 > >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- Mark Nottingham https://www.mnot.net/ From nobody Thu Apr 2 08:27:34 2020 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 BD7D93A155C for ; Thu, 2 Apr 2020 08:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 DZv0AdetjJiE for ; Thu, 2 Apr 2020 08:27:25 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACF1E3A159B for ; Thu, 2 Apr 2020 08:27:22 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 3E568548049; Thu, 2 Apr 2020 17:27:17 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 39727440040; Thu, 2 Apr 2020 17:27:17 +0200 (CEST) Date: Thu, 2 Apr 2020 17:27:17 +0200 From: Toerless Eckert To: Stephen Farrell Cc: "chirp@iab.org" , architecture-discuss@ietf.org Message-ID: <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [arch-d] on the nature of architecture discussion (was: Re: [Chirp] Fwd: IETF 107 Vancouver In-Person Meeting Cancelled) 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, 02 Apr 2020 15:27:27 -0000 [Cc'ing to architecture-discuss, because this reply goes beyond the scope of chirp.] Stephen, *: I don't think that a mailing list alone is a sufficient way to encourage interested parties to invest significant amount of cycles to contribute original work towards a subject even if as a one off: document and/or presentation. If you want people to invest cycles towards something you're interested in, you need to give contributors a well defined opportunity to engage in-person through a meeting (or virtual meeting in the time of corona) and allowing the work invested to be referenceable by future work of others (such as meeting proceedings for presentations). We have this mode of operations in hundreds of conferences including IRTF, we have it in IETF WGs for standards, we do not have this for architectural discussions for the Internet. Why not ? Stephen, I know we may have a fundamental difference in opinion about this if i correctly interpret your harsh criticism about my teams organized inofficial side-meeting in march, but i for once don't think that a discussion about internet architecture will magically improve through the absence of such meetings. Why is there no internet architecture discuss meeting slot in every IETF meeting (virtual in times of corona) ? I can not even start to comprehend why i am seemingly the only one asking this question. To me, providing such fairly open scoped meeting looks like the most fundamental meeting the IAB should organize to engage the community in an open fashion. Consider it the "dispatch" equivalent of other areas. Topics of special interest to IAB (such as chirp) could be indicated as prioritized topics to encourage contribution to them, and if they show critical mass the could be dispatched into separate forums. I can see no outcome worse than what we seemingly have now on this architecture-discuss mailing list: agony and inactivity interrupted by often snide lecturing meta discussions about those who attempt to contribute something, however well or badly that is done. Cheers Toerless On Thu, Apr 02, 2020 at 12:32:27PM +0100, Stephen Farrell wrote: > > Hiya, > > I only got one request to hold such a meeting so I guess > we don't want one. > > That, and the lack of activity on this list is a bit of > a pity I think so ideas welcome as to how to energise a > discussion... If you have such an idea, then please just > start a new thread on the list. > > Cheers, > S. > > On 10/03/2020 20:50, Stephen Farrell wrote: > > > > Hi all, > > > > Many of you will have seen this but we'll not be meeting > > f2f in Vancouver this time. Hopefully things will have > > improved by the timeframe of IETF108 and we'll be able > > to enjoy a meeting then. > > > > In the meantime, would people like to organise a call > > in a few weeks to replace our planned get together in > > Vancouver? If so, please mail me, the IAB or the list:-) > > > > If we do want a call, the IESG have asked for a > > bit of time to do some scheduling that they need to do > > before WGs (and groups like us:-) start to schedule > > such calls. So let's first see if we want a call and > > then we can do scheduling. > > > > Cheers, > > S. > > > > > > -------- Forwarded Message -------- > > Subject: IETF 107 Vancouver In-Person Meeting Cancelled > > Date: Tue, 10 Mar 2020 12:10:27 -0700 > > From: The IESG > > Reply-To: iesg@ietf.org > > To: IETF Announcement List > > CC: irtf-announce@irtf.org, ietf@ietf.org, 107all@ietf.org > > > > The IESG and the IRTF Chair have decided to cancel the in-person IETF > > 107 Vancouver meeting. This decision is based on input we gathered from > > Working Group (WG) and Research Group (RG) chairs about our ability to > > hold productive WG and RG sessions at IETF 107. Our assessment of this > > feedback is that a majority of sessions would not be viable if we were > > to hold the in-person IETF meeting. On this basis, we believe we cannot > > hold an effective in-person meeting. > > As a result of this cancellation, the in-person Hackathon, Code Sprint, > > all other in-person events planned for the weekend of March 21-22, the > > chairs training scheduled for March 20, and all other in-person sessions > > during the week are cancelled. > > > > The IESG is working on an alternative all-virtual agenda for the week of > > March 21-27 with a limited schedule adapted to accommodate the time > > zones of as many participants as possible. We are also planning to > > support an increased volume of virtual interim meetings during the weeks > > that follow. We will send another update to the community soon with more > > information about these plans. The Hackathon organizers are also > > considering plans for virtual Hackathon support. > > > > We have re-opened Internet-Draft submissions, which had been closed on > > March 9 in anticipation of the in-person meeting. Internet-Drafts may be > > submitted at . > > > > A separate announcement from the IETF Executive Director will follow > > with details about registration cancellations and refunds. > > These are unusual times given the circumstances created by the spread of > > COVID-19. We hope that everyone remains safe and healthy. > > > > Regards, > > The IESG and the IRTF Chair > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-announce > > > > > > pub RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) > sub RSA 4096/36CB8BB6 2017-12-22 > > -- > Chirp mailing list > Chirp@iab.org > https://www.iab.org/mailman/listinfo/chirp -- --- tte@cs.fau.de From nobody Thu Apr 2 08:32:39 2020 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 8EF5C3A15B8 for ; Thu, 2 Apr 2020 08:32:13 -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, RCVD_IN_DNSWL_BLOCKED=0.001, 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 (1024-bit key) header.d=cs.tcd.ie 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 mWhsRBnqk7hg for ; Thu, 2 Apr 2020 08:32:11 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1A3C3A15C0 for ; Thu, 2 Apr 2020 08:32:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AEF7EBE74; Thu, 2 Apr 2020 16:32:08 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOj7fpLnluYl; Thu, 2 Apr 2020 16:32:06 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BE672BE4D; Thu, 2 Apr 2020 16:32:06 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1585841526; bh=8+T0r0RU1uO0Njj2pV1PFLnyVQsH4tBOG4ApBbxo0Qo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=VXwKdLZmWJgmbFPn9bcW1vw0Vbptu479kAcsVqGJe4+kueVfo/u6ROv+rsJh8uNoA 5HvWg0RIUWnr99kdlmaN/rAI2QVXPuieukvD/7zI86hVt2wQ6OnhThnlJiJfkJ+3LL qeoAYr6Ig3GNe6ENxphD+rRn5U7mPFRnbU/6ILkY= To: Toerless Eckert Cc: "chirp@iab.org" , architecture-discuss@ietf.org References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Thu, 2 Apr 2020 16:32:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jQTaZZa5vDTJzMaJZMWX1zC3LZR5FpdRU" Archived-At: Subject: Re: [arch-d] [Chirp] on the nature of architecture discussion (was: Re: Fwd: IETF 107 Vancouver In-Person Meeting Cancelled) 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, 02 Apr 2020 15:32:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jQTaZZa5vDTJzMaJZMWX1zC3LZR5FpdRU Content-Type: multipart/mixed; boundary="KkGtpyhYwAs47wJcKNu9V7TSRApC5uo9b"; protected-headers="v1" From: Stephen Farrell To: Toerless Eckert Cc: "chirp@iab.org" , architecture-discuss@ietf.org Message-ID: Subject: Re: [Chirp] on the nature of architecture discussion (was: Re: Fwd: IETF 107 Vancouver In-Person Meeting Cancelled) References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> --KkGtpyhYwAs47wJcKNu9V7TSRApC5uo9b Content-Type: multipart/mixed; boundary="------------4E1A7BB16C30AA9A08B61812" Content-Language: en-US This is a multi-part message in MIME format. --------------4E1A7BB16C30AA9A08B61812 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 02/04/2020 16:27, Toerless Eckert wrote: > Why not ? I'd be really happy to organise a meeting for chirp. [1] If people want one, just mail me or that list. But, I asked on the list already, as I just said, and only 1 person was interested, so I'm very puzzled as to what it is you are complaining about. S. [1] https://www.iab.org/mailman/listinfo/chirp --------------4E1A7BB16C30AA9A08B61812 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------4E1A7BB16C30AA9A08B61812-- --KkGtpyhYwAs47wJcKNu9V7TSRApC5uo9b-- --jQTaZZa5vDTJzMaJZMWX1zC3LZR5FpdRU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl6GBXYACgkQWrL68XsX K+pGchAAkbjBj6Rj2zqiM2RV8Aorg8M5+Wl6Ppg4euqeVeCTKPmQs/jf4AAb2D3a enrrb54eC9FVkQ/vtuUyxzRRDe+wsxS2Vu/JFav4pxUmWSsevcd316S/kX9WmAs/ sOyt/yzYZMV/CAuFZE1+DWOvdOhzv7EcrPcVy0v6ZWMI44cuUeLhoLa2dhenZcVD OAfoWDiYjmLIk0vhJU4yuoWaxNP/3N6s4Sz5tlidM5Bnd0eSs7JpYa4arh+UkPTY DGZBGSbELfDweuYpNENzt/c5evRBhbqyqaOtTqVLD4gTKasTNZPR7YvVHyJiXGMp Sw3kKv8sdSBPg6dv1KkLdkObyK1tenh5WraSvzO4TfZ0HA+zvFXvpoU6eePM37MP jbrT7NqGkI8roihxQk8ZncnNqaCV6tbrwGSwCcu4IUYdlCxKjnN6/SJg69HbTSRu SPvcActVyES6vyR/MS5i2an0SO442hzEaxXYkdocBvLhcET8lrxV0sWSQcoL8T9c bm5B/34qRkl2yFmzhQPoxM6FAvGBplPJRWE5kq+NprO3bqaZGCNMGaIMuza3FXrI igphFmlDjKUzbGtmKSmsqz1yfvLZV84ZBw7lYzuCR1T/b6ckdCxN+KanjtJtHNJ4 gtmfDbJFPvgpirtT5hsVGjeijYS/j5Pp3NzLhlIrC3hB4Sx6qMk= =j51c -----END PGP SIGNATURE----- --jQTaZZa5vDTJzMaJZMWX1zC3LZR5FpdRU-- From nobody Thu Apr 2 08:37:13 2020 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 02DF53A15C6 for ; Thu, 2 Apr 2020 08:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 6vvZbW1SIJfB for ; Thu, 2 Apr 2020 08:37:05 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 46F2B3A15C0 for ; Thu, 2 Apr 2020 08:37:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 87B746601DF; Thu, 2 Apr 2020 18:37:03 +0300 (EEST) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Y-FFDs4jV5M; Thu, 2 Apr 2020 18:37:02 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 6187A66018B; Thu, 2 Apr 2020 18:37:02 +0300 (EEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> Date: Thu, 2 Apr 2020 18:37:02 +0300 Cc: Stephen Farrell , "chirp@iab.org" , architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [arch-d] on the nature of architecture discussion (was: Re: [Chirp] Fwd: IETF 107 Vancouver In-Person Meeting Cancelled) 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, 02 Apr 2020 15:37:07 -0000 Toerless, you ask good questions. But I=E2=80=99d say it is difficult to = discuss a large topic in the abstract. Not saying we shouldn=E2=80=99t = have arch-dispatch, but it isn=E2=80=99t immediately obvious to me that = such a meeting would work well. It is however easier to discuss more = specific issues, and for those there does exist many IAB-sponsored = meetings (such as ones Stephen has helped set up), IRTF RG meetings = looking at interesting Internet evolution topics, and meetings outside = IETF meeting week (such as workshops). And ultimately there are of = course many more private gatherings where some smaller set of people are = starting to discuss a new topic. Jari From nobody Thu Apr 2 09:15:08 2020 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 3F1FD3A1728 for ; Thu, 2 Apr 2020 09:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 wd4z5TfTzz9k for ; Thu, 2 Apr 2020 09:15:03 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E99643A1721 for ; Thu, 2 Apr 2020 09:15:02 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 9BCD3548015; Thu, 2 Apr 2020 18:14:57 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 8E5FC440040; Thu, 2 Apr 2020 18:14:57 +0200 (CEST) Date: Thu, 2 Apr 2020 18:14:57 +0200 From: Toerless Eckert To: Jari Arkko Cc: architecture-discuss@ietf.org, "chirp@iab.org" Message-ID: <20200402161457.GL28965@faui48f.informatik.uni-erlangen.de> References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] on the nature of architecture discussion (was: Re: [Chirp] Fwd: IETF 107 Vancouver In-Person Meeting Cancelled) 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, 02 Apr 2020 16:15:06 -0000 On Thu, Apr 02, 2020 at 06:37:02PM +0300, Jari Arkko wrote: > Toerless, you ask good questions. But I???d say it is difficult to discuss a large topic in the abstract. Not saying we shouldn???t have arch-dispatch, but it isn???t immediately obvious to me that such a meeting would work well. I am sure it will not work well initially because it would be new for us, but i am even more persuaded we should attempt to do it and give it time through iteration and learning of how to improve the process. For example, like in research conferences, we might need to invest more into upfront vetting/review of proposals - but not to limit the topics, but to improve the quality. And we can look at the continuum of useful outputs: On one end, there is a one-off draft/presentation, but it could still turn out to be viable long-term reference for further followup work. And compared to all those research conferences we would have the chance for the community to review and help improve the document through few iterations, even if it stops there. Such as many abandoned IETF drafts. IMHO still a lot better outcome than that of many journal published research conference papers. On the other end is the criticial mass of interested parties that drive a topic over to a community vetted/approved RFC. But we do not even have such a process for possible architecture RFCs and IMHO existing IETF WGs mostly start when the architecture is defined well enough already. > It is however easier to discuss more specific issues, and for those there does exist many IAB-sponsored meetings (such as ones Stephen has helped set up) The main problem to limit discussions to more specific topics is always the problem of timelyness and priorities between what the organizers think is of interest and what possible contributors think. Especially when there are commercial divergences if not conflicts. > IRTF RG meetings looking at interesting Internet evolution topics, and meetings outside IETF meeting week (such as workshops). Unfortunately, i have seen very strong rejection by the IRTF chair to consider topics he deems to be more architectural in nature than "research" in nature. Starting even with the problem of what composition model we want or the like to have for system level architecture or principles of how to evolve the forwarding plane. And i would have no argument about that distinction if we just had an architecture track as we have a reearch track to do the work. > And ultimately there are of course many more private gatherings where some smaller set of people are starting to discuss a new topic. Who are not even given equal access to collaboration tools in the IETF community (concern raised at plenary by me). because of the IMHO bogus argument of fear of "endorsement". Cheers Toerless > Jari > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Thu Apr 2 09:37:57 2020 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 60AEF3A040C for ; Thu, 2 Apr 2020 09:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 EOxXeBCjMMs1 for ; Thu, 2 Apr 2020 09:37:22 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BDAB3A03F1 for ; Thu, 2 Apr 2020 09:37:10 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 42BE0548049; Thu, 2 Apr 2020 18:37:05 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 3A23D440040; Thu, 2 Apr 2020 18:37:05 +0200 (CEST) Date: Thu, 2 Apr 2020 18:37:05 +0200 From: Toerless Eckert To: Stephen Farrell Cc: "chirp@iab.org" , architecture-discuss@ietf.org Message-ID: <20200402163705.GN28965@faui48f.informatik.uni-erlangen.de> References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] [Chirp] on the nature of architecture discussion (was: Re: Fwd: IETF 107 Vancouver In-Person Meeting Cancelled) 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, 02 Apr 2020 16:37:25 -0000 I am complaining about the absence of a recurring, IAB organized architecture-discuss/dispatch meeting slot at IETF meetings. If we had this, then you could indicate that 'chirp' contributions are a preferred topic to be presented/discussed in such a track. You do encourage contributions by giving them these incentices: recurring meeting with longer time horizon: ability to plan putting cycles into a contribution. Present in a larger context of an arch-discuss track == reach out to more opportunistic participants. Cheers Toerless On Thu, Apr 02, 2020 at 04:32:05PM +0100, Stephen Farrell wrote: > > Hiya, > > On 02/04/2020 16:27, Toerless Eckert wrote: > > Why not ? > > I'd be really happy to organise a meeting for chirp. [1] > If people want one, just mail me or that list. > > But, I asked on the list already, as I just said, and > only 1 person was interested, so I'm very puzzled as > to what it is you are complaining about. > > S. > > [1] https://www.iab.org/mailman/listinfo/chirp > > pub RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) > sub RSA 4096/36CB8BB6 2017-12-22 > -- --- tte@cs.fau.de From nobody Thu Apr 2 09:44:37 2020 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 E94633A07D3 for ; Thu, 2 Apr 2020 09:44:34 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 ogVnwWob_j_O for ; Thu, 2 Apr 2020 09:44:32 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 480373A07CF for ; Thu, 2 Apr 2020 09:44:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0407EBE64; Thu, 2 Apr 2020 17:44:28 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7ZmbxnkLq_r; Thu, 2 Apr 2020 17:44:26 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B9F57BE5D; Thu, 2 Apr 2020 17:44:25 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1585845865; bh=/+gJHwnHhpYX55o7lYnd7Xe7kw0TNJRD1xAzggym/EM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=xyU3iosHi/RHBbt8b6gDXev7iZQvehdLqEti9HqTZfWXwfToM/N8GqAh+d1Q6sv/H nX16ICHyxLawPO9s6U39d76w48jordZrIJJPBN1USwmBydLrfSMIHnrAb7J0MSxgK5 097vvJMQR+JX/6PaRm2eyF9DbCGLY6yfUZi7zmng= To: Toerless Eckert Cc: architecture-discuss@ietf.org References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> <20200402163705.GN28965@faui48f.informatik.uni-erlangen.de> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <36c258d4-3380-1875-73c4-da9ef6d180dd@cs.tcd.ie> Date: Thu, 2 Apr 2020 17:44:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200402163705.GN28965@faui48f.informatik.uni-erlangen.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FVjEQdMHCFQdFW2EA4NBrElntpykl3tTC" Archived-At: Subject: Re: [arch-d] [Chirp] on the nature of architecture discussion (was: Re: Fwd: IETF 107 Vancouver In-Person Meeting Cancelled) 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, 02 Apr 2020 16:44:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FVjEQdMHCFQdFW2EA4NBrElntpykl3tTC Content-Type: multipart/mixed; boundary="HNHoHH5h9HbVyPmqrmDGCNrONQCyfmxbq"; protected-headers="v1" From: Stephen Farrell To: Toerless Eckert Cc: architecture-discuss@ietf.org Message-ID: <36c258d4-3380-1875-73c4-da9ef6d180dd@cs.tcd.ie> Subject: Re: [Chirp] on the nature of architecture discussion (was: Re: Fwd: IETF 107 Vancouver In-Person Meeting Cancelled) References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> <20200402163705.GN28965@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200402163705.GN28965@faui48f.informatik.uni-erlangen.de> --HNHoHH5h9HbVyPmqrmDGCNrONQCyfmxbq Content-Type: multipart/mixed; boundary="------------F343FB49F1871244716CA223" Content-Language: en-US This is a multi-part message in MIME format. --------------F343FB49F1871244716CA223 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable (dropping the chirp list...) On 02/04/2020 17:37, Toerless Eckert wrote: >=20 > I am complaining about the absence of a recurring, IAB organized > architecture-discuss/dispatch meeting slot at IETF meetings. Ok, I think I now get what you're after. Not sure I'm convinced it'd be worthwhile, but if people wanted to try that, then saying so, and I guess suggesting topics to cover would be the things to do I guess. Then the IAB could think about that input and whether such sessions might be a good idea or not. S. >=20 > If we had this, then you could indicate that 'chirp' contributions are > a preferred topic to be presented/discussed in such a track. >=20 > You do encourage contributions by giving them these incentices: > recurring meeting with longer time horizon: ability to plan putting cyc= les > into a contribution. Present in a larger context of an arch-discuss > track =3D=3D reach out to more opportunistic participants. >=20 > Cheers > Toerless >=20 > On Thu, Apr 02, 2020 at 04:32:05PM +0100, Stephen Farrell wrote: >> >> Hiya, >> >> On 02/04/2020 16:27, Toerless Eckert wrote: >>> Why not ? >> >> I'd be really happy to organise a meeting for chirp. [1] >> If people want one, just mail me or that list. >> >> But, I asked on the list already, as I just said, and >> only 1 person was interested, so I'm very puzzled as >> to what it is you are complaining about. >> >> S. >> >> [1] https://www.iab.org/mailman/listinfo/chirp >> >> >=20 > pub RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) >> sub RSA 4096/36CB8BB6 2017-12-22 >> >=20 >=20 >=20 >=20 --------------F343FB49F1871244716CA223 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------F343FB49F1871244716CA223-- --HNHoHH5h9HbVyPmqrmDGCNrONQCyfmxbq-- --FVjEQdMHCFQdFW2EA4NBrElntpykl3tTC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl6GFmgACgkQWrL68XsX K+rVVA/+MG4006NyJMXSWdp0qCk04zFfCEijKV+TRgHw/gDP0mP5Sy8X2+sIUbey Xlq+rWOroJI5mZHWPTLAnIYu9epJem6O+TnqP3hxnouimWSA+CUG0oS08Q5f1eB5 fdN4rc5Gu3/AZfZ1pwlOxqRPAD1OfXm8Z2CI4KIn5BCRySZ2pU/cH3yLQDcmQF+t ndtaXdc6pPCWpF5xbQ0HM6Sz9QlxQKBGUeRaAgzwwruzXJjJ8/DyVkM5+zXqmMHd rNc3nXkg0XT9FKoa0PRYAynh6IU0WEvgcytjSgo9YV4RPjzCLSTnQkwf4jsa6ae5 bsP6P0Qrln7V1gGvvYxtusIb234YNv5GF6OEFFQ38MS3zZYLx+LTvsEVmMxumq6o a0jUXGwvdZ7494mAT3g0U9YZJxo3Zmr9UxNCcStY24gWZfZcsU34eaR9VTa1Aqzi 0OKtB0LNQl8QfONJwpXmbOUBtEwYRj7e8cwSRy0WM0jJ6pFdn9wTLhKB4Cvyx0Ba CivFYvIm28nWUWa4s/bpuU7/FMmUQgdJTeSRW7m5SAelNS1GXXOv8ULiXNpMTw0+ ojODESNGys9jlSXM7E/S1UF8fLUT3U042JpxWU9JlbwboFnf1UnZLhLSGrye8aKe mblVQ6b2x353sqjj2Kc5ObR9tdRXYeAOlronwojwowEStTicznA= =Z/3S -----END PGP SIGNATURE----- --FVjEQdMHCFQdFW2EA4NBrElntpykl3tTC-- From nobody Thu Apr 2 10:31:07 2020 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 C113C3A0BEE for ; Thu, 2 Apr 2020 10:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 jMcOyZMTgjBh for ; Thu, 2 Apr 2020 10:31:04 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E59FB3A0BF0 for ; Thu, 2 Apr 2020 10:31:03 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 93890548015; Thu, 2 Apr 2020 19:30:58 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 8B903440040; Thu, 2 Apr 2020 19:30:58 +0200 (CEST) Date: Thu, 2 Apr 2020 19:30:58 +0200 From: Toerless Eckert To: Stephen Farrell Cc: architecture-discuss@ietf.org Message-ID: <20200402173058.GP28965@faui48f.informatik.uni-erlangen.de> References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> <20200402163705.GN28965@faui48f.informatik.uni-erlangen.de> <36c258d4-3380-1875-73c4-da9ef6d180dd@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <36c258d4-3380-1875-73c4-da9ef6d180dd@cs.tcd.ie> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] [Chirp] on the nature of architecture discussion (was: Re: Fwd: IETF 107 Vancouver In-Person Meeting Cancelled) 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, 02 Apr 2020 17:31:06 -0000 On Thu, Apr 02, 2020 at 05:44:24PM +0100, Stephen Farrell wrote: > > I am complaining about the absence of a recurring, IAB organized > > architecture-discuss/dispatch meeting slot at IETF meetings. > > Ok, I think I now get what you're after. Not sure I'm > convinced it'd be worthwhile, but if people wanted to > try that, then saying so, and I guess suggesting topics > to cover would be the things to do I guess. Then the > IAB could think about that input and whether such > sessions might be a good idea or not. Thanks. As i said, a one-off will not succeed, but there should be the will to think/work on improving this through experience. Asking for submissions to be sent out earlier (even 1 month) to allow for pre-meeting vetting for example is a good step. Assigning designated reviewers might even be better. Lets experiment. We all know how more difficult these broader topic discussions are, but we have done very little experimentation in the past trying to improve. Also, wrt. IAB workshops and the like: - The co-location of IRTF work into IETF weeks is i think very successful for that community. I wish the IAB would consider this option more. - With corona/virtual meetings we should IMHO simply have a joint, integrated IRTF/IAB/IETF activities calender over e.g.: a period of one "virtual" meeting month and use the same/inified tooling/publishing mechanisms. That gives contributors hopefully the same attendance cross-polination opportunity as the physcial IETF week. Cheers Toerless > S. > > > > > If we had this, then you could indicate that 'chirp' contributions are > > a preferred topic to be presented/discussed in such a track. > > > > You do encourage contributions by giving them these incentices: > > recurring meeting with longer time horizon: ability to plan putting cycles > > into a contribution. Present in a larger context of an arch-discuss > > track == reach out to more opportunistic participants. > > > > Cheers > > Toerless > > > > On Thu, Apr 02, 2020 at 04:32:05PM +0100, Stephen Farrell wrote: > >> > >> Hiya, > >> > >> On 02/04/2020 16:27, Toerless Eckert wrote: > >>> Why not ? > >> > >> I'd be really happy to organise a meeting for chirp. [1] > >> If people want one, just mail me or that list. > >> > >> But, I asked on the list already, as I just said, and > >> only 1 person was interested, so I'm very puzzled as > >> to what it is you are complaining about. > >> > >> S. > >> > >> [1] https://www.iab.org/mailman/listinfo/chirp > >> > >> > > > > pub RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) > >> sub RSA 4096/36CB8BB6 2017-12-22 > >> > > > > > > > > pub RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) > sub RSA 4096/36CB8BB6 2017-12-22 > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Thu Apr 2 12:14:53 2020 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 8877A3A0CB2 for ; Thu, 2 Apr 2020 12:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=nomountain-net.20150623.gappssmtp.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 oRSltPFFlM1Y for ; Thu, 2 Apr 2020 12:14:50 -0700 (PDT) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 EFCF13A0CB1 for ; Thu, 2 Apr 2020 12:14:49 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id l14so2301148pgb.1 for ; Thu, 02 Apr 2020 12:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to; bh=bNYy26RR82lUeTh5EIORqBSkEe9zEY/gitL6aY2IQrI=; b=jMwM3dj5tagtNVBoo+hrHivVkaFCTr77N8l6ZhgtxryKdGCJ/ukaq/mFzahpX9ioPf hZb4wOP/otbrOuAVGFw46DCa5D5/3SHIacCmMHKuhUUhBdCk2y2vJtF2fyA1g7saAbho jto9PAp4Nc4SfY0FJ1IhYsVmEN5eTPTNfxjZw2Aoex2pPNRymsGWkoEVf+YAC8ikqseW fdDoX9i90StePuKkeGAIKEbHE2VdJQLJmbxwzlR0xvdIJS22dZkeany04BYR3PRYggyv Ip6oZoNljkHU1GZsM6AcOcUfBnu6gpz2WSTE3lNsrZwlFLGm8DJdThI77yP35pjeFLWy a6yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to; bh=bNYy26RR82lUeTh5EIORqBSkEe9zEY/gitL6aY2IQrI=; b=aLv5xHWMCKxQJ+FlLKuha3RxMTm33WxM2rXi9mCXAVe482LLivGLjJMim70UJbvipj /2YXEM0Oj5tzoXpWRPrL8cq0ROWwdPIj99vRP14EL++Cfhxe9hzxHjWwhtZHZfcPqbYf pXFRsOrIxgQF+GzaP6K29h0A69glD8jJcK88DOG66MShcrpAy7A1Ir4MLX7838uNEQSK hNncnw7j+67CX1XQs1eAxiHuJXLm89ZN4X+IVwzAjo+utUmMdXnZCCX1iXR6nfNyztQ0 WOHd0iaHeacCzkJdCV8nZ0N4OmGCYnMw9WY8JZlN0I4V8aaKRG+SJX7AfN4Cjwhf+NTT WHDw== X-Gm-Message-State: AGi0PuYJhmhAVesM6GwbJQsBB9T3rXPPdzDeNj7JnFdUV/P91igv4OCb t1ts0MiT9zZ/gNaww9mdGFN/prxJ7A== X-Google-Smtp-Source: APiQypKcwpsoc4z3D6S6+kOrzVduLuenla4aXKMi3v92QM3lvEKYgPoNzSOGnhKFbjw7a8vjW+V18w== X-Received: by 2002:aa7:87c1:: with SMTP id i1mr4444748pfo.44.1585854888577; Thu, 02 Apr 2020 12:14:48 -0700 (PDT) Received: from aspen.local ([63.140.71.170]) by smtp.gmail.com with ESMTPSA id j126sm4215365pfg.60.2020.04.02.12.14.47 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Apr 2020 12:14:47 -0700 (PDT) To: architecture-discuss@ietf.org References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> From: Melinda Shore Autocrypt: addr=melinda.shore@nomountain.net; prefer-encrypt=mutual; keydata= mQINBFppZ0gBEADFwxAi5szDOsM/6+CH4pbYTX7D+2gjLY4xEE7ydQcAF1WVLvcWXrpZM0GO /eA4N1PJ+OT5o8o9zVr7izMJkiLwcnQmxHdlYgZ9E+Cm8hDtMyEPBQwsYTkE5kpbGCmBAZ+W rHNHjvDg366uZQHzJejenB1/V4+rxMZs1Ak34Az2MVOz9Doecaiadpw3NpH3+1VXY/qilqnM lznINSANqD0ktxB/CVKjxl3/K5JnVnLp0h2kiUqt19hQPX2JmLcgaHzu+Ceb34/HZWhs0CiF c4auhQ3A9PcccOprQh6IGW1xo6RP3OEbeRFqeovgBWS+DIWzMIM0a3G2LDid0889QYwEv0zZ RPDCcF3g15mlkeUUmwKQ6eAagPyTqLtTiOKULqy9bQahyX2eqlySrF+HqlwGeNoG+A4l1Z2Y S7NCBLPIzUk2RuSKMBaKw86ORzvg2Advrw4bdv7kbDkArGzywky61SEB/q+GqR466mekXx2F O+m8RuoSnWrBsKvD/bhELHcneorIBleGz+VL7i5adU0rIydG3jPTfUeXoCZIeNx1LannxnAR ihKdh5+FE26WiiK6VmZWkvFjaPFwWGjvAsi82Pd9QgHhnG/XzINpXw/3HF4wtBTU5nIExMzC +FbJxCPq1kXpqSxJqg7hgUFvD5jUD9lpN5Br/S2dUgJj95bbPQARAQABtCxNZWxpbmRhIFNo b3JlIDxtZWxpbmRhLnNob3JlQG5vbW91bnRhaW4ubmV0PokCVAQTAQoAPgIbAwUJCWdTAAUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBE9oLZMqF5b4IPI0wN+4kXKadtuPBQJaaXRaAAoJ EN+4kXKadtuPVioP/3nVzx33yjiEtqLKTEHwofnLT15CV5wAcGa0DTbqgiomVKzSRkkhbF3Z KIHYrnjVpTcYJuW+PmFSIjNizNVr+vvjNP6ptRqx5orWmK4EBe/B9mrpmIshxUwkYr46uwN4 h06xJS3KCzhfhSsnesH5vlGBkUod0+nQhbSLyLRpxmaKaeAl4dxFSBLU0vUJMLH8PXTZVNof 5Yo+ThqCzu1pwOkBQ8gST2J6zdy4PjU9ENQ9RLAamlAG/6rGHEKLFcnUpEg7Tcu1hSzAsqR8 kjX2Prpu4A9DyLCjTOvfOPQa8WjZy18ZdYOxuPxdrTazeCRVJIvYRflhBCZb744jhMyfAiSW eckwRBVSCnBuvWBJl9Ua1wp8SOUXXhgGI8WGvSkvul6kKSkHQKDggd4cojAhxWLfvmjxn5pz 0BNbvrEBGqgWwO1ZMuJpmv3P8YK5Aytsl85NZoMMUJIDxEQhBUgYz5QTQANBKPi8RsfOntho rhzXLqnPPQcE4Xf9O9XIyy077F0JoyiPx74Zsl1dTxmT73pezpfhKUQR7/QlmJ/FAADpb6SO V0tlgBtR6FAZToBYPDiss57AcKM1zzyJ7sHIZkxQelykYSet6hp2WGcwMXQveWqFMQ4fiGQx XNEPO+KZKNj+0sfINzSLP88O5TniM/l/JrjZZNT/lVAQDTdkCBGyuQINBFppZ0gBEACgZuM1 8ghzSuhuv+n0kWyWCeEWrx9Ey03EgFj5alBt55+OLv3dOsdyBHJxjtd0cZS1XaKZlgr1YZ0O pQNv/Wyy8uSW2BZ6hyG1SKN9/1MmfJLNnjjxaBQP4yaMwDdS3wX7hoWY19IpVPZHYDR35FAg SnG/s6we+IOITM1TJoOJs4+ygeK5dC7LfRoj+lkEHYrTcglYVuwsyK2FNz/sF8kJW1fEZHM6 6phSbhCvwbECWbb4eDGXbKZY92W1RTQ5U5td8DMLXyYipQphrcoeRXpb18DbOnE0WwIQV0yB gc/rTiUt/wVjasd1RrsCPBQC/uJ+ZHknvr2MoxIWBBsRtKYHG66aOL+nDV8X1miuF6j4cztv gmdqrwPHpAKVxhfwd/G4suNBunYw4/kAV9b2+eidX5em3NtPPNl/qNjsmEHQGn/5JKRHRvQs 0yuigXDhN2N0keoHrbGCE8kyA/d83L7E9d95hsf3JxpRzmeaTze+NpcIaX5uXdKOaCBjLtx1 tOrDA4XX7Y3nY+waKZYa3RvC7yulFJiKfYWDSriWeQXcXj06p8H6vF6sy9LeX9xRRjTI7qDH FxwuMQIKGqgufXtxu0pxxcMqXTEUPZnxUWUvuFjjYvEmtO92+Ot/NuotV8JvRPwg2OnYjMJo dU1X7hzEs8djtgZG+t3FEGK3i1EJUQARAQABiQI8BBgBCgAmFiEET2gtkyoXlvgg8jTA37iR cpp2248FAlppZ0gCGwwFCQlnUwAACgkQ37iRcpp2248krg/9H896KtAQCAV0RcV3QqZ75iY5 pCxpRyxAaR0PjE5jiYV5gUHPCKtr9UPZt4Bi+bzNLQ2KJK6Rx4XNf5lQWopEo1IxtOiFPjkr QIpNkYmFWyOGpKpSIDhgsJpswZqxPDLpo+59GNlSUG6v3sMAnx+Gvtvqczkvg6UPDN/JYK75 BIGoCGZMyor1B0EmRYj98LdwjT95dQZXjZvWBDeIx+NxUZKoA7AlR/xgsN3PHGq4SApMLL0R /qbiLIzUPnTPt5sBs0peflVvMrtgIMiZ9FdYPE+VWy5+X2AmeFg6Zl5W76HQUP6eYZQV5abZ +iiW9lY1TmqsqpTIDu/ZMy7pLknxV5E1vQy+wsihluDYydaQ4HWoNaY7QFb+x7TsvjJRi+cH 7By4jxohTWUuaukuMmT0eEaesWJSraAmxsffqJwDpsi0chZskuXjEm9gX6rY7MhzOZl7Vz9F +6MYTtTmT1mpkLAMWf1/JuKUCfnSAHRlDxUOAG6QSJoHWAGqYy3XiF9bN63yQ6xllloSbbMv P9VW0e/iFKMKEIvfIvAg0IrlPcfKAGuuT1axwIU7da/N7LOcXyDDSEUuSzvXL/BkWyjxuLzd LY6eTvC6ZT/fA5iS/PAUj0WbrWNrHQtQ5OY2+al2v6JdLu/w6IZJCBpTosOAOzzmre+31fk1 HKwqd9xRxC8= Message-ID: <7de683b6-172b-7e7b-e043-d241804eaa42@nomountain.net> Date: Thu, 2 Apr 2020 11:14:46 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IK1KshRcylgXZbyUiKgN2DWiYKqJSp2bu" Archived-At: Subject: Re: [arch-d] on the nature of architecture discussion (was: Re: [Chirp] Fwd: IETF 107 Vancouver In-Person Meeting Cancelled) 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, 02 Apr 2020 19:14:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IK1KshRcylgXZbyUiKgN2DWiYKqJSp2bu Content-Type: multipart/mixed; boundary="5Un5fRZoTgyu1tDMQ36q1wo31lhE6fhyI" --5Un5fRZoTgyu1tDMQ36q1wo31lhE6fhyI Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 4/2/20 7:27 AM, Toerless Eckert wrote: > We have this mode of operations in hundreds of conferences > including IRTF, we have it in IETF WGs for standards, we do > not have this for architectural discussions for the Internet.=20 FWIW, many years ago we had these discussions in the technical plenaries. They were, as a rule, unproductive, which may be why they have fallen by the wayside. I'm curious to know what you think would change if there were structured general architectural discussions. Melinda --=20 Melinda Shore melinda.shore@nomountain.net Software longa, hardware brevis --5Un5fRZoTgyu1tDMQ36q1wo31lhE6fhyI-- --IK1KshRcylgXZbyUiKgN2DWiYKqJSp2bu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEET2gtkyoXlvgg8jTA37iRcpp2248FAl6GOaYACgkQ37iRcpp2 248LbxAAopbvr5I8Mm/1AUqt4IyAQX8bRNctj1GqvHVS6Y/CAok0d1DKsRN6VaAy brfdWWBCJWRgAI/pU9cqExG9nXAsOEery/uEgzUxZ56obT0A5Iqj0wlwSGhoiyzM GmVRWs+Qd2XF7ENFuA7CSIlXvUne3fVhHDShdK20+NOd2lqWdhl1HlTSEnwWcLgq CmEUgxc+U6zt8ronU9wZ+aewNu9eMYNpIoLED4qZ1HJnEh2SuBC7EdnfRdTa8AKo jRRB9JX8UWhOWTjuT7WV+GEoco+F6Z17QRy0/G99NqVG1Hzch6ryLFnproPxLq6V 0gDxV4e61B4vouVDEd06ZqCZMPiMhnyqGDIe2m5r9vHsmAdTg20uM6a9FmOmWwvt W+0tbaP6YQVjkcVxBhGHmclETb3lkhRfTC8RkWjUqVab68xjOukxz9Kd48V+Wl/m COOpwigR8nsVBxjpq92Vx+/UqGlPfNkNxINpt9FS0bzVaSbdqT73sdgnfO6T7KP8 0kTFrUPoxH5YJYSX//2FCAXH+zs3B2l9LAqr3mD2EZ2aHxBgcjLKhal+5kltUfhd /IPYCzOtrwpQEKVJ3k0646CYbYPlh37b05wyfYgNZ950C4R45d9+5sy5n7tSL/Bb 8L/wWvAlS0Zlmy8zL09ZuYhYDKN/N8C9zmblBePsoBTQe/+L/hs= =+b4p -----END PGP SIGNATURE----- --IK1KshRcylgXZbyUiKgN2DWiYKqJSp2bu-- From nobody Thu Apr 2 12:34:40 2020 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 2986C3A102C for ; Thu, 2 Apr 2020 12:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 tZYjPhXKReeq for ; Thu, 2 Apr 2020 12:34:36 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 479C93A1028 for ; Thu, 2 Apr 2020 12:34:35 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5DCC4548015; Thu, 2 Apr 2020 21:34:30 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 56FAF440040; Thu, 2 Apr 2020 21:34:30 +0200 (CEST) Date: Thu, 2 Apr 2020 21:34:30 +0200 From: Toerless Eckert To: Melinda Shore Cc: architecture-discuss@ietf.org Message-ID: <20200402193430.GQ28965@faui48f.informatik.uni-erlangen.de> References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> <7de683b6-172b-7e7b-e043-d241804eaa42@nomountain.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7de683b6-172b-7e7b-e043-d241804eaa42@nomountain.net> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] on the nature of architecture discussion (was: Re: [Chirp] Fwd: IETF 107 Vancouver In-Person Meeting Cancelled) 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, 02 Apr 2020 19:34:38 -0000 On Thu, Apr 02, 2020 at 11:14:46AM -0800, Melinda Shore wrote: > On 4/2/20 7:27 AM, Toerless Eckert wrote: > > We have this mode of operations in hundreds of conferences > > including IRTF, we have it in IETF WGs for standards, we do > > not have this for architectural discussions for the Internet. > > FWIW, many years ago we had these discussions in the technical > plenaries. They were, as a rule, unproductive, which may be why > they have fallen by the wayside. I vaguely remember there was something, but i don't remember the format. > I'm curious to know what you think would change if there were > structured general architectural discussions. Was it only presentations or also associated drafts ? Was the material asked to be make available sufficiently long ago to allow quality updates be prior review ? Was there an organized attempt to get upfront or afterwards reviews ? Was there an associated email discussion forum ? Was there the opportunity to follow up across multiple such plenaries to refine the content ? Was there somebody responsible trying to help with a dispatch style mechanism to help get material further reviewed by other IETF/IRTF groups that might hav emore interest ? Was there any attempt to force authors to fold feedback into updated documents so that final versions summarized not only author opinion but also community feedback ? Just off the top of my head. There certainly a lot more aspects. I think we know a lot of the process steps that can help to make discussions/presentations about these difficult topics more successful, i don't think we experiment enough with them. Especially not on what i think is the architecture track. We only have well working tracks for research and standardization. Not architecture. But architecture specifically could learn and experiment with a lot of the mechanisms in the range from research conferences over to IETF WGs. Cheers Toerless > Melinda > > -- > Melinda Shore > melinda.shore@nomountain.net > > Software longa, hardware brevis > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Thu Apr 2 12:50:25 2020 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 5E0083A118C for ; Thu, 2 Apr 2020 12:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpEFxy6AX4Ic for ; Thu, 2 Apr 2020 12:50:22 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 B2DE73A1179 for ; Thu, 2 Apr 2020 12:50:22 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id g6so376572pgs.9 for ; Thu, 02 Apr 2020 12:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Cp3eTFatkl3TW2TSlCBfEXLTrY36c6E6Wm6ofgLkRGE=; b=JFu4JmTSiooyLrtYyBPpZ6L6Xjn05HEx6g8/kRPQYLYBSbjqDaQ9hpWrWC/CfgnLXP OpgdHM70WqFCvMFe42XnC0CEDqKivhnDx+8xIU1k7VmhiSK+4K9XsC4uQrwXf1XwTi3F FMQUTrAD1kdEz4qqGMX7/7dBWu5e8N34FO7a7VM0MQvBRKy1iU2FULd07tDls+diDcTS 3Mj/3oPcWdxlPYh0nxCq6WlEYBYrwUyQajMFUXAylpMusWALiAOBKgwCReqFCZ+aiZRQ qgQFbExHMzGuhGda8mD2WEIqDkJmJPUrlA7vbTmOOUwWO2b2AEVq3wDLyYnjt4WHPC07 h0sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Cp3eTFatkl3TW2TSlCBfEXLTrY36c6E6Wm6ofgLkRGE=; b=E0ka5lh/WbmFgU/FOpNgdnYzotJ2e2xNZuxkZP4Gf0rP2bE45zYbctGn9/xG5iJUmY Axu1dDd5qNxY2lZVFB/ENgTHiTSCch0g7Nq6BeOsJb1OkJ7dZngPxAa+YNv1K/8caJ2C owbyTgGNLvmz2nACUJjgAkGyrpCA54fIoGWY0wZ9AH5iem2qkF++wdrr6aLMfsMZ2iYQ tSeKCTCM3cSwM98JYfUcyGLbCg5trq6joBb5O2TX+f2Mujl7VOywWLcZRFbIMsh6facV uAd60Nhw68f8WrkLbg0LPQF0JsVZP4nqXuriQLMy2RKGu9hNtgnaDt65kDhCtdlqdv23 2/Fg== X-Gm-Message-State: AGi0Puaayr54Zi0MIVKAO2DYKTO0JyO7vnffamL7rUJWG70Os/2GKzZ5 mW7kBs/yfwUWHNDjngB6HFQxFNTw X-Google-Smtp-Source: APiQypIKv6oKnnUsyDW7dH8QMuAizMjG6MFTun+j7X/XHwC86EQAVdNWo4Ss2IfNv0/C+Kqoj2pyig== X-Received: by 2002:a62:160b:: with SMTP id 11mr4955363pfw.189.1585857021766; Thu, 02 Apr 2020 12:50:21 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id s12sm3930647pgi.38.2020.04.02.12.50.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2020 12:50:21 -0700 (PDT) To: Stephen Farrell , Toerless Eckert Cc: architecture-discuss@ietf.org References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> <20200402163705.GN28965@faui48f.informatik.uni-erlangen.de> <36c258d4-3380-1875-73c4-da9ef6d180dd@cs.tcd.ie> From: Brian E Carpenter Organization: University of Auckland Message-ID: <28d9100f-3b3f-2a20-6815-ded301b82c8d@gmail.com> Date: Fri, 3 Apr 2020 08:50:17 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <36c258d4-3380-1875-73c4-da9ef6d180dd@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] [Chirp] on the nature of architecture discussion 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, 02 Apr 2020 19:50:25 -0000 On 03-Apr-20 05:44, Stephen Farrell wrote: > > (dropping the chirp list...) > > On 02/04/2020 17:37, Toerless Eckert wrote: >> >> I am complaining about the absence of a recurring, IAB organized >> architecture-discuss/dispatch meeting slot at IETF meetings. I don't think you should place any reliance on "meetings" in the traditional sense for the coming few years. Whether the sort of thing you want can happen in on-line meetings is less clear to me, since on-line meetings require floor-control, which is not what you want in any sort of wide-ranging blue-sky discussion. On 03-Apr-20 08:14, Melinda Shore wrote: > FWIW, many years ago we had these discussions in the technical > plenaries. They were, as a rule, unproductive, which may be why > they have fallen by the wayside. > > I'm curious to know what you think would change if there were > structured general architectural discussions. I think that the most important architectural documents have generally originated from inspired individuals, not from structured discussions. Examples (intentionally ancient): https://tools.ietf.org/html/rfc871 https://tools.ietf.org/html/rfc875 Brian From nobody Thu Apr 2 12:58:45 2020 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 D1A7E3A126A for ; Thu, 2 Apr 2020 12:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=nomountain-net.20150623.gappssmtp.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 yg6IdxfevHax for ; Thu, 2 Apr 2020 12:58:38 -0700 (PDT) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 4BF133A125F for ; Thu, 2 Apr 2020 12:58:38 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id c12so1757407plz.2 for ; Thu, 02 Apr 2020 12:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to; bh=ToExObqe2odWtASJOQc6oOMtjQdo4jCQO/ld0nsj4/o=; b=tk63K/oR4grZTGU25dzmNuvZulPiINCGtMzYygrlcQOTMuqsWZHKm0FxMwYPHJ76Ur MNCpoQM8ZeFQRhal7n/rY9+7i/su61fYLKZYr56xu0FTlCJsHh6qJSl+1aLNuXp1DTg6 KhLQALsBuvHrBgtyeZq+/+WRcyWam/5vni/cpIwTVyx1svnafTD+nZano0M4CLg8CqML Sef5ahzQBej2x6Zrv3T9UN9QrD+zw0T35DEqICu2DrzYjaGm75ydDCgiTNujgG7ZRuAN TfOhShX4kjwiqvzk9tmG2aUyKqgVTIlPlanO6+sYdKS5fTfiM1uELokezOpi20WRM76T ADVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=ToExObqe2odWtASJOQc6oOMtjQdo4jCQO/ld0nsj4/o=; b=f0tN7YZF4qDBvsfJ8SFwFDKJ028THT9jvlv4YiiqTcKlDaww9kFKJ7g6w6V9D68W/C ulYzZX02OEaAaJ/ru6gMPthzRG3XblPDOjjJs54ED9seBOPkg+Lqu4zOX2EnUaRTXsn0 Lh36RSBiCcHvSbWYa1aPQSvisqOkdPUpu7DMK3Uejd6vhQkSSImsTrGbPtf0x1UvxUBH Esa8n4dRC4uGEAw8ihlb9coq51XaOkPGUPRYiOQbcOJEr1SBvfNJVtTHdP0LSxrqBvRQ ndCI3dWbz+6QLe4DFpzoCntCjfYlbVm/fCsMIzkGplYPt8gh9dHRyFtRsjOpskRgxno8 GZNQ== X-Gm-Message-State: AGi0PuawZemrRaIw7MnJkUZX1wc1D6H5z9N+kHKzG6ESjrGihqyI5l10 ZQyeurieWKoeNKCp7rBno8k+slJRkg== X-Google-Smtp-Source: APiQypIePaKXNb5gYfKR+k0b3zS3SeLSZ6xFsHuqnmFRgNtlTFMkiFlqCQ6Hb47GkrPq50cVEQ2DrQ== X-Received: by 2002:a17:902:e987:: with SMTP id f7mr3752889plb.122.1585857517422; Thu, 02 Apr 2020 12:58:37 -0700 (PDT) Received: from aspen.local ([63.140.71.170]) by smtp.gmail.com with ESMTPSA id bt19sm4426910pjb.3.2020.04.02.12.58.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Apr 2020 12:58:36 -0700 (PDT) To: Toerless Eckert Cc: architecture-discuss@ietf.org References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> <7de683b6-172b-7e7b-e043-d241804eaa42@nomountain.net> <20200402193430.GQ28965@faui48f.informatik.uni-erlangen.de> From: Melinda Shore Autocrypt: addr=melinda.shore@nomountain.net; prefer-encrypt=mutual; keydata= mQINBFppZ0gBEADFwxAi5szDOsM/6+CH4pbYTX7D+2gjLY4xEE7ydQcAF1WVLvcWXrpZM0GO /eA4N1PJ+OT5o8o9zVr7izMJkiLwcnQmxHdlYgZ9E+Cm8hDtMyEPBQwsYTkE5kpbGCmBAZ+W rHNHjvDg366uZQHzJejenB1/V4+rxMZs1Ak34Az2MVOz9Doecaiadpw3NpH3+1VXY/qilqnM lznINSANqD0ktxB/CVKjxl3/K5JnVnLp0h2kiUqt19hQPX2JmLcgaHzu+Ceb34/HZWhs0CiF c4auhQ3A9PcccOprQh6IGW1xo6RP3OEbeRFqeovgBWS+DIWzMIM0a3G2LDid0889QYwEv0zZ RPDCcF3g15mlkeUUmwKQ6eAagPyTqLtTiOKULqy9bQahyX2eqlySrF+HqlwGeNoG+A4l1Z2Y S7NCBLPIzUk2RuSKMBaKw86ORzvg2Advrw4bdv7kbDkArGzywky61SEB/q+GqR466mekXx2F O+m8RuoSnWrBsKvD/bhELHcneorIBleGz+VL7i5adU0rIydG3jPTfUeXoCZIeNx1LannxnAR ihKdh5+FE26WiiK6VmZWkvFjaPFwWGjvAsi82Pd9QgHhnG/XzINpXw/3HF4wtBTU5nIExMzC +FbJxCPq1kXpqSxJqg7hgUFvD5jUD9lpN5Br/S2dUgJj95bbPQARAQABtCxNZWxpbmRhIFNo b3JlIDxtZWxpbmRhLnNob3JlQG5vbW91bnRhaW4ubmV0PokCVAQTAQoAPgIbAwUJCWdTAAUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBE9oLZMqF5b4IPI0wN+4kXKadtuPBQJaaXRaAAoJ EN+4kXKadtuPVioP/3nVzx33yjiEtqLKTEHwofnLT15CV5wAcGa0DTbqgiomVKzSRkkhbF3Z KIHYrnjVpTcYJuW+PmFSIjNizNVr+vvjNP6ptRqx5orWmK4EBe/B9mrpmIshxUwkYr46uwN4 h06xJS3KCzhfhSsnesH5vlGBkUod0+nQhbSLyLRpxmaKaeAl4dxFSBLU0vUJMLH8PXTZVNof 5Yo+ThqCzu1pwOkBQ8gST2J6zdy4PjU9ENQ9RLAamlAG/6rGHEKLFcnUpEg7Tcu1hSzAsqR8 kjX2Prpu4A9DyLCjTOvfOPQa8WjZy18ZdYOxuPxdrTazeCRVJIvYRflhBCZb744jhMyfAiSW eckwRBVSCnBuvWBJl9Ua1wp8SOUXXhgGI8WGvSkvul6kKSkHQKDggd4cojAhxWLfvmjxn5pz 0BNbvrEBGqgWwO1ZMuJpmv3P8YK5Aytsl85NZoMMUJIDxEQhBUgYz5QTQANBKPi8RsfOntho rhzXLqnPPQcE4Xf9O9XIyy077F0JoyiPx74Zsl1dTxmT73pezpfhKUQR7/QlmJ/FAADpb6SO V0tlgBtR6FAZToBYPDiss57AcKM1zzyJ7sHIZkxQelykYSet6hp2WGcwMXQveWqFMQ4fiGQx XNEPO+KZKNj+0sfINzSLP88O5TniM/l/JrjZZNT/lVAQDTdkCBGyuQINBFppZ0gBEACgZuM1 8ghzSuhuv+n0kWyWCeEWrx9Ey03EgFj5alBt55+OLv3dOsdyBHJxjtd0cZS1XaKZlgr1YZ0O pQNv/Wyy8uSW2BZ6hyG1SKN9/1MmfJLNnjjxaBQP4yaMwDdS3wX7hoWY19IpVPZHYDR35FAg SnG/s6we+IOITM1TJoOJs4+ygeK5dC7LfRoj+lkEHYrTcglYVuwsyK2FNz/sF8kJW1fEZHM6 6phSbhCvwbECWbb4eDGXbKZY92W1RTQ5U5td8DMLXyYipQphrcoeRXpb18DbOnE0WwIQV0yB gc/rTiUt/wVjasd1RrsCPBQC/uJ+ZHknvr2MoxIWBBsRtKYHG66aOL+nDV8X1miuF6j4cztv gmdqrwPHpAKVxhfwd/G4suNBunYw4/kAV9b2+eidX5em3NtPPNl/qNjsmEHQGn/5JKRHRvQs 0yuigXDhN2N0keoHrbGCE8kyA/d83L7E9d95hsf3JxpRzmeaTze+NpcIaX5uXdKOaCBjLtx1 tOrDA4XX7Y3nY+waKZYa3RvC7yulFJiKfYWDSriWeQXcXj06p8H6vF6sy9LeX9xRRjTI7qDH FxwuMQIKGqgufXtxu0pxxcMqXTEUPZnxUWUvuFjjYvEmtO92+Ot/NuotV8JvRPwg2OnYjMJo dU1X7hzEs8djtgZG+t3FEGK3i1EJUQARAQABiQI8BBgBCgAmFiEET2gtkyoXlvgg8jTA37iR cpp2248FAlppZ0gCGwwFCQlnUwAACgkQ37iRcpp2248krg/9H896KtAQCAV0RcV3QqZ75iY5 pCxpRyxAaR0PjE5jiYV5gUHPCKtr9UPZt4Bi+bzNLQ2KJK6Rx4XNf5lQWopEo1IxtOiFPjkr QIpNkYmFWyOGpKpSIDhgsJpswZqxPDLpo+59GNlSUG6v3sMAnx+Gvtvqczkvg6UPDN/JYK75 BIGoCGZMyor1B0EmRYj98LdwjT95dQZXjZvWBDeIx+NxUZKoA7AlR/xgsN3PHGq4SApMLL0R /qbiLIzUPnTPt5sBs0peflVvMrtgIMiZ9FdYPE+VWy5+X2AmeFg6Zl5W76HQUP6eYZQV5abZ +iiW9lY1TmqsqpTIDu/ZMy7pLknxV5E1vQy+wsihluDYydaQ4HWoNaY7QFb+x7TsvjJRi+cH 7By4jxohTWUuaukuMmT0eEaesWJSraAmxsffqJwDpsi0chZskuXjEm9gX6rY7MhzOZl7Vz9F +6MYTtTmT1mpkLAMWf1/JuKUCfnSAHRlDxUOAG6QSJoHWAGqYy3XiF9bN63yQ6xllloSbbMv P9VW0e/iFKMKEIvfIvAg0IrlPcfKAGuuT1axwIU7da/N7LOcXyDDSEUuSzvXL/BkWyjxuLzd LY6eTvC6ZT/fA5iS/PAUj0WbrWNrHQtQ5OY2+al2v6JdLu/w6IZJCBpTosOAOzzmre+31fk1 HKwqd9xRxC8= Message-ID: <17c21324-4238-9e56-48f2-e6df51967ca2@nomountain.net> Date: Thu, 2 Apr 2020 11:58:34 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200402193430.GQ28965@faui48f.informatik.uni-erlangen.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="44wyMKZMyILCPnVByQ0TKq8XR2fXqoR59" Archived-At: Subject: Re: [arch-d] on the nature of architecture discussion (was: Re: [Chirp] Fwd: IETF 107 Vancouver In-Person Meeting Cancelled) 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, 02 Apr 2020 19:58:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --44wyMKZMyILCPnVByQ0TKq8XR2fXqoR59 Content-Type: multipart/mixed; boundary="BosGhIWfWryOTXkmN2E5F3Wj8c4cfXMdL" --BosGhIWfWryOTXkmN2E5F3Wj8c4cfXMdL Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 4/2/20 11:34 AM, Toerless Eckert wrote: > Was it only presentations or also associated drafts ? Was the > material asked to be make available sufficiently long ago to > allow quality updates be prior review ?=20 Neither, really. It largely consisted of heated discussions at the mike lines. While there were presentations, for the most part they were not architectural in nature (with a few notable exceptions). My sense, from several decades of involvement in the IETF in various capacities, is that 1) it would take years to get agreement on a diagram of the current internet architecture and what you'd end up would be aspirational rather than descriptive; 2) architectural discussions in the past have had minimal impact on actual protocol design; and 3) complexity always wins in the end (the history and output of the NSIS working group might be a particularly illustrative example of the latter). Right now, there is nothing stopping anybody from publishing drafts and contributing to (or, indeed, leading) architectural discussions in IETF working groups. I'm not sure what inferences we should make from the fact that for the most part that's not happening now. I'm skeptical about the actual value of what you're proposing but as I said, there's nothing stopping you (or anybody else) from starting up something informally, which would give us all a better sense of the actual interest level and what the likely output would be. Also, note that there have been IAB programs like stackevo to deal with these questions. Melinda --=20 Melinda Shore melinda.shore@nomountain.net Software longa, hardware brevis --BosGhIWfWryOTXkmN2E5F3Wj8c4cfXMdL-- --44wyMKZMyILCPnVByQ0TKq8XR2fXqoR59 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEET2gtkyoXlvgg8jTA37iRcpp2248FAl6GQ+oACgkQ37iRcpp2 249eoxAAuRHXWkTrxBbtga6wb7ukLyhWT2s45OUAiJqLS8qY65vwlO5tjgb1cQ8G uYQz7KintetP5ry9JIpm9B0tXu1CPlmfizPxKvIFmaVG0naNbnbXAHy1Ox/4VewK 5kNq+ntqi8Q6ZXb1wiPfllNXXsGFzTqWiCQ7hXdxS/wrKI5SBZ4NMN+QZA24IDJ5 eU4cxGS3CTjIOovMgTkyunbnRwghdv5jICOAby5KPd+gZOuVVIWad8t96F8HMu6g 5NfTGhAH7JiOzlUrHwP7/IauuvQuBIFfxCdvdQVv9v3HrSin/eoMKiKwd7RH/A/J a8w1ARpNMTfNBkY2/v3fs5EoGatUqxEhsuwEWSjuYqaVN+b8ZE6ZCwzQs1HNtUcQ HCZVeOIqoRMDp8NhMIrXRWtE1mDGPGT0YiPs7AxBNtpzJHe83bP5QKUnF1wzFYQC nUzUd5CfhCPMScUq9ZI2jkxE5HTiR5R3w1JXxJX7lIy5wSCLhsntWIplOtBhj3XF Oxch9Uh8kdluZ1WLInJJumY0vcxeYdx/r4LpMBUI/Urk5BQOAjozeTgkHg7e7+j3 jKYXw1dFmx7T8ap5MYUrz8F/B+1PhPzn5c3hwqLL6OTOrVFsX8NmVhjO5tuH/fXO ahPnhcH6SrxwlROdFkY4VyEUQu8v+OknQGdr850kzFkOpVhvLFU= =MhAT -----END PGP SIGNATURE----- --44wyMKZMyILCPnVByQ0TKq8XR2fXqoR59-- From nobody Thu Apr 2 14:30:57 2020 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 C2D503A1A34 for ; Thu, 2 Apr 2020 14:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, 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 vloF7Pw3RUBY for ; Thu, 2 Apr 2020 14:30:54 -0700 (PDT) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 9A0C43A1A33 for ; Thu, 2 Apr 2020 14:30:54 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id a13so2405236pfa.2 for ; Thu, 02 Apr 2020 14:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=qzQvPWFoEGOWxw7u5hR+18j1FshdrAZ0ZEVj12B03yo=; b=t+20k23q+kL6uXx6nyVkV/5eeSyhJ+GoxbT77uJWXaLPr2ZgGyNdlMTexSpTxR4hWw s7bO1znlvbfhTVHEY5LDEXh0878a30VaTFaIZiEuZ4YS0B4l26K0V+EaOBDKXZHcI+H5 5/eqkaoA8xsPvPEv29zV9sDBvahBPvKadOSpqodEPG5pGM8hy2LozKwm6RmDWo2mALbh Nq+5o4yluoszbTHGUfdykqhRoAhfXWlw8ei16yjjKDgKexbc+vxZ76GxvDdj4Bnr087V n3A93ja/QiC4DihCQndC83ZgzDjRD/warHNsZSVSR7gFJrtVeylOPTJQqtdxVQHG8236 mnIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=qzQvPWFoEGOWxw7u5hR+18j1FshdrAZ0ZEVj12B03yo=; b=WstvMkG/Jx8Tpv41fR8PYGx1/mN75GmneokGS4dZbcc0PrJAw0ndcovGtHUGgTbwaz OePVs9CKPK2C95jbP5KHmdwBe5W4EMXz/yZJusEFf/eflzdehSpMuGXkvfcoi3VpY01t MMDzSlUgLFN9tQ62/8dzAKT8/Dzs+u32LQGxsw9nA+9AtCOWXpH5DU7VsDZo0e2Ku5R3 PLpoLe61lf7NY5478cuvok0HXVEyLnEpEIK0JFMTG796IToRA3aJyNPWuJnScFLVgg5z Ou3WmOtbbShiwvnJgGSPzb4AIB+nUi7L1/MsBlH3CUvCX0slrcKMTd+CYP5Rl3h6opak 6zLA== X-Gm-Message-State: AGi0PuaqFuQ6EQpbtJsLMIzT1nEE3dW6a16RIsoDfGEbEun+fyVFpIfd 3RSWvPISzG+BaZKS3NteOH0G5krEwKE= X-Google-Smtp-Source: APiQypKKHXFiQbtFxqAjQ1hYQg69sGEFxXp7HzKJChwXqeNaiMFuFpJO3xVAlJ2TdfWr53HWhin7RQ== X-Received: by 2002:a65:498c:: with SMTP id r12mr5190033pgs.14.1585863054033; Thu, 02 Apr 2020 14:30:54 -0700 (PDT) Received: from [10.95.92.219] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id t4sm4423356pfb.156.2020.04.02.14.30.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2020 14:30:53 -0700 (PDT) Sender: Tony Li From: tony.li@tony.li Message-Id: <45C9053C-E9C9-4BAD-873C-AFA40F1DB96A@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_4CCD1928-8A21-4E0D-B056-C3EBE4F00545" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 2 Apr 2020 14:30:51 -0700 In-Reply-To: <17c21324-4238-9e56-48f2-e6df51967ca2@nomountain.net> Cc: Toerless Eckert , architecture-discuss@ietf.org To: Melinda Shore References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> <7de683b6-172b-7e7b-e043-d241804eaa42@nomountain.net> <20200402193430.GQ28965@faui48f.informatik.uni-erlangen.de> <17c21324-4238-9e56-48f2-e6df51967ca2@nomountain.net> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [arch-d] on the nature of architecture discussion (was: Re: [Chirp] Fwd: IETF 107 Vancouver In-Person Meeting Cancelled) 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, 02 Apr 2020 21:30:56 -0000 --Apple-Mail=_4CCD1928-8A21-4E0D-B056-C3EBE4F00545 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Right now, there is nothing stopping anybody from publishing > drafts and contributing to (or, indeed, leading) architectural > discussions in IETF working groups. I'm not sure what > inferences we should make from the fact that for the most part > that's not happening now. Well, we=E2=80=99ve tried that before. We=E2=80=99ve put in a great deal = of time and effort to make architectural changes. And they were met=20 with total indifference. My takeaway from this is that the only time that change is welcome or = even possible is when there is a great deal of=20 (perceived) pain. The pain MUST be much much greater than the pain of = change. Architectural improvement is not welcome. The last time the IAB articulated that there was such a threat of pain = was the ROAD conference in the early =E2=80=9890s. That led to the architectural (non)change of IPv6. Thus, until there is a serious architectural threat, the only thing to = do is to sit quietly and wait for time to pass. Regards, Tony --Apple-Mail=_4CCD1928-8A21-4E0D-B056-C3EBE4F00545 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Right now, = there is nothing stopping anybody from publishing
drafts and contributing to (or, = indeed, leading) architectural
discussions in IETF working groups.  I'm not sure = what
inferences we = should make from the fact that for the most part
that's not happening = now.


Well, we=E2=80=99ve tried that before. = We=E2=80=99ve put in a great deal of time and effort to make = architectural changes. And they were met 
with = total indifference.

My takeaway from this is that the only time that change is = welcome or even possible is when there is a great deal = of 
(perceived) pain. The pain MUST be much = much greater than the pain of change. Architectural improvement is not = welcome.

The = last time the IAB articulated that there was such a threat of pain was = the ROAD conference in the early =E2=80=9890s. That
led to the architectural (non)change of IPv6.

Thus, until there is a = serious architectural threat, the only thing to do is to sit quietly and = wait for time to pass.

Regards,
Tony

= --Apple-Mail=_4CCD1928-8A21-4E0D-B056-C3EBE4F00545-- From nobody Thu Apr 2 16:14:57 2020 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 D672A3A1BE4 for ; Thu, 2 Apr 2020 16:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 ITgykIQvxGvv for ; Thu, 2 Apr 2020 16:14:53 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE14D3A1BE3 for ; Thu, 2 Apr 2020 16:14:53 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 4275D548015; Fri, 3 Apr 2020 01:14:48 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 38D21440040; Fri, 3 Apr 2020 01:14:48 +0200 (CEST) Date: Fri, 3 Apr 2020 01:14:48 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Stephen Farrell , architecture-discuss@ietf.org Message-ID: <20200402231448.GR28965@faui48f.informatik.uni-erlangen.de> References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> <20200402163705.GN28965@faui48f.informatik.uni-erlangen.de> <36c258d4-3380-1875-73c4-da9ef6d180dd@cs.tcd.ie> <28d9100f-3b3f-2a20-6815-ded301b82c8d@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28d9100f-3b3f-2a20-6815-ded301b82c8d@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] [Chirp] on the nature of architecture discussion 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, 02 Apr 2020 23:14:56 -0000 On Fri, Apr 03, 2020 at 08:50:17AM +1300, Brian E Carpenter wrote: > >> I am complaining about the absence of a recurring, IAB organized > >> architecture-discuss/dispatch meeting slot at IETF meetings. > > I don't think you should place any reliance on "meetings" in the traditional > sense for the coming few years. Just because i am trying to be more positive about a victory over corona doesn't mean i would not also like to use this sad opportunity for the community to work out better ways to leverage virtual meetings. > Whether the sort of thing you want can > happen in on-line meetings is less clear to me, since on-line meetings > require floor-control, which is not what you want in any sort of > wide-ranging blue-sky discussion. I don't think this particular topics issues are any different than those of other tracks. The need for floor control is independent of whether you are on-line or physcially in a room. It purely depends on the number of passionate participants and the degree of passion about the topic. Typically we have these actual discussions mostly in official/inofficial side-meetings these days, typically through the absence of powerpoint. Not commenting on the technical aspects of the on-line meeting aspects, thats better done on manycouches@ietf.org. > > > On 03-Apr-20 08:14, Melinda Shore wrote: > > > FWIW, many years ago we had these discussions in the technical > > plenaries. They were, as a rule, unproductive, which may be why > > they have fallen by the wayside. > > > > I'm curious to know what you think would change if there were > > structured general architectural discussions. > > I think that the most important architectural documents have generally > originated from inspired individuals, not from structured discussions. > > Examples (intentionally ancient): > https://tools.ietf.org/html/rfc871 > https://tools.ietf.org/html/rfc875 Yes, what would today likely be individual submission track is always a good option to consider. Not sure how much more hurdles would be in a way to do the same today. Certainly a lot more than what it did to publish an acuel, true to the name "Request For Comment" back then. Cheers Toerless > > Brian > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Thu Apr 2 18:05:33 2020 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 971453A0A9A for ; Thu, 2 Apr 2020 18:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 ih6_oOnxSfhJ for ; Thu, 2 Apr 2020 18:05:25 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A878B3A0A99 for ; Thu, 2 Apr 2020 18:05:24 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 176C854804A; Fri, 3 Apr 2020 03:05:13 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 0ED2C440040; Fri, 3 Apr 2020 03:05:13 +0200 (CEST) Date: Fri, 3 Apr 2020 03:05:13 +0200 From: Toerless Eckert To: Melinda Shore Cc: architecture-discuss@ietf.org Message-ID: <20200403010512.GS28965@faui48f.informatik.uni-erlangen.de> References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> <7de683b6-172b-7e7b-e043-d241804eaa42@nomountain.net> <20200402193430.GQ28965@faui48f.informatik.uni-erlangen.de> <17c21324-4238-9e56-48f2-e6df51967ca2@nomountain.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17c21324-4238-9e56-48f2-e6df51967ca2@nomountain.net> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] on the nature of architecture discussion (was: Re: [Chirp] Fwd: IETF 107 Vancouver In-Person Meeting Cancelled) 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, 03 Apr 2020 01:05:32 -0000 On Thu, Apr 02, 2020 at 11:58:34AM -0800, Melinda Shore wrote: > On 4/2/20 11:34 AM, Toerless Eckert wrote: > > Was it only presentations or also associated drafts ? Was the > > material asked to be make available sufficiently long ago to > > allow quality updates be prior review ? > > Neither, really. It largely consisted of heated discussions at > the mike lines. While there were presentations, for the most > part they were not architectural in nature (with a few notable > exceptions). Ok, remembering some bits now. That was fun, but yes, not what i was thinking of. > My sense, from several decades of involvement in the IETF in > various capacities, is that 1) it would take years to get > agreement on a diagram of the current internet architecture > and what you'd end up would be aspirational rather than > descriptive; I think we can and are doing descriptive. Most of stackevo mentioned by you below was descriptive. So are IMHO many other documents/RFC i would consider to be architectural. I can think of aspirational as a good and even necessar thing. > 2) architectural discussions in the past have > had minimal impact on actual protocol design; That is a very broad statement. We should first have an unserstanding about what we mean with architecture before i should even ask you to give me example evidence of this. My architecture interests for example are probably a lot lower inside the machine room of the Internet than e.g. the Internet BGP peering architecure. But all of it is valid architecture topics to me. For example, i would consider CBOR an example of an architcure concept (presentation layer) brought into IETF and protocols. One example architecture area of interest for me is the problem that we are not well enough taking the architecture of routers in to account for our protocols, or better yet propose to evolve architecture of both routers and protocols to be better fits in the future. I am betting neither of these topics are what you would have considered to be architecture in your statement... ?? > and 3) complexity > always wins in the end (the history and output of the NSIS > working group might be a particularly illustrative example > of the latter). > > Right now, there is nothing stopping anybody from publishing > drafts and contributing to (or, indeed, leading) architectural > discussions in IETF working groups. I'm not sure what > inferences we should make from the fact that for the most part > that's not happening now. If architecture can be associated directly with protocols of an IETF WG, then yes, it could and should happen in that WG, but i think there are more cases where even this does not happen. E.g.: I have seen ADs eliminate architecture from charters because it does not produce implementable protocols. But the more fundamental issue is that architecture mostly needs to predate protocol development, like research mostly needs to predate architecture and protocols. I can not see a logic that argues we must have an IRTF, but we cannot have an IATF (Internet Architecture Task Force). The whole construct of IAB for architecture is weird to me. > I'm skeptical about the actual value of what you're proposing > but as I said, there's nothing stopping you (or anybody else) > from starting up something informally, which would give us all > a better sense of the actual interest level and what the likely > output would be. Oh, i think there is a lot of sport in trying to discourage work that is not officially sponsored by the IETF/IAB authorities at least from my imited experience. We need to be darn careful with every single word we write about a side meeting. Make sure it is called "non official" every time you mention it, having people seemingly "borrow" sign up sheets for examination what could be wrong with them, ending up with concerns of using the same color (!) as "official" IETF meeting sign up sheets. Dismissive comments about even doing a side-meeting, Not being allowed to use IETF tooling like webex, jabber, wiki, etherpad, and so on. Because using IETF tools would mean "endorsement of the activity" *sigh*. This is sad in general, but at a time when it is legally crucial to make sure all communications is easily recognizeable as public and published because of the US Govt. export regulations (see EAR 734.7) it is outright dangerous to make it so difficult for inofficial side-meetings to use or emulate the public/published nature of official IETF meetings. > Also, note that there have been IAB programs like stackevo to > deal with these questions. Last RFC published in 2016. Concluded in 2019. Followup to architecture-discuss according to closing mail. Cheers Toerless > > Melinda > > > -- > Melinda Shore > melinda.shore@nomountain.net > > Software longa, hardware brevis > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Thu Apr 2 18:23:42 2020 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 254893A0AF7 for ; Thu, 2 Apr 2020 18:23: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, 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 (1024-bit key) header.d=cs.tcd.ie 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 L4TEIYjWVtrN for ; Thu, 2 Apr 2020 18:23:37 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3DBC3A0AF4 for ; Thu, 2 Apr 2020 18:23:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D8DF5BE4D; Fri, 3 Apr 2020 02:23:32 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6cWPxaV9KNw; Fri, 3 Apr 2020 02:23:31 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3AB31BE4C; Fri, 3 Apr 2020 02:23:31 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1585877011; bh=tHHd5rz1F1DdKmap9rEWcRTiCFRtb8sW9wRjFmIF2Ik=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=tdMHgvANsiKIo5g4DZabkQ4EqT1wg+kYSuASX65r07iynDPPLIx74XAWamTAs3CvX Q3YpCMx1ONL02LnsW2/3YG3+2CYuTVtsxlc54ePqJQXgCJIEbHb0yk0S2rl+bJeWUQ HyVs2LziYaDCWyRmWVW4B4HVvZqVQkI2ldgjnXQE= To: Toerless Eckert Cc: architecture-discuss@ietf.org References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> <7de683b6-172b-7e7b-e043-d241804eaa42@nomountain.net> <20200402193430.GQ28965@faui48f.informatik.uni-erlangen.de> <17c21324-4238-9e56-48f2-e6df51967ca2@nomountain.net> <20200403010512.GS28965@faui48f.informatik.uni-erlangen.de> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Fri, 3 Apr 2020 02:23:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200403010512.GS28965@faui48f.informatik.uni-erlangen.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PwJIdVdD0FGV9LPCLjMYO9OX78DqMBWuP" Archived-At: Subject: Re: [arch-d] on the nature of architecture discussion (was: Re: [Chirp] Fwd: IETF 107 Vancouver In-Person Meeting Cancelled) 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, 03 Apr 2020 01:23:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PwJIdVdD0FGV9LPCLjMYO9OX78DqMBWuP Content-Type: multipart/mixed; boundary="7ogubGmfHekcNAGTPc8e68vYmD14OIb7z"; protected-headers="v1" From: Stephen Farrell To: Toerless Eckert Cc: architecture-discuss@ietf.org Message-ID: Subject: Re: [arch-d] on the nature of architecture discussion (was: Re: [Chirp] Fwd: IETF 107 Vancouver In-Person Meeting Cancelled) References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> <7de683b6-172b-7e7b-e043-d241804eaa42@nomountain.net> <20200402193430.GQ28965@faui48f.informatik.uni-erlangen.de> <17c21324-4238-9e56-48f2-e6df51967ca2@nomountain.net> <20200403010512.GS28965@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200403010512.GS28965@faui48f.informatik.uni-erlangen.de> --7ogubGmfHekcNAGTPc8e68vYmD14OIb7z Content-Type: multipart/mixed; boundary="------------A3F30393E4DD1193B6C96D9A" Content-Language: en-US This is a multi-part message in MIME format. --------------A3F30393E4DD1193B6C96D9A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, This aspect is nothing to do with having or not having meetings, so don't take this as a negative or positive, but this bit of your mail hits a button of mine... On 03/04/2020 02:05, Toerless Eckert wrote: > But the more fundamental issue is that architecture mostly > needs to predate protocol development I've always thought that Internet architecture was mostly post-hoc "discovery" and wasn't really ex-ante invention. But, I wasn't there, and haven't delved deeply, so I don't claim to be sure. Has anyone tried to do a study to figure out if either of those are reasonable descriptions that match history? Cheers, S. --------------A3F30393E4DD1193B6C96D9A Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------A3F30393E4DD1193B6C96D9A-- --7ogubGmfHekcNAGTPc8e68vYmD14OIb7z-- --PwJIdVdD0FGV9LPCLjMYO9OX78DqMBWuP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl6GkBIACgkQWrL68XsX K+q5fQ/9FqL5sbaeoCsn/kaUdGhnMf+h0+dG9l0b2XmxRlEoF+DXsYibt5GIjTox xztfjQyAEZKoKL0VZbvLjhIn30UvHtTmIogNdzf/JHaLydehj7a7iAKVp2yK+rm1 djdfLz+TiBJm3RRsUg/uFLrZ/xiqZyibn4hvYHRkQs9UcJcBxMkM/vapepQgAl2f 9Dnk88ijcBdTqCUGt/OVL6/krH+LfhmoO2gYRQ0i8tSgGxov4JmYUUyMUHekBn3t LiNVshuBbTxJJ69XB5Sp08MxowbxPA76/u0J9aYPpvGXDNPhOqvudJQL1ss+M55I 87qDwzlvfDTTC5bfSWqqD/1kjcf+5Q9aU3mMwKEDBerbaROUbQJx7K/iW3Q9Lpk5 K3akX5i8esu+jTYdcnQSSzUZ+kyPQZ7ky/gTNZOrDoRsukmjU0BVDp4CQvWijopP D5NmmNgm/pqwG0TlH01Vh2vQkBzlFVNxrKfiXnz/MtgkbzfxKaQNPgeUSe1aF8ao rNlFpj8cTs4HvCXERFDwQpEa57wRO2Ig0Iom6n8w6Wku0w3wYuW+9ztUwcBh4GUo MQlfERBhxyT1lJa56TGLy8S2/sGU1uW/zE3F0a3Lp+Q9V+jh5hlh713pjZ7oScQt jW/frufnSn888BveIRLeTynitDVblGV0HK/WGVQsQTqGQPQV8kQ= =WtM3 -----END PGP SIGNATURE----- --PwJIdVdD0FGV9LPCLjMYO9OX78DqMBWuP-- From nobody Thu Apr 2 19:55:57 2020 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 6A1DB3A0CF6 for ; Thu, 2 Apr 2020 19:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=ar3vcRZD; dkim=pass (1536-bit key) header.d=taugh.com header.b=QFja8dnd 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 2DJhBJALE7NW for ; Thu, 2 Apr 2020 19:55:53 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 A75053A0CF3 for ; Thu, 2 Apr 2020 19:55:53 -0700 (PDT) Received: (qmail 83150 invoked from network); 3 Apr 2020 02:55:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=144cc.5e86a5b7.k2004; bh=8V8DO0iTAZGDycHLYQ0nV2H4yWf2fs6Rd5vwBJYlUAc=; b=ar3vcRZD6X2RMlwyL6cvFA9dAWIwUEIZ0UhTD9j7bgfnnavtgEmeYZCPRbpqmP5Z66VJMrP0S4FMkoIKoZAnfqSgrtMTAhVkYlWSIzoMYicwrKSKLOWxHHtZ5v/KsRacBVAUvvP40mkzTWWiIHJDssIg2X2nI541Hez6jgAoCSd88tWqbZHWlmCm8mTQBIWWl0C2Rzqz6hSvnVeYr9Uib28AiWePK/7kmKKUOR/py8YNkAO/AYm6rDYPJO76VuzS DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=144cc.5e86a5b7.k2004; bh=8V8DO0iTAZGDycHLYQ0nV2H4yWf2fs6Rd5vwBJYlUAc=; b=QFja8dndpBCgj9aZabEop35ea/E8GpaZgKi/E8+xXd5luVLr2a72mCg2yRPSxf9WT95VdnQcatSkFQsdg2rHsscZcgKdAFztCYoRMcsIO3MgKd4dj+ykQCKEMyIYccw9eRq+1eKbakiEWbUFDkqL/iGLzsjb71dOZEjRw679I1kNeIjyOIkueNHTwIJed19td9Z0FwDrZVOGOryQoiYSXBr+warsTX5whHeeh6eT372D7c2a/11PI7EzuuXXAu8i Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 03 Apr 2020 02:55:51 -0000 Received: by ary.qy (Postfix, from userid 501) id 5D27C16F6977; Thu, 2 Apr 2020 22:55:51 -0400 (EDT) Date: 2 Apr 2020 22:55:51 -0400 Message-Id: <20200403025551.5D27C16F6977@ary.qy> From: "John Levine" To: architecture-discuss@ietf.org Cc: tte@cs.fau.de In-Reply-To: <20200403010512.GS28965@faui48f.informatik.uni-erlangen.de> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [arch-d] on the nature of architecture discussion (was: Re: [Chirp] Fwd: IETF 107 Vancouver In-Person Meeting Cancelled) 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, 03 Apr 2020 02:55:56 -0000 In article <20200403010512.GS28965@faui48f.informatik.uni-erlangen.de> you write: >But the more fundamental issue is that architecture mostly >needs to predate protocol development, like research mostly >needs to predate architecture and protocols. Not to be unduly snarky, but have we already forgotten about OSI? From nobody Fri Apr 3 03:41:18 2020 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 81DA63A0EDF for ; Fri, 3 Apr 2020 03:41:15 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=livelancsac.onmicrosoft.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 kcUlJQY5wzYb for ; Fri, 3 Apr 2020 03:41:10 -0700 (PDT) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100133.outbound.protection.outlook.com [40.107.10.133]) (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 AF3D73A0ED6 for ; Fri, 3 Apr 2020 03:41:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PAehoyJIZGMmzj+DbOTyO1y1JFWuSzDD3APj5BDHzsATZtioD+QitjOnjqPBQfHADwviYWxzrSBlPsx6/pad80zlTHHw9B9T+29p4r1FXX9GpkPj/RoBg/4ItI1H8akPWUsFYTwX/WjKw+Iaxkf84gF/mFR37bzsk7HstoOo00fXCqbPLqNG9VKAfnBB8H6hlCIp7iPAsrZGdOyDvRNumndmfftoJlU+P4Gd8Stg7w6vC3Uy8lE33UjiJDfQ7si746mggwsI42+fKK45yQCQarCAnpevWwPqCtoJPe38qLnQzBQSCHHqVdnxlMtdRy0LV29M12P7O/k+e/v16XQZsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TxfEV5FTu84pqAOrpaFOxzMWtGI5aCqKqlmkkOTZQgI=; b=mI/L9lIwXGxZfIuRFuhgBZIV6r253PLAwx4cfNQIUgohXWasdRBqkUfNowtiE8/1k1UaSq07l3CuFwxpU99a7k3blM817V/YtdgkAdRlFImXebXfYP2/Z5IGu6RkvmbuzKI86Gvf1H8rFiZrKMhoZ7FcKPgJ0bKeuTdPOBohSR9N2mw4msYHploDwI7fBMMLrzttU3tlGvFaglwmM+SeviTPc+bdaz8Uar4mEOssLHN+yYK4aVJu1nawTP1OhHG5kmj/GqexyNlRm1mB7sHXLDb0NE6dV6UMvfGj1kO0LdjMOR5E053KTsAPcQNvPCIzfpklVBQm0LklnfUM0t7R/g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=lancaster.ac.uk; dmarc=pass action=none header.from=lancaster.ac.uk; dkim=pass header.d=lancaster.ac.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=livelancsac.onmicrosoft.com; s=selector2-livelancsac-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TxfEV5FTu84pqAOrpaFOxzMWtGI5aCqKqlmkkOTZQgI=; b=LYrhU73RVRftYq2Y03im8QAEzI3W6VS4thkAOVbnbopAMFNCczIg9kBfd9EJdpr8hHfwUrXwe4Zy+3ALjUe7Y3DDK592dOKFYHLITCCneoe3zdQMFG/kvV3AAOI2HpvCxJEtfaOBy0PTUPi3YRYuNSK1IZJ6zGom/f3Cif5VV/c= Received: from CWLP265MB0612.GBRP265.PROD.OUTLOOK.COM (10.166.23.10) by CWLP265MB1028.GBRP265.PROD.OUTLOOK.COM (20.176.34.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Fri, 3 Apr 2020 10:41:06 +0000 Received: from CWLP265MB0612.GBRP265.PROD.OUTLOOK.COM ([fe80::498c:513c:8f84:9580]) by CWLP265MB0612.GBRP265.PROD.OUTLOOK.COM ([fe80::498c:513c:8f84:9580%7]) with mapi id 15.20.2856.019; Fri, 3 Apr 2020 10:41:06 +0000 From: "Hutchison, David" To: Stephen Farrell , Toerless Eckert CC: "architecture-discuss@ietf.org" Thread-Topic: [arch-d] on the nature of architecture discussion (was: Re: [Chirp] Fwd: IETF 107 Vancouver In-Person Meeting Cancelled) Thread-Index: AdYJm/Fu/8NOaJelSwOjduSZhGUuuw== Date: Fri, 3 Apr 2020 10:41:06 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=d.hutchison@lancaster.ac.uk; x-originating-ip: [2a00:23c4:a52a:5700:ed18:6420:d37d:a693] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2f0e83cd-9f57-4c11-933d-08d7d7bb83a7 x-ms-traffictypediagnostic: CWLP265MB1028: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0362BF9FDB x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CWLP265MB0612.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(396003)(136003)(366004)(376002)(346002)(39860400002)(52536014)(55016002)(2906002)(64756008)(66946007)(7696005)(786003)(53546011)(33656002)(316002)(9686003)(4326008)(6506007)(296002)(110136005)(66446008)(66476007)(76116006)(5660300002)(71200400001)(66556008)(81156014)(8676002)(86362001)(81166006)(478600001)(8936002)(66574012)(186003); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: lancaster.ac.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qAfzaPUEwQZvZo7GTDgLyQWBU2zoiSepUH7obOuRdLXwIpstHPQBDbcbXQILoPQlx7bewh2DsWd2O1v3UDq4sjlf4RBq/jDWfSTmbZsQPwms8EeKkSikb1Em3e34J6re6H4YQoduz+ylKc9TpZ5UWp4OSFdvZD+WdjkD1XQYsHHwqcrXjg+z1w++3+DZVDWVnN371jGa0yivmK4njV1OtfRd3fvBdSnwj+eOWjCJtHHAOfdSOrSuA7icPO/bnw8MIjnitAs3yuGrcKVNdgkm34RijW9x05t42UaJ2KBAjUTrjK4t7s3CoNXkfmyvDntTXL7ghdYPOdUaaZKX2HNxFbQXtgHZw5Xw7vR1GTJNYBnVPRyNIaQsls24a44Sp+G6ygM//Wa20GNxzhEM8zoLgH+k9egy0oAvjM+SgLKzmTzrPU/edlqvuJKkmZNsSWlX x-ms-exchange-antispam-messagedata: A1bpsw+VZvIy1qnHhTXOqvePFuwQyUUodhM2IgtBQXonwUiOoZCiX74DsMd9QaMX19qN+o7Ab7qpWztt4dc1f11cf1ERmK/rsbSuEC1ZkTgfdhUV1XjpshXCZRhzIuEqDZFPyqub8vynCVmeXaiWGptFZ9GZVOQ1KTR6HQHergwJJ6jWrec/TUyaIL+5pPsaMHR4/h1PvaQcX0fxLMJgpA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: lancaster.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 2f0e83cd-9f57-4c11-933d-08d7d7bb83a7 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2020 10:41:06.2049 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c9bcd11-977a-4e9c-a9a0-bc734090164a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: GbMPVJbjTxtlOXo0PVmk5ql36ylqo9WOy7WTJmH2Z7lYl72igbCv+NjEVT1uxeEl7HlI7ZjdrNBSzP2O8SMX8GnegmOlwYGX6T2K7O7ubC0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CWLP265MB1028 Archived-At: Subject: Re: [arch-d] on the nature of architecture discussion (was: Re: [Chirp] Fwd: IETF 107 Vancouver In-Person Meeting Cancelled) 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, 03 Apr 2020 10:41:16 -0000 SGVsbG8gZXZlcnlvbmUsDQoNCkkndmUgdGhvdWdodCBvdmVyIHRoZSB5ZWFycyB0aGF0IHRoZXJl J3MgYSByZWx1Y3RhbmNlIHRvIHRhbGsgYWJvdXQgJ2FyY2hpdGVjdHVyZScgaW4gdGhlIGNvbnRl eHQgb2YgdGhlIEludGVybmV0LCBhcyBpZiBpdCBpbXBsaWVzIGRpc2N1c3Npb25zIHRoYXQgd2ls bCBiZSB0b28gYnJvYWQgYW5kIHBlcmhhcHMgaW50ZW5kZWQgcHJpbWFyaWx5IHRvIGJyaW5nIGFi b3V0IGZ1bmRhbWVudGFsIGNoYW5nZS4NCg0KRm9yIG1lLCAnYXJjaGl0ZWN0dXJlJyBpcyBtdWNo IG1vcmUgZG93bi10by1lYXJ0aCwgYW5kIGlzIHRvIGRvIHdpdGggZGVzY3JpYmluZyBhbiBvdmVy YWxsIHN0cnVjdHVyZSBpbiB3aGljaCB3ZSBjYW4gc2VlIGhvdyBzeXN0ZW0gY29tcG9uZW50cyBm aXQgdG9nZXRoZXIuIFNvIEknbSB3aXRoIFRvZXJsZXNzIG9uIHRoaXMgLS0gSSB0aGluayB0aGlz IGlzIHdoYXQgaGUncyBzdWdnZXN0aW5nLiBJIGFsc28gbGlrZSB0aGUgbm90aW9uIG9mIHZpZXdw b2ludHMgKGFzIHVzZWQgaW4gdGhlIFJlZmVyZW5jZSBNb2RlbCBvZiBPcGVuIERpc3RyaWJ1dGVk IFByb2Nlc3NpbmcpIGJlY2F1c2UgdGhlcmUncyBnb2luZyB0byBiZSBtb3JlIHRoYW4gb25lIGRl c2NyaXB0aW9uIG9mIGEgbmV0d29yayBvciBuZXR3b3JrZWQgc3lzdGVtIGRlcGVuZGluZyBvbiB3 aGF0IHRoZSB0YXJnZXQgaXMuIEZvciBleGFtcGxlLCBJJ20gaW50ZXJlc3RlZCBpbiBhbiBhcmNo aXRlY3R1cmFsIGRlc2NyaXB0aW9uIG9mIGhvdyBhdXRvbm9taWMgbWFuYWdlbWVudCBtaWdodCBi ZSBkb25lLCBhbmQgYWxzbyBob3cgd2UgbWlnaHQgZGVzY3JpYmUgYSBmdXR1cmUgbmV0d29ya2Vk IHN5c3RlbSBpbiB0ZXJtcyBvZiBQTkYgYW5kIFZORiBidWlsZGluZyBibG9ja3MuIFRob3NlIGRv IG5vdCBpbXBseSBhbnkgY2hhbmdlcyBpbiB0aGUgSW50ZXJuZXQgcHJvdG9jb2xzIC0tIGJ1dCB0 aGV5IGNhbiBvZmZlciBhIHVzZWZ1bCBzdGFydGluZyBwb2ludCBmb3IgcmVzZWFyY2ggdGhhdCB3 aWxsIHVzZSAoYW5kIG1heWJlIHNob3cgdGhlIG5lZWQgZm9yIGNoYW5nZSB0bykgY3VycmVudCBw cm90b2NvbHMgYW5kIHNlcnZpY2VzLiBMaWtld2lzZSwgaWYgbmV3IHNlcnZpY2UgcmVxdWlyZW1l bnRzIGVtZXJnZSwgaXQncyByaWdodCB0byBkaXNjdXNzIHRoZXNlIGluIGEgc3RydWN0dXJlZCAo b3Igc3RydWN0dXJhbD8pIHdheSB0byBzZWUgaWYgdGhlcmUncyBhIG5lZWQgZm9yIG5ldyBvciBt b2RpZmllZCBwcm90b2NvbHMsIG9yIHNlcnZpY2VzLCBvciBBUElzIC0tIG5vdCBsZWFzdCB0byBz YXRpc2Z5IGxhdGVuY3kgcmVxdWlyZW1lbnRzLCBvciBzZWN1cml0eSwgb3IgcmVzaWxpZW5jZSAu Li4NCg0KR2V0dGluZyB0byBTdGVwaGVuJ3MgcXVlc3Rpb246IEkndmUgYWx3YXlzIHVuZGVyc3Rv b2QgdGhlIChvcmlnaW5zIG9mKSB0aGUgSW50ZXJuZXQgaW4gdGVybXMgb2YgdGhlICdkZXNpZ24g cHJpbmNpcGxlcycgdGhhdCBEYXZpZCBDbGFyayBhbmQgb3RoZXJzIHRhbGsgYW5kIHdyaXRlIGFi b3V0LiBUaGUgJ2FyY2hpdGVjdHVyZScgaGFzLCBJIGJlbGlldmUsIGxhcmdlbHkgZm9sbG93ZWQg ZnJvbSB0aG9zZSwgaW5jbHVkaW5nICdjdWJlJyBkaWFncmFtcyBhbmQgb2YgY291cnNlIGxheWVy ZWQgZGlhZ3JhbXMgdGhhdCBtYW55IHBlb3BsZSBmaW5kIGhlbHBmdWwgZm9yIGlsbHVzdHJhdGlv biBidXQgYWxzbyBmb3IgZGVzaWduIGFuZCBpbXBsZW1lbnRhdGlvbi4NCiANCkhhdmluZyBzYWlk IGFsbCB0aGF0LCBvZiBjb3Vyc2UgaXQncyBub3QgZWFzeSBvcmdhbml6aW5nIG1lZXRpbmdzIHRv IGRpc2N1c3MgYXJjaGl0ZWN0dXJlLCBzbyB0aGUgZ29hbHMgd291bGQgaGF2ZSB0byBiZSBjYXJl ZnVsbHkgc2V0IG91dCAtLSBhbmQgQnJpYW4gaXMgY29ycmVjdCB0byB3YXJuIGFib3V0IGRpZmZp Y3VsdGllcyBnaXZlbiB0aGUgY3VycmVudCBjaXJjdW1zdGFuY2VzLg0KDQpCZXN0IHJnZHMsDQpE YXZpZA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQXJjaGl0ZWN0dXJlLWRp c2N1c3MgPGFyY2hpdGVjdHVyZS1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBP ZiBTdGVwaGVuIEZhcnJlbGwNClNlbnQ6IEZyaWRheSwgMyBBcHJpbCwgMjAyMCAwMjoyNA0KVG86 IFRvZXJsZXNzIEVja2VydCA8dHRlQGNzLmZhdS5kZT4NCkNjOiBhcmNoaXRlY3R1cmUtZGlzY3Vz c0BpZXRmLm9yZw0KU3ViamVjdDogW0V4dGVybmFsXSBSZTogW2FyY2gtZF0gb24gdGhlIG5hdHVy ZSBvZiBhcmNoaXRlY3R1cmUgZGlzY3Vzc2lvbiAod2FzOiBSZTogW0NoaXJwXSBGd2Q6IElFVEYg MTA3IFZhbmNvdXZlciBJbi1QZXJzb24gTWVldGluZyBDYW5jZWxsZWQpDQoNClRoaXMgZW1haWwg b3JpZ2luYXRlZCBvdXRzaWRlIHRoZSBVbml2ZXJzaXR5LiBDaGVjayBiZWZvcmUgY2xpY2tpbmcg bGlua3Mgb3IgYXR0YWNobWVudHMuDQoNCkhpeWEsDQoNClRoaXMgYXNwZWN0IGlzIG5vdGhpbmcg dG8gZG8gd2l0aCBoYXZpbmcgb3Igbm90IGhhdmluZyBtZWV0aW5ncywgc28gZG9uJ3QgdGFrZSB0 aGlzIGFzIGEgbmVnYXRpdmUgb3IgcG9zaXRpdmUsIGJ1dCB0aGlzIGJpdCBvZiB5b3VyIG1haWwg aGl0cyBhIGJ1dHRvbiBvZiBtaW5lLi4uDQoNCk9uIDAzLzA0LzIwMjAgMDI6MDUsIFRvZXJsZXNz IEVja2VydCB3cm90ZToNCj4gQnV0IHRoZSBtb3JlIGZ1bmRhbWVudGFsIGlzc3VlIGlzIHRoYXQg YXJjaGl0ZWN0dXJlIG1vc3RseSBuZWVkcyB0byANCj4gcHJlZGF0ZSBwcm90b2NvbCBkZXZlbG9w bWVudA0KDQpJJ3ZlIGFsd2F5cyB0aG91Z2h0IHRoYXQgSW50ZXJuZXQgYXJjaGl0ZWN0dXJlIHdh cyBtb3N0bHkgcG9zdC1ob2MgImRpc2NvdmVyeSIgYW5kIHdhc24ndCByZWFsbHkgZXgtYW50ZSBp bnZlbnRpb24uDQpCdXQsIEkgd2Fzbid0IHRoZXJlLCBhbmQgaGF2ZW4ndCBkZWx2ZWQgZGVlcGx5 LCBzbyBJIGRvbid0IGNsYWltIHRvIGJlIHN1cmUuIEhhcyBhbnlvbmUgdHJpZWQgdG8gZG8gYSBz dHVkeSB0byBmaWd1cmUgb3V0IGlmIGVpdGhlciBvZiB0aG9zZSBhcmUgcmVhc29uYWJsZSBkZXNj cmlwdGlvbnMgdGhhdCBtYXRjaCBoaXN0b3J5Pw0KDQpDaGVlcnMsDQpTLg0K From nobody Fri Apr 3 04:36:14 2020 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 E1C723A17F7 for ; Fri, 3 Apr 2020 04:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZi3V03xT0Km for ; Fri, 3 Apr 2020 04:36:06 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 AC3D13A17F6 for ; Fri, 3 Apr 2020 04:36:05 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id w15so1867760wrv.10 for ; Fri, 03 Apr 2020 04:36:05 -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=Iv6xJHhoMoFCT51pVmRzcIXea/2tJm+G3y0c3LH+kDM=; b=DslL3MHruRgkdwzhnqTrK0rAdAUneLzoLk1LckcXjcmXYI8xGRSSRp6O/VvBIJn+zl t0+Ux265d8QIYsb7SXqmFk8bfLVae64JYckKIwYXtnEoOwyrmNLM1pt9Oq8rG9to877e 1Rp6IBMgpJKvFbZ2ofieTbNrpcUHODYdIa2gqtTFhQ6hZOAJKQfn9HMXX8+jl4getLeS OsGtfaLEbXZ27fbeD5uSnG1yEmU1Mn3V+hSqssMGxzehBfT31orTnhcyNajOwKAhkV2w WO028MaTbg6NuQEs2YneIPWsXrF5SdFILEq+iO3NhfIRjE3OdyBR9Ui091KxrzR1qpDH LWdg== 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=Iv6xJHhoMoFCT51pVmRzcIXea/2tJm+G3y0c3LH+kDM=; b=AZLg/6qtZK+ac8YKN62MsmifuJCY/6jVH0qnu0avVjQqpIYGt2/b/iMXBZfF+4TPIF Q11p4URyEF1h705rQIn39qVUaLyXUJqk3XsBXQyz2eppbtmUgsnqzIblZZmE9dwpUshp k/VCn9L/GiTUzlk+oEp3TYL0Z7FMHK8EPxYwybtcftMhlKtstW7LLqPSaqbME8bggoXT ExXbkEsuG6wLisOjko3ynkg+MwClAf7YI5jsHY+KXob2KcWIX23/U3/ZDEdcOG09M0Vs ITn8D4ZapT3CSqao0AucKOBCG2hS23GaH7QFXOy1nuxD3wE/Pm0TBzO30zmeyGGZm7Is DKEA== X-Gm-Message-State: AGi0PuZUaBsxf5XTUQOC7eASZzUug0lHd6XQA/fyUXbZ+2h1f9dZPavo rrquKwziKk5SEYcgVKx193s= X-Google-Smtp-Source: APiQypJSSyWBbwtqQ6SBBAmsIo7nFzkTtt6geKGAX0DagO/k82H2vZQCawV7VIkr85ko6J92vKF0lQ== X-Received: by 2002:a5d:460f:: with SMTP id t15mr8637041wrq.413.1585913763711; Fri, 03 Apr 2020 04:36:03 -0700 (PDT) Received: from broadband.bt.com ([2a00:23a8:4140:0:3160:c613:68b0:b602]) by smtp.gmail.com with ESMTPSA id u16sm11607150wro.23.2020.04.03.04.36.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Apr 2020 04:36:03 -0700 (PDT) From: Stewart Bryant Message-Id: <374C8F16-5781-4BC8-8D0A-1136400BD1D4@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6260B2B8-855B-42C5-816A-D6B34D97CB10" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Fri, 3 Apr 2020 12:36:01 +0100 In-Reply-To: <17c21324-4238-9e56-48f2-e6df51967ca2@nomountain.net> Cc: Stewart Bryant , Toerless Eckert , architecture-discuss@ietf.org To: Melinda Shore References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> <7de683b6-172b-7e7b-e043-d241804eaa42@nomountain.net> <20200402193430.GQ28965@faui48f.informatik.uni-erlangen.de> <17c21324-4238-9e56-48f2-e6df51967ca2@nomountain.net> X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [arch-d] on the nature of architecture discussion (was: Re: [Chirp] Fwd: IETF 107 Vancouver In-Person Meeting Cancelled) 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, 03 Apr 2020 11:36:13 -0000 --Apple-Mail=_6260B2B8-855B-42C5-816A-D6B34D97CB10 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 2 Apr 2020, at 20:58, Melinda Shore = wrote: >=20 > I'm skeptical about the actual value of what you're proposing > but as I said, there's nothing stopping you (or anybody else) > from starting up something informally, which would give us all > a better sense of the actual interest level and what the likely > output would be. Regrettably the actions of the US Government excluded an active part of = the IETF community from taking part in informal technical discussions. If a principled position of the IETF is the inclusion of all competent = contributors, we cannot have informal technical discussions until the US = Government changes its position. As far as I can tell, ignoring the position taken by the US Government = puts us at risk as individuals regardless of our nationality or our = affiliation. Hence the request for formality in these discussions. - Stewart --Apple-Mail=_6260B2B8-855B-42C5-816A-D6B34D97CB10 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 2 Apr 2020, at 20:58, Melinda Shore <melinda.shore@nomountain.net> wrote:

I'm skeptical = about the actual value of what you're proposing
but as I = said, there's nothing stopping you (or anybody else)
from starting = up something informally, which would give us all
a better = sense of the actual interest level and what the likely
output would = be.

Regrettably the actions of the US Government excluded an = active part of the IETF community from taking part in informal technical = discussions.

If = a principled position of the IETF is the inclusion of all competent = contributors, we cannot have informal technical discussions until the US = Government changes its position.

As far as I can tell, ignoring the = position taken by the US Government puts us at risk as individuals = regardless of our nationality or our affiliation.
Hence the request for formality in = these discussions.

- Stewart


= --Apple-Mail=_6260B2B8-855B-42C5-816A-D6B34D97CB10-- From nobody Fri Apr 3 05:26:12 2020 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 72B7A3A18F3 for ; Fri, 3 Apr 2020 05:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 KQu3uLo1Wel9 for ; Fri, 3 Apr 2020 05:26:03 -0700 (PDT) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id A1EF43A18EA for ; Fri, 3 Apr 2020 05:25:58 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.126.213]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 033CP2fe020846 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2020 05:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1585916716; x=1586003116; i=@elandsys.com; bh=vjjSFtU7OLpssxz40gYWXu4aTsqxWNWujZiFnY1AQCs=; h=Date:To:From:Subject:In-Reply-To:References; b=fQRbsmCiHVAyqqUn4uFrK1KMSuaERgTo/kufsPuArvP9Si5BezeIEBxrzdPQxZZS/ 7gIvVvq8MeBBIdix63ExXFYnQDSXWgDj/yGm9LiJSQ/HD02NRhThgjNZUBjVn9QFiG hINPFE9e92BJ2HW8EUx4sbmA0ckXc6aEzY4vSoyI= Message-Id: <6.2.5.6.2.20200403042829.11c2a9e0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 03 Apr 2020 05:24:47 -0700 To: Toerless Eckert , architecture-discuss@iab.org From: S Moonesamy In-Reply-To: <20200403010512.GS28965@faui48f.informatik.uni-erlangen.de> References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> <7de683b6-172b-7e7b-e043-d241804eaa42@nomountain.net> <20200402193430.GQ28965@faui48f.informatik.uni-erlangen.de> <17c21324-4238-9e56-48f2-e6df51967ca2@nomountain.net> <20200403010512.GS28965@faui48f.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] on the nature of architecture discussion (was: Re: [Chirp] Fwd: IETF 107 Vancouver In-Person Meeting Cancelled) 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, 03 Apr 2020 12:26:10 -0000 Hi Toerless, At 06:05 PM 02-04-2020, Toerless Eckert wrote: >If architecture can be associated directly with protocols >of an IETF WG, then yes, it could and should happen >in that WG, but i think there are more cases where even >this does not happen. E.g.: I have seen ADs eliminate architecture >from charters because it does not produce implementable protocols. > >But the more fundamental issue is that architecture mostly >needs to predate protocol development, like research mostly >needs to predate architecture and protocols. I can not >see a logic that argues we must have an IRTF, but we cannot >have an IATF (Internet Architecture Task Force). The >whole construct of IAB for architecture is weird to me. The "architecture" in the mailing list name is a misnomer. For example, the last longest discussion was about Internet governance instead of architecture. The problem could be the Internet Engineering Task Force if that entity views itself as the supreme body for Internet protocols. >Oh, i think there is a lot of sport in trying to discourage work >that is not officially sponsored by the IETF/IAB authorities >at least from my imited experience. There might be some truth in the above. >We need to be darn careful with every single word we >write about a side meeting. Make sure it is called "non official" >every time you mention it, having people seemingly "borrow" >sign up sheets for examination what could be wrong with them, >ending up with concerns of using the same color (!) as "official" IETF >meeting sign up sheets. Dismissive comments about even doing >a side-meeting, Not being allowed to use IETF tooling >like webex, jabber, wiki, etherpad, and so on. Because using >IETF tools would mean "endorsement of the activity" *sigh*. Stephen expressed his opinion about that. I doubt that we would be encouraging people to be open if we do not allow opinions which might be deemed as politically-incorrect. I don't mind if anyone wishes to hold a side meeting. The tools mentioned above are available to any organization. >This is sad in general, but at a time when it is legally crucial >to make sure all communications is easily recognizeable as >public and published because of the US Govt. export regulations >(see EAR 734.7) it is outright dangerous to make it so difficult >for inofficial side-meetings to use or emulate the >public/published nature of official IETF meetings. If I understood correctly, the rationale for using (IETF) side meetings is that they offer a workaround for U.S. export restrictions. It may be risky to do things like that. Regards, S. Moonesamy From nobody Fri Apr 3 06:02:33 2020 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 D724F3A08AC for ; Fri, 3 Apr 2020 06:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 v5Vgps0g73Ws for ; Fri, 3 Apr 2020 06:02:27 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AD8B3A08B0 for ; Fri, 3 Apr 2020 06:02:26 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 4F942548049; Fri, 3 Apr 2020 15:02:21 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4658E440040; Fri, 3 Apr 2020 15:02:21 +0200 (CEST) Date: Fri, 3 Apr 2020 15:02:21 +0200 From: Toerless Eckert To: John Levine Cc: architecture-discuss@ietf.org Message-ID: <20200403130221.GT28965@faui48f.informatik.uni-erlangen.de> References: <20200403010512.GS28965@faui48f.informatik.uni-erlangen.de> <20200403025551.5D27C16F6977@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200403025551.5D27C16F6977@ary.qy> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] on the nature of architecture discussion (was: Re: [Chirp] Fwd: IETF 107 Vancouver In-Person Meeting Cancelled) 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, 03 Apr 2020 13:02:30 -0000 On Thu, Apr 02, 2020 at 10:55:51PM -0400, John Levine wrote: > In article <20200403010512.GS28965@faui48f.informatik.uni-erlangen.de> you write: > >But the more fundamental issue is that architecture mostly > >needs to predate protocol development, like research mostly > >needs to predate architecture and protocols. > > Not to be unduly snarky, but have we already forgotten about OSI? I thought the plan was that the next person asking this question has to write an RFC comparing TCP/IP with ISO that fairly takes into account the views of proponents of both sides. So, you're going to write that draft ? ;-) From nobody Fri Apr 3 08:11:25 2020 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 7B9EE3A1914 for ; Fri, 3 Apr 2020 08:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 XpgyXgnyoWvq for ; Fri, 3 Apr 2020 08:11:21 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 210D03A190F for ; Fri, 3 Apr 2020 08:11:20 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7897E54804A; Fri, 3 Apr 2020 17:11:15 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 6FB02440040; Fri, 3 Apr 2020 17:11:15 +0200 (CEST) Date: Fri, 3 Apr 2020 17:11:15 +0200 From: Toerless Eckert To: S Moonesamy Cc: architecture-discuss@iab.org Message-ID: <20200403151115.GU28965@faui48f.informatik.uni-erlangen.de> References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> <7de683b6-172b-7e7b-e043-d241804eaa42@nomountain.net> <20200402193430.GQ28965@faui48f.informatik.uni-erlangen.de> <17c21324-4238-9e56-48f2-e6df51967ca2@nomountain.net> <20200403010512.GS28965@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200403042829.11c2a9e0@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20200403042829.11c2a9e0@elandnews.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] on the nature of architecture discussion (was: Re: [Chirp] Fwd: IETF 107 Vancouver In-Person Meeting Cancelled) 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, 03 Apr 2020 15:11:24 -0000 On Fri, Apr 03, 2020 at 05:24:47AM -0700, S Moonesamy wrote: > > We need to be darn careful with every single word we > > write about a side meeting. Make sure it is called "non official" > > every time you mention it, having people seemingly "borrow" > > sign up sheets for examination what could be wrong with them, > > ending up with concerns of using the same color (!) as "official" IETF > > meeting sign up sheets. Dismissive comments about even doing > > a side-meeting, Not being allowed to use IETF tooling > > like webex, jabber, wiki, etherpad, and so on. Because using > > IETF tools would mean "endorsement of the activity" *sigh*. > > Stephen expressed his opinion about that. I doubt that we would be > encouraging people to be open if we do not allow opinions which might be > deemed as politically-incorrect. > > I don't mind if anyone wishes to hold a side meeting. The tools mentioned > above are available to any organization. Right now i have to find and use non-ietf tools to avoid not being in violation with whatever unwritten IETF policy there is. I found these for etherpad, i can pay for webex, it becomes of course annoying with jabber and wiki. I am mostly annoyed by the IMHO illogical nature of the current IESG position that making tooling available, and therefore encouraging more informal discussions in the community is the same as endorsing the payload of that discussion. Especially given how it only applies to the electronic tooling, not the physcial one (rooms). > > This is sad in general, but at a time when it is legally crucial > > to make sure all communications is easily recognizeable as > > public and published because of the US Govt. export regulations > > (see EAR 734.7) it is outright dangerous to make it so difficult > > for inofficial side-meetings to use or emulate the > > public/published nature of official IETF meetings. > > If I understood correctly, the rationale for using (IETF) side meetings is > that they offer a workaround for U.S. export restrictions. It may be risky > to do things like that. Just to be sure my points are not conflated: In the absence of U.S. export restrictions, i would be making exactly the same arguments here wrt. to the problems of doing architecture work in the IETF and the need for using inofficial side-meetings to make technical progress on things not currently well supported by established official IETF structures. I would just leave out the "dangerous" part. EAR 734.7 does not distinguish between official or inofficial meetings, it just talks about published/public exclusions to the scope of the EAR and hence the applicability of the entity list. So, if you follow the words of the regulation, inofficial side-meetings are as much or as little of a workaround as any other IETF or other SDO meetings are. IMHO, whatever the type of meeting is, the main risk is the one of selective investigation and prosecution, something where of course Futurewei has to be a lot more concerned about than any other company. Cheers Toerless > Regards, > S. Moonesamy > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Fri Apr 3 16:41:35 2020 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 8A76A3A10BE for ; Fri, 3 Apr 2020 16:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 FiLlO3-MJCnB for ; Fri, 3 Apr 2020 16:41:27 -0700 (PDT) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 61BBB3A10B7 for ; Fri, 3 Apr 2020 16:41:23 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.126.213]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 033NeqK1023776 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2020 16:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1585957265; x=1586043665; i=@elandsys.com; bh=e8x3KyJK20djrzHy74GMSKCOJ6XaJqx7jSGD9Apvoaw=; h=Date:To:From:Subject:In-Reply-To:References; b=gkSI48rjLqdMB6vChQhCNYpHeZIeOyEuf8JkMOfwNlYDR/4ZcEOwhuOI2RF+qN6UN pviZX0inBBngVZugN9ze+GwE3ppmAOwAxFPUyrh9eEMvyOnuHOM/O+TSX7xWJ6yn3C CO12ru+nfxm+I3nrgp9Kplq/eJbFM6FiR9biMU0M= Message-Id: <6.2.5.6.2.20200403100227.11c1caf0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 03 Apr 2020 16:36:43 -0700 To: Toerless Eckert , architecture-discuss@iab.org From: S Moonesamy In-Reply-To: <20200403151115.GU28965@faui48f.informatik.uni-erlangen.de> References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> <7de683b6-172b-7e7b-e043-d241804eaa42@nomountain.net> <20200402193430.GQ28965@faui48f.informatik.uni-erlangen.de> <17c21324-4238-9e56-48f2-e6df51967ca2@nomountain.net> <20200403010512.GS28965@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200403042829.11c2a9e0@elandnews.com> <20200403151115.GU28965@faui48f.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] on the nature of architecture discussion (was: Re: [Chirp] Fwd: IETF 107 Vancouver In-Person Meeting Cancelled) 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, 03 Apr 2020 23:41:33 -0000 Hi Toerless, At 08:11 AM 03-04-2020, Toerless Eckert wrote: >Right now i have to find and use non-ietf tools to avoid not being >in violation with whatever unwritten IETF policy there is. I found >these for etherpad, i can pay for webex, it becomes of course annoying >with jabber and wiki. > >I am mostly annoyed by the IMHO illogical nature of the current IESG >position that making tooling available, and therefore encouraging >more informal discussions in the community is the same as endorsing >the payload of that discussion. Especially given how it only applies >to the electronic tooling, not the physcial one (rooms). It has been a while since I looked at the meeting room "policy". I am not sure whether it was formalized or whether it is from some discussions about such meetings. I could argue that it should be formalized but then I am not sure whether that would be a good idea. Anyway, that does not solve the problem which you described above. IASA could allow a requester to use idle resources for informal discussions. It would be good if the informality is not debatable. For example, would you ask me to sign a "blue sheet" if we have a discussion in the hallway? >Just to be sure my points are not conflated: Ok. >In the absence of U.S. export restrictions, i would be making >exactly the same arguments here wrt. to the problems of doing >architecture work in the IETF and the need for using inofficial >side-meetings to make technical progress on things not currently >well supported by established official IETF structures. I would >just leave out the "dangerous" part. > >EAR 734.7 does not distinguish between official or inofficial >meetings, it just talks about published/public exclusions to the >scope of the EAR and hence the applicability of the entity list. >So, if you follow the words of the regulation, inofficial >side-meetings are as much or as little of a workaround as >any other IETF or other SDO meetings are. > >IMHO, whatever the type of meeting is, the main risk is the >one of selective investigation and prosecution, something where of course >Futurewei has to be a lot more concerned about than any other >company. I would not look at it as a matter of which entity would be a lot more concerned about. It is better if that does not turn into a concern for the other entity. Regards, S. Moonesamy From nobody Mon Apr 6 06:32:05 2020 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 707773A1DA6 for ; Mon, 6 Apr 2020 06:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=bobbriscoe.net 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 C4SHZWPvR9Aa for ; Mon, 6 Apr 2020 06:29:46 -0700 (PDT) Received: from cl3.bcs-hosting.net (cl3.bcs-hosting.net [3.11.37.202]) (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 E035D3A10B6 for ; Mon, 6 Apr 2020 06:25:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject: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=b10srLvwGUWDkBzvWE+0AxZbsdbfMm1GYZ3brwyxqb8=; b=toSpHPs3gqSbN3gYJzVpj8kbQF fV8DotFEwZqN7b4NXxnfsIZ2WsFk+Y+t3ewPE/ihLiKWj2jQzpcUPvs5MpwJF6i2MFfY3ikP4WiXd oCRNSpOkqvoiZy8yMqbV+6Q8zKgqaKOi+oRb65w/PB/zKt0kaJ1eN2MRqUkadcE7lXRt9fDDrX2Uc 53sgyhl65i0PrJDkJZSzQffCvC8WPm8/rOPX7eVa7Vl1uZzjZHTlxuJSSOZGStnoemhYuYhTGwWeL o2tggz3Jvn/2LczPTPoiRia42B0M8FrAHx0UhDK3OsTU8O31j6y5c0A5T7SVwIW3kEb7DFUT3sWOq 8lGYBC5w==; Received: from [31.185.135.141] (port=33188 helo=[192.168.0.11]) by cl3.bcs-hosting.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1jLRkp-00CJJ4-FE; Mon, 06 Apr 2020 13:25:31 +0000 To: Toerless Eckert , Melinda Shore Cc: architecture-discuss@ietf.org References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> <7de683b6-172b-7e7b-e043-d241804eaa42@nomountain.net> <20200402193430.GQ28965@faui48f.informatik.uni-erlangen.de> <17c21324-4238-9e56-48f2-e6df51967ca2@nomountain.net> <20200403010512.GS28965@faui48f.informatik.uni-erlangen.de> From: Bob Briscoe Message-ID: Date: Mon, 6 Apr 2020 14:25:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20200403010512.GS28965@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cl3.bcs-hosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: cl3.bcs-hosting.net: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: cl3.bcs-hosting.net: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [arch-d] on the nature of architecture discussion 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, 06 Apr 2020 13:30:46 -0000 Toerless, I helped with a series of 'Re-Arch' research workshops from 2008 to 2010. The name was about "re-architecting" the Internet (whatever that means), but the accepted papers included articulation of insights about the existing architecture. I was also involved in various activities before that to promote research investigation into the Internet's architecture. So, based on that experience, here's my 2 penny's worth. You don't want to have "arch-dispatch" sessions too often. Good architectural ideas don't come up that often, so if you create too much space to talk about them, the vacuum will get filled with waffle. Once a year is probably enough. But then, if you detect waffle is starting to fill a vacuum, it's best to back off the timer to biennial. Of course, if some new activity spins out of this (as it sometimes should from an arch-dispatch activity), that takes on a separate existence that is more frequent than the annual cycle of dispatch sessions. You certainly don't want to do this from mic lines. It's too easy for "random-ietf-bigot" to have opinions about architecture that don't add anything (other than for those collecting lists of opinions). Contributors need to have had to do some work, like writing an accepted paper, to even get into the room. It needs to be framed in a context of actionable outcomes. I mean, something like arch-dispatch would be a suitable context, 'cos it gives out the "actionable-only" message. That doesn't preclude "vague thoughts", but only as long as they have the potential to lead to some change that will impact on real life once they firm-up. So, IAB might be a more appropriate context than IRTF, but you want an environment that will attract researchers and thinkers. So the "political officers" need to be in the background managing the process rather than holding the floor. The architecture of such a valuable artefact as the Internet can become highly political. Huge businesses have been built on the Internet's current architecture, with a vested interest for it not to change. One person's architectural improvement is destruction of someone else's business (selling hacks to work round architectural problems is big business). And one progression of changes destroys someone else's idea of how they thought changes would progress. So altho the discussion will often seem academic, the structure in which ideas are taken forward has to be resilient against the wars it might start. That part is much easier said than done. Cheers Bob On 03/04/2020 02:05, Toerless Eckert wrote: > On Thu, Apr 02, 2020 at 11:58:34AM -0800, Melinda Shore wrote: >> On 4/2/20 11:34 AM, Toerless Eckert wrote: >>> Was it only presentations or also associated drafts ? Was the >>> material asked to be make available sufficiently long ago to >>> allow quality updates be prior review ? >> Neither, really. It largely consisted of heated discussions at >> the mike lines. While there were presentations, for the most >> part they were not architectural in nature (with a few notable >> exceptions). > Ok, remembering some bits now. > That was fun, but yes, not what i was thinking of. > >> My sense, from several decades of involvement in the IETF in >> various capacities, is that 1) it would take years to get >> agreement on a diagram of the current internet architecture >> and what you'd end up would be aspirational rather than >> descriptive; > I think we can and are doing descriptive. Most of stackevo > mentioned by you below was descriptive. So are IMHO > many other documents/RFC i would consider to be architectural. > > I can think of aspirational as a good and even necessar thing. > >> 2) architectural discussions in the past have >> had minimal impact on actual protocol design; > That is a very broad statement. We should first have an > unserstanding about what we mean with architecture before > i should even ask you to give me example evidence of this. > > My architecture interests for example are probably a lot lower > inside the machine room of the Internet than e.g. the > Internet BGP peering architecure. But all of it is valid > architecture topics to me. > > For example, i would consider CBOR an example of an > architcure concept (presentation layer) brought into > IETF and protocols. > > One example architecture area of interest for me is the problem that we > are not well enough taking the architecture of routers in to > account for our protocols, or better yet propose to evolve > architecture of both routers and protocols to be better fits in the > future. > > I am betting neither of these topics are what you would > have considered to be architecture in your statement... ?? > >> and 3) complexity >> always wins in the end (the history and output of the NSIS >> working group might be a particularly illustrative example >> of the latter). >> >> Right now, there is nothing stopping anybody from publishing >> drafts and contributing to (or, indeed, leading) architectural >> discussions in IETF working groups. I'm not sure what >> inferences we should make from the fact that for the most part >> that's not happening now. > If architecture can be associated directly with protocols > of an IETF WG, then yes, it could and should happen > in that WG, but i think there are more cases where even > this does not happen. E.g.: I have seen ADs eliminate architecture > from charters because it does not produce implementable protocols. > > But the more fundamental issue is that architecture mostly > needs to predate protocol development, like research mostly > needs to predate architecture and protocols. I can not > see a logic that argues we must have an IRTF, but we cannot > have an IATF (Internet Architecture Task Force). The > whole construct of IAB for architecture is weird to me. > >> I'm skeptical about the actual value of what you're proposing >> but as I said, there's nothing stopping you (or anybody else) >> from starting up something informally, which would give us all >> a better sense of the actual interest level and what the likely >> output would be. > Oh, i think there is a lot of sport in trying to discourage work > that is not officially sponsored by the IETF/IAB authorities > at least from my imited experience. > > We need to be darn careful with every single word we > write about a side meeting. Make sure it is called "non official" > every time you mention it, having people seemingly "borrow" > sign up sheets for examination what could be wrong with them, > ending up with concerns of using the same color (!) as "official" IETF > meeting sign up sheets. Dismissive comments about even doing > a side-meeting, Not being allowed to use IETF tooling > like webex, jabber, wiki, etherpad, and so on. Because using > IETF tools would mean "endorsement of the activity" *sigh*. > > This is sad in general, but at a time when it is legally crucial > to make sure all communications is easily recognizeable as > public and published because of the US Govt. export regulations > (see EAR 734.7) it is outright dangerous to make it so difficult > for inofficial side-meetings to use or emulate the > public/published nature of official IETF meetings. > >> Also, note that there have been IAB programs like stackevo to >> deal with these questions. > Last RFC published in 2016. Concluded in 2019. > Followup to architecture-discuss according to closing mail. > > Cheers > Toerless >> Melinda >> >> >> -- >> Melinda Shore >> melinda.shore@nomountain.net >> >> Software longa, hardware brevis >> > > > >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Mon Apr 6 06:55:00 2020 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 ED92A3A10FE for ; Mon, 6 Apr 2020 06:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 TyEvoN3l2Gfd for ; Mon, 6 Apr 2020 06:54:56 -0700 (PDT) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 74A423A10F7 for ; Mon, 6 Apr 2020 06:54:56 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id c195so89093wme.1 for ; Mon, 06 Apr 2020 06:54:56 -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=JDmYqlofK3yvjvaTOMNe9mN7k1UgMBz+xyFTxPYpOUk=; b=rcHYABxax/xWoe1UlGmn1HTwo9RYguwHL5vjGreXEl1E3Deu8l7I/bZPqizmS1e2KD fvOpQei7jxhbcbPOyfKR7cVIvhFhhZxYxswjjPb56ijUZvSXtsvFWYF+Fo2Sxx/v3ePj QaZZAxwuUIj/HyK2Iy42E/Q1QEqfpN5tUgZ/8xR004Uzw6XPOXAvQeH9BjyhNGGSWq/P MogLQkCO8jnVdDZ2XTfnNA1iDpm87QFsoP/sMFFMLTPmGnBgSubQ9zT8vBFM8iJivhB6 8yzVxGDmaNfTCIqWtGi60rkEXXoqa98Gz372AOexLaoxtBGo1x/JzWD3dk+FQNHx/n+4 Gkfw== 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=JDmYqlofK3yvjvaTOMNe9mN7k1UgMBz+xyFTxPYpOUk=; b=HQggmUR6UxSevhI4xOB7CYJc4XwxVRpjBleseAzhXCpDWpsa+LFBALyQPXAGeEps7D l2PUgR2GslHgQ5Xza+ufbZYM/NIKDiIRiPwdvDfxAHix6/eswxhysYGxh78t3UQNXloj RJAYhguMb00t4S5TBWAJetcuLYynrE4DtTOzFMbIgKRtNNI1YorI+YtgPeY3/MnW7mzu Nd7jMydKftUOPdR8Nj1T8w2yZywXlvOF1ERV+rvA7ocVCh3GFI+Bc0HX4sMD3Fb1Sc22 j4nxah7frfHxwtXQxNYZFpCOQ4q13Okvf7RdAhY1t7pLj7DBOo6cV2YtZDsdjSFX7+yJ Tokw== X-Gm-Message-State: AGi0PubS4fuN5fqwbEZ+OpZwnEfNM2hfrHfABoIoXi2a2FKQuWP9f9nD I4MOKjOigogrd/ApT266dr0= X-Google-Smtp-Source: APiQypI2/TEVFMwiP+t93zxmiogSnB5LhcS7YKMwSt2do10nfNPDAegPoFe0/pejS/lEEQ7A5nTiWA== X-Received: by 2002:a05:600c:2314:: with SMTP id 20mr11306773wmo.35.1586181294911; Mon, 06 Apr 2020 06:54:54 -0700 (PDT) Received: from broadband.bt.com ([2a00:23a8:4140:0:d82c:2aea:7184:f8c8]) by smtp.gmail.com with ESMTPSA id h13sm1237699wru.64.2020.04.06.06.54.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Apr 2020 06:54:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Stewart Bryant In-Reply-To: Date: Mon, 6 Apr 2020 14:54:52 +0100 Cc: Stewart Bryant , Toerless Eckert , Melinda Shore , architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <71362108-53DD-412F-A14D-D7C1CED98C5A@gmail.com> References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> <7de683b6-172b-7e7b-e043-d241804eaa42@nomountain.net> <20200402193430.GQ28965@faui48f.informatik.uni-erlangen.de> <17c21324-4238-9e56-48f2-e6df51967ca2@nomountain.net> <20200403010512.GS28965@faui48f.informatik.uni-erlangen.de> To: Bob Briscoe X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [arch-d] on the nature of architecture discussion 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, 06 Apr 2020 13:54:59 -0000 >=20 > You certainly don't want to do this from mic lines. It's too easy for = "random-ietf-bigot" to have opinions about architecture that don't add = anything (other than for those collecting lists of opinions). = Contributors need to have had to do some work, like writing an accepted = paper, to even get into the room. >=20 Interesting idea, let=E2=80=99s apply that to the IETF sessions as well: = no one can get into the room unless that have published an RFC?=20 On the other hand, perhaps not :) - Stewart From nobody Mon Apr 6 07:54:31 2020 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 517D53A0913 for ; Mon, 6 Apr 2020 07:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 o6eK7-h7GHoT for ; Mon, 6 Apr 2020 07:54:12 -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 B2DDF3A08F0 for ; Mon, 6 Apr 2020 07:53: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: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=a/XIzVyUc5sN3ju5HgMSEHLgmtbudm72O/qOBxGWZ80=; b=FTdxejKUphL1l9YJXhKH3y4lz Ytz6zFqsPaucsqERzOGaVcdVFk6OiLhWHbegGyIxUhi+0gT5SwKsU+kQ7BuKldkE6vXAnYMtk2z4g VC/YdiUrY+3O6VtViy3A2U8s7QgiTu2XzNi1BLgUWs8vDxsaQwLYab7mv/HdBJ9S2n7H+UABFIV/h ER6glHtUbX/GYbI68WfyiPC2aeFigYQZS+6rNejmP/YlumFPTrqTQDL3a4XvuYSDLnSTywSkF7eVV 0Q5erXdeaEVYR9DylIi4Lej4bw0x+DGXdokitbN4Hmq0N0nYenYU8oDFED40Ky8Rsr2oCtkK5ZxyT MDOV0cnWw==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:52259 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jLT8L-000TZu-WB; Mon, 06 Apr 2020 10:53:58 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_E4324B53-D499-4CEF-96B4-F8F46DF4BC49" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) From: Joseph Touch In-Reply-To: Date: Mon, 6 Apr 2020 07:53:52 -0700 Cc: Toerless Eckert , Melinda Shore , architecture-discuss@ietf.org Message-Id: <11365E40-37D2-4A12-AFB0-54F03C9C6C5D@strayalpha.com> References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> <7de683b6-172b-7e7b-e043-d241804eaa42@nomountain.net> <20200402193430.GQ28965@faui48f.informatik.uni-erlangen.de> <17c21324-4238-9e56-48f2-e6df51967ca2@nomountain.net> <20200403010512.GS28965@faui48f.informatik.uni-erlangen.de> To: Bob Briscoe X-Mailer: Apple Mail (2.3445.9.5) 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 - ietf.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] on the nature of architecture discussion 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, 06 Apr 2020 14:54:13 -0000 --Apple-Mail=_E4324B53-D499-4CEF-96B4-F8F46DF4BC49 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 6, 2020, at 6:25 AM, Bob Briscoe wrote: >=20 > You certainly don't want to do this from mic lines. It's too easy for = "random-ietf-bigot" to have opinions about architecture that don't add = anything (other than for those collecting lists of opinions). = Contributors need to have had to do some work, like writing an accepted = paper, to even get into the room. In various areas, that=E2=80=99s called an echo chamber (or worse). There are conferences with that reputation too; let=E2=80=99s not aspire = to that. Joe --Apple-Mail=_E4324B53-D499-4CEF-96B4-F8F46DF4BC49 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 6, 2020, at 6:25 AM, Bob Briscoe <ietf@bobbriscoe.net>= wrote:

You certainly don't want to do = this from mic lines. It's too easy for "random-ietf-bigot" to have = opinions about architecture that don't add anything (other than for = those collecting lists of opinions). Contributors need to have had to do = some work, like writing an accepted paper, to even get into the = room.

In various areas, that=E2=80=99s called an echo chamber (or = worse).

There = are conferences with that reputation too; let=E2=80=99s not aspire to = that.

Joe


= --Apple-Mail=_E4324B53-D499-4CEF-96B4-F8F46DF4BC49-- From nobody Mon Apr 6 08:51:59 2020 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 772073A0B36 for ; Mon, 6 Apr 2020 08:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 yQEHB1PyAQvy for ; Mon, 6 Apr 2020 08:51:41 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00FD53A0B2D for ; Mon, 6 Apr 2020 08:51:40 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 1D693548042; Mon, 6 Apr 2020 17:51:34 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 1479A440040; Mon, 6 Apr 2020 17:51:34 +0200 (CEST) Date: Mon, 6 Apr 2020 17:51:34 +0200 From: Toerless Eckert To: Bob Briscoe Cc: Melinda Shore , architecture-discuss@ietf.org Message-ID: <20200406155134.GH28965@faui48f.informatik.uni-erlangen.de> References: <158386742797.16091.1025684270011519738@ietfa.amsl.com> <20200402152717.GK28965@faui48f.informatik.uni-erlangen.de> <7de683b6-172b-7e7b-e043-d241804eaa42@nomountain.net> <20200402193430.GQ28965@faui48f.informatik.uni-erlangen.de> <17c21324-4238-9e56-48f2-e6df51967ca2@nomountain.net> <20200403010512.GS28965@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] on the nature of architecture discussion 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, 06 Apr 2020 15:51:44 -0000 Thanks for your insight, Bob I don't think we do disagree too much except for the benefit of regular frequency of having these "open" or "dispatch" style meeting. But as i think i pointed out in other emails, i can think of a lot more architectural aspects to be in scope than the whole "overall Internet architecture". The main issue really is that i think you need to keep an effort like this running at maybe low flame for a while before possible contributors will find opportunities to do something. Even if it is more documenting uncontentuous BCPs or informational text around architecture topics. Of course, you can not only have soapbox discussions, but it would really be a lot of fun to have some amount of soapbox microphone lines and then punish that by asking for it to be written down, and actually tracking whether it was and rejecting further soapboxing until it does get written down. Or any other strategies to actually foster useful output. Catch the people where they are (bitching) and redirect to something productive ;-) Cheers Toerless On Mon, Apr 06, 2020 at 02:25:31PM +0100, Bob Briscoe wrote: > Toerless, > > I helped with a series of 'Re-Arch' research workshops from 2008 to 2010. > The name was about "re-architecting" the Internet (whatever that means), but > the accepted papers included articulation of insights about the existing > architecture. I was also involved in various activities before that to > promote research investigation into the Internet's architecture. So, based > on that experience, here's my 2 penny's worth. > > You don't want to have "arch-dispatch" sessions too often. Good > architectural ideas don't come up that often, so if you create too much > space to talk about them, the vacuum will get filled with waffle. Once a > year is probably enough. But then, if you detect waffle is starting to fill > a vacuum, it's best to back off the timer to biennial. Of course, if some > new activity spins out of this (as it sometimes should from an arch-dispatch > activity), that takes on a separate existence that is more frequent than the > annual cycle of dispatch sessions. > > You certainly don't want to do this from mic lines. It's too easy for > "random-ietf-bigot" to have opinions about architecture that don't add > anything (other than for those collecting lists of opinions). Contributors > need to have had to do some work, like writing an accepted paper, to even > get into the room. > > It needs to be framed in a context of actionable outcomes. I mean, something > like arch-dispatch would be a suitable context, 'cos it gives out the > "actionable-only" message. That doesn't preclude "vague thoughts", but only > as long as they have the potential to lead to some change that will impact > on real life once they firm-up. > > So, IAB might be a more appropriate context than IRTF, but you want an > environment that will attract researchers and thinkers. So the "political > officers" need to be in the background managing the process rather than > holding the floor. > > The architecture of such a valuable artefact as the Internet can become > highly political. Huge businesses have been built on the Internet's current > architecture, with a vested interest for it not to change. One person's > architectural improvement is destruction of someone else's business (selling > hacks to work round architectural problems is big business). And one > progression of changes destroys someone else's idea of how they thought > changes would progress. So altho the discussion will often seem academic, > the structure in which ideas are taken forward has to be resilient against > the wars it might start. That part is much easier said than done. > > Cheers > > > Bob > > On 03/04/2020 02:05, Toerless Eckert wrote: > > On Thu, Apr 02, 2020 at 11:58:34AM -0800, Melinda Shore wrote: > > > On 4/2/20 11:34 AM, Toerless Eckert wrote: > > > > Was it only presentations or also associated drafts ? Was the > > > > material asked to be make available sufficiently long ago to > > > > allow quality updates be prior review ? > > > Neither, really. It largely consisted of heated discussions at > > > the mike lines. While there were presentations, for the most > > > part they were not architectural in nature (with a few notable > > > exceptions). > > Ok, remembering some bits now. > > That was fun, but yes, not what i was thinking of. > > > > > My sense, from several decades of involvement in the IETF in > > > various capacities, is that 1) it would take years to get > > > agreement on a diagram of the current internet architecture > > > and what you'd end up would be aspirational rather than > > > descriptive; > > I think we can and are doing descriptive. Most of stackevo > > mentioned by you below was descriptive. So are IMHO > > many other documents/RFC i would consider to be architectural. > > > > I can think of aspirational as a good and even necessar thing. > > > > > 2) architectural discussions in the past have > > > had minimal impact on actual protocol design; > > That is a very broad statement. We should first have an > > unserstanding about what we mean with architecture before > > i should even ask you to give me example evidence of this. > > > > My architecture interests for example are probably a lot lower > > inside the machine room of the Internet than e.g. the > > Internet BGP peering architecure. But all of it is valid > > architecture topics to me. > > > > For example, i would consider CBOR an example of an > > architcure concept (presentation layer) brought into > > IETF and protocols. > > > > One example architecture area of interest for me is the problem that we > > are not well enough taking the architecture of routers in to > > account for our protocols, or better yet propose to evolve > > architecture of both routers and protocols to be better fits in the > > future. > > > > I am betting neither of these topics are what you would > > have considered to be architecture in your statement... ?? > > > > > and 3) complexity > > > always wins in the end (the history and output of the NSIS > > > working group might be a particularly illustrative example > > > of the latter). > > > > > > Right now, there is nothing stopping anybody from publishing > > > drafts and contributing to (or, indeed, leading) architectural > > > discussions in IETF working groups. I'm not sure what > > > inferences we should make from the fact that for the most part > > > that's not happening now. > > If architecture can be associated directly with protocols > > of an IETF WG, then yes, it could and should happen > > in that WG, but i think there are more cases where even > > this does not happen. E.g.: I have seen ADs eliminate architecture > > from charters because it does not produce implementable protocols. > > > > But the more fundamental issue is that architecture mostly > > needs to predate protocol development, like research mostly > > needs to predate architecture and protocols. I can not > > see a logic that argues we must have an IRTF, but we cannot > > have an IATF (Internet Architecture Task Force). The > > whole construct of IAB for architecture is weird to me. > > > > > I'm skeptical about the actual value of what you're proposing > > > but as I said, there's nothing stopping you (or anybody else) > > > from starting up something informally, which would give us all > > > a better sense of the actual interest level and what the likely > > > output would be. > > Oh, i think there is a lot of sport in trying to discourage work > > that is not officially sponsored by the IETF/IAB authorities > > at least from my imited experience. > > > > We need to be darn careful with every single word we > > write about a side meeting. Make sure it is called "non official" > > every time you mention it, having people seemingly "borrow" > > sign up sheets for examination what could be wrong with them, > > ending up with concerns of using the same color (!) as "official" IETF > > meeting sign up sheets. Dismissive comments about even doing > > a side-meeting, Not being allowed to use IETF tooling > > like webex, jabber, wiki, etherpad, and so on. Because using > > IETF tools would mean "endorsement of the activity" *sigh*. > > > > This is sad in general, but at a time when it is legally crucial > > to make sure all communications is easily recognizeable as > > public and published because of the US Govt. export regulations > > (see EAR 734.7) it is outright dangerous to make it so difficult > > for inofficial side-meetings to use or emulate the > > public/published nature of official IETF meetings. > > > > > Also, note that there have been IAB programs like stackevo to > > > deal with these questions. > > Last RFC published in 2016. Concluded in 2019. > > Followup to architecture-discuss according to closing mail. > > > > Cheers > > Toerless > > > Melinda > > > > > > > > > -- > > > Melinda Shore > > > melinda.shore@nomountain.net > > > > > > Software longa, hardware brevis > > > > > > > > > > > > _______________________________________________ > > > Architecture-discuss mailing list > > > Architecture-discuss@ietf.org > > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Mon Apr 6 09:04:03 2020 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 723C23A0C57 for ; Mon, 6 Apr 2020 09:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 ye1gFoSVCJ7z for ; Mon, 6 Apr 2020 09:03:34 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E3E3A0C61 for ; Mon, 6 Apr 2020 09:03:30 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 891B5548042; Mon, 6 Apr 2020 18:03:25 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 800ED440040; Mon, 6 Apr 2020 18:03:25 +0200 (CEST) Date: Mon, 6 Apr 2020 18:03:25 +0200 From: Toerless Eckert To: Bob Briscoe Cc: Melinda Shore , architecture-discuss@ietf.org Message-ID: <20200406160325.GI28965@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [arch-d] Programmable forwarding plane discussions ? (was: Re: on the nature of architecture discussion) 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, 06 Apr 2020 16:03:42 -0000 To give one example aspect of what i would think of as a part of the architecture: Discussions about pogrammable forwarding planes. We had one talk/presentation last year sponsored by IESG talking about forwarding planes. And i think we did already see some good disagrement (discussion starter) about how flexible or inflexible we should consider them to be now or how much they could be more flexible in the future. I for once think that wee could promote for them to be more flexible if we would start getting our heads around this and maybe start writing up insights and expectations. There are several attendees whose organizations have collected experiences with options such as P4, FPGA or fd.io. But we have no forum whatsoever to discuss those programmable forwarding plane aspects. Heck, i am sure there would be interest for IETF participants interested in this topic to contribute educational insight, summaries of experiences, and thoughts about gaps that should and could be closed. I for once am of the firm believ that the degree of innovation on any platform is proportional to the degree of flexible programmability by third parties. See VNF/NFV in data centers versus ossification in gigabit switching in the WAN. But once we get to those forwarding planes, i think freely programmable can not mean x.86 style, but it does need to mean something beyond P4, and it does IMHO also mean that we have to do reusable extensible protocols or else we can not have virtual programmed networks due to lack of code space. Etc. pp... So, why don't we even have a mailing list for such discussions ? Yes, fragementing into many mailing lists has downsides, but most people here (beside probbly myself) would have likely not thought about forwarding plane architectures when they joined architecture-discuss, so having a more specific mailing list and promoting it might help to even attract the interested community. Of course, anything IETF organization would be easier if there was a sponsor in leadership. And even for a mailing list, such a sponsor is mandatory. Cheers Toerless On Mon, Apr 06, 2020 at 02:25:31PM +0100, Bob Briscoe wrote: > Toerless, > > I helped with a series of 'Re-Arch' research workshops from 2008 to 2010. > The name was about "re-architecting" the Internet (whatever that means), but > the accepted papers included articulation of insights about the existing > architecture. I was also involved in various activities before that to > promote research investigation into the Internet's architecture. So, based > on that experience, here's my 2 penny's worth. > > You don't want to have "arch-dispatch" sessions too often. Good > architectural ideas don't come up that often, so if you create too much > space to talk about them, the vacuum will get filled with waffle. Once a > year is probably enough. But then, if you detect waffle is starting to fill > a vacuum, it's best to back off the timer to biennial. Of course, if some > new activity spins out of this (as it sometimes should from an arch-dispatch > activity), that takes on a separate existence that is more frequent than the > annual cycle of dispatch sessions. > > You certainly don't want to do this from mic lines. It's too easy for > "random-ietf-bigot" to have opinions about architecture that don't add > anything (other than for those collecting lists of opinions). Contributors > need to have had to do some work, like writing an accepted paper, to even > get into the room. > > It needs to be framed in a context of actionable outcomes. I mean, something > like arch-dispatch would be a suitable context, 'cos it gives out the > "actionable-only" message. That doesn't preclude "vague thoughts", but only > as long as they have the potential to lead to some change that will impact > on real life once they firm-up. > > So, IAB might be a more appropriate context than IRTF, but you want an > environment that will attract researchers and thinkers. So the "political > officers" need to be in the background managing the process rather than > holding the floor. > > The architecture of such a valuable artefact as the Internet can become > highly political. Huge businesses have been built on the Internet's current > architecture, with a vested interest for it not to change. One person's > architectural improvement is destruction of someone else's business (selling > hacks to work round architectural problems is big business). And one > progression of changes destroys someone else's idea of how they thought > changes would progress. So altho the discussion will often seem academic, > the structure in which ideas are taken forward has to be resilient against > the wars it might start. That part is much easier said than done. > > Cheers > > > Bob > > On 03/04/2020 02:05, Toerless Eckert wrote: > > On Thu, Apr 02, 2020 at 11:58:34AM -0800, Melinda Shore wrote: > > > On 4/2/20 11:34 AM, Toerless Eckert wrote: > > > > Was it only presentations or also associated drafts ? Was the > > > > material asked to be make available sufficiently long ago to > > > > allow quality updates be prior review ? > > > Neither, really. It largely consisted of heated discussions at > > > the mike lines. While there were presentations, for the most > > > part they were not architectural in nature (with a few notable > > > exceptions). > > Ok, remembering some bits now. > > That was fun, but yes, not what i was thinking of. > > > > > My sense, from several decades of involvement in the IETF in > > > various capacities, is that 1) it would take years to get > > > agreement on a diagram of the current internet architecture > > > and what you'd end up would be aspirational rather than > > > descriptive; > > I think we can and are doing descriptive. Most of stackevo > > mentioned by you below was descriptive. So are IMHO > > many other documents/RFC i would consider to be architectural. > > > > I can think of aspirational as a good and even necessar thing. > > > > > 2) architectural discussions in the past have > > > had minimal impact on actual protocol design; > > That is a very broad statement. We should first have an > > unserstanding about what we mean with architecture before > > i should even ask you to give me example evidence of this. > > > > My architecture interests for example are probably a lot lower > > inside the machine room of the Internet than e.g. the > > Internet BGP peering architecure. But all of it is valid > > architecture topics to me. > > > > For example, i would consider CBOR an example of an > > architcure concept (presentation layer) brought into > > IETF and protocols. > > > > One example architecture area of interest for me is the problem that we > > are not well enough taking the architecture of routers in to > > account for our protocols, or better yet propose to evolve > > architecture of both routers and protocols to be better fits in the > > future. > > > > I am betting neither of these topics are what you would > > have considered to be architecture in your statement... ?? > > > > > and 3) complexity > > > always wins in the end (the history and output of the NSIS > > > working group might be a particularly illustrative example > > > of the latter). > > > > > > Right now, there is nothing stopping anybody from publishing > > > drafts and contributing to (or, indeed, leading) architectural > > > discussions in IETF working groups. I'm not sure what > > > inferences we should make from the fact that for the most part > > > that's not happening now. > > If architecture can be associated directly with protocols > > of an IETF WG, then yes, it could and should happen > > in that WG, but i think there are more cases where even > > this does not happen. E.g.: I have seen ADs eliminate architecture > > from charters because it does not produce implementable protocols. > > > > But the more fundamental issue is that architecture mostly > > needs to predate protocol development, like research mostly > > needs to predate architecture and protocols. I can not > > see a logic that argues we must have an IRTF, but we cannot > > have an IATF (Internet Architecture Task Force). The > > whole construct of IAB for architecture is weird to me. > > > > > I'm skeptical about the actual value of what you're proposing > > > but as I said, there's nothing stopping you (or anybody else) > > > from starting up something informally, which would give us all > > > a better sense of the actual interest level and what the likely > > > output would be. > > Oh, i think there is a lot of sport in trying to discourage work > > that is not officially sponsored by the IETF/IAB authorities > > at least from my imited experience. > > > > We need to be darn careful with every single word we > > write about a side meeting. Make sure it is called "non official" > > every time you mention it, having people seemingly "borrow" > > sign up sheets for examination what could be wrong with them, > > ending up with concerns of using the same color (!) as "official" IETF > > meeting sign up sheets. Dismissive comments about even doing > > a side-meeting, Not being allowed to use IETF tooling > > like webex, jabber, wiki, etherpad, and so on. Because using > > IETF tools would mean "endorsement of the activity" *sigh*. > > > > This is sad in general, but at a time when it is legally crucial > > to make sure all communications is easily recognizeable as > > public and published because of the US Govt. export regulations > > (see EAR 734.7) it is outright dangerous to make it so difficult > > for inofficial side-meetings to use or emulate the > > public/published nature of official IETF meetings. > > > > > Also, note that there have been IAB programs like stackevo to > > > deal with these questions. > > Last RFC published in 2016. Concluded in 2019. > > Followup to architecture-discuss according to closing mail. > > > > Cheers > > Toerless > > > Melinda > > > > > > > > > -- > > > Melinda Shore > > > melinda.shore@nomountain.net > > > > > > Software longa, hardware brevis > > > > > > > > > > > > _______________________________________________ > > > Architecture-discuss mailing list > > > Architecture-discuss@ietf.org > > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Mon Apr 6 10:10:40 2020 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 EBD133A0B67 for ; Mon, 6 Apr 2020 10:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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=mjmontpetit-com.20150623.gappssmtp.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 tjwx8uEGklEv for ; Mon, 6 Apr 2020 10:10:17 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 860263A0BA6 for ; Mon, 6 Apr 2020 10:10:16 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id 19so485837ljj.7 for ; Mon, 06 Apr 2020 10:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=T1Llbm4p2wtz1LstXrYRv5cwipk3OfLM2nEKFooXvgA=; b=VNDBYhcBaD9Olrk4eZCxH2wNwVl9Gs+5+TJCarbijONmsKhTl5kH6r6lv6cVJe7D29 cszVL5IjTft3//JSjR2pF+2xFqrFmwvKMZJxTYRVrlymtrqck1S56fv+jIUOadbvtaOi urgoz9CkXt9y7Ji3y7CI47EwzD0+SlbL6h0YFU2WyQFomwsZmKXnH4OdElJ28KNDCocc +yGoq0+AOe1FeRTT1TSIuzJu1TnlVY1Xz5eUre7a5wpBHHLkt9iqvIS55X3Sv5ix7uys IeLLqVDiLaolryXxgPce78JUZLP9AxglGvkaCU3srafrJyoICioHyvu//6LEVQN0GRay cKHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=T1Llbm4p2wtz1LstXrYRv5cwipk3OfLM2nEKFooXvgA=; b=CwKSMbFzwZQbje6JZFi7qJO96P7k1rvMVHwyymMuTuYfisnhk8S8ougvFomIKeVtVH DubGzzSgRWcJGq8Ez5C4IoqiZIBcqjy0QRrDCq0aK/aQissEm+8DkhEYPw7JgDRx8f/d ze6NJiB7mSoXj+LNrbClNYijeqcdg8DNvQHLFeYxU4eAnoUjEFFgY0byPJKR+kvkRYa9 uYIoYoaUv9K7iJcE4A7f4J9Q5amIY8LKfgp1Np/gwPWxN18lyzWdl37qCviPW9+I+3ox 4wLLdrT/UN+oJSmoIOvPCq/Rnjh0ZXL0ak5KYEbaO2rVF2WZW8/xjC+4UIOhszBJaomx Kovg== X-Gm-Message-State: AGi0PuYBr4TMmuKArltGJteXIALguollOsECE14N34l/pqQdm5nB25w8 NWRT3fMnT3qeQyOkIpL2hEAEt2ReEr3IrPVwdVSk99lLYBc= X-Google-Smtp-Source: APiQypKW3wFz8INhNpHsvvrl8yb627GMZC2NW+KHrKMOWqiC1tqehaGudYL+uQ/WsPV9L2qbOxgtigVn9rbW51e7lq0= X-Received: by 2002:a2e:b5bc:: with SMTP id f28mr141803ljn.191.1586193014416; Mon, 06 Apr 2020 10:10:14 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 6 Apr 2020 10:10:13 -0700 From: Marie-Jose Montpetit In-Reply-To: <20200406160325.GI28965@faui48f.informatik.uni-erlangen.de> References: <20200406160325.GI28965@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Date: Mon, 6 Apr 2020 10:10:13 -0700 Message-ID: To: Bob Briscoe , Toerless Eckert Cc: architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="0000000000002bbd2a05a2a25753" Archived-At: Subject: Re: [arch-d] Programmable forwarding plane discussions ? (was: Re: on the nature of architecture discussion) 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, 06 Apr 2020 17:10:20 -0000 --0000000000002bbd2a05a2a25753 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There is a IRTF RG on programmable forwarding planes: COINRG. And we have an active mailing list and an interim tomorrow if you want to participate. mjm Marie-Jos=C3=A9 Montpetit, Ph.D. marie@mjmontpetit.com On April 6, 2020 at 12:06:07 PM, Toerless Eckert (tte@cs.fau.de) wrote: To give one example aspect of what i would think of as a part of the architecture: Discussions about pogrammable forwarding planes. We had one talk/presentation last year sponsored by IESG talking about forwarding planes. And i think we did already see some good disagrement (discussion starter) about how flexible or inflexible we should consider them to be now or how much they could be more flexible in the future. I for once think that wee could promote for them to be more flexible if we would start getting our heads around this and maybe start writing up insights and expectations. There are several attendees whose organizations have collected experiences with options such as P4, FPGA or fd.io. But we have no forum whatsoever to discuss those programmable forwarding plane aspects. Heck, i am sure there would be interest for IETF participants interested in this topic to contribute educational insight, summaries of experiences, and thoughts about gaps that should and could be closed. I for once am of the firm believ that the degree of innovation on any platform is proportional to the degree of flexible programmability by third parties. See VNF/NFV in data centers versus ossification in gigabit switching in the WAN. But once we get to those forwarding planes, i think freely programmable can not mean x.86 style, but it does need to mean something beyond P4, and it does IMHO also mean that we have to do reusable extensible protocols or else we can not have virtual programmed networks due to lack of code space. Etc. pp... So, why don't we even have a mailing list for such discussions ? Yes, fragementing into many mailing lists has downsides, but most people here (beside probbly myself) would have likely not thought about forwarding plane architectures when they joined architecture-discuss, so having a more specific mailing list and promoting it might help to even attract the interested community. Of course, anything IETF organization would be easier if there was a sponsor in leadership. And even for a mailing list, such a sponsor is mandatory. Cheers Toerless On Mon, Apr 06, 2020 at 02:25:31PM +0100, Bob Briscoe wrote: > Toerless, > > I helped with a series of 'Re-Arch' research workshops from 2008 to 2010. > The name was about "re-architecting" the Internet (whatever that means), but > the accepted papers included articulation of insights about the existing > architecture. I was also involved in various activities before that to > promote research investigation into the Internet's architecture. So, based > on that experience, here's my 2 penny's worth. > > You don't want to have "arch-dispatch" sessions too often. Good > architectural ideas don't come up that often, so if you create too much > space to talk about them, the vacuum will get filled with waffle. Once a > year is probably enough. But then, if you detect waffle is starting to fill > a vacuum, it's best to back off the timer to biennial. Of course, if some > new activity spins out of this (as it sometimes should from an arch-dispatch > activity), that takes on a separate existence that is more frequent than the > annual cycle of dispatch sessions. > > You certainly don't want to do this from mic lines. It's too easy for > "random-ietf-bigot" to have opinions about architecture that don't add > anything (other than for those collecting lists of opinions). Contributors > need to have had to do some work, like writing an accepted paper, to even > get into the room. > > It needs to be framed in a context of actionable outcomes. I mean, something > like arch-dispatch would be a suitable context, 'cos it gives out the > "actionable-only" message. That doesn't preclude "vague thoughts", but only > as long as they have the potential to lead to some change that will impact > on real life once they firm-up. > > So, IAB might be a more appropriate context than IRTF, but you want an > environment that will attract researchers and thinkers. So the "political > officers" need to be in the background managing the process rather than > holding the floor. > > The architecture of such a valuable artefact as the Internet can become > highly political. Huge businesses have been built on the Internet's current > architecture, with a vested interest for it not to change. One person's > architectural improvement is destruction of someone else's business (selling > hacks to work round architectural problems is big business). And one > progression of changes destroys someone else's idea of how they thought > changes would progress. So altho the discussion will often seem academic, > the structure in which ideas are taken forward has to be resilient against > the wars it might start. That part is much easier said than done. > > Cheers > > > Bob > > On 03/04/2020 02:05, Toerless Eckert wrote: > > On Thu, Apr 02, 2020 at 11:58:34AM -0800, Melinda Shore wrote: > > > On 4/2/20 11:34 AM, Toerless Eckert wrote: > > > > Was it only presentations or also associated drafts ? Was the > > > > material asked to be make available sufficiently long ago to > > > > allow quality updates be prior review ? > > > Neither, really. It largely consisted of heated discussions at > > > the mike lines. While there were presentations, for the most > > > part they were not architectural in nature (with a few notable > > > exceptions). > > Ok, remembering some bits now. > > That was fun, but yes, not what i was thinking of. > > > > > My sense, from several decades of involvement in the IETF in > > > various capacities, is that 1) it would take years to get > > > agreement on a diagram of the current internet architecture > > > and what you'd end up would be aspirational rather than > > > descriptive; > > I think we can and are doing descriptive. Most of stackevo > > mentioned by you below was descriptive. So are IMHO > > many other documents/RFC i would consider to be architectural. > > > > I can think of aspirational as a good and even necessar thing. > > > > > 2) architectural discussions in the past have > > > had minimal impact on actual protocol design; > > That is a very broad statement. We should first have an > > unserstanding about what we mean with architecture before > > i should even ask you to give me example evidence of this. > > > > My architecture interests for example are probably a lot lower > > inside the machine room of the Internet than e.g. the > > Internet BGP peering architecure. But all of it is valid > > architecture topics to me. > > > > For example, i would consider CBOR an example of an > > architcure concept (presentation layer) brought into > > IETF and protocols. > > > > One example architecture area of interest for me is the problem that we > > are not well enough taking the architecture of routers in to > > account for our protocols, or better yet propose to evolve > > architecture of both routers and protocols to be better fits in the > > future. > > > > I am betting neither of these topics are what you would > > have considered to be architecture in your statement... ?? > > > > > and 3) complexity > > > always wins in the end (the history and output of the NSIS > > > working group might be a particularly illustrative example > > > of the latter). > > > > > > Right now, there is nothing stopping anybody from publishing > > > drafts and contributing to (or, indeed, leading) architectural > > > discussions in IETF working groups. I'm not sure what > > > inferences we should make from the fact that for the most part > > > that's not happening now. > > If architecture can be associated directly with protocols > > of an IETF WG, then yes, it could and should happen > > in that WG, but i think there are more cases where even > > this does not happen. E.g.: I have seen ADs eliminate architecture > > from charters because it does not produce implementable protocols. > > > > But the more fundamental issue is that architecture mostly > > needs to predate protocol development, like research mostly > > needs to predate architecture and protocols. I can not > > see a logic that argues we must have an IRTF, but we cannot > > have an IATF (Internet Architecture Task Force). The > > whole construct of IAB for architecture is weird to me. > > > > > I'm skeptical about the actual value of what you're proposing > > > but as I said, there's nothing stopping you (or anybody else) > > > from starting up something informally, which would give us all > > > a better sense of the actual interest level and what the likely > > > output would be. > > Oh, i think there is a lot of sport in trying to discourage work > > that is not officially sponsored by the IETF/IAB authorities > > at least from my imited experience. > > > > We need to be darn careful with every single word we > > write about a side meeting. Make sure it is called "non official" > > every time you mention it, having people seemingly "borrow" > > sign up sheets for examination what could be wrong with them, > > ending up with concerns of using the same color (!) as "official" IETF > > meeting sign up sheets. Dismissive comments about even doing > > a side-meeting, Not being allowed to use IETF tooling > > like webex, jabber, wiki, etherpad, and so on. Because using > > IETF tools would mean "endorsement of the activity" *sigh*. > > > > This is sad in general, but at a time when it is legally crucial > > to make sure all communications is easily recognizeable as > > public and published because of the US Govt. export regulations > > (see EAR 734.7) it is outright dangerous to make it so difficult > > for inofficial side-meetings to use or emulate the > > public/published nature of official IETF meetings. > > > > > Also, note that there have been IAB programs like stackevo to > > > deal with these questions. > > Last RFC published in 2016. Concluded in 2019. > > Followup to architecture-discuss according to closing mail. > > > > Cheers > > Toerless > > > Melinda > > > > > > > > > -- > > > Melinda Shore > > > melinda.shore@nomountain.net > > > > > > Software longa, hardware brevis > > > > > > > > > > > > _______________________________________________ > > > Architecture-discuss mailing list > > > Architecture-discuss@ietf.org > > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss --=20 --- tte@cs.fau.de _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www.ietf.org/mailman/listinfo/architecture-discuss --0000000000002bbd2a05a2a25753 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Ther= e is a IRTF RG on programmable forwarding planes: COINRG.

And we have an active mailing list= and an interim tomorrow if you want to participate.

mjm

Marie-Jos=C3=A9 Montpetit, Ph.D.

On April 6, 2020 at 12:06:07 PM, To= erless Eckert (tte@cs.fau.de) wrote:

= To give one example aspect of what i would think of as a part
of the architecture: Discussions about pogrammable forwarding planes.

We had one talk/presentation last year sponsored by IESG talking about
forwarding planes. And i think we did already see some good disagrement
(discussion starter) about how flexible or inflexible we should conside= r
them to be now or how much they could be more flexible in the future.
I for once think that wee could promote for them to be more flexible
if we would start getting our heads around this and maybe start writing
up insights and expectations.

There are several attendees whose organizations have collected
experiences with options such as P4, FPGA or f= d.io. But we have
no forum whatsoever to discuss those programmable forwarding plane
aspects. Heck, i am sure there would be interest for IETF participants
interested in this topic to contribute educational insight, summaries
of experiences, and thoughts about gaps that should and could be
closed.

I for once am of the firm believ that the degree of innovation on any
platform is proportional to the degree of flexible programmability
by third parties. See VNF/NFV in data centers versus ossification in
gigabit switching in the WAN. But once we get to those forwarding
planes, i think freely programmable can not mean x.86 style, but
it does need to mean something beyond P4, and it does IMHO also
mean that we have to do reusable extensible protocols or else we
can not have virtual programmed networks due to lack of code space.
Etc. pp...

So, why don't we even have a mailing list for such discussions ?
Yes, fragementing into many mailing lists has downsides, but most peopl= e
here (beside probbly myself) would have likely not thought about
forwarding plane architectures when they joined architecture-discuss,
so having a more specific mailing list and promoting it might help
to even attract the interested community.

Of course, anything IETF organization would be easier if there was
a sponsor in leadership. And even for a mailing list, such a sponsor
is mandatory.

Cheers
Toerless

On Mon, Apr 06, 2020 at 02:25:31PM +0100, Bob Briscoe wrote:
> Toerless,
> =20
> I helped with a series of 'Re-Arch' research workshops fro= m 2008 to 2010.
> The name was about "re-architecting" the Internet (whate= ver that means), but
> the accepted papers included articulation of insights about the ex= isting
> architecture. I was also involved in various activities before tha= t to
> promote research investigation into the Internet's architectur= e. So, based
> on that experience, here's my 2 penny's worth.
> =20
> You don't want to have "arch-dispatch" sessions too = often. Good
> architectural ideas don't come up that often, so if you create= too much
> space to talk about them, the vacuum will get filled with waffle. = Once a
> year is probably enough. But then, if you detect waffle is startin= g to fill
> a vacuum, it's best to back off the timer to biennial. Of cour= se, if some
> new activity spins out of this (as it sometimes should from an arc= h-dispatch
> activity), that takes on a separate existence that is more frequen= t than the
> annual cycle of dispatch sessions.
> =20
> You certainly don't want to do this from mic lines. It's t= oo easy for
> "random-ietf-bigot" to have opinions about architecture = that don't add
> anything (other than for those collecting lists of opinions). Cont= ributors
> need to have had to do some work, like writing an accepted paper, = to even
> get into the room.
> =20
> It needs to be framed in a context of actionable outcomes. I mean,= something
> like arch-dispatch would be a suitable context, 'cos it gives = out the
> "actionable-only" message. That doesn't preclude &qu= ot;vague thoughts", but only
> as long as they have the potential to lead to some change that wil= l impact
> on real life once they firm-up.
> =20
> So, IAB might be a more appropriate context than IRTF, but you wan= t an
> environment that will attract researchers and thinkers. So the &qu= ot;political
> officers" need to be in the background managing the process r= ather than
> holding the floor.
> =20
> The architecture of such a valuable artefact as the Internet can b= ecome
> highly political. Huge businesses have been built on the Internet&= #39;s current
> architecture, with a vested interest for it not to change. One per= son's
> architectural improvement is destruction of someone else's bus= iness (selling
> hacks to work round architectural problems is big business). And o= ne
> progression of changes destroys someone else's idea of how the= y thought
> changes would progress. So altho the discussion will often seem ac= ademic,
> the structure in which ideas are taken forward has to be resilient= against
> the wars it might start. That part is much easier said than done.
> =20
> Cheers
> =20
> =20
> Bob
> =20
> On 03/04/2020 02:05, Toerless Eckert wrote:
> > On Thu, Apr 02, 2020 at 11:58:34AM -0800, Melinda Shore wrote= :
> > > On 4/2/20 11:34 AM, Toerless Eckert wrote:
> > > > Was it only presentations or also associated drafts= ? Was the
> > > > material asked to be make available sufficiently lo= ng ago to
> > > > allow quality updates be prior review ?
> > > Neither, really. It largely consisted of heated discuss= ions at
> > > the mike lines. While there were presentations, for the= most
> > > part they were not architectural in nature (with a few n= otable
> > > exceptions).
> > Ok, remembering some bits now.
> > That was fun, but yes, not what i was thinking of.
> > =20
> > > My sense, from several decades of involvement in the IET= F in
> > > various capacities, is that 1) it would take years to ge= t
> > > agreement on a diagram of the current internet architect= ure
> > > and what you'd end up would be aspirational rather t= han
> > > descriptive;
> > I think we can and are doing descriptive. Most of stackevo
> > mentioned by you below was descriptive. So are IMHO
> > many other documents/RFC i would consider to be architectural= .
> > =20
> > I can think of aspirational as a good and even necessar thing= .
> > =20
> > > 2) architectural discussions in the past have
> > > had minimal impact on actual protocol design;
> > That is a very broad statement. We should first have an
> > unserstanding about what we mean with architecture before
> > i should even ask you to give me example evidence of this.
> > =20
> > My architecture interests for example are probably a lot lowe= r
> > inside the machine room of the Internet than e.g. the
> > Internet BGP peering architecure. But all of it is valid
> > architecture topics to me.
> > =20
> > For example, i would consider CBOR an example of an
> > architcure concept (presentation layer) brought into
> > IETF and protocols.
> > =20
> > One example architecture area of interest for me is the probl= em that we
> > are not well enough taking the architecture of routers in to
> > account for our protocols, or better yet propose to evolve
> > architecture of both routers and protocols to be better fits = in the
> > future.
> > =20
> > I am betting neither of these topics are what you would
> > have considered to be architecture in your statement... ??
> > =20
> > > and 3) complexity
> > > always wins in the end (the history and output of the NS= IS
> > > working group might be a particularly illustrative examp= le
> > > of the latter).
> > > =20
> > > Right now, there is nothing stopping anybody from publis= hing
> > > drafts and contributing to (or, indeed, leading) archite= ctural
> > > discussions in IETF working groups. I'm not sure wh= at
> > > inferences we should make from the fact that for the mos= t part
> > > that's not happening now.
> > If architecture can be associated directly with protocols
> > of an IETF WG, then yes, it could and should happen
> > in that WG, but i think there are more cases where even
> > this does not happen. E.g.: I have seen ADs eliminate archite= cture
> > from charters because it does not produce implementable proto= cols.
> > =20
> > But the more fundamental issue is that architecture mostly
> > needs to predate protocol development, like research mostly
> > needs to predate architecture and protocols. I can not
> > see a logic that argues we must have an IRTF, but we cannot
> > have an IATF (Internet Architecture Task Force). The
> > whole construct of IAB for architecture is weird to me.
> > =20
> > > I'm skeptical about the actual value of what you'= ;re proposing
> > > but as I said, there's nothing stopping you (or anyb= ody else)
> > > from starting up something informally, which would give = us all
> > > a better sense of the actual interest level and what the= likely
> > > output would be.
> > Oh, i think there is a lot of sport in trying to discourage w= ork
> > that is not officially sponsored by the IETF/IAB authorities
> > at least from my imited experience.
> > =20
> > We need to be darn careful with every single word we
> > write about a side meeting. Make sure it is called "non = official"
> > every time you mention it, having people seemingly "borr= ow"
> > sign up sheets for examination what could be wrong with them,
> > ending up with concerns of using the same color (!) as "= official" IETF
> > meeting sign up sheets. Dismissive comments about even doing
> > a side-meeting, Not being allowed to use IETF tooling
> > like webex, jabber, wiki, etherpad, and so on. Because using
> > IETF tools would mean "endorsement of the activity"= *sigh*.
> > =20
> > This is sad in general, but at a time when it is legally cruc= ial
> > to make sure all communications is easily recognizeable as
> > public and published because of the US Govt. export regulatio= ns
> > (see EAR 734.7) it is outright dangerous to make it so diffic= ult
> > for inofficial side-meetings to use or emulate the
> > public/published nature of official IETF meetings.
> > =20
> > > Also, note that there have been IAB programs like stacke= vo to
> > > deal with these questions.
> > Last RFC published in 2016. Concluded in 2019.
> > Followup to architecture-discuss according to closing mail.
> > =20
> > Cheers
> > Toerless
> > > Melinda
> > > =20
> > > =20
> > > -- =20
> > > Melinda Shore
> > > melinda.= shore@nomountain.net
> > > =20
> > > Software longa, hardware brevis
> > > =20
> > =20
> > =20
> > =20
> > > _______________________________________________
> > > Architecture-discuss mailing list
> > > Archite= cture-discuss@ietf.org
> > > https://www.ietf.org/mailman/listinfo/architecture-discuss
> > =20
> =20
> -- =20
> ________________________________________________________________
> Bob Briscoe http://bobbriscoe.net/
> =20
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-disc= uss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss

-- =20
---
tte@cs.fau.de

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@i= etf.org
= https://www.ietf.org/mailman/listinfo/architecture-discuss
--0000000000002bbd2a05a2a25753-- From nobody Mon Apr 6 10:45:16 2020 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 8F1DF3A0D1F for ; Mon, 6 Apr 2020 10:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 PHE2KDMqcZjg for ; Mon, 6 Apr 2020 10:44:58 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A2263A0D1D for ; Mon, 6 Apr 2020 10:44:58 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id BFAFF548042; Mon, 6 Apr 2020 19:44:52 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id AA097440040; Mon, 6 Apr 2020 19:44:52 +0200 (CEST) Date: Mon, 6 Apr 2020 19:44:52 +0200 From: Toerless Eckert To: Marie-Jose Montpetit Cc: Bob Briscoe , architecture-discuss@ietf.org Message-ID: <20200406174452.GK28965@faui48f.informatik.uni-erlangen.de> References: <20200406160325.GI28965@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] Programmable forwarding plane discussions ? (was: Re: on the nature of architecture discussion) 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, 06 Apr 2020 17:45:03 -0000 Yes, i know, but thanks for reminding! Cheers oerless On Mon, Apr 06, 2020 at 10:10:13AM -0700, Marie-Jose Montpetit wrote: > There is a IRTF RG on programmable forwarding planes: COINRG. > > And we have an active mailing list and an interim tomorrow if you want to > participate. > > mjm > > Marie-José Montpetit, Ph.D. > marie@mjmontpetit.com > > > > On April 6, 2020 at 12:06:07 PM, Toerless Eckert (tte@cs.fau.de) wrote: > > To give one example aspect of what i would think of as a part > of the architecture: Discussions about pogrammable forwarding planes. > > We had one talk/presentation last year sponsored by IESG talking about > forwarding planes. And i think we did already see some good disagrement > (discussion starter) about how flexible or inflexible we should consider > them to be now or how much they could be more flexible in the future. > I for once think that wee could promote for them to be more flexible > if we would start getting our heads around this and maybe start writing > up insights and expectations. > > There are several attendees whose organizations have collected > experiences with options such as P4, FPGA or fd.io. But we have > no forum whatsoever to discuss those programmable forwarding plane > aspects. Heck, i am sure there would be interest for IETF participants > interested in this topic to contribute educational insight, summaries > of experiences, and thoughts about gaps that should and could be > closed. > > I for once am of the firm believ that the degree of innovation on any > platform is proportional to the degree of flexible programmability > by third parties. See VNF/NFV in data centers versus ossification in > gigabit switching in the WAN. But once we get to those forwarding > planes, i think freely programmable can not mean x.86 style, but > it does need to mean something beyond P4, and it does IMHO also > mean that we have to do reusable extensible protocols or else we > can not have virtual programmed networks due to lack of code space. > Etc. pp... > > So, why don't we even have a mailing list for such discussions ? > Yes, fragementing into many mailing lists has downsides, but most people > here (beside probbly myself) would have likely not thought about > forwarding plane architectures when they joined architecture-discuss, > so having a more specific mailing list and promoting it might help > to even attract the interested community. > > Of course, anything IETF organization would be easier if there was > a sponsor in leadership. And even for a mailing list, such a sponsor > is mandatory. > > Cheers > Toerless > > On Mon, Apr 06, 2020 at 02:25:31PM +0100, Bob Briscoe wrote: > > Toerless, > > > > I helped with a series of 'Re-Arch' research workshops from 2008 to 2010. > > The name was about "re-architecting" the Internet (whatever that means), > but > > the accepted papers included articulation of insights about the existing > > architecture. I was also involved in various activities before that to > > promote research investigation into the Internet's architecture. So, > based > > on that experience, here's my 2 penny's worth. > > > > You don't want to have "arch-dispatch" sessions too often. Good > > architectural ideas don't come up that often, so if you create too much > > space to talk about them, the vacuum will get filled with waffle. Once a > > year is probably enough. But then, if you detect waffle is starting to > fill > > a vacuum, it's best to back off the timer to biennial. Of course, if some > > new activity spins out of this (as it sometimes should from an > arch-dispatch > > activity), that takes on a separate existence that is more frequent than > the > > annual cycle of dispatch sessions. > > > > You certainly don't want to do this from mic lines. It's too easy for > > "random-ietf-bigot" to have opinions about architecture that don't add > > anything (other than for those collecting lists of opinions). > Contributors > > need to have had to do some work, like writing an accepted paper, to even > > get into the room. > > > > It needs to be framed in a context of actionable outcomes. I mean, > something > > like arch-dispatch would be a suitable context, 'cos it gives out the > > "actionable-only" message. That doesn't preclude "vague thoughts", but > only > > as long as they have the potential to lead to some change that will > impact > > on real life once they firm-up. > > > > So, IAB might be a more appropriate context than IRTF, but you want an > > environment that will attract researchers and thinkers. So the "political > > officers" need to be in the background managing the process rather than > > holding the floor. > > > > The architecture of such a valuable artefact as the Internet can become > > highly political. Huge businesses have been built on the Internet's > current > > architecture, with a vested interest for it not to change. One person's > > architectural improvement is destruction of someone else's business > (selling > > hacks to work round architectural problems is big business). And one > > progression of changes destroys someone else's idea of how they thought > > changes would progress. So altho the discussion will often seem academic, > > the structure in which ideas are taken forward has to be resilient > against > > the wars it might start. That part is much easier said than done. > > > > Cheers > > > > > > Bob > > > > On 03/04/2020 02:05, Toerless Eckert wrote: > > > On Thu, Apr 02, 2020 at 11:58:34AM -0800, Melinda Shore wrote: > > > > On 4/2/20 11:34 AM, Toerless Eckert wrote: > > > > > Was it only presentations or also associated drafts ? Was the > > > > > material asked to be make available sufficiently long ago to > > > > > allow quality updates be prior review ? > > > > Neither, really. It largely consisted of heated discussions at > > > > the mike lines. While there were presentations, for the most > > > > part they were not architectural in nature (with a few notable > > > > exceptions). > > > Ok, remembering some bits now. > > > That was fun, but yes, not what i was thinking of. > > > > > > > My sense, from several decades of involvement in the IETF in > > > > various capacities, is that 1) it would take years to get > > > > agreement on a diagram of the current internet architecture > > > > and what you'd end up would be aspirational rather than > > > > descriptive; > > > I think we can and are doing descriptive. Most of stackevo > > > mentioned by you below was descriptive. So are IMHO > > > many other documents/RFC i would consider to be architectural. > > > > > > I can think of aspirational as a good and even necessar thing. > > > > > > > 2) architectural discussions in the past have > > > > had minimal impact on actual protocol design; > > > That is a very broad statement. We should first have an > > > unserstanding about what we mean with architecture before > > > i should even ask you to give me example evidence of this. > > > > > > My architecture interests for example are probably a lot lower > > > inside the machine room of the Internet than e.g. the > > > Internet BGP peering architecure. But all of it is valid > > > architecture topics to me. > > > > > > For example, i would consider CBOR an example of an > > > architcure concept (presentation layer) brought into > > > IETF and protocols. > > > > > > One example architecture area of interest for me is the problem that we > > > are not well enough taking the architecture of routers in to > > > account for our protocols, or better yet propose to evolve > > > architecture of both routers and protocols to be better fits in the > > > future. > > > > > > I am betting neither of these topics are what you would > > > have considered to be architecture in your statement... ?? > > > > > > > and 3) complexity > > > > always wins in the end (the history and output of the NSIS > > > > working group might be a particularly illustrative example > > > > of the latter). > > > > > > > > Right now, there is nothing stopping anybody from publishing > > > > drafts and contributing to (or, indeed, leading) architectural > > > > discussions in IETF working groups. I'm not sure what > > > > inferences we should make from the fact that for the most part > > > > that's not happening now. > > > If architecture can be associated directly with protocols > > > of an IETF WG, then yes, it could and should happen > > > in that WG, but i think there are more cases where even > > > this does not happen. E.g.: I have seen ADs eliminate architecture > > > from charters because it does not produce implementable protocols. > > > > > > But the more fundamental issue is that architecture mostly > > > needs to predate protocol development, like research mostly > > > needs to predate architecture and protocols. I can not > > > see a logic that argues we must have an IRTF, but we cannot > > > have an IATF (Internet Architecture Task Force). The > > > whole construct of IAB for architecture is weird to me. > > > > > > > I'm skeptical about the actual value of what you're proposing > > > > but as I said, there's nothing stopping you (or anybody else) > > > > from starting up something informally, which would give us all > > > > a better sense of the actual interest level and what the likely > > > > output would be. > > > Oh, i think there is a lot of sport in trying to discourage work > > > that is not officially sponsored by the IETF/IAB authorities > > > at least from my imited experience. > > > > > > We need to be darn careful with every single word we > > > write about a side meeting. Make sure it is called "non official" > > > every time you mention it, having people seemingly "borrow" > > > sign up sheets for examination what could be wrong with them, > > > ending up with concerns of using the same color (!) as "official" IETF > > > meeting sign up sheets. Dismissive comments about even doing > > > a side-meeting, Not being allowed to use IETF tooling > > > like webex, jabber, wiki, etherpad, and so on. Because using > > > IETF tools would mean "endorsement of the activity" *sigh*. > > > > > > This is sad in general, but at a time when it is legally crucial > > > to make sure all communications is easily recognizeable as > > > public and published because of the US Govt. export regulations > > > (see EAR 734.7) it is outright dangerous to make it so difficult > > > for inofficial side-meetings to use or emulate the > > > public/published nature of official IETF meetings. > > > > > > > Also, note that there have been IAB programs like stackevo to > > > > deal with these questions. > > > Last RFC published in 2016. Concluded in 2019. > > > Followup to architecture-discuss according to closing mail. > > > > > > Cheers > > > Toerless > > > > Melinda > > > > > > > > > > > > -- > > > > Melinda Shore > > > > melinda.shore@nomountain.net > > > > > > > > Software longa, hardware brevis > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Architecture-discuss mailing list > > > > Architecture-discuss@ietf.org > > > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > > > > > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > -- > --- > tte@cs.fau.de > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Mon Apr 6 11:47:54 2020 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 2B0FF3A0D24 for ; Mon, 6 Apr 2020 11:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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=mjmontpetit-com.20150623.gappssmtp.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 HUB8QO5SIUKI for ; Mon, 6 Apr 2020 11:47:50 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 F02063A0CB6 for ; Mon, 6 Apr 2020 11:47:48 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id r24so864060ljd.4 for ; Mon, 06 Apr 2020 11:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=veeIyV2SkLvAr8UTsQhHCtAvbdwLz/s0MN80TXULVJE=; b=UlT+I5LVwfBaJL+hypPg1cvRUUXOWKyCxRs9RTusEPFDHtE1bJeBi6G4OJ1pL4P98G UtGlWVLannSi2l3DcuZmMfVSNLY+GB38rU69iOlpb7DbFXIaaeRH3yT4RIA0C0w8thws IW0NJI8B0MkPmRZeTqb9XJ219c6+NH7DLI2682nMBqFa2rYKOu4z0tPqT2YVu/xMnBP+ Piue6hqP3ElSoGA9r6Q0QeKAPgNpBcnIAVmrXLE6K/8jqOrA7F5oCgQKZV/YDKCviKd9 ECJax2yG2T/fMVB3JAKhgGlbu4UjIqQx7CnvXq65wzsFZ1Zfa0Zfw5PxWNvb1Gk2LMuq 6SpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=veeIyV2SkLvAr8UTsQhHCtAvbdwLz/s0MN80TXULVJE=; b=OyzidwfKm1/UEInvoE152bZxshIikkcXe/udFnIsWHSYSWW98Fs1RC6Z2slhsZAbwP elWJhNvq0D3OX3ScoBkJ0LdjoUK2t7RLTlWsUc1F8zKYe9UcSC5HjW4FvmsxB6fPNN8J HF/b9WnDkCGnw45FwztFKHQDl1FEYVXeW0ila0bi7cTbFaAbxYs/VA59hcTOmUHDHWoA RQ3SmDtgOsvnz6+c+vUyCdlQxY1p/RqpqeDH8F1QMtyUxS2jALHXhTPhc5VXmqtJn3Ii b46mkWaWZ1ED8adMSt2dGAptcvaNJcQO0YZQgBkECLJiJsmst1N3z/ZgGaumI9yiI2Ld G14A== X-Gm-Message-State: AGi0PubAzNj+/v9IKtrmVlHIZy8RJi+nkjJlyTGk4DT1OhmVMUrDZtP9 RAqYCBivImhTmX3b1pKZ8Enr3aPwkBosiheeevHAlQ== X-Google-Smtp-Source: APiQypLcmHD5aw6ofXnMFAOaxDUzLDJ250IY1QJ76jV0relN5kaRVX+6/ofsQ+pq9cM19oPuT7xTS0ZUIT8LxkllTJY= X-Received: by 2002:a2e:9b05:: with SMTP id u5mr398800lji.257.1586198867008; Mon, 06 Apr 2020 11:47:47 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 6 Apr 2020 11:47:45 -0700 From: Marie-Jose Montpetit In-Reply-To: <20200406174452.GK28965@faui48f.informatik.uni-erlangen.de> References: <20200406160325.GI28965@faui48f.informatik.uni-erlangen.de> <20200406174452.GK28965@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Date: Mon, 6 Apr 2020 11:47:45 -0700 Message-ID: To: Toerless Eckert Cc: architecture-discuss@ietf.org, Bob Briscoe , "coinrg-chairs@irtf.org" Content-Type: multipart/alternative; boundary="00000000000002f10005a2a3b4f0" Archived-At: Subject: Re: [arch-d] Programmable forwarding plane discussions ? (was: Re: on the nature of architecture discussion) 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, 06 Apr 2020 18:47:53 -0000 --00000000000002f10005a2a3b4f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We will have an open discussion if you want to participate in that. Marie-Jos=C3=A9 Montpetit, Ph.D. marie@mjmontpetit.com On April 6, 2020 at 1:44:57 PM, Toerless Eckert (tte@cs.fau.de) wrote: Yes, i know, but thanks for reminding! Cheers oerless On Mon, Apr 06, 2020 at 10:10:13AM -0700, Marie-Jose Montpetit wrote: > There is a IRTF RG on programmable forwarding planes: COINRG. > > And we have an active mailing list and an interim tomorrow if you want to > participate. > > mjm > > Marie-Jos=C3=A9 Montpetit, Ph.D. > marie@mjmontpetit.com > > > > On April 6, 2020 at 12:06:07 PM, Toerless Eckert (tte@cs.fau.de) wrote: > > To give one example aspect of what i would think of as a part > of the architecture: Discussions about pogrammable forwarding planes. > > We had one talk/presentation last year sponsored by IESG talking about > forwarding planes. And i think we did already see some good disagrement > (discussion starter) about how flexible or inflexible we should consider > them to be now or how much they could be more flexible in the future. > I for once think that wee could promote for them to be more flexible > if we would start getting our heads around this and maybe start writing > up insights and expectations. > > There are several attendees whose organizations have collected > experiences with options such as P4, FPGA or fd.io. But we have > no forum whatsoever to discuss those programmable forwarding plane > aspects. Heck, i am sure there would be interest for IETF participants > interested in this topic to contribute educational insight, summaries > of experiences, and thoughts about gaps that should and could be > closed. > > I for once am of the firm believ that the degree of innovation on any > platform is proportional to the degree of flexible programmability > by third parties. See VNF/NFV in data centers versus ossification in > gigabit switching in the WAN. But once we get to those forwarding > planes, i think freely programmable can not mean x.86 style, but > it does need to mean something beyond P4, and it does IMHO also > mean that we have to do reusable extensible protocols or else we > can not have virtual programmed networks due to lack of code space. > Etc. pp... > > So, why don't we even have a mailing list for such discussions ? > Yes, fragementing into many mailing lists has downsides, but most people > here (beside probbly myself) would have likely not thought about > forwarding plane architectures when they joined architecture-discuss, > so having a more specific mailing list and promoting it might help > to even attract the interested community. > > Of course, anything IETF organization would be easier if there was > a sponsor in leadership. And even for a mailing list, such a sponsor > is mandatory. > > Cheers > Toerless > > On Mon, Apr 06, 2020 at 02:25:31PM +0100, Bob Briscoe wrote: > > Toerless, > > > > I helped with a series of 'Re-Arch' research workshops from 2008 to 2010. > > The name was about "re-architecting" the Internet (whatever that means), > but > > the accepted papers included articulation of insights about the existing > > architecture. I was also involved in various activities before that to > > promote research investigation into the Internet's architecture. So, > based > > on that experience, here's my 2 penny's worth. > > > > You don't want to have "arch-dispatch" sessions too often. Good > > architectural ideas don't come up that often, so if you create too much > > space to talk about them, the vacuum will get filled with waffle. Once a > > year is probably enough. But then, if you detect waffle is starting to > fill > > a vacuum, it's best to back off the timer to biennial. Of course, if some > > new activity spins out of this (as it sometimes should from an > arch-dispatch > > activity), that takes on a separate existence that is more frequent than > the > > annual cycle of dispatch sessions. > > > > You certainly don't want to do this from mic lines. It's too easy for > > "random-ietf-bigot" to have opinions about architecture that don't add > > anything (other than for those collecting lists of opinions). > Contributors > > need to have had to do some work, like writing an accepted paper, to even > > get into the room. > > > > It needs to be framed in a context of actionable outcomes. I mean, > something > > like arch-dispatch would be a suitable context, 'cos it gives out the > > "actionable-only" message. That doesn't preclude "vague thoughts", but > only > > as long as they have the potential to lead to some change that will > impact > > on real life once they firm-up. > > > > So, IAB might be a more appropriate context than IRTF, but you want an > > environment that will attract researchers and thinkers. So the "political > > officers" need to be in the background managing the process rather than > > holding the floor. > > > > The architecture of such a valuable artefact as the Internet can become > > highly political. Huge businesses have been built on the Internet's > current > > architecture, with a vested interest for it not to change. One person's > > architectural improvement is destruction of someone else's business > (selling > > hacks to work round architectural problems is big business). And one > > progression of changes destroys someone else's idea of how they thought > > changes would progress. So altho the discussion will often seem academic, > > the structure in which ideas are taken forward has to be resilient > against > > the wars it might start. That part is much easier said than done. > > > > Cheers > > > > > > Bob > > > > On 03/04/2020 02:05, Toerless Eckert wrote: > > > On Thu, Apr 02, 2020 at 11:58:34AM -0800, Melinda Shore wrote: > > > > On 4/2/20 11:34 AM, Toerless Eckert wrote: > > > > > Was it only presentations or also associated drafts ? Was the > > > > > material asked to be make available sufficiently long ago to > > > > > allow quality updates be prior review ? > > > > Neither, really. It largely consisted of heated discussions at > > > > the mike lines. While there were presentations, for the most > > > > part they were not architectural in nature (with a few notable > > > > exceptions). > > > Ok, remembering some bits now. > > > That was fun, but yes, not what i was thinking of. > > > > > > > My sense, from several decades of involvement in the IETF in > > > > various capacities, is that 1) it would take years to get > > > > agreement on a diagram of the current internet architecture > > > > and what you'd end up would be aspirational rather than > > > > descriptive; > > > I think we can and are doing descriptive. Most of stackevo > > > mentioned by you below was descriptive. So are IMHO > > > many other documents/RFC i would consider to be architectural. > > > > > > I can think of aspirational as a good and even necessar thing. > > > > > > > 2) architectural discussions in the past have > > > > had minimal impact on actual protocol design; > > > That is a very broad statement. We should first have an > > > unserstanding about what we mean with architecture before > > > i should even ask you to give me example evidence of this. > > > > > > My architecture interests for example are probably a lot lower > > > inside the machine room of the Internet than e.g. the > > > Internet BGP peering architecure. But all of it is valid > > > architecture topics to me. > > > > > > For example, i would consider CBOR an example of an > > > architcure concept (presentation layer) brought into > > > IETF and protocols. > > > > > > One example architecture area of interest for me is the problem that we > > > are not well enough taking the architecture of routers in to > > > account for our protocols, or better yet propose to evolve > > > architecture of both routers and protocols to be better fits in the > > > future. > > > > > > I am betting neither of these topics are what you would > > > have considered to be architecture in your statement... ?? > > > > > > > and 3) complexity > > > > always wins in the end (the history and output of the NSIS > > > > working group might be a particularly illustrative example > > > > of the latter). > > > > > > > > Right now, there is nothing stopping anybody from publishing > > > > drafts and contributing to (or, indeed, leading) architectural > > > > discussions in IETF working groups. I'm not sure what > > > > inferences we should make from the fact that for the most part > > > > that's not happening now. > > > If architecture can be associated directly with protocols > > > of an IETF WG, then yes, it could and should happen > > > in that WG, but i think there are more cases where even > > > this does not happen. E.g.: I have seen ADs eliminate architecture > > > from charters because it does not produce implementable protocols. > > > > > > But the more fundamental issue is that architecture mostly > > > needs to predate protocol development, like research mostly > > > needs to predate architecture and protocols. I can not > > > see a logic that argues we must have an IRTF, but we cannot > > > have an IATF (Internet Architecture Task Force). The > > > whole construct of IAB for architecture is weird to me. > > > > > > > I'm skeptical about the actual value of what you're proposing > > > > but as I said, there's nothing stopping you (or anybody else) > > > > from starting up something informally, which would give us all > > > > a better sense of the actual interest level and what the likely > > > > output would be. > > > Oh, i think there is a lot of sport in trying to discourage work > > > that is not officially sponsored by the IETF/IAB authorities > > > at least from my imited experience. > > > > > > We need to be darn careful with every single word we > > > write about a side meeting. Make sure it is called "non official" > > > every time you mention it, having people seemingly "borrow" > > > sign up sheets for examination what could be wrong with them, > > > ending up with concerns of using the same color (!) as "official" IETF > > > meeting sign up sheets. Dismissive comments about even doing > > > a side-meeting, Not being allowed to use IETF tooling > > > like webex, jabber, wiki, etherpad, and so on. Because using > > > IETF tools would mean "endorsement of the activity" *sigh*. > > > > > > This is sad in general, but at a time when it is legally crucial > > > to make sure all communications is easily recognizeable as > > > public and published because of the US Govt. export regulations > > > (see EAR 734.7) it is outright dangerous to make it so difficult > > > for inofficial side-meetings to use or emulate the > > > public/published nature of official IETF meetings. > > > > > > > Also, note that there have been IAB programs like stackevo to > > > > deal with these questions. > > > Last RFC published in 2016. Concluded in 2019. > > > Followup to architecture-discuss according to closing mail. > > > > > > Cheers > > > Toerless > > > > Melinda > > > > > > > > > > > > -- > > > > Melinda Shore > > > > melinda.shore@nomountain.net > > > > > > > > Software longa, hardware brevis > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Architecture-discuss mailing list > > > > Architecture-discuss@ietf.org > > > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > > > > > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > -- > --- > tte@cs.fau.de > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss --=20 --- tte@cs.fau.de --00000000000002f10005a2a3b4f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
We w= ill have an open discussion if you want to participate in that.

=
Marie-Jos=C3=A9 Montpetit, Ph.D.
marie@mjmontpetit.com
=


On April = 6, 2020 at 1:44:57 PM, Toerless Eckert (tt= e@cs.fau.de) wrote:

Yes, i know, but thanks for reminding!

Cheers
oerless

On Mon, Apr 06, 2020 at 10:10:13AM -0700, Marie-Jose Montpetit wrote:
> There is a IRTF RG on programmable forwarding planes: COINRG.
> =20
> And we have an active mailing list and an interim tomorrow if you = want to
> participate.
> =20
> mjm
> =20
> Marie-Jos=C3=A9 Montpetit, Ph.D.
> marie@mjmontpetit.com
> =20
> =20
> =20
> On April 6, 2020 at 12:06:07 PM, Toerless Eckert (tte@cs.fau.de) wrote:
> =20
> To give one example aspect of what i would think of as a part
> of the architecture: Discussions about pogrammable forwarding plan= es.
> =20
> We had one talk/presentation last year sponsored by IESG talking a= bout
> forwarding planes. And i think we did already see some good disagr= ement
> (discussion starter) about how flexible or inflexible we should co= nsider
> them to be now or how much they could be more flexible in the futu= re.
> I for once think that wee could promote for them to be more flexib= le
> if we would start getting our heads around this and maybe start wr= iting
> up insights and expectations.
> =20
> There are several attendees whose organizations have collected
> experiences with options such as P4, FPGA or fd.io. But we have
> no forum whatsoever to discuss those programmable forwarding plane
> aspects. Heck, i am sure there would be interest for IETF particip= ants
> interested in this topic to contribute educational insight, summar= ies
> of experiences, and thoughts about gaps that should and could be
> closed.
> =20
> I for once am of the firm believ that the degree of innovation on = any
> platform is proportional to the degree of flexible programmability
> by third parties. See VNF/NFV in data centers versus ossification = in
> gigabit switching in the WAN. But once we get to those forwarding
> planes, i think freely programmable can not mean x.86 style, but
> it does need to mean something beyond P4, and it does IMHO also
> mean that we have to do reusable extensible protocols or else we
> can not have virtual programmed networks due to lack of code space= .
> Etc. pp...
> =20
> So, why don't we even have a mailing list for such discussions= ?
> Yes, fragementing into many mailing lists has downsides, but most = people
> here (beside probbly myself) would have likely not thought about
> forwarding plane architectures when they joined architecture-discu= ss,
> so having a more specific mailing list and promoting it might help
> to even attract the interested community.
> =20
> Of course, anything IETF organization would be easier if there was
> a sponsor in leadership. And even for a mailing list, such a spons= or
> is mandatory.
> =20
> Cheers
> Toerless
> =20
> On Mon, Apr 06, 2020 at 02:25:31PM +0100, Bob Briscoe wrote:
> > Toerless,
> >
> > I helped with a series of 'Re-Arch' research workshop= s from 2008 to 2010.
> > The name was about "re-architecting" the Internet (= whatever that means),
> but
> > the accepted papers included articulation of insights about t= he existing
> > architecture. I was also involved in various activities befor= e that to
> > promote research investigation into the Internet's archit= ecture. So,
> based
> > on that experience, here's my 2 penny's worth.
> >
> > You don't want to have "arch-dispatch" sessions= too often. Good
> > architectural ideas don't come up that often, so if you c= reate too much
> > space to talk about them, the vacuum will get filled with waf= fle. Once a
> > year is probably enough. But then, if you detect waffle is st= arting to
> fill
> > a vacuum, it's best to back off the timer to biennial. Of= course, if some
> > new activity spins out of this (as it sometimes should from a= n
> arch-dispatch
> > activity), that takes on a separate existence that is more fr= equent than
> the
> > annual cycle of dispatch sessions.
> >
> > You certainly don't want to do this from mic lines. It= 9;s too easy for
> > "random-ietf-bigot" to have opinions about architec= ture that don't add
> > anything (other than for those collecting lists of opinions).
> Contributors
> > need to have had to do some work, like writing an accepted pa= per, to even
> > get into the room.
> >
> > It needs to be framed in a context of actionable outcomes. I = mean,
> something
> > like arch-dispatch would be a suitable context, 'cos it g= ives out the
> > "actionable-only" message. That doesn't preclud= e "vague thoughts", but
> only
> > as long as they have the potential to lead to some change tha= t will
> impact
> > on real life once they firm-up.
> >
> > So, IAB might be a more appropriate context than IRTF, but yo= u want an
> > environment that will attract researchers and thinkers. So th= e "political
> > officers" need to be in the background managing the proc= ess rather than
> > holding the floor.
> >
> > The architecture of such a valuable artefact as the Internet = can become
> > highly political. Huge businesses have been built on the Inte= rnet's
> current
> > architecture, with a vested interest for it not to change. On= e person's
> > architectural improvement is destruction of someone else'= s business
> (selling
> > hacks to work round architectural problems is big business). = And one
> > progression of changes destroys someone else's idea of ho= w they thought
> > changes would progress. So altho the discussion will often se= em academic,
> > the structure in which ideas are taken forward has to be resi= lient
> against
> > the wars it might start. That part is much easier said than d= one.
> >
> > Cheers
> >
> >
> > Bob
> >
> > On 03/04/2020 02:05, Toerless Eckert wrote:
> > > On Thu, Apr 02, 2020 at 11:58:34AM -0800, Melinda Shore = wrote:
> > > > On 4/2/20 11:34 AM, Toerless Eckert wrote:
> > > > > Was it only presentations or also associated d= rafts ? Was the
> > > > > material asked to be make available sufficient= ly long ago to
> > > > > allow quality updates be prior review ?
> > > > Neither, really. It largely consisted of heated dis= cussions at
> > > > the mike lines. While there were presentations, for= the most
> > > > part they were not architectural in nature (with a = few notable
> > > > exceptions).
> > > Ok, remembering some bits now.
> > > That was fun, but yes, not what i was thinking of.
> > >
> > > > My sense, from several decades of involvement in th= e IETF in
> > > > various capacities, is that 1) it would take years = to get
> > > > agreement on a diagram of the current internet arch= itecture
> > > > and what you'd end up would be aspirational rat= her than
> > > > descriptive;
> > > I think we can and are doing descriptive. Most of stacke= vo
> > > mentioned by you below was descriptive. So are IMHO
> > > many other documents/RFC i would consider to be architec= tural.
> > >
> > > I can think of aspirational as a good and even necessar = thing.
> > >
> > > > 2) architectural discussions in the past have
> > > > had minimal impact on actual protocol design;
> > > That is a very broad statement. We should first have an
> > > unserstanding about what we mean with architecture befor= e
> > > i should even ask you to give me example evidence of thi= s.
> > >
> > > My architecture interests for example are probably a lot= lower
> > > inside the machine room of the Internet than e.g. the
> > > Internet BGP peering architecure. But all of it is valid
> > > architecture topics to me.
> > >
> > > For example, i would consider CBOR an example of an
> > > architcure concept (presentation layer) brought into
> > > IETF and protocols.
> > >
> > > One example architecture area of interest for me is the = problem that we
> > > are not well enough taking the architecture of routers i= n to
> > > account for our protocols, or better yet propose to evol= ve
> > > architecture of both routers and protocols to be better = fits in the
> > > future.
> > >
> > > I am betting neither of these topics are what you would
> > > have considered to be architecture in your statement... = ??
> > >
> > > > and 3) complexity
> > > > always wins in the end (the history and output of t= he NSIS
> > > > working group might be a particularly illustrative = example
> > > > of the latter).
> > > >
> > > > Right now, there is nothing stopping anybody from p= ublishing
> > > > drafts and contributing to (or, indeed, leading) ar= chitectural
> > > > discussions in IETF working groups. I'm not sur= e what
> > > > inferences we should make from the fact that for th= e most part
> > > > that's not happening now.
> > > If architecture can be associated directly with protocol= s
> > > of an IETF WG, then yes, it could and should happen
> > > in that WG, but i think there are more cases where even
> > > this does not happen. E.g.: I have seen ADs eliminate ar= chitecture
> > > from charters because it does not produce implementable = protocols.
> > >
> > > But the more fundamental issue is that architecture most= ly
> > > needs to predate protocol development, like research mos= tly
> > > needs to predate architecture and protocols. I can not
> > > see a logic that argues we must have an IRTF, but we can= not
> > > have an IATF (Internet Architecture Task Force). The
> > > whole construct of IAB for architecture is weird to me.
> > >
> > > > I'm skeptical about the actual value of what yo= u're proposing
> > > > but as I said, there's nothing stopping you (or= anybody else)
> > > > from starting up something informally, which would = give us all
> > > > a better sense of the actual interest level and wha= t the likely
> > > > output would be.
> > > Oh, i think there is a lot of sport in trying to discour= age work
> > > that is not officially sponsored by the IETF/IAB authori= ties
> > > at least from my imited experience.
> > >
> > > We need to be darn careful with every single word we
> > > write about a side meeting. Make sure it is called "= ;non official"
> > > every time you mention it, having people seemingly "= ;borrow"
> > > sign up sheets for examination what could be wrong with = them,
> > > ending up with concerns of using the same color (!) as &= quot;official" IETF
> > > meeting sign up sheets. Dismissive comments about even d= oing
> > > a side-meeting, Not being allowed to use IETF tooling
> > > like webex, jabber, wiki, etherpad, and so on. Because u= sing
> > > IETF tools would mean "endorsement of the activity&= quot; *sigh*.
> > >
> > > This is sad in general, but at a time when it is legally= crucial
> > > to make sure all communications is easily recognizeable = as
> > > public and published because of the US Govt. export regu= lations
> > > (see EAR 734.7) it is outright dangerous to make it so d= ifficult
> > > for inofficial side-meetings to use or emulate the
> > > public/published nature of official IETF meetings.
> > >
> > > > Also, note that there have been IAB programs like s= tackevo to
> > > > deal with these questions.
> > > Last RFC published in 2016. Concluded in 2019.
> > > Followup to architecture-discuss according to closing ma= il.
> > >
> > > Cheers
> > > Toerless
> > > > Melinda
> > > >
> > > >
> > > > --
> > > > Melinda Shore
> > > > mel= inda.shore@nomountain.net
> > > >
> > > > Software longa, hardware brevis
> > > >
> > >
> > >
> > >
> > > > _______________________________________________
> > > > Architecture-discuss mailing list
> > > > Ar= chitecture-discuss@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/architecture-disc= uss
> > >
> >
> > --
> > _____________________________________________________________= ___
> > Bob Briscoe http://bobbris= coe.net/
> >
> > _______________________________________________
> > Architecture-discuss mailing list
> > Architecture= -discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/architecture-discuss
> =20
> -- =20
> ---
> tte@cs.fau.de
> =20
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-disc= uss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss

-- =20
---
tte@cs.fau.de
--00000000000002f10005a2a3b4f0-- From nobody Tue Apr 7 03:17:44 2020 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 331BD3A1A80 for ; Tue, 7 Apr 2020 03:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_NONE=0.001, SPF_NONE=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 H1iy8NlXO2MZ for ; Tue, 7 Apr 2020 03:17:41 -0700 (PDT) Received: from vs22.mail.saunalahti.fi (vs22.mail.saunalahti.fi [193.64.193.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62C083A1A7F for ; Tue, 7 Apr 2020 03:17:41 -0700 (PDT) Received: from vs22.mail.saunalahti.fi (localhost [127.0.0.1]) by vs22.mail.saunalahti.fi (Postfix) with ESMTP id 69E622036B for ; Tue, 7 Apr 2020 13:17:39 +0300 (EEST) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by vs22.mail.saunalahti.fi (Postfix) with ESMTP id 5F4F7202E2 for ; Tue, 7 Apr 2020 13:17:39 +0300 (EEST) Received: from eggert.org (unknown [62.248.255.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eggert@elisanet.fi) by gw02.mail.saunalahti.fi (Postfix) with ESMTPSA id 5A10B40009 for ; Tue, 7 Apr 2020 13:17:38 +0300 (EEST) Received: from stickers.eggert.org (stickers.eggert.org [172.24.110.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id 8C076893CB2 for ; Tue, 7 Apr 2020 13:17:32 +0300 (EEST) From: Lars Eggert Content-Type: multipart/signed; boundary="Apple-Mail=_FF3715E3-F6AC-48FB-BB13-32D24103A36D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: Date: Tue, 7 Apr 2020 13:17:32 +0300 To: architecture-discuss@ietf.org X-MailScanner-ID: 8C076893CB2.A3A27 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: [arch-d] Funding opportunity for architecture work 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: Tue, 07 Apr 2020 10:17:43 -0000 --Apple-Mail=_FF3715E3-F6AC-48FB-BB13-32D24103A36D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, the NGI POINTER project opened its first call for funding proposals = today. Deadline June 1, 2020. Topics include those of interest to this = list, specifically innovating on the Internet architecture and the web. https://pointer.ngi.eu/pages/ngi-pointer-opencalls Feel free to share. Lars --Apple-Mail=_FF3715E3-F6AC-48FB-BB13-32D24103A36D 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl6MUzwACgkQVLXDCb9w wVdyUhAAmtE2lC8Ze6UUBczfYjSAS0ayL4+R7rAGJCr+A0YErpFxuGKCF3rWiO3M 6kDZ+yTHYZvzhFliNzJNY0RtIqDs8b1DmIQsAIAb5vIVgRs6WGvbLKiQIFp1kjKI ncJcmH8x/R9joGfLNygH3lCYc1VHvDBxqq/3gp9Y56+zUfhBOBrsUCeast0rE0zu BeYOWz19EQWiTvUg8BZZTuIqJop55SpYiThGpU6ieOxt+uAiKI8UspTQbt/YtpCh GhDpuM4/8ynrF7VgIzY6AimhxeC6stJfBvivwRqMujiiEmVKFZHVXect776zX039 V0C57wols8MZz5h6Kxjnr3Aywfl/9vUyXbk3Oyt5fTLvQ7A29UmeR/gC1NCbiiv8 AfMY+/NMVz5r3w9N8d2x8SOSVITUSjwZRcmPy4CzVBsWm1sc5s+3PfNWTsdX2U14 mdDwd2a38c1KBUafHnvGz7JiH4J6Lf9hp3i+0FWju4Rh5BPgMXfxGCyT+Hx544MR uEQIUTOE5nVI0UZ0tNQZEihvxo/oTG6g0V2NJoDmjjLIT4ZCBGfsQlp3vvJCw4Am 6nk4eX4opYcGmrfdoi80kunV9QQXAwSz5d9Gy27hliQPh2LLVcdHBiFZR/DXvpd5 1DPg0KS2pXNpznoXtYFimIDeKEQtd7KR2O7AEQwiHYicOa6seU0= =b8jF -----END PGP SIGNATURE----- --Apple-Mail=_FF3715E3-F6AC-48FB-BB13-32D24103A36D-- From nobody Tue Apr 7 21:58:45 2020 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 AD5A33A0C5C for ; Tue, 7 Apr 2020 21:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQdX1Xe8CcGa for ; Tue, 7 Apr 2020 21:58:42 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 7AE593A0C5A for ; Tue, 7 Apr 2020 21:58:42 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id k191so2776253pgc.13 for ; Tue, 07 Apr 2020 21:58:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:from:organization:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=XPS1QmmneoFqpTDEblxKJbquZbhrxfSH/yV8veTNX6I=; b=rOaggHxm5z09Ni16uQi5JywGj7jIA/sqTq+F2WMg7QVe9jtknNbQtDD7aXmYNyXHzI Mwa+2tT97y7TlmVwEPspnqh9qTO679PFe5ywLAo/PQgaLRpOudvLjKg7hIxVkTbFV0Lg EUGY7bBs8HXJx9q523zWtCSMJWlhTnGF+UYqQk7i/5kXA8z1HCYpznOkMcbKUvXsqjzL mApNFzyVU4GK7j1Y7vyTZMmsItG9bbhVekhsI0+r5yYj1FOuj7PtP8Jyfu/OurCFdM4L iS13BrrXImUh1NgsXMe7PG9lOYTbtXcCKGnKB3w7E+U/V/GCTrpvJV+5OCz5YDJEs1r/ qdNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:from:organization:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=XPS1QmmneoFqpTDEblxKJbquZbhrxfSH/yV8veTNX6I=; b=YeI3/R5/wohm2tQgpozIzKaoPOU0CHzo5RF9ui0sLPGqIKxcvCxlqucZECVd2vcIxQ vYToE4AS8cPee8ihkX0DEbiKFlfIqJ1dHXhHo2ZEzRcU53Ir5osjWh8yATinlSFXNw24 FWqmyaJRhNm8pcJf4jm1WpjOe96w9Y1Nax0KbFJTC6kk/VL65/qwt0LOSbst0sfOKqH2 i39b/zSbAOb5FocYBaxlWRisZ9mWSnHlDw31kZoacdETVuCvD36KXRRHmc1L5jlbJ+gB 4MnllWEeSW8GIbw5Ur8krPJZZ9mpki0Yuh90LLshxDozb994IVn8Z06+vbXokw27qh+U Rjlw== X-Gm-Message-State: AGi0PuZ49pi9UcQUZxBV2bBSmYzbZC4v8+Qnf/A4DXay3ItFXZ1rNLEQ DKicKVgDbQxtQnc2wyX05+00+NGI X-Google-Smtp-Source: APiQypKVXYlCF2hAJuOITm38YRIDJnGC9uIak3TWxFE2oFwOq5NY9i5UcDTh5IaYUt65bVYJtw8wbQ== X-Received: by 2002:a63:d3:: with SMTP id 202mr5280889pga.378.1586321921447; Tue, 07 Apr 2020 21:58:41 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id s102sm318700pjc.26.2020.04.07.21.58.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Apr 2020 21:58:40 -0700 (PDT) To: architecture-discuss@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> Date: Wed, 8 Apr 2020 16:58:36 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 08 Apr 2020 04:58:44 -0000 All our troubles will soon be over, apparently: https://www.etsi.org/newsroom/press-releases/1749-2020-04-etsi-launches-new-group-on-non-ip-networking-addressing-5g-new-services Stay well Brian Carpenter From nobody Tue Apr 7 22:00:01 2020 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 4F9203A0C70 for ; Tue, 7 Apr 2020 22:00:00 -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 clo4XVuD0TzN for ; Tue, 7 Apr 2020 21:59:57 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 608B93A0C6D for ; Tue, 7 Apr 2020 21:59:57 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48xsXC2BbTzyVk; Wed, 8 Apr 2020 06:59:55 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> Date: Wed, 8 Apr 2020 06:59:54 +0200 Cc: architecture-discuss@ietf.org X-Mao-Original-Outgoing-Id: 608014794.7286609-15d1e2ee791bf371900f29f33cde3cdf Content-Transfer-Encoding: quoted-printable Message-Id: <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 08 Apr 2020 05:00:00 -0000 On 2020-04-08, at 06:58, Brian E Carpenter = wrote: >=20 > All our troubles will soon be over, apparently: >=20 > = https://www.etsi.org/newsroom/press-releases/1749-2020-04-etsi-launches-ne= w-group-on-non-ip-networking-addressing-5g-new-services =E2=80=A6 and you can find one thoughtful piece of discussion from the = IETF chair at the unlikely place of https://datatracker.ietf.org/liaison/1677/ Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Apr 7 22:42:36 2020 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 E58313A0DA7 for ; Tue, 7 Apr 2020 22:42: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, 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 qcHZYMxjcW7x for ; Tue, 7 Apr 2020 22:42:32 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 B2BEF3A0DA6 for ; Tue, 7 Apr 2020 22:42:32 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id B63AB28015E; Wed, 8 Apr 2020 07:42:29 +0200 (CEST) Received: by mx4.nic.fr (Postfix, from userid 500) id AFBED280674; Wed, 8 Apr 2020 07:42:29 +0200 (CEST) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id A82DF28015E; Wed, 8 Apr 2020 07:42:29 +0200 (CEST) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id A4D0B64C6C03; Wed, 8 Apr 2020 07:42:29 +0200 (CEST) Received: by b12.nic.fr (Postfix, from userid 1000) id 948203FD5F; Wed, 8 Apr 2020 07:42:04 +0200 (CEST) Date: Wed, 8 Apr 2020 07:42:04 +0200 From: Stephane Bortzmeyer To: Carsten Bormann Cc: Brian E Carpenter , architecture-discuss@ietf.org Message-ID: <20200408054204.GA6005@nic.fr> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> X-Operating-System: Debian GNU/Linux 10.3 X-Kernel: Linux 4.19.0-8-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: No, tests=bogofilter, spamicity=0.000017, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.11.5.63017 Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 08 Apr 2020 05:42:35 -0000 On Wed, Apr 08, 2020 at 06:59:54AM +0200, Carsten Bormann wrote a message of 11 lines which said: > … and you can find one thoughtful piece of discussion from the IETF chair at the unlikely place of > > https://datatracker.ietf.org/liaison/1677/ It seems that IETF's answer is about another project, by ITU. ITU and ETSI have the same discourse but, apparently, they operate separately. From nobody Tue Apr 7 22:55:41 2020 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 2E63D3A0DC6 for ; Tue, 7 Apr 2020 22:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 hkIvtBOxAKmF for ; Tue, 7 Apr 2020 22:55:36 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47CA13A07C2 for ; Tue, 7 Apr 2020 22:55:35 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 987AE548045; Wed, 8 Apr 2020 07:55:30 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 906FD440040; Wed, 8 Apr 2020 07:55:30 +0200 (CEST) Date: Wed, 8 Apr 2020 07:55:30 +0200 From: Toerless Eckert To: Carsten Bormann Cc: Brian E Carpenter , architecture-discuss@ietf.org Message-ID: <20200408055530.GC28965@faui48f.informatik.uni-erlangen.de> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 08 Apr 2020 05:55:38 -0000 I think there are also different opinions about the usefulness of this overall ITU-T/IETF exchange. And the reports in the media ensuing from it are painfully politically charged and misleading. But then again, even if the exchange per se would have been more useful IMHO, i am not a fan of leadership-to-leadership only processes that do not actively involve the respective communities but post notes on rarely visited URLs. This form of communications reminds me of: ...All the planning charts and demolition orders have been on display at your local planning department in Alpha Centauri... The media reports also sound like Douglas Adams. Cheers Toerless On Wed, Apr 08, 2020 at 06:59:54AM +0200, Carsten Bormann wrote: > On 2020-04-08, at 06:58, Brian E Carpenter wrote: > > > > All our troubles will soon be over, apparently: > > > > https://www.etsi.org/newsroom/press-releases/1749-2020-04-etsi-launches-new-group-on-non-ip-networking-addressing-5g-new-services > > ??? and you can find one thoughtful piece of discussion from the IETF chair at the unlikely place of > > https://datatracker.ietf.org/liaison/1677/ > > Grüße, Carsten > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Tue Apr 7 23:16:02 2020 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 C28973A00C1 for ; Tue, 7 Apr 2020 23:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 cvq75q6-betA for ; Tue, 7 Apr 2020 23:15:59 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BB923A00B0 for ; Tue, 7 Apr 2020 23:15:58 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A6563548017; Wed, 8 Apr 2020 08:15:52 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 977C5440040; Wed, 8 Apr 2020 08:15:52 +0200 (CEST) Date: Wed, 8 Apr 2020 08:15:52 +0200 From: Toerless Eckert To: Stephane Bortzmeyer Cc: Carsten Bormann , architecture-discuss@ietf.org Message-ID: <20200408061552.GD28965@faui48f.informatik.uni-erlangen.de> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200408054204.GA6005@nic.fr> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 08 Apr 2020 06:16:01 -0000 On Wed, Apr 08, 2020 at 07:42:04AM +0200, Stephane Bortzmeyer wrote: > > https://datatracker.ietf.org/liaison/1677/ > > It seems that IETF's answer is about another project, by ITU. Yes. > ITU and ETSI have the same discourse What information makes you think that ? I do not think that that is true. > That document was input to ITU-T Study Group 13 (SG13) for the start of Focus Group 2030 (FGNET2030). FGNET203 was not formally involved in the creation of the Liaison Statements referred to in the liaison exchange pointed to by Carsten. Instead that was done by ITU-T Telecommunication Standardization Advisory Group (TSAG) probably with help from SG13. There are ITU-T members and contributors who think that topics related directly to the evolution of IP (often referred to as "New IP") should be discussed by interested parties directly to IETF instead of of being brought into some IMHO obfuscated leadership statements via some liaison process. At least thats what i believe, which is why we have inofficial IETF side meetings about "New IP" and other related topics. But then again, this is from my team working only in FGNET2030, but not having been involved in any of the payload of the TSAG/SG13 liaison statements. > but, apparently, they operate separately. Yes. ETSI is a completely separate SDO from ITU, Not a United Nations organization. Cheers Toerless > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Wed Apr 8 10:28:22 2020 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 CF12F3A1402 for ; Wed, 8 Apr 2020 10:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wl9xXS7OrFmF for ; Wed, 8 Apr 2020 10:28:19 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 312863A1403 for ; Wed, 8 Apr 2020 10:28:19 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id i10so2495358wrv.10 for ; Wed, 08 Apr 2020 10:28:18 -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=pEw2suZCy7x781bGKq6/SK83IKlnzPS/urOdR4RAJRI=; b=Ps30REB6XuWwa70JU51LWb+M9P/ElG3jFXp1jSkMimEb25sCu1tLU0zHV778anyVst B/GUpRNnNgi6D67sd24S0co6DfxQtZkes5GYKX0TAltHfNgQMii7CndpjbTehZUnO9bV l/BtJssteavMS3HsQy/yX8rnf1hDs3eGDcZMgAJx6qB3z7oacWWzguw2tseBts8SFjC6 dM7yotLWex2W83dRfhmkY1cPHcO1Z6TALLjfPD+BI0szGUy9B69ce274yJQxtkTuV66U CvgHzapR1VjhWpc5LHkkDOw9w4sK0r9MZEM/2OSuHSHihF1VZnMlOkGc1+UIDpR2Qt8c JEvQ== 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=pEw2suZCy7x781bGKq6/SK83IKlnzPS/urOdR4RAJRI=; b=onFoV5QHla0vNhQWPy/pEkrnvdQkRsJ+RKsbLBv4W9Dr4uJ2MoC1mwbUq7WxwSVttQ 6qcXEeUfbQX19m6b/6Fsj55uyEs020l8itHxPjrld02aFoNizINUSfnUhHqFpNdFIlUn gqsfkZ47SC94UiWJzkxz98VlS/T2KI1tGYl9a58WqZ4qXGrqNaDb17cZnhiRZJ+OJU6K 3JgjtCt7vf/6bLRM9QGPgFHqi/mZMseoTZEgqYzMkXaFWGIaQtXbAFW2n3bltoyxUo8J Avimntyy3heR9SO+N48GaG4KDjDvYA8CzlibvwXDsL9ZTr6Tm7+feEQWhuTxAJ8LZtgX ixNg== X-Gm-Message-State: AGi0PuYPcmN+nOJf45tLzM1C1Y+SePEm2dHfVl49naCyaGotkT0kE0Fe 8ZG9GUjjMenbQRD4+geSKJ0= X-Google-Smtp-Source: APiQypIUbhIDtSuHhDUIZoXLjHB6O3G6bJOt2mXh6wvWev6GOEAJsVg1HBw0Lcz+nO6JbHzA+HcZrg== X-Received: by 2002:adf:d084:: with SMTP id y4mr9977127wrh.374.1586366897448; Wed, 08 Apr 2020 10:28:17 -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 127sm255252wmd.38.2020.04.08.10.28.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Apr 2020 10:28:16 -0700 (PDT) From: Bob Hinden Message-Id: <3F26D0A8-28DE-4F35-B4B9-2346A8AED46F@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_224FC101-52C7-4154-AC56-0E071A640664"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Wed, 8 Apr 2020 10:28:12 -0700 In-Reply-To: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> Cc: Bob Hinden , architecture-discuss@ietf.org To: Brian Carpenter References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 08 Apr 2020 17:28:21 -0000 --Apple-Mail=_224FC101-52C7-4154-AC56-0E071A640664 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Brian, > On Apr 7, 2020, at 9:58 PM, Brian E Carpenter = wrote: >=20 > All our troubles will soon be over, apparently: >=20 > = https://www.etsi.org/newsroom/press-releases/1749-2020-04-etsi-launches-ne= w-group-on-non-ip-networking-addressing-5g-new-services Interesting. Seems to me that an application designer has a big choice here. They = can design their application/service so it works over the Internet (with = a mix of L2 technologies that includes 5G), or with this over 5G only = with what is apparently being proposed here. IMHO, this is going to be a simple choice for most. Bob --Apple-Mail=_224FC101-52C7-4154-AC56-0E071A640664 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----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl6OCawACgkQrut0EXfn u6icuwf/aTi0oDSVff6Uh7EFdw648CzEGVyvxDypt2x/klnY6ATHngriRu2dQrMB VBiGiPEyOt7SYILQhZszC6LvGVbbLOUazTrzGhlldjUy5Uo2UAxKDmBq1wg7hfV1 zfqd9ekb2Ps2cudBYrpMtGF1uZ0TlBl13AMrFoniXkzOyBFQXkoJvqScenOQESyr aMQCEvWCWab9FjA1vcQ7GXMD9M6xMw7QxmMFfKcOfdJT/yYqKrt194HvgdwIFP4+ NAdiIUlg2Ox3CZgvhxWCaHj1k4tgHlJub63zJ0XsmTmf99CbURUzT0gHk/S9YCCX 5rjkN3I+zuHc6L78hjgM+xFKMHQd8Q== =dcRU -----END PGP SIGNATURE----- --Apple-Mail=_224FC101-52C7-4154-AC56-0E071A640664-- From nobody Wed Apr 8 11:57:14 2020 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 E3AB23A0C28 for ; Wed, 8 Apr 2020 11:57:08 -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 dbqJz85hv-5I for ; Wed, 8 Apr 2020 11:57:06 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F3E13A0C25 for ; Wed, 8 Apr 2020 11:57:04 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48yD666HMxzyTc; Wed, 8 Apr 2020 20:57:02 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <20200408054204.GA6005@nic.fr> Date: Wed, 8 Apr 2020 20:57:02 +0200 Cc: Brian E Carpenter , architecture-discuss@ietf.org X-Mao-Original-Outgoing-Id: 608065022.291535-2e1a3295a70042d287baf6995832640a Content-Transfer-Encoding: quoted-printable Message-Id: <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 08 Apr 2020 18:57:09 -0000 Hi Stephane, > On 2020-04-08, at 07:42, Stephane Bortzmeyer = wrote: >=20 >>=20 >> =E2=80=A6 and you can find one thoughtful piece of discussion from = the IETF chair at the unlikely place of >>=20 >> https://datatracker.ietf.org/liaison/1677/ >=20 > It seems that IETF's answer is about another project, by ITU. Yes. I do know about the difference between ETSI and ITU-T. But the technical content (that I could find) was, at first look, = indistinguishable to me; Alissa=E2=80=99s text can be used right away as = a reply to this press release. There has been a decade of =E2=80=9Cclean slate Internet=E2=80=9D = discussion, and only ICN emerged as an interesting new architecture from = that context. So I=E2=80=99m not very optimistic with any process that = tries to relive that process. But genuine new ideas do get generated = now and then, and I would be quite interested to hear about them without = the now obligatory press release bombast on how they will create cheaper = battery technology for flying cars and cure Covid-19 at the same time. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Apr 8 12:12:57 2020 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 027283A0B73 for ; Wed, 8 Apr 2020 12:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.297 X-Spam-Level: X-Spam-Status: No, score=-0.297 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 vR20vWq40dpb for ; Wed, 8 Apr 2020 12:12:53 -0700 (PDT) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 7D73A3A0B70 for ; Wed, 8 Apr 2020 12:12:52 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.117.21]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 038JCKu1004808 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Apr 2020 12:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1586373153; x=1586459553; i=@elandsys.com; bh=zk6NVaSGx2cxhqiWlRiqEq5QblKaDoYuPWNT6VH2CRs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=MUMqtd9v02fO6/e8OYr9w2mYUDKWO41UOvz13VwF4qUrO5UcmNfSsS4zFCHsbEQsr rBil5dJJG9BFaZ9r0Tfb19ycv+PoTO/fLAerQWBAX2LxLSc43yu6LZIZ2T/BqzeKWg IY8dMHL5ddRVHvA2Bu8025BdwTrsFt6Je3mPJPgs= Message-Id: <6.2.5.6.2.20200408102605.0ba41040@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 08 Apr 2020 11:53:09 -0700 To: architecture-discuss@ietf.org From: S Moonesamy Cc: Toerless Eckert , Carsten Bormann In-Reply-To: <20200408055530.GC28965@faui48f.informatik.uni-erlangen.de> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408055530.GC28965@faui48f.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 08 Apr 2020 19:12:56 -0000 Hello, At 10:55 PM 07-04-2020, Toerless Eckert wrote: >I think there are also different opinions about >the usefulness of this overall ITU-T/IETF exchange. >And the reports in the media ensuing from it >are painfully politically charged and misleading. A past chairman of ETSI commented that ETSI has members from 80 countries [1]. The IETF, in comparison, describes itself as having a large open international community of individuals interested in the Internet. Depending on one's view of the world, it might or might not be viewed as being able to reach out to the world out there. Irrespective of whether the reports are misleading, the question is that those reports will have an impact on future decisions. >But then again, even if the exchange per se >would have been more useful IMHO, i am not >a fan of leadership-to-leadership only processes >that do not actively involve the respective >communities but post notes on rarely >visited URLs. Communication between two or more entities is usually formal. The communication is said to represent the views from each side instead of what some people describe as "speaking for myself". The "rarely visited URLs" practice was introduced by an IETF Chair. Over time, such an initiative can turn into a practice in which manufacturers or providers gain exposure for their products. I doubt that it is very effective for URLs rarely show up in search results or in industry discussions. Regards, S. Moonesamy 1. According to the ETSI web site the number is 65. From nobody Wed Apr 8 12:19:41 2020 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 7C9333A0CC6 for ; Wed, 8 Apr 2020 12:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkpsQ8vbtLeD for ; Wed, 8 Apr 2020 12:19:37 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 4628A3A0CA3 for ; Wed, 8 Apr 2020 12:19:37 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id i7so10179475edq.3 for ; Wed, 08 Apr 2020 12:19:37 -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=JS8Ik0Ma/5gT+/FWbC4Ho1i5BvlZmHjGhXUKrcNsvIA=; b=tMixMfQNnxCZRakR9mEuWotZI40+nfhRYkCXC8N7OhfFNBSZSAxQz4wpUNikAwHN2P RvIuSVFhDiN+xk2pCKnALBXM9Axm3452uxGOh+/gMDryCbERL86pCONlZUypNuHz5/hs WTtgKvP3GcCSPWO8ljF6ymVFj7dchLBbLUlGedq4vQznfjrzFMcACgjvdjP7aeRe2QBc QzKQ9mP8DNCBW0cgb4QQiYQ4XF8VYgkjxt591DQLXKl44fGOq+QoKe3W6ThruEAOrJPi TEXEhqEiIFccxbg2gW85uxiNxG4TNrjsbKSsHGUACOWp4PgB6oQdRFpEGmU48OE7aTkv bXmg== 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=JS8Ik0Ma/5gT+/FWbC4Ho1i5BvlZmHjGhXUKrcNsvIA=; b=rFmlcA3VHvzQKQepJIk5RnNxUFOWbZQvpF1MuNhTJHRi7s0c8GO7uIqSpZaWQZjzzO 9wOtho/Nn3mbTkD1AvbNtwQ9xSHhPUidsPuT7fgNTj9qF+HAG2tofTyXUDRtSHupBdq7 Jkb3zwY3UZmI3dv/PpsvhEE/OKlDWg5ThlAvH4aHJhfK3cM8X67Ao2jxSTk0iphuYVka 8kaRckzGOj3/95tP8HfaULOR3yPJ7i0eVTxsPa2T7S/MvRa80lhTyeYZ0+c3mbcztmMo ecDF2N95Sz7itFvs6aIuzN3kQEzUvLS6Bf3lrQptlj6rxz3qMFVOovOjh2YnrXBvFg9P scOw== X-Gm-Message-State: AGi0Pubwui59z3jt8bLeyztaNmhu52VjMsixGZnc9lO1EyzsqHhc2VrB zfuM3NpIumEtnCHH+JEzWJhZ9IIo8BxgFVZQFUY1SoU= X-Google-Smtp-Source: APiQypJXb379Fq2/7R6An4suCPPsZt2WCs7m8pD4eykghM8TqBcvBkOXJJJKs9G6+tLLMVzMza8nDQB9o+TDlrJGnuk= X-Received: by 2002:a50:a0c7:: with SMTP id 65mr8056386edo.7.1586373575496; Wed, 08 Apr 2020 12:19:35 -0700 (PDT) MIME-Version: 1.0 References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <3F26D0A8-28DE-4F35-B4B9-2346A8AED46F@gmail.com> In-Reply-To: <3F26D0A8-28DE-4F35-B4B9-2346A8AED46F@gmail.com> From: Scott Brim Date: Wed, 8 Apr 2020 15:19:19 -0400 Message-ID: To: Bob Hinden Cc: Brian Carpenter , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="00000000000072d8bc05a2cc61e8" Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 08 Apr 2020 19:19:40 -0000 --00000000000072d8bc05a2cc61e8 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 8, 2020 at 1:28 PM Bob Hinden wrote: > Brian, > > > On Apr 7, 2020, at 9:58 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > > > > All our troubles will soon be over, apparently: > > > > > https://www.etsi.org/newsroom/press-releases/1749-2020-04-etsi-launches-new-group-on-non-ip-networking-addressing-5g-new-services > > Interesting. > > Seems to me that an application designer has a big choice here. They can > design their application/service so it works over the Internet (with a mix > of L2 technologies that includes 5G), or with this over 5G only with what > is apparently being proposed here. > > IMHO, this is going to be a simple choice for most. > > Bob > So ... we will get this, with IP and associated protocols layered over it, and all the applications over that. --00000000000072d8bc05a2cc61e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Wed, Apr 8, 2020 at 1:28 PM Bob Hinden <bob.hinden@gmail.com> wrote:
Brian,
> On Apr 7, 2020, at 9:58 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>
> All our troubles will soon be over, apparently:
>
> https://www.etsi.org/newsroom/press-relea= ses/1749-2020-04-etsi-launches-new-group-on-non-ip-networking-addressing-5g= -new-services

Interesting.

Seems to me that an application designer has a big choice here.=C2=A0 They = can design their application/service so it works over the Internet (with a = mix of L2 technologies that includes 5G), or with this over 5G only with wh= at is apparently being proposed here.

IMHO, this is going to be a simple choice for most.

Bob

So ... we will get this, with IP and = associated protocols layered over it, and all the applications over that. <= /div>
--00000000000072d8bc05a2cc61e8-- From nobody Wed Apr 8 12:22:43 2020 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 22EF63A1609 for ; Wed, 8 Apr 2020 12:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 K6ZI0aETiYuD for ; Wed, 8 Apr 2020 12:22:40 -0700 (PDT) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 E69A53A160A for ; Wed, 8 Apr 2020 12:22:39 -0700 (PDT) Received: by mail-pj1-x1034.google.com with SMTP id l36so237016pjb.3 for ; Wed, 08 Apr 2020 12:22:39 -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=dlyqTH6/ybywIHxuaRW79uxgJOFPNAYJVMSvvDLqWtc=; b=FgoZaQLaXYtTvAShPcNfZ+7BcW/Azb6MdADdFKToL/SFS0mYtPGpcZp8PjDG9lQS5h MB1KeqRibgHOI8lVotVHFih6YYAw4914Xbsg558cykc5syQBZN1aJZD+4qc7z7y14oOj 2AQCww4Cw19Gh8wDZUXr/F0SMway6xF4osG1EZ2ABHnvSAKAd3NrH/1hELkZATwrBvbw t9Pc3OpB2gJn4GAKDxYadnHbGVs/FyOT7IxGj/nYd2SJRavvN3YN9wNYzUzErDVVCp+0 n7nublMsUAUBcP2tyh473L86IwaaWzwEtYhlx+Wwx+dq7SAbj59J4LuXkznOEfBMuql0 12PQ== 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=dlyqTH6/ybywIHxuaRW79uxgJOFPNAYJVMSvvDLqWtc=; b=sh7BS7QauXBTiC3aB9ywFcIxgiPHg6WNtzWaKcg8Rrprg4RRAmbEYl4U1KhI2SI7GI 2ZIiBAujfrbr/3j1IrAkJ8CyVxJz0rQMHA+W+V9eA0gawejOWVhy8ThGSQHdXNafIXkT WSmWrHXFjkaiNoFHg14C+j4Ww6tIJ64C39eiJk5mqZMSalJJSV0lalJ+Slk40WmBPef0 3LU+szwMVnue0Y64SpfXs6EQqfdr/HauJr9c81HI1D/MC3KK2NwimegTSRa4lqCZRdui K3unNgnkoORc1IV/QfSznHSR15zflwPP+IEWJi2F3WxNa5bBHWxTzZ2dho5i6xIF+bgW 7wPg== X-Gm-Message-State: AGi0PuYZXqO6K53PKIPkQ3HvTktRYHZ7G14ZnDfh2k9CtaRINe0VDQG6 0bOwPgxKZIG/JnaBWi8Z4wn22/grk5s= X-Google-Smtp-Source: APiQypKehiNnveQWh+Mf0JXvEpSZO7FHMwXD6/uip6EKT8x7UDfuI6uEPrdr1ItCF8MECwo2IX1WyA== X-Received: by 2002:a17:90a:cb14:: with SMTP id z20mr6911439pjt.170.1586373759288; Wed, 08 Apr 2020 12:22:39 -0700 (PDT) Received: from [10.95.81.208] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id i2sm17288897pfr.203.2020.04.08.12.22.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Apr 2020 12:22:38 -0700 (PDT) From: Tony Li Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_7EA94B09-051D-450B-A62A-339385033CEF" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 8 Apr 2020 12:22:37 -0700 In-Reply-To: Cc: Bob Hinden , architecture-discuss@ietf.org To: Scott Brim References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <3F26D0A8-28DE-4F35-B4B9-2346A8AED46F@gmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 08 Apr 2020 19:22:41 -0000 --Apple-Mail=_7EA94B09-051D-450B-A62A-339385033CEF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > So ... we will get this, with IP and associated protocols layered over = it, and all the applications over that.=20 Which is exactly fine. We cannot stop them from creating overlays and = as long as they are an overlay, they do not pervert the base = architecture. If they do come up with something interesting, we=E2=80=99ll be able to = integrate it. Tony --Apple-Mail=_7EA94B09-051D-450B-A62A-339385033CEF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
So ... we will get = this, with IP and associated protocols layered over it, and all the = applications over that. 


Which is = exactly fine.  We cannot stop them from creating overlays and as = long as they are an overlay, they do not pervert the base = architecture.
If they do come up with something interesting, = we=E2=80=99ll be able to integrate it.

Tony

= --Apple-Mail=_7EA94B09-051D-450B-A62A-339385033CEF-- From nobody Wed Apr 8 12:23:11 2020 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 55F283A160A for ; Wed, 8 Apr 2020 12:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 nmJXKJcCduYB for ; Wed, 8 Apr 2020 12:23:08 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 908BD3A1609 for ; Wed, 8 Apr 2020 12:23:08 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jMGHy-0008tJ-D4; Wed, 08 Apr 2020 15:23:06 -0400 Date: Wed, 08 Apr 2020 15:23:00 -0400 From: John C Klensin To: Bob Hinden , Brian Carpenter cc: architecture-discuss@ietf.org Message-ID: In-Reply-To: <3F26D0A8-28DE-4F35-B4B9-2346A8AED46F@gmail.com> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <3F26D0A8-28DE-4F35-B4B9-2346A8AED46F@gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 08 Apr 2020 19:23:10 -0000 --On Wednesday, April 8, 2020 10:28 -0700 Bob Hinden wrote: > Brian, > >> On Apr 7, 2020, at 9:58 PM, Brian E Carpenter >> wrote: >> >> All our troubles will soon be over, apparently: >> >> https://www.etsi.org/newsroom/press-releases/1749-2020-04-ets >> i-launches-new-group-on-non-ip-networking-addressing-5g-new-s >> ervices > > Interesting. > > Seems to me that an application designer has a big choice > here. They can design their application/service so it works > over the Internet (with a mix of L2 technologies that includes > 5G), or with this over 5G only with what is apparently being > proposed here. > > IMHO, this is going to be a simple choice for most. Right. And that suggests one constructive thing that could be said to them (both the ETSI and ITU-T efforts, as Carsten points out) that is not covered by Alissa's (otherwise quite good, IMO) note. The letter, at least as I understood it, focused on the "above IP" ("above waist of hourglass") solutions with which the IETF has traditionally worked. I don't know nearly enough to have a competent opinion about whether it would help with the problems they are pointing at, but we have a long history of IP-over-foo protocols that are specific to particular physical or link layers. I assume that, if they wanted to design a specific IP-over-5G protocol (completely in line with _their_ layering model, which Alissa was too polite to point out), that the IETF would be delighted to have them do that. They might even discover, as some other developers of IP-over-foo protocols have, that they gain insights into the lower-layer design of 5G itself that enable them to make improvements. Otherwise, in addition to your observation about application designers (with which I agree unless those designers have their development costs unwritten by ETSI, ITU-T, or their members) this feels a lot like "every decade or so we need to revisit either OSI or its layer-less predecessors because we aren't good at learning (perhaps because of those strange-looking bells stuck over our heads)". If so, we should probably encourage them to charge ahead and let us know how it works out for them :-( Mumble. john From nobody Wed Apr 8 12:42:05 2020 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 A0EF23A0C8E for ; Wed, 8 Apr 2020 12:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 QSL1VWE2VeTQ for ; Wed, 8 Apr 2020 12:42:00 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66EA23A0B7D for ; Wed, 8 Apr 2020 12:41:59 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 52B6E548015; Wed, 8 Apr 2020 21:41:54 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 49D13440040; Wed, 8 Apr 2020 21:41:54 +0200 (CEST) Date: Wed, 8 Apr 2020 21:41:54 +0200 From: Toerless Eckert To: Carsten Bormann Cc: Stephane Bortzmeyer , architecture-discuss@ietf.org Message-ID: <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 08 Apr 2020 19:42:03 -0000 On Wed, Apr 08, 2020 at 08:57:02PM +0200, Carsten Bormann wrote: > Hi Stephane, > > > On 2020-04-08, at 07:42, Stephane Bortzmeyer wrote: > > > >> > >> ??? and you can find one thoughtful piece of discussion from the IETF chair at the unlikely place of > >> > >> https://datatracker.ietf.org/liaison/1677/ > > > > It seems that IETF's answer is about another project, by ITU. > > Yes. I do know about the difference between ETSI and ITU-T. > But the technical content (that I could find) was, at first look, indistinguishable to me; Alissa???s text can be used right away as a reply to this press release. >From Alissa's statement: "The IETF maintains copyright and change control for the IP specifications..." That fact is AFAIK the reason why ETSI choose expicitly call their effort "Non IP", even if it might come up with proposals that for reasons of global adoption might better be done within the IETF. That and the probably more limited scope of networks considered is probably the key difference to ITU-T goals. Alissas liaison statement goes on to give IMHO a correct but ineffective explanation how contributors from other SDOs can come to IETF. Given how this is a leadership-to-leadership exchange, i would be surprised if any relevant amount of ITU contributors would even be made aware of Alissas text explicitly and officially by ITU. Which is IMHO the same on the reverse side. When would have IETF leadership ever have tried to explain/help IETF attendants to do better work in another SDO ? Which meeting did i miss about this ? Maybe with the small exception of RTCweb and W3C (or maybe even more in APP, i am not that much involved there). IMHO, IETF leadership would be well helping IETF by figuring out a better outreach method to other SDO than such liaison statements. But of course there is the main issues of SDOs first trying to fight for their own survival and relevance. > There has been a decade of ???clean slate Internet??? discussion, and only ICN emerged as an interesting new architecture from that context. So I???m not very optimistic with any process that tries to relive that process. But genuine new ideas do get generated now and then, and I would be quite interested to hear about them without the now obligatory press release bombast on how they will create cheaper battery technology for flying cars and cure Covid-19 at the same time. Flying cars give 3 dimensions of social distancing. Obvious Covid-19 solution. Our IETF issue to make more progress than we do is IMHO rooted that we conflate everything into one concept "Internet". In reality, "Internet" is one instance of an overlay "Internetwork Layer" running on at least one or more interconnected "Network Layers", such as formed by IP/MPLS or IPv4/IPv6 or SRv6. And then we apply one architecture (RFC8200) to the often contradictory requirements of Internetwork and Network layers and wonder why we have problems. If we would at least acknowledge this architecture and fundamental difference in requirements, it would be a lot easier not only for IETF to make progress, but also for more specialized SDOs to propose enhancements for the Network Layer in networks they are interested in (5G) and i think they would have a lot more interest to fit their work into an IETF lead overall Internetwork Layer + Network Layer(s) architecture. I think IETF is just going through puberty, having to evolve from reactive to proactive: When technologies are young, you just let engineers innovate and implement and when everything is done, you can go and fight for it to get standardized. When an industries becomes more mature and a lot more capital investment heavy, you need to revert this and SDOs need to play a lot more proactive role in defining next-gen solutions. See 3GPP. IETF is not doing this at the architecture scale. Only at small incremental enhancements. Cheers Toerless > Grüße, Carsten > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Wed Apr 8 12:56:31 2020 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 72E423A167A for ; Wed, 8 Apr 2020 12:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 BLlIP2z5jmIc for ; Wed, 8 Apr 2020 12:56:28 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58463A163E for ; Wed, 8 Apr 2020 12:56:27 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 9DE0B548015; Wed, 8 Apr 2020 21:56:22 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 9596E440040; Wed, 8 Apr 2020 21:56:22 +0200 (CEST) Date: Wed, 8 Apr 2020 21:56:22 +0200 From: Toerless Eckert To: S Moonesamy Cc: architecture-discuss@ietf.org Message-ID: <20200408195622.GK28965@faui48f.informatik.uni-erlangen.de> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408055530.GC28965@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200408102605.0ba41040@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20200408102605.0ba41040@elandnews.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 08 Apr 2020 19:56:30 -0000 Thanks, S. inline On Wed, Apr 08, 2020 at 11:53:09AM -0700, S Moonesamy wrote: > Hello, > At 10:55 PM 07-04-2020, Toerless Eckert wrote: > > I think there are also different opinions about > > the usefulness of this overall ITU-T/IETF exchange. > > And the reports in the media ensuing from it > > are painfully politically charged and misleading. [...] > > Irrespective of whether the reports are misleading, the question is that > those reports will have an impact on future decisions. Definitely, but most people looking at those reports in the media will not even understand the nature of how or why they where created: To sell one particular political view, however tainted, wrong and misleading the result is. Alas, there is really no good investigative journalism in our field that would expose how this is e.g.: a fight for votes in next ITU-T round of decision making. > > But then again, even if the exchange per se > > would have been more useful IMHO, i am not > > a fan of leadership-to-leadership only processes > > that do not actively involve the respective > > communities but post notes on rarely > > visited URLs. > > Communication between two or more entities is usually formal. The > communication is said to represent the views from each side instead of what > some people describe as "speaking for myself". The key word of my criticism is "only". None of what done in liaison is per-se bad, its just too isolated from the communities. But i am of course repeating just my core ask to have a more open architecture evolution forum in the IAB/IETF to be able to more effectiely pull in possible contributors from other SDOs. Heck, think of a track where you start to inviting 3GPP, ETSI, ITU-T and other SDO presenters, ask them to present what they do and their thoughts how it should impact the future of IETF work. And make sure the time planning allows double the amount of time for IETF participants to discuss. And hopefully help them to understand where/how that integration could be suggested/done via specific contributions to IETF. (and be careful in selecting whom to invite so you do not end up with administrative slide deck readers). > The "rarely visited URLs" practice was introduced by an IETF Chair. Over > time, such an initiative can turn into a practice in which manufacturers or > providers gain exposure for their products. I doubt that it is very > effective for URLs rarely show up in search results or in industry > discussions. Indeed. The problem though is to figure out how to get to more effective forms of actual architecture/engineering process and not to better marketing mechanisms. Then again, given how ossified our industry is, there is unfortunately something to be said about scaring people to wake up, even though i do not like it. Cheers Toerless > Regards, > S. Moonesamy > > 1. According to the ETSI web site the number is 65. > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Wed Apr 8 13:07:39 2020 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 0C0223A1646 for ; Wed, 8 Apr 2020 13:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 I_CuERdg2yYX for ; Wed, 8 Apr 2020 13:07:36 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 439A13A1093 for ; Wed, 8 Apr 2020 13:07:36 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 45BA2548017; Wed, 8 Apr 2020 22:07:31 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 3D344440040; Wed, 8 Apr 2020 22:07:31 +0200 (CEST) Date: Wed, 8 Apr 2020 22:07:31 +0200 From: Toerless Eckert To: Tony Li Cc: Scott Brim , architecture-discuss@ietf.org Message-ID: <20200408200731.GL28965@faui48f.informatik.uni-erlangen.de> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <3F26D0A8-28DE-4F35-B4B9-2346A8AED46F@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 08 Apr 2020 20:07:38 -0000 On Wed, Apr 08, 2020 at 12:22:37PM -0700, Tony Li wrote: > > So ... we will get this, with IP and associated protocols layered over it, and all the applications over that. > > > Which is exactly fine. We cannot stop them from creating overlays and as long as they are an overlay, they do not pervert the base architecture. > If they do come up with something interesting, we???ll be able to integrate it. Indeed. See my email about us not even acknowleding architecturally our own layering (Network / Internetwork). If a new underlay ("Network Layer") from 3GPP or some other SDO would define great new better than best effort service distinctions, IETF would be really bad & slow on mapping these into end-to-end service distinction controllable by applications. "Please try to figure out how your new underlay fits into the crappy DiffServ Model of the IETF". Alas, i think as bad as IETF is, any other network layer SDO work is worse. When 3GPP did broadcast services (3G times ?), it didn't even bother to map it to IP multicast on top of it, but expected every application to implement against their new isolated service interface. Guess how successful that was. Toerless > Tony > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Wed Apr 8 13:09:08 2020 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 F32063A1678 for ; Wed, 8 Apr 2020 13:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFb0Cg3jT8A7 for ; Wed, 8 Apr 2020 13:09:05 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 A9A023A1676 for ; Wed, 8 Apr 2020 13:09:04 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id q19so9013427ljp.9 for ; Wed, 08 Apr 2020 13:09:04 -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=QxpzBjVqi2G8/Mii1rMo99aeoazI0wt5SPN5OOWRv3Y=; b=MD1at7yYXaFbcWhPc36ybv5YRfHZd5tCWvDHsH/6VDtJNtD6z2+b4+EgyUWzwik5o5 dx0VYznZOo4Dw6ouioI/6lehdELkbDzs3+ljJUdIy5OnU45xkMYz2PsVmBNLAtv4xs0o rggKWxZYlErGT+V0XUCdEYhBI5OZ5lGulxFTRDjM+AiBTO1ps+KOcDVgotl9rtLrrdXQ ZjFRHFtUYO4PEf5LWK32WfCHBjqd6xL8MDAV0X94j+fD65vPyIReXVsrEpcXP4U+5BGY f9HCKpC8Syt5YdHytxT0Wbwgb8BcmFVSYuhkpyJJAQ5BhtKUWOJGz4IVdzcRyGIHVFVU SEVQ== 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=QxpzBjVqi2G8/Mii1rMo99aeoazI0wt5SPN5OOWRv3Y=; b=nsztIbSKWeAI+aZgnyo3bz1WzN94lOeGchj+AGx9vCkzZeSraJzqUrlFl+dIVTCY55 DuXV52zvLwtRg8ww5DDKlXrEpyTPNlnFDxzMxF5a2ImtHb34847mGp49FIbbNgRzjfRk 99Dl2i5gcT59gXQjeYlQqMw7E/XBknHveGLBGB+sTBACcYDCZtuKmIfQ+A/T2TuuRVN+ 3qzjW3o7ELipDsVQXicjDnuPO3dC20P5iN4ycdD4vANgoz4ZfXr+i2hxHWWw/3fLdp+c kG65bfEkNVELBdeyG4hlP1gx5YkTJyB0LHoy82lhD+6/ubOv6frrk23AatkjlPe/CkZC 9XAw== X-Gm-Message-State: AGi0PuYtz0G8P7YUnBTdrMsvBSq26EXMBspRTRtKejoW1Dwm6/3tkJn3 Bimpm9jnwDalBJOqrTw1qbFA83obunZWzD9HU2M= X-Google-Smtp-Source: APiQypLoYPRkZoQWrj80T/8zbKrjrpmI0w5gRckmT2/igomcp11YBFS5DMuWV4s4AiJOeJt3txLpW6idW7WEVb37q8M= X-Received: by 2002:a2e:7e06:: with SMTP id z6mr6269135ljc.60.1586376542890; Wed, 08 Apr 2020 13:09:02 -0700 (PDT) MIME-Version: 1.0 References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <3F26D0A8-28DE-4F35-B4B9-2346A8AED46F@gmail.com> In-Reply-To: From: Spencer Dawkins at IETF Date: Wed, 8 Apr 2020 15:08:36 -0500 Message-ID: To: John C Klensin Cc: Bob Hinden , Brian Carpenter , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="00000000000051ad7105a2cd1252" Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 08 Apr 2020 20:09:07 -0000 --00000000000051ad7105a2cd1252 Content-Type: text/plain; charset="UTF-8" For what it's worth, On Wed, Apr 8, 2020 at 2:23 PM John C Klensin wrote: > > > --On Wednesday, April 8, 2020 10:28 -0700 Bob Hinden > wrote: > > > Brian, > > > >> On Apr 7, 2020, at 9:58 PM, Brian E Carpenter > >> wrote: > >> > >> All our troubles will soon be over, apparently: > >> > >> https://www.etsi.org/newsroom/press-releases/1749-2020-04-ets > >> i-launches-new-group-on-non-ip-networking-addressing-5g-new-s > >> ervices > > > > Interesting. > > > > Seems to me that an application designer has a big choice > > here. They can design their application/service so it works > > over the Internet (with a mix of L2 technologies that includes > > 5G), or with this over 5G only with what is apparently being > > proposed here. > > > > IMHO, this is going to be a simple choice for most. > > Right. And that suggests one constructive thing that could be > said to them (both the ETSI and ITU-T efforts, as Carsten points > out) that is not covered by Alissa's (otherwise quite good, IMO) > note. The letter, at least as I understood it, focused on the > "above IP" ("above waist of hourglass") solutions with which the > IETF has traditionally worked. I don't know nearly enough to > have a competent opinion about whether it would help with the > problems they are pointing at, but we have a long history of > IP-over-foo protocols that are specific to particular physical > or link layers. I assume that, if they wanted to design a > specific IP-over-5G protocol (completely in line with _their_ > layering model, which Alissa was too polite to point out), that > the IETF would be delighted to have them do that. They might > even discover, as some other developers of IP-over-foo protocols > have, that they gain insights into the lower-layer design of 5G > itself that enable them to make improvements. > THIS. I've deleted multiple replies in this thread, but I'd really like to see that mentioned in a liaison response ... pointed somewhere. I don't see ETSI listed as a formal liaison at https://www.ietf.org/about/liaisons/, but note that (1) ETSI is one of the "partners" in 3GPP, (2) 3GPP has many thoughts about 5G, which might or might not map onto this ETSI project, and (3) Gonzalo Camarillo is still listed as the IETF's liaison manager to 3GPP, which seems like an excellent resource we might want to involve. Perhaps that's (also?) a fruitful place to engage on this topic. Best, Spencer > Otherwise, in addition to your observation about application > designers (with which I agree unless those designers have their > development costs unwritten by ETSI, ITU-T, or their members) > this feels a lot like "every decade or so we need to revisit > either OSI or its layer-less predecessors because we aren't good > at learning (perhaps because of those strange-looking bells > stuck over our heads)". If so, we should probably encourage > them to charge ahead and let us know how it works out for them > :-( > > Mumble. > john > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --00000000000051ad7105a2cd1252 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For what=C2=A0it's worth,=C2=A0
=
On Wed= , Apr 8, 2020 at 2:23 PM John C Klensin <john-ietf@jck.com> wrote:


--On Wednesday, April 8, 2020 10:28 -0700 Bob Hinden
<bob.hinden@gm= ail.com> wrote:

> Brian,
>
>> On Apr 7, 2020, at 9:58 PM, Brian E Carpenter
>> <brian.e.carpenter@gmail.com> wrote:
>>
>> All our troubles will soon be over, apparently:
>>
>> https://www.etsi.org/newsroom/= press-releases/1749-2020-04-ets
>> i-launches-new-group-on-non-ip-networking-addressing-5g-new-s
>> ervices
>
> Interesting.
>
> Seems to me that an application designer has a big choice
> here.=C2=A0 They can design their application/service so it works
> over the Internet (with a mix of L2 technologies that includes
> 5G), or with this over 5G only with what is apparently being
> proposed here.
>
> IMHO, this is going to be a simple choice for most.

Right.=C2=A0 And that suggests one constructive thing that could be
said to them (both the ETSI and ITU-T efforts, as Carsten points
out) that is not covered by Alissa's (otherwise quite good, IMO)
note.=C2=A0 The letter, at least as I understood it, focused on the
"above IP" ("above waist of hourglass") solutions with = which the
IETF has traditionally worked.=C2=A0 I don't know nearly enough to
have a competent opinion about whether it would help with the
problems they are pointing at, but we have a long history of
IP-over-foo protocols that are specific to particular physical
or link layers.=C2=A0 I assume that, if they wanted to design a
specific IP-over-5G protocol (completely in line with _their_
layering model, which Alissa was too polite to point out), that
the IETF would be delighted to have them do that.=C2=A0 They might
even discover, as some other developers of IP-over-foo protocols
have, that they gain insights into the lower-layer design of 5G
itself that enable them to make improvements.

THIS.=C2=A0

I've deleted multiple repli= es in this thread, but I'd really like to see that mentioned in a liais= on response ... pointed somewhere.=C2=A0

I don'= ;t see ETSI listed as a formal liaison at=C2=A0https://www.ietf.org/about/liaisons/, but note tha= t (1) ETSI is one of the "partners" in 3GPP, (2) 3GPP has many th= oughts about 5G, which might or might not map onto this ETSI project, and (= 3) Gonzalo Camarillo is still listed as the IETF's liaison manager to 3= GPP, which seems like an excellent resource we might want to involve.=C2=A0=

Perhaps that's (also?) a fruitful place to en= gage on this topic.

Best,

Spencer
=C2=A0
Otherwise, in addition to your observation about application
designers (with which I agree unless those designers have their
development costs unwritten by ETSI, ITU-T, or their members)
this feels a lot like "every decade or so we need to revisit
either OSI or its layer-less predecessors because we aren't good
at learning (perhaps because of those strange-looking bells
stuck over our heads)".=C2=A0 =C2=A0If so, we should probably encourag= e
them to charge ahead and let us know how it works out for them
:-(

Mumble.
=C2=A0 =C2=A0john

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--00000000000051ad7105a2cd1252-- From nobody Wed Apr 8 13:48:47 2020 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 3E0F23A1788 for ; Wed, 8 Apr 2020 13:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gksbpaLfIExq for ; Wed, 8 Apr 2020 13:48:44 -0700 (PDT) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 E42D43A18A9 for ; Wed, 8 Apr 2020 13:48:22 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id g2so2972253plo.3 for ; Wed, 08 Apr 2020 13:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=3zL3WJaFzP+43HA5jNDq+j3uAvELFb0E0CsOeDKT0FI=; b=g2QFf3tj3IAQMP3eC+nt2PucrIsfZbXPP0S4LQXyOuLmja3eUT6aUAOuQc5+XomFPF 2T9wNgnq3khuyQaeRPBEQqC6pbLUYkU0vb4D0y7IOFzkK7kHoBFf1DFtLRWQKgBLH/YX tG6A6lTDrK6kSmfjqWUElg8py7QpYqm+2qdNVJfv0N0bMyPLJzmlDISHBv9npwuZSnv8 feA+mPI186oF6w4opS9FOy6ugLysQ3Hl8EBPLv4X+75rrdpPIW+bMCn9HB5RI6A5bwQM xm16xV4Ql8nGZdOCDaw8t6M6JyHqhLqaPKlFbXvhj7wuOO1JQTjsS8H2nQAW7vks/sd9 OqMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3zL3WJaFzP+43HA5jNDq+j3uAvELFb0E0CsOeDKT0FI=; b=c12g9m/3j0hM2aebPgyH13sMIe+Ocvmn4MRzBCrj7jxRBsOj8YSFD2eSQYvT4iv3DM GqwFCR15aOH+o/C9x8HZl8WKYa86fGWDD4Ptf0EZS4HhXHtL2MhOmQ69ZpwqFxEgJpGZ SA5x+jLj3cnei9bDx/iInJhZqGlbCLA7asjQzLix8+xUE7KkWB3aR0jGmnu9DZfixtU3 W5y314gngP0SlmNcYHua/pP8auUex/sJWVNMmnaTPiDGloJScavFzz3jS5a9drH8NNkI HhcsvjLrXpZC00YzBV48rfd+9uSmuJXGbUgD/J855oJB54JneUBZxVtL7rHtkRp9aetX JICQ== X-Gm-Message-State: AGi0PuZRABp65Nzcj4IeGujGpHJObgi9friwdNNMv9oWb4WY4jg1b+dp bQ0RcpOWaIYo/DbwKyGMc2mrDjYI X-Google-Smtp-Source: APiQypLS+Dh5tzVZNiWcSWHW8bSM6fL8ZtX/Bq7MiINcnCQ7O/rrQR8f6HY42wKptvvvofPFRzWAaA== X-Received: by 2002:a17:902:6ac9:: with SMTP id i9mr9184855plt.35.1586378901993; Wed, 08 Apr 2020 13:48:21 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id z5sm2988337pfz.209.2020.04.08.13.48.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Apr 2020 13:48:21 -0700 (PDT) To: Toerless Eckert , Carsten Bormann Cc: architecture-discuss@ietf.org References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408055530.GC28965@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: <551a2b4b-3cba-880d-e715-ecfbf138dc4c@gmail.com> Date: Thu, 9 Apr 2020 08:48:18 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20200408055530.GC28965@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 08 Apr 2020 20:48:46 -0000 Hi Toerless, On 08-Apr-20 17:55, Toerless Eckert wrote: > I think there are also different opinions about > the usefulness of this overall ITU-T/IETF exchange. > And the reports in the media ensuing from it > are painfully politically charged and misleading. >=20 > But then again, even if the exchange per se > would have been more useful IMHO, i am not > a fan of leadership-to-leadership only processes > that do not actively involve the respective > communities but post notes on rarely > visited URLs. The formality of our interaction with ITU-T, ETSI (and ISO/IEC) has never been *our* choice; it was forced on us many years ago by those organizations. Nobody from those organizations has ever been denied admission to any IETF discussion. The converse is not true. Brian > This form of communications reminds me of: >=20 > ...All the planning charts and demolition > orders have been on display at your local > planning department in Alpha Centauri... >=20 > The media reports also sound like Douglas Adams. >=20 > Cheers > Toerless > =20 > On Wed, Apr 08, 2020 at 06:59:54AM +0200, Carsten Bormann wrote: >> On 2020-04-08, at 06:58, Brian E Carpenter wrote: >>> >>> All our troubles will soon be over, apparently: >>> >>> https://www.etsi.org/newsroom/press-releases/1749-2020-04-etsi-launch= es-new-group-on-non-ip-networking-addressing-5g-new-services >> >> ??? and you can find one thoughtful piece of discussion from the IETF = chair at the unlikely place of >> >> https://datatracker.ietf.org/liaison/1677/ >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 From nobody Wed Apr 8 13:53:53 2020 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 962DE3A1731 for ; Wed, 8 Apr 2020 13:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 qPuZaU4mCIS6 for ; Wed, 8 Apr 2020 13:53:44 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38C713A17BD for ; Wed, 8 Apr 2020 13:53:43 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B32A8548048; Wed, 8 Apr 2020 22:53:38 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id A9FAF440040; Wed, 8 Apr 2020 22:53:38 +0200 (CEST) Date: Wed, 8 Apr 2020 22:53:38 +0200 From: Toerless Eckert To: John C Klensin Cc: Bob Hinden , Brian Carpenter , architecture-discuss@ietf.org Message-ID: <20200408205338.GM28965@faui48f.informatik.uni-erlangen.de> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <3F26D0A8-28DE-4F35-B4B9-2346A8AED46F@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 08 Apr 2020 20:53:52 -0000 John, I think 3GPP 3/4/5/6G is not a fitting example to apply the IP-over-foo approach. 4G/5G "core" networks effectively are overlays on top of of some typically IP based transport network. Today the overlay nodes are mostly software in edge-data-centers/pops. So its more naturally an overlay. There is some liaison process whereby IETF technologies are pitching their benefits to 3GPP if used an an underlay (i reall having heard about this for SRv6 or LISP). Yet, 3GPP seems to prefer not to really change anything fundamental in their overlay architecture from what i've been told (only tangentially watching this). "Only simple, minimal layering integration is good integration". The more fundamental problem is that the mobile services in most service providers are where the money is coming from, so now they want to re-design the hardware underlay in their name, aka: the actual physical network infrastructure besides DCs and radio towers. And i think 3GPP has no clue what to do there exactly. But i am sure that something strange will evolve. Cheers Toerless On Wed, Apr 08, 2020 at 03:23:00PM -0400, John C Klensin wrote: > > > --On Wednesday, April 8, 2020 10:28 -0700 Bob Hinden > wrote: > > > Brian, > > > >> On Apr 7, 2020, at 9:58 PM, Brian E Carpenter > >> wrote: > >> > >> All our troubles will soon be over, apparently: > >> > >> https://www.etsi.org/newsroom/press-releases/1749-2020-04-ets > >> i-launches-new-group-on-non-ip-networking-addressing-5g-new-s > >> ervices > > > > Interesting. > > > > Seems to me that an application designer has a big choice > > here. They can design their application/service so it works > > over the Internet (with a mix of L2 technologies that includes > > 5G), or with this over 5G only with what is apparently being > > proposed here. > > > > IMHO, this is going to be a simple choice for most. > > Right. And that suggests one constructive thing that could be > said to them (both the ETSI and ITU-T efforts, as Carsten points > out) that is not covered by Alissa's (otherwise quite good, IMO) > note. The letter, at least as I understood it, focused on the > "above IP" ("above waist of hourglass") solutions with which the > IETF has traditionally worked. I don't know nearly enough to > have a competent opinion about whether it would help with the > problems they are pointing at, but we have a long history of > IP-over-foo protocols that are specific to particular physical > or link layers. I assume that, if they wanted to design a > specific IP-over-5G protocol (completely in line with _their_ > layering model, which Alissa was too polite to point out), that > the IETF would be delighted to have them do that. They might > even discover, as some other developers of IP-over-foo protocols > have, that they gain insights into the lower-layer design of 5G > itself that enable them to make improvements. > > Otherwise, in addition to your observation about application > designers (with which I agree unless those designers have their > development costs unwritten by ETSI, ITU-T, or their members) > this feels a lot like "every decade or so we need to revisit > either OSI or its layer-less predecessors because we aren't good > at learning (perhaps because of those strange-looking bells > stuck over our heads)". If so, we should probably encourage > them to charge ahead and let us know how it works out for them > :-( > > Mumble. > john > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Wed Apr 8 13:54:30 2020 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 29C033A1731 for ; Wed, 8 Apr 2020 13:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 U7Po3Xa3ieCA for ; Wed, 8 Apr 2020 13:54:27 -0700 (PDT) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 5BB0F3A1734 for ; Wed, 8 Apr 2020 13:54:27 -0700 (PDT) Received: by mail-vs1-xe31.google.com with SMTP id u9so5625200vsp.6 for ; Wed, 08 Apr 2020 13:54:27 -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=lQae09yAo+e4iM3OaWhk92fljUVLfkCSTcNQptstAw0=; b=e0j0g6vP4wTygOKAb1SQWGbXZJkhrQ673X1YNRNaOo/qOSClQJJapsrfJbxNx0/le6 /F8KhId1IU6Zz9zknLam/aGWb+/EkmfRigmqG+FYddvScQJyfEB+GSap6QSe9rr0wqbN d52pvM+iftSt96tDaObnZlNAUaI/NBmOPyBeQiilLTJpXhip7dNgCmf5Wikh8YYnkh5O GOL2NRm6+2qkfCjCwY6yOmFyzXkOW4V41gxE6lRkGMZB9oBetR5Xy6IWe5GsT51OHTsW DlQbNyvkUBeemaUvxp53esiJWi2pEVImrHm9TDEGQ5+J4gg26GqJWaA+AmQSlS2ZWm/L VhAw== 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=lQae09yAo+e4iM3OaWhk92fljUVLfkCSTcNQptstAw0=; b=sObopRLON2uX1Bj8OoLin6NUAOJ2SzVAg1Gw9IIt6PDOYUDNEd5x6IOIxiwm4EJv8x oKxgUnGJGOXYVrvhU4bqPBD5taTXmBG1byybXbCefDkKEkN9B52oP5aYL2wGj7R/eb1f Rv1SewB1N6ZB8QsvDLWJbKm8Mqsx/wESI+ZskmkjrGDEYHZ1QOjYuHtH8fN1cU/riVD4 Eck4t8RAI2uBTFqPWKzNYtluk3UaFC3fFyaTDWb+KPO2Sh7k+8gB0qdLD+VzP6Y0Z6nO 4GsrIpchIvE44oTxmc+FS4hSvGKOvro1uu/RvsrL4aYeqHhUHcQVm/UqsLPIkYHS/oGG wR8Q== X-Gm-Message-State: AGi0Pub6N4Dl5D42OAbe5P6hPpm1WS/acE4vNu6HNAQ0KNCNBtKYOBgw 6DUvDneZCvc5ON/QnElJgdyWbjJ1xB1LvTYwyNM= X-Google-Smtp-Source: APiQypJqAhTqTi3qbLDHbN0uvJOtUhJQC4bFt7fADqZD2jKpAY0WurvdbUlHKyHQu+p2EPgb3pDAXfEkGpkghXsfTSA= X-Received: by 2002:a67:2247:: with SMTP id i68mr7383503vsi.19.1586379266295; Wed, 08 Apr 2020 13:54:26 -0700 (PDT) MIME-Version: 1.0 References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <3F26D0A8-28DE-4F35-B4B9-2346A8AED46F@gmail.com> In-Reply-To: From: Uma Chunduri Date: Wed, 8 Apr 2020 13:54:30 -0700 Message-ID: To: John C Klensin Cc: Bob Hinden , Brian Carpenter , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="000000000000a588a705a2cdb4f1" Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 08 Apr 2020 20:54:29 -0000 --000000000000a588a705a2cdb4f1 Content-Type: text/plain; charset="UTF-8" I assume that, if they wanted to design a > specific IP-over-5G protocol (completely in line with _their_ layering model, which Alissa was too polite to point out), that the IETF would be delighted to have them do that. GTP Layer. I guess, it's there for 20+ years and serving them fine (hopefully). As far as I understand, there aspects on underlay that need to be dealt with to get some of the new services. The underlay (IP and MPLS) are IETF protocols I see more flexibility beyond what these underlays offer. Else one can put the edge close to base station (the "new edge compute" to avoid the traffic on best effort IP layer). Can they? I second Toerless and we as IETF community ought to have more broader discussions to nail down actual requirements. Cheers! -- Uma C. > --000000000000a588a705a2cdb4f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I assume that, if they wanted to design a
specific IP-over-5G protocol (completely in line with _their_
<= /div>
layering model, which Alissa was too polite to point out), that
the IETF would be delighted to have them do that.=C2=A0
= =C2=A0
GTP Layer.=C2=A0I guess, it's there for = 20+ years and serving them fine (hopefully).=C2=A0

As fa= r as I understand, there aspects on underlay that need to be dealt with to = get=C2=A0 some of the new services.
The underlay (IP and MPLS) ar= e IETF protocols I see more flexibility beyond what these underlays offer.<= /div>
Else one can put the edge close to base station (the "new ed= ge compute" to avoid the traffic on best effort IP layer). Can they?

I second Toerless and we as IETF community ought to= have more broader discussions to nail down actual requirements.
=


Cheers!
--
Uma C.





--000000000000a588a705a2cdb4f1-- From nobody Wed Apr 8 14:24:39 2020 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 F11643A17B9 for ; Wed, 8 Apr 2020 14:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 9_13W40PdLkK for ; Wed, 8 Apr 2020 14:24:35 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EADCD3A17B8 for ; Wed, 8 Apr 2020 14:24:34 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 81738548017; Wed, 8 Apr 2020 23:24:29 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 78F64440040; Wed, 8 Apr 2020 23:24:29 +0200 (CEST) Date: Wed, 8 Apr 2020 23:24:29 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Carsten Bormann , architecture-discuss@ietf.org Message-ID: <20200408212429.GN28965@faui48f.informatik.uni-erlangen.de> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408055530.GC28965@faui48f.informatik.uni-erlangen.de> <551a2b4b-3cba-880d-e715-ecfbf138dc4c@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <551a2b4b-3cba-880d-e715-ecfbf138dc4c@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 08 Apr 2020 21:24:37 -0000 On Thu, Apr 09, 2020 at 08:48:18AM +1200, Brian E Carpenter wrote: > The formality of our interaction with ITU-T, ETSI (and ISO/IEC) > has never been *our* choice; it was forced on us many years > ago by those organizations. The IETF process of keeping this liaison a leadership only exercise within the IETF surely was not forced upon us by other SDOs. > Nobody from those organizations has ever been denied admission > to any IETF discussion. Being open is not the same as being inviting or proactive. > The converse is not true. Yes, it is quite weird to think that government policy based admission to a telecommunications standard body was ever considered to be a good idea. I have only come to experience it as a weapon in an economic war of aggression. And IETF is not even marketing itself as being superior over such standard bodies using those type of examples. Toerless > Brian > > > This form of communications reminds me of: > > > > ...All the planning charts and demolition > > orders have been on display at your local > > planning department in Alpha Centauri... > > > > The media reports also sound like Douglas Adams. > > > > Cheers > > Toerless > > > > On Wed, Apr 08, 2020 at 06:59:54AM +0200, Carsten Bormann wrote: > >> On 2020-04-08, at 06:58, Brian E Carpenter wrote: > >>> > >>> All our troubles will soon be over, apparently: > >>> > >>> https://www.etsi.org/newsroom/press-releases/1749-2020-04-etsi-launches-new-group-on-non-ip-networking-addressing-5g-new-services > >> > >> ??? and you can find one thoughtful piece of discussion from the IETF chair at the unlikely place of > >> > >> https://datatracker.ietf.org/liaison/1677/ > >> > >> Grüße, Carsten > >> From nobody Wed Apr 8 14:33:23 2020 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 4BE703A17F2 for ; Wed, 8 Apr 2020 14:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXLnjThrceYh for ; Wed, 8 Apr 2020 14:33:20 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 745263A17EF for ; Wed, 8 Apr 2020 14:33:19 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id h6so6365749lfc.0 for ; Wed, 08 Apr 2020 14:33:19 -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=AZh4k2OXMBQNnLw7OHoykkWbwpKJipYvdU9D7D0zW6M=; b=ijCVnjjCi1pN2E2w/QbA3qcKyte9yHoa9l9+9PferlAMKAdJbvhf8TI6Fh3UEOfmbP 2PLo8XHkc7g53C4NuqL8G8LCgUj4lDCG6Iq/ZP3KInERS5OjI/3PtBNZsb63AR4aMYx7 PhLl4DxAK8NyOfuke1pIGRiYs0OK3+/gYSTC7wsV89RvhJzXsXPSAHvB8X2fEjzomSF6 1sNbUqjQaYhqJF/l0T7oW0KjHfk2ZLrsMoCrb1l7bqajsd9w+OVWo6S/Je+NujhaqWLn lMB9E5hTi6u8zqSLhHNxBbTK1+voj5nRLhKSjTqpm14NTyoHawfLBrMtdI6acqpfBN1A 4gXw== 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=AZh4k2OXMBQNnLw7OHoykkWbwpKJipYvdU9D7D0zW6M=; b=U0irU2aYsJfzIObkvRG+D49l65ZesiV8e+tLbQavf8pk5BDnlknZ2ctUV7iQLXkGew jfTel+6B8JopzuUFK57mEnqEYpsyzzwHWPFZbkxHuLKWi8I7DYWv0H9FS6qN+qWWfcma k7r8/KWGU9NKRloXn37qaMqLFDQxPXcq24RacbkdKN9FJlIv4OgfxzfrcwIJth/w8cxu 8hbeAFbSN9KTl6eeJJTtQZutKtjMwj9fO2jSeljrszeCjW37u7JP0cfW3fOnjTSoR+b5 QTMwuhYb4kr7CvdOwPx1dwbctym/5Y6fdc6TCGHnvtWtl9/ZrDAx4r1I2mi/bnRuhCV2 X3Dg== X-Gm-Message-State: AGi0PuZNvvi1uivYTsXf9UkM2CrBWgM9ozROmAfMklznr0u3r3P6q3LC uhpclzywdTCTWu5fbxaXMuNInAI0W84P4IEWWos= X-Google-Smtp-Source: APiQypJXk5nYJjSuSmX/2S8a3AZ/cN1I+wPJ99URVd7JwH0GN7/1p20pTfKuv+dfGrCVwdPvIQAe6GRidnWgGNNeafY= X-Received: by 2002:a19:7411:: with SMTP id v17mr5816179lfe.27.1586381597384; Wed, 08 Apr 2020 14:33:17 -0700 (PDT) MIME-Version: 1.0 References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408055530.GC28965@faui48f.informatik.uni-erlangen.de> <551a2b4b-3cba-880d-e715-ecfbf138dc4c@gmail.com> <20200408212429.GN28965@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200408212429.GN28965@faui48f.informatik.uni-erlangen.de> From: Spencer Dawkins at IETF Date: Wed, 8 Apr 2020 16:32:51 -0500 Message-ID: To: Toerless Eckert Cc: Brian E Carpenter , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="00000000000097243d05a2ce3ff3" Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 08 Apr 2020 21:33:22 -0000 --00000000000097243d05a2ce3ff3 Content-Type: text/plain; charset="UTF-8" I've gotta get back to work stuff (which this isn't, no matter how much fun as it is), but On Wed, Apr 8, 2020 at 4:24 PM Toerless Eckert wrote: (deleted down to) Yes, it is quite weird to think that government policy based > admission to a telecommunications standard body was ever > considered to be a good idea. I have only come to experience it as a > weapon in an economic war of aggression. I couldn't possibly comment ... > And IETF is not even > marketing itself as being superior over such standard bodies > using those type of examples. > Does anyone know if anything replaced https://open-stand.org/about-us/ (from 2012)? Enjoy your days/nights, of course! Best, Spencer --00000000000097243d05a2ce3ff3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
--00000000000097243d05a2ce3ff3-- From nobody Wed Apr 8 15:51:02 2020 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 AC3433A18EB for ; Wed, 8 Apr 2020 15:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.696 X-Spam-Level: X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 6yyo8BFmdhMU for ; Wed, 8 Apr 2020 15:50:56 -0700 (PDT) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 694C53A193C for ; Wed, 8 Apr 2020 15:50:56 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.117.21]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 038MoRoI027849 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Apr 2020 15:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1586386240; x=1586472640; i=@elandsys.com; bh=5ApZZGb1ueISlxURmZMC6rfyulnSkt1vPRTz8g8DJoI=; h=Date:To:From:Subject:In-Reply-To:References; b=liopvVER1ydRrwriPwyWu6aog3qjyoxgPaOZQ0aKkBrTzYZXALcwMYJV7+Nz7lwG2 8/AaauHwd70IMsRIWVBuUwXr3rDpVKJC97TkBOzVEE5NoGIa772uVF7rrOnZFbYWEp am3R19jUHXH3ZQkS2G2kH1YpS9Yk1jc9hqajnhG8= Message-Id: <6.2.5.6.2.20200408142709.0b957348@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 08 Apr 2020 15:40:09 -0700 To: Toerless Eckert , architecture-discuss@ietf.org From: S Moonesamy In-Reply-To: <20200408195622.GK28965@faui48f.informatik.uni-erlangen.de> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408055530.GC28965@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200408102605.0ba41040@elandnews.com> <20200408195622.GK28965@faui48f.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 08 Apr 2020 22:51:01 -0000 Hi Toerless, At 12:56 PM 08-04-2020, Toerless Eckert wrote: >Alas, there is really no good investigative journalism >in our field that would expose how this is e.g.: a fight >for votes in next ITU-T round of decision making. It is a cyclic event. >The key word of my criticism is "only". None of >what done in liaison is per-se bad, its just too >isolated from the communities. But i am of course >repeating just my core ask to have a more open >architecture evolution forum in the IAB/IETF to >be able to more effectiely pull in possible >contributors from other SDOs. My guess is that another SDO would have its own culture. >Heck, think of a track where you start to inviting >3GPP, ETSI, ITU-T and other SDO presenters, ask >them to present what they do and their thoughts how >it should impact the future of IETF work. And make >sure the time planning allows double the amount of >time for IETF participants to discuss. And hopefully >help them to understand where/how that integration could >be suggested/done via specific contributions to IETF. Have you watched a presentation of IETF work in a non-IETF forum? Sometimes, it is not an accurate reflection of the IETF discussions. I'd say that the above suggestion is worth a try instead of viewing it through pessimistic lenses. >(and be careful in selecting whom to invite so you do > not end up with administrative slide deck readers). Yes. >Indeed. The problem though is to figure out how to get to >more effective forms of actual architecture/engineering >process and not to better marketing mechanisms. Then again, >given how ossified our industry is, there is unfortunately >something to be said about scaring people to wake up, even >though i do not like it. I don't think that businesses would remain idle if there was an effective way to change things over the short term. Regards, S. Moonesamy From nobody Wed Apr 8 16:09:01 2020 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 E61D03A1979 for ; Wed, 8 Apr 2020 16:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_BLOCKED=0.001, 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 DXNSVasaYdmb for ; Wed, 8 Apr 2020 16:08:59 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 274243A1977 for ; Wed, 8 Apr 2020 16:08:58 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 353CC548045; Thu, 9 Apr 2020 01:08:53 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 1843B440040; Thu, 9 Apr 2020 01:08:53 +0200 (CEST) Date: Thu, 9 Apr 2020 01:08:53 +0200 From: Toerless Eckert To: S Moonesamy Cc: architecture-discuss@ietf.org Message-ID: <20200408230852.GS28965@faui48f.informatik.uni-erlangen.de> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408055530.GC28965@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200408102605.0ba41040@elandnews.com> <20200408195622.GK28965@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200408142709.0b957348@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20200408142709.0b957348@elandnews.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 08 Apr 2020 23:09:01 -0000 On Wed, Apr 08, 2020 at 03:40:09PM -0700, S Moonesamy wrote: > Hi Toerless, > > The key word of my criticism is "only". None of > > what done in liaison is per-se bad, its just too > > isolated from the communities. But i am of course > > repeating just my core ask to have a more open > > architecture evolution forum in the IAB/IETF to > > be able to more effectiely pull in possible > > contributors from other SDOs. > > My guess is that another SDO would have its own culture. Sure. But i was talking about reaching out to contributors, not SDOs as an organization. There are a limite amount of individuals working across multipiple SDO including IETF. But i suspect that there are more contributors that wouldn't dare to go out of their comfort zone without being invited. Of course, there is a large amount of SDO participation that is just doing work within a narrowly defined scope of operations by their sponsor, those typically would not be of interest. > > Heck, think of a track where you start to inviting > > 3GPP, ETSI, ITU-T and other SDO presenters, ask > > them to present what they do and their thoughts how > > it should impact the future of IETF work. And make > > sure the time planning allows double the amount of > > time for IETF participants to discuss. And hopefully > > help them to understand where/how that integration could > > be suggested/done via specific contributions to IETF. > > Have you watched a presentation of IETF work in a non-IETF forum? > Sometimes, it is not an accurate reflection of the IETF discussions. If all you have is a liaison statement you will always wander on thin ice attempting to extrapolate the meaning between the lines / discussion. Goes both ways. > I'd say that the above suggestion is worth a try instead of viewing it > through pessimistic lenses. ? Sorry, to much thread cutting... which suggestion ? > > Indeed. The problem though is to figure out how to get to > > more effective forms of actual architecture/engineering > > process and not to better marketing mechanisms. Then again, > > given how ossified our industry is, there is unfortunately > > something to be said about scaring people to wake up, even > > though i do not like it. > > I don't think that businesses would remain idle if there was an effective > way to change things over the short term. As said in the othre thread, i don't think in an industry as mature as ours and as capital intensive, that there is a lot you can change short term and from a single player. Hence the need IMHO for IETF to have to rethink to promote and support more poactive longer term architiecture discussions. (and if you don't like the word architecture, use design, strategy,...) Cheers Toerless > Regards, > S. Moonesamy > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Wed Apr 8 18:39:41 2020 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 EC8353A1D2C for ; Wed, 8 Apr 2020 18:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyuBTCsJEMJp for ; Wed, 8 Apr 2020 18:39:38 -0700 (PDT) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (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 6914C3A1D29 for ; Wed, 8 Apr 2020 18:39:38 -0700 (PDT) Received: by mail-ua1-x929.google.com with SMTP id v24so3411693uak.0 for ; Wed, 08 Apr 2020 18:39:38 -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=rndXhXGo0fcacPARBfxG6pmB96xuzxE3P2MVrZReios=; b=VNGXoN+qLeosXSdm6N102Jx5BXXDuGZmEMI25O/FXzW+QAx+DKiykY5OuJncbMdEVF oL0+jSovevvmomjq4tBVNWj+TMAaCYmM0w+ya4x/ty8gEnQsojdTdvlWKATgFjzmgtPp VhAnVbZo4y+HhSBQq+haEJ5TVWO/P3Soleqi8S6YXtCI21kHOTXMNpQj21u49UT8tsTr efIzORDTkkypXuk6n+78McXJSrwZRSBarrAl9DTkSDc8nKlkyH5mMIwpQkGkpMJRBg1n jzx581B++RyMNkC3ZQ0rLCwOlqUq15VbWxYZ+JPsNABU3++Pu2vF6MdBiLwLZlLOipcZ xNxg== 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=rndXhXGo0fcacPARBfxG6pmB96xuzxE3P2MVrZReios=; b=e3WbRvD1tFtooRm3EI878hBYChcYhLnzaP1E3hJDcw2NrPe7lT04Z1DL8KUxlrXxN3 ihHFXUpOTnKECFv+JnVt7Shj9EracvcgLAc1eqx738zaBH/MpEV0F2EvYnPxLfDXHq8o T28tLTj+kkiR4au7dUKhvZ7ME13AwAlXfjjohJc/rXOA0yTr7RfHuNnRsAX5ALh3tcVx AYUTtUACKRYBYhn3J4DFuj0qh1+c2OnWvSnltwUihsSjuHC1/rl8c2QW8Ej0fwEAtSCP kpzHtvJqFpMKhkcA4SoVugJGM9F7KSmGdtwSg0XBknuIBMOKVerRWD5C4Kfc3esuA61Y LnwA== X-Gm-Message-State: AGi0PuaShhDOL96FsdOuAohwMo/yiIJVfqgkvmXOq2HcdkU2+6hbBcXd TQQVahLyxw30+yDZyirKgUwjQ7gjh4biWBpFDR5mDnmB X-Google-Smtp-Source: APiQypKvC1tFl4vVo1oeyS8XUc45EQ6WaFIPOMeP/bayvsL4ZhpluedUEfPF2cHSpxe1hYY9CXj9C8fHnW54i5rg8uc= X-Received: by 2002:ab0:73cd:: with SMTP id m13mr917897uaq.22.1586396377258; Wed, 08 Apr 2020 18:39:37 -0700 (PDT) MIME-Version: 1.0 References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <3F26D0A8-28DE-4F35-B4B9-2346A8AED46F@gmail.com> <20200408205338.GM28965@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200408205338.GM28965@faui48f.informatik.uni-erlangen.de> From: Uma Chunduri Date: Wed, 8 Apr 2020 18:39:41 -0700 Message-ID: To: Toerless Eckert Cc: John C Klensin , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="0000000000008a1ed105a2d1b075" Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 01:39:40 -0000 --0000000000008a1ed105a2d1b075 Content-Type: text/plain; charset="UTF-8" Hi Toerless, Your observations are right, of course Quick replies in-line [Uma]: On Wed, Apr 8, 2020 at 1:54 PM Toerless Eckert wrote: > John, > I think 3GPP 3/4/5/6G is not a fitting example to apply the IP-over-foo approach. > 4G/5G "core" networks effectively are overlays on top of of some typically IP based transport network. Today the overlay nodes are mostly software in edge-data-centers/pops. So its more naturally an overlay. [Uma]: Right. But those overlays served well and all IP/MPLS transformation started there 10 years ago (from LTE days). It's only 2 bearers effectively till now. And those were simply not enough for some of the critical services envisioned in 5G networks beyond eMBB (so called "slice"). Hence you will continue to see some of the efforts in this thread as in the title of this thread (while I know some of the big operators which support that I am not plugged in that effort). > There is some liaison process whereby IETF technologies are pitching their benefits to 3GPP if used an an underlay (i reall having heard about this for SRv6 or LISP). Yet, 3GPP seems to prefer not to really change anything fundamental in their overlay architecture from what i've been told (only tangentially watching this). "Only simple, minimal layering integration is good integration". [Uma]: Lot of discussions couple of years ago in various side meetings. But at the end those were not so fruitful. Partly because there was a misguided effort to remove their heavily deployed overlay. Obviously, collapsing underlay and overlay won't help. LISP is different and it can potentially solve the control plane signaling and other issues in 3GPP domain but it's not that backward compatible (yet). But I am sure, Dino and other might be working in future releases .. The more fundamental problem is that the mobile services in most service providers are where the money is coming from, so now they want to re-design the hardware underlay in their name, aka: the actual physical network infrastructure besides DCs and radio towers. And i think 3GPP has no clue what to do there exactly. But i am sure that something strange will evolve. [Uma]: Yes; we all heard E2E slicing at some point in last few years? There is a lot in that E2E including L2 and IP/MPLS. You can get only so far moving the edge. Radio (with NR) is dis-aggregated and it doesn't help even for small sub-set of use cases, which can be solved by moving your DCs/Edge closure (cost, complexity and security issues). But the bottom line is underlay (IETF) needs to evolve independently of 5G/B5G (at best this is one use case), given the earlier futile discussions/efforts as you mentioned above. This would benefit vast number of use cases with new media, non-eMBB slices and industrial internet seeking beyond-best-effort which can co-exist along with BE. While I am not claiming I know fully, but yes, some of these aspects could belong rightly in this forum perhaps. Cheers! -- Uma C. > --0000000000008a1ed105a2d1b075 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0Hi Toerless,

You= r observations are right, of course
Quick replies in-line [Uma]:<= /div>

On Wed, Apr 8, 202= 0 at 1:54 PM Toerless Eckert <tte@cs.fa= u.de> wrote:
John,

I think 3GPP 3/4/5/6G is not a fitting example to apply
<= div class=3D"gmail_quote">
the IP-over-foo approach.

4G/5G "core" networks effectively are overlays on top of of some<= /blockquote>
typically IP based transport network. Today the overlay nodes are mostly
software in edge-data-centers/pops. So its more naturally an
overlay.
=C2=A0
[Uma]: Right. But = those overlays served well and all IP/MPLS transformation started there 10 = years ago (from LTE days). It's only 2 bearers effectively till now.=C2= =A0 And those were simply not enough for some of the critical services envi= sioned in 5G networks beyond eMBB (so called=C2=A0 "slice"). Henc= e you will continue to see some of the efforts in this thread as in the tit= le=C2=A0 of this thread (while I know some of the big operators=C2=A0 which= support that I am not plugged in that effort).

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
There is some liaison process whereby IETF technologies are pitching
their benefits to 3GPP if used an an underlay (i reall having
<= /div>
heard about this for SRv6 or LISP). Yet, 3GPP seems to prefer not
to really change anything fundamental in their overlay architecture
from what i've been told (only tangentially watching this).
"Only simple, minimal layering integration is good integration".<= /blockquote>
=C2=A0
[Uma]: Lot of discussions c= ouple of years ago in various=C2=A0side meetings. But at the end those were= not so fruitful.=C2=A0 Partly because there=C2=A0was a misguided effort t= o remove their heavily=C2=A0deployed overlay.=C2=A0 Obviously, collapsing underlay and overlay won't help. LISP is different and it can potentially solve the control plane signaling= and other issues in 3GPP=C2=A0 domain but it's not that backward compa= tible (yet). But I am sure, Dino and other might be working in future relea= ses ..
=C2=A0
The more fundamental problem is that the mobile services in most
service providers are where the money is coming from, so now
they want to re-design the hardware underlay in their name, aka: the actual=
physical network infrastructure besides DCs and radio towers.
<= /div>
And i think 3GPP has no clue what to do there exactly. But i
am sure that something strange will evolve.

[Uma]:=C2=A0 Yes; we all heard E2E slicing at some point in = last few years?=C2=A0
There is a lot in that E2E including L2 and= IP/MPLS. You can get only so far moving the edge. Radio (with NR) is dis-a= ggregated=C2=A0 and=C2=A0 it doesn't help even for small sub-set=C2=A0o= f use cases, which can be solved=C2=A0by moving=C2=A0your DCs/Edge closure = (cost, complexity and security issues).=C2=A0

But = the bottom line is underlay (IETF) needs to evolve independently of 5G/B5G = (at best this is one use case), given the earlier futile discussions/effort= s as you mentioned above. This would=C2=A0benefit vast number of use cases = with new media, non-eMBB slices and industrial internet seeking beyond-best= -effort which can co-exist along with BE. While I am not claiming I know fu= lly, but yes, some of these aspects could belong rightly in this forum perh= aps.


Cheers!
--
Uma C.


=C2=A0

--0000000000008a1ed105a2d1b075-- From nobody Wed Apr 8 19:10:31 2020 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 203A63A1DA0 for ; Wed, 8 Apr 2020 19:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qTc7qKLb184 for ; Wed, 8 Apr 2020 19:10:28 -0700 (PDT) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 8806F3A1D9F for ; Wed, 8 Apr 2020 19:10:28 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id b5so6052656vsb.1 for ; Wed, 08 Apr 2020 19:10:28 -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=BaeONW2zp/oveXKqKPi2fVitgHxzUBzUMO9J93N4pYM=; b=a7dUIMS/w5yMxamgWi12nK7NgwYCUVn2u1/sGSMBnCBCPSmKx+FsQWIIWtGnfIRodO nKSJbwZcT5x2wlQWtX0bbg6R4x7pFk/AtBFev4+qmSmEgh9S0tK0O/aW7K6Yz3Ln7b9J BsFQsTV/ZROuzGrv19zUdGof/Y7Yjgpo0bj+ejSPDmqUzESIVjVDZEgRsm3maCIPDe0U 0eVfBUaJCMfRdAv5dfw30OzIMxWF6IPkW2cDBJ74IIdSoPVI5pgrvw+KTPBKC7hTrCxS okYUul1OviBk4BJ0QUbUzGVu4Q7RD2/uAdJod7WIzvMkvMTBWxZnIRbgSqjSpkQn0xoT w3uw== 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=BaeONW2zp/oveXKqKPi2fVitgHxzUBzUMO9J93N4pYM=; b=PBvuLQvP8QuklCdbZFbro7EQoaGbdo/UqH21rJuQZy9SAc5HsYHYDDyLfBdFFnZ5cM zDYi7JTbS966F6gURtJhUze/NprC8l0bi6U7OYt0tEyK8yR6CM4nAwUdZfxuo8//PKUG RZ6DGy5FA9MrAFPmCvTeanldVzc/eTGv7kbnmTKnHrXD10P3pFm7rkLjhbjtKyCBoOBJ xlX/vKIWnoekftiCFdxoyPjT7oF3Sl5iiX8P2xBQwODSb9pC4huIoC1H5EnjP/Ird4DL sIpWVKDRf4+GGJQZMZJVs24+Ks9wAXZ/FI8NslXid+2iZkmMMvX8gXio6S+16pjt2gD9 6tAA== X-Gm-Message-State: AGi0PuZF1c2IX9/TO/ZpMWQqqHNkpww5HbZwMPTLefPUqToQ8ksJsipo VNZROVCbOJd+VVijKYAT1jcGJPj61oKJWHReji0= X-Google-Smtp-Source: APiQypJXIu3nkVydzwm04PG6XkdG+McbAKN6qz9gqtGQtb/do5g21qDFdmkbAoC/hb+bXX1GTyzFy5g7ZXkoT2jsCrw= X-Received: by 2002:a05:6102:3104:: with SMTP id e4mr8932930vsh.61.1586398227485; Wed, 08 Apr 2020 19:10:27 -0700 (PDT) MIME-Version: 1.0 References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> In-Reply-To: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> From: Uma Chunduri Date: Wed, 8 Apr 2020 19:10:31 -0700 Message-ID: To: Brian E Carpenter Cc: architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="000000000000d2587305a2d21e66" Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 02:10:30 -0000 --000000000000d2587305a2d21e66 Content-Type: text/plain; charset="UTF-8" > All our troubles will soon be over While I don't know all their troubles by reading that announcement; would definitely love to hear what do you think our troubles are ...(if any). * -- Uma C. [*] Appreciate your work and concur a lot on https://tools.ietf.org/html/draft-carpenter-limited-domains-13 . On Tue, Apr 7, 2020 at 9:59 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > All our troubles will soon be over, apparently: > > > https://www.etsi.org/newsroom/press-releases/1749-2020-04-etsi-launches-new-group-on-non-ip-networking-addressing-5g-new-services > > Stay well > Brian Carpenter > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --000000000000d2587305a2d21e66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0 All our troubles will soon be over


Whi= le I don't know all their troubles by reading that announcement; would = definitely=C2=A0love to hear what do you think our troubles are ...(if any)= . *

--
Uma C.=C2= =A0

[*] Appreciate your=C2=A0 work and concur a lo= t on=C2=A0=C2=A0https://tools.ietf.org/html/draft-carpenter-limited-domains= -13=C2=A0.=C2=A0


=C2=A0On Tue, Apr 7, 2020 at= 9:59 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
All our troubles will soon be over, apparentl= y:

https://www.etsi.org/newsroom/press-releases/1= 749-2020-04-etsi-launches-new-group-on-non-ip-networking-addressing-5g-new-= services

Stay well
=C2=A0 =C2=A0Brian Carpenter

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--000000000000d2587305a2d21e66-- From nobody Wed Apr 8 23:11:26 2020 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 6AA693A0BFB for ; Wed, 8 Apr 2020 23:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 OPaPPEXqtgN6 for ; Wed, 8 Apr 2020 23:11:20 -0700 (PDT) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id CAB2E3A0BFA for ; Wed, 8 Apr 2020 23:11:20 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.117.21]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 0396AriY013631 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Apr 2020 23:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1586412665; x=1586499065; i=@elandsys.com; bh=dQ5qoTstV1H3cHTprRwRUWKFYTHkbCQx3ExkL4t3u38=; h=Date:To:From:Subject:In-Reply-To:References; b=0enHaBhtgq04TmoCmBGcCihO9CPD4+Gg1eItXfmeU8phWBcYZn02Pz1zMArgOgtqm KQMPTublXaC080Amyb+lJYikTz9IkWo67oHHu6ezxuvGBCALtxwn8fopqm7sonjRfb 69D7K1rF2hnZ2fx1DWDmrdpjOm7AmU969UfPJJSQ= Message-Id: <6.2.5.6.2.20200408222422.0ae60b50@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 08 Apr 2020 23:10:38 -0700 To: Toerless Eckert , architecture-discuss@ietf.org From: S Moonesamy In-Reply-To: <20200408230852.GS28965@faui48f.informatik.uni-erlangen.de> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408055530.GC28965@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200408102605.0ba41040@elandnews.com> <20200408195622.GK28965@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200408142709.0b957348@elandnews.com> <20200408230852.GS28965@faui48f.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 06:11:24 -0000 Hi Toerless, At 04:08 PM 08-04-2020, Toerless Eckert wrote: >If all you have is a liaison statement you will >always wander on thin ice attempting to extrapolate >the meaning between the lines / discussion. Goes both ways. There are liaisons who are expected to get the message across. In theory, that should prevent the two sides from misunderstanding the (formal) statements. >? Sorry, to much thread cutting... which suggestion ? It was the one where you mentioned several SDOs and having them presenting what they do [1]. >As said in the othre thread, i don't think in an industry as >mature as ours and as capital intensive, that there is >a lot you can change short term and from a single player. >Hence the need IMHO for IETF to have to rethink to promote >and support more poactive longer term architiecture discussions. >(and if you don't like the word architecture, use design, strategy,...) I'll have to review past discussions (unrelated to this thread) to provide a good answer. It may be possible [2] to make some short steps, e.g. have a venue for a discussion. Someone will have to convince the IAB members to include that in their list of pet projects. :-) Regards, S. Moonesamy 1. https://mailarchive.ietf.org/arch/msg/architecture-discuss/D8Mxm3e4BPSf15JDXzfITNlwjbo/ 2. I would rate the probability of success as very low. From nobody Thu Apr 9 01:41:54 2020 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 15B563A0F06 for ; Thu, 9 Apr 2020 01:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 uJ5VlBx_7X2M for ; Thu, 9 Apr 2020 01:41:51 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 5AE923A0ED5 for ; Thu, 9 Apr 2020 01:41:35 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id f10so1242865wrr.9 for ; Thu, 09 Apr 2020 01:41:35 -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=evCZsOnSgZrjkS1N9CItlltPFhq/Jlr+vjOn+BeZBmw=; b=QZYyS6DDGIe9+RtZXivE8v0iBqJDdxqlHqXUeLIWZkdk6P0x7VcJr/PPqXdHd2AGck 93LnHCT9jWjkal2Z2zqRDCc3dNDaYcJ2YhLSVGhzCGjTWEeCIuCzS+Gpr/PHUb3v0DH+ Pp66XsHIxZFVu7HFjH1/uy8/k2aD86GUjwCSy8UCVBf4kzaxnSQGfWfpJ7riDiQeVrz/ KCV/8KkDebxQXe3IEOk+F2YY8o12eYwShEYzKbtpETeIhij8BrqlOj4weUKo8ictWYBo p6LQ6GsOj9vZ/cQgBPYAGkx14e0ndH4DoDxGt40sxueU6iG1yvealxPdR0s0Ad8KOLPo 1DeQ== 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=evCZsOnSgZrjkS1N9CItlltPFhq/Jlr+vjOn+BeZBmw=; b=e8UgsmgxBq4DbH8QPIrFgK7EVuHlK9PzS0t0trpt/GYiAVghMs9R/4pu6qVbaDKacC BdLIOPinUbYcsq4R9pGxXZG1785q/rZHbTTUcAxL8IE1v1tFdICjXC85Pgo7SgtuATSJ cTM3FOE3IDd7XkerDs3D3ooaiFDmvkbVtSYGGtDEhFjBV2e2cfc9WmcbnHeDooX4RCkc bQ9Vy3A3WJXIKqPY2lBhWzkuMOmG2tT5LN58ehidYFNjXWP/J0sRN9cDo1NoRyMZ8RIn Uf7DIMRpdNqiHGqmECYLkRmdHsQye6rf7lNhXk88mF9q1moNVH0SoFI3rv6rYBSe43/F M1vw== X-Gm-Message-State: AGi0PuaC2RwaS+41wzP7u1kL9it6RrrsCg1M0Rm6JN9av1y9gUKdb2wP 2ymKWPJCTL5nGWpBTkTJ0QY= X-Google-Smtp-Source: APiQypJBRIbmWX++VHyc/gzWslN8ZAnXtzOCgtUX4d7j1j5cjsZSnkQqb8Cf7dnZB6v9yAZJ8WzSEw== X-Received: by 2002:adf:b78b:: with SMTP id s11mr12423939wre.235.1586421693589; Thu, 09 Apr 2020 01:41:33 -0700 (PDT) Received: from broadband.bt.com ([2a00:23a8:4140:0:3d3c:abfc:9a8f:c39d]) by smtp.gmail.com with ESMTPSA id s13sm23158272wrw.20.2020.04.09.01.41.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2020 01:41:32 -0700 (PDT) From: Stewart Bryant Message-Id: <06B9C3A7-17D4-4815-AD22-1DAACA6C35DE@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_AABB35F2-804F-4490-8910-C2FC7ABB09C0" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 9 Apr 2020 09:41:30 +0100 In-Reply-To: <20200408212429.GN28965@faui48f.informatik.uni-erlangen.de> Cc: Stewart Bryant , Brian E Carpenter , architecture-discuss@ietf.org To: Toerless Eckert References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408055530.GC28965@faui48f.informatik.uni-erlangen.de> <551a2b4b-3cba-880d-e715-ecfbf138dc4c@gmail.com> <20200408212429.GN28965@faui48f.informatik.uni-erlangen.de> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 08:41:53 -0000 --Apple-Mail=_AABB35F2-804F-4490-8910-C2FC7ABB09C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 8 Apr 2020, at 22:24, Toerless Eckert wrote: >=20 > Yes, it is quite weird to think that government policy based > admission to a telecommunications standard body was ever > considered to be a good idea. I have only come to experience it as a=20= > weapon in an economic war of aggression.=20 There is of course history here. It is within my working lifetime that = many PTTs were denationalised and ITU changed from being a meeting of = civil servants to a meeting in which engineers working for private = enterprise were permitted to attend, express a view and vote on = outcomes. It is a great pity that governments do not automatically allow any = entity legally operating in their jurisdiction automatic entry to the = ITU, particularly countries claiming to be core drivers of the =E2=80=9Cfr= ee world=E2=80=9D. That said the IETF really does need to be more open to new revolutionary = ideas. The old concept of the innovators dilemma applies to SDOs as much as to = vendors. An idea that seems an outlandish toy to the established player = who completely dismisses the concept as unworkable, a position = reinforced by the threat to its core business, may indeed turn out to be = a valid replacement for its major technology. Sooner or later someone = will have an idea that ultimately leads to the obsolescence of IP. = Whilst that seems unthinkable to many, remember how many thought that = the internal combustion engine would provide the motive power for = transport for ever. That position looks a bit shaky at the moment. If = the IETF is always dismissive of a change from IPv6 to another = forwarding layer, eventually some other SDO will latch onto its = replacement and will take primacy in the development of what people will = still call the Internet but which will work another way. Another lesson = from the innovator=E2=80=99s dilemma is the exponential speed of the = transition making it rare that an organisation supporting the old can = reconfigure to the new. The IETF could try to buck the trend here by more openly fostering = investigation of the mechanisms and protocols that will ultimately = replace its core offerings, and this is why we need more to be open = minded about the operation of all parts of the Internet, something that = I do not see in the IETF=E2=80=99s current mode of operation. - Stewart --Apple-Mail=_AABB35F2-804F-4490-8910-C2FC7ABB09C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 8 Apr 2020, at 22:24, Toerless Eckert <tte@cs.fau.de> = wrote:

Yes, it is = quite weird to think that government policy based
admission to = a telecommunications standard body was ever
considered to = be a good idea. I have only come to experience it as a 
weapon in an = economic war of aggression. 


There is = of course history here. It is within my working lifetime that many PTTs = were denationalised and ITU changed from being a meeting of civil = servants to a meeting in which engineers working for private enterprise = were permitted to attend, express a view and vote on outcomes.

It is a great pity that = governments do not automatically allow any entity legally operating in = their jurisdiction automatic entry to the ITU, particularly countries = claiming to be core drivers of the =E2=80=9Cfree world=E2=80=9D.

That said the IETF = really does need to be more open to new revolutionary ideas.

The old concept of the = innovators dilemma applies to SDOs as much as to vendors. An idea that = seems an outlandish toy to the established player who completely = dismisses the concept as unworkable, a position reinforced by the threat = to its core business, may indeed turn out to be a valid replacement for = its major technology. Sooner or later someone will have an idea that = ultimately leads to the obsolescence of IP. Whilst that seems = unthinkable to many, remember how many thought that the internal = combustion engine would provide the motive power for transport for ever. = That position looks a bit shaky at the moment. If the IETF is always = dismissive of a change from IPv6 to another forwarding layer, eventually = some other SDO will latch onto its replacement and will take primacy in = the development of what people will still call the Internet but which = will work another way. Another lesson from the innovator=E2=80=99s = dilemma is the exponential speed of the transition making it rare that = an organisation supporting the old can reconfigure to the new.

The IETF could try to = buck the trend here by more openly fostering investigation of the = mechanisms and protocols that will ultimately replace its core = offerings, and this is why we need more to be open minded about the = operation of all parts of the Internet, something that I do not see in = the IETF=E2=80=99s current mode of operation.

- Stewart






= --Apple-Mail=_AABB35F2-804F-4490-8910-C2FC7ABB09C0-- From nobody Thu Apr 9 01:47:13 2020 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 9735B3A0F1B for ; Thu, 9 Apr 2020 01:47:12 -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 kuOu5OXBKT3V for ; Thu, 9 Apr 2020 01:47:10 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 4731E3A0F1A for ; Thu, 9 Apr 2020 01:47:09 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 49A0B280554; Thu, 9 Apr 2020 10:47:07 +0200 (CEST) Received: by mx4.nic.fr (Postfix, from userid 500) id 4168A2806CC; Thu, 9 Apr 2020 10:47:07 +0200 (CEST) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id 37F21280554; Thu, 9 Apr 2020 10:47:07 +0200 (CEST) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 31585642C582; Thu, 9 Apr 2020 10:47:07 +0200 (CEST) Received: by b12.nic.fr (Postfix, from userid 1000) id 22AF43FD4B; Thu, 9 Apr 2020 10:46:42 +0200 (CEST) Date: Thu, 9 Apr 2020 10:46:42 +0200 From: Stephane Bortzmeyer To: Carsten Bormann Cc: Stephane Bortzmeyer , Brian E Carpenter , architecture-discuss@ietf.org Message-ID: <20200409084642.GB23663@nic.fr> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> X-Operating-System: Debian GNU/Linux 10.3 X-Kernel: Linux 4.19.0-8-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.11.5.63017 Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 08:47:13 -0000 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Apr 08, 2020 at 08:57:02PM +0200, Carsten Bormann wrote a message of 27 lines which said: > > It seems that IETF's answer is about another project, by ITU. > > Yes. I do know about the difference between ETSI and ITU-T. > But the technical content (that I could find) was, at first look, > indistinguishable to me; I agree. But Toerless Eckert does not. --a8Wt8u1KmwUX3Y2C Content-Type: message/rfc822 Content-Disposition: inline Return-Path: eckert@i4.informatik.uni-erlangen.de Received: from hebe.prod-int.prive.th3.nic.fr [10.1.81.80] by b12.tech.prive.nic.fr with IMAP (fetchmail-6.4.0.beta4) for (single-drop); Wed, 08 Apr 2020 08:16:47 +0200 (CEST) Received: from hebe.prod-int.prive.th3.nic.fr (LHLO zimbra.afnic.fr) (10.1.81.80) by zimbra.afnic.fr with LMTP; Wed, 8 Apr 2020 08:15:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.afnic.fr (Postfix) with ESMTP id 82EB72D7D099 for ; Wed, 8 Apr 2020 08:15:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.afnic.fr X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-10 required=6.6 tests=[BAYES_50=0.8, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from zimbra.afnic.fr ([127.0.0.1]) by localhost (zimbra.afnic.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMMIjay_kWFZ for ; Wed, 8 Apr 2020 08:15:58 +0200 (CEST) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [10.1.50.11]) by zimbra.afnic.fr (Postfix) with ESMTP id 093702D7D096 for ; Wed, 8 Apr 2020 08:15:58 +0200 (CEST) Received: by relay01.prive.nic.fr (Postfix) id 0122E64C6C06; Wed, 8 Apr 2020 08:15:58 +0200 (CEST) Delivered-To: bortzmeyer@nic.fr Received: from mx5.nic.fr (mx5.nic.fr [IPv6:2001:67c:2218:2::4:13]) by relay01.prive.nic.fr (Postfix) with ESMTP id F339664C6C03 for ; Wed, 8 Apr 2020 08:15:57 +0200 (CEST) Received: from mx5.nic.fr (localhost [127.0.0.1]) by mx5.nic.fr (Postfix) with SMTP id EF62E30016C for ; Wed, 8 Apr 2020 08:15:57 +0200 (CEST) Received: by mx5.nic.fr (Postfix, from userid 1137) id 8FCC0300271; Wed, 8 Apr 2020 08:15:57 +0200 (CEST) Received-SPF: neutral (i4.informatik.uni-erlangen.de: Domain does not state whether sender is authorized to use 'eckert@i4.informatik.uni-erlangen.de' in 'mfrom' identity (mechanism '?all' matched)) receiver=mx5.nic.fr; identity=mailfrom; envelope-from="eckert@i4.informatik.uni-erlangen.de"; helo=faui40.informatik.uni-erlangen.de; client-ip="2001:638:a000:4134::ffff:40" Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx5.nic.fr (Postfix) with ESMTPS id 8322430016C for ; Wed, 8 Apr 2020 08:15:57 +0200 (CEST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A6563548017; Wed, 8 Apr 2020 08:15:52 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 977C5440040; Wed, 8 Apr 2020 08:15:52 +0200 (CEST) Date: Wed, 8 Apr 2020 08:15:52 +0200 Old-From: Toerless Eckert To: Stephane Bortzmeyer Cc: Carsten Bormann , architecture-discuss@ietf.org Old-Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services Message-ID: <20200408061552.GD28965@faui48f.informatik.uni-erlangen.de> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200408054204.GA6005@nic.fr> User-Agent: Mutt/1.10.1 (2018-07-13) X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.11.5.63017 X-PerlMx-Spam: Gauge=IIIIIIIII, Probability=9%, Report=' MULTIPLE_RCPTS 0.1, RCVD_FROM_IP_DATE 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1700_1799 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, IN_REP_TO 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, REFERENCES 0, URI_WITH_PATH_ONLY 0, __ANY_URI 0, __BODY_NO_MAILTO 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CC_NAME 0, __CC_NAME_DIFF_FROM_ACC 0, __CC_REAL_NAMES 0, __CD 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __DQ_NEG_HEUR 0, __DQ_NEG_IP 0, __FORWARDED_MSG 0, __FRAUD_COMMON 0, __FRAUD_DPTCOMPNY 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_REFERENCES 0, __HTTPS_URI 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __MULTIPLE_URI_TEXT 0, __NO_HTML_TAG_RAW 0, __REFERENCES 0, __SANE_MSGID 0, __STOCK_PHRASE_7 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __SUBJ_REPLY 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __URI_IN_BODY 0, __URI_NOT_IMG 0, __URI_NS , __URI_WITH_PATH 0, __USER_AGENT 0' X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services From: Toerless Eckert On Wed, Apr 08, 2020 at 07:42:04AM +0200, Stephane Bortzmeyer wrote: > > https://datatracker.ietf.org/liaison/1677/ > > It seems that IETF's answer is about another project, by ITU. Yes. > ITU and ETSI have the same discourse What information makes you think that ? I do not think that that is true. > That document was input to ITU-T Study Group 13 (SG13) for the start of Focus Group 2030 (FGNET2030). FGNET203 was not formally involved in the creation of the Liaison Statements referred to in the liaison exchange pointed to by Carsten. Instead that was done by ITU-T Telecommunication Standardization Advisory Group (TSAG) probably with help from SG13. There are ITU-T members and contributors who think that topics related directly to the evolution of IP (often referred to as "New IP") should be discussed by interested parties directly to IETF instead of of being brought into some IMHO obfuscated leadership statements via some liaison process. At least thats what i believe, which is why we have inofficial IETF side meetings about "New IP" and other related topics. But then again, this is from my team working only in FGNET2030, but not having been involved in any of the payload of the TSAG/SG13 liaison statements. > but, apparently, they operate separately. Yes. ETSI is a completely separate SDO from ITU, Not a United Nations organization. Cheers Toerless > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de --a8Wt8u1KmwUX3Y2C-- From nobody Thu Apr 9 01:58:45 2020 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 5E1DE3A0F50 for ; Thu, 9 Apr 2020 01:58:44 -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 e9JR3UPFWO_K for ; Thu, 9 Apr 2020 01:58:43 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 F19F83A0F4E for ; Thu, 9 Apr 2020 01:58:42 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id DF23B280297; Thu, 9 Apr 2020 10:58:40 +0200 (CEST) Received: by mx4.nic.fr (Postfix, from userid 500) id D88C32806CA; Thu, 9 Apr 2020 10:58:40 +0200 (CEST) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id D045C280297; Thu, 9 Apr 2020 10:58:40 +0200 (CEST) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id CAB46642C582; Thu, 9 Apr 2020 10:58:40 +0200 (CEST) Received: by b12.nic.fr (Postfix, from userid 1000) id B996B3FD4B; Thu, 9 Apr 2020 10:58:15 +0200 (CEST) Date: Thu, 9 Apr 2020 10:58:15 +0200 From: Stephane Bortzmeyer To: Stewart Bryant Cc: Toerless Eckert , architecture-discuss@ietf.org Message-ID: <20200409085815.GC23663@nic.fr> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408055530.GC28965@faui48f.informatik.uni-erlangen.de> <551a2b4b-3cba-880d-e715-ecfbf138dc4c@gmail.com> <20200408212429.GN28965@faui48f.informatik.uni-erlangen.de> <06B9C3A7-17D4-4815-AD22-1DAACA6C35DE@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06B9C3A7-17D4-4815-AD22-1DAACA6C35DE@gmail.com> X-Operating-System: Debian GNU/Linux 10.3 X-Kernel: Linux 4.19.0-8-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: No, tests=bogofilter, spamicity=0.073798, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.11.5.63017 Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 08:58:44 -0000 On Thu, Apr 09, 2020 at 09:41:30AM +0100, Stewart Bryant wrote a message of 176 lines which said: > That said the IETF really does need to be more open to new > revolutionary ideas. Is it really the role of the IETF? The IETF standardizes things for the Internet. Nothing lasts forever so, one day, the TCP/IP Internet will be replaced by something different. It is not a problem if this is done by another organisation. The IETF is not a goal in itself, it has a purpose, dealing with the current Internet. I'm fine with the idea that other organisations (but certainly not ITU or ETSI) work on more revolutionary ideas. (This may be also a job for the IRTF.) > Sooner or later someone will have an idea that ultimately leads to > the obsolescence of IP. Whilst that seems unthinkable to many, It is perfectly thinkable, one day, it will happen, but so what? Our goal is to make people communicate, not to maintain the IETF for ever. > If the IETF is always dismissive of a change from IPv6 to another > forwarding layer, eventually some other SDO will latch onto its > replacement and will take primacy in the development of what people > will still call the Internet but which will work another way. I'm OK with that. But I bet this "other SDO" will never be ITU or ETSI. > The IETF could try to buck the trend here by more openly fostering > investigation of the mechanisms and protocols that will ultimately > replace its core offerings, and this is why we need more to be open > minded about the operation of all parts of the Internet, Or IETF may think that it is not its role and happily defer to researchers outside the IETF. From nobody Thu Apr 9 02:07:45 2020 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 0E2903A0F79 for ; Thu, 9 Apr 2020 02:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 EW7eI0JUrXQ6 for ; Thu, 9 Apr 2020 02:07:42 -0700 (PDT) Received: from vs25.mail.saunalahti.fi (vs25.mail.saunalahti.fi [62.142.117.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 402A03A0CC8 for ; Thu, 9 Apr 2020 02:07:42 -0700 (PDT) Received: from vs25.mail.saunalahti.fi (localhost [127.0.0.1]) by vs25.mail.saunalahti.fi (Postfix) with ESMTP id 66FFA212C2; Thu, 9 Apr 2020 12:07:40 +0300 (EEST) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by vs25.mail.saunalahti.fi (Postfix) with ESMTP id A58E5215DA; Thu, 9 Apr 2020 12:07:36 +0300 (EEST) Received: from eggert.org (unknown [62.248.255.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eggert@elisanet.fi) by gw02.mail.saunalahti.fi (Postfix) with ESMTPSA id 5D11240004; Thu, 9 Apr 2020 12:07:33 +0300 (EEST) Received: from stickers.eggert.org (stickers.eggert.org [172.24.110.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id 1FB2C84E5A5; Thu, 9 Apr 2020 12:07:27 +0300 (EEST) From: Lars Eggert Message-Id: <09CE56D4-985B-41A4-AA8B-A459B4A5E696@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_D6D61CE8-C8CB-43AC-AEA0-2C4672600059"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 9 Apr 2020 12:07:26 +0300 In-Reply-To: <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> Cc: Stephane Bortzmeyer , architecture-discuss@ietf.org To: Carsten Bormann References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> X-MailScanner-ID: 1FB2C84E5A5.A806B X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 09:07:44 -0000 --Apple-Mail=_D6D61CE8-C8CB-43AC-AEA0-2C4672600059 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 2020-4-8, at 21:57, Carsten Bormann wrote: > There has been a decade of =E2=80=9Cclean slate Internet=E2=80=9D = discussion, and only ICN emerged as an interesting new architecture from = that context. So I=E2=80=99m not very optimistic with any process that = tries to relive that process. But genuine new ideas do get generated = now and then, and I would be quite interested to hear about them without = the now obligatory press release bombast on how they will create cheaper = battery technology for flying cars and cure Covid-19 at the same time. +1 An even ICN has an uncertain road to larger-scale deployment. Lars --Apple-Mail=_D6D61CE8-C8CB-43AC-AEA0-2C4672600059 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl6O5c4ACgkQVLXDCb9w wVf+ohAAhq3VPU/3wVbowWj79DVfWbUz4ad8Plp9wru1Hx5dKyhbIJ4BG9D/Kmlo Z4L6ApQb8nPY7TYaCrEgAA1arze9mPQbz+IVaTqKuLybcIf3BzMO3P6QQHiAjsgi u+o1gDRRws3sZgE+IuKjDGesYEX3PBJ3vjNNwvP1/DiLKNHiPa+paSZeoykGk4ku EFa2P2DFkt/+L8JUDnsu88bmtNAgVfUTV3m7m2jlo77iJjzjr7mTVdM6XG1O7BbI Zl0PZCaIFygY8fSagRvE0WdPpBXBTQO7IX9yfKsYAVA/XM2MtH3cGgnhOYT4R8xE fuoBx8XkJpztOr1Eg1ajCgCWvyo6XIDP+Na9esz0ZP/+W6xGI2YffjazDPZFwvFi L8LANLzgXXaekpCBSSfWnZjDGla2QG8ePUi0STywx7Fs55bzZcxCWy088804qD4Q W+pOl4CMsSpTRjk1fri7pIAb/YLi6mFszv9jJtdGfR14TUwUdNxtAlwA01ogZPjX EkJq7B9tvcrQo9fYgKBtwGRb0JqSgf/exjjV8Kr9aLGdS5ZVIL/Zrn3uAEms7q8d woK306uM+PGsJODIxIUwJa5dB03cD0kBePLXoWio2nC5wMtoEs5X814XGOrVqdIC HcDFzidWDI3If0/Z3/53OGNx0tL0zfOu20zexKS1FakPhhtmSPU= =QHqs -----END PGP SIGNATURE----- --Apple-Mail=_D6D61CE8-C8CB-43AC-AEA0-2C4672600059-- From nobody Thu Apr 9 02:14:19 2020 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 2E05A3A0F8E for ; Thu, 9 Apr 2020 02:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 mZ_9n1MCgdUi for ; Thu, 9 Apr 2020 02:14:16 -0700 (PDT) Received: from vs23.mail.saunalahti.fi (vs23.mail.saunalahti.fi [193.64.193.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09A6A3A0F8D for ; Thu, 9 Apr 2020 02:14:15 -0700 (PDT) Received: from vs23.mail.saunalahti.fi (localhost [127.0.0.1]) by vs23.mail.saunalahti.fi (Postfix) with ESMTP id 8D44520838; Thu, 9 Apr 2020 12:14:14 +0300 (EEST) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by vs23.mail.saunalahti.fi (Postfix) with ESMTP id 825D120994; Thu, 9 Apr 2020 12:14:14 +0300 (EEST) Received: from eggert.org (unknown [62.248.255.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eggert@elisanet.fi) by gw03.mail.saunalahti.fi (Postfix) with ESMTPSA id 6B5D620004; Thu, 9 Apr 2020 12:14:11 +0300 (EEST) Received: from stickers.eggert.org (stickers.eggert.org [172.24.110.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id 0D5B284E5F0; Thu, 9 Apr 2020 12:14:05 +0300 (EEST) From: Lars Eggert Message-Id: <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_3A7FEE5A-5210-4A99-8A21-1F08B76540FE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 9 Apr 2020 12:14:04 +0300 In-Reply-To: <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> Cc: Carsten Bormann , architecture-discuss@ietf.org To: Toerless Eckert References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> X-MailScanner-ID: 0D5B284E5F0.AA24C X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 09:14:17 -0000 --Apple-Mail=_3A7FEE5A-5210-4A99-8A21-1F08B76540FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2020-4-8, at 22:41, Toerless Eckert wrote: > When technologies are young, you just let engineers > innovate and implement and when everything is done, you > can go and fight for it to get standardized. When an > industries becomes more mature and a lot more capital > investment heavy, you need to revert this and SDOs > need to play a lot more proactive role in defining > next-gen solutions. See 3GPP. IETF is not doing this > at the architecture scale. Only at small incremental > enhancements. if this is what you belief needs to happen, please do take this work to = the ITU-T. Lars --Apple-Mail=_3A7FEE5A-5210-4A99-8A21-1F08B76540FE 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl6O51wACgkQVLXDCb9w wVeCQxAAjMkQyEqCqle0UmEoBO+89Tc+wfPJ6JJDmnvbiXNpTFsMBsg7d8wHDCKE c9gk3vPpKEHnK9XEDFzA/38Bbd8OXqT6kjI+12XUT2hdbt9lNkfK7ULIGKmqYqQX OHqJPFg3o/6R7rH/xB7TjbldK2Tvy1zXHJ6gjOzALngHSJWo8iD4wxqocjT1LHwO GS5R/mWwyHRag4GU/toQ9rUNGnGik4QxPHJAZ0mKyqd2Y3/ug4YbfdxFOcQIAk6s cD6nCfh10QksR6C9N4gcLhrxa8yM02KZXwPFfc0XZX+Z/yWf8O6Zq41dP73lo1kX 9Mz35Fi7114uJlG7kcawaHaQkm8AoyFGYVp8JRzedylS9gZOm8FeAdOImbnQ45LK I3qC2lxWB5eBdc6eSRlES3df4ErJDRaJg9nafBI06bwhY9AyjaEtwnjAEFdGYXfu rBq2WOuFPtrWzmm1hs/IH+SoV0EfGKdR3Cl9m6ukrAewQNuXytC+dUGX/BxlmR9T jciS8oFNUqZ3aiDi7P7eO7KzTJ4/aguicd/WML17TYXoQNAPujgSbzc95uWQ5QU7 PYVW3A27udjRBtvNmAaTQrKy2CjKr6SQIKxjEct+zAyYEedao7YzGTmSYoGIeffJ Du9gJFCDodw3WRqFYAhRhfUJXEiN9feBZm2LHa08YnK8LIbPfJY= =gdxf -----END PGP SIGNATURE----- --Apple-Mail=_3A7FEE5A-5210-4A99-8A21-1F08B76540FE-- From nobody Thu Apr 9 02:50:27 2020 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 234F93A103D for ; Thu, 9 Apr 2020 02:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRrx-Y3MuFLH for ; Thu, 9 Apr 2020 02:50:23 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 7E32C3A103F for ; Thu, 9 Apr 2020 02:50:23 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id c15so11129920wro.11 for ; Thu, 09 Apr 2020 02:50: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=SUxiTJzxbkEb5PSuX46WOnRaUPETcOyY3UiJyeBQIX8=; b=vUM8UezEqSE00VVHDYSswNjPCr0Pq4oXE3YwCyKPQxyGd6EvkvaYn80JQ6X/fxEJHd QDTVWq8gEaCjVNk6jtNkl9Xyw2H8fVfdgzDfvsU3mSsyGWGz645kSvoRSCOcBj0dmjem h1sa9ZnFNLoe517IzynZLND/fVqX5gs7X0sg1K9tg1RpsmCE8bDSR94HEIPKv+wFv+6y 1fR/Ae0NkRJq5jZHWYX238LZgpNgD/nx/EDRj66Q3R9vGLrCXwkTfmxNdwq3Kr/79X3u GCJYHcNLODq2Q1ArYb74fKLv+BB9IKqlIeBpJ1esvmYM24UcvfHwDh2RFs80CUmt0ve5 WV5A== 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=SUxiTJzxbkEb5PSuX46WOnRaUPETcOyY3UiJyeBQIX8=; b=geISg3XQKJs32kMCkBtWKiLhBVohn60Ehtk54Tq006C6WtU0JL525Sy+5kwHbEm20r s8rZtDANTgZjNu8KL91Q8oO70Quj6Lna4flx5eqwOWKq9RN9WPARvCNAlTDCw7jFnqDB oksMZZQi1tFHlWPJ/zLQkZSowgh1Yzvgg+aYfU6wmWwozBvDpTzSe8bPTxFiQNA0r5+y axOyQ+8qhSRRf386fKbwkR6Dbnxn/tde0cwW7ftmF9gX3kOF6fC/vjF51Ih2QMwi2VBu kE6y1Q8KBrKsowxy4j4bbshzpECyciEOR54NFos2dBCDOcDIeLEBSMWmqj9W6iW9CxYm 2syQ== X-Gm-Message-State: AGi0PuaID2UeJrDLA/HqkkQRyK2VbjRCltXDPXy3QK6wjOKprBTYFoul v/PmenhnYH1PmZzsJolOuyM= X-Google-Smtp-Source: APiQypI2tcBS04a4sRDi8i1ShEKA2eHMxfD1Zm/QKzluPI+d7TJVArV8VO5wS4aBUVJAa/LVmdxFbA== X-Received: by 2002:adf:f4c6:: with SMTP id h6mr12912296wrp.267.1586425821809; Thu, 09 Apr 2020 02:50:21 -0700 (PDT) Received: from broadband.bt.com ([2a00:23a8:4140:0:3d3c:abfc:9a8f:c39d]) by smtp.gmail.com with ESMTPSA id w18sm16754046wrn.55.2020.04.09.02.50.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2020 02:50:21 -0700 (PDT) From: Stewart Bryant Message-Id: <57789C39-10B6-42A2-A413-78ABACBE8686@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6B15F3EA-0B6C-450F-AECE-8DDE47B15554" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 9 Apr 2020 10:50:18 +0100 In-Reply-To: <20200408230852.GS28965@faui48f.informatik.uni-erlangen.de> Cc: Stewart Bryant , S Moonesamy , architecture-discuss@ietf.org To: Toerless Eckert References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408055530.GC28965@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200408102605.0ba41040@elandnews.com> <20200408195622.GK28965@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200408142709.0b957348@elandnews.com> <20200408230852.GS28965@faui48f.informatik.uni-erlangen.de> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 09:50:25 -0000 --Apple-Mail=_6B15F3EA-0B6C-450F-AECE-8DDE47B15554 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 9 Apr 2020, at 00:08, Toerless Eckert wrote: >=20 > As said in the othre thread, i don't think in an industry as=20 > mature as ours and as capital intensive, that there is > a lot you can change short term and from a single player. That depends on what you mean by short term and what the financial = imperative is. Think about the heady days when the Internet rolled out in several waves = to the consumer world, and the rate at which modems changed and then = switched to DSL then to xDSL, and from MPLS to Ethernet as the primary = backhaul in many networks. The key enabler this time is the move to edge service combined with the = move to apps which hold their own network stack and tunnel to the edge = service. That significantly reduces the scope of and hence barrier to = change needed to introduce a new innovation. So as with many things it comes down to imperative. Think of the rate of = military technical evolution between 1939 and 1945 and how many = impossible things were done because of the imperative. Think of the = social change that has happened in the last few weeks. If the incentive = is high enough long term can be a remarkably short time. - Stewart --Apple-Mail=_6B15F3EA-0B6C-450F-AECE-8DDE47B15554 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 9 Apr 2020, at 00:08, Toerless Eckert <tte@cs.fau.de> = wrote:

As said in = the othre thread, i don't think in an industry as 
mature as = ours and as capital intensive, that there is
a lot you can = change short term and from a single = player.

That= depends on what you mean by short term and what the financial = imperative is.

Think about the heady days when the Internet rolled out in = several waves to the consumer world, and the rate at which modems = changed and then switched to DSL then to xDSL, and from MPLS to Ethernet = as the primary backhaul in many networks.

The key enabler this time is the move = to edge service combined with the move to apps which hold their own = network stack and tunnel to the edge service. That significantly reduces = the scope of and hence barrier to change needed to introduce a new = innovation.

So = as with many things it comes down to imperative. Think of the rate of = military technical evolution between 1939 and 1945 and how many = impossible things were done because of the imperative. Think of the = social change that has happened in the last few weeks. If the incentive = is high enough long term can be a remarkably short time.

- Stewart


= --Apple-Mail=_6B15F3EA-0B6C-450F-AECE-8DDE47B15554-- From nobody Thu Apr 9 03:29:18 2020 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 D0CF23A02BE for ; Thu, 9 Apr 2020 03:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.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 VxkL5c_EDUUH for ; Thu, 9 Apr 2020 03:29:15 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 E1E403A03EA for ; Thu, 9 Apr 2020 03:29:14 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id a6so9773431ilr.4 for ; Thu, 09 Apr 2020 03:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UtuRgQ5Bck3ZJUc9M8utAvJjnHRrbovk+2ZfCNqfT+0=; b=1Etfg1gzAZCDLc31mFmlG7niL7jWne7TxCDvrJgA/f2ydg2AXylqTO9E4ElI4512Ny 5HbyLlWCIsETwVU3p8bHa2I+JHL0HEln/GQ0tEMMN8l00gdAUxSjFa5YNjwXkwBpSchb Bjo3loEyWIu6uAjTVLYdH/6LXsBPfE1I2ly5SNIq+gQfAxWIj0D9eeIK1uWJdo8ZsYug 0CeSHSV8xtA6XIb89NaYdZmMp16NZ4cIOE+pnrslYgRoW4MP8uvPwZ5MKOqXsybd4wx7 rD1d6D2B35tqKC0YTYwGRrS6pRivxB1c0cfXVR6oNkj0g2uXNxAZvv4kxlgL4wuRRewO eYHQ== 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=UtuRgQ5Bck3ZJUc9M8utAvJjnHRrbovk+2ZfCNqfT+0=; b=bkEi1u6zn7e0jQwCI99ahr1LpkqNP1adnnJQKA0iO61TIIqZCmuHv1Et8o29EgTVFF o8URJPtxEiSRPar+hDqCs+5C3yKz3+UYWqSW7pCXE7Wvh7hAS19N1biQ7NkCqpmsUeLS gmjRn8cKxXp+GbSw8kHGc49VUQBJs1qnmc8x5KdEkiNxg1aQiMhqngm9AMTz2kmcnEb0 G7RBdAr6DlLj0zl6N2VJsdzxaJ072h9XRE8/lAuXDPB8ecQdA50kx9x/jSXsNoNwZKh2 AnOSKQq6G03oT3V2ORFc0m491ngS7CwoqdfvY6rs1MCqeOw9hnDCVHCaT39M5o6zyHtb eCug== X-Gm-Message-State: AGi0PuY9y7P9kITgdJhJ0BqJHiwNbcL8jUlXl6rdgDLSFaLj2eCvthIR rJlmg8gqF8u/lxaiIAmniaDpX9N1ZXjS5/NJ/BAnIQ== X-Google-Smtp-Source: APiQypI8C6+26GPl76QsP0Q+dglnDtCt+0YuhChmTksdhWmhe+BYh4X4+vMYOaf/e02AhJx2iJ3SpGtZQ544Ss+xaBo= X-Received: by 2002:a92:aa87:: with SMTP id p7mr4093475ill.63.1586428153998; Thu, 09 Apr 2020 03:29:13 -0700 (PDT) MIME-Version: 1.0 References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> In-Reply-To: <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> From: Alexander Pelov Date: Thu, 9 Apr 2020 12:28:34 +0200 Message-ID: To: Carsten Bormann Cc: Brian E Carpenter , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="00000000000094ca8705a2d91653" Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 10:29:17 -0000 --00000000000094ca8705a2d91653 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Carsten, all, Thanks for the pointer and the interesting discussion! I think one additional point was not yet mentioned regarding the Non-IP architecture. In LPWANs you have essentially this, and the goal of SCHC (RFC-to-be-8724) is exactly that - having IP-over-NonIP. There is even a draft on SCHC-over-NBIOT. What would be the way to make sure the ETSI people are aware that they can have the benefits of the Non-IP approach, all without losing compatibility with the Internet? Cheers, Alexander On Wed, Apr 8, 2020 at 7:00 AM Carsten Bormann wrote: > On 2020-04-08, at 06:58, Brian E Carpenter > wrote: > > > > All our troubles will soon be over, apparently: > > > > > https://www.etsi.org/newsroom/press-releases/1749-2020-04-etsi-launches-n= ew-group-on-non-ip-networking-addressing-5g-new-services > > =E2=80=A6 and you can find one thoughtful piece of discussion from the IE= TF chair > at the unlikely place of > > https://datatracker.ietf.org/liaison/1677/ > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --00000000000094ca8705a2d91653 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Carsten, all,

Thanks for the point= er and the interesting discussion!
I think one additional point w= as not yet mentioned regarding the Non-IP architecture. In LPWANs you have = essentially this, and the goal of SCHC (RFC-to-be-8724) is exactly that - h= aving IP-over-NonIP. There is even a draft on SCHC-over-NBIOT.
What would be the way to make sure the ETSI people are aware t= hat they can have the benefits of the Non-IP approach, all without losing c= ompatibility with the Internet?

Cheers,
= Alexander



On Wed, Apr 8, 2020 at 7:00 AM= Carsten Bormann <cabo= @tzi.org> wrote:
On 2020-04-08, at 06:58, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>
> All our troubles will soon be over, apparently:
>
> https://www.etsi.org/newsroom/press-relea= ses/1749-2020-04-etsi-launches-new-group-on-non-ip-networking-addressing-5g= -new-services

=E2=80=A6 and you can find one thoughtful piece of discussion from the IETF= chair at the unlikely place of

https://datatracker.ietf.org/liaison/1677/

Gr=C3=BC=C3=9Fe, Carsten

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--00000000000094ca8705a2d91653-- From nobody Thu Apr 9 04:30:27 2020 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 DEBD63A088E for ; Thu, 9 Apr 2020 04:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 tLc9DJuoRY-q for ; Thu, 9 Apr 2020 04:30:24 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F00663A088D for ; Thu, 9 Apr 2020 04:30:23 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D4D5A548042; Thu, 9 Apr 2020 13:30:17 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id CA88B440040; Thu, 9 Apr 2020 13:30:17 +0200 (CEST) Date: Thu, 9 Apr 2020 13:30:17 +0200 From: Toerless Eckert To: S Moonesamy Cc: architecture-discuss@ietf.org Message-ID: <20200409113017.GX28965@faui48f.informatik.uni-erlangen.de> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408055530.GC28965@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200408102605.0ba41040@elandnews.com> <20200408195622.GK28965@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200408142709.0b957348@elandnews.com> <20200408230852.GS28965@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200408222422.0ae60b50@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20200408222422.0ae60b50@elandnews.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 11:30:26 -0000 On Wed, Apr 08, 2020 at 11:10:38PM -0700, S Moonesamy wrote: > Hi Toerless, > At 04:08 PM 08-04-2020, Toerless Eckert wrote: > > If all you have is a liaison statement you will > > always wander on thin ice attempting to extrapolate > > the meaning between the lines / discussion. Goes both ways. > > There are liaisons who are expected to get the message across. In theory, > that should prevent the two sides from misunderstanding the (formal) > statements. Sure, and lets assume everybody does an excellent job in that: Where on the IETF schedule is the open meeting with those liaisons to discuss with them ? (same thing other side of course too). > > ? Sorry, to much thread cutting... which suggestion ? > > It was the one where you mentioned several SDOs and having them presenting > what they do [1]. Ack. > > As said in the othre thread, i don't think in an industry as > > mature as ours and as capital intensive, that there is > > a lot you can change short term and from a single player. > > Hence the need IMHO for IETF to have to rethink to promote > > and support more poactive longer term architiecture discussions. > > (and if you don't like the word architecture, use design, strategy,...) > > I'll have to review past discussions (unrelated to this thread) to provide a > good answer. It may be possible [2] to make some short steps, e.g. have a > venue for a discussion. Someone will have to convince the IAB members to > include that in their list of pet projects. :-) Its crazy that in research (IRTF) and protocol development (IEF), the groups are started by pet topics of the community, and leadership provides process management and adult supervision. And in architecture its the opposite: Work has to be pet topics of IAB and the community has to provide adult supervision. WHich model works better ? Why is architecture not using the model of research and protocol development ? Cheers Toerless > Regards, > S. Moonesamy > 1. https://mailarchive.ietf.org/arch/msg/architecture-discuss/D8Mxm3e4BPSf15JDXzfITNlwjbo/ > 2. I would rate the probability of success as very low. > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Thu Apr 9 04:54:12 2020 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 1BDE33A0937 for ; Thu, 9 Apr 2020 04:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 2mjhl-_ZtQhB for ; Thu, 9 Apr 2020 04:52:33 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 214073A0938 for ; Thu, 9 Apr 2020 04:52:32 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C5DB8548045; Thu, 9 Apr 2020 13:52:27 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id BE242440040; Thu, 9 Apr 2020 13:52:27 +0200 (CEST) Date: Thu, 9 Apr 2020 13:52:27 +0200 From: Toerless Eckert To: Alexander Pelov Cc: Carsten Bormann , architecture-discuss@ietf.org Message-ID: <20200409115227.GY28965@faui48f.informatik.uni-erlangen.de> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 11:52:35 -0000 Alexander: John Klensin pointed to the general approach of IP over/for Foo. I pointed to the problem that if Foo supports more than best effort, there is likely more work needed so that this can be used in the IP over Foo. Such improvements for IP may not be able to work all across the tradtional Internet, but across all the interesting IP networks running over Foo, such as e.g.: metropolitan/city networks. If technologies such as those sought by ETSI become such a candidate Foo, we foremost need to ask if they desire to support IP over Foo or if they totally want to eliminate IP all the way to the application. For example, Google could easily completely eliminate TCP/IP. They are already doing it for TCP (QUIC), and if they roll out more google Fiber access, all user traffic could well be QUIC over Google Foo instead of IP. There is nothing stopping a market player doing this. Work in IETF today only happens when it is driven by players with overwhelming market power, so IETF will only be involved reactively if any such happens. Exactly like it did happen for QUIC. I think we can see how this works in several working groups already for above example. I have expressed my opinion about whethre i think it is the best mode of operations for IETF to be reactively moved only by big industry players, or if a more proactive approach to shape the future would be better for IETF. Cheers Toerless On Thu, Apr 09, 2020 at 12:28:34PM +0200, Alexander Pelov wrote: > Dear Carsten, all, > > Thanks for the pointer and the interesting discussion! > I think one additional point was not yet mentioned regarding the Non-IP > architecture. In LPWANs you have essentially this, and the goal of SCHC > (RFC-to-be-8724) is exactly that - having IP-over-NonIP. There is even a > draft on SCHC-over-NBIOT. > > What would be the way to make sure the ETSI people are aware that they can > have the benefits of the Non-IP approach, all without losing compatibility > with the Internet? > > Cheers, > Alexander > > > > On Wed, Apr 8, 2020 at 7:00 AM Carsten Bormann wrote: > > > On 2020-04-08, at 06:58, Brian E Carpenter > > wrote: > > > > > > All our troubles will soon be over, apparently: > > > > > > > > https://www.etsi.org/newsroom/press-releases/1749-2020-04-etsi-launches-new-group-on-non-ip-networking-addressing-5g-new-services > > > > ??? and you can find one thoughtful piece of discussion from the IETF chair > > at the unlikely place of > > > > https://datatracker.ietf.org/liaison/1677/ > > > > Grüße, Carsten > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Thu Apr 9 05:10:08 2020 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 C8A0E3A09D3 for ; Thu, 9 Apr 2020 05:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pu35U5CuPMy2 for ; Thu, 9 Apr 2020 05:10:00 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 C5B3D3A09C7 for ; Thu, 9 Apr 2020 05:09:59 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id v16so11215903ljg.5 for ; Thu, 09 Apr 2020 05:09:59 -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=m7X3Om/8ieFFmJZkGbk/77Opr0NmJeZes4wMTbS/o3Y=; b=hW6+848+R2yCwZIIR26btL/g4TtCsXMKJFga1lgttxy5eVNEQOgxpXxsbUXm/zQc9s 0vZDD+rHksnH6UnqtbsQmvR0r2llnbiChE9Tu/9x5upbsrG+SIapLsB4LLCtYwUmwUG6 2gCjRM8LNi1O78dEsMcTumP8TkDfa7bVhFoipZ7gzrnBlIflm5X4TgWbdLYrEY+xiz4O 1RNwmd3jD03fEVCYJSBFTK56FGQGvRvWfjTpjiLyygkcu8wxkJv8/4G+MaQwnvPrcHEU MQNjjEJ7kO/JbOAj7zvhCOlB3DETD1EvX68CP4DEz5261qvcKH8ARTJ8v92rsDvpa1m/ 80Vw== 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=m7X3Om/8ieFFmJZkGbk/77Opr0NmJeZes4wMTbS/o3Y=; b=d+4vDEvI/MlxR6QS1PvRkKwT7170efSppE5zn7iMRtuKZwliOuU3wa7A54++4f6ECw 9G+08QI/JfLEmwQBm0jGmYHUg8u3reKTJYZXH5h+gS7hxiBRKb4/4xU7zxnhEEgc+rLz c+aKK0pMaa6k70MfJuHsUmVsHnnCk8vITV+utIbJsKjJomacZVNvWmE1J+Rbu8YKXHwX iBJ7bdkWiV+8iCGBYBPM4/kBoL+AmRPryLl9/kfcxjEHAQ1Amsex9vMmEeLrnjVyRV7i leCffPQ9oajgc+b02jNgvvawFgj4EgoMTuoioZkLci3v1HuzQYxMoYkMeoMxwMxs9jkX uO7A== X-Gm-Message-State: AGi0Pua1EuLAIgiceBy2uVsOlrfgPm0DXAGKwAEX4Zx2MVbhlYn4lZAY vrmcNi1FtmV0aWlRkbo1oqNLGIvVuzdHoOC9JQHFzZaa X-Google-Smtp-Source: APiQypJFW6neqH6Lampcbn4CBGyVlqbNGpISaud87EmgTyzcl3eQ9u9w2UVV2bk00mdFk9DvvS88tCxQw9dk2sR5PHo= X-Received: by 2002:a2e:3202:: with SMTP id y2mr1427330ljy.60.1586434197806; Thu, 09 Apr 2020 05:09:57 -0700 (PDT) MIME-Version: 1.0 References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> In-Reply-To: From: Spencer Dawkins at IETF Date: Thu, 9 Apr 2020 07:09:31 -0500 Message-ID: To: Alexander Pelov Cc: Carsten Bormann , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="000000000000d1e41d05a2da7ec0" Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 12:10:06 -0000 --000000000000d1e41d05a2da7ec0 Content-Type: text/plain; charset="UTF-8" Another day, another e-mail from Spencer :-) On Thu, Apr 9, 2020 at 5:29 AM Alexander Pelov wrote: > Dear Carsten, all, > > Thanks for the pointer and the interesting discussion! > I think one additional point was not yet mentioned regarding the Non-IP > architecture. In LPWANs you have essentially this, and the goal of SCHC > (RFC-to-be-8724) is exactly that - having IP-over-NonIP. There is even a > draft on SCHC-over-NBIOT. > > What would be the way to make sure the ETSI people are aware that they can > have the benefits of the Non-IP approach, all without losing compatibility > with the Internet? > That's actually a helpful question that's not arch-discuss-related. (This thread has had interesting questions that ARE arch-discuss-related - I'm just talking about the external relationship with other SDOs. Per https://tools.ietf.org/html/rfc2850#section-2, (f) External Liaison The IAB acts as representative of the interests of the IETF and the Internet Society in technical liaison relationships with other organizations concerned with standards and other technical and organizational issues relevant to the world-wide Internet. Liaisons are kept as informal as possible and must be of demonstrable value in improving the quality of IETF specifications. Individual members of the IETF are appointed as liaisons to other organizations by the IAB or IESG as appropriate. I am told (because I asked) that the IAB is also discussing the ETSI press announcement. Conveniently, the IAB already has a program on liaison oversight (details at https://www.iab.org/activities/programs/iab-liaison-coordination-program/ ). It has two current IAB members, and a bunch of people with deep experience in liaison management, shepherding, and trying to Do The Right Thing. I know that the IAB is also aware of this thread (because I asked), so we might wait for a few minutes while the new IAB (seated last month) gets organized and gets to work, and see what they do next. Please continue discussion as seems appropriate to you, of course. And that's my e-mail for the day :-) Best, Spencer, no hats --000000000000d1e41d05a2da7ec0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Another day, another e-mail from Spencer = :-)

On Thu, Apr 9, 2020 at 5:29 AM Alexander Pelov <a@ackl.io> wrote:
Dear Carsten, all,

Tha= nks for the pointer and the interesting discussion!
I think one a= dditional point was not yet mentioned regarding the Non-IP architecture. In= LPWANs you have essentially this, and the goal of SCHC (RFC-to-be-8724) is= exactly that - having IP-over-NonIP. There is even a draft on SCHC-over-NB= IOT.

What would be the way to make sure the ETSI p= eople are aware that they can have the benefits of the Non-IP approach, all= without losing compatibility with the Internet?

That's actually a helpful question that's not= arch-discuss-related. (This thread has had interesting questions that ARE = arch-discuss-related - I'm just talking about the external relationship= with other SDOs.


=C2=A0 =C2=A0(f) External Liaison=

=C2=A0 =C2=A0The IAB acts as representative of the interests of the= IETF and the
=C2=A0 =C2=A0Internet Society in technical liaison relatio= nships with other
=C2=A0 =C2=A0organizations concerned with standards an= d other technical and
=C2=A0 =C2=A0organizational issues relevant to the= world-wide Internet. Liaisons
=C2=A0 =C2=A0are kept as informal as poss= ible and must be of demonstrable value in
=C2=A0 =C2=A0improving the qua= lity of IETF specifications.=C2=A0 Individual members of
=C2=A0 =C2=A0th= e IETF are appointed as liaisons to other organizations by the IAB
=C2= =A0 =C2=A0or IESG as appropriate.

I am told (b= ecause I asked) that the IAB is also discussing the ETSI press announcement= .

Conveniently, the IAB already has a program on l= iaison oversight (details at=C2=A0https://www.iab.org/activities= /programs/iab-liaison-coordination-program/).=C2=A0

It has two current IAB members, and a bunch of people with deep exper= ience in liaison management, shepherding, and trying to Do The Right Thing.= =C2=A0

I know that the IAB is also aware of this t= hread (because I asked), so we might wait for a few minutes while the new I= AB (seated last month) gets organized and gets to work, and see what they d= o next.

Please continue discussion as seems approp= riate to you, of course.=C2=A0

And that's my e= -mail for the day :-)

Best,

Spencer, no hats
--000000000000d1e41d05a2da7ec0-- From nobody Thu Apr 9 05:19:55 2020 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 1997E3A09F4 for ; Thu, 9 Apr 2020 05:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 irYmCNzEX0nB for ; Thu, 9 Apr 2020 05:19:48 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B02F3A09F3 for ; Thu, 9 Apr 2020 05:19:48 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 95576548045; Thu, 9 Apr 2020 14:19:41 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 8C557440040; Thu, 9 Apr 2020 14:19:41 +0200 (CEST) Date: Thu, 9 Apr 2020 14:19:41 +0200 From: Toerless Eckert To: Lars Eggert Cc: architecture-discuss@ietf.org Message-ID: <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 12:19:50 -0000 On Thu, Apr 09, 2020 at 12:14:04PM +0300, Lars Eggert wrote: > Hi, > > On 2020-4-8, at 22:41, Toerless Eckert wrote: > > When technologies are young, you just let engineers > > innovate and implement and when everything is done, you > > can go and fight for it to get standardized. When an > > industries becomes more mature and a lot more capital > > investment heavy, you need to revert this and SDOs > > need to play a lot more proactive role in defining > > next-gen solutions. See 3GPP. IETF is not doing this > > at the architecture scale. Only at small incremental > > enhancements. > > if this is what you belief needs to happen, please do take this work to the ITU-T. Just making sure i understand your statement correctly: You only want for IAB and IETF to continue do only small incremental enhancements ? Btw: I do not need to take any work to ITU-T or 3GPP. These SDOs will move forward with whatever they want to do without consulting IETF. Cheers Toerless > Lars > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Thu Apr 9 05:24:17 2020 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 DEE523A0A01 for ; Thu, 9 Apr 2020 05:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 mTzlqOXFlBKA for ; Thu, 9 Apr 2020 05:24:14 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 450EC3A09FC for ; Thu, 9 Apr 2020 05:24:14 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id AB960548042; Thu, 9 Apr 2020 14:24:09 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id A1AC8440040; Thu, 9 Apr 2020 14:24:09 +0200 (CEST) Date: Thu, 9 Apr 2020 14:24:09 +0200 From: Toerless Eckert To: Lars Eggert Cc: Carsten Bormann , architecture-discuss@ietf.org Message-ID: <20200409122409.GA28965@faui48f.informatik.uni-erlangen.de> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <09CE56D4-985B-41A4-AA8B-A459B4A5E696@eggert.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09CE56D4-985B-41A4-AA8B-A459B4A5E696@eggert.org> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 12:24:16 -0000 To me, the interesting question is really if/whether ICN has a chance to happen as software in data centers. Last i looked (2 years ago ?), Cisco seems to have made that pitch architecturally. I am always sceptical of classical interoperating networking solutions (ICN or else) to be successul in that DC software-only deployment model. Lot more abilities for vertical proprietary solutions to be faster successful. Any good "state of affairs" summary in ICNRG ? Sorry... didn't track the RG. Cheers Toerless On Thu, Apr 09, 2020 at 12:07:26PM +0300, Lars Eggert wrote: > On 2020-4-8, at 21:57, Carsten Bormann wrote: > > There has been a decade of ???clean slate Internet??? discussion, and only ICN emerged as an interesting new architecture from that context. So I???m not very optimistic with any process that tries to relive that process. But genuine new ideas do get generated now and then, and I would be quite interested to hear about them without the now obligatory press release bombast on how they will create cheaper battery technology for flying cars and cure Covid-19 at the same time. > > +1 > > An even ICN has an uncertain road to larger-scale deployment. > > Lars From nobody Thu Apr 9 05:26:57 2020 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 6BC193A0A0A for ; Thu, 9 Apr 2020 05:26:56 -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 FGCs9qck6EpM for ; Thu, 9 Apr 2020 05:26:53 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9CF73A0A08 for ; Thu, 9 Apr 2020 05:26:52 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48ygPR1FYYzyrc; Thu, 9 Apr 2020 14:26:51 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> Date: Thu, 9 Apr 2020 14:26:50 +0200 Cc: Stephane Bortzmeyer , architecture-discuss@ietf.org X-Mao-Original-Outgoing-Id: 608128010.518101-dc0e28d143ec75d26f755bba944016bb Content-Transfer-Encoding: quoted-printable Message-Id: References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [arch-d] Other SDOs (Re: ETSI launches new group on Non-IP Networking addressing 5G new services) 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, 09 Apr 2020 12:26:57 -0000 On 2020-04-08, at 21:41, Toerless Eckert wrote: >=20 > When would have > IETF leadership ever have tried to explain/help IETF attendants to > do better work in another SDO ? I=E2=80=99m not sure WG chairs qualify as =E2=80=9Cleadership=E2=80=9D = in your view (they do, in my view), but that has been a constant theme = for us in IoT-land. > Which meeting did i miss about this ? Well, we didn=E2=80=99t quite start by saying =E2=80=9Cthis is the way = we, the IETF, will work with other SDOs, now eat it=E2=80=9D. We = started by working with other SDOs and tried to find out what they = actually need. Interestingly, one of the homes of that work is the T2TRG, as it turns = out that IETF and other-SDO work isn=E2=80=99t already perfectly = aligned, so you need a wider view (and a longer outlook) to really be = useful. I=E2=80=99m sure we are not yet nearly doing enough of this, but you = can=E2=80=99t say we (as an organization) ignore working with other = SDOs. > Maybe with the small exception of RTCweb and W3C (or maybe even more > in APP, i am not that much involved there). It may help that some of the IoT work is in ART (which encompasses what = previously was APP). Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Apr 9 05:34:10 2020 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 057963A08EE for ; Thu, 9 Apr 2020 05:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 llAzEQ2VoSxw for ; Thu, 9 Apr 2020 05:34:07 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1281C3A0926 for ; Thu, 9 Apr 2020 05:34:06 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7161D548048; Thu, 9 Apr 2020 14:34:02 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 67D3F440040; Thu, 9 Apr 2020 14:34:02 +0200 (CEST) Date: Thu, 9 Apr 2020 14:34:02 +0200 From: Toerless Eckert To: Carsten Bormann Cc: Stephane Bortzmeyer , architecture-discuss@ietf.org Message-ID: <20200409123402.GB28965@faui48f.informatik.uni-erlangen.de> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] Other SDOs (Re: ETSI launches new group on Non-IP Networking addressing 5G new services) 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, 09 Apr 2020 12:34:09 -0000 On Thu, Apr 09, 2020 at 02:26:50PM +0200, Carsten Bormann wrote: > On 2020-04-08, at 21:41, Toerless Eckert wrote: > > > > When would have > > IETF leadership ever have tried to explain/help IETF attendants to > > do better work in another SDO ? > > I???m not sure WG chairs qualify as ???leadership??? in your view (they do, in my view), but that has been a constant theme for us in IoT-land. Ok. great. I did mention i can imagine this to happen better in APP/ART, if it also happens in IoT land, all the better. I was just coming from not seeing it for ITU-T. Cheers Toerless > > Which meeting did i miss about this ? > > Well, we didn???t quite start by saying ???this is the way we, the IETF, will work with other SDOs, now eat it???. We started by working with other SDOs and tried to find out what they actually need. > Interestingly, one of the homes of that work is the T2TRG, as it turns out that IETF and other-SDO work isn???t already perfectly aligned, so you need a wider view (and a longer outlook) to really be useful. > > I???m sure we are not yet nearly doing enough of this, but you can???t say we (as an organization) ignore working with other SDOs. > > > Maybe with the small exception of RTCweb and W3C (or maybe even more > > in APP, i am not that much involved there). > > It may help that some of the IoT work is in ART (which encompasses what previously was APP). > > Grüße, Carsten From nobody Thu Apr 9 05:48:53 2020 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 EEB323A0A74 for ; Thu, 9 Apr 2020 05:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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=mjmontpetit-com.20150623.gappssmtp.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 0ezqMfvKS_R9 for ; Thu, 9 Apr 2020 05:48:41 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 972663A0A6A for ; Thu, 9 Apr 2020 05:48:40 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id b1so11338246ljp.3 for ; Thu, 09 Apr 2020 05:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=b7apK3Qz5DFHNH8GF3nLArI16EFHMvlLWA/kekx3I3w=; b=v7MElAI+5pLen5PmDsjE5fyA8VzhhPqfrxVzFN3n67Yc/hs51qUgFWfGZy9Hmz57EQ 6BZRtFFu4NLn4LeqtPBOfjarAwByIHFm7oPgiBIdGYGtjJPO5cdHkQ7m7BAmx4jp76yq k+g0x+8Yiq/gLv8LEyw9c7mxI0Fi8qYrgFlUdj5I9PD5RLIbzLsxZ7uVDwHDZBbjVVuw xu8zn/Xe31QYVJn+4KXjdZ2OyfDykcotN+OLINioAvBWhG+E3ATes49P9XIyHSOs3zP4 AqUz5ei6xfb3yjkWcC1/XSwysMY5M/Jr6gYRv0eJLs1u/u+MQB9M/1JriQXYWahJ1BJ1 /4RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=b7apK3Qz5DFHNH8GF3nLArI16EFHMvlLWA/kekx3I3w=; b=dNxhjmBOuGbEyUXjA1ioOgiXoA//b2Gwnv2duM99JSVFvGuLps35Jjo7zXR0pk8/RA HNnCLc7a0dwck4SSzKrCXPkynUxrfanhFmEZr9TBzE+gwCpDVNe0pngnnwRsTGqpxF2n ODwWR08Hl/X410b90E/s0lU7KKgeWX6m8GWiLz60kgVVjdSnFccXIV/Yxei7EsEkMf6c MQaoV9EAuO59Tlkwbma4dXxvIN8vpvv/tpXy6Sr9H+ZhwAog6waOp4b03hi0SA9chZU2 QxTNG98oJ6bbz0Zxup3+mT3wHbc1HsR9kPBftLJ4o5tuQMnXoOtn/j/G7Idqj0POY290 8nbA== X-Gm-Message-State: AGi0PuYOBWsXuZnvrTFAC22r68N8afICnUj9GQmEOF3iBmEkLhSPhttD VYEfYUe3+zKtDbiqaB0xREJbcZgJ2FIVU4BkI6imcg== X-Google-Smtp-Source: APiQypLZT1mdqsMIeFIVXguK2DJoCnC3MrKus2NWOtvxA8IjsFbS43N6VAym2LjLgBAU07JDzMSPzf2/4rrvRgytKZg= X-Received: by 2002:a2e:b5bc:: with SMTP id f28mr8322738ljn.191.1586436518528; Thu, 09 Apr 2020 05:48:38 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 9 Apr 2020 05:48:37 -0700 From: Marie-Jose Montpetit In-Reply-To: <20200409122409.GA28965@faui48f.informatik.uni-erlangen.de> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <09CE56D4-985B-41A4-AA8B-A459B4A5E696@eggert.org> <20200409122409.GA28965@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Date: Thu, 9 Apr 2020 05:48:37 -0700 Message-ID: To: Lars Eggert , Toerless Eckert Cc: architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="0000000000002559a805a2db094d" Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 12:48:46 -0000 --0000000000002559a805a2db094d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Interesting that you mention vertically integrated solutions because in COIN and in related IoT research we are looking at common data layers to avoid having to go back to the DC or cloud before applications (in industry, agriculture etc.) can interoperate or data can be processed and communicated in order to create more advanced solutions using distributed cognition and machine learning. I know called these =E2=80=9Cpet projects= =E2=80=9D in a previous email but believe me there is not pet there but a real need. And I gather you may know about the ICNRG since your team was contributing :) And while this thread has gone on for a while and it=E2=80=99s nice to crit= icize what are you exactly proposing. What is the architecture you would like to be discussed? mjm Marie-Jos=C3=A9 Montpetit, Ph.D. marie@mjmontpetit.com On April 9, 2020 at 8:24:33 AM, Toerless Eckert (tte@cs.fau.de) wrote: To me, the interesting question is really if/whether ICN has a chance to happen as software in data centers. Last i looked (2 years ago ?), Cisco seems to have made that pitch architecturally. I am always sceptical of classical interoperating networking solutions (ICN or else) to be successul in that DC software-only deployment model. Lot more abilities for vertical proprietary solutions to be faster successful. Any good "state of affairs" summary in ICNRG ? Sorry... didn't track the RG. Cheers Toerless On Thu, Apr 09, 2020 at 12:07:26PM +0300, Lars Eggert wrote: > On 2020-4-8, at 21:57, Carsten Bormann wrote: > > There has been a decade of ???clean slate Internet??? discussion, and only ICN emerged as an interesting new architecture from that context. So I???m not very optimistic with any process that tries to relive that process. But genuine new ideas do get generated now and then, and I would be quite interested to hear about them without the now obligatory press release bombast on how they will create cheaper battery technology for flying cars and cure Covid-19 at the same time. > > +1 > > An even ICN has an uncertain road to larger-scale deployment. > > Lars _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www.ietf.org/mailman/listinfo/architecture-discuss --0000000000002559a805a2db094d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Inte= resting that you mention vertically integrated solutions because in COIN an= d in related IoT research we are looking at common data layers to avoid hav= ing to go back to the DC or cloud before applications (in industry, agricul= ture etc.) can interoperate or data can be processed and communicated in or= der to create more advanced solutions using distributed cognition and machi= ne learning. I know called these =E2=80=9Cpet projects=E2=80=9D in a previo= us email but believe me there is not pet there but a real need.

And I gather you may know abou= t the ICNRG since your team was contributing :)

And while this thread has gone on for a while = and it=E2=80=99s nice to criticize what are you exactly proposing. What is = the architecture you would like to be discussed?

mjm

Marie-Jos=C3=A9 Montpetit, Ph.D.

On April 9, 2020 at 8:24:33 AM, Toerles= s Eckert (tte@cs.fau.de) wrote:

To me= , the interesting question is really if/whether ICN
has a chance to happen as software in data centers.
Last i looked (2 years ago ?), Cisco seems to have made
that pitch architecturally.

I am always sceptical of classical interoperating
networking solutions (ICN or else) to be successul =20
in that DC software-only deployment model. Lot more
abilities for vertical proprietary solutions to be
faster successful.

Any good "state of affairs" summary in ICNRG ?
Sorry... didn't track the RG.

Cheers
Toerless

On Thu, Apr 09, 2020 at 12:07:26PM +0300, Lars Eggert wrote:
> On 2020-4-8, at 21:57, Carsten Bormann <cabo@tzi.org> wrote:
> > There has been a decade of ???clean slate Internet??? discuss= ion, and only ICN emerged as an interesting new architecture from that cont= ext. So I???m not very optimistic with any process that tries to relive th= at process. But genuine new ideas do get generated now and then, and I wou= ld be quite interested to hear about them without the now obligatory press = release bombast on how they will create cheaper battery technology for flyi= ng cars and cure Covid-19 at the same time.
> =20
> +1
> =20
> An even ICN has an uncertain road to larger-scale deployment.
> =20
> Lars

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@i= etf.org
= https://www.ietf.org/mailman/listinfo/architecture-discuss
--0000000000002559a805a2db094d-- From nobody Thu Apr 9 06:06:27 2020 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 6A4AD3A092F for ; Thu, 9 Apr 2020 06:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 McTczpAQbk6Q for ; Thu, 9 Apr 2020 06:06:21 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AC4F3A092D for ; Thu, 9 Apr 2020 06:06:20 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D19D6548015; Thu, 9 Apr 2020 15:06:14 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id C9023440040; Thu, 9 Apr 2020 15:06:14 +0200 (CEST) Date: Thu, 9 Apr 2020 15:06:14 +0200 From: Toerless Eckert To: Marie-Jose Montpetit Cc: Lars Eggert , architecture-discuss@ietf.org Message-ID: <20200409130614.GC28965@faui48f.informatik.uni-erlangen.de> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <09CE56D4-985B-41A4-AA8B-A459B4A5E696@eggert.org> <20200409122409.GA28965@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 13:06:25 -0000 On Thu, Apr 09, 2020 at 05:48:37AM -0700, Marie-Jose Montpetit wrote: > Interesting that you mention vertically integrated solutions because in > COIN and in related IoT research we are looking at common data layers to > avoid having to go back to the DC or cloud before applications (in > industry, agriculture etc.) can interoperate or data can be processed and > communicated in order to create more advanced solutions using distributed > cognition and machine learning. Yes. interesting virtual meeting earlier this week. > I know called these ???pet projects??? in a > previous email but believe me there is not pet there but a real need. Maybe i have not been using the term "pet" correctly, i was meaning to have it express something people are passionate about. Maybe i should have rather pointed to the financial incentives: Folks contributing work to IETF and IRTF do this because its most often part of their job/funding and its not really primarily self-elected (beyond the fact how they may be able to self-elect within bounds their funding). I think situation of topic selection by IAB members follows quite different rules. For better or worse. > And I gather you may know about the ICNRG since your team was contributing > :) Only had limied time to track that. Unfortunately a lot of defunding of ICN going on i think. > And while this thread has gone on for a while and > it???s nice to criticize what are you exactly proposing. > What is the architecture you would like to be discussed? Well, this threas was not started by what architecure i would like to see, that was a different thread, but thanks for asking: If you want to provide more explicit criticism for what wee have put out so far, please comment on: https://datatracker.ietf.org/doc/draft-bryant-arch-fwd-layer-ps/ Btw: while it will be fun to focus on the pieces you don't like (common feedback has been "i do not believe in hologram use-cases"), its obviously also helpful to comment on what you do agree on. This is not really proposals for specific architecture or protocol components, because there are certainly a lot of possible options. We started to write down the areas of concerns as a gap analysis because we have primarily seen the discuss about anything "New IP" come back with "what problem are you trying to solve". Of course we have ideas and proposals how to solve them, and will write them down too, but it would be a lot more interesting if other members of the community would bring in their ideas as well. Practically speaking, in our opinions, most of interesting future internet traffic that needs more than best-effort-network services will happen in metropolitan networks between towers/usrs and edge-DC, and i think we can and need to evolve the internet architecture for that future on many laers, starting at making the actual forwarding plane of all routes/switches programmable (which would be where i think your interest might be), up to the point of how to introduce monetization models for consumption of such future network services beyond the current model of "flat rate for network transport and secret anticompetitive backend deals for differentiated service delivery" Cheers Toerless > mjm > > Marie-José Montpetit, Ph.D. > marie@mjmontpetit.com > > > > On April 9, 2020 at 8:24:33 AM, Toerless Eckert (tte@cs.fau.de) wrote: > > To me, the interesting question is really if/whether ICN > has a chance to happen as software in data centers. > Last i looked (2 years ago ?), Cisco seems to have made > that pitch architecturally. > > I am always sceptical of classical interoperating > networking solutions (ICN or else) to be successul > in that DC software-only deployment model. Lot more > abilities for vertical proprietary solutions to be > faster successful. > > Any good "state of affairs" summary in ICNRG ? > Sorry... didn't track the RG. > > Cheers > Toerless > > On Thu, Apr 09, 2020 at 12:07:26PM +0300, Lars Eggert wrote: > > On 2020-4-8, at 21:57, Carsten Bormann wrote: > > > There has been a decade of ???clean slate Internet??? discussion, and > only ICN emerged as an interesting new architecture from that context. So > I???m not very optimistic with any process that tries to relive that > process. But genuine new ideas do get generated now and then, and I would > be quite interested to hear about them without the now obligatory press > release bombast on how they will create cheaper battery technology for > flying cars and cure Covid-19 at the same time. > > > > +1 > > > > An even ICN has an uncertain road to larger-scale deployment. > > > > Lars > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Thu Apr 9 06:51:33 2020 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 1A9883A0B7B for ; Thu, 9 Apr 2020 06:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 UL_6Hbm-KMV6 for ; Thu, 9 Apr 2020 06:51:27 -0700 (PDT) Received: from vs23.mail.saunalahti.fi (vs23.mail.saunalahti.fi [193.64.193.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 148B43A0B6E for ; Thu, 9 Apr 2020 06:51:27 -0700 (PDT) Received: from vs23.mail.saunalahti.fi (localhost [127.0.0.1]) by vs23.mail.saunalahti.fi (Postfix) with ESMTP id 7A3D3204A0; Thu, 9 Apr 2020 16:51:25 +0300 (EEST) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by vs23.mail.saunalahti.fi (Postfix) with ESMTP id 658262043D; Thu, 9 Apr 2020 16:51:25 +0300 (EEST) Received: from eggert.org (unknown [62.248.255.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eggert@elisanet.fi) by gw01.mail.saunalahti.fi (Postfix) with ESMTPSA id 3F32140002; Thu, 9 Apr 2020 16:51:23 +0300 (EEST) Received: from stickers.eggert.org (stickers.eggert.org [172.24.110.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id 2D5FB84E56B; Thu, 9 Apr 2020 16:51:17 +0300 (EEST) From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_6A2C98A6-AAE9-4DE5-92E3-CBE651616E05"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 9 Apr 2020 16:51:16 +0300 In-Reply-To: <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> Cc: architecture-discuss@ietf.org To: Toerless Eckert References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> X-MailScanner-ID: 2D5FB84E56B.A620C X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 13:51:32 -0000 --Apple-Mail=_6A2C98A6-AAE9-4DE5-92E3-CBE651616E05 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2020-4-9, at 15:19, Toerless Eckert wrote: > On Thu, Apr 09, 2020 at 12:14:04PM +0300, Lars Eggert wrote: >> On 2020-4-8, at 22:41, Toerless Eckert wrote: >>> When technologies are young, you just let engineers >>> innovate and implement and when everything is done, you >>> can go and fight for it to get standardized. When an >>> industries becomes more mature and a lot more capital >>> investment heavy, you need to revert this and SDOs >>> need to play a lot more proactive role in defining >>> next-gen solutions. See 3GPP. IETF is not doing this >>> at the architecture scale. Only at small incremental >>> enhancements. >>=20 >> if this is what you belief needs to happen, please do take this work = to the ITU-T. >=20 > Just making sure i understand your statement correctly: >=20 > You only want for IAB and IETF to continue do only small > incremental enhancements ? You seem to think small, incremental enhancements are somehow a bad = thing. We're disagreeing on that. We've managed to evolve the Internet = and its architecture pretty well through a series of small, incremental = enhancements at all layers. I don't see why continuing on this path is = such a bad thing. You seem to want to do some large-scale, monolithically-designed "v2" = architecture thing. This is not what the IETF does. Hence, my suggestion = is you try and do the work in a forum that likes to work that way, and = see if you manage to get anyone to deploy the outcome in the end. > Btw: I do not need to take any work to ITU-T or 3GPP. > These SDOs will move forward with whatever they want to > do without consulting IETF. Great. I guess we can then stop this discussion on am IETF list. Lars --Apple-Mail=_6A2C98A6-AAE9-4DE5-92E3-CBE651616E05 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl6PKFQACgkQVLXDCb9w wVf4Hg//R+lW8JtI0tRYuZ//9I4M1ePhhdjthns7g6LQpoPiRtiijOFLNCkyD0H/ OeG7o0e9kJF7MdqsBU8WfCk6rXN/FdHgTXI+rfnBYzY1LVpDSnKwF9HfS6yltZ3O R5jFcRAG1tbegl92tg7jj+TFs/q8y6cwELbz8FiY7IKzVFCDlQ7AHdyuUaf6jO7d Z6Kwl52946TxkFbOEzfPJp0btejJQuWZ5QWVqHf7OJmmS1ChDSp1xZSOiSfaR9Gu npfBc6HV5eO4oyjFjk6JU7WqHQBMi9r3RkUsvFHoHSRyM+4CFzC4KiaOeTc6zTkl AZpMEgUNEXfsqt43rfsM5AYvYiZdcAuD24mrft9JA3kFFZ/SRVDOqXIxJsCAlxiN l38fg24VcT5hLrPYkWoWl436JnFMrKTeXNgWwO6mYn5mi1iSklpRJRhEnwIGBbmV LdO2e823i3WtIa1NxfM1MePJPsEgrc9M/SrjV2iEHUw7Qbgcq9lCz+s12JLzf13p +SWx15cyJOkTxK6ViHABBUhd9gRMNNIPK7jqF+KqXtqniWfZ/LqSm8u/+jwM7OXD K76xVZWOoKNKuVMcRLsqNVG3b/bh0X03WB/w46HwoYn16MrhZlh4bgh5nfqspt+R N8b2yBqUgQ4gFnYkOWhAPx/y+ES2mtwP070ITccrvKrD+QZYL28= =vFvL -----END PGP SIGNATURE----- --Apple-Mail=_6A2C98A6-AAE9-4DE5-92E3-CBE651616E05-- From nobody Thu Apr 9 09:26:33 2020 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 6520D3A0ADD for ; Thu, 9 Apr 2020 09:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpi6uIvjmDEV for ; Thu, 9 Apr 2020 09:26:28 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 3FF393A0BBC for ; Thu, 9 Apr 2020 09:26:18 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id k1so12666524wrm.3 for ; Thu, 09 Apr 2020 09:26:18 -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=v89bFD/h+l2wfdPt33fT4zoANIb2k6YZ73tKGka3GYg=; b=SglAZfOb0wlzdGEg7zoPchj+9VTlCYGVasFfa6gcLH/k/0vAsicumztzS8ChYkUlVx xFHAufQnjS/jnrA2lhiArnKKmZYzSk+U5BHOxx7tktjUMysHo9q1JBZ/C17eVtCIITSp OED1qNHQtELincDKyE5yDTh51QFH0sZmlb1ylZ1nSNUWts6f0RzYIjc3z4ml8qmij7mX p3aBXURL1wtTzXsu0VdntVlzLBgEQaK2DpC39OScegPS5WP9JlI/s7TKmt/xg5LxyOsb 08UA1dKR7P38pGl3q/Sumd7obmD3W3e41yHMUTz7ODBQbXeMw8KU3HNCtssctHp9U5mq ruhw== 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=v89bFD/h+l2wfdPt33fT4zoANIb2k6YZ73tKGka3GYg=; b=mB/9zpqph5bQ37XtAdzo2x0GyMjJZUML6fcEN4uhcgJmJHo8GDPiaG3+iNsdz8eQIh CEjkJE+ARfdEUUGYBlEe9pDwEqOKe0GcRGVCG5A4XQrYxA/iwRxhgzjV2+6V044BRgiC xgl311667mgaE4lRmbbrTHROSAgKUBt72ezDlciYBWM755EZMT4FQpsP6wduuSUmllcT mNrEj/QXvNLQVYfjRUUd7zgeLEPZmZZ4YyUCscTivzy69pP342ugU3sg3BfRljs3T77V XTC5Gryk3KIbM6dat9l2QvhHHDPgF+838ILykI9tZNLCjAB/y8pjc4gVYPbpVNxt2BRZ XbSw== X-Gm-Message-State: AGi0Pub73Lrlh2bwmObDg2kvMwIX9LflPboDU5dtV3rdFV3/+zwQM0vb /DA+RUsnlNO0lftFWJi3PeghDX8wrDI= X-Google-Smtp-Source: APiQypLsD01tO2Q8Buzbs+mJ5VavcyA4uABAbTP1Tmv9AOuTu16kEQgU6g78HFof6hWqtPqJBCW3TA== X-Received: by 2002:adf:cd12:: with SMTP id w18mr14732794wrm.311.1586449576281; Thu, 09 Apr 2020 09:26:16 -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 l185sm4153409wml.44.2020.04.09.09.26.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2020 09:26:15 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9AA73364-5BE2-4BAC-8F0E-3A3FD06CF4A1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Thu, 9 Apr 2020 09:26:10 -0700 In-Reply-To: To: architecture-discuss@ietf.org References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 16:26:33 -0000 --Apple-Mail=_9AA73364-5BE2-4BAC-8F0E-3A3FD06CF4A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I wonder if this desire for new non-ip networking architectures, is = really a replay of the what I call the packet switching vs. circuit = switching debate. Somewhat more recently Ethernet vs. Token ring. = Basically, can networking architectures provide deterministic service = (like circuit switching), or is the Internet best effort OK. It was very common to hear that voice or video couldn=E2=80=99t possibly = work over an Internet style packet switching network. I haven=E2=80=99t = heard that in a while, or at least until recently after the 5G hype = started gearing up. I attended the lunch speaker session on 5G at the Singapore IETF, slides = can be found: = https://datatracker.ietf.org/meeting/106/materials/slides-106-edu-sessa-5g= -impact-on-networks-edge-cloud-and-slicing-00 Seemed to me it was proposing (see slide 13) an end to end 5G = network/service. Lots of words like "Guarantee transport SLAs for each = service=E2=80=9D, =E2=80=9COptimize network resources as load conditions = change=E2=80=9D, etc. I think arguments proposing a new non-ip = networking architecture is back to wanting a more deterministic = networking (aka circuit switching). I suppose it also has something to = do with wanting to sell services to very large numbers of devices (vs. = the current Internet model a subscription per enterprise or home user). I didn=E2=80=99t understand why all of this couldn=E2=80=99t be built = today with the current set of IP wireless and wired technologies. I = was thinking of coming to the mic and ask the speaker if he had heard = about the Internet, but decided it wouldn=E2=80=99t be constructive :-) Bob --Apple-Mail=_9AA73364-5BE2-4BAC-8F0E-3A3FD06CF4A1 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----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl6PTKIACgkQrut0EXfn u6gjmQgAgfQiNmUAP8DCyq2J475mMlEDZDDJEiwO90gbqhbpv0aAAT0X+ueuSjqn /G++OpqoIeNCIOJiYQMSUOKCeKt+e2+TOhQbTm/gf+sTfvtbo1Jev23OZuuNqNk0 vwdF8ZJ4EHJ4hZmS+RbTmGw05Y8yaPvrrIRBXXFGZKy7YgTdT+yhg6GSrsyiShsi 0CD7L7sAURgQuaA53qdep8MWvOHB1qSPQpalP2FVk0xqx2vBmy3J4MmUtfTW2cUa fy02nO8nJiFJYj6XDTebK/1UInL/ZGfC/oAb8Emw99jiJnA5n61Op7SdoUeIeyTf KXFwYnUwROAd9+GB9qi5rd1UvQg4kA== =Lg3q -----END PGP SIGNATURE----- --Apple-Mail=_9AA73364-5BE2-4BAC-8F0E-3A3FD06CF4A1-- From nobody Thu Apr 9 09:40:55 2020 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 0436B3A0C30 for ; Thu, 9 Apr 2020 09:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 XJ5AZ6ZS4u3f for ; Thu, 9 Apr 2020 09:40:51 -0700 (PDT) Received: from mx0a-00364e01.pphosted.com (mx0a-00364e01.pphosted.com [148.163.135.74]) (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 6D2353A0B1F for ; Thu, 9 Apr 2020 09:40:37 -0700 (PDT) Received: from pps.filterd (m0167069.ppops.net [127.0.0.1]) by mx0a-00364e01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 039GZjxV019965 for ; Thu, 9 Apr 2020 12:40:37 -0400 Received: from sendprodmail12.cc.columbia.edu (sendprodmail12.cc.columbia.edu [128.59.72.20]) by mx0a-00364e01.pphosted.com with ESMTP id 30920tt5w7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 09 Apr 2020 12:40:36 -0400 Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by sendprodmail12.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id 039GeZcI036743 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 9 Apr 2020 12:40:35 -0400 Received: by mail-qv1-f69.google.com with SMTP id p6so9815359qvo.18 for ; Thu, 09 Apr 2020 09:40:35 -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=zrEnk9R4EHedWWsDwf+XOxDGLDt/aQvLb/K43ddW8JA=; b=VZ2MUk0m4Atz3yXFddSWHeEMmu44f4x2oQ/LZFO04KZz57HnRej0aiVmo0JsoxnXL+ 2+I8UWzcPE5Q5+SzJ9CN1jwkqsCwUbbuY9Nwm4ilJudQaW5HJEsF4AROzb0N9pdW4thu WqTgfNq6EmFq4f7m9ABLb6IX5CNvTLicdyF/Zv5fSJgovXQTyHyeOKCR7SQzY1d0os4Y ggZfcbV575jT3n1WCwu9UhWjCFlkRzLW1UyU9yFApjw7OxJ2jzxvBazp5CGA2x3cxt4G 2XxGLRZa4jl2SHBWKFyQXoOtM9oBXJ5V9fyn9IkVl6hZcH2x+nkLwMYbmKPfk3o8JvZE HHNw== X-Gm-Message-State: AGi0Puay7+pPD1Dx61qpX3jmP66e4IT4phI5ZAjc+nDDIYXZGXwJDDba 1MOzZaW/zfL2s3lmHuYSptsE4TaW7TW3E2Xp5DVQWHFBSxKRoAiHqeFy/Xwmr9H3Onascr0lN1I HGFkmV2T1mFm+HBPQt5CgSH1ZhZPSBvHAlQQnHGys/oM8CuMzre/ysfg= X-Received: by 2002:a37:5f41:: with SMTP id t62mr772216qkb.410.1586450435207; Thu, 09 Apr 2020 09:40:35 -0700 (PDT) X-Google-Smtp-Source: APiQypLpg8zgRZ/tFAFaWE2oQqViP5iPhX7jGAp6DmRObKPfWstz/sBDj+dH20vxdOUx1pkX+lFCrufYw4ypqB/TpwQ= X-Received: by 2002:a37:5f41:: with SMTP id t62mr772170qkb.410.1586450434708; Thu, 09 Apr 2020 09:40:34 -0700 (PDT) MIME-Version: 1.0 References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> In-Reply-To: From: Henning Schulzrinne Date: Thu, 9 Apr 2020 12:40:08 -0400 Message-ID: To: Bob Hinden Cc: architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="0000000000009d87e805a2de46e9" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-09_05:2020-04-07, 2020-04-09 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 phishscore=0 adultscore=0 mlxlogscore=999 clxscore=1011 suspectscore=0 mlxscore=0 malwarescore=0 bulkscore=10 spamscore=0 lowpriorityscore=0 impostorscore=10 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004090120 Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 16:40:53 -0000 --0000000000009d87e805a2de46e9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Since we're talking slides, I'll throw in my take: http://www.cs.columbia.edu/~hgs/papers/2019/2019%20Internet40%20IIT-RTC.pdf Every single failed network architecture has promised QoS by making bits more expensive; every successful technology has lowered the total cost of deployment and operations and making bits cheaper. On Thu, Apr 9, 2020 at 12:26 PM Bob Hinden wrote: > I wonder if this desire for new non-ip networking architectures, is reall= y > a replay of the what I call the packet switching vs. circuit switching > debate. Somewhat more recently Ethernet vs. Token ring. Basically, can > networking architectures provide deterministic service (like circuit > switching), or is the Internet best effort OK. > > It was very common to hear that voice or video couldn=E2=80=99t possibly = work over > an Internet style packet switching network. I haven=E2=80=99t heard tha= t in a > while, or at least until recently after the 5G hype started gearing up. > > I attended the lunch speaker session on 5G at the Singapore IETF, slides > can be found: > > > https://datatracker.ietf.org/meeting/106/materials/slides-106-edu-sessa-5= g-impact-on-networks-edge-cloud-and-slicing-00 > > Seemed to me it was proposing (see slide 13) an end to end 5G > network/service. Lots of words like "Guarantee transport SLAs for each > service=E2=80=9D, =E2=80=9COptimize network resources as load conditions = change=E2=80=9D, etc. I > think arguments proposing a new non-ip networking architecture is back to > wanting a more deterministic networking (aka circuit switching). I > suppose it also has something to do with wanting to sell services to very > large numbers of devices (vs. the current Internet model a subscription p= er > enterprise or home user). > > I didn=E2=80=99t understand why all of this couldn=E2=80=99t be built tod= ay with the > current set of IP wireless and wired technologies. I was thinking of > coming to the mic and ask the speaker if he had heard about the Internet, > but decided it wouldn=E2=80=99t be constructive :-) > > Bob > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --0000000000009d87e805a2de46e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Since we're talking slides, I'll throw in my = take:


Every single failed network architecture has promised QoS by making bits= more expensive; every successful technology has lowered the total cost of = deployment and operations and making bits cheaper.

On Thu, Apr 9, 2020 at 12= :26 PM Bob Hinden <bob.hinden@gm= ail.com> wrote:
I wonder if this desire for new non-ip networking architectures, is = really a replay of the what I call the packet switching vs. circuit switchi= ng debate.=C2=A0 =C2=A0Somewhat more recently Ethernet vs. Token ring.=C2= =A0 Basically, can networking architectures provide deterministic service (= like circuit switching), or is the Internet best effort OK.

It was very common to hear that voice or video couldn=E2=80=99t possibly wo= rk over an Internet style packet switching network.=C2=A0 =C2=A0I haven=E2= =80=99t heard that in a while, or at least until recently after the 5G hype= started gearing up.

I attended the lunch speaker session on 5G at the Singapore IETF, slides ca= n be found:

https://datatracker.ietf.org/meeting/106/materials/slide= s-106-edu-sessa-5g-impact-on-networks-edge-cloud-and-slicing-00

Seemed to me it was proposing (see slide 13) an end to end 5G network/servi= ce.=C2=A0 Lots of words like "Guarantee transport SLAs for each servic= e=E2=80=9D, =E2=80=9COptimize network resources as load conditions change= =E2=80=9D, etc.=C2=A0 =C2=A0I think arguments proposing a new non-ip networ= king architecture is back to wanting a more deterministic networking (aka c= ircuit switching).=C2=A0 =C2=A0I suppose it also has something to do with w= anting to sell services to very large numbers of devices (vs. the current I= nternet model a subscription per enterprise or home user).

I didn=E2=80=99t understand why all of this couldn=E2=80=99t be built today= with the current set of IP wireless and wired technologies.=C2=A0 =C2=A0I = was thinking of coming to the mic and ask the speaker if he had heard about= the Internet, but decided it wouldn=E2=80=99t be constructive :-)

Bob


_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--0000000000009d87e805a2de46e9-- From nobody Thu Apr 9 10:54:42 2020 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 190503A0D8E for ; Thu, 9 Apr 2020 10:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 1KQOIjLTfBgy for ; Thu, 9 Apr 2020 10:54:37 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB6503A0D89 for ; Thu, 9 Apr 2020 10:54:36 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 8D76F548045; Thu, 9 Apr 2020 19:54:31 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 85522440040; Thu, 9 Apr 2020 19:54:31 +0200 (CEST) Date: Thu, 9 Apr 2020 19:54:31 +0200 From: Toerless Eckert To: Lars Eggert Cc: architecture-discuss@ietf.org Message-ID: <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 17:54:39 -0000 Thanks for the discussion points, Lars, inline. On Thu, Apr 09, 2020 at 04:51:16PM +0300, Lars Eggert wrote: > Hi, > > On 2020-4-9, at 15:19, Toerless Eckert wrote: > > On Thu, Apr 09, 2020 at 12:14:04PM +0300, Lars Eggert wrote: > >> On 2020-4-8, at 22:41, Toerless Eckert wrote: > >>> When technologies are young, you just let engineers > >>> innovate and implement and when everything is done, you > >>> can go and fight for it to get standardized. When an > >>> industries becomes more mature and a lot more capital > >>> investment heavy, you need to revert this and SDOs > >>> need to play a lot more proactive role in defining > >>> next-gen solutions. See 3GPP. IETF is not doing this > >>> at the architecture scale. Only at small incremental > >>> enhancements. > >> > >> if this is what you belief needs to happen, please do take this work to the ITU-T. > > > > Just making sure i understand your statement correctly: > > > > You only want for IAB and IETF to continue do only small > > incremental enhancements ? > > You seem to think small, incremental enhancements are somehow a bad thing. We're disagreeing on that. I am surprised to read that because that is not what i wrote and not what i think. I fear that maybe other people too are interpreting too much and wrong things into the whole excurse with ITU-T. I said "only": Incremental improvements are are absolutely essential. They are just not sufficient anymore IMHO for specific topics. > We've managed to evolve the Internet and its architecture > pretty well through a series of small, incremental > enhancements at all layers. I don't see why continuing > on this path is such a bad thing. Yes, and 30 years ago we made a mayor new step (IPNG -> IPv6) and learned a lot through it. After > 25 years of IPv6 we do not even seem to welcome a broader discussion how well or how-not-well-enough that step and its evolution since then has been. Or thinking about the benefits that even thinking about another IPNG step could have. Without saying that the result couldn't even be just a set of incremental enhancements (which mfor example could be expanding beyond RFC8200). Btw: stackevo does have a nice set of analysis of subsets of what we learned. Alas, the whole problem of evolving transport stack functions started with SPUD was not really followed up on. > You seem to want to do some large-scale, > monolithically-designed "v2" architecture thing. I never said this, and i don't want that. I am not sure i would read from the ITU-T(TSAG) statements a monolithical-designed v2, but i understand how that claim was made. I already said that i and my team where not involved in that but that our undersstanding of problems is in our gap draft and that we have not published specific architecture propsals beyond what you can glean from that draft. > This is not what the IETF does. I am not even sure what a good definition of monolythic architecture would be, but obviously one doesn't want to throw out the baby with the bathwater, and if we're talking about modularity, i think we rather need more than less. Aka: reusing CBOR as a common presentation layer like ancoding instead of monolytic one-off TLV definitions, or equally (my pet peeve) reused transport protocol components (such as SPUD) instead of every protocol (like QUIC) reinventing the whole wheel). Just examples. > Hence, my suggestion is you try and do the work in > a forum that likes to work that way, and see if you > manage to get anyone to deploy the outcome in the end. Oh, i did work in such a forum. Its called a big vendor inventing new stuff, getting it deployed and then going to the IETF and attempting to get it standardized. When today most routers are becoming white box vendors, the opportunity to do innovation that way in that space is just going to shift quite a bit. > > Btw: I do not need to take any work to ITU-T or 3GPP. > > These SDOs will move forward with whatever they want to > > do without consulting IETF. > > Great. I guess we can then stop this discussion on am IETF list. Well.. "this" thread was already "derailed" by Carsten with an ITU-T mentioning, even though it says "ETSI". (not a complaint...) I am indeed happy if we do not need to continue to discuss ITU-T/TSAG statments, but as long as there is the presumption that that ITU-T/TSAG statement is about what i and my colleagues are talking about, i am very happy that you give me the opportunity to clear up that misperception and confusion in threads like this. Thanks again Toerless > Lars From nobody Thu Apr 9 11:14:38 2020 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 C9B503A011D for ; Thu, 9 Apr 2020 11:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, PLING_QUERY=0.1, 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 RHdf89Yv_5ZR for ; Thu, 9 Apr 2020 11:14:35 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D80003A010D for ; Thu, 9 Apr 2020 11:14:34 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D3148548048; Thu, 9 Apr 2020 20:14:28 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id CD5DB440040; Thu, 9 Apr 2020 20:14:28 +0200 (CEST) Date: Thu, 9 Apr 2020 20:14:28 +0200 From: Toerless Eckert To: Henning Schulzrinne Cc: Bob Hinden , architecture-discuss@ietf.org Message-ID: <20200409181428.GG28965@faui48f.informatik.uni-erlangen.de> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [arch-d] Beyond Best Effort ?! Re: ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 18:14:37 -0000 This really goes to what i also think is one of the core architectural questions. There is an important amount of DiffServ in many private networks, including service provider video to the ome, that users might consider "Internet". There are IntServ uses for criticial traffic in Service providers and Enterprises (RSVP-TE), also for higher resilience (reroute with resource guarantees). TSN has a lot of critical manufacturing and othher industrial use cases, and those all want L3 support (DetNet). On the oter hand, we have in IETF not even come up with a better definition of fairness than don't kill all competing traffic, we have AFAIK no agreement of what level of aggressiveness of TCP congestion control should be the fairness standard (maybe L4S will help here a bit), and we are far from even acknowledging that we should also have solutions for differentiated dynamic bandwidth, even though we already have good technology proof points that it can be done. (Stuck in Net Neutrality ...). See below. We have recently made a bit of progress in IETF to better support less than best effort, that could actually make bits less expensive too. Aka: I agree that from 50,000 feet you are right, but when you come closer, you see that the picture is less binary, but that what you say its true for "Best Effort Internet", but that is not really sufficient, and its not true for many private networks. And it is going to become more of an issue, the more we want to apply Internet technologies for more critical infrastructure functions IMHO. Or even for more differentiated services experiences. I for once think its not a good QoS architecture when presidents have to call up NetFlix's CEO and ask him to reduce his companies pressure on the networks, because networks themselves can not distinguish this entertainment traffic from more critical traffic. Do you think this is the right QoS architecture for the Internet ? Are we going to have an IANA registries for the FAX numbers of those CEO's ? ;-)) (yeah, sorry, couldn't resist). Cheers Toerless On Thu, Apr 09, 2020 at 12:40:08PM -0400, Henning Schulzrinne wrote: > Since we're talking slides, I'll throw in my take: > > http://www.cs.columbia.edu/~hgs/papers/2019/2019%20Internet40%20IIT-RTC.pdf > > Every single failed network architecture has promised QoS by making bits > more expensive; every successful technology has lowered the total cost of > deployment and operations and making bits cheaper. > > On Thu, Apr 9, 2020 at 12:26 PM Bob Hinden wrote: > > > I wonder if this desire for new non-ip networking architectures, is really > > a replay of the what I call the packet switching vs. circuit switching > > debate. Somewhat more recently Ethernet vs. Token ring. Basically, can > > networking architectures provide deterministic service (like circuit > > switching), or is the Internet best effort OK. > > > > It was very common to hear that voice or video couldn???t possibly work over > > an Internet style packet switching network. I haven???t heard that in a > > while, or at least until recently after the 5G hype started gearing up. > > > > I attended the lunch speaker session on 5G at the Singapore IETF, slides > > can be found: > > > > > > https://datatracker.ietf.org/meeting/106/materials/slides-106-edu-sessa-5g-impact-on-networks-edge-cloud-and-slicing-00 > > > > Seemed to me it was proposing (see slide 13) an end to end 5G > > network/service. Lots of words like "Guarantee transport SLAs for each > > service???, ???Optimize network resources as load conditions change???, etc. I > > think arguments proposing a new non-ip networking architecture is back to > > wanting a more deterministic networking (aka circuit switching). I > > suppose it also has something to do with wanting to sell services to very > > large numbers of devices (vs. the current Internet model a subscription per > > enterprise or home user). > > > > I didn???t understand why all of this couldn???t be built today with the > > current set of IP wireless and wired technologies. I was thinking of > > coming to the mic and ask the speaker if he had heard about the Internet, > > but decided it wouldn???t be constructive :-) > > > > Bob > > > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Thu Apr 9 11:41:08 2020 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 76BA73A0BD7 for ; Thu, 9 Apr 2020 11:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 xS6XWELRkRj1 for ; Thu, 9 Apr 2020 11:41:02 -0700 (PDT) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 08D343A0BDC for ; Thu, 9 Apr 2020 11:40:51 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.136.239]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 039IeGYJ022874 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2020 11:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1586457628; x=1586544028; i=@elandsys.com; bh=gjsM7YfxmaJtk5TBBpPyIZ+rJ11X5jq4ywIS/2o8nRk=; h=Date:To:From:Subject:In-Reply-To:References; b=YicUtUqualY5AumR3LjBZed9CMIR5eoUiTWccKYfitR7tlldPzGMbiAMCk9sA30zn YMP86LwvL3xYWNXyt1WZO3Hfrjn9Xmd37Hi54R23iNnI5fbVhOT9M5ZpYnJ1/9aKET OpD/Kjv1nGsXSHR16GlyYKxXVciocwc/AagEsNQo= Message-Id: <6.2.5.6.2.20200409080057.0adeffc8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 09 Apr 2020 11:38:44 -0700 To: Toerless Eckert , architecture-discuss@ietf.org From: S Moonesamy In-Reply-To: <20200409113017.GX28965@faui48f.informatik.uni-erlangen.de> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408055530.GC28965@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200408102605.0ba41040@elandnews.com> <20200408195622.GK28965@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200408142709.0b957348@elandnews.com> <20200408230852.GS28965@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200408222422.0ae60b50@elandnews.com> <20200409113017.GX28965@faui48f.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 18:41:06 -0000 Hi Toerless, At 04:30 AM 09-04-2020, Toerless Eckert wrote: >Sure, and lets assume everybody does an excellent job in that: >Where on the IETF schedule is the open meeting with those liaisons >to discuss with them ? (same thing other side of course too). It's not on the schedule. >Its crazy that in research (IRTF) and protocol development (IEF), > the groups are started by pet topics of the community, and leadership >provides process management and adult supervision. > >And in architecture its the opposite: Work has to be pet topics >of IAB and the community has to provide adult supervision. > >WHich model works better ? >Why is architecture not using the model of research and protocol >development ? I don't see commenting on a draft as the community providing adult supervision to what the IAB may be working on. As for pet topics, there are one or more topics which I may be familiar with. Some people are more comfortable working on such topics. Looking at things from the outside, it is easy for me to say that a model would work better. The reality could be different. There isn't a unique model for protocol development (in the IETF). I commented about architecture previously: https://mailarchive.ietf.org/arch/msg/architecture-discuss/2oi-BrLgaosxRL-Q6KXuHaO8S7o Sorry, that doesn't answer your question. Regards, S. Moonesamy From nobody Thu Apr 9 12:11:12 2020 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 57FE23A0C41 for ; Thu, 9 Apr 2020 12:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 IPckqBTw_vHZ for ; Thu, 9 Apr 2020 12:11:08 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2106.outbound.protection.outlook.com [40.107.237.106]) (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 914653A0C3F for ; Thu, 9 Apr 2020 12:11:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OyjGEKo6ukgRe1o4GxHorC79s/5eRa6NZPfgP3GeDtm8D9z1chBCUOdDeKEpVFU3voN1B7WyNa6zs69SqueT1BRZUc/+xX1eObSwdBsI2EvBS67hWsRtiufyvln66/7xNUv4vdxr6SSrwu+18sfaKxwX2gfr0DcEwxFv7LJdn/bhLe5mFpzlzCcvQX3YLKaMVWj92OxfcyEr0e3qpJITZwOWAFsg0f/5+/aITn+9S2rJj9zwr1njUTehZGPYq6Aad05cEHwHqFk6EcTo7cNW8CtuC9L4RkTfbsAEGXjdo4/CW1batc513MEVAq0CPhlS69dZt6Jv+3EWpoFEscDrPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BkWeoTyAW7RG/dn3EtyYD9B/ao203uEVmdsC0AdgOAM=; b=E6ydfYXZskSEYVSbB/DTiQ8dgC6X6vipa1hqEo9MhuuiQmyWL0jXS86o2FSzcz1vY8FCgvEZBebETBxnBz7YAtE/UWfuso/e7oT929C4+Ec6yt+i92wwsVFdLnHzBJThuZjVHIW6aYrgxgbEOqFuTexDs/ytk1uffJGu1/8v02XXwCccA+igWL0iBAB0Uqu2qQ1UgQzD9CoD0vMHvgBKk+U4dh1OTvWG/S/90Ydnymo3MdncwsrxdqODnW+GUgBBYjjIEYcqOfUyk9vvYRyVJyzpJh7TNmd6Nvuv+sUC8PQPRopdj/dP7h+IBjZOLsPOJqPrkhpSN4+7RPme6AoPgw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BkWeoTyAW7RG/dn3EtyYD9B/ao203uEVmdsC0AdgOAM=; b=AVyrZEinFfbaiJOITPwc6yj1W89k2RV0ZUvXYeht4fKh7b/YMkvoUJeryLeepvJLR43ewxF6jRPfGZ8yY+rCLcwtUhZ4EMOwgcThoZ55+De9aZR5N8uhgvG4xKh2XRtq0Xs+YYFspnQqQVVI77z4duva7oyuMOW7HEB/dthFaG8= Received: from BN6PR13MB3169.namprd13.prod.outlook.com (2603:10b6:405:81::26) by BN6PR13MB1857.namprd13.prod.outlook.com (2603:10b6:404:145::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.13; Thu, 9 Apr 2020 19:11:07 +0000 Received: from BN6PR13MB3169.namprd13.prod.outlook.com ([fe80::acb5:4b4f:b7f6:4dee]) by BN6PR13MB3169.namprd13.prod.outlook.com ([fe80::acb5:4b4f:b7f6:4dee%3]) with mapi id 15.20.2900.015; Thu, 9 Apr 2020 19:11:06 +0000 From: Cedric Westphal To: Carsten Bormann CC: "architecture-discuss@ietf.org" Thread-Topic: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services Thread-Index: AQHWDWJra39TqB7yDUCsuAt3NtjX+KhuqlAAgAALyACAAN4dAIAA7ZkAgACogEA= Date: Thu, 9 Apr 2020 19:11:06 +0000 Message-ID: References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <09CE56D4-985B-41A4-AA8B-A459B4A5E696@eggert.org> In-Reply-To: <09CE56D4-985B-41A4-AA8B-A459B4A5E696@eggert.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=cedric.westphal@futurewei.com; x-originating-ip: [198.27.189.108] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aa7aaa2c-945b-435b-4019-08d7dcb9c174 x-ms-traffictypediagnostic: BN6PR13MB1857: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0368E78B5B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR13MB3169.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(39840400004)(396003)(136003)(376002)(366004)(346002)(76116006)(33656002)(6916009)(66946007)(66556008)(66476007)(66446008)(316002)(8936002)(6506007)(64756008)(81156014)(86362001)(7696005)(8676002)(52536014)(53546011)(478600001)(81166007)(55016002)(4744005)(186003)(2906002)(26005)(5660300002)(66574012)(71200400001)(44832011)(4001150100001)(9686003)(4326008); DIR:OUT; SFP:1102; received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: c7UUON9VoW28LCeSDpZ1BiMvsBQKdiSmSLpeR1v4MhRuLQcjNZY7gFH8+luVEu3A+RCsbruZlD7xA3y2xl6wiJmyuCP99R8MOxgPl44Q6CVvbjFzwXW+c993D4a/FBQwhFp9F4k4qWgB2iZDPRUF2B5emMvPp/HVQG2B7kIv2ZFsvX4qmIDLne17pQfoPIVyYbkJ4H++BH50duMzKl2KJ3BDXX2q2suXI8DV0SShYb9dwRKYPMptG97h268F1jY1sIZSB6vqhQSkFQZrZHqZLSlwbXrUjrXJqtrXb2oD3KalvfR4wRKRtbmn1HA0VC3nA2qafsYOoIZCVwHGc5/dCDv2Z2MVx0BZFbV45AU3MYX2TqgQdr/z0XsmEFjXp/pK7ntuqkGb4HanjVRRY74Xh0td+3HKM5xg43aH+5x81t1+4LXH0LvCoHhqU//5F6aN x-ms-exchange-antispam-messagedata: hsCdIdn4x9VA2SGWszGauEqC4yQ6GPEK0m1AnBUx2l9UMXkDKaNsMpSiTQuueVfOWT1Y+JIPHVTt0RJVsY3ccGb14XBCh+GrVUp43idr+ml7vsXx+h/8/RTkUWajTh7baag9EWcEpSySyffzazdiMg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-Network-Message-Id: aa7aaa2c-945b-435b-4019-08d7dcb9c174 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2020 19:11:06.7477 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 2FWFYnw+7a5EZp3oT/NdyhAETsY2fRqb0K1mfhQROAGVULg9Vel6C+vza9fAtWpJHEx+Nm9UDeTfmeBks9/GIw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR13MB1857 Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 19:11:10 -0000 SSBzZWVtIHRvIHJlY2FsbCB0aGF0IFNETiBjYW1lIG91dCBvZiBDbGVhbiBzbGF0ZSBJbnRlcm5l dCBwcm9ncmFtIGZyb20gTlNGLiBUaGF0IHdhcyBpbiAyMDA3IG9yIHNvIChzYW1lIHllYXIgYXMg dGhlIENDTiBwYXBlcikuDQpCZXN0LA0KDQpDLiANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IEFyY2hpdGVjdHVyZS1kaXNjdXNzIDxhcmNoaXRlY3R1cmUtZGlzY3Vzcy1ib3Vu Y2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTGFycyBFZ2dlcnQNClNlbnQ6IFRodXJzZGF5LCBB cHJpbCAwOSwgMjAyMCAyOjA3IEFNDQpUbzogQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+ DQpDYzogYXJjaGl0ZWN0dXJlLWRpc2N1c3NAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbYXJjaC1k XSBFVFNJIGxhdW5jaGVzIG5ldyBncm91cCBvbiBOb24tSVAgTmV0d29ya2luZyBhZGRyZXNzaW5n IDVHIG5ldyBzZXJ2aWNlcw0KDQpPbiAyMDIwLTQtOCwgYXQgMjE6NTcsIENhcnN0ZW4gQm9ybWFu biA8Y2Fib0B0emkub3JnPiB3cm90ZToNCj4gVGhlcmUgaGFzIGJlZW4gYSBkZWNhZGUgb2Yg4oCc Y2xlYW4gc2xhdGUgSW50ZXJuZXTigJ0gZGlzY3Vzc2lvbiwgYW5kIG9ubHkgSUNOIGVtZXJnZWQg YXMgYW4gaW50ZXJlc3RpbmcgbmV3IGFyY2hpdGVjdHVyZSBmcm9tIHRoYXQgY29udGV4dC4gIFNv IEnigJltIG5vdCB2ZXJ5IG9wdGltaXN0aWMgd2l0aCBhbnkgcHJvY2VzcyB0aGF0IHRyaWVzIHRv IHJlbGl2ZSB0aGF0IHByb2Nlc3MuICBCdXQgZ2VudWluZSBuZXcgaWRlYXMgZG8gZ2V0IGdlbmVy YXRlZCBub3cgYW5kIHRoZW4sIGFuZCBJIHdvdWxkIGJlIHF1aXRlIGludGVyZXN0ZWQgdG8gaGVh ciBhYm91dCB0aGVtIHdpdGhvdXQgdGhlIG5vdyBvYmxpZ2F0b3J5IHByZXNzIHJlbGVhc2UgYm9t YmFzdCBvbiBob3cgdGhleSB3aWxsIGNyZWF0ZSBjaGVhcGVyIGJhdHRlcnkgdGVjaG5vbG9neSBm b3IgZmx5aW5nIGNhcnMgYW5kIGN1cmUgQ292aWQtMTkgYXQgdGhlIHNhbWUgdGltZS4NCg0KKzEN Cg0KQW4gZXZlbiBJQ04gaGFzIGFuIHVuY2VydGFpbiByb2FkIHRvIGxhcmdlci1zY2FsZSBkZXBs b3ltZW50Lg0KDQpMYXJzDQo= From nobody Thu Apr 9 12:24:00 2020 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 1E2B03A0C87 for ; Thu, 9 Apr 2020 12:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4FFJHGXzLk1 for ; Thu, 9 Apr 2020 12:23:56 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 0BB983A10DB for ; Thu, 9 Apr 2020 12:23:12 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id c21so4581978pfo.5 for ; Thu, 09 Apr 2020 12:23:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version; bh=KuKXyrc9nKt7wj74pGZM2qMFnI5r4ICe+5bJOzhrI4o=; b=ZrHV85OgZR1LB2fEs80/H0YDrdemUL6TAOY9xITYXIeIG5/5lp2TBvQemDNDyngotS Ohsbl8/HZwggOafHlqn+zSn1nuak2N5isPAZLg0BB+cveAlAiZ4fMhrL58hZBaP6yezE ELEQbtAZAmjeWMDx3fApBrMPPzfE71nTzk3RW0QGs1Rkn7LoClH4qIR1r/luCxqMapNP OCR6UJWso12ewLSGZPd8b7yAUwCARJWDAr1/ynqZLyGfNGw8BqhlOV7QujImtJYMILQ/ MnDJs0FRSHrEzpDKQCo6WBeycOaAKu/Tcmub3Q0NCsL94I7OWh3KqRpPOwZNMuKvTstM mPOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version; bh=KuKXyrc9nKt7wj74pGZM2qMFnI5r4ICe+5bJOzhrI4o=; b=FIGLuns7VyNS3R/svGy5y+C8MyJSrbqfKXRZ74QYZ4a+s3iAjQXZvJdZ+37XFai3rH tA14YlRHI6FEZ52eDBw9WyRoEchtzu/u14zAfzMLVzBZg/CextYQIJbmnv8eMtFvwpbC SsYN8bEtWG+68zFroYwnJyTe4VqSQqxYs7Pq6dPQZrbu6S+WJxT2h56JFw3ycpsdflPn hoa6sXn/wHqPMELb8BOV5Z90WDwiiTPp8l2tXFc4zUpPsoerlo4rT2uNMu/Of/Pq4zHK I/w2qu1U2kKRnUSo9+GDELRNMY4CdIE9Dp0i3oq2NJm/doiISsn8wdUnnpcVLffsDA3+ knaA== X-Gm-Message-State: AGi0PuY5egY29E4sLqJ7Y+lrVkQHM5WV3Mx6n+Oz34Tvh4YUpuwMeoDa 9GzFg+scWXq/vUF9pjAVGYc15Uiw X-Google-Smtp-Source: APiQypL4Z4c0HokWHQkKcI5YqvpbCnhHyJy++5IXVzAngOIM2oqeIt0X8pnc3Mbtnzk5jYsnWNsCRw== X-Received: by 2002:a62:5cc1:: with SMTP id q184mr1096109pfb.259.1586460191860; Thu, 09 Apr 2020 12:23:11 -0700 (PDT) Received: from [192.168.1.2] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id 17sm9812814pfa.8.2020.04.09.12.23.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2020 12:23:10 -0700 (PDT) Date: Thu, 9 Apr 2020 12:23:00 -0700 From: Jeff Tantsura To: architecture-discuss@ietf.org, Bob Hinden Message-ID: <9fefd390-53c1-4e83-84b9-69b2af476bbb@Spark> In-Reply-To: References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> X-Readdle-Message-ID: 9fefd390-53c1-4e83-84b9-69b2af476bbb@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5e8f761d_288fa9d6_16f" Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 19:23:58 -0000 --5e8f761d_288fa9d6_16f Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Bob/all, We have published a draft that outlines in great details the architectura= l framework (based on IP and existing IET=46 technologies) in the slides = presented at lunch speaker session on 5G at the Singapore IET=46=C2=A0-=C2= =A0draft-bookham-rtgwg-nfix-arch. There=E2=80=99s already a number of successful deployments. Cheers, Jeff On Apr 9, 2020, 9:26 AM -0700, Bob Hinden , wrote= : > I wonder if this desire for new non-ip networking architectures, is rea= lly a replay of the what I call the packet switching vs. circuit switchin= g debate. Somewhat more recently Ethernet vs. Token ring. Basically, can = networking architectures provide deterministic service (like circuit swit= ching), or is the Internet best effort OK. > > It was very common to hear that voice or video couldn=E2=80=99t possibl= y work over an Internet style packet switching network. I haven=E2=80=99t= heard that in a while, or at least until recently after the 5G hype star= ted gearing up. > > I attended the lunch speaker session on 5G at the Singapore IET=46, sli= des can be found: > > https://datatracker.ietf.org/meeting/106/materials/slides-106-edu-sessa= -5g-impact-on-networks-edge-cloud-and-slicing-00 > > Seemed to me it was proposing (see slide 13) an end to end 5G network/s= ervice. Lots of words like =22Guarantee transport SLAs for each service=E2= =80=9D, =E2=80=9COptimize network resources as load conditions change=E2=80= =9D, etc. I think arguments proposing a new non-ip networking architectur= e is back to wanting a more deterministic networking (aka circuit switchi= ng). I suppose it also has something to do with wanting to sell services = to very large numbers of devices (vs. the current Internet model a subscr= iption per enterprise or home user). > > I didn=E2=80=99t understand why all of this couldn=E2=80=99t be built t= oday with the current set of IP wireless and wired technologies. I was th= inking of coming to the mic and ask the speaker if he had heard about the= Internet, but decided it wouldn=E2=80=99t be constructive :-) > > Bob > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Architecture-discuss mailing list > Architecture-discuss=40ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss --5e8f761d_288fa9d6_16f Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Bob/all,

We have published a draft that outlines in great details the architectura= l framework (based on IP and existing IET=46 technologies) in the slides = presented at lunch speaker session on 5G at the Singapore IET=46&=23160;-= &=23160;draft-bookham-rtgwg-nfix-arch.
There=E2=80=99s already a number of successful depl= oyments.&=23160;

Cheers,
Jeff
On Apr 9, 2020, 9:26 AM -0700, Bob = Hinden <bob.hinden=40gmail.com>, wrote:
I = wonder if this desire for new non-ip networking architectures, is really = a replay of the what I call the packet switching vs. circuit switching de= bate. Somewhat more recently Ethernet vs. Token ring. Basically, can netw= orking architectures provide deterministic service (like circuit switchin= g), or is the Internet best effort OK.

It was very common to hear that voice or video couldn=E2=80=99t possibly = work over an Internet style packet switching network. I haven=E2=80=99t h= eard that in a while, or at least until recently after the 5G hype starte= d gearing up.

I attended the lunch speaker session on 5G at the Singapore IET=46, slide= s can be found:

https://datatracker.ietf.org/meeting/106/materials/slides-106-edu-sessa-5= g-impact-on-networks-edge-cloud-and-slicing-00

Seemed to me it was proposing (see slide 13) an end to end 5G network/ser= vice. Lots of words like =22Guarantee transport SLAs for each service=E2=80= =9D, =E2=80=9COptimize network resources as load conditions change=E2=80=9D= , etc. I think arguments proposing a new non-ip networking architecture i= s back to wanting a more deterministic networking (aka circuit switching)= . I suppose it also has something to do with wanting to sell services to = very large numbers of devices (vs. the current Internet model a subscript= ion per enterprise or home user).

I didn=E2=80=99t understand why all of this couldn=E2=80=99t be built tod= ay with the current set of IP wireless and wired technologies. I was thin= king of coming to the mic and ask the speaker if he had heard about the I= nternet, but decided it wouldn=E2=80=99t be constructive :-)

Bob



=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Architecture-discuss mailing list
Architecture-discuss=40ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discuss
--5e8f761d_288fa9d6_16f-- From nobody Thu Apr 9 12:28:26 2020 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 A068D3A0B4A for ; Thu, 9 Apr 2020 12:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 aVogoDToVCzS for ; Thu, 9 Apr 2020 12:28:23 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0B913A0C91 for ; Thu, 9 Apr 2020 12:26:52 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id E823C548015; Thu, 9 Apr 2020 21:26:46 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id DF71A440040; Thu, 9 Apr 2020 21:26:46 +0200 (CEST) Date: Thu, 9 Apr 2020 21:26:46 +0200 From: Toerless Eckert To: S Moonesamy Cc: architecture-discuss@ietf.org Message-ID: <20200409192646.GI28965@faui48f.informatik.uni-erlangen.de> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408055530.GC28965@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200408102605.0ba41040@elandnews.com> <20200408195622.GK28965@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200408142709.0b957348@elandnews.com> <20200408230852.GS28965@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200408222422.0ae60b50@elandnews.com> <20200409113017.GX28965@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200409080057.0adeffc8@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20200409080057.0adeffc8@elandnews.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 19:28:25 -0000 On Thu, Apr 09, 2020 at 11:38:44AM -0700, S Moonesamy wrote: > I don't see commenting on a draft as the community providing adult > supervision to what the IAB may be working on. As for pet topics, there are > one or more topics which I may be familiar with. Some people are more > comfortable working on such topics. Looking at things from the outside, it > is easy for me to say that a model would work better. The reality could be > different. Sure, its just my impression that the IETF WG and IRTG RG model works a lot better from where i stand than the IAB model. I also didn't mean adult supervision in itself as a negativ term, i am quite happy that overall it happens in a way it does from IESG to WGs. I am just saying that i wish that i do not see any benefits in how the IAB is run differently from that model. > There isn't a unique model for protocol development (in the IETF). I > commented about architecture previously: https://mailarchive.ietf.org/arch/msg/architecture-discuss/2oi-BrLgaosxRL-Q6KXuHaO8S7o > Sorry, that doesn't answer your question. ;-) Haha, well, that mail discuss is more an example of the problem we have applying the IPv6 protocol architecture not only the the Internet layer, but also to network layers (forgive the missng well formalized names here). Different topic. Cheers Toerless From nobody Thu Apr 9 12:50:28 2020 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 B654C3A0D03 for ; Thu, 9 Apr 2020 12:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrMeWW84DnlZ for ; Thu, 9 Apr 2020 12:50:22 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 24C553A0D00 for ; Thu, 9 Apr 2020 12:50:21 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id g3so13416399wrx.2 for ; Thu, 09 Apr 2020 12:50:21 -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=LvP7wXuXNMo9mdezNPlCsptVvM1ygvAD67uIusFJbl4=; b=cPxa+2FqkkEFwmyLCdwzeenF6pCcGmAuiuFWa8oMKlUT0h6QD3EusAdPhKwMDA4XqX YHJzXAZwFErOIaR2bBgltNbV8Bj2bQ2XT1lwMg2BWyRvbIL8x//PP6t4ojwVmF9BtoGK LHjUGXZ78K8paExRsgOuxXcnrX5ev/owX7cB6RQGE3mIW3Y6Fnv9WwHLypepP0itSV3z t5I/HeR7idRY65NzrOIGziXtF3o2baToT02ONPtO36gdLtFMERF4hOeTuK8R7aW1rj53 YrNkeDUdAlwPyvdXpIHzf53jtl3BTFcrEbeBgVIS+CsaFlgSq+bN3raxWsYCtZkEgiKE N3AA== 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=LvP7wXuXNMo9mdezNPlCsptVvM1ygvAD67uIusFJbl4=; b=EUjdJLfilThxYUYBnXhAIscdSMGBjBACqKMP/23a6JGP9LldfR0FjX23s3qYltE7i9 +ONJ3WitjF12Phir2kBTb6xDUOER4cRELGxclNvNHWdms9zGmNae3SFBM2AN/7ZMk3H+ 4ydZNwuoRH8UoQtN+ZFAmX8d+mtZH6G09BcSraYLkIy/cHyyZoQj8G3kjJfJlah3J4Gp 5vBaCan73qQqEGGwQP4iQxA8XtZTp8QV7q1z9PKUN0il2Tb8e+6T3IH/zWVQZXk1go6g Tf8tUgEMs28CQBjSCBl1Uy9i7/ghpu9Gl6RHg6b97IIjKO6i7ghboMz9OT0JZJleHSpU bCUg== X-Gm-Message-State: AGi0PuY5eA/skAiH34w/GKpK+Hi3liWqbYmFJ1qgqmUxBZlnQbFWZMEs lODYYk42p1EkqP8WnjjlqLDB3MCs X-Google-Smtp-Source: APiQypI//zrK7mu3JkQkVrA48yLP6GFT59mNsSWz0GP1dIMNQdNZn3dXy/j9TLDRVZLZTxvX4J5b/g== X-Received: by 2002:a05:6000:1142:: with SMTP id d2mr753892wrx.320.1586461820350; Thu, 09 Apr 2020 12:50:20 -0700 (PDT) Received: from [192.168.0.8] (tchowndsl.claranet.co.uk. [212.188.254.49]) by smtp.gmail.com with ESMTPSA id z11sm25986281wrv.58.2020.04.09.12.50.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2020 12:50:19 -0700 (PDT) From: Tim Chown Message-Id: <69FD26EB-EC87-4C9B-B13D-1248FEBFB732@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F324AF93-D26A-43BE-AC16-67B9C4AC6556" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 9 Apr 2020 20:50:17 +0100 In-Reply-To: Cc: Bob Briscoe , Toerless Eckert , architecture-discuss@ietf.org To: Marie-Jose Montpetit References: <20200406160325.GI28965@faui48f.informatik.uni-erlangen.de> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [arch-d] Programmable forwarding plane discussions ? (was: Re: on the nature of architecture discussion) 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, 09 Apr 2020 19:50:26 -0000 --Apple-Mail=_F324AF93-D26A-43BE-AC16-67B9C4AC6556 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Oh, I had no idea from the name that COINRG had P4 in scope, thank you = for the pointer. Tim > On 6 Apr 2020, at 18:10, Marie-Jose Montpetit = wrote: >=20 > There is a IRTF RG on programmable forwarding planes: COINRG. >=20 > And we have an active mailing list and an interim tomorrow if you want = to participate. >=20 > mjm >=20 > Marie-Jos=C3=A9 Montpetit, Ph.D. > marie@mjmontpetit.com >=20 >=20 >=20 > On April 6, 2020 at 12:06:07 PM, Toerless Eckert (tte@cs.fau.de = ) wrote: >=20 >> To give one example aspect of what i would think of as a part=20 >> of the architecture: Discussions about pogrammable forwarding planes.=20= >>=20 >> We had one talk/presentation last year sponsored by IESG talking = about=20 >> forwarding planes. And i think we did already see some good = disagrement=20 >> (discussion starter) about how flexible or inflexible we should = consider=20 >> them to be now or how much they could be more flexible in the future.=20= >> I for once think that wee could promote for them to be more flexible=20= >> if we would start getting our heads around this and maybe start = writing=20 >> up insights and expectations.=20 >>=20 >> There are several attendees whose organizations have collected=20 >> experiences with options such as P4, FPGA or fd.io . = But we have=20 >> no forum whatsoever to discuss those programmable forwarding plane=20 >> aspects. Heck, i am sure there would be interest for IETF = participants=20 >> interested in this topic to contribute educational insight, summaries=20= >> of experiences, and thoughts about gaps that should and could be=20 >> closed.=20 >>=20 >> I for once am of the firm believ that the degree of innovation on any=20= >> platform is proportional to the degree of flexible programmability=20 >> by third parties. See VNF/NFV in data centers versus ossification in=20= >> gigabit switching in the WAN. But once we get to those forwarding=20 >> planes, i think freely programmable can not mean x.86 style, but=20 >> it does need to mean something beyond P4, and it does IMHO also=20 >> mean that we have to do reusable extensible protocols or else we=20 >> can not have virtual programmed networks due to lack of code space.=20= >> Etc. pp...=20 >>=20 >> So, why don't we even have a mailing list for such discussions ?=20 >> Yes, fragementing into many mailing lists has downsides, but most = people=20 >> here (beside probbly myself) would have likely not thought about=20 >> forwarding plane architectures when they joined architecture-discuss,=20= >> so having a more specific mailing list and promoting it might help=20 >> to even attract the interested community.=20 >>=20 >> Of course, anything IETF organization would be easier if there was=20 >> a sponsor in leadership. And even for a mailing list, such a sponsor=20= >> is mandatory.=20 >>=20 >> Cheers=20 >> Toerless=20 >>=20 >> On Mon, Apr 06, 2020 at 02:25:31PM +0100, Bob Briscoe wrote:=20 >> > Toerless,=20 >> > =20 >> > I helped with a series of 'Re-Arch' research workshops from 2008 to = 2010.=20 >> > The name was about "re-architecting" the Internet (whatever that = means), but=20 >> > the accepted papers included articulation of insights about the = existing=20 >> > architecture. I was also involved in various activities before that = to=20 >> > promote research investigation into the Internet's architecture. = So, based=20 >> > on that experience, here's my 2 penny's worth.=20 >> > =20 >> > You don't want to have "arch-dispatch" sessions too often. Good=20 >> > architectural ideas don't come up that often, so if you create too = much=20 >> > space to talk about them, the vacuum will get filled with waffle. = Once a=20 >> > year is probably enough. But then, if you detect waffle is starting = to fill=20 >> > a vacuum, it's best to back off the timer to biennial. Of course, = if some=20 >> > new activity spins out of this (as it sometimes should from an = arch-dispatch=20 >> > activity), that takes on a separate existence that is more frequent = than the=20 >> > annual cycle of dispatch sessions.=20 >> > =20 >> > You certainly don't want to do this from mic lines. It's too easy = for=20 >> > "random-ietf-bigot" to have opinions about architecture that don't = add=20 >> > anything (other than for those collecting lists of opinions). = Contributors=20 >> > need to have had to do some work, like writing an accepted paper, = to even=20 >> > get into the room.=20 >> > =20 >> > It needs to be framed in a context of actionable outcomes. I mean, = something=20 >> > like arch-dispatch would be a suitable context, 'cos it gives out = the=20 >> > "actionable-only" message. That doesn't preclude "vague thoughts", = but only=20 >> > as long as they have the potential to lead to some change that will = impact=20 >> > on real life once they firm-up.=20 >> > =20 >> > So, IAB might be a more appropriate context than IRTF, but you want = an=20 >> > environment that will attract researchers and thinkers. So the = "political=20 >> > officers" need to be in the background managing the process rather = than=20 >> > holding the floor.=20 >> > =20 >> > The architecture of such a valuable artefact as the Internet can = become=20 >> > highly political. Huge businesses have been built on the Internet's = current=20 >> > architecture, with a vested interest for it not to change. One = person's=20 >> > architectural improvement is destruction of someone else's business = (selling=20 >> > hacks to work round architectural problems is big business). And = one=20 >> > progression of changes destroys someone else's idea of how they = thought=20 >> > changes would progress. So altho the discussion will often seem = academic,=20 >> > the structure in which ideas are taken forward has to be resilient = against=20 >> > the wars it might start. That part is much easier said than done.=20= >> > =20 >> > Cheers=20 >> > =20 >> > =20 >> > Bob=20 >> > =20 >> > On 03/04/2020 02:05, Toerless Eckert wrote:=20 >> > > On Thu, Apr 02, 2020 at 11:58:34AM -0800, Melinda Shore wrote:=20 >> > > > On 4/2/20 11:34 AM, Toerless Eckert wrote:=20 >> > > > > Was it only presentations or also associated drafts ? Was the=20= >> > > > > material asked to be make available sufficiently long ago to=20= >> > > > > allow quality updates be prior review ?=20 >> > > > Neither, really. It largely consisted of heated discussions at=20= >> > > > the mike lines. While there were presentations, for the most=20 >> > > > part they were not architectural in nature (with a few notable=20= >> > > > exceptions).=20 >> > > Ok, remembering some bits now.=20 >> > > That was fun, but yes, not what i was thinking of.=20 >> > > =20 >> > > > My sense, from several decades of involvement in the IETF in=20 >> > > > various capacities, is that 1) it would take years to get=20 >> > > > agreement on a diagram of the current internet architecture=20 >> > > > and what you'd end up would be aspirational rather than=20 >> > > > descriptive;=20 >> > > I think we can and are doing descriptive. Most of stackevo=20 >> > > mentioned by you below was descriptive. So are IMHO=20 >> > > many other documents/RFC i would consider to be architectural..=20= >> > > =20 >> > > I can think of aspirational as a good and even necessar thing..=20= >> > > =20 >> > > > 2) architectural discussions in the past have=20 >> > > > had minimal impact on actual protocol design;=20 >> > > That is a very broad statement. We should first have an=20 >> > > unserstanding about what we mean with architecture before=20 >> > > i should even ask you to give me example evidence of this.=20 >> > > =20 >> > > My architecture interests for example are probably a lot lower=20 >> > > inside the machine room of the Internet than e.g. the=20 >> > > Internet BGP peering architecure. But all of it is valid=20 >> > > architecture topics to me.=20 >> > > =20 >> > > For example, i would consider CBOR an example of an=20 >> > > architcure concept (presentation layer) brought into=20 >> > > IETF and protocols.=20 >> > > =20 >> > > One example architecture area of interest for me is the problem = that we=20 >> > > are not well enough taking the architecture of routers in to=20 >> > > account for our protocols, or better yet propose to evolve=20 >> > > architecture of both routers and protocols to be better fits in = the=20 >> > > future.=20 >> > > =20 >> > > I am betting neither of these topics are what you would=20 >> > > have considered to be architecture in your statement... ??=20 >> > > =20 >> > > > and 3) complexity=20 >> > > > always wins in the end (the history and output of the NSIS=20 >> > > > working group might be a particularly illustrative example=20 >> > > > of the latter).=20 >> > > > =20 >> > > > Right now, there is nothing stopping anybody from publishing=20 >> > > > drafts and contributing to (or, indeed, leading) architectural=20= >> > > > discussions in IETF working groups. I'm not sure what=20 >> > > > inferences we should make from the fact that for the most part=20= >> > > > that's not happening now.=20 >> > > If architecture can be associated directly with protocols=20 >> > > of an IETF WG, then yes, it could and should happen=20 >> > > in that WG, but i think there are more cases where even=20 >> > > this does not happen. E.g.: I have seen ADs eliminate = architecture=20 >> > > from charters because it does not produce implementable = protocols.=20 >> > > =20 >> > > But the more fundamental issue is that architecture mostly=20 >> > > needs to predate protocol development, like research mostly=20 >> > > needs to predate architecture and protocols. I can not=20 >> > > see a logic that argues we must have an IRTF, but we cannot=20 >> > > have an IATF (Internet Architecture Task Force). The=20 >> > > whole construct of IAB for architecture is weird to me.=20 >> > > =20 >> > > > I'm skeptical about the actual value of what you're proposing=20= >> > > > but as I said, there's nothing stopping you (or anybody else)=20= >> > > > from starting up something informally, which would give us all=20= >> > > > a better sense of the actual interest level and what the likely=20= >> > > > output would be.=20 >> > > Oh, i think there is a lot of sport in trying to discourage work=20= >> > > that is not officially sponsored by the IETF/IAB authorities=20 >> > > at least from my imited experience.=20 >> > > =20 >> > > We need to be darn careful with every single word we=20 >> > > write about a side meeting. Make sure it is called "non official"=20= >> > > every time you mention it, having people seemingly "borrow"=20 >> > > sign up sheets for examination what could be wrong with them,=20 >> > > ending up with concerns of using the same color (!) as "official" = IETF=20 >> > > meeting sign up sheets. Dismissive comments about even doing=20 >> > > a side-meeting, Not being allowed to use IETF tooling=20 >> > > like webex, jabber, wiki, etherpad, and so on. Because using=20 >> > > IETF tools would mean "endorsement of the activity" *sigh*.=20 >> > > =20 >> > > This is sad in general, but at a time when it is legally crucial=20= >> > > to make sure all communications is easily recognizeable as=20 >> > > public and published because of the US Govt. export regulations=20= >> > > (see EAR 734.7) it is outright dangerous to make it so difficult=20= >> > > for inofficial side-meetings to use or emulate the=20 >> > > public/published nature of official IETF meetings.=20 >> > > =20 >> > > > Also, note that there have been IAB programs like stackevo to=20= >> > > > deal with these questions.=20 >> > > Last RFC published in 2016. Concluded in 2019.=20 >> > > Followup to architecture-discuss according to closing mail.=20 >> > > =20 >> > > Cheers=20 >> > > Toerless=20 >> > > > Melinda=20 >> > > > =20 >> > > > =20 >> > > > -- =20 >> > > > Melinda Shore=20 >> > > > melinda.shore@nomountain.net = =20 >> > > > =20 >> > > > Software longa, hardware brevis=20 >> > > > =20 >> > > =20 >> > > =20 >> > > =20 >> > > > _______________________________________________=20 >> > > > Architecture-discuss mailing list=20 >> > > > Architecture-discuss@ietf.org = =20 >> > > > https://www.ietf.org/mailman/listinfo/architecture-discuss = =20 >> > > =20 >> > =20 >> > -- =20 >> > ________________________________________________________________=20 >> > Bob Briscoe http://bobbriscoe.net/ =20 >> > =20 >> > _______________________________________________=20 >> > Architecture-discuss mailing list=20 >> > Architecture-discuss@ietf.org = =20 >> > https://www.ietf.org/mailman/listinfo/architecture-discuss = =20 >>=20 >> -- =20 >> ---=20 >> tte@cs.fau.de =20 >>=20 >> _______________________________________________=20 >> Architecture-discuss mailing list=20 >> Architecture-discuss@ietf.org =20= >> https://www.ietf.org/mailman/listinfo/architecture-discuss = =20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss = --Apple-Mail=_F324AF93-D26A-43BE-AC16-67B9C4AC6556 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Oh, = I had no idea from the name that COINRG had P4 in scope, thank you for = the pointer.

Tim

On 6 Apr 2020, at 18:10, Marie-Jose Montpetit <marie@mjmontpetit.com> wrote:

There is a IRTF RG on programmable forwarding planes: = COINRG.

And we have an active mailing list and an interim = tomorrow if you want to participate.

mjm

Marie-Jos=C3=A9 Montpetit, Ph.D.
marie@mjmontpetit.com



On April 6, 2020 at 12:06:07 PM, Toerless Eckert = (tte@cs.fau.de) = wrote:

To give one example aspect of what i = would think of as a part 
of the = architecture: Discussions about pogrammable forwarding planes. 

We had one talk/presentation last year sponsored by IESG = talking about 
forwarding planes. And i think we did already see some good = disagrement 
(discussion starter) about how flexible or inflexible we = should consider 
them to be now or how much they could be more flexible in the = future. 
I= for once think that wee could promote for them to be more flexible 
if we would = start getting our heads around this and maybe start writing 
up insights = and expectations. 

There are several attendees whose = organizations have collected 
experiences = with options such as P4, FPGA or fd.io. But we have 
no forum = whatsoever to discuss those programmable forwarding plane 
aspects. = Heck, i am sure there would be interest for IETF participants 
interested = in this topic to contribute educational insight, summaries 
of = experiences, and thoughts about gaps that should and could be 
closed. 

I for once am of the firm believ that the degree of = innovation on any 
platform is proportional to the degree of flexible = programmability 
by third parties. See VNF/NFV in data centers versus = ossification in 
gigabit switching in the WAN. But once we get to those = forwarding 
planes, i think freely programmable can not mean x.86 style, = but 
it = does need to mean something beyond P4, and it does IMHO also 
mean that we = have to do reusable extensible protocols or else we 
can not have = virtual programmed networks due to lack of code space. 
Etc. = pp... 
So, why don't we even have a mailing list for such = discussions ? 
Yes, fragementing into many mailing lists has downsides, but = most people 
here (beside probbly myself) would have likely not thought = about 
forwarding plane architectures when they joined = architecture-discuss, 
so having a = more specific mailing list and promoting it might help 
to even = attract the interested community. 

Of course, anything IETF organization would be easier if = there was 
a sponsor in leadership. And even for a mailing list, such a = sponsor 
is mandatory. 

Cheers 
Toerless 

On Mon, Apr 06, 2020 at 02:25:31PM +0100, Bob = Briscoe wrote: 
> Toerless, 
>  
> I = helped with a series of 'Re-Arch' research workshops from 2008 to = 2010. 
> The name was about "re-architecting" the Internet = (whatever that means), but 
> the = accepted papers included articulation of insights about the = existing 
> architecture. I was also involved in various activities = before that to 
> promote research investigation into the Internet's = architecture. So, based 
> on that = experience, here's my 2 penny's worth. 
>  
> You = don't want to have "arch-dispatch" sessions too often. Good 
> = architectural ideas don't come up that often, so if you create too = much 
>= space to talk about them, the vacuum will get filled with waffle. Once = a 
> = year is probably enough. But then, if you detect waffle is starting to = fill 
>= a vacuum, it's best to back off the timer to biennial. Of course, if = some 
>= new activity spins out of this (as it sometimes should from an = arch-dispatch 
> activity), that takes on a separate existence that is = more frequent than the 
> annual = cycle of dispatch sessions. 
>  
> You = certainly don't want to do this from mic lines. It's too easy for 
> = "random-ietf-bigot" to have opinions about architecture that don't = add 
> = anything (other than for those collecting lists of opinions). = Contributors 
> need to have had to do some work, like writing an = accepted paper, to even 
> get = into the room. 
>  
> It = needs to be framed in a context of actionable outcomes. I mean, = something 
> like arch-dispatch would be a suitable context, 'cos it = gives out the 
> "actionable-only" message. That doesn't preclude "vague = thoughts", but only 
> as long as they have the potential to lead to some = change that will impact 
> on real = life once they firm-up. 
>  
> So, IAB = might be a more appropriate context than IRTF, but you want an 
> = environment that will attract researchers and thinkers. So the = "political 
> officers" need to be in the background managing the = process rather than 
> holding the floor. 
>  
> The = architecture of such a valuable artefact as the Internet can become 
> highly = political. Huge businesses have been built on the Internet's = current 
> architecture, with a vested interest for it not to = change. One person's > architectural improvement is destruction of someone = else's business (selling 
> hacks = to work round architectural problems is big business). And one 
> = progression of changes destroys someone else's idea of how they = thought 
> changes would progress. So altho the discussion will = often seem academic, > the structure in which ideas are taken forward has to = be resilient against > the wars it might start. That part is much easier said = than done. 
>  
> = Cheers 
>  
>  
> = Bob 
>  
> On = 03/04/2020 02:05, Toerless Eckert wrote: 
> > On = Thu, Apr 02, 2020 at 11:58:34AM -0800, Melinda Shore wrote: 
> > = > On 4/2/20 11:34 AM, Toerless Eckert wrote: 
> > = > > Was it only presentations or also associated drafts ? Was = the 
> = > > > material asked to be make available sufficiently long ago = to 
> = > > > allow quality updates be prior review ? 
> > = > Neither, really. It largely consisted of heated discussions at 
> > = > the mike lines. While there were presentations, for the most 
> > = > part they were not architectural in nature (with a few notable 
> > = > exceptions). 
> > Ok, remembering some bits now. 
> > = That was fun, but yes, not what i was thinking of. 
> = >  
> > = > My sense, from several decades of involvement in the IETF in 
> > = > various capacities, is that 1) it would take years to get 
> > = > agreement on a diagram of the current internet architecture 
> > = > and what you'd end up would be aspirational rather than 
> > = > descriptive; 
> > I think we can and are doing descriptive. Most of = stackevo 
> > mentioned by you below was descriptive. So are = IMHO 
>= > many other documents/RFC i would consider to be = architectural.. 
> >  
> > I = can think of aspirational as a good and even necessar thing.. 
> = >  
> > = > 2) architectural discussions in the past have 
> > = > had minimal impact on actual protocol design; 
> > = That is a very broad statement. We should first have an 
> > = unserstanding about what we mean with architecture before 
> > i = should even ask you to give me example evidence of this. 
> = >  
> > My = architecture interests for example are probably a lot lower 
> > = inside the machine room of the Internet than e.g. the 
> > = Internet BGP peering architecure. But all of it is valid 
> > = architecture topics to me. 
> = >  
> > = For example, i would consider CBOR an example of an 
> > = architcure concept (presentation layer) brought into 
> > = IETF and protocols. 
> >  
> > = One example architecture area of interest for me is the problem that = we 
> = > are not well enough taking the architecture of routers in to 
> > = account for our protocols, or better yet propose to evolve 
> > = architecture of both routers and protocols to be better fits in the 
> > = future. 
> >  
> > I = am betting neither of these topics are what you would 
> > = have considered to be architecture in your statement... ?? 
> = >  
> > = > and 3) complexity 
> > = > always wins in the end (the history and output of the NSIS 
> > = > working group might be a particularly illustrative example 
> > = > of the latter). > > >  
> > = > Right now, there is nothing stopping anybody from publishing 
> > = > drafts and contributing to (or, indeed, leading) architectural 
> > = > discussions in IETF working groups. I'm not sure what 
> > = > inferences we should make from the fact that for the most part 
> > = > that's not happening now. 
> > If = architecture can be associated directly with protocols 
> > of = an IETF WG, then yes, it could and should happen 
> > in = that WG, but i think there are more cases where even 
> > = this does not happen. E.g.: I have seen ADs eliminate architecture 
> > = from charters because it does not produce implementable protocols. 
> = >  
> > = But the more fundamental issue is that architecture mostly 
> > = needs to predate protocol development, like research mostly 
> > = needs to predate architecture and protocols. I can not 
> > = see a logic that argues we must have an IRTF, but we cannot 
> > = have an IATF (Internet Architecture Task Force). The 
> > = whole construct of IAB for architecture is weird to me. 
> = >  
> > = > I'm skeptical about the actual value of what you're proposing 
> > = > but as I said, there's nothing stopping you (or anybody else) 
> > = > from starting up something informally, which would give us all 
> > = > a better sense of the actual interest level and what the = likely 
> > > output would be. 
> > = Oh, i think there is a lot of sport in trying to discourage work 
> > = that is not officially sponsored by the IETF/IAB authorities 
> > at = least from my imited experience. 
> = >  
> > We = need to be darn careful with every single word we 
> > = write about a side meeting. Make sure it is called "non official" 
> > = every time you mention it, having people seemingly "borrow" 
> > = sign up sheets for examination what could be wrong with them, 
> > = ending up with concerns of using the same color (!) as "official" = IETF 
>= > meeting sign up sheets. Dismissive comments about even doing 
> > a = side-meeting, Not being allowed to use IETF tooling 
> > = like webex, jabber, wiki, etherpad, and so on. Because using 
> > = IETF tools would mean "endorsement of the activity" *sigh*. 
> = >  
> > = This is sad in general, but at a time when it is legally crucial 
> > to = make sure all communications is easily recognizeable as 
> > = public and published because of the US Govt. export regulations 
> > = (see EAR 734.7) it is outright dangerous to make it so difficult 
> > = for inofficial side-meetings to use or emulate the 
> > = public/published nature of official IETF meetings. 
> = >  
> > = > Also, note that there have been IAB programs like stackevo to 
> > = > deal with these questions. 
> > = Last RFC published in 2016. Concluded in 2019. 
> > = Followup to architecture-discuss according to closing mail. 
> = >  
> > = Cheers 
> > Toerless 
> > = > Melinda 
> > >  
> > = >  
> > = > --  
> > = > Melinda Shore 
> > > melinda.shore@nomountain.net 
> > = >  
> > = > Software longa, hardware brevis 
> > = >  
> = >  
> = >  
> = >  
> > = > _______________________________________________ 
> > = > Architecture-discuss mailing list 
> > = > Architecture-discuss@ietf.org 
> > = > https://www.ietf.org/mailman/listinfo/architecture-discuss<= span class=3D"Apple-converted-space"> 
> = >  
>  
> --  
> = ________________________________________________________________ 
> Bob = Briscoe  http://bobbriscoe.net/ 
>  
> = _______________________________________________ 
> = Architecture-discuss mailing list 
> Architecture-discuss@ietf.org 
> https://www.ietf.org/mailman/listinfo/architecture-discuss<= span class=3D"Apple-converted-space"> 

--  
--- 
tte@cs.fau.de 

_______________________________________________ 
Architecture-discuss mailing list 
Architecture-discuss@ietf.org 
https://www.ietf.org/mailman/listinfo/architecture-discuss<= span class=3D"Apple-converted-space"> 
_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discuss<= /div>

= --Apple-Mail=_F324AF93-D26A-43BE-AC16-67B9C4AC6556-- From nobody Thu Apr 9 13:44:43 2020 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 410533A0E69 for ; Thu, 9 Apr 2020 13:44:37 -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, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, PLING_QUERY=0.1, 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 a4lqW6vi0uvh for ; Thu, 9 Apr 2020 13:44:35 -0700 (PDT) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (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 7AA3F3A0E32 for ; Thu, 9 Apr 2020 13:44:35 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id z3so1752001pjr.4 for ; Thu, 09 Apr 2020 13:44:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=X9nuBlKWXWKbNCIsrZxcVyeJDDBquwBy76mB7sc9lFg=; b=SjAMsi6/7JCScfIcAXSV3MmiXHzrO3KPfjEYSN9ShW8/DQqcE6jANXeshekPPD68qv KkgcoZGE0TWTck644WWTfof3q8f+r52mPQn1IlpFgnPxvubhvC2XqL2R0BwjgEqM+DfU kku2BiGJvnDfu5mdN7EJ/tGjrZoL7mT6U8ViFbTHP5QGCJYGerqsE+V+PVEll5n/wLer AEyqUq326d6qTamPrf1k3R0+Z2+tDRh8hoSFAOx/O+TvQSh8twjtCPQ9MY/ij+ZPH/ui vWTPh38wL689S9DBMwp46ccyPsA1GU2UqVCx+G4v/5yCG1VdknUxr3O2ryHOH78KiPtQ 13oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=X9nuBlKWXWKbNCIsrZxcVyeJDDBquwBy76mB7sc9lFg=; b=fnmDQruUyjG4KuX6TXFsXOQ6STLwkZmLvfYKwx70vGrA5EGzA2YYdX+B8zDt9WDK5+ 9KQWsXiLeTRyjmVvIubVk5mzT/FIJ2lZDTFzSuywxfg68nHp/DTLsTIoR3Rx21G/NYNy Lj5wnVt4ELR7SYu7K+JNdZY1k9H6OUTOH8mYwNEeV3vJy9RaWq8AR8n28JmWcpom59kz +6c5VtkFrvqCc/XPzy2lLcQONW0DyBJul4f4xED91XbVpvG8T8oyXdPBWWV1NRITcfOe jM2eiGucQf/snchh9zwlsECNdIxlmU418JQj6F3cEEz2xT0yELkrEhGIHEG1G6L9kXfK wlVw== X-Gm-Message-State: AGi0PuaYtzhEmUV6EoHhbAj56fi4IfH12/tDYhh48CBRyo2ds0S5H7hk s9uvh5z8wXZDm04MCl7DOOUnjYA0 X-Google-Smtp-Source: APiQypIUcHHw19LXElsibNyag0uB6mkYMoJShWGX5g/rLjb42XkEVy4IzcvOXrTr/S6CcnEvo9ZlYw== X-Received: by 2002:a17:902:b593:: with SMTP id a19mr1439892pls.92.1586465074446; Thu, 09 Apr 2020 13:44:34 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id w15sm19989624pfj.28.2020.04.09.13.44.32 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2020 13:44:33 -0700 (PDT) To: Toerless Eckert , Henning Schulzrinne Cc: architecture-discuss@ietf.org References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409181428.GG28965@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: Date: Fri, 10 Apr 2020 08:44:30 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20200409181428.GG28965@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] Beyond Best Effort ?! Re: ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 20:44:42 -0000 On 10-Apr-20 06:14, Toerless Eckert wrote: ... > I for once think its not a good QoS architecture when > presidents have to call up NetFlix's CEO and ask him > to reduce his companies pressure on the networks, because > networks themselves can not distinguish this entertainment > traffic from more critical traffic. Do you think this > is the right QoS architecture for the Internet ? No, but I tend to blame the largely ignorant political polemics (one cannot say "debate") about a mythical beast called "network neutrality". This: https://tools.ietf.org/html/rfc3086 and this: https://doi.org/10.1109/JPROC.2002.802000 The fact is that there are fundamental mathematical limits on QoS in a network that is dominated by contention for switching resources and by queueing theory. You can only change that by getting rid of contention. Is there a plan? > Are > we going to have an IANA registries for the FAX numbers > of those CEO's ? ;-)) (yeah, sorry, couldn't resist). No, we have Google for that ;-) Brian From nobody Thu Apr 9 14:08:09 2020 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 077063A0E8F for ; Thu, 9 Apr 2020 14:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jQbbdmvfMZk for ; Thu, 9 Apr 2020 14:08:06 -0700 (PDT) Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [IPv6:2607:f8b0:4864:20::644]) (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 51F873A0E8E for ; Thu, 9 Apr 2020 14:08:06 -0700 (PDT) Received: by mail-pl1-x644.google.com with SMTP id x2so1668907plv.13 for ; Thu, 09 Apr 2020 14:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=KZj5dPAXltELF3w1Im5l/hYfqOwS8OWhN930/xudEsk=; b=oTVnM0w24I/lHsP8k8kQrj7a7kAPGsnoiqZHBDhdxFHR7GAc7ijAYPhmSXvMROUxMB XIamfOzhviXW/V6yTGjVnif5NGMm424c0oVAkMKNsuiBiHcm4dS0g4daEq2zbymxTWds 3JpwC2nK4WQxe5Tidjx++s1+FzzbxYchFIBCmii8pNYufWWAqKefQspKKDtJFd0B+ml0 RSX5Koc8+hMQzNKjaVev0RD18yyRCIJdi3DrMGnV3y8+urYDMnML7txHWMdDmJMY8VHS MqokqmhdZWChkbYGTUIQRbVPSHpXiMp2cZMpwVI/CVLtXfd787WhZd9jedSHbEgS+e52 6I1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KZj5dPAXltELF3w1Im5l/hYfqOwS8OWhN930/xudEsk=; b=AhXM4pxwIxzxRCw6gICWApYRrCZtMR03Kg2uvJXJ3B+DajNCeNUQ4dSuJHi8d6KEga EM+zFS2+KGu5reZrLB+xm8ctCuqttc2zx2ucPKjV+LpnRLyTihJOddql1sMYYMZIuKDp nXig08L1Ay1zPdP7XhpKmXVA7V5gLGrfJJPFqSwTsRFieM/hRoIQdN+ggY3hHyayofZw m35v8ZSP+c+LG96HoULMi7hErdp5yj8jhPmOOhkE28ZIQOyaLGxPhRUWI4dNUJm5eBGM Z6D03GVJvgh0gwxCEFBh9vM2aYO7sB4FZaDR/w9BbstdD9ozM56vZbeJS7/Q3uYftD7m hc/Q== X-Gm-Message-State: AGi0PuYJMzT9Qx0Rf7XFzG2X/ezbexTGcox7D23/LXqK5JTH6fsjAPFo OhRqlJ2fDfrEb/RKztgxSdj7rkDZ X-Google-Smtp-Source: APiQypJGHCRF9zOWJJ0K0uQUNOq2MPrMY8Fo8SfONg1F0srnHr3mSVdBqp3O2CKDKNwlWDZ/npU+fQ== X-Received: by 2002:a17:90a:2323:: with SMTP id f32mr1486424pje.139.1586466485300; Thu, 09 Apr 2020 14:08:05 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id n69sm90690pjc.8.2020.04.09.14.08.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2020 14:08:04 -0700 (PDT) To: Toerless Eckert , Lars Eggert Cc: architecture-discuss@ietf.org References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> Date: Fri, 10 Apr 2020 09:08:00 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 21:08:08 -0000 On 10-Apr-20 05:54, Toerless Eckert wrote: > Thanks for the discussion points, Lars, > inline. > > On Thu, Apr 09, 2020 at 04:51:16PM +0300, Lars Eggert wrote: >> Hi, >> >> On 2020-4-9, at 15:19, Toerless Eckert wrote: >>> On Thu, Apr 09, 2020 at 12:14:04PM +0300, Lars Eggert wrote: >>>> On 2020-4-8, at 22:41, Toerless Eckert wrote: >>>>> When technologies are young, you just let engineers >>>>> innovate and implement and when everything is done, you >>>>> can go and fight for it to get standardized. When an >>>>> industries becomes more mature and a lot more capital >>>>> investment heavy, you need to revert this and SDOs >>>>> need to play a lot more proactive role in defining >>>>> next-gen solutions. See 3GPP. IETF is not doing this >>>>> at the architecture scale. Only at small incremental >>>>> enhancements. >>>> >>>> if this is what you belief needs to happen, please do take this work to the ITU-T. >>> >>> Just making sure i understand your statement correctly: >>> >>> You only want for IAB and IETF to continue do only small >>> incremental enhancements ? >> >> You seem to think small, incremental enhancements are somehow > a bad thing. We're disagreeing on that. > > I am surprised to read that because that is not what i > wrote and not what i think. I fear that maybe other people > too are interpreting too much and wrong things into the > whole excurse with ITU-T. > > I said "only": > > Incremental improvements are are absolutely essential. > They are just not sufficient anymore IMHO for specific > topics. > >> We've managed to evolve the Internet and its architecture >> pretty well through a series of small, incremental >> enhancements at all layers. I don't see why continuing >> on this path is such a bad thing. > > Yes, and 30 years ago we made a mayor new step (IPNG -> IPv6) > and learned a lot through it. Actually, I disagree. IPv6 is a very conservative design that had exactly no effect on fundamentals. That was intentional. Remember TUBA (TCP and UDP over Bigger Addresses)? That's what we did, with the tiny detail of using homebrew IPv6 instead of ISO8473. What we learned is that even a minor step like bigger addresses is expensive *because of the even more tiny details* like the socket API, router CLI commands, and the address configuration mechanism. The major lower-layer atchitecture change in the last 30 years was completely unplanned: middleboxes. Brian > > After > 25 years of IPv6 we do not even seem to welcome a > broader discussion how well or how-not-well-enough that > step and its evolution since then has been. Or thinking > about the benefits that even thinking about another > IPNG step could have. Without saying that the result > couldn't even be just a set of incremental enhancements > (which mfor example could be expanding beyond RFC8200). > > Btw: stackevo does have a nice set of analysis of > subsets of what we learned. Alas, the whole problem > of evolving transport stack functions started with SPUD > was not really followed up on. > >> You seem to want to do some large-scale, >> monolithically-designed "v2" architecture thing. > > I never said this, and i don't want that. I am not > sure i would read from the ITU-T(TSAG) statements > a monolithical-designed v2, but i understand how > that claim was made. I already said that i and > my team where not involved in that but that our > undersstanding of problems is in our gap draft > and that we have not published specific architecture > propsals beyond what you can glean from that draft. > >> This is not what the IETF does. > > I am not even sure what a good definition of > monolythic architecture would be, but obviously one > doesn't want to throw out the baby with the bathwater, > and if we're talking about modularity, i think we > rather need more than less. Aka: reusing CBOR > as a common presentation layer like ancoding instead > of monolytic one-off TLV definitions, or equally > (my pet peeve) reused transport protocol components > (such as SPUD) instead of every protocol (like QUIC) > reinventing the whole wheel). Just examples. > >> Hence, my suggestion is you try and do the work in >> a forum that likes to work that way, and see if you >> manage to get anyone to deploy the outcome in the end. > > Oh, i did work in such a forum. Its called a big vendor > inventing new stuff, getting it deployed and then > going to the IETF and attempting to get it standardized. > > When today most routers are becoming white box vendors, > the opportunity to do innovation that way in that > space is just going to shift quite a bit. > >>> Btw: I do not need to take any work to ITU-T or 3GPP. >>> These SDOs will move forward with whatever they want to >>> do without consulting IETF. >> >> Great. I guess we can then stop this discussion on am IETF list. > > Well.. "this" thread was already "derailed" by Carsten > with an ITU-T mentioning, even though it says "ETSI". > (not a complaint...) > > I am indeed happy if we do not need to continue to > discuss ITU-T/TSAG statments, but as long as there is the > presumption that that ITU-T/TSAG statement is > about what i and my colleagues are talking about, > i am very happy that you give me the opportunity > to clear up that misperception and confusion in threads like this. > > Thanks again > Toerless > >> Lars > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > From nobody Thu Apr 9 14:19:11 2020 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 771B93A0ED9 for ; Thu, 9 Apr 2020 14:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 S8fdsziGqZDS for ; Thu, 9 Apr 2020 14:19:09 -0700 (PDT) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 5CF953A0ED7 for ; Thu, 9 Apr 2020 14:19:09 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id p8so68931pgi.5 for ; Thu, 09 Apr 2020 14:19:09 -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=oIun+7ejSlEjHfAZwFHorkeA8WfGS2qgYM1Hh1tWhzw=; b=lFynE9MfSa2S0hPA1RyAcCclrGrrShwFTyXRHCiw9MC19waQVis6gpKPohTBcOuyvP lE+5vOzm38HDeQXQF30n2AtrvuAdYut5fxaH8bMkRPV3eM7BHCWW93okMoz/vJDIpCq1 68EqudFoeMkrlUcqaoVxe3vHAgAYlP2d/zEVb+GXE8M1gVwTQQbXfDmjEnXtleMs81ys P4AHhZmav5seOQ4Pi4eMjOF7fSxtTnBehyoqW/E8uA8aa3LZyOFuuFsfmanSsMF72fDn 2mrBeBPMO6mNUplUTz4Y6Hu5xcAAG3gNdipedFAkIiHSxTS5+b2CewBqFIVDGutmz7xY DPIw== 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=oIun+7ejSlEjHfAZwFHorkeA8WfGS2qgYM1Hh1tWhzw=; b=jWaHbt2X6LnszDOuw5ViIXTMrnhga60iVvI4Pwg9+13LBkkR2wzsaXzmFhrMVUX98g woNLFWOI/P6/Q6beFZjyjry8V5hj5zZaQMTHAqzJ8K+l8TZsbgZKRqrFPvfCwChgVEbd vdDZM7VHyfnAQVR71ddoqHj2w7lxmcVkmHgMpDlBV9eUSNHOxQf5Bh4dE7iqFa4FCEGZ KV86l5hsjjQP2WjM57pV0Zyz59D9zpgqgYiot6Oj1VVjfo/rW+QGFg8FtMui5wkWE0Gr pqL+jUwwqB7lfb9k/7rwafW/VEKeIBtwJEGonx6EjIoO4agtmpRw/T3g+WPaCVf0JPN4 wYkQ== X-Gm-Message-State: AGi0PuYdoGIEhZ1NvlR3oe9vANzjAa+pTJNdoYa5UwPaZMXgDVkXPt2o LhlH3wmbIt6sQo7qJyW3umg= X-Google-Smtp-Source: APiQypIOXt8/j3c63Pz9APKgObmdggtaw9Vy5W+v/kEsxSyBbcfuLmPTnTGQJhzAgP/G+Efkz6/y8g== X-Received: by 2002:a62:5487:: with SMTP id i129mr1681155pfb.134.1586467147735; Thu, 09 Apr 2020 14:19:07 -0700 (PDT) Received: from ?IPv6:2601:646:9600:af10:a5e0:670f:28cf:e535? ([2601:646:9600:af10:a5e0:670f:28cf:e535]) by smtp.gmail.com with ESMTPSA id w16sm25898pfj.79.2020.04.09.14.19.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2020 14:19:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Dino Farinacci In-Reply-To: <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> Date: Thu, 9 Apr 2020 14:19:06 -0700 Cc: Toerless Eckert , Lars Eggert , architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <229AAF4A-C43F-46E9-97C6-99CC124E9B48@gmail.com> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 21:19:10 -0000 > Actually, I disagree. IPv6 is a very conservative design that had > exactly no effect on fundamentals. That was intentional. Remember > TUBA (TCP and UDP over Bigger Addresses)? That's what we did, > with the tiny detail of using homebrew IPv6 instead of ISO8473. > What we learned is that even a minor step like bigger addresses is > expensive *because of the even more tiny details* like the socket > API, router CLI commands, and the address configuration mechanism. I agree with you Brian. But remember NSAP addresses are variable length = so we could have addressed nodes out of different sized addresses.=20 The big question would TCAM and DRAM vendors have designed their chips = for the smaller case or the 20 byte case. For IPv6 they were required to = design for the 128-bit case. Also, back then, we would have thought crazy that software forwarders = would be so popular like they are today. Dino From nobody Thu Apr 9 14:21:22 2020 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 DF0613A0EDA for ; Thu, 9 Apr 2020 14:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_PASS=-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 9UXBxmX_gdyd for ; Thu, 9 Apr 2020 14:21:18 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01A9E3A0ED7 for ; Thu, 9 Apr 2020 14:21:17 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 97DE6548015; Thu, 9 Apr 2020 23:21:12 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 8F08E440040; Thu, 9 Apr 2020 23:21:12 +0200 (CEST) Date: Thu, 9 Apr 2020 23:21:12 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Lars Eggert , architecture-discuss@ietf.org Message-ID: <20200409212112.GJ28965@faui48f.informatik.uni-erlangen.de> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 21:21:20 -0000 Not sure what exactly you're disageeing with. "mayor" ? I guess everything is relative. Creating something not backward compatible counts as "mayor" to me, even if its just 96 more address bits. 21++ 32->128 bit migration mechanisms is IMHO a lot of good experience. All very painfull of course. stackevo summarized a bit of it, but don't think we've really tried to conclude on how to avoid / minimize these issues if we every would have a chance to redo. I guess most high level marketing always says variable length addresses for next-gen, but there is certainly a lot more architectural/mechanism to be worked out ... Cheers Toerless On Fri, Apr 10, 2020 at 09:08:00AM +1200, Brian E Carpenter wrote: > > Yes, and 30 years ago we made a mayor new step (IPNG -> IPv6) > > and learned a lot through it. > > Actually, I disagree. IPv6 is a very conservative design that had > exactly no effect on fundamentals. That was intentional. Remember > TUBA (TCP and UDP over Bigger Addresses)? That's what we did, > with the tiny detail of using homebrew IPv6 instead of ISO8473. > What we learned is that even a minor step like bigger addresses is > expensive *because of the even more tiny details* like the socket > API, router CLI commands, and the address configuration mechanism. > > The major lower-layer atchitecture change in the last 30 years > was completely unplanned: middleboxes. > > Brian From nobody Thu Apr 9 14:28:48 2020 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 67CE53A0EF3 for ; Thu, 9 Apr 2020 14:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 dHi4yjGR2MdV for ; Thu, 9 Apr 2020 14:28:46 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A5723A0EF1 for ; Thu, 9 Apr 2020 14:28:46 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 82D29548017; Thu, 9 Apr 2020 23:28:41 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 7A28C440040; Thu, 9 Apr 2020 23:28:41 +0200 (CEST) Date: Thu, 9 Apr 2020 23:28:41 +0200 From: Toerless Eckert To: Dino Farinacci Cc: Brian E Carpenter , Lars Eggert , architecture-discuss@ietf.org Message-ID: <20200409212841.GK28965@faui48f.informatik.uni-erlangen.de> References: <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <229AAF4A-C43F-46E9-97C6-99CC124E9B48@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <229AAF4A-C43F-46E9-97C6-99CC124E9B48@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 21:28:47 -0000 Anything variable length is still under i think a lot of contention in forwarding plane, even P4 if i remember correctly some discussions. Heck, i even had a lot of fight when we wanted to introduce variable length in control plane addressing a decade ago (FEC in mLDP ;-) I think this is one of those architectural topics where we need to push so that hardware inventors invest cycles to make variable length addresses more likely to become mainstream. There is quite a good amount of private networks, that have no interest to deal with 128 bit addresses and are happy with rfc1918 addresses for example. Most service provider cores run with 20 bit addresses, not even requiring aggregation. Others use non-aggregateable 48 Bit addresses. Or 64 bit addresses. Aka: IMHO the argument of variable length addresses is still quite an open issue.. On Thu, Apr 09, 2020 at 02:19:06PM -0700, Dino Farinacci wrote: > I agree with you Brian. But remember NSAP addresses are variable length so we could have addressed nodes out of different sized addresses. > > The big question would TCAM and DRAM vendors have designed their chips for the smaller case or the 20 byte case. For IPv6 they were required to design for the 128-bit case. > > Also, back then, we would have thought crazy that software forwarders would be so popular like they are today. > > Dino -- --- tte@cs.fau.de From nobody Thu Apr 9 14:35:28 2020 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 641403A0F66 for ; Thu, 9 Apr 2020 14:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 2f0MWVSRO_R5 for ; Thu, 9 Apr 2020 14:35:24 -0700 (PDT) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 5D8743A0F17 for ; Thu, 9 Apr 2020 14:35:24 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id c20so122881pfi.7 for ; Thu, 09 Apr 2020 14:35:24 -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=qKJo2BlfEPWZmkKTIO3n3LxBvCFdxpc5rzPXuoSpjyo=; b=pxqlFMO0V/ZFesDugdtNkxG0P5rXBLL/oikFsER8HFKuav/YlvKF4xDTv0YdSDRQM9 OGX2inOy/9yQiscJ9V8HXj0pMXuv/bJ3BSIDsNCvNUu8HkOCWpfFLBgLFoWUdbUbwls9 5Bwyoo1iO41Q/e4V97P0EwHtkbeEGzjajdThFdnXyQA20Qzydf6rsx9k28tJjOknGOBq XDZvNi5IhCmGmVG8Ncfq9hvNZCZb/ZR1+vNq/4v2vWeeLCc2i7GB9kcyX7w+FMIf0b5n NmRfVuCVuTw258Xde8mz3EfEVduralZQfyy0sEw0l/CvojrtxVhlB0wBDXLeX7wJUCrm iHBg== 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=qKJo2BlfEPWZmkKTIO3n3LxBvCFdxpc5rzPXuoSpjyo=; b=Q1uzR16kTKCpCzeW984lam4NHt47ozeLEQARZVLmPmxSrPbqt704n1XvZyEAGzLTKR VrwybY+9PgzelNNkGh6Sp+4gDsjQ+FzwA4x13L/usIhxeu/GWmaR6N4pCXedoBcgt7zj Pj8mfMWSvffNA3xQmCGq9mK93ldR52MGJKLNZa9Fcd6r1vxctzsoNqmivcwf3pFrzkLo LWoxRAiQUw4UHGbL94FgUW4gRkkdY6HgatmYfSwAsQOBLlso9y8oSsCy/x6u2SZQD9jG vws4XCsaNWNEeeHrPDYvB1JraZMdONVeIhGOV/DMfHXHaRaDpA5dsIFAYP7hFRU2mtTD ARQQ== X-Gm-Message-State: AGi0PubLLvSOd2mO8IrcRb5qDdrZL++g+Utue/yJAFd0yZg6oD/Xe9En qBpcVEgFyAwakWT3SR7oro89apsGkHM= X-Google-Smtp-Source: APiQypIz25TaDsicdZoazSzsF07JmX7ODOowNNWnF3XWVUbOIu9LinaZFbER6fe9fWiUjkR8/inTQQ== X-Received: by 2002:aa7:9f12:: with SMTP id g18mr1611298pfr.262.1586468123588; Thu, 09 Apr 2020 14:35:23 -0700 (PDT) Received: from [10.95.82.211] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id s12sm69177pgi.38.2020.04.09.14.35.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2020 14:35:22 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Tony Li In-Reply-To: <20200409212841.GK28965@faui48f.informatik.uni-erlangen.de> Date: Thu, 9 Apr 2020 14:35:21 -0700 Cc: Dino Farinacci , architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0A15B52E-2A67-4D6A-AACF-8A92FB67ADEC@gmail.com> References: <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <229AAF4A-C43F-46E9-97C6-99CC124E9B48@gmail.com> <20200409212841.GK28965@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 21:35:26 -0000 > Aka: IMHO the argument of variable length addresses is still=20 > quite an open issue.. It shouldn=E2=80=99t be. Today=E2=80=99s hardware is enormously capable = and continues to grow aggressively (thank you Gordon Moore). It would be backwards to let hardware limitations constrain the = architecture. Instead, the hardware will always grow to what is needed = by the architecture. That said, that=E2=80=99s no excuse to create enormously wasteful = architectures. Resources are not free. Waste not, want not. Tony From nobody Thu Apr 9 14:42:14 2020 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 30FC53A0F9A for ; Thu, 9 Apr 2020 14:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 AyHMlVbcQlu6 for ; Thu, 9 Apr 2020 14:42:11 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 394733A0F9C for ; Thu, 9 Apr 2020 14:42:11 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D5FD1548015; Thu, 9 Apr 2020 23:42:05 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id CD3E4440040; Thu, 9 Apr 2020 23:42:05 +0200 (CEST) Date: Thu, 9 Apr 2020 23:42:05 +0200 From: Toerless Eckert To: Tony Li Cc: Dino Farinacci , architecture-discuss@ietf.org Message-ID: <20200409214205.GL28965@faui48f.informatik.uni-erlangen.de> References: <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <229AAF4A-C43F-46E9-97C6-99CC124E9B48@gmail.com> <20200409212841.GK28965@faui48f.informatik.uni-erlangen.de> <0A15B52E-2A67-4D6A-AACF-8A92FB67ADEC@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0A15B52E-2A67-4D6A-AACF-8A92FB67ADEC@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 21:42:13 -0000 On Thu, Apr 09, 2020 at 02:35:21PM -0700, Tony Li wrote: > > Aka: IMHO the argument of variable length addresses is still > > quite an open issue.. > > > It shouldn???t be. Today???s hardware is enormously capable and continues to grow aggressively (thank you Gordon Moore). Nice to hear. I was thinking this for a long time for higher end platforms, but i am unsure about TCAM architectures with fixed upfront parsers. No ideas about the latest lower end, e.g.: enterprise level switches. P4 also seems to have overheads with variable length parsing (only hearsay, need more cycles to read into those levels of P4 details). > It would be backwards to let hardware limitations constrain the architecture. Instead, the hardware will always grow to what is needed by the architecture. Did you watch the forwarding plane reality talk we gave a few IETFs ago ? There was still a lot of concern about the right degree of flexibility to expect from one of the co-presenters slides. > That said, that???s no excuse to create enormously wasteful architectures. Resources are not free. Waste not, want not. Well... I had discussions with a bit Service Provider wondering about what they thought about the overhead of e.g.: 6x128bit SRv6 SIDs, and he was not concerned. One person of course, but i think we have to assume that there is a wide range of opinions about what would constitute "wasteful" on the wire. Variability in headers is a nice concept to make more use-cases happy IMHO, but when can we really expect it to be acceptable on any low-end switch (worst hardware). > > Tony -- --- tte@cs.fau.de From nobody Thu Apr 9 14:43:51 2020 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 C8B423A0FA2 for ; Thu, 9 Apr 2020 14:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 eefCEZrGm0EO for ; Thu, 9 Apr 2020 14:43:44 -0700 (PDT) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 681253A0FA1 for ; Thu, 9 Apr 2020 14:43:44 -0700 (PDT) Received: by mail-pj1-x102c.google.com with SMTP id cp9so1320683pjb.0 for ; Thu, 09 Apr 2020 14:43:44 -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=G7Ard4SDhhwXURmcBGf4bycsj+OzBNykAXshMmATNjk=; b=mHEAxWcMtlDmlrMgHSK6ogrzHe+rLD4A5aR5eUc2/9/UuA7ajZ4HigWWGBOvORP4KW CT3S7cPCZbeARXaHdIWB0dnDhRFkmcr2TXK925yuoLv7hTS1tnH99rYlI0kDcZozD3YE gjD6tI4TLFdp8C2R1BwyLDzRSPjd8pY+EbsKAHHZQ9G5rcGTf2VRJEOblG3gYLoWI14j Y0MrdnViatYjE8nxCtAyhKmqrNW+vccdS89Oj8SN6wHOPLT9ha1Dl2RUqVj6m1YZrmjo +z/6AB46apona9iZrXDyaNY29x7Grm+0VxnrIPTHhkmKYm94wA03cWbqwa1hIH3+HTYK 5leQ== 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=G7Ard4SDhhwXURmcBGf4bycsj+OzBNykAXshMmATNjk=; b=VbhwRDlZo08llFyNMWNnhszQuKFTnsfVhYPUyPU/0aURZ3BbVMuaJy+2JoN1kiUUMo 4nKOJQrwyiNoq5lCcclcGalX60M9paUKghePMaxtrf1aXINg8kf64A/mrQ0wMy/2EH6X 46i/kjg5pe7cX+N/jIe4l079ByjBcZKbG8b7DkKcYaP1AjGhTGwSvYmJ2uG49tD1wRLw OhTGZi4a/DhdfB73TpPvy12EPusTZDjI2k+bti8ef/kBYrlYvm235Gz3GpgnJsCziAyp kJCl/ni7x0HAbvNLzQy4f1eSQdCKFoGOsrI3m+at/ghtqsOMwT2vwq3HM2QKQpeglfCT eLPA== X-Gm-Message-State: AGi0PuZjv3mXEb9xR1DWBLNmjyodtYOMP8a22xXL6QCTNKdyb39ckzjg G1y+2afPAefuicuGV2bSfPA= X-Google-Smtp-Source: APiQypJsJuM6EbUWkbBtIKdttUI0KjP2k7pzoH4+631ZqUwzjmxF7irkcSoYlX9vB4L5hmErHsAzZg== X-Received: by 2002:a17:90b:3585:: with SMTP id mm5mr1710588pjb.168.1586468623913; Thu, 09 Apr 2020 14:43:43 -0700 (PDT) Received: from ?IPv6:2601:646:9600:af10:a5e0:670f:28cf:e535? ([2601:646:9600:af10:a5e0:670f:28cf:e535]) by smtp.gmail.com with ESMTPSA id j24sm122150pji.20.2020.04.09.14.43.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2020 14:43:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Dino Farinacci In-Reply-To: <0A15B52E-2A67-4D6A-AACF-8A92FB67ADEC@gmail.com> Date: Thu, 9 Apr 2020 14:43:41 -0700 Cc: Toerless Eckert , architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <53EFFD37-57EB-4288-AE19-2EB2DC3BDE39@gmail.com> References: <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <229AAF4A-C43F-46E9-97C6-99CC124E9B48@gmail.com> <20200409212841.GK28965@faui48f.informatik.uni-erlangen.de> <0A15B52E-2A67-4D6A-AACF-8A92FB67ADEC@gmail.com> To: Tony Li X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 21:43:50 -0000 And OSPF was too complicated for networks and IGRP will live on into = 2020. ;-) My point being Toerless, is that the variable length issue would now be = 2 decades behind us, very well understood and mainstream today. Dino > On Apr 9, 2020, at 2:35 PM, Tony Li wrote: >=20 >> Aka: IMHO the argument of variable length addresses is still=20 >> quite an open issue.. >=20 >=20 > It shouldn=E2=80=99t be. Today=E2=80=99s hardware is enormously = capable and continues to grow aggressively (thank you Gordon Moore). >=20 > It would be backwards to let hardware limitations constrain the = architecture. Instead, the hardware will always grow to what is needed = by the architecture. >=20 > That said, that=E2=80=99s no excuse to create enormously wasteful = architectures. Resources are not free. Waste not, want not. >=20 > Tony >=20 From nobody Thu Apr 9 14:59:35 2020 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 994CD3A0FF7 for ; Thu, 9 Apr 2020 14:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 AFzi5FgJlvWO for ; Thu, 9 Apr 2020 14:59:31 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 758CD3A0FF1 for ; Thu, 9 Apr 2020 14:59:31 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C8072548015; Thu, 9 Apr 2020 23:59:25 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id BF517440040; Thu, 9 Apr 2020 23:59:25 +0200 (CEST) Date: Thu, 9 Apr 2020 23:59:25 +0200 From: Toerless Eckert To: Dino Farinacci Cc: Tony Li , architecture-discuss@ietf.org Message-ID: <20200409215925.GA44502@faui48f.informatik.uni-erlangen.de> References: <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <229AAF4A-C43F-46E9-97C6-99CC124E9B48@gmail.com> <20200409212841.GK28965@faui48f.informatik.uni-erlangen.de> <0A15B52E-2A67-4D6A-AACF-8A92FB67ADEC@gmail.com> <53EFFD37-57EB-4288-AE19-2EB2DC3BDE39@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53EFFD37-57EB-4288-AE19-2EB2DC3BDE39@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 21:59:34 -0000 On Thu, Apr 09, 2020 at 02:43:41PM -0700, Dino Farinacci wrote: > And OSPF was too complicated for networks and IGRP will live on into 2020. ;-) > > My point being Toerless, is that the variable length issue would now be 2 decades behind us, very well understood and mainstream today. I got your point. But remember last years forwarding plane talk (i think you where there). Right now we only have the disucss whether somehing works in forwading plane individually in each protocol new field discuss, and that does not give us good coverage. It also raises the risk that someone who does not like a protocol uses the "not possible in forwarding plane" as a scapegoat not having to say no on a protocol due to otherreasons (company policies etc..). Cheers toerless > Dino > > > On Apr 9, 2020, at 2:35 PM, Tony Li wrote: > > > >> Aka: IMHO the argument of variable length addresses is still > >> quite an open issue.. > > > > > > It shouldn???t be. Today???s hardware is enormously capable and continues to grow aggressively (thank you Gordon Moore). > > > > It would be backwards to let hardware limitations constrain the architecture. Instead, the hardware will always grow to what is needed by the architecture. > > > > That said, that???s no excuse to create enormously wasteful architectures. Resources are not free. Waste not, want not. > > > > Tony > > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Thu Apr 9 15:01:07 2020 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 CFD983A0FFE for ; Thu, 9 Apr 2020 15:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.503 X-Spam-Level: X-Spam-Status: No, score=-1.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 65pHErYls3dy for ; Thu, 9 Apr 2020 15:00:48 -0700 (PDT) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 9FCA33A1001 for ; Thu, 9 Apr 2020 15:00:46 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id n10so167704pff.3 for ; Thu, 09 Apr 2020 15:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+hoIthE3Ayx/wCZRnqTBBk1e+ECN2915i1axDqXsS7g=; b=H3f/VD3doA4SqtF9sMEJv/3cc6si2XOd47e4QE+YxVbrm/8KVCEwInQKhs9lFnHWxz T0Y7PAN2Lmzx5M19MDu1JE1m1brIJU+PWtiTr7soVYgY+IDGOznLpE1arLhH2OhKD9Ap OgviSHzy9OLWCFbYil84sf9WBmtdSCHovk8WUvMO2KO8mpI1xhPfJcJxU8wPGxNAc5dW M8vDd/94A+WSt1KGIvpmWStCmDP96/P4bNSePy8EIx/RSVECP4m4N1e0J6LdSWWFBvLR jIDEr3bo0cGKiWLS4tM4qGgaN3VbqNZc4pqXeMZt0X2BGfeFXxpaT/ObDRWzxV+qkWg+ 4bIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=+hoIthE3Ayx/wCZRnqTBBk1e+ECN2915i1axDqXsS7g=; b=LoolKkzdY8Irh/7wW3fjT0pb59Q4+FgiPHSWsOKMfiHsEBKmNHgz+meg308X1lWCoN sPsIK7c6d+/XZnPgmEfiuX9qQLVtj2C22rPz+nP8VXmjmbT558qu1QjYErCKr4l/BceF Z0XvyYCrI4uI5wXoQEuLZtpoTDGsMlPjI+CZfpjkE/QKDFUEjvs3tmeO1vDtUaxDELAe VOD8chdbtuzMRdUkxjWMhB66e8U+a9HhlVFimzcU78Lu0MdN6fTtd3QiX3pAs+bri6ib bPJZTOGZBJEOwhP4Olc0anMoY8dNVM6KNNDVqVdO4e7c7oGtYqg+WR/QT7GCTO8TeSS+ pLkg== X-Gm-Message-State: AGi0PuZQByzOrfw5OPL0NGCAXyDCvmVXeGeHaLeoa1by/dbMW3VAnoFx AFuFP+x6Humd7fgceC+y/2E= X-Google-Smtp-Source: APiQypK6mX8ZgNwdj6Dc9TrZSrR6a4SpiAvTbb7ghy9sHVmTt/WA9OnOaHUak2RqVEwsZQAxI1S0gQ== X-Received: by 2002:a62:ed19:: with SMTP id u25mr1810103pfh.114.1586469645883; Thu, 09 Apr 2020 15:00:45 -0700 (PDT) Received: from [10.95.82.211] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id g9sm83271pgj.89.2020.04.09.15.00.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2020 15:00:44 -0700 (PDT) Sender: Tony Li Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: tony.li@tony.li In-Reply-To: <20200409214205.GL28965@faui48f.informatik.uni-erlangen.de> Date: Thu, 9 Apr 2020 15:00:40 -0700 Cc: Dino Farinacci , architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <229AAF4A-C43F-46E9-97C6-99CC124E9B48@gmail.com> <20200409212841.GK28965@faui48f.informatik.uni-erlangen.de> <0A15B52E-2A67-4D6A-AACF-8A92FB67ADEC@gmail.com> <20200409214205.GL28965@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 22:00:54 -0000 > Did you watch the forwarding plane reality talk we gave a few IETFs = ago ? I was the one who asked the embarassing question about SRv6. > Well... I had discussions with a bit Service Provider wondering about = what > they thought about the overhead of e.g.: 6x128bit SRv6 SIDs, and he > was not concerned. One person of course, but i think we have to assume > that there is a wide range of opinions about what would constitute > "wasteful" on the wire.=20 SPs are somewhat sheltered from hardware limitations. They simply ask = for scale numbers. I don=E2=80=99t think that the bandwidth implications of SRv6 are well = understood yet. IMHO, those are actually more of a concern. Tony From nobody Thu Apr 9 15:06:06 2020 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 7EF7D3A1015 for ; Thu, 9 Apr 2020 15:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 1K0_nwm83jro for ; Thu, 9 Apr 2020 15:06:02 -0700 (PDT) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 C7B5F3A1014 for ; Thu, 9 Apr 2020 15:06:02 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id t4so4328274plq.12 for ; Thu, 09 Apr 2020 15:06:02 -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=ejBgeVFkamp6isNi9ptm62gISIrPw/wgfQ97sl1+du8=; b=OrZVFFOksEK9KstMhcgmrFOogzJE/5dFvqLqmeW5mqClpr6ytTB59g0lmbA8wUFIJt lVWl9DWs4p/nZYi2RPgogKZY/PO92fJeEDMv1IlyMmHxT2zF2Bwlc6j8gcbJiJSQr+6r tNEgcTwmzFz4XQReZqhVwct3YDs4mRu6T7a9ql4KsuIehSLcrbq5XBAABQKaUMF12rVd 6sa943bjYFsvM68rqHPNz27cZEekmumtMWB2EcGQumKvNrGresAiiR5GTBipJ0AhGFOP 9+87Wywyoyv4oy2h10//WtkyzoYnZYSGpyzP16hR0OIg/jngLDLklNmUW/1bWtLBmrlD j8FQ== 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=ejBgeVFkamp6isNi9ptm62gISIrPw/wgfQ97sl1+du8=; b=r1kxeHPJt+QQ1hTTjhRCYqYVb82OFyzfMKdTQ3qgtNwy0Lya7krvk0jeKPQyL39xKQ ZDgYKMAbVKWb2qoRJ3pQ6d1LFolnbu71T7enOH8Qp/w/BN5BdkMMLbHRYWPYi/MvddDJ 6dqOQ1GMutL97GurYk7jj16g0pqh9vpHWEIQu5FuRXU0de8tjgSqVdoEkvGW54Gxpuay vqTfVPN4PvQAnNQLVuMrF/RCN3Kugx6PcbsJ6mreO2XgmvA3hKxXRYr3HEYxTN0NVe/C dqmGximA51BfRO+XtwsZjDDRX2ZHfHqI6odyT+znyI/qjL1aKBrZipHwnDHWE1o7HR+N xfig== X-Gm-Message-State: AGi0PuYkyOp5qChwSoAVOh18ZRvyFQN/LldN7zJ5ENNdNbgkzJ7UIDVS harBLE3GKS8EoC+yJ0+bkyg= X-Google-Smtp-Source: APiQypIpF0bampZP88n4bZkebNsHjUPEP06iquyONdyI4WdxeIRlqCWzvRxKHiltG+O1JbtNBW+9uQ== X-Received: by 2002:a17:902:8543:: with SMTP id d3mr1634413plo.314.1586469962104; Thu, 09 Apr 2020 15:06:02 -0700 (PDT) Received: from ?IPv6:2601:646:9600:af10:a5e0:670f:28cf:e535? ([2601:646:9600:af10:a5e0:670f:28cf:e535]) by smtp.gmail.com with ESMTPSA id b11sm84719pgj.92.2020.04.09.15.06.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2020 15:06:01 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Dino Farinacci In-Reply-To: <20200409215925.GA44502@faui48f.informatik.uni-erlangen.de> Date: Thu, 9 Apr 2020 15:06:00 -0700 Cc: Tony Li , architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4BB15D5F-735F-409D-B518-DD99A4428794@gmail.com> References: <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <229AAF4A-C43F-46E9-97C6-99CC124E9B48@gmail.com> <20200409212841.GK28965@faui48f.informatik.uni-erlangen.de> <0A15B52E-2A67-4D6A-AACF-8A92FB67ADEC@gmail.com> <53EFFD37-57EB-4288-AE19-2EB2DC3BDE39@gmail.com> <20200409215925.GA44502@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 22:06:05 -0000 > Right now we only have the disucss whether somehing works in forwading = plane > individually in each protocol new field discuss, and that does not = give us > good coverage. It also raises the risk that someone who does not like = a > protocol uses the "not possible in forwarding plane" as a scapegoat > not having to say no on a protocol due to otherreasons (company = policies etc..). Let me try to be specific on your point. I could be completely = misunderstand you. Here are some basic statements: (1) IP is a robust network layer that has proved to work for many = applications. (2) ICN/NDN is a new data-plane paradigm that is designed for = non-conversational flows. (3) It is not clear yet, if an ICN forwarding plane is faster than a IP = forwarding plane. And it may not matter. (4) ICN can do source authentication for each packet. That is a nice = feature at some cost. (5) IP cannot do packet source authentication. So you might follow to say that IP can=E2=80=99t do source = authenticaiton and therefore IP doesn=E2=80=99t have enough coverage for = new features. Is that what you are claiming? Dino From nobody Thu Apr 9 15:07:18 2020 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 1C6C63A1018 for ; Thu, 9 Apr 2020 15:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 eMITTM3KRGkB for ; Thu, 9 Apr 2020 15:07:16 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 0A85A3A1015 for ; Thu, 9 Apr 2020 15:07:16 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id c5so123278pgi.7 for ; Thu, 09 Apr 2020 15:07:15 -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=GcsjgvtN/0WO6AW46uDcWSmYZStVBlzSs3zZqJlC3to=; b=cZf7ldWIU5jssXlpci4u7QYu5IpWOAKaACk9b5cTvEt2B7/RCQvH8J0QQsRZxa9+Fv +ICnhwZGDCUt6AxPxoSNJkYSCnbRX973etjmh6R+y5LRshiizSp52dbkqlUfstgwLJDg iSJ1MIbUroOzluAH1IEcq/oIpn1kGiG/eNmp1kyadPqMCm8VMvLc/XKDQz+d003lxgRn HcFlRc/Z/3SdMDycFc6rybk2T3FOYfibgLjE1/VkpznXYB49sG+oC6jLJSqzY4vOhAv2 qTZ1ROXOlRfbVlvOQUIYkmpFBd/oPnzARknJBFLJXo0m33Pv2S5966tNDRGCDrM2rWSE 6z8A== 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=GcsjgvtN/0WO6AW46uDcWSmYZStVBlzSs3zZqJlC3to=; b=YB8VdLbzQ5jEh42/tBKWvljMX/tpyvzKXGAsjnygpswSPDrhOgi2ForKeBvTZdEkpF YHC+MYSqOfl5OVyk15EnUGQNwKzdk0A/wWMUW7/VBH3ER4E32YOR/iBpo/76HFbk0YUq a22Ka7KdPL5pdx5iIJd6MEuYmwvylkMBPdQkO89f0ox9UzwhGggLk+XibjKsrgMAI/Yg WLUh1kizeWvpoGfrWSjdMw0dDO8B44BbH1+855K/qt1iyazphspivko/FkSy2QSHH3gm wFzBpzLd1uFrPU70M6gGTfQLR4uoyOHjTc6CSVDCSiModHZAGDNrnUURaAVpg8T+w+Nb K/IA== X-Gm-Message-State: AGi0PuZWc6YeUxjG2AAoZkUFAnLeXFgsHR7KJ370/42hvhjGIUP62qS4 RlNJG5Y5jh4inoFKn4beoOjzuYuDUzo= X-Google-Smtp-Source: APiQypILvAQ8QaEkuEYFRAkppm9PBzWEf/cCfWp8LdgZbmci/UJE5uDeWfkFo2hZXrEs2kk/TpSShw== X-Received: by 2002:a62:8684:: with SMTP id x126mr1830092pfd.160.1586470035511; Thu, 09 Apr 2020 15:07:15 -0700 (PDT) Received: from ?IPv6:2601:646:9600:af10:85cd:cdcd:eb4e:cfd5? ([2601:646:9600:af10:85cd:cdcd:eb4e:cfd5]) by smtp.gmail.com with ESMTPSA id s24sm104086pgq.16.2020.04.09.15.07.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2020 15:07:15 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Dino Farinacci In-Reply-To: Date: Thu, 9 Apr 2020 15:07:14 -0700 Cc: Toerless Eckert , architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8D444744-A6C1-4313-982D-4C55F0F8A5AD@gmail.com> References: <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <229AAF4A-C43F-46E9-97C6-99CC124E9B48@gmail.com> <20200409212841.GK28965@faui48f.informatik.uni-erlangen.de> <0A15B52E-2A67-4D6A-AACF-8A92FB67ADEC@gmail.com> <20200409214205.GL28965@faui48f.informatik.uni-erlangen.de> To: Tony Li X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 22:07:17 -0000 > I was the one who asked the embarassing question about SRv6. And I was the won who said =E2=80=9Care we going to leave any data for = the user=E2=80=9D. Where I heard a loud Tony Li laugh from the audience. = ;-) Dino From nobody Thu Apr 9 15:08:02 2020 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 7A26D3A101A for ; Thu, 9 Apr 2020 15:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 MrIDpwCB4hSj for ; Thu, 9 Apr 2020 15:07:59 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E0C33A100D for ; Thu, 9 Apr 2020 15:07:53 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 48675548015; Fri, 10 Apr 2020 00:07:49 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 40629440040; Fri, 10 Apr 2020 00:07:49 +0200 (CEST) Date: Fri, 10 Apr 2020 00:07:49 +0200 From: Toerless Eckert To: tony.li@tony.li Cc: Dino Farinacci , architecture-discuss@ietf.org Message-ID: <20200409220749.GB44502@faui48f.informatik.uni-erlangen.de> References: <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <229AAF4A-C43F-46E9-97C6-99CC124E9B48@gmail.com> <20200409212841.GK28965@faui48f.informatik.uni-erlangen.de> <0A15B52E-2A67-4D6A-AACF-8A92FB67ADEC@gmail.com> <20200409214205.GL28965@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 22:08:01 -0000 On Thu, Apr 09, 2020 at 03:00:40PM -0700, tony.li@tony.li wrote: > SPs are somewhat sheltered from hardware limitations. They simply ask for scale numbers. > > I don???t think that the bandwidth implications of SRv6 are well understood yet. IMHO, those are actually more of a concern. Indeed. I remember some rude platform awakening in IP multicast when throughput was designed for video with > 1K avg packet size and the customers where finance market data with < 200 byte payload. Its really hard to predict if environmental telemetry in metropolitan networks will become an actual problem in this respect, but from what i understand, the amount of telemetry collected in DCs already is often surprisingly more traffic volume than one would guess. Toerless From nobody Thu Apr 9 15:23:50 2020 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 5DA943A108D for ; Thu, 9 Apr 2020 15:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 da3PRHQP68Kh for ; Thu, 9 Apr 2020 15:23:46 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0E4C3A108C for ; Thu, 9 Apr 2020 15:23:46 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 2DAA0548017; Fri, 10 Apr 2020 00:23:41 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 26BB4440040; Fri, 10 Apr 2020 00:23:41 +0200 (CEST) Date: Fri, 10 Apr 2020 00:23:41 +0200 From: Toerless Eckert To: Dino Farinacci Cc: Tony Li , architecture-discuss@ietf.org Message-ID: <20200409222341.GC44502@faui48f.informatik.uni-erlangen.de> References: <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <229AAF4A-C43F-46E9-97C6-99CC124E9B48@gmail.com> <20200409212841.GK28965@faui48f.informatik.uni-erlangen.de> <0A15B52E-2A67-4D6A-AACF-8A92FB67ADEC@gmail.com> <53EFFD37-57EB-4288-AE19-2EB2DC3BDE39@gmail.com> <20200409215925.GA44502@faui48f.informatik.uni-erlangen.de> <4BB15D5F-735F-409D-B518-DD99A4428794@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BB15D5F-735F-409D-B518-DD99A4428794@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 22:23:48 -0000 On Thu, Apr 09, 2020 at 03:06:00PM -0700, Dino Farinacci wrote: > > Right now we only have the disucss whether somehing works in forwading plane > > individually in each protocol new field discuss, and that does not give us > > good coverage. It also raises the risk that someone who does not like a > > protocol uses the "not possible in forwarding plane" as a scapegoat > > not having to say no on a protocol due to otherreasons (company policies etc..). > > Let me try to be specific on your point. I could be completely misunderstand you. Here are some basic statements: You make a lot of good observation to discuss below, but my comments where not meant to be specific to ICN. Think about something else, like BIER, or any other interesting new forwarding plane features. Think about a vendor who might have stood up and said "BIER is nogo as my HW does not do it", but suspicion could be that he just does not want to see devaluation of investment into existing multicast forwarding plane. If instead we had a broader agreed upon understanding of what forwarding plane functionality we could expect upfront, this could not happen. Think about defining some reference thats maybe P4++ (we know its too limited, we don't know what an acceptable ++ is). So you demonstrate that you can do your forwarding plane feature in P4++ and that should settle the "acceptable for forwarding plane in IETF" argument. Just as a very rough idea on potential goals for forwarding plane architecture. Cheers Toerless P.S.: If you want a discuss about ICN/NDN i am all game. Still trying to figure out its benefits over PGM with DLR (kidding). > (1) IP is a robust network layer that has proved to work for many applications. > (2) ICN/NDN is a new data-plane paradigm that is designed for non-conversational flows. > (3) It is not clear yet, if an ICN forwarding plane is faster than a IP forwarding plane. And it may not matter. > (4) ICN can do source authentication for each packet. That is a nice feature at some cost. > (5) IP cannot do packet source authentication. > > So you might follow to say that IP can???t do source authenticaiton and therefore IP doesn???t have enough coverage for new features. > > Is that what you are claiming? > > Dino -- --- tte@cs.fau.de From nobody Thu Apr 9 15:32:41 2020 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 8BBD53A10D7 for ; Thu, 9 Apr 2020 15:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKkEtFmHRm09 for ; Thu, 9 Apr 2020 15:32:38 -0700 (PDT) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 E8FFF3A10D6 for ; Thu, 9 Apr 2020 15:32:37 -0700 (PDT) Received: by mail-pj1-x102e.google.com with SMTP id np9so71565pjb.4 for ; Thu, 09 Apr 2020 15:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=pODM4Ga/OgA295RGEjVxW1q1y/995x8NA5PrilN1CLM=; b=LocApAZwvKtuucNcPyQB5X/0z8WVnF44XB1ctINa6J23aYKqAj8hj/gBHBExZgnwpC oNacRwJg4lVJWf+3hCqM/4vLxpPJbFFRLxHtDBKTD7c1ypwnzccpz6UcB/yBQ+2D/MMD wBaCqQWd+nKbMtCACNoVQjMILkxYNmPMLQoEg+hCqjFTCqt+D3lppBpPhvit58cr0HhA fpE63+AUkuQOMsJm5YpD5RwGY++0g12OCsKHePrKVaSt9/K1vxlx15d1XmsgzqEuyMmJ 1OpKAOa/VskgDO2Qu9NbLUJwmhby6noTH6uGv/iPcsK1zgUKeF4pCU8vic7q1MXT6ci/ P/EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pODM4Ga/OgA295RGEjVxW1q1y/995x8NA5PrilN1CLM=; b=LCzQiIrX8NrDMNneWNEkPxQ6sDP7pkHA/iw39FLUBO2meDAEbOA1BWVDrG0oEBCSDX 2BUxnNZ3CdEO8YdSz/RBPJ4IvpSN8FNUdAd/Qigft/Eh+XQkItdikcUYUI4kTNQx1mhb j5A8GorhY28jcqAwfoJy8bHpYat0yDoeEd/TKZ9mHgy4m4Iwa3FY9Es4R9tODGMWpyZ+ EEuSi3IKcZWUzyDbqHkwBs8lcdpfTIFUg2lD/uMw9M8vi9j0mXt10BjlzBO/xti8VjwQ Odmjp6l1EY//py59eW2Dq5ua6wvPES1UsUngEw2TPqwpAZ3rAmbN59OLgsuXX6J5Ll4O /b2g== X-Gm-Message-State: AGi0PuaR7pjehHcIacCES3x+VYXFnGSRZYlx1wpqeF+clgmbqFlrgKYH S7XxKjvEtdhqCyzq77sv6e1V9D/t X-Google-Smtp-Source: APiQypIUckrmz5QNsa+a/MDE2IsLYveo3Wy5t+wO0whf5NuNQ1QAvdvtjdJLkxUZL9TCLRrNs4ZOQQ== X-Received: by 2002:a17:90a:17a4:: with SMTP id q33mr1729513pja.175.1586471556885; Thu, 09 Apr 2020 15:32:36 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id t63sm115147pgc.85.2020.04.09.15.32.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2020 15:32:36 -0700 (PDT) To: Uma Chunduri Cc: architecture-discuss@ietf.org References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> From: Brian E Carpenter Message-ID: <4bbecb54-5d15-8d13-14c5-c58bd54ba009@gmail.com> Date: Fri, 10 Apr 2020 10:32:31 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [arch-d] our troubles [was: ETSI launches new group on Non-IP Networking addressing 5G new services] 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, 09 Apr 2020 22:32:40 -0000 I think Uma's question deserves some thought: On 09-Apr-20 14:10, Uma Chunduri wrote: > >=C2=A0 All our troubles will soon be over >=20 >=20 > While I don't know all their troubles by reading that announcement; wou= ld definitely=C2=A0love to hear what do you think our troubles are ...(if= any). * I know I've said it before, but I sum it up as "you can't beat queueing t= heory". I don't know how we are going to meet stringent real-time require= ments in a network architecture that fundamentally assumes contention and= queues (and has done since 1969). I don't how ETSI is going to do that e= ither. Brian >=20 > -- > Uma C.=C2=A0 >=20 > [*] Appreciate your=C2=A0 work and concur a lot on=C2=A0=C2=A0https://t= ools.ietf.org/html/draft-carpenter-limited-domains-13=C2=A0.=C2=A0 >=20 >=20 > =C2=A0On Tue, Apr 7, 2020 at 9:59 PM Brian E Carpenter > wrote: >=20 > All our troubles will soon be over, apparently: >=20 > https://www.etsi.org/newsroom/press-releases/1749-2020-04-etsi-laun= ches-new-group-on-non-ip-networking-addressing-5g-new-services >=20 > Stay well > =C2=A0 =C2=A0Brian Carpenter >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 From nobody Thu Apr 9 15:47:40 2020 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 51DCC3A1130 for ; Thu, 9 Apr 2020 15:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VO_boudWxRzl for ; Thu, 9 Apr 2020 15:47:37 -0700 (PDT) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 D8ACD3A112B for ; Thu, 9 Apr 2020 15:47:37 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id h11so31878plk.7 for ; Thu, 09 Apr 2020 15:47:37 -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=YxwV7ptF4GxTAbfNKrtwNImL3S6hT0DwSWKXI8HrlUI=; b=FN791oBAARAHT/wq3aU1oF339LQOr6RT1RAJHTVHAFmG6IAIbmszxSOSb+LlJr01fz 2PZ3BSA/qKQhNTFpfpM3ZsmoCiBIMPotuxx0A9B5pXWLUCXjAipvXvmAroPXWWZr2ZhG rtF77+hv8YgWS37z3rOdlPq0UkSJfQRdeegoTrjdwax6XCigjpqLgUp7ZDvg58oHziAp QPfeesGyZrD6c0F0i2E4obgtOLXo3xbjS8qK8GEeaETVtOA9qZqGGdZlV4xE/U/KaUpf yo+oSaWxylsiBP+VZcRRqfw5UUz9Kveq38RhwNkwuo0JRqpDoU2YNSn5a7Cp2TLWECIf XfUg== 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=YxwV7ptF4GxTAbfNKrtwNImL3S6hT0DwSWKXI8HrlUI=; b=JdlFv5W39iB7cBr3aaA+MG9QrHqkZDAnE1stBpBCqlQd0rp0q+phUtC2nLqqwOGe92 I+QAxKdQ7uI2Rw9rp0pl0OmoFESXG7NR79d7lB0Q5o36Ay3rayzSIUeOKOfiL9Y4jReQ PHxCchIJHmt8N4X5F1X6OgdOajS8mLF86OkiyhWeoh9QCtxLsnqgH0rRPOMWVtiYEAbv WdwVsbVgWkKgIkmEEeJGRuL0XxdKx1wp09RqBvRfmQ+41ptCiSTdBjYOCVBV3RUXxFvm xwKwvD2RJFbgtCWqT7QzYDapn2/jhnssE87Le8yA3zmki9jWiCGukXGFmj095Jb2NbEP OTDA== X-Gm-Message-State: AGi0PuYxy4aTH1nmA1O7Li+PWVJ1+QKyvQcT5nXfXpWPlfPCI7rKkXle y7+McSB8Z9Afu4h4jJwO1wc= X-Google-Smtp-Source: APiQypLc1qdO6fVxzs2TJmOwsioQDsEnZ1rLErGwTXQjvoOFb28hZoVjEH2bE40NzYKNIOIXadPUWw== X-Received: by 2002:a17:90a:aa0e:: with SMTP id k14mr1937419pjq.74.1586472457096; Thu, 09 Apr 2020 15:47:37 -0700 (PDT) Received: from ?IPv6:2601:646:9600:af10:a5e0:670f:28cf:e535? ([2601:646:9600:af10:a5e0:670f:28cf:e535]) by smtp.gmail.com with ESMTPSA id i34sm128482pgm.83.2020.04.09.15.47.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2020 15:47:36 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Dino Farinacci In-Reply-To: <20200409222341.GC44502@faui48f.informatik.uni-erlangen.de> Date: Thu, 9 Apr 2020 15:47:35 -0700 Cc: Tony Li , architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <952F886C-1B20-4E80-9948-D5D7EFF3BAA6@gmail.com> References: <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <229AAF4A-C43F-46E9-97C6-99CC124E9B48@gmail.com> <20200409212841.GK28965@faui48f.informatik.uni-erlangen.de> <0A15B52E-2A67-4D6A-AACF-8A92FB67ADEC@gmail.com> <53EFFD37-57EB-4288-AE19-2EB2DC3BDE39@gmail.com> <20200409215925.GA44502@faui48f.informatik.uni-erlangen.de> <4BB15D5F-735F-409D-B518-DD99A4428794@gmail.com> <20200409222341.GC44502@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 22:47:39 -0000 Right, so you want new forwarding features. But let=E2=80=99s pop up to = a higher level discussion. I think what is more important than = technology at a single layer is that you have to get it deployed with = useful features at other layers. A holistic approach. And if you want to = run it over the Internet, your new features may or will not work well. IPv6 shows up how a simple protocol takes a long time to get deployed. = And that the applications that run over IPv6 could also be run over = IPv4. I=E2=80=99d argue that when IPv6 was developed and if we created QUIC at = the same time, people would argue there are more useful features that = merit the change. IMO, I think its still not enough. Dino > On Apr 9, 2020, at 3:23 PM, Toerless Eckert wrote: >=20 > On Thu, Apr 09, 2020 at 03:06:00PM -0700, Dino Farinacci wrote: >>> Right now we only have the disucss whether somehing works in = forwading plane >>> individually in each protocol new field discuss, and that does not = give us >>> good coverage. It also raises the risk that someone who does not = like a >>> protocol uses the "not possible in forwarding plane" as a scapegoat >>> not having to say no on a protocol due to otherreasons (company = policies etc..). >>=20 >> Let me try to be specific on your point. I could be completely = misunderstand you. Here are some basic statements: >=20 > You make a lot of good observation to discuss below, but my comments > where not meant to be specific to ICN. Think about something > else, like BIER, or any other interesting new forwarding plane > features. Think about a vendor who might have stood up and=20 > said "BIER is nogo as my HW does not do it", but suspicion > could be that he just does not want to see devaluation of > investment into existing multicast forwarding plane. >=20 > If instead we had a broader agreed upon understanding of what > forwarding plane functionality we could expect upfront, this > could not happen. Think about defining some reference thats > maybe P4++ (we know its too limited, we don't know what an > acceptable ++ is). So you demonstrate that you can do your > forwarding plane feature in P4++ and that should settle the > "acceptable for forwarding plane in IETF" argument. >=20 > Just as a very rough idea on potential goals for forwarding > plane architecture. >=20 > Cheers > Toerless >=20 > P.S.: If you want a discuss about ICN/NDN i am all game. Still trying = to > figure out its benefits over PGM with DLR (kidding). >=20 >> (1) IP is a robust network layer that has proved to work for many = applications. >> (2) ICN/NDN is a new data-plane paradigm that is designed for = non-conversational flows. >> (3) It is not clear yet, if an ICN forwarding plane is faster than a = IP forwarding plane. And it may not matter. >> (4) ICN can do source authentication for each packet. That is a nice = feature at some cost. >> (5) IP cannot do packet source authentication. >>=20 >> So you might follow to say that IP can???t do source authenticaiton = and therefore IP doesn???t have enough coverage for new features. >>=20 >> Is that what you are claiming? >>=20 >> Dino >=20 > --=20 > --- > tte@cs.fau.de From nobody Thu Apr 9 16:26:22 2020 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 6E3DE3A1315 for ; Thu, 9 Apr 2020 16:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 5kpKjvgH6HU4 for ; Thu, 9 Apr 2020 16:26:18 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 403543A1313 for ; Thu, 9 Apr 2020 16:26:17 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 54D49548015; Fri, 10 Apr 2020 01:16:46 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4B92D440040; Fri, 10 Apr 2020 01:16:46 +0200 (CEST) Date: Fri, 10 Apr 2020 01:16:46 +0200 From: Toerless Eckert To: Dino Farinacci Cc: Tony Li , architecture-discuss@ietf.org Message-ID: <20200409231646.GF44502@faui48f.informatik.uni-erlangen.de> References: <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <229AAF4A-C43F-46E9-97C6-99CC124E9B48@gmail.com> <20200409212841.GK28965@faui48f.informatik.uni-erlangen.de> <0A15B52E-2A67-4D6A-AACF-8A92FB67ADEC@gmail.com> <53EFFD37-57EB-4288-AE19-2EB2DC3BDE39@gmail.com> <20200409215925.GA44502@faui48f.informatik.uni-erlangen.de> <4BB15D5F-735F-409D-B518-DD99A4428794@gmail.com> <20200409222341.GC44502@faui48f.informatik.uni-erlangen.de> <952F886C-1B20-4E80-9948-D5D7EFF3BAA6@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <952F886C-1B20-4E80-9948-D5D7EFF3BAA6@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 23:26:21 -0000 On Thu, Apr 09, 2020 at 03:47:35PM -0700, Dino Farinacci wrote: > Right, so you want new forwarding features. But let???s pop up to a higher level discussion. I think what is more important than technology at a single layer is that you have to get it deployed with useful features at other layers. Indeed. IMHO, having lived with classical vendor/operator driven network innovation for 3 decades, i think the best long-term evolution is if we had networks that would allow a limited number of hop-by-hop programmable virtual networks with something like P4++. Consider for the research community to have such a virtual self-programmed network would empower to experiment in a real network. Would make network infra behave like a DC. > A holistic approach. And if you want to run it over the Internet, your new features may or will not work well. I don't think i need to run a lot of new things end-to-end across the planet. I'd be happy if i can run it across a metro space to edge-DCs. at least for everything commercially relevant. global DC to DC traffic is typically across variety of priate networks anyhow. > IPv6 shows up how a simple protocol takes a long time to get deployed. And that the applications that run over IPv6 could also be run over IPv4. There is a lot more permissionless software upgrades these days than 20 years ago. I think we understand dependencies to enable faster innovation cycles. > I???d argue that when IPv6 was developed and if we created QUIC at the same time, people would argue there are more useful features that merit the change. IMO, I think its still not enough. Back when IPv6 was done nobody had calculated how many billions of dollars could be made if advertisements on web browsers are displayed a few RTTs earlier. But yes, agree. Cheers Toerless > Dino > > > On Apr 9, 2020, at 3:23 PM, Toerless Eckert wrote: > > > > On Thu, Apr 09, 2020 at 03:06:00PM -0700, Dino Farinacci wrote: > >>> Right now we only have the disucss whether somehing works in forwading plane > >>> individually in each protocol new field discuss, and that does not give us > >>> good coverage. It also raises the risk that someone who does not like a > >>> protocol uses the "not possible in forwarding plane" as a scapegoat > >>> not having to say no on a protocol due to otherreasons (company policies etc..). > >> > >> Let me try to be specific on your point. I could be completely misunderstand you. Here are some basic statements: > > > > You make a lot of good observation to discuss below, but my comments > > where not meant to be specific to ICN. Think about something > > else, like BIER, or any other interesting new forwarding plane > > features. Think about a vendor who might have stood up and > > said "BIER is nogo as my HW does not do it", but suspicion > > could be that he just does not want to see devaluation of > > investment into existing multicast forwarding plane. > > > > If instead we had a broader agreed upon understanding of what > > forwarding plane functionality we could expect upfront, this > > could not happen. Think about defining some reference thats > > maybe P4++ (we know its too limited, we don't know what an > > acceptable ++ is). So you demonstrate that you can do your > > forwarding plane feature in P4++ and that should settle the > > "acceptable for forwarding plane in IETF" argument. > > > > Just as a very rough idea on potential goals for forwarding > > plane architecture. > > > > Cheers > > Toerless > > > > P.S.: If you want a discuss about ICN/NDN i am all game. Still trying to > > figure out its benefits over PGM with DLR (kidding). > > > >> (1) IP is a robust network layer that has proved to work for many applications. > >> (2) ICN/NDN is a new data-plane paradigm that is designed for non-conversational flows. > >> (3) It is not clear yet, if an ICN forwarding plane is faster than a IP forwarding plane. And it may not matter. > >> (4) ICN can do source authentication for each packet. That is a nice feature at some cost. > >> (5) IP cannot do packet source authentication. > >> > >> So you might follow to say that IP can???t do source authenticaiton and therefore IP doesn???t have enough coverage for new features. > >> > >> Is that what you are claiming? > >> > >> Dino > > > > -- > > --- > > tte@cs.fau.de -- --- tte@cs.fau.de From nobody Thu Apr 9 16:27:14 2020 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 D983F3A1319 for ; Thu, 9 Apr 2020 16:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 WGuC7-yqc-B9 for ; Thu, 9 Apr 2020 16:27:11 -0700 (PDT) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 B46803A1315 for ; Thu, 9 Apr 2020 16:27:11 -0700 (PDT) Received: by mail-pj1-x1036.google.com with SMTP id q16so1372988pje.1 for ; Thu, 09 Apr 2020 16:27:11 -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=bW5B5ZjY3Sebxl286rrjJAAzxVMBCL34s/3fZTH4S0U=; b=Hqo2Qos06pQL/Cx0YS3uKqo4TYvgiaydyiQrCzkuWHGM63P6nxLjH37jBFvCS5W8AE R8Fc1gj1cw+t14un2yugSFMnfW+eWcbyH41bLdJr9P2vYyiDEmKOjn7ofBmuNPttP1i7 eymXIMoLAlXkzInVDweiBQssXdFBwpYG32/Yqxr7qqEg/PR3Il67c5Wskvgy1S3qvA4f t03YcFZnWoOs3cnJ3W8WMq/6Slky4UYLDz+AhJgQrd15CgVy4bpTySxAnqiwcRFro7ee +PvH6vn2NTHcp/rBcNYc7a73kvS4QCe+XoXkghMN9/Err3ZhsA2/glNpKX4Ry0qrzJSQ eewA== 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=bW5B5ZjY3Sebxl286rrjJAAzxVMBCL34s/3fZTH4S0U=; b=aAQv30O6KCr1MDBY0ax5vpKUEbYg5Rc6vyiit46yFX7KKyY32f3mfamAbgNe0Oycae eV3oFzR0oYpgtRJhciXM0Q1FpvCMBneY38iEy8n3VbSAflfqMv98Tx5k+bFUvEkBzU4f 005Co1wnjCpwIXjzxwhLYR0eLnUp4dEdLF4PK+z4GAgIDadRRhSZ5zteZgR8jvwzdIOe rw34pX/qDRtXg1v5y0kZvz+JLitq8rwP+epmtVZhOBSH9UZBdbguchX039UIdIUzmp/F 7Pi19Af2JTBi5xNjXSpJMb7+LgEXGXr0pXhgWzdNDKQybnGVbMLBXUNgfN5MmR1M0Y4l TFtw== X-Gm-Message-State: AGi0PuaZb2Pf3Gc/A5Py7PfAP+Ld1sVqGcuwroVFqLPXXaIsuJ1tQO2f rVZBvswycFf8CEj8mHbsdws= X-Google-Smtp-Source: APiQypJhsqXLHZzjAxQuwtF9NIve65PPu4Pk16+4oifPoO5Z0K2FBaoHUv/iBICPak8g7iV/1cjGJA== X-Received: by 2002:a17:90a:1946:: with SMTP id 6mr2204160pjh.42.1586474831140; Thu, 09 Apr 2020 16:27:11 -0700 (PDT) Received: from ?IPv6:2601:646:9600:af10:a5e0:670f:28cf:e535? ([2601:646:9600:af10:a5e0:670f:28cf:e535]) by smtp.gmail.com with ESMTPSA id d21sm187669pfo.49.2020.04.09.16.27.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2020 16:27:10 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Dino Farinacci In-Reply-To: <20200409231646.GF44502@faui48f.informatik.uni-erlangen.de> Date: Thu, 9 Apr 2020 16:27:09 -0700 Cc: Tony Li , architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1936E4A5-6E5A-41AA-BA7F-B9EBEEE170C7@gmail.com> References: <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <229AAF4A-C43F-46E9-97C6-99CC124E9B48@gmail.com> <20200409212841.GK28965@faui48f.informatik.uni-erlangen.de> <0A15B52E-2A67-4D6A-AACF-8A92FB67ADEC@gmail.com> <53EFFD37-57EB-4288-AE19-2EB2DC3BDE39@gmail.com> <20200409215925.GA44502@faui48f.informatik.uni-erlangen.de> <4BB15D5F-735F-409D-B518-DD99A4428794@gmail.com> <20200409222341.GC44502@faui48f.informatik.uni-erlangen.de> <952F886C-1B20-4E80-9948-D5D7EFF3BAA6@gmail.com> <20200409231646.GF44502@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 23:27:13 -0000 > I don't think i need to run a lot of new things end-to-end across > the planet. I'd be happy if i can run it across a metro space to > edge-DCs. at least for everything commercially relevant.=20 > global DC to DC traffic is typically across variety of priate > networks anyhow. Even if you had a completely new 4-hop network (non-IP) with multiple = paths, you could not guarantee zero packet loss. And what I understand = from the requirements, you can=E2=80=99t have delayed packets either. So = retransmission cannot be used as a tool. So the only option you have with a new protocol or with IP is to send = the same packet over diverse paths. The more diverse paths you have, the = greater probablity the packet will not be dropped. And for Brian=E2=80=99s= point, you have to measure queuing delay to you can pick 5 out of the = 10 diverse paths that meet your delay requirement. And the delay will = change so quickly, packet will already be launched into a congestive = path.=20 You can only do this with an overlay so the edge of the network can = select different paths by simply changing the destination address = (either with tunneling or translation). But its a hard problem that may = be unsolvable. You would have to set expectations very clearly what this = new architecture provides and how and when it fails. Having said that, you may as well build solutions that are IP based. You = don=E2=80=99t really need an IPvN. Dino From nobody Thu Apr 9 16:43:00 2020 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 E7A553A13EF for ; Thu, 9 Apr 2020 16:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 PBxGTPpm5rUi for ; Thu, 9 Apr 2020 16:42:56 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0E83A13EE for ; Thu, 9 Apr 2020 16:42:56 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id E0F8E548017; Fri, 10 Apr 2020 01:42:51 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id D800B440040; Fri, 10 Apr 2020 01:42:51 +0200 (CEST) Date: Fri, 10 Apr 2020 01:42:51 +0200 From: Toerless Eckert To: Dino Farinacci Cc: Tony Li , architecture-discuss@ietf.org Message-ID: <20200409234251.GG44502@faui48f.informatik.uni-erlangen.de> References: <229AAF4A-C43F-46E9-97C6-99CC124E9B48@gmail.com> <20200409212841.GK28965@faui48f.informatik.uni-erlangen.de> <0A15B52E-2A67-4D6A-AACF-8A92FB67ADEC@gmail.com> <53EFFD37-57EB-4288-AE19-2EB2DC3BDE39@gmail.com> <20200409215925.GA44502@faui48f.informatik.uni-erlangen.de> <4BB15D5F-735F-409D-B518-DD99A4428794@gmail.com> <20200409222341.GC44502@faui48f.informatik.uni-erlangen.de> <952F886C-1B20-4E80-9948-D5D7EFF3BAA6@gmail.com> <20200409231646.GF44502@faui48f.informatik.uni-erlangen.de> <1936E4A5-6E5A-41AA-BA7F-B9EBEEE170C7@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1936E4A5-6E5A-41AA-BA7F-B9EBEEE170C7@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 23:42:59 -0000 On Thu, Apr 09, 2020 at 04:27:09PM -0700, Dino Farinacci wrote: > > I don't think i need to run a lot of new things end-to-end across > > the planet. I'd be happy if i can run it across a metro space to > > edge-DCs. at least for everything commercially relevant. > > global DC to DC traffic is typically across variety of priate > > networks anyhow. > > Even if you had a completely new 4-hop network (non-IP) with multiple paths, you could not guarantee zero packet loss. And what I understand from the requirements, you can???t have delayed packets either. So retransmission cannot be used as a tool. Not sure how this relates to my paragraph above, but yes, solutions that offer higher resilience and lower packet loss at lowest latency are crucial for more critical services IMHO in the future. > > So the only option you have with a new protocol or with IP is to send the same packet over diverse paths. The more diverse paths you have, the greater probablity the packet will not be dropped. And for Brian???s point, you have to measure queuing delay to you can pick 5 out of the 10 diverse paths that meet your delay requirement. And the delay will change so quickly, packet will already be launched into a congestive path. I would alredy be happy if we had a better overall system standard to simply operationale path diversity. distributed MRT IGP extensions was the only thing i rememer we did, and while its cool, it doesn't offer lowest latency (shorted path length compared to centralized diverse path calculation). Hence also proposal from our side like PPR for easier forwarding plane agnostic path engineering. What you are talking about are cool ideas which have been had in more ad-hoc networks for a while now, but i wonder how well they would really improve resilience over the more traditional mechanisms (like simple N-path diversity). >From one of the older discuss i had, ROLL for example was not allowed way back to charter more forwarding plane centric functions (stick to routing), so ideas such as having those intelligent functions such that flexible forwarding planes like the following did not happen in IETF yet: "try to send packet to link i with up to j retransmissions, max total wait time k, afterwards try link l,..." Similarily of course extenible to replicate for reasons of resilience. > You can only do this with an overlay so the edge of the network can select different paths by simply changing the destination address (either with tunneling or translation). But its a hard problem that may be unsolvable. You would have to set expectations very clearly what this new architecture provides and how and when it fails. The simple n-path diverse pathset calculation is easy to use in any network, thats why its a good starting point the more dynamic mechanisms you mention are still good research topics IMHO. At least for quantitive evaluations. > Having said that, you may as well build solutions that are IP based. You don???t really need an IPvN. If RFC8200 wouldn't make extensions so convoluted and expensive for controlled networks, i think i could do everything needed for network layer as IPv6 extensions, except things where i really don't like the initial IPv6 header. For example integrating the best ideas of MPLS. And whenever i really do not want 2 * 128 bit addresses. Such as when we come up with better privacy models where the source address was waste of space. Cheers toerless > Dino -- --- tte@cs.fau.de From nobody Thu Apr 9 16:54:29 2020 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 DF43D3A149C for ; Thu, 9 Apr 2020 16:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 60SIvbAgR5Uc for ; Thu, 9 Apr 2020 16:54:26 -0700 (PDT) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 C7F5F3A149A for ; Thu, 9 Apr 2020 16:54:26 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id np9so144193pjb.4 for ; Thu, 09 Apr 2020 16:54:26 -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=wxP2797gz4GdKUbymrMzFV1kRyN6OQF1agZP4nAK5oo=; b=cJjLbwpvraaqLxLAa2zNwwhoMJpuMk6z3DfSjgOFKlwFHDssECiyG0Z85HdyhQyk1H 3GtQzEHiT7OL6NDh4YmggwQET+3FhRpDdGur6ZWmRIzWPFWEy/YPo0/fjQfxp8LxYe5L 5ibK1XajlhjGocoQM7R+fBqnZn8w97TL2w4jA+daxYEkGph2LgtqgwQsCKzBpou4kAH8 3x8bnWb0k0rSFRnjWJqNpMSr9OXn90lCtfQjWGclZrWAarR6El1zuv93rEE+phQB7J6b Adlg/pRoQg2ag7IsM775mGR7/FtGL/3yQ6GFr+XdCXzwajBj0tBBBs3Lcn3kLL3MQcjd qpuA== 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=wxP2797gz4GdKUbymrMzFV1kRyN6OQF1agZP4nAK5oo=; b=fXlyOgSrw5eeCpOx6phuFYzlZIfHFAZF8dIkL13HTTi4hGtRsFc1Bfzr+Y7ESw3bTT Q1QGkqSNF36Fepx/AXOJ4rzGnlCzenlaO4JLWROq+BgonUqTOcJf6FWjgQ8uQFQHziuV jBYjDPfNHquyCcbJDsTEXNcZyU4a/ycK5mYTYPrcRwg3Mql7iY/JRZLtmwRgBuD5pfn8 AwAtkUI+JqJBEVgvzFR5bVDQpoCH52oxMv4hEC7aI3Wd9ldIzLJsNAxSm7eDQ67R+L2f dAO6z2b1YfqbCiKwseRQjoW1F/De5TcpMPAn/rA9uBGrtRGQNCVxctNanI45nGXgBP5I DSFw== X-Gm-Message-State: AGi0Puaev/pjyKLu8OjFDsNgKjbDqzRS5AcUiZphgc4MkCdy4TLvxzOZ Rx7dqOWjLHKX0ikAQzj4rV4= X-Google-Smtp-Source: APiQypI2IQu/sIqVWir9kYIc0FD9ipYLvh83FSMofJ48/FlUSXOLkqUV4v+NOE4yMqo95MVFVb1MMA== X-Received: by 2002:a17:902:8f8b:: with SMTP id z11mr2146495plo.189.1586476466284; Thu, 09 Apr 2020 16:54:26 -0700 (PDT) Received: from ?IPv6:2601:646:9600:af10:a5e0:670f:28cf:e535? ([2601:646:9600:af10:a5e0:670f:28cf:e535]) by smtp.gmail.com with ESMTPSA id y9sm216811pfo.135.2020.04.09.16.54.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2020 16:54:25 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Dino Farinacci In-Reply-To: <20200409234251.GG44502@faui48f.informatik.uni-erlangen.de> Date: Thu, 9 Apr 2020 16:54:24 -0700 Cc: Tony Li , architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6D5C324F-9078-4DC5-8B5D-D0D95EB6D1C7@gmail.com> References: <229AAF4A-C43F-46E9-97C6-99CC124E9B48@gmail.com> <20200409212841.GK28965@faui48f.informatik.uni-erlangen.de> <0A15B52E-2A67-4D6A-AACF-8A92FB67ADEC@gmail.com> <53EFFD37-57EB-4288-AE19-2EB2DC3BDE39@gmail.com> <20200409215925.GA44502@faui48f.informatik.uni-erlangen.de> <4BB15D5F-735F-409D-B518-DD99A4428794@gmail.com> <20200409222341.GC44502@faui48f.informatik.uni-erlangen.de> <952F886C-1B20-4E80-9948-D5D7EFF3BAA6@gmail.com> <20200409231646.GF44502@faui48f.informatik.uni-erlangen.de> <1936E4A5-6E5A-41AA-BA7F-B9EBEEE170C7@gmail.com> <20200409234251.GG44502@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 23:54:28 -0000 > I would alredy be happy if we had a better overall system standard > to simply operationale path diversity. distributed MRT IGP > extensions was the only thing i rememer we did, and while > its cool, it doesn't offer lowest latency (shorted path > length compared to centralized diverse path calculation). > Hence also proposal from our side like PPR for easier > forwarding plane agnostic path engineering. Then why don=E2=80=99t you write a solutions draft that says =E2=80=9Cuse = X, Y, and Z protocols that allows near-zero packet loss and probablisic = delays=E2=80=9D. >> You can only do this with an overlay so the edge of the network can = select different paths by simply changing the destination address = (either with tunneling or translation). But its a hard problem that may = be unsolvable. You would have to set expectations very clearly what this = new architecture provides and how and when it fails. >=20 > The simple n-path diverse pathset calculation is easy to > use in any network, thats why its a good starting point > the more dynamic mechanisms you mention are still good > research topics IMHO. At least for quantitive evaluations. That=E2=80=99s right. So write a draft that starts out using IP. It will = go a long way and you can test it sooner. ;-) Dino From nobody Thu Apr 9 16:59:44 2020 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 1E7B53A1500 for ; Thu, 9 Apr 2020 16:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.872 X-Spam-Level: X-Spam-Status: No, score=-0.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] 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 nK-NIEmzTZ2f for ; Thu, 9 Apr 2020 16:59:41 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86D9A3A1504 for ; Thu, 9 Apr 2020 16:59:41 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 0E246548017; Fri, 10 Apr 2020 01:59:36 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 05418440040; Fri, 10 Apr 2020 01:59:36 +0200 (CEST) Date: Fri, 10 Apr 2020 01:59:35 +0200 From: Toerless Eckert To: Dino Farinacci Cc: Tony Li , architecture-discuss@ietf.org Message-ID: <20200409235935.GH44502@faui48f.informatik.uni-erlangen.de> References: <0A15B52E-2A67-4D6A-AACF-8A92FB67ADEC@gmail.com> <53EFFD37-57EB-4288-AE19-2EB2DC3BDE39@gmail.com> <20200409215925.GA44502@faui48f.informatik.uni-erlangen.de> <4BB15D5F-735F-409D-B518-DD99A4428794@gmail.com> <20200409222341.GC44502@faui48f.informatik.uni-erlangen.de> <952F886C-1B20-4E80-9948-D5D7EFF3BAA6@gmail.com> <20200409231646.GF44502@faui48f.informatik.uni-erlangen.de> <1936E4A5-6E5A-41AA-BA7F-B9EBEEE170C7@gmail.com> <20200409234251.GG44502@faui48f.informatik.uni-erlangen.de> <6D5C324F-9078-4DC5-8B5D-D0D95EB6D1C7@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6D5C324F-9078-4DC5-8B5D-D0D95EB6D1C7@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 09 Apr 2020 23:59:43 -0000 On Thu, Apr 09, 2020 at 04:54:24PM -0700, Dino Farinacci wrote: > > I would alredy be happy if we had a better overall system standard > > to simply operationale path diversity. distributed MRT IGP > > extensions was the only thing i rememer we did, and while > > its cool, it doesn't offer lowest latency (shorted path > > length compared to centralized diverse path calculation). > > Hence also proposal from our side like PPR for easier > > forwarding plane agnostic path engineering. > > Then why don???t you write a solutions draft that says ???use X, Y, and Z protocols that allows near-zero packet loss and probablisic delays???. There is always more drafts one could write than time. We presented PPR drafts as a generic concept, its benefits and maybe even specific details for disjoint paths is still one some Todo list. > > The simple n-path diverse pathset calculation is easy to > > use in any network, thats why its a good starting point > > the more dynamic mechanisms you mention are still good > > research topics IMHO. At least for quantitive evaluations. > > That???s right. So write a draft that starts out using IP. It will go a long way and you can test it sooner. ;-) I am not even sure that something that improves IPv4 value equal to IPv6 would be welcome by part of the community ;-) But i think there are a lot more pieces to the puzzle than path diversity, and those othre pieces would require additional header info, and thats where we run into 8200 and other issues. Cheers Toerless From nobody Thu Apr 9 17:09:48 2020 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 ADB0D3A15A5 for ; Thu, 9 Apr 2020 17:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.872 X-Spam-Level: X-Spam-Status: No, score=-0.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] 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 iluIf0h5mDqc for ; Thu, 9 Apr 2020 17:09:42 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF4643A15A3 for ; Thu, 9 Apr 2020 17:09:41 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 699A6548015; Fri, 10 Apr 2020 02:09:37 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5DC2A440040; Fri, 10 Apr 2020 02:09:37 +0200 (CEST) Date: Fri, 10 Apr 2020 02:09:37 +0200 From: Toerless Eckert To: Dino Farinacci Cc: Tony Li , architecture-discuss@ietf.org Message-ID: <20200410000937.GJ44502@faui48f.informatik.uni-erlangen.de> References: <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <229AAF4A-C43F-46E9-97C6-99CC124E9B48@gmail.com> <20200409212841.GK28965@faui48f.informatik.uni-erlangen.de> <0A15B52E-2A67-4D6A-AACF-8A92FB67ADEC@gmail.com> <20200409214205.GL28965@faui48f.informatik.uni-erlangen.de> <8D444744-A6C1-4313-982D-4C55F0F8A5AD@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8D444744-A6C1-4313-982D-4C55F0F8A5AD@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 10 Apr 2020 00:09:47 -0000 On Thu, Apr 09, 2020 at 03:07:14PM -0700, Dino Farinacci wrote: > > I was the one who asked the embarassing question about SRv6. > > And I was the won who said ???are we going to leave any data for the user???. Where I heard a loud Tony Li laugh from the audience. ;-) Btw. There are interesting hybrid optical/electrical research network architectures, where optical packets arriving are passed through an optical delay loop and the packet header spoofed into the electrical side to make packet processing decisions, which can then happen when the packet header starts to appear at the end of the optical delay loop. Given how these optical networks will be many orders of magnitudes faster than the electrical processing capability, we may end up with networks that just scream to get larger packets to max out performance. 100 Kb minimum. And then we can waste all the header space we ever wanted. SIDs in URL encoding, x86 BIER replication function !!!! Cheers Toerless From nobody Thu Apr 9 17:11:11 2020 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 AFEAA3A15BB for ; Thu, 9 Apr 2020 17:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8fESTUXlfK7 for ; Thu, 9 Apr 2020 17:11:08 -0700 (PDT) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 6F0FA3A15BA for ; Thu, 9 Apr 2020 17:11:08 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id a13so323910pfa.2 for ; Thu, 09 Apr 2020 17:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=XLC6fmtj3h3DMgFs41tvEof0jLeoV1vHCUXDsIHa9fg=; b=r3rrsFA9Rs9odO5oFLW5gVuXu/+NAdPxUfkY9pARFX4H7N+Ou8kuzby4HzX7syB4aV u/a5jwOhNy6J53dLZiJsQfzVE27oMgaaqADzpDiALL1mENH6LTsfVnhhuZBTs2P1RJal OPlDME5fj254qxVF0C2ZjAfQjXhkg1tUudFwA+IEf5voAoNJ/4Fm2KksjSwLirkaNYA4 iVHu3KKNtYzqBrc+7Tk5ikzyLyF8daqfHs5XFS8luajbBtvenAEfadtQKovc1yVIsqt3 aViMxrpCfJzXID8C+fgGe7CQ+IUGcClJqI49b/1t3EnrbaDBkWJKXhl5MnyPAjZtTpfL fuLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=XLC6fmtj3h3DMgFs41tvEof0jLeoV1vHCUXDsIHa9fg=; b=V1af1KSfJ+pBpQ0plKZx574M7/KyU4Cfjqi97tONiMZOs8AzBMEBLoRVuUrfHFtK3H +pEBSwpwSeeuCq7uw5G6LjuDXdCLvugPOUqpxuM9o6Xjw+QBSL5ci9Onob2qRXIo325R 0H4VnupkCw6rjM6Ets7cyZ5aOvtR35yg6VaLymYZ7l1XMylGGGXKSxTQqs0ByGIVtXS9 y24XNykGuXeI6p2nIhis2ui3F/wKboIHH6mRugiXDgTDYBJ16J3eoHSMyAPngOpwNKVZ K5e/tYMolcIU4NC8f7KbjRkB+lNDO0DKRJ6uegLnexA1B0P5pbYbuhS/UIMRqfNU5emt S3Wg== X-Gm-Message-State: AGi0PuZqXFc+Kv4VFdyFWs2afQ+4dDHFh9vnYsTZIYX6jUzMepNQ6JSB TD0SoV+59HKlocN91/fnNv8= X-Google-Smtp-Source: APiQypKUVjlcc614kzAiz2Yvn6W4FjWpJcfk2CxmSBn0xWn5t1NG6DD/z11c03yDDX/xU2qB1jgBiA== X-Received: by 2002:a62:164a:: with SMTP id 71mr2136416pfw.273.1586477467887; Thu, 09 Apr 2020 17:11:07 -0700 (PDT) Received: from ?IPv6:2600:380:442d:dd38:9809:8320:97e5:e834? ([2600:380:442d:dd38:9809:8320:97e5:e834]) by smtp.gmail.com with ESMTPSA id x186sm228719pfb.151.2020.04.09.17.11.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Apr 2020 17:11:07 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Dino Farinacci Mime-Version: 1.0 (1.0) Date: Thu, 9 Apr 2020 17:11:06 -0700 Message-Id: References: <20200409235935.GH44502@faui48f.informatik.uni-erlangen.de> Cc: Tony Li , architecture-discuss@ietf.org In-Reply-To: <20200409235935.GH44502@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: iPhone Mail (17E255) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 10 Apr 2020 00:11:10 -0000 Toerless, you (we) have to present a design. You gotta write it down in some= form. How else do you get peer review? Dino > On Apr 9, 2020, at 4:59 PM, Toerless Eckert wrote: >=20 > =EF=BB=BFOn Thu, Apr 09, 2020 at 04:54:24PM -0700, Dino Farinacci wrote: >>> I would alredy be happy if we had a better overall system standard >>> to simply operationale path diversity. distributed MRT IGP >>> extensions was the only thing i rememer we did, and while >>> its cool, it doesn't offer lowest latency (shorted path >>> length compared to centralized diverse path calculation). >>> Hence also proposal from our side like PPR for easier >>> forwarding plane agnostic path engineering. >>=20 >> Then why don???t you write a solutions draft that says ???use X, Y, and Z= protocols that allows near-zero packet loss and probablisic delays???. >=20 > There is always more drafts one could write than time. We > presented PPR drafts as a generic concept, its benefits and > maybe even specific details for disjoint paths is still > one some Todo list. >=20 >>> The simple n-path diverse pathset calculation is easy to >>> use in any network, thats why its a good starting point >>> the more dynamic mechanisms you mention are still good >>> research topics IMHO. At least for quantitive evaluations. >>=20 >> That???s right. So write a draft that starts out using IP. It will go a l= ong way and you can test it sooner. ;-) >=20 > I am not even sure that something that improves IPv4 value > equal to IPv6 would be welcome by part of the community ;-) >=20 > But i think there are a lot more pieces to the puzzle > than path diversity, and those othre pieces would > require additional header info, and thats where we > run into 8200 and other issues. >=20 > Cheers > Toerless >=20 From nobody Thu Apr 9 17:16:40 2020 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 3FBD33A1629 for ; Thu, 9 Apr 2020 17:16: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, 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 AELCU5xJp4f8 for ; Thu, 9 Apr 2020 17:16:37 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 AD1CE3A1627 for ; Thu, 9 Apr 2020 17:16:37 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jMhLY-0006GQ-3L; Fri, 10 Apr 2020 00:16:36 +0000 Date: Thu, 09 Apr 2020 17:16:34 -0700 Message-ID: From: Randy Bush To: Dino Farinacci Cc: architecture-discuss@ietf.org In-Reply-To: <6D5C324F-9078-4DC5-8B5D-D0D95EB6D1C7@gmail.com> References: <229AAF4A-C43F-46E9-97C6-99CC124E9B48@gmail.com> <20200409212841.GK28965@faui48f.informatik.uni-erlangen.de> <0A15B52E-2A67-4D6A-AACF-8A92FB67ADEC@gmail.com> <53EFFD37-57EB-4288-AE19-2EB2DC3BDE39@gmail.com> <20200409215925.GA44502@faui48f.informatik.uni-erlangen.de> <4BB15D5F-735F-409D-B518-DD99A4428794@gmail.com> <20200409222341.GC44502@faui48f.informatik.uni-erlangen.de> <952F886C-1B20-4E80-9948-D5D7EFF3BAA6@gmail.com> <20200409231646.GF44502@faui48f.informatik.uni-erlangen.de> <1936E4A5-6E5A-41AA-BA7F-B9EBEEE170C7@gmail.com> <20200409234251.GG44502@faui48f.informatik.uni-erlangen.de> <6D5C324F-9078-4DC5-8B5D-D0D95EB6D1C7@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) 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] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 10 Apr 2020 00:16:39 -0000 some times people do what we thought could not be done. it might be cool if this was one. given the mess we're in and will be for the years to come, i say best wishes. as i said to spencer the other day with my limited time and resources, i focus on doing the best work i can, and let others do as they choose. i am not holden caufield and do not have time, energy, or talent to play him on the net. these will be hard times. randy From nobody Thu Apr 9 17:21:41 2020 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 2F9623A169A for ; Thu, 9 Apr 2020 17:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Q1aoB_Aa6rU for ; Thu, 9 Apr 2020 17:21:37 -0700 (PDT) Received: from mail-pl1-x641.google.com (mail-pl1-x641.google.com [IPv6:2607:f8b0:4864:20::641]) (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 D7C433A169E for ; Thu, 9 Apr 2020 17:21:37 -0700 (PDT) Received: by mail-pl1-x641.google.com with SMTP id w3so116562plz.5 for ; Thu, 09 Apr 2020 17:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=XgFTNOOPu3M+bfHrygd3TTRDbpY3O7XP7v6yFBcTbTM=; b=BHkZA06+T3AGF6VKgyDBO6EICQp+YHy8rSxTcsGYqKuqlbOJxET/ONcGpW5es87GHO mwqOpJ81fUd2KAiC6JeOxFl+S6gPbmthqqDxcR6iVYPmAlFMVBL8DSJvPzQKf8RtCyKC 1iL5k0mkkAzk9eEt8DJPd89gmcQt0A2+VQyWg2aiQWlAG4gns5KFpjVfZeuhPc+x/Lrh mgGYU2TYn1CG71h/m20WJtaE05nyaZzHl4tsDsSlpKPpB4EGVYKFHBq89OOLYwzL0hD1 QUUrenwXpl9MtAGagccY/DAz+BFtwMP70ZmSGyVvfuTxRuJ9BJVidQWVZ2D/6TruI+oj /OWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=XgFTNOOPu3M+bfHrygd3TTRDbpY3O7XP7v6yFBcTbTM=; b=n2TgMCO0ygnka4uBGDE4SHcS8uPmwBqRaCOzAvE05m2m9PcSwIb3bqyhzSzckpt2fn 24alEBFsZKEVOxv5A/KEviP2i4JLmtBnaAUE1No/hOEL84lql3jrAZivdi0kb8D0bnNW JvV2pH92Vtjt2R+wiRJGpvhFwJJX7sHJl7P7IXk5sv7cQtItbDEkHnJvbCyKRbR/jZdi UMUc3DAf3Itf4fHiBXdV3M3UC6RZewtgBlw4bIqalJ6u2Cgo14h96yMpr6aQDTeCMb+H FT8aiH5iNpC/i7YR/LUisYMA/p1P42BvY1ek8G62f0UhuJfxslyUSD4QfGyetoAokj+Z QYXQ== X-Gm-Message-State: AGi0PuZUnbMq54LSe3/+mylv7T8SiI7yXBDyiTyAxT99TrO/OrbhCsQ7 7W9Uy/GOzEzJHBK5afs45Wg= X-Google-Smtp-Source: APiQypL/w6AaA5ofDFbFgV3EkG9REUqZ+c2uedDQMVi0Dm1ohCL88CpJkhUfrCZ0Gb8kcXzJN5+e1w== X-Received: by 2002:a17:902:7288:: with SMTP id d8mr2116926pll.52.1586478097209; Thu, 09 Apr 2020 17:21:37 -0700 (PDT) Received: from [192.168.1.2] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id 6sm251890pfx.69.2020.04.09.17.21.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2020 17:21:36 -0700 (PDT) Date: Thu, 9 Apr 2020 17:21:29 -0700 From: Jeff Tantsura To: Dino Farinacci , Toerless Eckert Cc: Tony Li , architecture-discuss@ietf.org Message-ID: In-Reply-To: <20200409235935.GH44502@faui48f.informatik.uni-erlangen.de> References: <0A15B52E-2A67-4D6A-AACF-8A92FB67ADEC@gmail.com> <53EFFD37-57EB-4288-AE19-2EB2DC3BDE39@gmail.com> <20200409215925.GA44502@faui48f.informatik.uni-erlangen.de> <4BB15D5F-735F-409D-B518-DD99A4428794@gmail.com> <20200409222341.GC44502@faui48f.informatik.uni-erlangen.de> <952F886C-1B20-4E80-9948-D5D7EFF3BAA6@gmail.com> <20200409231646.GF44502@faui48f.informatik.uni-erlangen.de> <1936E4A5-6E5A-41AA-BA7F-B9EBEEE170C7@gmail.com> <20200409234251.GG44502@faui48f.informatik.uni-erlangen.de> <6D5C324F-9078-4DC5-8B5D-D0D95EB6D1C7@gmail.com> <20200409235935.GH44502@faui48f.informatik.uni-erlangen.de> X-Readdle-Message-ID: f1ba0f10-5571-410c-8475-ed59ae05b5dc@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5e8fbc0f_68573db1_16f" Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 10 Apr 2020 00:21:40 -0000 --5e8fbc0f_68573db1_16f Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Toerless, You have been mentioning P4 in almost every email. P4 (and similar) is an abstraction on top of forwarding plane, if anythin= g - it doesn=E2=80=99t enhance one. The problem with such layers in an he= terogeneous environment - almost always they end up being lowest common d= enominator, or variability inevitably kills them (O=46 ;-)) At scale - In the chain NB(programmable logic you interact with)->magic(t= ranslation from high level to 0..1)->SB - SB(silicon) is fixed, magic is = limited by amount of permutations, eventually NB that is exposed to you h= ave to limit amount and variability of features to support more than 1 ta= rget. So if I end up with: convoluted management plane (I have to program my fo= rwarding plane directly, 1:1 relationship) =C2=A0a handicapped feature se= t across different HW and at the end can't do anything else at line rate = =C2=A0besides moving IP packets from A to B=E2=80=A6 I=E2=80=99d stick to= BGP ;-) Cheers, Jeff On Apr 9, 2020, 4:59 PM -0700, Toerless Eckert , wrote: > On Thu, Apr 09, 2020 at 04:54:24PM -0700, Dino =46arinacci wrote: > > > I would alredy be happy if we had a better overall system standard > > > to simply operationale path diversity. distributed MRT IGP > > > extensions was the only thing i rememer we did, and while > > > its cool, it doesn't offer lowest latency (shorted path > > > length compared to centralized diverse path calculation). > > > Hence also proposal from our side like PPR for easier > > > forwarding plane agnostic path engineering. > > > > Then why don=3F=3F=3Ft you write a solutions draft that says =3F=3F=3F= use X, Y, and Z protocols that allows near-zero packet loss and probablis= ic delays=3F=3F=3F. > > There is always more drafts one could write than time. We > presented PPR drafts as a generic concept, its benefits and > maybe even specific details for disjoint paths is still > one some Todo list. > > > > The simple n-path diverse pathset calculation is easy to > > > use in any network, thats why its a good starting point > > > the more dynamic mechanisms you mention are still good > > > research topics IMHO. At least for quantitive evaluations. > > > > That=3F=3F=3Fs right. So write a draft that starts out using IP. It w= ill go a long way and you can test it sooner. ;-) > > I am not even sure that something that improves IPv4 value > equal to IPv6 would be welcome by part of the community ;-) > > But i think there are a lot more pieces to the puzzle > than path diversity, and those othre pieces would > require additional header info, and thats where we > run into 8200 and other issues. > > Cheers > Toerless > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Architecture-discuss mailing list > Architecture-discuss=40ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss --5e8fbc0f_68573db1_16f Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Toerless,

You have been mentioning P4 in almost every email.<= /div>
P4 (and similar) is an abstraction on top of forwar= ding plane, if anything - it doesn=E2=80=99t enhance one. The problem wit= h such layers in an heterogeneous environment - almost always they end up= being lowest common denominator, or variability inevitably kills them (O= =46 ;-))
At scale - In the chain NB(programmable logic you i= nteract with)->magic(translation from high level to 0..1)->SB - SB(= silicon) is fixed, magic is limited by amount of permutations, eventually= NB that is exposed to you have to limit amount and variability of featur= es to support more than 1 target.&=23160;
So if I end up with: convoluted management plane (I= have to program my forwarding plane directly, 1:1 relationship) &=23160;= a handicapped feature set across different HW and at the end can't do any= thing else at line rate &=23160;besides moving IP packets from A to B=E2=80= =A6 I=E2=80=99d stick to BGP ;-)

Cheers,
Jeff
On Apr 9, 2020, 4:59 PM -0700, Toer= less Eckert <tte=40cs.fau.de>, wrote:
On= Thu, Apr 09, 2020 at 04:54:24PM -0700, Dino =46arinacci wrote:
I = would alredy be happy if we had a better overall system standard
to simply operationale path diversity. distributed MRT IGP
extensions was the only thing i rememer we did, and while
its cool, it doesn't offer lowest latency (shorted path
length compared to centralized diverse path calculation).
Hence also proposal from our side like PPR for easier
forwarding plane agnostic path engineering.

Then why don=3F=3F=3Ft you write a solutions draft that says =3F=3F=3Fuse= X, Y, and Z protocols that allows near-zero packet loss and probablisic = delays=3F=3F=3F.

There is always more drafts one could write than time. We
presented PPR drafts as a generic concept, its benefits and
maybe even specific details for disjoint paths is still
one some Todo list.

Th= e simple n-path diverse pathset calculation is easy to
use in any network, thats why its a good starting point
the more dynamic mechanisms you mention are still good
research topics IMHO. At least for quantitive evaluations.

That=3F=3F=3Fs right. So write a draft that starts out using IP. It will = go a long way and you can test it sooner. ;-)

I am not even sure that something that improves IPv4 value
equal to IPv6 would be welcome by part of the community ;-)

But i think there are a lot more pieces to the puzzle
than path diversity, and those othre pieces would
require additional header info, and thats where we
run into 8200 and other issues.

Cheers
Toerless

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Architecture-discuss mailing list
Architecture-discuss=40ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discuss
--5e8fbc0f_68573db1_16f-- From nobody Thu Apr 9 17:54:38 2020 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 D2AD63A1826 for ; Thu, 9 Apr 2020 17:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 35GSr612olTH for ; Thu, 9 Apr 2020 17:54:34 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8F8F3A1824 for ; Thu, 9 Apr 2020 17:54:34 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 42018548015; Fri, 10 Apr 2020 02:54:29 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 38E5F440040; Fri, 10 Apr 2020 02:54:29 +0200 (CEST) Date: Fri, 10 Apr 2020 02:54:29 +0200 From: Toerless Eckert To: Dino Farinacci Cc: Tony Li , architecture-discuss@ietf.org Message-ID: <20200410005429.GK44502@faui48f.informatik.uni-erlangen.de> References: <20200409235935.GH44502@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 10 Apr 2020 00:54:37 -0000 On Thu, Apr 09, 2020 at 05:11:06PM -0700, Dino Farinacci wrote: > Toerless, you (we) have to present a design. You gotta write it down in some form. How else do you get peer review? I think i explained in another mail on the thread that we first did the gap analysis to not immediately run into the concern "why" on any proposal. Just sequentialization. Cheers toerless > Dino > > > On Apr 9, 2020, at 4:59 PM, Toerless Eckert wrote: > > > > ???On Thu, Apr 09, 2020 at 04:54:24PM -0700, Dino Farinacci wrote: > >>> I would alredy be happy if we had a better overall system standard > >>> to simply operationale path diversity. distributed MRT IGP > >>> extensions was the only thing i rememer we did, and while > >>> its cool, it doesn't offer lowest latency (shorted path > >>> length compared to centralized diverse path calculation). > >>> Hence also proposal from our side like PPR for easier > >>> forwarding plane agnostic path engineering. > >> > >> Then why don???t you write a solutions draft that says ???use X, Y, and Z protocols that allows near-zero packet loss and probablisic delays???. > > > > There is always more drafts one could write than time. We > > presented PPR drafts as a generic concept, its benefits and > > maybe even specific details for disjoint paths is still > > one some Todo list. > > > >>> The simple n-path diverse pathset calculation is easy to > >>> use in any network, thats why its a good starting point > >>> the more dynamic mechanisms you mention are still good > >>> research topics IMHO. At least for quantitive evaluations. > >> > >> That???s right. So write a draft that starts out using IP. It will go a long way and you can test it sooner. ;-) > > > > I am not even sure that something that improves IPv4 value > > equal to IPv6 would be welcome by part of the community ;-) > > > > But i think there are a lot more pieces to the puzzle > > than path diversity, and those othre pieces would > > require additional header info, and thats where we > > run into 8200 and other issues. > > > > Cheers > > Toerless > > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Thu Apr 9 18:05:59 2020 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 86FF43A184E for ; Thu, 9 Apr 2020 18:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 5V6h44dUURCK for ; Thu, 9 Apr 2020 18:05:55 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51AC03A184D for ; Thu, 9 Apr 2020 18:05:55 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 31D9B548017; Fri, 10 Apr 2020 03:05:50 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 25C77440040; Fri, 10 Apr 2020 03:05:50 +0200 (CEST) Date: Fri, 10 Apr 2020 03:05:50 +0200 From: Toerless Eckert To: Jeff Tantsura Cc: Dino Farinacci , Tony Li , architecture-discuss@ietf.org Message-ID: <20200410010550.GL44502@faui48f.informatik.uni-erlangen.de> References: <20200409215925.GA44502@faui48f.informatik.uni-erlangen.de> <4BB15D5F-735F-409D-B518-DD99A4428794@gmail.com> <20200409222341.GC44502@faui48f.informatik.uni-erlangen.de> <952F886C-1B20-4E80-9948-D5D7EFF3BAA6@gmail.com> <20200409231646.GF44502@faui48f.informatik.uni-erlangen.de> <1936E4A5-6E5A-41AA-BA7F-B9EBEEE170C7@gmail.com> <20200409234251.GG44502@faui48f.informatik.uni-erlangen.de> <6D5C324F-9078-4DC5-8B5D-D0D95EB6D1C7@gmail.com> <20200409235935.GH44502@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 10 Apr 2020 01:05:58 -0000 On Thu, Apr 09, 2020 at 05:21:29PM -0700, Jeff Tantsura wrote: > Toerless, > > You have been mentioning P4 in almost every email. > P4 (and similar) is an abstraction on top of forwarding plane, if anything - it doesn???t enhance one. > The problem with such layers in an heterogeneous environment - almost always they end up being lowest common denominator, or variability inevitably kills them (OF ;-)) Sure. BUt remember example from prior mail in this thread, the question is what to do with such a programming language. E.g.: using it purely as a proof of feasiblity of a proposed forwarding plane function. This is just one example. Your argument that is often lowest common denominator seems to very well support this option. We already know it makes researchers happy. thats a second example. Using it to write highest performance production probably as you said not ideal for that. But initial research might well get away with lower speed or lower scale code. > At scale - In the chain NB(programmable logic you interact with)->magic(translation from high level to 0..1)->SB - SB(silicon) is fixed, magic is limited by amount of permutations, eventually NB that is exposed to you have to limit amount and variability of features to support more than 1 target. Exactly. Thats another core important aspect to consider. > So if I end up with: convoluted management plane (I have to program my forwarding plane directly, 1:1 relationship)  a handicapped feature set across different HW and at the end can't do anything else at line rate  besides moving IP packets from A to B??? I???d stick to BGP ;-) I think you are taking apart a combination of options of your own design ;-) Today, everybody can fairly easily build a virtual programmed overlay network as long as he just uses routers that are VM/container in DCs, and somehow doesn't have to care about controlling QoS on the paths between them, but is fine with controlling them indirectly. SD-WAN being one example of such overlay networks. And there is IMHO a lot of great innovation in it. Is the innovation inside the network layer ? Who knows, its all proprietary. I'd guess there is some. So, how do i make a hardware router/switch based metro network a possible target for such innovator ? Make it programmable. And of course that comes with a lot of challenges. But it wrt. management plane it could be similar to how a SW-overlay network is deployed on DC: Totally separate to what the actual SW on the VM/containers does. Aka: The system to download some P4++ code into a network infra has nothing to do with what protocols that P4++ code implements. Cheers Toerless > Cheers, > Jeff > On Apr 9, 2020, 4:59 PM -0700, Toerless Eckert , wrote: > > On Thu, Apr 09, 2020 at 04:54:24PM -0700, Dino Farinacci wrote: > > > > I would alredy be happy if we had a better overall system standard > > > > to simply operationale path diversity. distributed MRT IGP > > > > extensions was the only thing i rememer we did, and while > > > > its cool, it doesn't offer lowest latency (shorted path > > > > length compared to centralized diverse path calculation). > > > > Hence also proposal from our side like PPR for easier > > > > forwarding plane agnostic path engineering. > > > > > > Then why don???t you write a solutions draft that says ???use X, Y, and Z protocols that allows near-zero packet loss and probablisic delays???. > > > > There is always more drafts one could write than time. We > > presented PPR drafts as a generic concept, its benefits and > > maybe even specific details for disjoint paths is still > > one some Todo list. > > > > > > The simple n-path diverse pathset calculation is easy to > > > > use in any network, thats why its a good starting point > > > > the more dynamic mechanisms you mention are still good > > > > research topics IMHO. At least for quantitive evaluations. > > > > > > That???s right. So write a draft that starts out using IP. It will go a long way and you can test it sooner. ;-) > > > > I am not even sure that something that improves IPv4 value > > equal to IPv6 would be welcome by part of the community ;-) > > > > But i think there are a lot more pieces to the puzzle > > than path diversity, and those othre pieces would > > require additional header info, and thats where we > > run into 8200 and other issues. > > > > Cheers > > Toerless > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Thu Apr 9 20:33:02 2020 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 1854F3A1A53 for ; Thu, 9 Apr 2020 20:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhaxmAHKv-fW for ; Thu, 9 Apr 2020 20:32:59 -0700 (PDT) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 A3B1B3A1A52 for ; Thu, 9 Apr 2020 20:32:59 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id p8so461799pgi.5 for ; Thu, 09 Apr 2020 20:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=dpoY75CoVVj4Yzf9KkHCrufJ2syZPGun/wAXGUaF84I=; b=B/EGFB0ipH0BI9S7iYLVC6MeJ1Fm1Jv/FqugpHeoKY385iFp02XETLZqV+cjAxG4xu zNqSbGpRrhRwrhSn7yuXSdISEr2RgkW0jFFnoGcQ8ZawAOdJ9Z0k7BXvz7ZmMO3EqfkJ +EZdI9Kc57Tl0FTCtHNYUeGyBdwtH/BF5f7OIgqHrYJh+IlnDim2Od0lTH5XCUYyb6fl A8OCGA+BEKbeoM3WzYrn28ZT9BBJqyfkOQwBOeL4Me18/06AsDsgO1SW+QNL9PCEk5dH xh18gTrgbuAW+g+l+mtGhNFRIbeoo+9QkyIFBPKybCwpSgXa8znaDK4F4ZkuV0qQqIAt POcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dpoY75CoVVj4Yzf9KkHCrufJ2syZPGun/wAXGUaF84I=; b=t2NvVZx+6ucHzGGRNFVvuPEdYffQonhlktLqb+c/gKG+vS3BmEcrfV+d2K3MhwLAKD ilkQa1sMfBfIrg+c7qFgxRQXQcbo94qIHhm2ErrHm1JdmsfLHss/Dc+O/pOrJgcXY8f5 wMJZgr1+Ooen2A+ZoExn1zXZ2TqcIlh83LuuBYLHQ/tmu0WMCdkZ24d/d0Dg+DQOndpT SV7wTdaJpXyP71JzSkx7sCpQNgbGTIy8gCwa4wf0b6hlf7IFbUFlblZpaUo/91DdsUhr vMcYmKdVOWS/dxM1JzNlNUamBenm+DTEpg2HBoZzt1eAkPJRM1ixk7UlBQPaeZfmYCtC 8YYg== X-Gm-Message-State: AGi0PubNtxCJsmSG/hCYJot+TusuXtue0Cr1ACErKjNcq6zxJjxKOH5+ P/QmpXwWFDMfBMf8G+CrvldskV0o X-Google-Smtp-Source: APiQypLzt+hGsOA4gPd+P+ksRjCrIN5i85T5GSYZ64EUXTExeJ0HfnoxC5TtIZDHTFQRZ2K3ygWJ4A== X-Received: by 2002:a63:1662:: with SMTP id 34mr2621893pgw.117.1586489578532; Thu, 09 Apr 2020 20:32:58 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id na18sm534896pjb.31.2020.04.09.20.32.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2020 20:32:57 -0700 (PDT) To: Toerless Eckert , Dino Farinacci Cc: architecture-discuss@ietf.org References: <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <229AAF4A-C43F-46E9-97C6-99CC124E9B48@gmail.com> <20200409212841.GK28965@faui48f.informatik.uni-erlangen.de> <0A15B52E-2A67-4D6A-AACF-8A92FB67ADEC@gmail.com> <20200409214205.GL28965@faui48f.informatik.uni-erlangen.de> <8D444744-A6C1-4313-982D-4C55F0F8A5AD@gmail.com> <20200410000937.GJ44502@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: <97604e18-3c3d-cbcb-a4af-2ae94b815114@gmail.com> Date: Fri, 10 Apr 2020 15:32:52 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20200410000937.GJ44502@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 10 Apr 2020 03:33:01 -0000 On 10-Apr-20 12:09, Toerless Eckert wrote: > On Thu, Apr 09, 2020 at 03:07:14PM -0700, Dino Farinacci wrote: >>> I was the one who asked the embarassing question about SRv6. >> >> And I was the won who said ???are we going to leave any data for the u= ser???. Where I heard a loud Tony Li laugh from the audience. ;-) >=20 > Btw. There are interesting hybrid optical/electrical research > network architectures, where optical packets arriving are > passed through an optical delay loop and the packet header > spoofed into the electrical side to make packet > processing decisions, which can then happen when the packet > header starts to appear at the end of the optical delay loop. That's roughly how computers worked in the early 1950s, with words stored serially in mercury delay lines, where the bits travelled at the speed of sound, so that micro-second latency vacuum tube logic circuits could comfortably do their thing before the bits emerged from the delay line. Such computers were almost impossible to program and they died as soon as faster memories were invented. The problem was that you had to be ready exactly when the bits you wanted came around; this was called optimum programming and the people who could do it were the =C3=BCbergeeks of 1950. As you said, "research architectures". Or limited domains, as somebody else said. >=20 > Given how these optical networks will be many orders of > magnitudes faster than the electrical processing > capability, we may end up with networks that just scream > to get larger packets to max out performance. 100 Kb minimum. > And then we can waste all the header space we ever wanted. > SIDs in URL encoding, x86 BIER replication function !!!! Sure, but it won't help typical UDP streams much. We may not like the historical traffic patterns, but we can't ignore them. Brian >=20 > Cheers > Toerless >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > . >=20 From nobody Fri Apr 10 03:53:17 2020 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 B5A813A2092 for ; Fri, 10 Apr 2020 03:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 E0i8BqJNtR4A for ; Fri, 10 Apr 2020 03:53:12 -0700 (PDT) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 93AA33A208E for ; Fri, 10 Apr 2020 03:53:11 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.136.239]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 03AAqeqI021651 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2020 03:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1586515975; x=1586602375; i=@elandsys.com; bh=7ya9Ur0mPtqWA2nPslVCAi1mFHRCt+bftQbYvDOsbNE=; h=Date:To:From:Subject:In-Reply-To:References; b=2/dBcMPwXvrAB7ha+Iv/Bd+TqgCfyf9z5xGpWJ/RjvzYfdKCNfk3mqGBowr4mg+Us JHMWiECLCH/qoO14labmmza8W+pL5GU87U6orVH5b+Iv223CPQakJzPC9N4y4emUAE 2EJrcfgl6dM8+WM3XLJ4yzcN01+fBM342gI0t24M= Message-Id: <6.2.5.6.2.20200410013325.0c85def8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 10 Apr 2020 03:08:27 -0700 To: Toerless Eckert , architecture-discuss@ietf.org From: S Moonesamy In-Reply-To: <20200409192646.GI28965@faui48f.informatik.uni-erlangen.de> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408055530.GC28965@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200408102605.0ba41040@elandnews.com> <20200408195622.GK28965@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200408142709.0b957348@elandnews.com> <20200408230852.GS28965@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200408222422.0ae60b50@elandnews.com> <20200409113017.GX28965@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200409080057.0adeffc8@elandnews.com> <20200409192646.GI28965@faui48f.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 10 Apr 2020 10:53:16 -0000 Hi Toerless, At 12:26 PM 09-04-2020, Toerless Eckert wrote: >Sure, its just my impression that the IETF WG and IRTG RG model >works a lot better from where i stand than the IAB model. >I also didn't mean adult supervision in itself as a negativ >term, i am quite happy that overall it happens in a way it >does from IESG to WGs. I am just saying that i wish that >i do not see any benefits in how the IAB is run differently >from that model. I did not read your comment as negative. There was this discussion on an IETF thread in which it was argued that an IETF WG was a SDO. I wonder whether it was made for the sake of argument or because that is how the IETF model operates. The IAB is an artefact. In my opinion, and I could be wrong, the two are not comparable. It is the privilege of IAB members to determine how their committee should be run. Whether I like or do not like does not make any difference to the state of affairs. Regards, S. Moonesamy From nobody Fri Apr 10 05:05:30 2020 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 2A7083A07A7 for ; Fri, 10 Apr 2020 05:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.49 X-Spam-Level: * X-Spam-Status: No, score=1.49 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PDS_OTHER_BAD_TLD=1.989, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fyber.space 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 lIsxPdaUtfoo for ; Fri, 10 Apr 2020 05:05:26 -0700 (PDT) Received: from mail.fyber.space (mail.fyber.space [IPv6:2a01:4f8:c0c:4314:100::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 566843A07A6 for ; Fri, 10 Apr 2020 05:05:26 -0700 (PDT) Received: from mail.intra.fyber.space (mail.fyber.space [127.0.0.1]) by mail.fyber.space (Postfix) with ESMTP id 48zGtD1X12zWyf for ; Fri, 10 Apr 2020 12:05:24 +0000 (UTC) Authentication-Results: mail.intra.fyber.space (amavisd-new); dkim=pass (1024-bit key) reason="pass (just generated, assumed good)" header.d=fyber.space DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fyber.space; h= content-transfer-encoding:content-language:content-type :mime-version:user-agent:date:message-id:subject:from:to; s= dkim; t=1586520323; x=1589112324; bh=DXWj6PrKrkC/aCPDWGPLgCyxBr0 rdDVxZNhaOXb8jzo=; b=ARzPYmFx3TtcdJpYMSsogtBB6NjtC9bm3UtzGTG7x6x DiO8fs0oTkF3ZX4n3pJkZvOQKkGKSo6mXvVu4HvDm4i4IJZLFKe/UyqMCy6zzsJE KhrF4uYOH8WvlzpvE/mDrVu3kq/LLJsG+Ak14ezDj3tCSNxxOm9en0neiXcJzcCk = X-Virus-Scanned: Debian amavisd-new at mail.intra.fyber.space Received: from mail.fyber.space ([127.0.0.1]) by mail.intra.fyber.space (mail.intra.fyber.space [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id D6181B8UTKY1 for ; Fri, 10 Apr 2020 12:05:23 +0000 (UTC) Received: from [IPv6:2001:a62:4e3:b501:6873:5414:dc7a:67b4] (unknown [IPv6:2001:a62:4e3:b501:6873:5414:dc7a:67b4]) by mail.fyber.space (Postfix) with ESMTPSA id 48zGtB6mQ4zWyT for ; Fri, 10 Apr 2020 12:05:22 +0000 (UTC) To: architecture-discuss@ietf.org From: =?UTF-8?Q?Vincent_Truchse=c3=9f?= Autocrypt: addr=ietf-arch@v-tr.org; prefer-encrypt=mutual; keydata= mQENBF6MlBQBCADJcBW5ZoxYw0D01zRK1DdYrZM9dh+MGM0s5pg9PHBYCZdi73eq6CsD7TaA j4xCmRmVReCSsOczw41PMlgI0iRESmJwqhJs0oHbFSEzPCYVd2ekQPiI8BsUNkjPCHV/aUNk R80ZToduxZv18Z2YQw9I0Wnes25YnHakcLiBNTUIBWc40jV/O027K3TugAtcpspUFMpY7QSJ VG377ZrVck2beXtQTZl52M8AnWJp39qya6GXiZg217oKRpjXojsBeep+sE+BcPpsfj/mjbx8 3QqsUFuyRaosJ/tbImdIi780VJtZWjUYC3YsZSx/wlGiYuEncpUY3Ai6GDDK5qJrOfQ1ABEB AAG0H1ZpbmNlbnQgVHJ1Y2hzZcOfIDxtZUB2LXRyLm9yZz6JAVcEEwEIAEECGwMFCQHhM4AF CwkIBwIGFQoJCAsCBBYCAwECHgECF4AWIQTYjPr6pkipmgSKxz8M5Di139y4MwUCXoyfZAIZ AQAKCRAM5Di139y4M0naCACmXasHYO8QqjI/eqxAzHGKPfTWTfsEU4+VXZOZGzYmZfBqKYoX l2LzGh1jKe+zNObodSQcIw83itMBxccFbZIgQ4UQY0CL8iTptt+B+WiVozYWVB9teLof78TH 6lQPqFlDRJ3NjjOGNXLIYPXMOa2VH50i+RGfQ1pgGmtaFqjNgzEh1LnSaMPSGgAARc042m6/ fYeWS2HdrwB3gHSncZxYcVVQX+uhjKkUcwU9BQzHe9Z08BUAPVKmQqegri/c3blUWMhINs8a kXygyCOrAS/pWwqQuf+JJLsLEZ7Qd7O3hpWYMzf8OsKvHk45IyRo5emZ1+A+nc/vWFRNAflh IfRYuQENBF6MlBcBCADBjfFlM1WxbYZEa51Ty0Sc4YMbAVWcyWlttxYYxJX1fmXiXq5Y65DC XXf2er64BANZ8Uveg7BWe/6ovkpYBh0UxDyuUDzimHL5i1sODW2nS1T1hxH4hG99tQS3cgFb 6kFdNvZn0avuRTtch1JntVl9pnLx9NLxDi7LM16KuZf13x2489o5oBpKssZn6VtvS91z39ax hd8bDUObWqaJdgmuAq0D/ld+hmCFQ76jEMBNezCzcXxq8BhT98SbjGNf3ojCsLqAr8XOQzS4 bOHZ4yhT0dFlSGpgxzIl7Odn/uV9HTnYvxIchxRSw4MR2CsDhDvxJJBGq7P1VXXAyocxxp7b ABEBAAGJATwEGAEIACYWIQTYjPr6pkipmgSKxz8M5Di139y4MwUCXoyUFwIbDAUJAeEzgAAK CRAM5Di139y4M68pB/4rmyL30wo4yHNTzmftY1dN1EbKEbJPQD3GCU5255aaOWBaLe+9QeKM BECjM9oRQGeF+PbsRZArOzpGul1YOiiqa295W/02kNRRwbZ7MvCGBFhJh5FC4DNdU7dKEwBx l7YpC3jOzsXtC2uYrk0XhKXVHthCqktq8LokrUTQX20F31hYHbZJKCDuj0EdxmUeRe45E7qH +WIo/Wcp11qVnQKNMuDTgu0Ck5ZetA8lPO8IKZUIwiQoI9agDppzutfo0ri1r2AGO1+ZPQY4 es68oGLdkCPBCXoQtTqwotscsA1Ev8UXPp+wloPqggdv0S1RoCvptmjeHV1Hs+ozvmqItgvq Message-ID: <98d43782-6543-b473-6a3c-dc6fe0e4de7d@v-tr.org> Date: Fri, 10 Apr 2020 14:05:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [arch-d] Mail Etiquette 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, 10 Apr 2020 12:05:28 -0000 Hi there, I am new on this list but I wonder if it is generally the case here that people send their replies not only to the list's bounces-address but also directly to the author as well. I'm just asking because some people might find it harder to sort their mail fully automated when the to-header behaves inconsistently while some do prefer their replies directed to the author and manually create filters for every list they've subscribed. Sorry if it sounds like I'm tipping on someones toess here; that's not my intention. YT, VT. From nobody Fri Apr 10 05:58:20 2020 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 BF5A53A0922 for ; Fri, 10 Apr 2020 05:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.406 X-Spam-Level: X-Spam-Status: No, score=-0.406 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_RHS_DOB=1.514] 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 hY36PI5TTlzV for ; Fri, 10 Apr 2020 05:58:17 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC15E3A091E for ; Fri, 10 Apr 2020 05:58:17 -0700 (PDT) Received: from [10.0.0.129] (c-68-49-104-93.hsd1.mi.comcast.net [68.49.104.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id A02E95402BC; Fri, 10 Apr 2020 08:58:07 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Jared Mauch In-Reply-To: <98d43782-6543-b473-6a3c-dc6fe0e4de7d@v-tr.org> Date: Fri, 10 Apr 2020 08:58:07 -0400 Cc: architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <869472A7-EF3E-4CC2-8ACE-0196E8B10504@puck.nether.net> References: <98d43782-6543-b473-6a3c-dc6fe0e4de7d@v-tr.org> To: =?utf-8?Q?Vincent_Truchse=C3=9F?= X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [arch-d] Mail Etiquette 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, 10 Apr 2020 12:58:19 -0000 > On Apr 10, 2020, at 8:05 AM, Vincent Truchse=C3=9F = wrote: >=20 > Hi there, >=20 > I am new on this list but I wonder if it is generally the case here = that > people send their replies not only to the list's bounces-address but > also directly to the author as well. >=20 > I'm just asking because some people might find it harder to sort their > mail fully automated when the to-header behaves inconsistently while > some do prefer their replies directed to the author and manually = create > filters for every list they've subscribed. >=20 > Sorry if it sounds like I'm tipping on someones toess here; that's not > my intention. >=20 Much of this is due to the history of how e-mail has worked, etc. It=E2=80=99s often unknown who is behind an alias and then participants = in the thread will get copied on replies. This can often lead to them = seeing the reply before the list runs and gets data out to the others. Mailing list software also has the option to disable people getting the = e-mail who send it (eg: mailman it=E2=80=99s called the [metoo] = setting). =20 People like myself tend to run procmail on the server side which = filter/weed out duplicates so I don=E2=80=99t see two copies. Your mail = client may also silently suppress them as well. It=E2=80=99s also helpful to know that your message did make it to the = list vs being silently held out there. (Think of e-mail back in the = UUCP days, when it may take 8-24h to have something flow through and a = bit more to flow-back). - Jared From nobody Fri Apr 10 06:04:03 2020 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 B93FB3A093D for ; Fri, 10 Apr 2020 06:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 My95v7QMrVMM for ; Fri, 10 Apr 2020 06:04:00 -0700 (PDT) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 0B8BD3A093B for ; Fri, 10 Apr 2020 06:03:59 -0700 (PDT) Received: by mail-ua1-x92c.google.com with SMTP id g10so598630uae.5 for ; Fri, 10 Apr 2020 06:03:59 -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=NxmhsE2em8bYCYQc0bNSeqhOdcs93ResRWcf5JaiNtI=; b=sjHGyCx6x0RzZAmXMm0xvGxb0kmyg87IV6pOYhvMCG8X24XlCJVDgjmQ9lw6RNCHnC fLrS3scAzTw7EBC3d/9j+UX5GYHxAq2fRg5INe3XAOS0VM1ARmp5Nzz+dk1UeGoxMp+p YpP1TFjKMMmj94v6fUICSPNdXEwxACYuqgwXjpC1EoHB8mVSh2rYBBkp+Tj6G4AWO25X WpAw4H37WhkpOQ25NNoJ8Wov6zfU2G5CUkYMTX/kJ6tZ89agotan7vHL6SoAuZW4daD0 XpCfQ8A9C5+hBwo9RWlA8zPsXDUB4nvffi30rAci7BJx2L3H/zhTsFLWjweydLj8/DH9 jz8w== 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=NxmhsE2em8bYCYQc0bNSeqhOdcs93ResRWcf5JaiNtI=; b=rbwC0jK6RcflYSmTF9lx/T7ZZ3taYZxpSfhFa8gd2AhFrsuWGnxNzSoVXLBD2kFs0L 8igN6b6DjXJrdG9zsUfWgQeHIpqIFJW0yyOeYNsLMQOzMW8rw0VB4JauVoypZ6mJPml0 TqA4RfajBkG+d4azGxYqWzHsz5x0rF/C5+WNpJ2OQJf33/+W/PZMgRnDX3aANZHAMbDL 8trs2ohU180KYmeHw17kkVkWDQsJwZMtH/QFGBDB9C3wemxp4u6ilCGyU/FNqh2B8sFR 7sC3Uwbs3h1CFc4ysyHhRT1k1VLS+hakgOYc1yu84Dh224idpJTMr2q25r1rMOHgKyOF L2rg== X-Gm-Message-State: AGi0Publge4z8z8IfKU/i0h5MqkeIORZeyC6uk9diK7WeXwuzhXWOuik FqsE7ybZ/dPlrxxwXuwlii4kBUxQofyfbycLT28= X-Google-Smtp-Source: APiQypLfwYpSZD2IlAwLIreZ+9hoacoGeRNZpJJcKwK/bJc0zybWi6P75ybyMCTzVzWaqwx0TenyysarjPzXq0DX8RY= X-Received: by 2002:ab0:710a:: with SMTP id x10mr2764907uan.76.1586523838936; Fri, 10 Apr 2020 06:03:58 -0700 (PDT) MIME-Version: 1.0 References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <4bbecb54-5d15-8d13-14c5-c58bd54ba009@gmail.com> In-Reply-To: <4bbecb54-5d15-8d13-14c5-c58bd54ba009@gmail.com> From: Uma Chunduri Date: Fri, 10 Apr 2020 06:04:06 -0700 Message-ID: To: Brian E Carpenter Cc: architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="000000000000d8f87805a2ef5de7" Archived-At: Subject: Re: [arch-d] our troubles [was: ETSI launches new group on Non-IP Networking addressing 5G new services] 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, 10 Apr 2020 13:04:02 -0000 --000000000000d8f87805a2ef5de7 Content-Type: text/plain; charset="UTF-8" in-line.. On Thu, Apr 9, 2020 at 3:32 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > I think Uma's question deserves some thought: > > On 09-Apr-20 14:10, Uma Chunduri wrote: > > > All our troubles will soon be over > > > > > > While I don't know all their troubles by reading that announcement; > would definitely love to hear what do you think our troubles are ...(if > any). * > > I know I've said it before, but I sum it up as "you can't beat queueing > theory". Right. And yes, statistical multiplexing would always be there. I don't know how we are going to meet stringent real-time requirements in a > network architecture that fundamentally assumes contention and queues (and > has done since 1969). I don't how ETSI is going to do that either. > Me too. However, there is lot of work happening in various forums including IEEE/TSN, research communities and other SDOs. This is one of the aspects perhaps IRTF or some other relevant forum in IETF can look into; if at all if, there is a forum to see better than BE stuff and how it can co-exist with BE with our transport layer fairness principles. Remember there could be other aspects too. mIOT stuff. There was this topic on "potentially" billions of IoT (non vehicular or non UAV UEs), which are resource constrained and can't do (IPv6) header compression. These devices emit smaller amount of data connecting to the radio and the associated spectrum cost (one of the most sacred and expensive resource in that domain)... -- Uma C. > > Brian > > > > > -- > > Uma C. > > > > [*] Appreciate your work and concur a lot on > https://tools.ietf.org/html/draft-carpenter-limited-domains-13 . > > > > > > On Tue, Apr 7, 2020 at 9:59 PM Brian E Carpenter < > brian.e.carpenter@gmail.com > wrote: > > > > All our troubles will soon be over, apparently: > > > > > https://www.etsi.org/newsroom/press-releases/1749-2020-04-etsi-launches-new-group-on-non-ip-networking-addressing-5g-new-services > > > > Stay well > > Brian Carpenter > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > > > --000000000000d8f87805a2ef5de7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
in-line..

On Thu, Apr 9, 2020 at 3:32 PM B= rian E Carpenter <brian.e= .carpenter@gmail.com> wrote:
I think Uma's question deserves some thought:

On 09-Apr-20 14:10, Uma Chunduri wrote:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 All our troubles will soon be over
>
>
> While I don't know all their troubles by reading that announcement= ; would definitely=C2=A0love to hear what do you think our troubles are ...= (if any). *

I know I've said it before, but I sum it up as "you can't beat= queueing theory".

Right. And yes, sta= tistical multiplexing=C2=A0 would always be there.=C2=A0

I don't know how w= e are going to meet stringent real-time requirements in a network architect= ure that fundamentally assumes contention and queues (and has done since 19= 69). I don't how ETSI is going to do that either.
=
Me too.=C2=A0

However, t= here is lot of work happening in various forums including IEEE/TSN, researc= h=C2=A0communities and=C2=A0 other SDOs. This is one of the aspects perhaps= IRTF or some other relevant forum in IETF can look into; if at all if, the= re is a forum to see better than BE stuff and how it can co-exist with BE w= ith our transport layer fairness principles.

R= emember there could be other aspects too.=C2=A0

mI= OT stuff. There was=C2=A0 this topic on "potentially" billions of= =C2=A0 IoT (non vehicular or non UAV UEs), which are resource constrained = and can't do (IPv6) header compression. These devices=C2=A0emit smaller= amount of data connecting to the radio and the associated spectrum cost (o= ne of the most sacred and expensive resource in that domain)...
<= br>
--
Uma C.
=C2=A0

=C2=A0 =C2=A0Brian

>
> --
> Uma C.=C2=A0
>
> [*] Appreciate your=C2=A0 work and concur a lot on=C2=A0=C2=A0https://tools.ietf.org/html/draft-carpenter-l= imited-domains-13=C2=A0.=C2=A0
>
>
> =C2=A0On Tue, Apr 7, 2020 at 9:59 PM Brian E Carpenter <brian.e.carpenter@gma= il.com <mailto:brian.e.carpenter@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0All our troubles will soon be over, apparently:
>
>=C2=A0 =C2=A0 =C2=A0https://www.etsi.org/n= ewsroom/press-releases/1749-2020-04-etsi-launches-new-group-on-non-ip-netwo= rking-addressing-5g-new-services
>
>=C2=A0 =C2=A0 =C2=A0Stay well
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Brian Carpenter
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0Architecture-discuss mailing list
>=C2=A0 =C2=A0 =C2=A0Architecture-discuss@ietf.org <mailto:Architecture-discuss@i= etf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.o= rg/mailman/listinfo/architecture-discuss
>

--000000000000d8f87805a2ef5de7-- From nobody Fri Apr 10 06:05:09 2020 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 7FDDA3A093E for ; Fri, 10 Apr 2020 06:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFDlnpIyYO9r for ; Fri, 10 Apr 2020 06:05:03 -0700 (PDT) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 E648A3A093D for ; Fri, 10 Apr 2020 06:05:02 -0700 (PDT) Received: by mail-ua1-x931.google.com with SMTP id 21so599107uae.4 for ; Fri, 10 Apr 2020 06:05:02 -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=tWaibZdu6FLgQYdbFiq0nhWZgjKlpwYuLiCZd6MLFvY=; b=SJeNgyc3PkilwMq1zkYefK/M6QptTA4e8zXipszPVkN5Uwn1h9Wt2ID/Ebt1/VrLeh vecDgyTCSinZjpmIMEC6ngDXr8+cKAJYyl70LIMrj44Ix9cxxxbjjx5kudUB6/8RF12B B06IMt6vkkjU3YHkIflxaS8rFcagf7hL5WAHKcr5AU2Juqz7pea0+UhQTWS3h/QCbAN8 zZNcOgKNkAvdyn9UW9Hek3K1Cj97mBSWaJwakJzHqyehpXxEdfqRymjVz118FsEBDgKG bRErmubPMMiqQmkpqOQRV5mpXlA2z4nqU/L0kDRAb5+6Z6zOcRi7Qp/VegUZn2XMFk93 3A4w== 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=tWaibZdu6FLgQYdbFiq0nhWZgjKlpwYuLiCZd6MLFvY=; b=rmKCU/1pGESiXtSAqeDy55/rgCoWwkq5a1i4cizbilTiLxaH1VodDnKLG+zJHNDfzG ruv8oNLPXQ582y+ohVhzxNHVkC7/dqPw96u+ioqVNc22zGfqGD0TA0kT6aKhYk1ulgy0 8OV1w/y9PN5U40bh5rzrKlTEsUYfGfb640DTdpj68Ycs/izp1B5PZRu++rNKf/UQA7Kg di4boDHPi5tIS1Xr3sGgJAXbW+4EVEIGOakbj+8BA6ggUEG94JiOm2BX18Vh+SqQuRoG td94KLva5a4Jz9vJh/GIxHju+G9HKyjMmtHHmF5OCrPjbwAJG+Ieqo9xgJJU6HeF50CH 9+QA== X-Gm-Message-State: AGi0PuYQM1YGRzHlLQ/0qVKVrvxthF035insfopI4U0idOpkV3pnmrYi clFwiU2TbwOZjLSajVa0QfgwouyExNjj1FeVVU8= X-Google-Smtp-Source: APiQypLiubMjDai3bONpxVvMamE8Dr2e/xU1M3YL3phMr+g9L3HC3+CMJkXPoa4q2ir1ZMB8/bB47LkVQTrBKEs2UJM= X-Received: by 2002:ab0:73cd:: with SMTP id m13mr2702847uaq.22.1586523901831; Fri, 10 Apr 2020 06:05:01 -0700 (PDT) MIME-Version: 1.0 References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> In-Reply-To: From: Uma Chunduri Date: Fri, 10 Apr 2020 06:05:08 -0700 Message-ID: To: Henning Schulzrinne Cc: Bob Hinden , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="00000000000098afb405a2ef614d" Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 10 Apr 2020 13:05:06 -0000 --00000000000098afb405a2ef614d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Lot of (brutal) truths in the link below. But this slides would have painted a different picture if there were incentives for the E2E Qos way back. There was no business model to deploy this (besides the neutrality stuff). However, as so many changes with better hardware than 2-3 decades ago, programmable schedulers, and the raise of limited domain use cases (+ the new E2E with disappearing transit) there is a possibility. Perhaps when the initial hype cycle of 5G/B5G is over with $$ on the table for some verticals. Or who knows; it may never happen! -- Uma C. On Thu, Apr 9, 2020 at 9:41 AM Henning Schulzrinne wrote: > Since we're talking slides, I'll throw in my take: > > http://www.cs.columbia.edu/~hgs/papers/2019/2019%20Internet40%20IIT-RTC.p= df > > Every single failed network architecture has promised QoS by making bits > more expensive; every successful technology has lowered the total cost of > deployment and operations and making bits cheaper. > > On Thu, Apr 9, 2020 at 12:26 PM Bob Hinden wrote: > >> I wonder if this desire for new non-ip networking architectures, is >> really a replay of the what I call the packet switching vs. circuit >> switching debate. Somewhat more recently Ethernet vs. Token ring. >> Basically, can networking architectures provide deterministic service (l= ike >> circuit switching), or is the Internet best effort OK. >> >> It was very common to hear that voice or video couldn=E2=80=99t possibly= work >> over an Internet style packet switching network. I haven=E2=80=99t hea= rd that in >> a while, or at least until recently after the 5G hype started gearing up= . >> >> I attended the lunch speaker session on 5G at the Singapore IETF, slides >> can be found: >> >> >> https://datatracker.ietf.org/meeting/106/materials/slides-106-edu-sessa-= 5g-impact-on-networks-edge-cloud-and-slicing-00 >> >> Seemed to me it was proposing (see slide 13) an end to end 5G >> network/service. Lots of words like "Guarantee transport SLAs for each >> service=E2=80=9D, =E2=80=9COptimize network resources as load conditions= change=E2=80=9D, etc. I >> think arguments proposing a new non-ip networking architecture is back t= o >> wanting a more deterministic networking (aka circuit switching). I >> suppose it also has something to do with wanting to sell services to ver= y >> large numbers of devices (vs. the current Internet model a subscription = per >> enterprise or home user). >> >> I didn=E2=80=99t understand why all of this couldn=E2=80=99t be built to= day with the >> current set of IP wireless and wired technologies. I was thinking of >> coming to the mic and ask the speaker if he had heard about the Internet= , >> but decided it wouldn=E2=80=99t be constructive :-) >> >> Bob >> >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >> > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --00000000000098afb405a2ef614d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Lot of (brutal) truths in the link below.=C2=A0

But this slides would have painted a different picture if there we= re incentives for the E2E Qos way back. There was no business model to depl= oy this (besides the neutrality stuff).

However, a= s so many changes with better hardware than 2-3 decades ago,=C2=A0 programm= able schedulers, and the raise of limited domain use cases (+ the new E2E w= ith disappearing transit) there is a possibility. Perhaps when the initial = hype cycle of 5G/B5G is over with $$ on the table for some verticals.
=


Or who knows; it may never happen!
=

--
Uma C.

On Thu, Apr 9, 2020 at 9:41 AM= Henning Schulzrinne <hgs@cs.colu= mbia.edu> wrote:
Since we're talking slides, I'll thro= w in my take:


Every single failed network architecture has p= romised QoS by making bits more expensive; every successful technology has = lowered the total cost of deployment and operations and making bits cheaper= .

On Thu, Apr 9, 2020 at 12:26 PM Bob Hinden <bob.hinden@gmail.com> wrote:
I wonder if this desire = for new non-ip networking architectures, is really a replay of the what I c= all the packet switching vs. circuit switching debate.=C2=A0 =C2=A0Somewhat= more recently Ethernet vs. Token ring.=C2=A0 Basically, can networking arc= hitectures provide deterministic service (like circuit switching), or is th= e Internet best effort OK.

It was very common to hear that voice or video couldn=E2=80=99t possibly wo= rk over an Internet style packet switching network.=C2=A0 =C2=A0I haven=E2= =80=99t heard that in a while, or at least until recently after the 5G hype= started gearing up.

I attended the lunch speaker session on 5G at the Singapore IETF, slides ca= n be found:

https://datatracker.ietf.org/meeting/106/materials/slide= s-106-edu-sessa-5g-impact-on-networks-edge-cloud-and-slicing-00

Seemed to me it was proposing (see slide 13) an end to end 5G network/servi= ce.=C2=A0 Lots of words like "Guarantee transport SLAs for each servic= e=E2=80=9D, =E2=80=9COptimize network resources as load conditions change= =E2=80=9D, etc.=C2=A0 =C2=A0I think arguments proposing a new non-ip networ= king architecture is back to wanting a more deterministic networking (aka c= ircuit switching).=C2=A0 =C2=A0I suppose it also has something to do with w= anting to sell services to very large numbers of devices (vs. the current I= nternet model a subscription per enterprise or home user).

I didn=E2=80=99t understand why all of this couldn=E2=80=99t be built today= with the current set of IP wireless and wired technologies.=C2=A0 =C2=A0I = was thinking of coming to the mic and ask the speaker if he had heard about= the Internet, but decided it wouldn=E2=80=99t be constructive :-)

Bob


_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--00000000000098afb405a2ef614d-- From nobody Fri Apr 10 06:12:19 2020 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 404F23A0974 for ; Fri, 10 Apr 2020 06:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 88ctulgFBZS9 for ; Fri, 10 Apr 2020 06:12:11 -0700 (PDT) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 B89D83A097E for ; Fri, 10 Apr 2020 06:12:04 -0700 (PDT) Received: by mail-vs1-xe2c.google.com with SMTP id z63so1280046vsz.2 for ; Fri, 10 Apr 2020 06:12:04 -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=Qe9evWpZNtVIp6CsY8XYKLLxmcyeTdv4ES0pyGK7gS8=; b=E4HOinS6fB6R/QWsAMqI2jypSoepN5nKk6dmZBWZo2+VEQVYmW1Xs7oPyEuGbkcs05 v9/iCXgpObr4T1pPPrduyVIQnMUImamQYMjL0SO9Ikhz3fY3Pf7GCynQHF+EWkZr9gMh QJ9PW7j4VgEeub5SIksbGN6Zv8hgyHDQhpc9o3DQrOtILF31ddW+V0Jh+T4VuSxbZHGB U4BUTlt4gWzRYJdnC2OB6fYz4W+4VpLkLO4XFTKI1OYJw3GoiqwINDDFy4zXXoKfcdOL A5eY38TCFVS+0uGryVeiMEc6tlwmSr3H34Ln3GYfSTr1tPA1/dd0/zL67QCDbEcPWF+b GhOw== 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=Qe9evWpZNtVIp6CsY8XYKLLxmcyeTdv4ES0pyGK7gS8=; b=QoxAmacHdpy1GyCNULdhPQzRpmawg4HbHJDDraEWVmPUlKdWpsjaK2zMOZ+8/KEiDD Ia7hoPxtjGiN1+MHpxDnhFgF1WJYwoVXdkM3Vi4N8V6K8y+Nb8QxByTD0+4hVLp1pMYV On+BEe1qMa77lnvNbxOFKURojGktawRiVpLsCXrIsSB31WVyAWuG59R9PXnW01+O1Kzk tD0dtqGeycaXWdatMPT3clQJbievVs8YL6cNpVe+KKVLHHQXFQkptlbmX/TP9MJjAoF7 FUy9UP/9A6lOHorbPlnJG/cDtTl6w0XBY0KYKnjl2ga32IzTWQs5s6+2TE7tjvuSbeVD 02UQ== X-Gm-Message-State: AGi0PuZrci/2tvWHZ6jBfJYRk0a7MRKqACkJDa9UXHnT44aeQpgT9ON9 Jx1/rwdcGlXfsOmqE8g47a8YAVdaMBncqZn+gIc= X-Google-Smtp-Source: APiQypKNRts8mVou/Dq1Wuos2lPI4zUUlvUsjDD+0cQ+TP2SUhnAEde5nLYA6HzL+3izf7Q9tb5QhnCiY0PuX56Azu4= X-Received: by 2002:a67:1587:: with SMTP id 129mr4027582vsv.146.1586524323696; Fri, 10 Apr 2020 06:12:03 -0700 (PDT) MIME-Version: 1.0 References: <0A15B52E-2A67-4D6A-AACF-8A92FB67ADEC@gmail.com> <53EFFD37-57EB-4288-AE19-2EB2DC3BDE39@gmail.com> <20200409215925.GA44502@faui48f.informatik.uni-erlangen.de> <4BB15D5F-735F-409D-B518-DD99A4428794@gmail.com> <20200409222341.GC44502@faui48f.informatik.uni-erlangen.de> <952F886C-1B20-4E80-9948-D5D7EFF3BAA6@gmail.com> <20200409231646.GF44502@faui48f.informatik.uni-erlangen.de> <1936E4A5-6E5A-41AA-BA7F-B9EBEEE170C7@gmail.com> <20200409234251.GG44502@faui48f.informatik.uni-erlangen.de> <6D5C324F-9078-4DC5-8B5D-D0D95EB6D1C7@gmail.com> <20200409235935.GH44502@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200409235935.GH44502@faui48f.informatik.uni-erlangen.de> From: Uma Chunduri Date: Fri, 10 Apr 2020 06:12:10 -0700 Message-ID: To: Toerless Eckert Cc: Dino Farinacci , Tony Li , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="000000000000bdd3d305a2ef7a2c" Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 10 Apr 2020 13:12:19 -0000 --000000000000bdd3d305a2ef7a2c Content-Type: text/plain; charset="UTF-8" > > > I am not even sure that something that improves IPv4 value > equal to IPv6 would be welcome by part of the community ;-) > > But i think there are a lot more pieces to the puzzle > than path diversity, and those othre pieces would > require additional header info, and thats where we > run into 8200 and other issues. > > Indeed. At some point you will come down here.. > --000000000000bdd3d305a2ef7a2c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I am not even sure that something that improves IPv4 value
equal to IPv6 would be welcome by part of the community ;-)

But i think there are a lot more pieces to the puzzle
than path diversity, and those othre pieces would
require additional header info, and thats where we
run into 8200 and other issues.


Indeed. At some point you will come do= wn here..
=C2=A0


--000000000000bdd3d305a2ef7a2c-- From nobody Fri Apr 10 06:20:14 2020 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 562503A09A1 for ; Fri, 10 Apr 2020 06:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_RHS_DOB=1.514] 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 EY7zVWSu-9dG for ; Fri, 10 Apr 2020 06:20:09 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C11E3A099F for ; Fri, 10 Apr 2020 06:20:08 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 731DF548049; Fri, 10 Apr 2020 15:20:03 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 665EA440041; Fri, 10 Apr 2020 15:20:03 +0200 (CEST) Date: Fri, 10 Apr 2020 15:20:03 +0200 From: Toerless Eckert To: Jared Mauch Cc: Vincent Truchse? , architecture-discuss@ietf.org Message-ID: <20200410132003.GM44502@faui48f.informatik.uni-erlangen.de> References: <98d43782-6543-b473-6a3c-dc6fe0e4de7d@v-tr.org> <869472A7-EF3E-4CC2-8ACE-0196E8B10504@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <869472A7-EF3E-4CC2-8ACE-0196E8B10504@puck.nether.net> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] Mail Etiquette 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, 10 Apr 2020 13:20:13 -0000 There is also now on hopefully all IETF mailing lists that you can send to a list without being member to the list, if you are at least member of one other IETF mailing list (global whitelist concept), for example when you are not normally active on a particular list, but want help on an issue for it. This means that it is highly desirable for followup replies to mails to go back to not only the list, but also individuals on the To/Cc lines, because otherwise you would not reach those off-list participants in a communication. Procmail with duplicate elimination is what i use too. Toerless On Fri, Apr 10, 2020 at 08:58:07AM -0400, Jared Mauch wrote: > > > > On Apr 10, 2020, at 8:05 AM, Vincent Truchseß wrote: > > > > Hi there, > > > > I am new on this list but I wonder if it is generally the case here that > > people send their replies not only to the list's bounces-address but > > also directly to the author as well. > > > > I'm just asking because some people might find it harder to sort their > > mail fully automated when the to-header behaves inconsistently while > > some do prefer their replies directed to the author and manually create > > filters for every list they've subscribed. > > > > Sorry if it sounds like I'm tipping on someones toess here; that's not > > my intention. > > > > Much of this is due to the history of how e-mail has worked, etc. > > It???s often unknown who is behind an alias and then participants in the thread will get copied on replies. This can often lead to them seeing the reply before the list runs and gets data out to the others. > > Mailing list software also has the option to disable people getting the e-mail who send it (eg: mailman it???s called the [metoo] setting). > > People like myself tend to run procmail on the server side which filter/weed out duplicates so I don???t see two copies. Your mail client may also silently suppress them as well. > > It???s also helpful to know that your message did make it to the list vs being silently held out there. (Think of e-mail back in the UUCP days, when it may take 8-24h to have something flow through and a bit more to flow-back). > > - Jared > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Fri Apr 10 06:23:33 2020 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 C34993A09AA for ; Fri, 10 Apr 2020 06:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 uX4OOjfjImHh for ; Fri, 10 Apr 2020 06:23:27 -0700 (PDT) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (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 25ACF3A09A3 for ; Fri, 10 Apr 2020 06:23:27 -0700 (PDT) Received: by mail-ua1-x929.google.com with SMTP id v24so606742uaj.8 for ; Fri, 10 Apr 2020 06:23:27 -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=hV8iNdivqYVdPYlkDT9E89hbiygy/1cL1eSW29fegno=; b=WsaNqXLGAPMp5NtCXri5uUx/OA4ZlZUZ1G9RPTPpAslhnotm6crU5avnWapgT2q2kg KHdK62zJEvxugz250ZuTsomkbyUmW5c7mFWVCP0S4W/XYOjtK2JOuv2f1S3Baf4VfwFm g34gbEl8GlxJFM8V0vlOcdT7y3ItiyC82TIj3XA9hzBMRFhpocZQQ1fafGnV9dfbWcUV YZTv10JVuSNvR/G/xD3jY2KhKS1YbcpEAggcHyX6OSb1v+x7MwAJ84WJYmo2hFGnB1CC N0HODWTtDZO97VxYX40QXkSTYEIRTg2SIAVn7LGxudKLB50bytxWKh0oOaEm4aoTByXw UlOw== 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=hV8iNdivqYVdPYlkDT9E89hbiygy/1cL1eSW29fegno=; b=daylx94nRbIDVBggz6aTDWlDzRyZizgWhCRiybGWSWvHuRqoMZYCI1QQL+uarS5v2K L7wLAbuXiS2yEgAnYiHMWB+qYDtbLMYMrwZl/i1/VND1gR8/5g39D0jsVzfowKN6+UZA hmkpJtOgdOTpMTKU6rGvA+hcoODJRFKqvEo9MsnZQnebPElVxR1r18r6U+kLCMUVezjE bnAb4pGZ/CivBtzFKTpufv7QJGy+mbRZG/70DlHeByQMxNIjbSe9g6bbh6PbmxsLvVQ3 QKlE+LUP91eK/pi25iBpiuiCGOQwliFoJK+RLUQdk3twMjbBaVfzLpeOUiN2OAEUTUB/ KnBA== X-Gm-Message-State: AGi0PubpCclT+GQ7aWjDtflqo8Cshsj22Ukfa1VWjJxknn6HyXQCZvVV V564PiPvGOGdt/52VWfXyid+LxzqvNxu0xFuX3FiaA== X-Google-Smtp-Source: APiQypLTXFhOXKioOKtsD/kVYgZ/EPrfu2t6FwNJeiI5ZeOIGS7IMeX/x/XyEi60hr/JVKBjJiizc2R79F48V0rmVD4= X-Received: by 2002:ab0:250c:: with SMTP id j12mr2960806uan.113.1586525005740; Fri, 10 Apr 2020 06:23:25 -0700 (PDT) MIME-Version: 1.0 References: <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <229AAF4A-C43F-46E9-97C6-99CC124E9B48@gmail.com> <20200409212841.GK28965@faui48f.informatik.uni-erlangen.de> <0A15B52E-2A67-4D6A-AACF-8A92FB67ADEC@gmail.com> In-Reply-To: <0A15B52E-2A67-4D6A-AACF-8A92FB67ADEC@gmail.com> From: Uma Chunduri Date: Fri, 10 Apr 2020 06:23:32 -0700 Message-ID: To: Tony Li Cc: Toerless Eckert , architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="00000000000064fd4805a2efa3a5" Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 10 Apr 2020 13:23:31 -0000 --00000000000064fd4805a2efa3a5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > > It shouldn=E2=80=99t be. Today=E2=80=99s hardware is enormously capable = and continues to > grow aggressively (thank you Gordon Moore). > > It would be backwards to let hardware limitations constrain the > architecture. Instead, the hardware will always grow to what is needed b= y > the architecture. > > That said, that=E2=80=99s no excuse to create enormously wasteful archite= ctures. > Resources are not free. Waste not, want not. > I can't agree more. > --00000000000064fd4805a2efa3a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

It shouldn=E2=80=99t be.=C2=A0 Today=E2=80=99s hardware is enormously capab= le and continues to grow aggressively (thank you Gordon Moore).

It would be backwards to let hardware limitations constrain the architectur= e.=C2=A0 Instead, the hardware will always grow to what is needed by the ar= chitecture.

That said, that=E2=80=99s no excuse to create enormously wasteful architect= ures.=C2=A0 Resources are not free. Waste not, want not.

I can't agree more.=C2=A0


--00000000000064fd4805a2efa3a5-- From nobody Fri Apr 10 07:57:00 2020 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 3DDDD3A0BF1 for ; Fri, 10 Apr 2020 07:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PDS_OTHER_BAD_TLD=1.989, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fyber.space 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 fhqrhkowE6Ll for ; Fri, 10 Apr 2020 07:56:57 -0700 (PDT) Received: from mail.fyber.space (mail.fyber.space [78.47.154.76]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BECA13A0BF0 for ; Fri, 10 Apr 2020 07:56:57 -0700 (PDT) Received: from mail.intra.fyber.space (mail.fyber.space [127.0.0.1]) by mail.fyber.space (Postfix) with ESMTP id 48zLh73526zX9N for ; Fri, 10 Apr 2020 14:56:55 +0000 (UTC) Authentication-Results: mail.intra.fyber.space (amavisd-new); dkim=pass (1024-bit key) reason="pass (just generated, assumed good)" header.d=fyber.space DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fyber.space; h= content-transfer-encoding:content-language:content-type :in-reply-to:mime-version:user-agent:date:message-id:from:to :references:subject; s=dkim; t=1586530614; x=1589122615; bh=2k6W ge/v1o8RJSiqK50r1pbt+xG/xAYTdrz8+ERvOmo=; b=IpxIGBg3z/QwJKxHugRz 6FzjULJPeQ7mDs4wYwGmfDp9AcZsAsEPYVE7Cckvk1WqFmUxpjHf6hDkpm3t6xB+ HsQTx99LpIYB2xEJBdPEwlYAzvRULWr/4jNSWG6JZRxAVCEUXNL8rzOVUTAxpLDj FBL9+HAeXTe5UlcKFuZFu5E= X-Virus-Scanned: Debian amavisd-new at mail.intra.fyber.space Received: from mail.fyber.space ([127.0.0.1]) by mail.intra.fyber.space (mail.intra.fyber.space [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id AfP-2w3UhUHc for ; Fri, 10 Apr 2020 14:56:54 +0000 (UTC) Received: from [IPv6:2001:a62:4e3:b501:6873:5414:dc7a:67b4] (unknown [IPv6:2001:a62:4e3:b501:6873:5414:dc7a:67b4]) by mail.fyber.space (Postfix) with ESMTPSA id 48zLh63NrDzX9C for ; Fri, 10 Apr 2020 14:56:54 +0000 (UTC) References: <98d43782-6543-b473-6a3c-dc6fe0e4de7d@v-tr.org> <869472A7-EF3E-4CC2-8ACE-0196E8B10504@puck.nether.net> To: architecture-discuss@ietf.org From: =?UTF-8?Q?Vincent_Truchse=c3=9f?= Message-ID: <688f5250-c8f6-765b-a51a-b931b76e6d65@v-tr.org> Date: Fri, 10 Apr 2020 16:57:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <869472A7-EF3E-4CC2-8ACE-0196E8B10504@puck.nether.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [arch-d] Mail Etiquette 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, 10 Apr 2020 14:56:59 -0000 Hi, > It=E2=80=99s often unknown who is behind an alias and then participants= in the thread will get copied on replies. This can often lead to them s= eeing the reply before the list runs and gets data out to the others. >=20 > Mailing list software also has the option to disable people getting the= e-mail who send it (eg: mailman it=E2=80=99s called the [metoo] setting)= . =20 >=20 > People like myself tend to run procmail on the server side which filter= /weed out duplicates so I don=E2=80=99t see two copies. Your mail client= may also silently suppress them as well. >=20 > It=E2=80=99s also helpful to know that your message did make it to the = list vs being silently held out there. (Think of e-mail back in the UUCP= days, when it may take 8-24h to have something flow through and a bit mo= re to flow-back). >=20 > - Jared >=20 Automated sorting becomes a pain if the list's address is sometimes in To, sometimes in Cc and whatnot. Also, those duplicates like to appear in different folders making it difficult to track threats. Anything against simply replying to the list instead? It makes subscribing to a list without manually editing sieve-filters much more pleasurable. YT, VT. From nobody Fri Apr 10 10:17:08 2020 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 A08F93A0A20 for ; Fri, 10 Apr 2020 10:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.383 X-Spam-Level: X-Spam-Status: No, score=-0.383 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_RHS_DOB=1.514] 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 q3mvEooXLl7W for ; Fri, 10 Apr 2020 10:17:04 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15CFE3A09D8 for ; Fri, 10 Apr 2020 10:17:04 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jMxH1-000GOm-Ig; Fri, 10 Apr 2020 13:16:59 -0400 Date: Fri, 10 Apr 2020 13:16:53 -0400 From: John C Klensin To: =?UTF-8?Q?Vincent_Truchse=C3=9F?= , architecture-discuss@ietf.org Message-ID: In-Reply-To: <688f5250-c8f6-765b-a51a-b931b76e6d65@v-tr.org> References: <98d43782-6543-b473-6a3c-dc6fe0e4de7d@v-tr.org> <869472A7-EF3E-4CC2-8ACE-0196E8B10504@puck.nether.net> <688f5250-c8f6-765b-a51a-b931b76e6d65@v-tr.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [arch-d] Mail Etiquette 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, 10 Apr 2020 17:17:07 -0000 --On Friday, April 10, 2020 16:57 +0200 Vincent Truchse=C3=9F wrote: > Automated sorting becomes a pain if the list's address is > sometimes in To, sometimes in Cc and whatnot. Also, those > duplicates like to appear in different folders making it > difficult to track threats. Vincent, these are really local problems of how things are filtered and organized, not ones that are easy to solve, or even make recommendations about, globally. FWIW, even if you don't copy the sender, similar problems occur when, for good reason, something is cross-posted to multiple lists. > Anything against simply replying to the list instead? > It makes subscribing to a list without manually editing > sieve-filters much more pleasurable. I think the first of these has already been mentioned: (1) The IETF allows IETF participants who are not subscribers to post to a particular list. This, and copying more than one list, are particularly important during IETF Last Calls or WG tentative decisions are announced on the IETF list in the hope of getting cross-area review. In some of those cases, the author or a response may not actual be on the relevant list. If you respond to such a comment/response, the author of that response, unless copied explicitly, may never see what you had to say. (2) When we get very busy, some (certainly not all) of us may prioritize reading messages addressed to us (in either "To:" or "Cc:" header fields) over messages addressed only to one or more mailing lists. So, again, if you want your comments on a message to be seen as soon as possible by the author of the one to which you are responding, it may be in your interest to go ahead and explicitly include that author among the addressees. That said, the reality is that different of us follow different conventions, sometimes not even being consistent about that on a given day. You will see the same thing with decisions as to whether to write responses inline with a copy of the original message or to make one's comments at the top. There is no fixed rule and people seem to do what they thing best and everyone just learns to cope.=20 welcome to the IETF. john From nobody Fri Apr 10 13:32:32 2020 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 D04C73A0CCA for ; Fri, 10 Apr 2020 13:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jydtPHFXanfE for ; Fri, 10 Apr 2020 13:32:29 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 92CE43A0CD1 for ; Fri, 10 Apr 2020 13:32:29 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id a13so1499331pfa.2 for ; Fri, 10 Apr 2020 13:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=30EUhWoOP91z/ovejx9kFUEPTd6HASP2xFCVLdE/8kY=; b=Qfe+MAAJereQVH9jVfrnFiFVdJlBXNaA6BOzsF/CeK9rArqb/0z/1AHd642xld2+Sm PzphHWEfJVAjEydfHeZWQAH67VorR0YBY5BCcuNJqfqY9xI1AfwO1aTgMPJghOyVDjTQ 9Z3o/JOXAKOyTr1VCTYIjYSBXZbNZl4bVmw6Oo7or2MsDhh38woTegWaRGluk59yK6y1 FmKijZ+X5xy/vC5yWl66O68RJJrNINpODfWx/ZOznASrfRdr/Wh08YqBhFJdSRlJLcAD xsl1nSi4vdiXBoKH/MErQ2rqQB+5lQuNbASuOjKeXIT0F9ej0QuTphmJYmmiIVtIL4J2 TR1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=30EUhWoOP91z/ovejx9kFUEPTd6HASP2xFCVLdE/8kY=; b=c3qa8I3PhnIOAts7x2MVXUp4K2gkQ6C+jM5Fm2WD/Tc2n5Z7Y8ECqqZ9eFxH3RGJYd H47bQIDbQ+m1KTr+KaQNsTKEKBYyywntRxVa/jgw0uZcNLKAoJPRy1RIimT5n8wm5oxg FnkO1YyZeelgA8QaV7c05eEEFaq1yOWEvZJAFCDmAtOCPmv60v23Y6zS8DgPrRsBSIdN sIhhu5hcr8/S2au7PAZj3x2xzmhskRx1fbLm8t+/nYsPoBDB4c0Cvg1V62bA3MpIY9Lh BajZpOA7e7stWzGayzkrTwtg/3IOjgiK5iN7/bLteiV73n9BgClvXs59MJDoCGPmGdYZ Ix+A== X-Gm-Message-State: AGi0PuY3QuVcuQaMQ2EyXTYDS9b80yejcWxcgzP7TTJmLg3Lvio2tBb/ auzmDj5fqBcFNZv4fl5RNtX4u82k X-Google-Smtp-Source: APiQypJlPL6PILIM4Uv4399/leVQla14kdvaTCambgEVfsyR0XMX0uOS43WjGEqC06Z9/VS0M5+r+w== X-Received: by 2002:a62:3888:: with SMTP id f130mr6475108pfa.141.1586550748535; Fri, 10 Apr 2020 13:32:28 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id d23sm2470819pfq.210.2020.04.10.13.32.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Apr 2020 13:32:28 -0700 (PDT) To: John C Klensin , =?UTF-8?Q?Vincent_Truchse=c3=9f?= , architecture-discuss@ietf.org References: <98d43782-6543-b473-6a3c-dc6fe0e4de7d@v-tr.org> <869472A7-EF3E-4CC2-8ACE-0196E8B10504@puck.nether.net> <688f5250-c8f6-765b-a51a-b931b76e6d65@v-tr.org> From: Brian E Carpenter Message-ID: <563a6f12-e1fe-b64d-4b4d-c52958807c1a@gmail.com> Date: Sat, 11 Apr 2020 08:32:23 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 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] Mail Etiquette 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, 10 Apr 2020 20:32:31 -0000 Vincent, I tend to use Reply All by default to avoid interested recipients being missed. A lot of IETF discussions end up cross-posted to multiple WGs or even being switched to a different WG, so those extra CCs can be important. There's a catch in Reply All though: if you forget to delete (say) ietf-announce@ietf.org, that's a guaranteed annoying bounce message. With mailman lists, you can suppress duplicates in your personal config, with the "Avoid duplicate copies of messages?" option: "When you are listed explicitly in the To: or Cc: headers of a list message, you can opt to not receive another copy from the mailing list. Select Yes to avoid receiving copies from the mailing list; select No to receive copies." There's also the "Receive your own posts to the list?" option. On 11-Apr-20 05:16, John C Klensin wrote: ... > That said, the reality is that different of us follow different > conventions, sometimes not even being consistent about that on a > given day. You will see the same thing with decisions as to > whether to write responses inline with a copy of the original > message or to make one's comments at the top. There is no > fixed rule and people seem to do what they thing best and > everyone just learns to cope. Indeed. Wrapped text or hard returns? With hard returns, line length? Worst of all, HTML instead of text/plain. Sometimes, not even charset=utf-8. Different quoting and commenting methods; some people even rely on colour (which they probably spell "color"). It would be a brave person who tried to write down the best practice. > welcome to the IETF. +1 Stay well, Brian From nobody Fri Apr 10 13:36:43 2020 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 8BCDF3A0CDD for ; Fri, 10 Apr 2020 13:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.338 X-Spam-Level: X-Spam-Status: No, score=-0.338 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_RHS_DOB=1.514] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=PAA83xa6; dkim=pass (1536-bit key) header.d=taugh.com header.b=sq++/xRb 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 NsMLrcciwdIR for ; Fri, 10 Apr 2020 13:36:40 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 8EE2A3A0CE0 for ; Fri, 10 Apr 2020 13:36:40 -0700 (PDT) Received: (qmail 19357 invoked from network); 10 Apr 2020 20:36:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=4b9b.5e90d8d7.k2004; bh=/chhtzyWjUr6A08qenLsfK6dhCgzXR1j7T+zD5Zftbg=; b=PAA83xa6S5VBzTnKQTGoCuPImJWrs+WYzOySREWjc9Ax0QggLU1GWFTnYoimeJjAyscx9f22ji7J88CTw8LOQ7J8EoK2pvPlJtaloExxDOaCS+ghV5jG/L7n7ep+OjpkAkspBPEFAjXYbtgNRbPkXqjpi3cYEqphFhgVzuknmW4mL9Q0m6PRlLm+u+fKOw/aKo0Dw3bA3ZfjuWet3aoLH8t2SiLnsarYxmC9Ncu5hy3b1RdAFS9wMq7MvHEuTs6x DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=4b9b.5e90d8d7.k2004; bh=/chhtzyWjUr6A08qenLsfK6dhCgzXR1j7T+zD5Zftbg=; b=sq++/xRbKQPhpZSBQdixfFzO4HoiKDrLY2O6dNHMZr9ICKNgqPSZlEbQRAOxYvNpzg66rlw+p5a5ZWmkIg2wqhvJqq8c4/nlebAzH9JpXdBC5kketbHGURz1nwdRvcQgiBJOsd+/3JbXq/LOmrSxWQauiOZO6bEWSQhydn9tcj2aO5MyUI3uPUvwzID3VdUzICiZ8XpnroqZW4XTIKNzr1E139Ie70w54jlLfDSoyLvK8i1NoPybOQkFtcG1KP8a Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 10 Apr 2020 20:36:38 -0000 Received: by ary.qy (Postfix, from userid 501) id D248A176CB88; Fri, 10 Apr 2020 16:36:38 -0400 (EDT) Date: 10 Apr 2020 16:36:38 -0400 Message-Id: <20200410203638.D248A176CB88@ary.qy> From: "John Levine" To: architecture-discuss@ietf.org In-Reply-To: <688f5250-c8f6-765b-a51a-b931b76e6d65@v-tr.org> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [arch-d] Mail Etiquette 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, 10 Apr 2020 20:36:43 -0000 In article <688f5250-c8f6-765b-a51a-b931b76e6d65@v-tr.org> you write: >Automated sorting becomes a pain if the list's address is sometimes in >To, sometimes in Cc and whatnot. Also, those duplicates like to appear >in different folders making it difficult to track threats. Messages sent through IETF lists all have a List-ID header. That's what you sort on. Works great. >Anything against simply replying to the list instead? As John K said, there's a great deal of history here and reasons that people do what they do. It's not that hard to adjust your mail handling to match what we all do, and rather quixotic to expect people to change 30 years of practice across hundreds of lists. R's, John From nobody Fri Apr 10 14:40:33 2020 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 309EB3A0DF5 for ; Fri, 10 Apr 2020 14:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.514 X-Spam-Level: * X-Spam-Status: No, score=1.514 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_RHS_DOB=1.514] 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 55afMyXqqtRO for ; Fri, 10 Apr 2020 14:40:30 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 32D4F3A0DF2 for ; Fri, 10 Apr 2020 14:40:30 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jN1O0-0001dK-8R; Fri, 10 Apr 2020 21:40:28 +0000 Date: Fri, 10 Apr 2020 14:40:24 -0700 Message-ID: From: Randy Bush To: "John Levine" Cc: architecture-discuss@ietf.org In-Reply-To: <20200410203638.D248A176CB88@ary.qy> References: <688f5250-c8f6-765b-a51a-b931b76e6d65@v-tr.org> <20200410203638.D248A176CB88@ary.qy> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) 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] Mail Etiquette 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, 10 Apr 2020 21:40:32 -0000 > In article <688f5250-c8f6-765b-a51a-b931b76e6d65@v-tr.org> you write: thanks for demonstrating another feature of leaving the OP in the reply header randy From nobody Fri Apr 10 14:48:04 2020 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 B9C873A0E0C for ; Fri, 10 Apr 2020 14:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PDS_OTHER_BAD_TLD=1.989, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fyber.space 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 YTTDjCrwwGeH for ; Fri, 10 Apr 2020 14:48:02 -0700 (PDT) Received: from mail.fyber.space (mail.fyber.space [IPv6:2a01:4f8:c0c:4314:100::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 151763A0E0B for ; Fri, 10 Apr 2020 14:48:01 -0700 (PDT) Received: from mail.intra.fyber.space (mail.fyber.space [127.0.0.1]) by mail.fyber.space (Postfix) with ESMTP id 48zWpS2K64zXRP for ; Fri, 10 Apr 2020 21:48:00 +0000 (UTC) Authentication-Results: mail.intra.fyber.space (amavisd-new); dkim=pass (1024-bit key) reason="pass (just generated, assumed good)" header.d=fyber.space DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fyber.space; h= content-transfer-encoding:content-language:content-type :in-reply-to:mime-version:user-agent:date:message-id:from :references:to:subject; s=dkim; t=1586555279; x=1589147280; bh=c 9O9RqeVuif2jHBa24Mlgjoi82SmtM4RWLjfZetqMGY=; b=7YcXMlBRd/GS3dry2 h325F46KP5eNrV9MH8KCxZ9lRIVfnW4dkboHk+aOITj3opOUDMfcNEDasSeNylUO jA1MkH/0hbSm+SA7KmTAOeYq1QcZ32m7o3RqvPM5ULgF/X/bQjZghL9TzHpmCeLB uEsjBZ9nmhAXJQq9i+TrWmA7bw= X-Virus-Scanned: Debian amavisd-new at mail.intra.fyber.space Received: from mail.fyber.space ([127.0.0.1]) by mail.intra.fyber.space (mail.intra.fyber.space [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DxcOk42B13Kn for ; Fri, 10 Apr 2020 21:47:59 +0000 (UTC) Received: from [IPv6:2001:a62:4e3:b501:6873:5414:dc7a:67b4] (unknown [IPv6:2001:a62:4e3:b501:6873:5414:dc7a:67b4]) by mail.fyber.space (Postfix) with ESMTPSA id 48zWpR4ng7zXRB; Fri, 10 Apr 2020 21:47:59 +0000 (UTC) To: John Levine , architecture-discuss@ietf.org References: <20200410203638.D248A176CB88@ary.qy> From: =?UTF-8?Q?Vincent_Truchse=c3=9f?= Message-ID: Date: Fri, 10 Apr 2020 23:48:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200410203638.D248A176CB88@ary.qy> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] Mail Etiquette 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, 10 Apr 2020 21:48:04 -0000 > Messages sent through IETF lists all have a List-ID header. That's > what you sort on. Works great. Thanks for the tip. And sorry if my initial mail sounded like a complaint. I was just about the local customs. - Vincent From nobody Fri Apr 10 17:22:54 2020 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 5AFA53A135B for ; Fri, 10 Apr 2020 17:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 KCTU0x_P6lxL for ; Fri, 10 Apr 2020 17:22:52 -0700 (PDT) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 2E4B13A135A for ; Fri, 10 Apr 2020 17:22:51 -0700 (PDT) Received: from xse350.mail2web.com ([66.113.197.96] helo=xse.mail2web.com) by mx168.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1jN3v6-000AoQ-Dd for architecture-discuss@ietf.org; Sat, 11 Apr 2020 02:22:50 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 48zbF30rh0z3Lny for ; Fri, 10 Apr 2020 17:22:47 -0700 (PDT) Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jN3v5-0001o6-06 for architecture-discuss@ietf.org; Fri, 10 Apr 2020 17:22:47 -0700 Received: (qmail 11320 invoked from network); 11 Apr 2020 00:22:46 -0000 Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.58.46.206]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 11 Apr 2020 00:22:46 -0000 To: Brian E Carpenter Cc: architecture-discuss@ietf.org References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> From: Christian Huitema 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: <4ac9e9fc-41a3-f458-566e-f0a68d26d9ea@huitema.net> Date: Fri, 10 Apr 2020 17:22:48 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: 66.113.197.96 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.63) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0VxB0mWeGZk2wSOLROvd+japSDasLI4SayDByyq9LIhVrxO5yLhB/vtQ lev0pUEF+0TNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDsYLBcJLyHnVrULITPs15U6ts NHuRxlWqWR9fNqLY1ai4Dcwf+CZK8NXgy3In+fX7HgpyfDDTpYxM86VYrcNQelO05s+oip5EC/YK rMQ9+O9t+TYaqvvx766D6vBkj4PutP0Dzal8myJ8vVhoWnSKP2MRQY4sL7fGBhvCp6oW0F28pnvZ XWSe7jV34Pxn0vH1Lz/y+awqhw7CmTPsWtYsCV/oEQh3zFZ7AJOfdc5NLopVCPmS+MVojfDUugvn Zl+jhHQOLtWk4clq0P6Ltvr/5Zl+BJt+8hYKwgejR0Z9YPn97p3CKmEi95YYeXPNWMiahaC2TJpF rGrq1WX76kTmg5w7R2/M+XaT5BLifEp8KpWu41J1t4cteGI4vH6PuMQp0kaOEXLuWd+6zLg4wp8u XxPcpGyeyPXKNTABBN67jV7JvFCbAD7w3FUirQwmJIqD2OUMeHyTpNN0eXybX/w7/3ZCM0u5uBlK VwmNWN494pWaZ30sdVozPGNttYaP6Q9/2E4JvzZwv3PGBEOc6AcTtJtRtJoQDVceXxku57M+ylKe mCc5i959HofBoQchlXIK7+aVm/NqgKA5dyCxkhdL5g7yNAxIoTne18wgCHBWXWNdeu+6D1xe6+c7 Ft92TZYqm6tYkEIaKUMagHVttkVduFTHxy0eEBhPVsxSyJqntVQ8wFz1NVLwsiExbNgDC9D6rXc2 UgPIHgu7jfmEB0kulRxwEiTVJqDh0qKoKsXx5ln2SMMcYcLzHFodDBnL1LUIELntCCboMzjU4pY3 22r5vNbxIx8r0tkGYkfgGWL38RL2RSrvmTNpgdQqU4ccmgaW3jR5NeVaJQBh0uawl0Cg8gkFJY4U lg4VofOxwUi4TVKOKogdFzFUBtke4lHzswE2heUd4UCZPAsMlEWCkNGHtIkd2x35zAiBFPp64JaI ysCWp33KKvSLEepfzmW/VTBD X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 11 Apr 2020 00:22:53 -0000 On 4/9/2020 2:08 PM, Brian E Carpenter wrote: > Actually, I disagree. IPv6 is a very conservative design that had > exactly no effect on fundamentals. That was intentional. Remember > TUBA (TCP and UDP over Bigger Addresses)? That's what we did, > with the tiny detail of using homebrew IPv6 instead of ISO8473. > What we learned is that even a minor step like bigger addresses is > expensive *because of the even more tiny details* like the socket > API, router CLI commands, and the address configuration mechanism. > > The major lower-layer atchitecture change in the last 30 years > was completely unplanned: middleboxes. The post-2013 general deployment of encryption is a pretty big change too. It was only partially planned. And if QUIC comes to displace TCP, that too would be a significant change. -- Christian Huitema From nobody Mon Apr 13 11:56:43 2020 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 E55F83A1C2F for ; Mon, 13 Apr 2020 11:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 KLlpRJFvkiEB for ; Mon, 13 Apr 2020 11:56:40 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A5983A1C2E for ; Mon, 13 Apr 2020 11:56:40 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jO4G4-0003hj-Kr; Mon, 13 Apr 2020 14:56:36 -0400 Date: Mon, 13 Apr 2020 14:56:30 -0400 From: John C Klensin To: Christian Huitema , Brian E Carpenter cc: architecture-discuss@ietf.org Message-ID: In-Reply-To: <4ac9e9fc-41a3-f458-566e-f0a68d26d9ea@huitema.net> References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <4ac9e9fc-41a3-f458-566e-f0a68d26d9ea@huitema.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 13 Apr 2020 18:56:42 -0000 --On Friday, April 10, 2020 17:22 -0700 Christian Huitema wrote: > On 4/9/2020 2:08 PM, Brian E Carpenter wrote: > >> Actually, I disagree. IPv6 is a very conservative design that >> had exactly no effect on fundamentals. That was intentional. >> Remember TUBA (TCP and UDP over Bigger Addresses)? That's >> what we did, with the tiny detail of using homebrew IPv6 >> instead of ISO8473. What we learned is that even a minor step >> like bigger addresses is expensive *because of the even more >> tiny details* like the socket API, router CLI commands, and >> the address configuration mechanism. >> >> The major lower-layer atchitecture change in the last 30 years >> was completely unplanned: middleboxes. > > The post-2013 general deployment of encryption is a pretty big > change too. It was only partially planned. And if QUIC comes > to displace TCP, that too would be a significant change. It may also be worth noting that a, perhaps the, major add-on change in IPv6 --much touted in its early days-- was supposed to be ubiquitous lP-level encryption. That post-2013 encryption deployment, at least AFAICT, relies on methods much closer to the applications layer, sometimes ones that are at least partially specific to particular applications and applications protocols. If there is a message in those things, I think it is either that we are not good at predicting which of our innovations will be successful and which will not or that, when the IETF says "go forth and do X", thee are no guarantees that the world will listen. And I expect it will be some years more before we actually know whether our more recent push toward encryption has helped the Internet and its users by increasing privacy or whether pushback and reactions from the political and law enforcement sectors ultimately result in fragmentation, large-scale interconnection problems, and the either development of a lot of ad hoc solutions or movement of work to other SDOs because the IETF was too stuck on the importance of encryption no matter what. I don't predict that outcome and definitely don't wish for it, but I think our architectural work would be improved by more recognition of the possibility. best, john From nobody Thu Apr 16 03:43:17 2020 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 0B0403A1415 for ; Thu, 16 Apr 2020 03:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=open-xchange.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 nGZd69YdOx64 for ; Thu, 16 Apr 2020 03:43:12 -0700 (PDT) Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 2B6753A1416 for ; Thu, 16 Apr 2020 03:43:11 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id A0A0B6A273; Thu, 16 Apr 2020 12:43:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1587033789; bh=wM7omCpkOi3osSRdHWOFkLNUYAgoPlu8PNQfuUDnD4M=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=X3T4e+1fp0qO4oSnQr4Psy3qe/VT7f3oEa5keprlKxlFKJH7uSwpptKTENPdDqJVd irUokEOoCz8goOcw3PPB9+Y545XrRcf0jPZoVgS/oMRirHz46aHBci+/Eyl3A3QaeD IIlpcoHd6J8EtWk4LN6KrGSd3/LhargCETO5HSC7wioZCvB1tsOn3esV6XUNKfxFlC BCcXKfLv/X5vf0Xglx1KhJn7WnEukvJRJVGvzw3TNjUyHHhEhB2ObDwzIIzuptjMQO SdDNUCBxbsdkB4v8dhEONWNdXRGXTZDQhOlVW9bn4fNshW8luz26t7O/Z9KwJy0ZTA ODbPQtIoDut/Q== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 91E4A3C0425; Thu, 16 Apr 2020 12:43:09 +0200 (CEST) Date: Thu, 16 Apr 2020 12:43:09 +0200 (CEST) From: Vittorio Bertola To: John C Klensin Cc: architecture-discuss@ietf.org Message-ID: <480966587.17396.1587033789496@appsuite-gw2.open-xchange.com> In-Reply-To: References: <60a10451-5fbd-fcec-5389-7a72870dcc84@gmail.com> <6A3A4410-A889-46C7-8FD5-7C5AA85486A1@tzi.org> <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <4ac9e9fc-41a3-f458-566e-f0a68d26d9ea@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev8 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 16 Apr 2020 10:43:15 -0000 > Il 13/04/2020 20:56 John C Klensin ha scritto: > > If there is a message in those things, I think it is > either that we are not good at predicting which of our > innovations will be successful and which will not or that, when > the IETF says "go forth and do X", thee are no guarantees that > the world will listen. Incidentally, the attempted discussion on the relationship between the IETF and non-technical, policy-oriented stakeholders would also be pertinent to this. Sometimes, the world seems not to have listened (or even actively resisted) because what the IETF did was not aligned with non-technical incentives, or was affecting some other stakeholders too negatively. > And I expect it will be some years more before we actually know > whether our more recent push toward encryption has helped the > Internet and its users by increasing privacy or whether pushback > and reactions from the political and law enforcement sectors > ultimately result in fragmentation, large-scale interconnection > problems, and the either development of a lot of ad hoc > solutions or movement of work to other SDOs because the IETF was > too stuck on the importance of encryption no matter what. I > don't predict that outcome and definitely don't wish for it, but > I think our architectural work would be improved by more > recognition of the possibility. Or, in general, by having a dialogue in advance with the rest of the Internet community on this kind of far-reaching change, so that the resulting non-technical issues are at least understood properly, and possibly taken into account in the design; and an alignment of interests can be created to promote the change. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Thu Apr 16 10:48:50 2020 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 57EB63A09D9 for ; Thu, 16 Apr 2020 10:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 UKp8N3Tn-w9c for ; Thu, 16 Apr 2020 10:48:47 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF6173A09D6 for ; Thu, 16 Apr 2020 10:48:46 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B36D7548045; Thu, 16 Apr 2020 19:48:40 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id ACFE5440055; Thu, 16 Apr 2020 19:48:40 +0200 (CEST) Date: Thu, 16 Apr 2020 19:48:40 +0200 From: Toerless Eckert To: John C Klensin Cc: Christian Huitema , Brian E Carpenter , architecture-discuss@ietf.org Message-ID: <20200416174840.GL41264@faui48f.informatik.uni-erlangen.de> References: <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <4ac9e9fc-41a3-f458-566e-f0a68d26d9ea@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 16 Apr 2020 17:48:50 -0000 On Mon, Apr 13, 2020 at 02:56:30PM -0400, John C Klensin wrote: > It may also be worth noting that a, perhaps the, major add-on > change in IPv6 --much touted in its early days-- was supposed to > be ubiquitous lP-level encryption. Indeed. It is almost puzzling to think that end-to-end encryption at IP(sec) level was presumed to be a good architectural choice. Besides the obvious beneeit of being agnostic to transport protocol choices but then failing on ever getting a host stack model that would allow applications to leverage it easily. Of couse, luckily we have it (IPsec) as there are a lot of other good use cases for it. Maybe a bit too much of the "one size fits all" syndrom that new technologies by sheer self interest always come to presume ? > That post-2013 encryption > deployment, at least AFAICT, relies on methods much closer to > the applications layer, sometimes ones that are at least > partially specific to particular applications and applications > protocols. If there is a message in those things, I think it is > either that we are not good at predicting which of our > innovations will be successful and which will not or that, when > the IETF says "go forth and do X", thee are no guarantees that > the world will listen. Well, i think IPsec was an example of things working well in IETF. They may have overexpected on the range of where it best fits (and can be completed by host stack/APIs, which always is the worst dependency of any IETF work), but they (IPsec) folks AFAIK never tried to stop TLS with arguments like "we must only have one protocol" or the like, one of the negative syndroms we have IMHO seen for othre protocols in the IETF. But nothing the IETF can really do. Just comes when its participants develop a particular protocol religion or know how their jobs may depend on a specific protocol. > And I expect it will be some years more before we actually know > whether our more recent push toward encryption has helped the > Internet and its users by increasing privacy or whether pushback > and reactions from the political and law enforcement sectors > ultimately result in fragmentation, large-scale interconnection > problems, and the either development of a lot of ad hoc > solutions or movement of work to other SDOs because the IETF was > too stuck on the importance of encryption no matter what. I > don't predict that outcome and definitely don't wish for it, but > I think our architectural work would be improved by more > recognition of the possibility. If i limit your "encryption to "(TLS) end-to-end encryption", then i think there are already a lot of people that have opinions about the results even visible today. IMHO, TLS has two main neglected consequences: It has become the key component of a strategy for revenue supremacy from one part of the industry, and it has moved the bad behavior (perpass and its revenue tail) into a layer of the solution (application) where it is out of the control of the IETF. Or at least out of the scope of interest of the companies shaping the IETF standards in that space because they are the beneficiaries of this evolution. So, the next round of privacy discussion as we already see will mostly be happening outside the IETF. For better or worse. This is of course non-withstanding the basic necessities to use TLS and its benefits. Cheers Toerless > best, > john > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Thu Apr 16 14:17:21 2020 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 1995F3A116B for ; Thu, 16 Apr 2020 14:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJaOY6s7spFX for ; Thu, 16 Apr 2020 14:17:11 -0700 (PDT) Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444]) (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 3B8AF3A1132 for ; Thu, 16 Apr 2020 14:17:11 -0700 (PDT) Received: by mail-pf1-x444.google.com with SMTP id b8so2240418pfp.8 for ; Thu, 16 Apr 2020 14:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=EfTGXBUCGzz4eD7oREZhez1olPIQ3UMaSLNmCTdF7Qo=; b=uZrBo6uACyXT2hCSEfNVarikZDQwCd4pv9E+xtcAdIKSKLIa8SZ1ngR1k0LULkyB4u vEqVfcCVe0sYvx/FE+eZUJ82Z2H5iyD+pD8l74kDA5pwkEOqd6WSRqcSddTAn7slRm7P VTF2KDrTyQi6dV83gxX15Lk4vsCNNV68Gpj6OmURlLkt5rYEvAkVbxuOwZQB9Cc6ytv+ GPYuEmzhHnfSnIwJEZq7EnyeQypoJDnfD7YUgBhBeMalCIy0qrIXfeveN8do6JZpuFiu MQEsEuyEElXKTy1NrCLFeaITyvbjo3wwDNV6KAh3OzuNDsmfRfT1fwFfuz/fzqwOmWUg IXvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=EfTGXBUCGzz4eD7oREZhez1olPIQ3UMaSLNmCTdF7Qo=; b=IiGeB8NYTEajUawIAQPsXUTvp85+URIc8A/azuBIPxkNhKtTDHfHsLiBw1lttHl0mE x/7qs8hkOeFLZJNuFmIBw7whx0nH/X1XprhcV32qqtf4qyoAG6R+XZI4EBHWkXIP7P1O KwDvwdHLyn9Om6lWDRoNlNASelE9neHyueNciTCQ23Tu86FNhQm+i+AD0x2Lu51FX2mQ SmBl7dF7YHHVoq0m58/CEpqlrLRjUrjKqHaJq/LqW2Dx+mwyb8WV0Upw6ksCkOvh++LR TxbjMOtHGz3iRGfUA/CoWspPm2UcNiCZBw3Ul6WnXD1syiecQLn8qqRiCMj9Le1H6yc0 Z0jA== X-Gm-Message-State: AGi0PubK6TESkRD38j/g1WbX1NmIKDn6Y0St5yFWyS75nuNmxMkEhm6H OlQI3Y0y5vKOv7MAm0kk8IPHFmCV X-Google-Smtp-Source: APiQypKPx7mfxFjqdDDxiSxZQ2wBO9Xw4eDwHqCyR3SeuPMs78CW/9G8OzfYwq0HQcXJJq2xIdN7ug== X-Received: by 2002:a63:1853:: with SMTP id 19mr26035085pgy.108.1587071829390; Thu, 16 Apr 2020 14:17:09 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id j24sm3471199pji.20.2020.04.16.14.17.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Apr 2020 14:17:08 -0700 (PDT) To: Toerless Eckert , John C Klensin Cc: Christian Huitema , architecture-discuss@ietf.org References: <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <4ac9e9fc-41a3-f458-566e-f0a68d26d9ea@huitema.net> <20200416174840.GL41264@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: <96ea575b-78d5-019d-15b2-abc8e5c8b22e@gmail.com> Date: Fri, 17 Apr 2020 09:17:05 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20200416174840.GL41264@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 16 Apr 2020 21:17:19 -0000 On 17-Apr-20 05:48, Toerless Eckert wrote: > On Mon, Apr 13, 2020 at 02:56:30PM -0400, John C Klensin wrote: >> It may also be worth noting that a, perhaps the, major add-on >> change in IPv6 --much touted in its early days-- was supposed to >> be ubiquitous lP-level encryption. Not touted by the IPv6 protagonists, however. Yes, there was an intention to make IPsec mandatory-to-implement, but there was never a claim from the IETF that IPv6 with IPsec was intrinsically more secure than IPv4 with IPsec. The claim that IPv6 was intrinsically secure was indeed touted; if I'm not mistaken it orginated in an industry white paper, was picked up and exagerrated by the IPv6 Forum, and got into draft-ietf-iab-case-for-ipv6-00, (which led to draft-iab-case-for-ipv6-06 and was then scrapped). But it also featured in various lists of IPv6 Myths over many years. Brian > Indeed. It is almost puzzling to think that end-to-end > encryption at IP(sec) level was presumed to be a good > architectural choice. Besides the obvious beneeit of being > agnostic to transport protocol choices but then failing on > ever getting a host stack model that would allow applications > to leverage it easily. Of couse, luckily we have it (IPsec) > as there are a lot of other good use cases for it. > Maybe a bit too much of the "one size fits all" syndrom that > new technologies by sheer self interest always come to presume ? > >> That post-2013 encryption >> deployment, at least AFAICT, relies on methods much closer to >> the applications layer, sometimes ones that are at least >> partially specific to particular applications and applications >> protocols. If there is a message in those things, I think it is >> either that we are not good at predicting which of our >> innovations will be successful and which will not or that, when >> the IETF says "go forth and do X", thee are no guarantees that >> the world will listen. > > Well, i think IPsec was an example of things working well in IETF. > They may have overexpected on the range of where it best > fits (and can be completed by host stack/APIs, which always is > the worst dependency of any IETF work), but they (IPsec) folks > AFAIK never tried to stop TLS with arguments like "we must only > have one protocol" or the like, one of the negative syndroms we > have IMHO seen for othre protocols in the IETF. But nothing > the IETF can really do. Just comes when its participants develop > a particular protocol religion or know how their jobs may depend > on a specific protocol. > >> And I expect it will be some years more before we actually know >> whether our more recent push toward encryption has helped the >> Internet and its users by increasing privacy or whether pushback >> and reactions from the political and law enforcement sectors >> ultimately result in fragmentation, large-scale interconnection >> problems, and the either development of a lot of ad hoc >> solutions or movement of work to other SDOs because the IETF was >> too stuck on the importance of encryption no matter what. I >> don't predict that outcome and definitely don't wish for it, but >> I think our architectural work would be improved by more >> recognition of the possibility. > > If i limit your "encryption to "(TLS) end-to-end encryption", then > i think there are already a lot of people that have opinions about > the results even visible today. > > IMHO, TLS has two main neglected consequences: It has become the > key component of a strategy for revenue supremacy from one part of > the industry, and it has moved the bad behavior (perpass and its > revenue tail) into a layer of the solution (application) where it > is out of the control of the IETF. Or at least out of the scope > of interest of the companies shaping the IETF standards in that > space because they are the beneficiaries of this evolution. > > So, the next round of privacy discussion as we already see will > mostly be happening outside the IETF. For better or worse. > > This is of course non-withstanding the basic necessities to use > TLS and its benefits. > > Cheers > Toerless > >> best, >> john >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss > From nobody Thu Apr 16 14:52:33 2020 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 C31923A11B8 for ; Thu, 16 Apr 2020 14:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, 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 (1024-bit key) header.d=apnic.net 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 Y0aPiaOpsY_c for ; Thu, 16 Apr 2020 14:52:29 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-eopbgr1320054.outbound.protection.outlook.com [40.107.132.54]) (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 153703A108B for ; Thu, 16 Apr 2020 14:52:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ME1o0ATHI2kD6aNE0cpZuNZb8LIzfyQ8ym5N45dXTkxkuXrgqL4pqP8yp3EduUqwTVA8lTh2FNDmmiLs27gq25ixg/Jjoji7cBCE9s0aOcO5tjzgXj4e8GqBkOysI0/Ob3CVVjMwKPGFl0MJnNBEplAXUMEbFlKvxPAm33pk7IAiE1JXv9c276mVoz06LtqTz+DEu+RnDpOuAio8RT232TvxvGrT+kX/NZziT9sheqXO1KKJM4G6TjawFTjGl0lINa2lJitBOlYlBaaN9UZm9vtrcfjp218R32wOYwLa+nlSw2DSZvBPsalRqHdPHl0UnlOlerHwvJETxYniCfojYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ohBY7QJg5fhSf0hVYQ+lxZJoNErAlKGC+vT+Hd1TbF8=; b=iXRpMzPi4aAEG16NVerBDtWVvWFnbUEWbzHaxhNi5g3PDQcz9dI+6RcSiCHBXOuNUQR65xTZyqPr1oBJXpjPR2C3qWEPsGUim+dxy9yrcMla12/uzqeppm089m3v6+ldx+kiDypGCgPp6ECuw4qiQCQMVnpok8aHBaGfoLOGcuDSv+T+uk3hivcImsffGH9u2WSdLVPWzgBNi+XxSCDzA0b4LxGtRXL/TQUXISuCXge8VJyIYHc7e/nkvNcZmwm7GPW6I3DKFgP6w2RosRy2SJ5Yl2vIC03Akcnhi4PYuUdqRX/Sl2XemUKlKf2B5wYaexvl0XCHTMw57Hh78DenXg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=apnic.net; dmarc=pass action=none header.from=apnic.net; dkim=pass header.d=apnic.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ohBY7QJg5fhSf0hVYQ+lxZJoNErAlKGC+vT+Hd1TbF8=; b=FqVrVr84I+OLQaf8IhZRBWgDZ3/wUfsYyIQEUB8HnWwbrx4F+U6ekELJckp4HQavaJ3+E7/C5eOXBu14CwoYSpAQGqo7s0ekdkIgRkcdd4krJi645yHyS7qewOEbl/lywPk9Nqjksj4LMOjOiyLLX6MA2td00n95PhlrKZSt6KQ= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=gih@apnic.net; Received: from HK0PR04MB2756.apcprd04.prod.outlook.com (20.177.25.74) by HK0PR04MB2371.apcprd04.prod.outlook.com (52.133.145.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.28; Thu, 16 Apr 2020 21:52:25 +0000 Received: from HK0PR04MB2756.apcprd04.prod.outlook.com ([fe80::b09f:3852:b2bd:c8bd]) by HK0PR04MB2756.apcprd04.prod.outlook.com ([fe80::b09f:3852:b2bd:c8bd%4]) with mapi id 15.20.2900.028; Thu, 16 Apr 2020 21:52:25 +0000 Content-Type: text/plain; charset=utf-8 From: Geoff Huston In-Reply-To: <96ea575b-78d5-019d-15b2-abc8e5c8b22e@gmail.com> Date: Fri, 17 Apr 2020 07:52:20 +1000 Cc: Toerless Eckert , John C Klensin , architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <737F9A7C-C982-4C86-BAAE-8982CA4050F6@apnic.net> References: <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <4ac9e9fc-41a3-f458-566e-f0a68d26d9ea@huitema.net> <20200416174840.GL41264@faui48f.informatik.uni-erlangen.de> <96ea575b-78d5-019d-15b2-abc8e5c8b22e@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.80.23.2.2) X-ClientProxiedBy: SYXPR01CA0092.ausprd01.prod.outlook.com (2603:10c6:0:2e::25) To HK0PR04MB2756.apcprd04.prod.outlook.com (2603:1096:203:34::10) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from 2001-44b8-110b-5100-45a2-8555-7ad5-38a2.static.ipv6.internode.on.net (2001:44b8:110b:5100:45a2:8555:7ad5:38a2) by SYXPR01CA0092.ausprd01.prod.outlook.com (2603:10c6:0:2e::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.26 via Frontend Transport; Thu, 16 Apr 2020 21:52:24 +0000 X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Originating-IP: [2001:44b8:110b:5100:45a2:8555:7ad5:38a2] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 530557ce-53ae-4a85-1186-08d7e25072da X-MS-TrafficTypeDiagnostic: HK0PR04MB2371: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-Forefront-PRVS: 0375972289 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HK0PR04MB2756.apcprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39840400004)(136003)(376002)(396003)(346002)(366004)(6512007)(186003)(81156014)(66574012)(8676002)(6486002)(6916009)(36756003)(8936002)(2906002)(508600001)(5660300002)(2616005)(33656002)(66476007)(54906003)(53546011)(6506007)(86362001)(16526019)(316002)(4326008)(52116002)(6666004)(66556008)(66946007); DIR:OUT; SFP:1101; Received-SPF: None (protection.outlook.com: apnic.net does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: CoZr+0tgUyQ8r9I+AsZ4IUz/Gq+JmxHceF957VHMgi97XLfwqC/4mvgEH6y4/EyNxsFztKpFJL4httXNq8S8+YiFadUH7SFN3spyugLRS3cciTqV3xLLr9Y+1TehM6k4JR5lTuetmJYTHNYAnuWY9vT9MJDDSDiPKxvXEgrb1Qyp5xPPVDDk3Fz4j3Pmor/1/Nv34MTdJ/TKWOJ+YztU+okxdWrV2TbdPWinPo4svNMFY9LXOr4iceHDnalvR58v9rPh/y2mWvOaICOMZCi8QpXyxI7VH4Uvuv4Ho+o0H20ExD6Sfs4ouZQrLOQIimpmXJA/8P620k5HotsSeGXZoakEyfxJwoioQMDjumJD/TWAZQcLQ0j9y1Dbd3kmibjZeIV2ZjMgb3sYFXMDKjpPBtMTn2+VWz+GuQTKGkoLZ/2mLjXUIKokKj1SVI/wARtB X-MS-Exchange-AntiSpam-MessageData: sqN77TmNzHTnVjpdeA76hO1IcEy+t14t1pVlDtZLeSc1v9ObEwrjSULX5r+hcB5eqhPq0n/fcWShPoBzQA7Ps1G68xe5QEAiT8npkSRBMfKyWIajWsBH6IRRTeM/2JdXaF70rV7JEZ/PXVp37gz8PIjde+Flteu0TC38IynwdVK0CQ080c7JNJTeETUMwGHFggV/CwJDjCoY7fX1oktFYg== X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-Network-Message-Id: 530557ce-53ae-4a85-1186-08d7e25072da X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Apr 2020 21:52:25.0858 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 4yjptb4XNYxkpmTpcle4QQdzAwxPAKz3hxw1JUeCODrpJB6PXQkz01emfN2ZRt1t X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK0PR04MB2371 Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 16 Apr 2020 21:52:31 -0000 > On 17 Apr 2020, at 7:17 am, Brian E Carpenter wrote: >=20 > On 17-Apr-20 05:48, Toerless Eckert wrote: >> On Mon, Apr 13, 2020 at 02:56:30PM -0400, John C Klensin wrote: >>> It may also be worth noting that a, perhaps the, major add-on >>> change in IPv6 --much touted in its early days-- was supposed to >>> be ubiquitous lP-level encryption. >=20 > Not touted by the IPv6 protagonists, Evidently you never sat through a Latif Ladid presentation Brian! I heard many many many stories about how IPv6 and IPSEC was a revolutionary combination that was going to change the internet, yada yada yada. > Yes, there was an intention > to make IPsec mandatory-to-implement, but there was never a claim from th= e > IETF that IPv6 with IPsec was intrinsically more secure than IPv4 with IP= sec. >=20 Gee, the rooms I was in at the time was full of such wondrous claims. I kin= da wonder which room you were in at the time! With 20/20 hindsight I=E2=80=99d say the host-centric perspective of IPSEC = was comprehensively=20 flawed, as the subsequent move in the marketplace for protocols attests. As for IPv6: extension headers. No more need be said. Geoff From nobody Thu Apr 16 16:21:31 2020 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 4AC1C3A1325 for ; Thu, 16 Apr 2020 16:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 9g1Ujv9gAjzc for ; Thu, 16 Apr 2020 16:21:28 -0700 (PDT) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 22C573A1324 for ; Thu, 16 Apr 2020 16:21:28 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id ay1so231944plb.0 for ; Thu, 16 Apr 2020 16:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=BlPgIQ1CtI/uGiQzzVbdPjFy4g+GCU6OmMYpgRm2PBk=; b=FclH3Wca23Bz1wTsyDb8/W9bK5RTj1XK6nYc+R/cOPUq8/9CEfRUWsbx9eo67D+fw8 f5IH9UQ91BWYNzjSHUP9U8uza/q1WAzfKN5KIkmfNXPYtAC0PfSxk4rx6hDzpta5zHBs +KL+AJlADQUY6UXMaG5gdxbesfYcau7vQ4cyEj/nRvBP3Oe3i8nEhV+vvH633J+PVaRA HwZO6jm81t+ppN/Zk6RtCiD5MF9rN7M8xm1VYJlHv3KtW618IvQvsNFmjWD8w5Thgbf6 2oC1q8J4oJ7e5kah9iqjzNLN6iyZWDif23dCcuP/atFu03rZT3PXbizGA6uwf8tBDHAp ri5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=BlPgIQ1CtI/uGiQzzVbdPjFy4g+GCU6OmMYpgRm2PBk=; b=PtEjUXn8h6OPVpm7tNDUZyJWCchJlXjNsQs6dJti89y5EhyNDTaiY79Z+t17R4nhdx u4L0ciFQkGIxvT9xHusJgAPE9+rco3Zn7lvISMkKu3ijQ8x5HchpZhhzxzM9TjQTJCKx iXUiOnZBmaCvNL8NDE345CT85blunYefU2+5BBbJ++OOBwBYJkq1jww1brvuk13BMHGP qEkIHPFC/Sk3VBgWq+oynEiKqA8Fw6QZFsJnb9KeQxhVzb+enQe2556p/T2VWQQB2DEO NGGY8q3RToerVZEmE61WVnHnXHdxKS+709j+3AqTmUGl5ZI6iFjR49BwqPJa//EwIQ1P MHUw== X-Gm-Message-State: AGi0PuYwkwFIliUtU1lr5/EsNnxhWZJMKcfEXfwUWArqhLQiyja2eV+q vZx/5vEw0aSoEQPmJyUIJE4wJ4PX X-Google-Smtp-Source: APiQypIqMUg2rPo3/WvLmiDD7GNG5kxRL9l+kI/9ZXDriNtbBRWEFA1TA7Wl5iEBTag6u2o7Zp1yjA== X-Received: by 2002:a17:902:fe8e:: with SMTP id x14mr674120plm.128.1587079287338; Thu, 16 Apr 2020 16:21:27 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id y14sm9327402pff.205.2020.04.16.16.21.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Apr 2020 16:21:26 -0700 (PDT) From: Brian E Carpenter To: Geoff Huston Cc: Toerless Eckert , John C Klensin , architecture-discuss@ietf.org References: <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <4ac9e9fc-41a3-f458-566e-f0a68d26d9ea@huitema.net> <20200416174840.GL41264@faui48f.informatik.uni-erlangen.de> <96ea575b-78d5-019d-15b2-abc8e5c8b22e@gmail.com> <737F9A7C-C982-4C86-BAAE-8982CA4050F6@apnic.net> Message-ID: <7f8a176e-38ac-443f-9cc2-774d7b861bec@gmail.com> Date: Fri, 17 Apr 2020 11:21:22 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <737F9A7C-C982-4C86-BAAE-8982CA4050F6@apnic.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 16 Apr 2020 23:21:29 -0000 Geoff, I was talking about IETF IPv6 protagonists, not about people outside the = IETF. Regards Brian On 17-Apr-20 09:52, Geoff Huston wrote: >=20 >=20 >> On 17 Apr 2020, at 7:17 am, Brian E Carpenter wrote: >> >> On 17-Apr-20 05:48, Toerless Eckert wrote: >>> On Mon, Apr 13, 2020 at 02:56:30PM -0400, John C Klensin wrote: >>>> It may also be worth noting that a, perhaps the, major add-on >>>> change in IPv6 --much touted in its early days-- was supposed to >>>> be ubiquitous lP-level encryption. >> >> Not touted by the IPv6 protagonists, >=20 > Evidently you never sat through a Latif Ladid presentation Brian! I hea= rd > many many many stories about how IPv6 and IPSEC was a revolutionary > combination that was going to change the internet, yada yada yada. >=20 >> Yes, there was an intention >> to make IPsec mandatory-to-implement, but there was never a claim from= the >> IETF that IPv6 with IPsec was intrinsically more secure than IPv4 with= IPsec. >> >=20 > Gee, the rooms I was in at the time was full of such wondrous claims. I= kinda > wonder which room you were in at the time! >=20 > With 20/20 hindsight I=E2=80=99d say the host-centric perspective of IP= SEC was comprehensively=20 > flawed, as the subsequent move in the marketplace for protocols attests= =2E >=20 > As for IPv6: extension headers. No more need be said. >=20 > Geoff >=20 >=20 >=20 >=20 >=20 >=20 From nobody Thu Apr 16 20:46:32 2020 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 E6AD93A08A7 for ; Thu, 16 Apr 2020 20:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 6nKapxm9yGIk for ; Thu, 16 Apr 2020 20:46:28 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C57083A089F for ; Thu, 16 Apr 2020 20:46:27 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jPHxN-000Ki9-C2; Thu, 16 Apr 2020 23:46:21 -0400 Date: Thu, 16 Apr 2020 23:46:15 -0400 From: John C Klensin To: Brian E Carpenter , Toerless Eckert cc: Christian Huitema , architecture-discuss@ietf.org Message-ID: <3B865A655CF0068FB0217D67@PSB> In-Reply-To: <96ea575b-78d5-019d-15b2-abc8e5c8b22e@gmail.com> References: <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <4ac9e9fc-41a3-f458-566e-f0a68d26d9ea@huitema.net> <20200416174840.GL41264@faui48f.informatik.uni-erlangen.de> <96ea575b-78d5-019d-15b2-abc8e5c8b22e@gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 17 Apr 2020 03:46:31 -0000 --On Friday, April 17, 2020 09:17 +1200 Brian E Carpenter wrote: > On 17-Apr-20 05:48, Toerless Eckert wrote: >> On Mon, Apr 13, 2020 at 02:56:30PM -0400, John C Klensin >> wrote: >>> It may also be worth noting that a, perhaps the, major add-on >>> change in IPv6 --much touted in its early days-- was >>> supposed to be ubiquitous lP-level encryption. > > Not touted by the IPv6 protagonists, however. Really? You obviously were not at some of the IPv6 Forum events that I got to. Now, if you mean (as suggested below) "IETF IPv6 protagonists", then I would probably agree, but the same IPv6 Forum leadership were citing the IETF as authority for a lot of things few, if any, IETF participants ever said. (Obviously agreeing with Geoff here, just writing more slowly.) And, since we are mentioning names, Latif wasn't the only one. Arguably "we" -- IETF, IAB, and ISOC -- said some things that were interpreted as indicating that IPv4 address exhaustion was going to occur really soon, that it would be the end of life as we knew it, and that IPv6 was the only solution. While most of those/ "our" comments were very nuanced, they left a vacuum that a variety of people --some very sincere and a few pushing products that were often not quite ready -- pushed, supposedly quoting/representing "us". > Yes, there was > an intention to make IPsec mandatory-to-implement, but there > was never a claim from the IETF that IPv6 with IPsec was > intrinsically more secure than IPv4 with IPsec. Agreed. But there were a lot of claims that, since it was or soon would be mandatory to implement, it was going to be much more widely supported under IPv6 than it had been, or would likely ever be, under IPv4. And the implication of many of those claims was the IPSec over (or integrated with) IPv6 would be far more secure, easier to implement and deploy, etc., than what was available (as an add-on, they said) over IPv4. See above. > The claim that IPv6 was intrinsically secure was indeed > touted; if I'm not mistaken it orginated in an industry white > paper, was picked up and exagerrated by the IPv6 Forum, and > got into draft-ietf-iab-case-for-ipv6-00, (which led to > draft-iab-case-for-ipv6-06 and was then scrapped). But it also > featured in various lists of IPv6 Myths over many years. And I am pushing on this because, at least IMO, we are still talking about when IPv6 will dominate IPv4 on the Internet and/or making claims about how rapidly it is deploying. That breaks, by far, the record of claims for "two years from now" about a small collection of protocols unrelated to the IETF, claims that you may remember every couple of years through the 1980s. >From an entirely non-technical perspective, we --the IETF and various bodies that claimed our support and involvement, with said IPv6 Forum high on the list-- made two very fundamental political-economic errors. "We" claimed that it was ready, and products that would support it were ready, and that it was/would be easy to deploy at a time when the claims about readiness were dubious (because the assorted dual-stack and other arrangements at the endpoints were not quite finished or because ISPs were not ready to deploy either the packets or the boundary routers or equivalent). And some of the organizations that took "our" advice and tried to deploy got burned and became harder to convince to try again later. The other is that, at least IMO, we failed to adequately consider incentives for deployment once one moved past fear of running out of address space (which, predictably, tended to be seen as something to be worked around or someone else's problem). This is, I think, important today, not because of the IPv6 issues but because the Internet has matured enough that it may be even more important now than it was then to include in our thinking about major new protocols or protocol changes an analysis of incentives and disincentives to deployment, and, if appropriate, who benefits and who loses, not just analyses of whether they can be implemented and will work. And it would be reasonable for us to share that advice with others as well as following it ourselves. best, john From nobody Fri Apr 17 02:09:37 2020 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 E7C1C3A114C for ; Fri, 17 Apr 2020 02:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 lgkbskqgv9LW for ; Fri, 17 Apr 2020 02:09:30 -0700 (PDT) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 748983A114B for ; Fri, 17 Apr 2020 02:09:28 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.4.149]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 03H98rOc002950 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Apr 2020 02:09:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1587114547; x=1587200947; i=@elandsys.com; bh=zvOv0ZYp3pkSawafxfwP8zVrWkiIm50qXEbWkJorNb0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=a3h1WgcTQPbQNzce1E5S1z9VBbrS7rAYXeURh91TRk/OSKcg21Q+4p/JgGEFAeGhY FZ08dnIfXKncZz1nuYnYooWi+rpENI69WT5aORsBogxSiqRujjJUMjRbQxUh4Yh2MN CTKKBbc+eHYjg5LFrVggk4+wPAuyrWgafpuJ250U= Message-Id: <6.2.5.6.2.20200417010529.0c28ab50@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 17 Apr 2020 02:08:28 -0700 To: Toerless Eckert , architecture-discuss@ietf.org From: S Moonesamy In-Reply-To: <20200416174840.GL41264@faui48f.informatik.uni-erlangen.de> References: <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <4ac9e9fc-41a3-f458-566e-f0a68d26d9ea@huitema.net> <20200416174840.GL41264@faui48f.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 17 Apr 2020 09:09:35 -0000 Hi Toerless, At 10:48 AM 16-04-2020, Toerless Eckert wrote: >On Mon, Apr 13, 2020 at 02:56:30PM -0400, John C Klensin wrote: > > It may also be worth noting that a, perhaps the, major add-on > > change in IPv6 --much touted in its early days-- was supposed to > > be ubiquitous lP-level encryption. > >Indeed. It is almost puzzling to think that end-to-end >encryption at IP(sec) level was presumed to be a good >architectural choice. Besides the obvious beneeit of being >agnostic to transport protocol choices but then failing on >ever getting a host stack model that would allow applications >to leverage it easily. Of couse, luckily we have it (IPsec) >as there are a lot of other good use cases for it. >Maybe a bit too much of the "one size fits all" syndrom that >new technologies by sheer self interest always come to presume ? IPv6 was promoted as "secure by default" as IPsec was part of it. It took many years for the IETF to admit that the technology selected by its central planning department did not see widespread use. It's a bit like "SEND". Have you ever heard of FILTH [1]? There are people who visit what is sometimes referred to as an undeveloped country. Some of those people tout their affiliation with the IETF to convince entities in that country to deploy a technology on the premise that it is used in advanced countries. The "one size fits all" rarely works. Regards, S. Moonesamy 1. http://r.elandsys.com/r/10933 From nobody Fri Apr 17 03:45:58 2020 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 759293A088C for ; Fri, 17 Apr 2020 03:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=sidn.nl 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 FhYuq7I-ijSl for ; Fri, 17 Apr 2020 03:45:54 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2067.outbound.protection.outlook.com [40.107.20.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 289983A088A for ; Fri, 17 Apr 2020 03:45:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T4IlDOI4xNNoCSUQ8IW53N6mb+wjeYW5a7LTx8GD/kUREpgV/njoUrlrW6C5c3WOnL3rvZjAX/U/GM/heLXkRN+Ih0urzyK7QSvOftvp3JHYDUN2ij1UCEy14jlsTzph9RCbb/31/M8Ofk2Q1yzwbMKRrPWQXw5VdNPFKzx8TsIPTZoBYZ49YmgXzE1MHy/pUpc+VBISANfmwc1nHJWiF9S6uj1oJ6XMYvLCe0ASExqcvxkXZTNWHeNBvMlB5iFZAlcwI6NamQ3AFPOuhHHhkaeRI99Hj4/v4Ym28ATDoOXrOcVkfXT+w7uRrXe3ug/c+9OWhMIIuFXrPJV/+tqr/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kDYWWDIAriyDybvuaUiqpBY2odpDwbWxjJL+72OAofY=; b=WL1l+1e2sIJMS9SHfl8N5IV/299me+K5eMUDIC7mg2abBSordLoX+mVT5mjoboe61V7hEVx1I91IAQLlBjJ+PeOeYSYO2ryphBSGdCvfxIErmMF/d1PN0Ir414Qqgb7IzLfG1B22TCTmesrpkIt8chwEQvnw7+AjUVZUqUm76EnsQScflgo/Pezrx1GBENJ2Y8YDwwrjcx44buNOGdsRnkYjTOssQLE6USDo2pK0zIAxQ2oxkm9OzWfi+3rM/TR/N8yssJroJ+JBPEsyjuYoLJhWCT1J5EcJ44uG6jULtszweBfVLhxWys8l5BdM78glMcrWl+XBdH2o1XGriKItAA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sidn.nl; dmarc=pass action=none header.from=sidn.nl; dkim=pass header.d=sidn.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sidn.nl; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kDYWWDIAriyDybvuaUiqpBY2odpDwbWxjJL+72OAofY=; b=bwAVo1UPFqhB6fqiFGzKaQK+t5z0eANt1UD2/vXVjQGTKFC5q+HLX4HZJs5ex7wX13gJDOlGhM1AfZyeWWCgamyatoFztvWMCQd5ouGnJgi16BPxSwZrYuNuoBMn/p2SIzOLlbJskn3rJ234XuPkyA5d4mAg9LpGpmQuzBqSEJo= Received: from PR3P194MB0602.EURP194.PROD.OUTLOOK.COM (2603:10a6:102:38::12) by PR3P194MB0764.EURP194.PROD.OUTLOOK.COM (2603:10a6:102:29::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.29; Fri, 17 Apr 2020 10:45:50 +0000 Received: from PR3P194MB0602.EURP194.PROD.OUTLOOK.COM ([fe80::b575:a338:3cd4:1ee1]) by PR3P194MB0602.EURP194.PROD.OUTLOOK.COM ([fe80::b575:a338:3cd4:1ee1%5]) with mapi id 15.20.2921.027; Fri, 17 Apr 2020 10:45:50 +0000 From: Victor Reijs To: S Moonesamy , Toerless Eckert , "architecture-discuss@ietf.org" Thread-Topic: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services Thread-Index: AQHWDWJyhUWBPnI3wkiq6mi66DMYhahuqlAAgAALyACAAN4dAIAADIkAgADi6gCAADPdgIAAGZYAgABD94CAADYPAIAByMIAgARb1ACABKQKAIABAP0AgAAXdVA= Date: Fri, 17 Apr 2020 10:45:50 +0000 Message-ID: References: <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <4ac9e9fc-41a3-f458-566e-f0a68d26d9ea@huitema.net> <20200416174840.GL41264@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200417010529.0c28ab50@elandnews.com> In-Reply-To: <6.2.5.6.2.20200417010529.0c28ab50@elandnews.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=victor.reijs@sidn.nl; x-originating-ip: [213.127.1.166] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 17e7993c-fad6-4701-6eb1-08d7e2bc7f05 x-ms-traffictypediagnostic: PR3P194MB0764: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0376ECF4DD x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR3P194MB0602.EURP194.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(376002)(39840400004)(136003)(366004)(346002)(2906002)(33656002)(7696005)(6506007)(53546011)(26005)(110136005)(316002)(86362001)(66574012)(52536014)(186003)(44832011)(5660300002)(9686003)(478600001)(8676002)(66556008)(64756008)(66446008)(71200400001)(55016002)(81156014)(8936002)(76116006)(66946007)(66476007)(15974865002)(83080400001)(18886075002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: sidn.nl does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yT1cwtREYKgklbcFE4jQEFRZ2Xt4gpmXEtGib9raf6U+BN3bpnZo19UP7ZPsMJYCxkhjj/jF1kgIxZX20J2GN55GtWKW6vf7dGySW3itL9bTG+/HVu3+jHQmZJpIEmDZDwMrlPcOOBxPU1qS/amer27h5CpPL96c2NtKrQANZh7eyv9f+jipaU7NIn0toCLBDDRxu/H1LdmxkX2p1oK9CN4aGkMra1Sq8pAI2V6J5ypESK/CxSMjdQvTCOMos/X/lxUPGPRlVYoNp5YxMDHsCFfRYzEXeMR4nkAy3n3bSWmwZr5YeK1oaeL9OkZbYWlC8l2EbxEwEmu3OW9yvPtD76jV2qwyGAgc1PaElghkHgwwMYhAcLHD3ONj31SpMBpJ4u063MhVFwA/5k8X9iIGc4ZourJwYz+5X7lsgih0+97ObGsDysdMZqmMXgGhZHrQGAbHTiiLOzg+c+OMF9J2FRbSjJKPrSkVGQlc1GAI3fNhzr2f0OLdF1oY42izzSACu6YQMYmanNEu0puQamVvOR4hvG1mBtIuKOITOL9ECWzd6TZKseQfegNxTU30pXw9TEj6Az2IpvHVJqdaAqK2Lw== x-ms-exchange-antispam-messagedata: 9sAaPbf8uJHZNlnE+K4BiXufpcaKzhQsbIpapP/LsSKOBy1f0IBIk4krp44x9MLXenvK1xhuu/hDG5q3nsvtCrVhe2CcA0sSdVBcHlppqA5uhQd7821S7ihAxNUmL/EQstM3UvWhKUZ/WZ8dRt2hgQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sidn.nl X-MS-Exchange-CrossTenant-Network-Message-Id: 17e7993c-fad6-4701-6eb1-08d7e2bc7f05 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2020 10:45:50.8249 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ab4d3626-c1c5-4a75-ab85-427f1a644a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3v8c7CBzqnP1IfS9oPP30yJxgbysES+fvR2leiOrWWSUATtDCz9a28Y3PiKL6g+Cd5EkgExRWDGcEhq67Xy/yA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3P194MB0764 Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 17 Apr 2020 10:45:57 -0000 SGVsbG8gYWxsIG9mIHlvdSwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBBcmNoaXRlY3R1cmUtZGlzY3VzcyA8YXJjaGl0ZWN0dXJlLWRpc2N1c3MtYm91bmNlc0BpZXRm Lm9yZz4gT24gQmVoYWxmIE9mDQo+IFMgTW9vbmVzYW15DQo+IFNlbnQ6IEZyaWRheSwgMTcgQXBy aWwgMjAyMCAxMTowOA0KPiBUbzogVG9lcmxlc3MgRWNrZXJ0IDx0dGVAY3MuZmF1LmRlPjsgYXJj aGl0ZWN0dXJlLWRpc2N1c3NAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFthcmNoLWRdIEVUU0kg bGF1bmNoZXMgbmV3IGdyb3VwIG9uIE5vbi1JUCBOZXR3b3JraW5nIGFkZHJlc3NpbmcNCj4gNUcg bmV3IHNlcnZpY2VzDQo+IA0KPiBJUHY2IHdhcyBwcm9tb3RlZCBhcyAic2VjdXJlIGJ5IGRlZmF1 bHQiIGFzIElQc2VjIHdhcyBwYXJ0IG9mIGl0LiAgDQoNCltWaWN0b3IgUmVpanNdIA0KSSBjYW4g cmVtZW1iZXIgdGhhdCB3aGVuIHdlIHRvZ2V0aGVyIGhhZCBhIGZ1bGx5IG9wZXJhdGlvbmFsIFRV QkEvQ0xOUyBzZXJ2aWNlIGluIEV1cm9wZSBhbmQgVVMgKHJlYWxseSA5MHMpLiBUaGUgbWlzc2lu ZyBvZiBJUFNlYyB3YXMgb25lIG9mIHRoZSByZWFzb24gbm90IHRvIGNob29zZSBmb3IgVFVCQS9D TE5TIChiZXNpZGUgdGhhdCBpdCB3YXMgYW4gSVRVIHN0YW5kYXJkKS4gVFVCQS9DTE5TIHdhcyBv bmx5IHByb3ZpZGluZyBsb25nZXIgKGZsZXhpYmxlIGxlbmd0aCkgYWRkcmVzc2VzLiBXaGlsZSBJ UHY2IHNob3VsZCBkbyBpbmRlZWQgc2VjdXJlIHN0dWZmLiBOb3QgbXVjaCBoYXMgbWF0ZXJpYWxp c2UgaW4gYWxsIHRoZXNlIHllYXJzIGR1cmluZyB3aGljaCBJUHY2IG5lZWRlZCB0byBiZSBkZXZl bG9wZWQvZGVwbG95ZWQuLi4NCkJ1dCBvayB0aGF0IGlzIGluIHRoZSBwYXN0Lg0KDQpJIG5vdyBy ZWFkIGluIHRoZSBFVFNJIElTRy1OSU4gZ3JvdXAgdGhhdCB0aGUgbWFqb3IgaXNzdWVzIG5vdCB0 byB1c2UgSVAgaW5zaWRlIEI1RyBpcyBkZSBhZGRpdGlvbmFsIGNvc3Qgb2Ygc3BlY3RydW0gKHdo aWNoIGlzIHF1aXRlIGxpbWl0ZWQpIGR1ZSB0byB0aGUgbGFyZ2UgaGVhZGVycyBpbiBJUHY0L3Y2 IGFuZCBtYW55IGVuY2Fwc3VsYXRpb25zIGhhcHBlbmluZy4gRnVydGhlcm1vcmUgY29uZ2VzdGlv biBjb250cm9sIGFuZCBRb1MgYXJlIHJlYWxseSBub3Qgc3VwcG9ydGVkIGFuZCB0aGF0IG1pZ2h0 IGNhdXNlIHByb2JsZW1zIGZvciByZWFsLXRpbWUgb3IgdGltZSBjcml0aWNhbCBhcHBsaWNhdGlv bnMuIFRoZSBJQ0FOTiByZXBvcnQgKDVHIFRlY2hub2xvZ3kpIHNheXMgdGhhdCBJUCBjYW4gYWxs IGRvIHRoYXQsIGJ1dCB3aHkgYXJlIHRoZSBJQ0FOTiBhcmd1bWVudHMgbm90ICh5ZXQpIGNvbnZp bmNpbmcgdGhlIG1vYmlsZSBvcGVyYXRvcnM/DQpJIHRoaW5rIHRoZSBzcGVjaWZpY2F0aW9ucyBh cmUgcXVpdGUgY2xlYXIgZGVmaW5lZCBieSBFVFNJIE5HUCdzIEtQSSAoaHR0cHM6Ly93d3cuZXRz aS5vcmcvZGVsaXZlci9ldHNpX2dzL05HUC8wMDFfMDk5LzAxMi8wMS4wMS4wMV82MC9nc19OR1Aw MTJ2MDEwMTAxcC5wZGYgKSBzbyBpdCBtdXN0IGJlICdlYXN5JyB0byBkZXRlcm1pbmUgaWYgSVAg Y2FuIG9yIGNhbm5vdCBkbyBpdC4NCg0KDQpBbGwgdGhlIGJlc3QgYW5kIHN0YXkgaGVhbHRoeSwN Cg0KVmljdG9yIFJlaWpzDQpSZXNlYXJjaCBlbmdpbmVlcjogZnV0dXJlIGludGVybmV0DQoNCkF0 dGVuZGFuY2UgKENFU1QpOiBNb24gOC4xNS0xNi40NSB8IFR1ZSA4LjE1LTE2LjQ1IHwgRnJpIDku MDAtMTcuMzANCg0KDQoNClNJRE4gfCBNZWFuZGVyIDUwMSB8IDY4MjUgTUQgfCBQb3N0YnVzIDUw MjIgfCA2ODAyIEVBIHwgQVJOSEVNIHwgVGhlIE5ldGhlcmxhbmRzDQpUICszMSAoMCkyNiAzNTIg NTUgMDAgfCBNICszMSAoMCk2IDEyIDQ1IDAwIDExDQp2aWN0b3IucmVpanNAc2lkbi5ubCB8IHd3 dy5zaWRuLm5sDQo= From nobody Fri Apr 17 07:31:02 2020 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 ED0523A09F3 for ; Fri, 17 Apr 2020 07:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 n8mLhEPjShvB for ; Fri, 17 Apr 2020 07:30:59 -0700 (PDT) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (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 3C1813A09E9 for ; Fri, 17 Apr 2020 07:30:59 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-02v.sys.comcast.net with ESMTP id PRYrjtlxzGF45PS1CjLYBp; Fri, 17 Apr 2020 14:30:58 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1587133858; bh=nX7c6LnFqgcbu0LBik+2LCZ/45xhqtpqr/VRs2S6IEc=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=tkhiIv6R/mSBdTGIk8iCEecpsVREa/d89ZfA6HJRCbjEfRrih4tTAC/VoE3poN8uX RDvjDNsyEloG9gw3TFE/8WpyHnC7/aTwgyCTJTLm3Gq7QFbDtwkl15BE04lQhDIPIt LTIDDAIgdU5KfXTKl1bedSzBn0iziByS6EzGHswjOTZb9bP5nDK/neFIUWwwmDtq12 p3CicJan9smdRmI5tlVMgzlMhFATTOKbh+I4cBnEho/dIQTBNABr0SU4AgcL7HNys4 rCDj1qg9Z/NlS0BDmwHz4EYs0Zzx1hA8a6xmNmyBuDwLPZz6LhGG3mHS/dRx0O2y1o pVFtye4c5cG7A== Received: from [IPv6:2601:189:4300:cee9:48a:1a1c:36e9:cf55] ([IPv6:2601:189:4300:cee9:48a:1a1c:36e9:cf55]) by resomta-ch2-08v.sys.comcast.net with ESMTPA id PS18jCgU3Gi8APS19jnPcj; Fri, 17 Apr 2020 14:30:57 +0000 X-Xfinity-VMeta: sc=0.00;st=legit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: John Day In-Reply-To: Date: Fri, 17 Apr 2020 10:30:54 -0400 Cc: S Moonesamy , Toerless Eckert , "architecture-discuss@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <4ac9e9fc-41a3-f458-566e-f0a68d26d9ea@huitema.net> <20200416174840.GL41264@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200417010529.0c28ab50@elandnews.com> To: Victor Reijs X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 17 Apr 2020 14:31:01 -0000 One minor correction. =20 TUBA/CLNS was an ISO effort. It is true that it does have a ITU number = but nearly all OSI standards had both an ISO number and an ITU number.=20= The ITU consistently opposed connectionless and CLNP at every = opportunity they had starting with the OSI Reference Model to keep = connectionless out of OSI. The first amendment to the OSI Reference = Model was to add connectionless and the ITU fought that tooth and nail. = It was only through the efforts of *computer companies,* not ITU = members, that connectionless and CLNP was there and the work progressed. The ITU never wanted CLNP and the IETF obliged them. There was more CLNP deployed and operational in the Internet in 1992 = than IPv6 in 2014. The ITU owes the IETF an immense debt of gratitude for keeping this = issue uncertain for the past 28 years. This has greatly facilitated the = ITU's great success in bringing the IETF even closer to the ITU = direction. Congratulations. John > On Apr 17, 2020, at 06:45, Victor Reijs = wrote: >=20 > Hello all of you, >=20 >> -----Original Message----- >> From: Architecture-discuss On = Behalf Of >> S Moonesamy >> Sent: Friday, 17 April 2020 11:08 >> To: Toerless Eckert ; architecture-discuss@ietf.org >> Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking = addressing >> 5G new services >>=20 >> IPv6 was promoted as "secure by default" as IPsec was part of it. =20 >=20 > [Victor Reijs]=20 > I can remember that when we together had a fully operational TUBA/CLNS = service in Europe and US (really 90s). The missing of IPSec was one of = the reason not to choose for TUBA/CLNS (beside that it was an ITU = standard). TUBA/CLNS was only providing longer (flexible length) = addresses. While IPv6 should do indeed secure stuff. Not much has = materialise in all these years during which IPv6 needed to be = developed/deployed... > But ok that is in the past. >=20 > I now read in the ETSI ISG-NIN group that the major issues not to use = IP inside B5G is de additional cost of spectrum (which is quite limited) = due to the large headers in IPv4/v6 and many encapsulations happening. = Furthermore congestion control and QoS are really not supported and that = might cause problems for real-time or time critical applications. The = ICANN report (5G Technology) says that IP can all do that, but why are = the ICANN arguments not (yet) convincing the mobile operators? > I think the specifications are quite clear defined by ETSI NGP's KPI = (https://www.etsi.org/deliver/etsi_gs/NGP/001_099/012/01.01.01_60/gs_NGP01= 2v010101p.pdf ) so it must be 'easy' to determine if IP can or cannot do = it. >=20 >=20 > All the best and stay healthy, >=20 > Victor Reijs > Research engineer: future internet >=20 > Attendance (CEST): Mon 8.15-16.45 | Tue 8.15-16.45 | Fri 9.00-17.30 >=20 >=20 >=20 > SIDN | Meander 501 | 6825 MD | Postbus 5022 | 6802 EA | ARNHEM | The = Netherlands > T +31 (0)26 352 55 00 | M +31 (0)6 12 45 00 11 > victor.reijs@sidn.nl | www.sidn.nl > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Fri Apr 17 07:41:03 2020 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 882723A0CBD for ; Fri, 17 Apr 2020 07:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sidn.nl 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 fuSkrclOCP4f for ; Fri, 17 Apr 2020 07:40:57 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60041.outbound.protection.outlook.com [40.107.6.41]) (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 315F83A0C66 for ; Fri, 17 Apr 2020 07:40:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Rcth3hL1ADH/tExG7cy5jlPLIPmJtXGZd1IlPwfSslMuvBGvwZ2v05VZ5OYyXr+c5cV9GecQxp8CNExFYADVKX1mOsVyoqLAd79duOZrbCEiO+LJ7RhgiRpb4u48W7jpN+y2m5xCHceJWDxyM6TP5IUKjTF9Pf/Kb9KB322fHGRiGWqj+7mpDJ4MRgEui6GwUdeafREHdNOqr3zt2ie0uXBfgpu1Jvbg9YduTM+MybXVlGOzTPeqhtk2zwi+Za5J9ZH/kxBIUnShczr2w5S951Ot5qvmII+PFiNv4omp4ICrZMOgkLoh/K/91Py5O+Y5BhBn5rOkEOXZe8IrnF6x7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0N3fHmg28HD7Q9vCkYw5jeEW7VbyZO7vgU+EONJKz04=; b=LTeRDjMia4l449gjdwUJIwsPOnkAnSO23wTEEAQwJ8y2A6YHhalrNKWxgEfN2Q9fS4D8VYG6zDmRKQxT0sge0XUJS4WRpz1wtMPUkkpGxc9Zy91aCGITx+D1ic64o22Z+vEAarrSHfdidYKaBQz1deQkGDrNe7m36nItojOJ+SlQ8TiTWB7Z9+/87GbtcE7EQi5CBLZIVGbpWEFsdLlW+nWFdwZuuH45T8US7gY7h3vs+UVHgZLbPQIs4bWJQrX1vUJfa1rB2D7TOwUiUBkKeGME3m5Qnfa7Q1g17tPa2duhhr26+kGfaDgxpu0ZPfiEcwzLyQSNDo0dFqqTF+zdfQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sidn.nl; dmarc=pass action=none header.from=sidn.nl; dkim=pass header.d=sidn.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sidn.nl; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0N3fHmg28HD7Q9vCkYw5jeEW7VbyZO7vgU+EONJKz04=; b=Uw/tGSW2fRNOveNv40lb3yeXENjgWWcZIti9tX13KcVXBTTlzrsJbGPhOpB78qlLJTUNj844MKCBhJ9MmfX5igVH5yzwjs3MCodbyT1nkZpoxp6XwYoOQFDW+hajPziqYr5eA1eqwLZQytLc6f45X94EMbSoU82djq7/ixyprRM= Received: from PR3P194MB0602.EURP194.PROD.OUTLOOK.COM (2603:10a6:102:38::12) by PR3P194MB0906.EURP194.PROD.OUTLOOK.COM (2603:10a6:102:4a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.27; Fri, 17 Apr 2020 14:40:53 +0000 Received: from PR3P194MB0602.EURP194.PROD.OUTLOOK.COM ([fe80::b575:a338:3cd4:1ee1]) by PR3P194MB0602.EURP194.PROD.OUTLOOK.COM ([fe80::b575:a338:3cd4:1ee1%5]) with mapi id 15.20.2921.027; Fri, 17 Apr 2020 14:40:53 +0000 From: Victor Reijs To: John Day CC: S Moonesamy , Toerless Eckert , "architecture-discuss@ietf.org" Thread-Topic: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services Thread-Index: AQHWDWJyhUWBPnI3wkiq6mi66DMYhahuqlAAgAALyACAAN4dAIAADIkAgADi6gCAADPdgIAAGZYAgABD94CAADYPAIAByMIAgARb1ACABKQKAIABAP0AgAAXdVCAAEKiAIAAArMg Date: Fri, 17 Apr 2020 14:40:53 +0000 Message-ID: References: <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <4ac9e9fc-41a3-f458-566e-f0a68d26d9ea@huitema.net> <20200416174840.GL41264@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200417010529.0c28ab50@elandnews.com> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=victor.reijs@sidn.nl; x-originating-ip: [213.127.1.166] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 03546282-0972-4c5c-066c-08d7e2dd54c8 x-ms-traffictypediagnostic: PR3P194MB0906: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0376ECF4DD x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PR3P194MB0602.EURP194.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(136003)(346002)(39840400004)(376002)(366004)(396003)(316002)(6506007)(7696005)(15974865002)(66446008)(76116006)(53546011)(9686003)(55016002)(64756008)(66556008)(66946007)(66476007)(26005)(54906003)(478600001)(186003)(44832011)(6916009)(966005)(81156014)(8676002)(8936002)(5660300002)(83080400001)(66574012)(86362001)(71200400001)(4326008)(52536014)(2906002)(33656002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: sidn.nl does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bqYRt0+eE5xL+oJZZg8obovDmeV+BPHk5EYxMIZ/aLd8jYjv75w2J0FL/pytR+rjVQmSNpy7zFikchj3gvsJkbmYS/H/MCXcvRE3CZ+TsQ1zGHXEG/OPhyhFOxnHspwFslCKexy9iKT/vR2kOmYXTRCCRzg9owoOVEUExoWVIca+L01pGiaWUJUxqk0P2CmRgn8oWTVpqGDlCGMqCRpTWlBFrhBHo4VAVMvZWw/Of8YrB/FQJKR4nce1+Ph4PtGHCscDQz1HMnD9YYYeH0+3rWr4c0oANwuyBTSzb+M1isPywbnlVdWTfWzYv8TOrYIN6aORzLwXw1NLulrNbhHzPoji+xT+svJc4dSjeT7Ux+G0JwhRId87Fco5+6lI6ITP2lVUoyMCFUkaO7ITsU90A6vqhbH7RcD98J5HCLdN8GugHT3357NOZzz0n+Hh77SSdiHDinPYl2xlgk3LAcL2iXQbxmqWFusV4+MoQ1+A6FcCSishci6Kn7SbRSELkvuhJUUacY2FF0PH962QFkxfyA== x-ms-exchange-antispam-messagedata: BXEn53kZdwr9OlCR5ZwQERzp9zwijeLMZEX6lRhjdKQ0AI2A9decG7zhD2mHud0aQTWcAI2L7RxY5pEfb4SuxHlJUPRdzsgEjYoZwQkkYxhdusFK3CaBTkczQW3QmDxNjuRJEzmy5LWIo6H4C2qT1Q== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sidn.nl X-MS-Exchange-CrossTenant-Network-Message-Id: 03546282-0972-4c5c-066c-08d7e2dd54c8 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2020 14:40:53.3482 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ab4d3626-c1c5-4a75-ab85-427f1a644a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nHwiWZqxmPaNoIiSFaU/aARTAC6vBf2fyiG3nmwYaG+BvP2qzsMe8P2ovWQE/tNBlh0ciI3NTkb8sCfsUVwMgA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3P194MB0906 Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 17 Apr 2020 14:41:02 -0000 SW5kZWVkIEkgd2FzIHJ1bm5pbmcgdGhlIFRVQkEvQ0xOQlMgcHJvamVjdCB3b3JsZHdpZGXwn5iJ DQoNCg0KVmljdG9yIFJlaWpzDQpSZXNlYXJjaCBlbmdpbmVlcjogZnV0dXJlIGludGVybmV0DQoN CkF0dGVuZGFuY2UgKENFU1QpOiBNb24gOC4xNS0xNi40NSB8IFR1ZSA4LjE1LTE2LjQ1IHwgRnJp IDkuMDAtMTcuMzANCg0KDQoNClNJRE4gfCBNZWFuZGVyIDUwMSB8IDY4MjUgTUQgfCBQb3N0YnVz IDUwMjIgfCA2ODAyIEVBIHwgQVJOSEVNIHwgVGhlIE5ldGhlcmxhbmRzDQpUICszMSAoMCkyNiAz NTIgNTUgMDAgfCBNICszMSAoMCk2IDEyIDQ1IDAwIDExDQp2aWN0b3IucmVpanNAc2lkbi5ubCB8 wqB3d3cuc2lkbi5ubA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpv aG4gRGF5IDxqZWFuam91ckBjb21jYXN0Lm5ldD4NCj4gU2VudDogRnJpZGF5LCAxNyBBcHJpbCAy MDIwIDE2OjMxDQo+IFRvOiBWaWN0b3IgUmVpanMgPHZpY3Rvci5yZWlqc0BzaWRuLm5sPg0KPiBD YzogUyBNb29uZXNhbXkgPHNtK2lldGZAZWxhbmRzeXMuY29tPjsgVG9lcmxlc3MgRWNrZXJ0IDx0 dGVAY3MuZmF1LmRlPjsNCj4gYXJjaGl0ZWN0dXJlLWRpc2N1c3NAaWV0Zi5vcmcNCj4gU3ViamVj dDogUmU6IFthcmNoLWRdIEVUU0kgbGF1bmNoZXMgbmV3IGdyb3VwIG9uIE5vbi1JUCBOZXR3b3Jr aW5nIGFkZHJlc3NpbmcNCj4gNUcgbmV3IHNlcnZpY2VzDQo+IA0KPiBPbmUgbWlub3IgY29ycmVj dGlvbi4NCj4gDQo+IFRVQkEvQ0xOUyB3YXMgYW4gSVNPIGVmZm9ydC4gSXQgaXMgdHJ1ZSB0aGF0 IGl0IGRvZXMgaGF2ZSBhIElUVSBudW1iZXIgYnV0IG5lYXJseQ0KPiBhbGwgT1NJIHN0YW5kYXJk cyBoYWQgYm90aCBhbiBJU08gbnVtYmVyIGFuZCBhbiBJVFUgbnVtYmVyLg0KPiANCj4gVGhlIElU VSBjb25zaXN0ZW50bHkgb3Bwb3NlZCBjb25uZWN0aW9ubGVzcyBhbmQgQ0xOUCBhdCBldmVyeSBv cHBvcnR1bml0eSB0aGV5DQo+IGhhZCBzdGFydGluZyB3aXRoIHRoZSBPU0kgUmVmZXJlbmNlIE1v ZGVsIHRvIGtlZXAgY29ubmVjdGlvbmxlc3Mgb3V0IG9mIE9TSS4gVGhlDQo+IGZpcnN0IGFtZW5k bWVudCB0byB0aGUgT1NJIFJlZmVyZW5jZSBNb2RlbCB3YXMgdG8gYWRkIGNvbm5lY3Rpb25sZXNz IGFuZCB0aGUNCj4gSVRVIGZvdWdodCB0aGF0IHRvb3RoIGFuZCBuYWlsLiAgSXQgd2FzIG9ubHkg dGhyb3VnaCB0aGUgZWZmb3J0cyBvZiAqY29tcHV0ZXINCj4gY29tcGFuaWVzLCogbm90IElUVSBt ZW1iZXJzLCB0aGF0IGNvbm5lY3Rpb25sZXNzIGFuZCBDTE5QIHdhcyB0aGVyZSBhbmQgdGhlDQo+ IHdvcmsgcHJvZ3Jlc3NlZC4NCj4gDQo+IFRoZSBJVFUgbmV2ZXIgd2FudGVkIENMTlAgYW5kIHRo ZSBJRVRGIG9ibGlnZWQgdGhlbS4NCj4gDQo+IFRoZXJlIHdhcyBtb3JlIENMTlAgZGVwbG95ZWQg YW5kIG9wZXJhdGlvbmFsIGluIHRoZSBJbnRlcm5ldCBpbiAxOTkyIHRoYW4gSVB2Ng0KPiBpbiAy MDE0Lg0KPiANCj4gVGhlIElUVSBvd2VzIHRoZSBJRVRGIGFuIGltbWVuc2UgZGVidCBvZiBncmF0 aXR1ZGUgZm9yIGtlZXBpbmcgdGhpcyBpc3N1ZQ0KPiB1bmNlcnRhaW4gZm9yIHRoZSBwYXN0IDI4 IHllYXJzLiAgVGhpcyBoYXMgZ3JlYXRseSBmYWNpbGl0YXRlZCB0aGUgSVRVJ3MgZ3JlYXQgc3Vj Y2Vzcw0KPiBpbiBicmluZ2luZyB0aGUgSUVURiBldmVuIGNsb3NlciB0byB0aGUgSVRVIGRpcmVj dGlvbi4NCj4gDQo+IENvbmdyYXR1bGF0aW9ucy4NCj4gDQo+IEpvaG4NCj4gDQo+IA0KPiANCj4g PiBPbiBBcHIgMTcsIDIwMjAsIGF0IDA2OjQ1LCBWaWN0b3IgUmVpanMgPHZpY3Rvci5yZWlqcz00 MHNpZG4ubmxAZG1hcmMuaWV0Zi5vcmc+DQo+IHdyb3RlOg0KPiA+DQo+ID4gSGVsbG8gYWxsIG9m IHlvdSwNCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBB cmNoaXRlY3R1cmUtZGlzY3VzcyA8YXJjaGl0ZWN0dXJlLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9y Zz4gT24NCj4gPj4gQmVoYWxmIE9mIFMgTW9vbmVzYW15DQo+ID4+IFNlbnQ6IEZyaWRheSwgMTcg QXByaWwgMjAyMCAxMTowOA0KPiA+PiBUbzogVG9lcmxlc3MgRWNrZXJ0IDx0dGVAY3MuZmF1LmRl PjsgYXJjaGl0ZWN0dXJlLWRpc2N1c3NAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFthcmNo LWRdIEVUU0kgbGF1bmNoZXMgbmV3IGdyb3VwIG9uIE5vbi1JUCBOZXR3b3JraW5nDQo+ID4+IGFk ZHJlc3NpbmcgNUcgbmV3IHNlcnZpY2VzDQo+ID4+DQo+ID4+IElQdjYgd2FzIHByb21vdGVkIGFz ICJzZWN1cmUgYnkgZGVmYXVsdCIgYXMgSVBzZWMgd2FzIHBhcnQgb2YgaXQuDQo+ID4NCj4gPiBb VmljdG9yIFJlaWpzXQ0KPiA+IEkgY2FuIHJlbWVtYmVyIHRoYXQgd2hlbiB3ZSB0b2dldGhlciBo YWQgYSBmdWxseSBvcGVyYXRpb25hbCBUVUJBL0NMTlMNCj4gc2VydmljZSBpbiBFdXJvcGUgYW5k IFVTIChyZWFsbHkgOTBzKS4gVGhlIG1pc3Npbmcgb2YgSVBTZWMgd2FzIG9uZSBvZiB0aGUgcmVh c29uDQo+IG5vdCB0byBjaG9vc2UgZm9yIFRVQkEvQ0xOUyAoYmVzaWRlIHRoYXQgaXQgd2FzIGFu IElUVSBzdGFuZGFyZCkuIFRVQkEvQ0xOUw0KPiB3YXMgb25seSBwcm92aWRpbmcgbG9uZ2VyIChm bGV4aWJsZSBsZW5ndGgpIGFkZHJlc3Nlcy4gV2hpbGUgSVB2NiBzaG91bGQgZG8gaW5kZWVkDQo+ IHNlY3VyZSBzdHVmZi4gTm90IG11Y2ggaGFzIG1hdGVyaWFsaXNlIGluIGFsbCB0aGVzZSB5ZWFy cyBkdXJpbmcgd2hpY2ggSVB2NiBuZWVkZWQNCj4gdG8gYmUgZGV2ZWxvcGVkL2RlcGxveWVkLi4u DQo+ID4gQnV0IG9rIHRoYXQgaXMgaW4gdGhlIHBhc3QuDQo+ID4NCj4gPiBJIG5vdyByZWFkIGlu IHRoZSBFVFNJIElTRy1OSU4gZ3JvdXAgdGhhdCB0aGUgbWFqb3IgaXNzdWVzIG5vdCB0byB1c2Ug SVAgaW5zaWRlDQo+IEI1RyBpcyBkZSBhZGRpdGlvbmFsIGNvc3Qgb2Ygc3BlY3RydW0gKHdoaWNo IGlzIHF1aXRlIGxpbWl0ZWQpIGR1ZSB0byB0aGUgbGFyZ2UNCj4gaGVhZGVycyBpbiBJUHY0L3Y2 IGFuZCBtYW55IGVuY2Fwc3VsYXRpb25zIGhhcHBlbmluZy4gRnVydGhlcm1vcmUgY29uZ2VzdGlv bg0KPiBjb250cm9sIGFuZCBRb1MgYXJlIHJlYWxseSBub3Qgc3VwcG9ydGVkIGFuZCB0aGF0IG1p Z2h0IGNhdXNlIHByb2JsZW1zIGZvciByZWFsLQ0KPiB0aW1lIG9yIHRpbWUgY3JpdGljYWwgYXBw bGljYXRpb25zLiBUaGUgSUNBTk4gcmVwb3J0ICg1RyBUZWNobm9sb2d5KSBzYXlzIHRoYXQgSVAN Cj4gY2FuIGFsbCBkbyB0aGF0LCBidXQgd2h5IGFyZSB0aGUgSUNBTk4gYXJndW1lbnRzIG5vdCAo eWV0KSBjb252aW5jaW5nIHRoZSBtb2JpbGUNCj4gb3BlcmF0b3JzPw0KPiA+IEkgdGhpbmsgdGhl IHNwZWNpZmljYXRpb25zIGFyZSBxdWl0ZSBjbGVhciBkZWZpbmVkIGJ5IEVUU0kgTkdQJ3MgS1BJ DQo+IChodHRwczovL3d3dy5ldHNpLm9yZy9kZWxpdmVyL2V0c2lfZ3MvTkdQLzAwMV8wOTkvMDEy LzAxLjAxLjAxXzYwL2dzX05HUDAxDQo+IDJ2MDEwMTAxcC5wZGYgKSBzbyBpdCBtdXN0IGJlICdl YXN5JyB0byBkZXRlcm1pbmUgaWYgSVAgY2FuIG9yIGNhbm5vdCBkbyBpdC4NCj4gPg0KPiA+DQo+ ID4gQWxsIHRoZSBiZXN0IGFuZCBzdGF5IGhlYWx0aHksDQo+ID4NCj4gPiBWaWN0b3IgUmVpanMN Cj4gPiBSZXNlYXJjaCBlbmdpbmVlcjogZnV0dXJlIGludGVybmV0DQo+ID4NCj4gPiBBdHRlbmRh bmNlIChDRVNUKTogTW9uIDguMTUtMTYuNDUgfCBUdWUgOC4xNS0xNi40NSB8IEZyaSA5LjAwLTE3 LjMwDQo+ID4NCj4gPg0KPiA+DQo+ID4gU0lETiB8IE1lYW5kZXIgNTAxIHwgNjgyNSBNRCB8IFBv c3RidXMgNTAyMiB8IDY4MDIgRUEgfCBBUk5IRU0gfCBUaGUNCj4gPiBOZXRoZXJsYW5kcyBUICsz MSAoMCkyNiAzNTIgNTUgMDAgfCBNICszMSAoMCk2IDEyIDQ1IDAwIDExDQo+ID4gdmljdG9yLnJl aWpzQHNpZG4ubmwgfCB3d3cuc2lkbi5ubA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gQXJjaGl0ZWN0dXJlLWRpc2N1c3MgbWFpbGluZyBs aXN0DQo+ID4gQXJjaGl0ZWN0dXJlLWRpc2N1c3NAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FyY2hpdGVjdHVyZS1kaXNjdXNzDQoNCg== From nobody Fri Apr 17 09:13:21 2020 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 6D0803A1038 for ; Fri, 17 Apr 2020 09:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 eLD4eYokGo-Q for ; Fri, 17 Apr 2020 09:13:19 -0700 (PDT) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 1DFD83A1034 for ; Fri, 17 Apr 2020 09:13:19 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id a23so1137036plm.1 for ; Fri, 17 Apr 2020 09:13:19 -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=QTYiqwHb4mthIXCcBnKIz5QEhak8zCPLWw6msVyOPO8=; b=TAw6+x1flSlKupa8JSNQz0eDl3sypQ8Cjc+eQN3qD4pqzGSKjAz7ddRfHozu1YH977 JIOOF8WPycCAVsCB5oVHxkBOmM+Ns0muU0EboFWDn00m/2w3x1my/gqaevG/3l5fQnP3 B4sDYC29eGP2bVbTVvhHjIS8+Mlgs6l6CAAwgiW/IwPQzVj2JUeG+l3mZtultx5O8IvW euuezcldI17Vxi659VX6qT2nngfmoqay2f4WSTe3zzQ+/7YDnJwAC57dVxAvc13w/LF0 E63pRRbhjA9s/CBHuo9E7KEm/2pGm3Yt+x8uU5sxrUp6uCliMDozBO5Pli1IpDWxw8rd 0ecA== 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=QTYiqwHb4mthIXCcBnKIz5QEhak8zCPLWw6msVyOPO8=; b=flQlLAMCTy3PUWHmyRnx8TCB+NdIXeVN7GMBzldAdril39EnloW6XTe6fGqvoi5e3l yhDj0j8LuT9bXAgrQSP/KF63gNHQUKP5fexQaC8cUDPEQQ4gktJVjVnHXl/aKbCjFTmV 6CjJb42+raKAPRauiBrrD/AVIJSgpLfIakEKNvKHt3HcZyz4BjAVCb8Wf7tBiszWGFGl jEcUhOZEE0W6sLMUk2Kyg3nNTV6q1uoyEh2xQ78GoT7kvqyLioVtEhzL+L3YwGpr/nuF EMF7lzlg/PJ2R48rrdQ5RGeogF+Y5K6aL3TXX5vh2CMRVEhplxmEVyAOQqzRiuZjL18R I5Vw== X-Gm-Message-State: AGi0PuYFv1biyJzFvzXgeVdgzo+stIOE7MvbGmCPwrV8h6vk/+vV3Q4B KAG6XAb4vxsSofHZY7oi5SE= X-Google-Smtp-Source: APiQypKnBQTvlcCnZrfdijsxrvSfWDHqCKlwgKkuVcHOCFMb+GzFQVRQLFcjWHnQberYpNdyRVc5Kw== X-Received: by 2002:a17:90b:300a:: with SMTP id hg10mr5322184pjb.42.1587139998510; Fri, 17 Apr 2020 09:13:18 -0700 (PDT) Received: from ?IPv6:2601:646:9600:af10:d52c:a63a:73be:af64? ([2601:646:9600:af10:d52c:a63a:73be:af64]) by smtp.gmail.com with ESMTPSA id a12sm13440378pfr.28.2020.04.17.09.13.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Apr 2020 09:13:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Dino Farinacci In-Reply-To: Date: Fri, 17 Apr 2020 09:13:17 -0700 Cc: Victor Reijs , Toerless Eckert , S Moonesamy , "architecture-discuss@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <4ac9e9fc-41a3-f458-566e-f0a68d26d9ea@huitema.net> <20200416174840.GL41264@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200417010529.0c28ab50@elandnews.com> To: John Day X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 17 Apr 2020 16:13:20 -0000 > TUBA/CLNS was an ISO effort. It is true that it does have a ITU number = but nearly all OSI standards had both an ISO number and an ITU number.=20= This is not true.=20 We did all the TUBA work in the IETF. And we had multiple = implementations running interoperability tests at the Amsterdam IETF in = 1993. Ross Callon, Peter Ford and Richard Colella, among others were = part of the effort. I remember telneting from a cisco router using an NSAP address to telnet = server implementations from Peter and Richard. Dino From nobody Fri Apr 17 09:27:51 2020 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 B26F03A11EB for ; Fri, 17 Apr 2020 09:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 r2FRyl2EZgZL for ; Fri, 17 Apr 2020 09:27:45 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 136AE3A11E5 for ; Fri, 17 Apr 2020 09:27:44 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id ED9C2548054; Fri, 17 Apr 2020 18:27:38 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id E4D8B440055; Fri, 17 Apr 2020 18:27:38 +0200 (CEST) Date: Fri, 17 Apr 2020 18:27:38 +0200 From: Toerless Eckert To: S Moonesamy Cc: architecture-discuss@ietf.org, John C Klensin Message-ID: <20200417162738.GD5351@faui48f.informatik.uni-erlangen.de> References: <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <4ac9e9fc-41a3-f458-566e-f0a68d26d9ea@huitema.net> <20200416174840.GL41264@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200417010529.0c28ab50@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20200417010529.0c28ab50@elandnews.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 17 Apr 2020 16:27:50 -0000 On Fri, Apr 17, 2020 at 02:08:28AM -0700, S Moonesamy wrote: > > Indeed. It is almost puzzling to think that end-to-end > > encryption at IP(sec) level was presumed to be a good > > architectural choice. Besides the obvious beneeit of being > > agnostic to transport protocol choices but then failing on > > ever getting a host stack model that would allow applications > > to leverage it easily. Of couse, luckily we have it (IPsec) > > as there are a lot of other good use cases for it. > > Maybe a bit too much of the "one size fits all" syndrom that > > new technologies by sheer self interest always come to presume ? > > IPv6 was promoted as "secure by default" as IPsec was part of it. It took > many years for the IETF to admit that the technology selected by its central > planning department did not see widespread use. It's a bit like "SEND". Hahaha. Am i assuming correctly that "central planning department" is intentionally written to sound dismissive, or am i just reading that into your text ? We do have an official IETF photographer. Why can't we have an official IETF cartoonist ? I would love to see a rendering of the "central planning department of the IETF". Also the whole discussion about IETF photography, badges and datatracker mugshots would take a real interesting turn if we changed over to cartoons. Kidding aside: i think we need to be careful in not discouraging innovation when it is ambitious. The sole reason why the IETF exists is to create innovation that depends on multiple parties to become active. And the primary place where IPsec IMHO failed to gain adoption is on those parts IETF continues not to want to work in: host-stacks, APIs, (policy) etc.. > Have you ever heard of FILTH [1]? The reference seems to be more about depressing language barriers than technical aspects. But sure, the London led collonialization of the finance industry of this planet is coming to an end (sob ? hurray ? ;-) > There are people who visit what is > sometimes referred to as an undeveloped country. Some of those people tout > their affiliation with the IETF to convince entities in that country to > deploy a technology on the premise that it is used in advanced countries. I have only seen few bits and pieces about those IETF outreach programs, but it was all from people i respect and activites i felt where useful, so i have no example data points to be cynical about. > The "one size fits all" rarely works. In India, subsistence farmers get updates of different city market prices realtime via SMS on their cell phones so they know where to sell their produce. In Germany, Corona case tracking is delayed for days through a multi-stage series or FAX between different bureaucracies that manually process and propagate information. Maybe IPv6 was specifically architected not to be too much better than IPv4 to ensure that developing countries that can skip IPv4 and start with simple IPv6 greenfields can not leap ahead of "developed" nations with all their historic IPv4 baggage too much. Cheers Toerless > > Regards, > S. Moonesamy > > 1. http://r.elandsys.com/r/10933 From nobody Fri Apr 17 11:03:53 2020 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 AE3ED3A0D77 for ; Fri, 17 Apr 2020 11:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 OGLG0J5ET5ac for ; Fri, 17 Apr 2020 11:03:49 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (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 CAEF83A0D5C for ; Fri, 17 Apr 2020 11:03:49 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-09v.sys.comcast.net with ESMTP id PUqTjiZV5dWWZPVLAjio2z; Fri, 17 Apr 2020 18:03:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1587146628; bh=3GOjOzPm8FZzbYnfdA51absbVn5TPAk7jxQXEKWadVI=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=FYEaLMt193OO1QjK8mUj6H+MV7BHIr1x2iPoVXIN5UXFMxAF3Pu1QL5tviYNlXANB qPpffHHsiP29s/pw3AyQgt5PazEujG3sakGWD7MVAT2fp+f1rlTOFs85WikCLfPkdU e61WF82wY6BAuMqi7s9ETuYEywtAQ3X6hC/WOubsVoRCDaIUddbSLm20Gm0iJvmm2V AU+yzinrjIm6DYX+OvMB1VtJpPi9sr5/+tgwK97Oc7Ett8uE0Y57ZxyvlC7zVzV2qx B7pwHkIPMG9v+cVzCezbUV1rIdL04C8kV4V1jl+KIIDu6Bp8vdfYAlSHi343zZbb4K 1bWB337KIa65g== Received: from [IPv6:2601:189:4300:cee9:48a:1a1c:36e9:cf55] ([IPv6:2601:189:4300:cee9:48a:1a1c:36e9:cf55]) by resomta-ch2-18v.sys.comcast.net with ESMTPA id PVKojbxAXOACIPVKpjjzi3; Fri, 17 Apr 2020 18:03:28 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: John Day In-Reply-To: Date: Fri, 17 Apr 2020 14:03:25 -0400 Cc: "architecture-discuss@ietf.org" , Victor Reijs , Toerless Eckert , S Moonesamy Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <4ac9e9fc-41a3-f458-566e-f0a68d26d9ea@huitema.net> <20200416174840.GL41264@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200417010529.0c28ab50@elandnews.com> To: Dino Farinacci X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 17 Apr 2020 18:03:52 -0000 thanks for the correction. Yes, the TUBA adaption of CLNP was done in = the IETF. However, CLNP was an ISO effort. > On Apr 17, 2020, at 12:13, Dino Farinacci wrote: >=20 >> TUBA/CLNS was an ISO effort. It is true that it does have a ITU = number but nearly all OSI standards had both an ISO number and an ITU = number.=20 >=20 > This is not true.=20 >=20 > We did all the TUBA work in the IETF. And we had multiple = implementations running interoperability tests at the Amsterdam IETF in = 1993. Ross Callon, Peter Ford and Richard Colella, among others were = part of the effort. >=20 > I remember telneting from a cisco router using an NSAP address to = telnet server implementations from Peter and Richard. >=20 > Dino >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Fri Apr 17 12:11:34 2020 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 7FF223A0AC2 for ; Fri, 17 Apr 2020 12:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sidn.nl 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 ggP7jF8auGLA for ; Fri, 17 Apr 2020 12:11:29 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50071.outbound.protection.outlook.com [40.107.5.71]) (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 EFC983A0AAA for ; Fri, 17 Apr 2020 12:11:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nQ6fFwH5X6F4ToO5ME4OwHTPCXejDYEt+w7tnNFOHrIWFh8LEyaKeYPaWFNnlH5UdyUCmOqdpWsFwFEMV3fXhOWS52DwnP/7MSBGaXgnX9+Pzc2ir9LdCBvCPYdxXap4WEXS1IWek0UTFcG1ncFWIyeyC6MamZu1hXvZby6vPLKAULw1X45tLEzQMxoRvJOCaOk4P6ZQLZUotQbqsLnfAP9EhvatQE098fVo5zsWBStmVZLHKKHCUWGHtRfJZ6/6li3Zx1Yn8JrI0e1LaBX+00cJ3AL2zvm6OAPMj1sv2X3R+V03lEj587cOQTmySvyKzhD5StVfM9Rp+EYMhM8hzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bUdctrd6oWMO6TyGZ6nlB93X33pI44SumBUkb3EoGwU=; b=U26qa1vVipkxqudZjdl4HvYIHgQYoCjOKa7cyCUpCmTjZER0/MCh/LOLMbS/Md/y7MjwA2/aWXnPho71AfDM0mfE0X4CQvUOX0zpZCGNVzYwI4DcC0h8rCJTR/+C2SEKXcgJO5kmo9ktf9XCL3iv1uyqbAVKX+ouAvkVn5SLJoliLv/8i7gWKx8i7bPCwF/eZ4STQ2TUHCxm9Zer9JxJ5sK/MB0zo0L5bNO2vNnxOa1ajMVyHREKobyqA3CWlBVLQePjU2bulC+//n30g0Yz3ObDn2BOHZON3x02fa+DpaPXS2lfamxNFZPLmf9wGhyhJgXx8TDuAQfq/FYTMVC5qw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sidn.nl; dmarc=pass action=none header.from=sidn.nl; dkim=pass header.d=sidn.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sidn.nl; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bUdctrd6oWMO6TyGZ6nlB93X33pI44SumBUkb3EoGwU=; b=qNcDTAsVRpJU1ZPEkjqE+W3xiogDhyAF2XPfSImeUkLJes8iCU+HYrxulMfdjd49LF4IfYkLpeIAkoYQ3wCr9AhtGoGGAAK9Cqv6K7nIjIsy+NTHyz9SE3HNTlY64kGe1zx+lQIvHEpQziA08smdG1K8MqD5acutMsB2Dl5Z42Y= Received: from AM0P194MB0593.EURP194.PROD.OUTLOOK.COM (2603:10a6:20b:166::19) by AM0SPR01MB0060.EURP194.PROD.OUTLOOK.COM (2603:10a6:208:18d::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.25; Fri, 17 Apr 2020 19:11:19 +0000 Received: from AM0P194MB0593.EURP194.PROD.OUTLOOK.COM ([fe80::6012:af08:ebd9:57ad]) by AM0P194MB0593.EURP194.PROD.OUTLOOK.COM ([fe80::6012:af08:ebd9:57ad%8]) with mapi id 15.20.2900.030; Fri, 17 Apr 2020 19:11:18 +0000 From: Victor Reijs To: John Day , Dino Farinacci CC: "architecture-discuss@ietf.org" , Toerless Eckert , S Moonesamy Thread-Topic: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services Thread-Index: AQHWDWJyhUWBPnI3wkiq6mi66DMYhahuqlAAgAALyACAAN4dAIAADIkAgADi6gCAADPdgIAAGZYAgABD94CAADYPAIAByMIAgARb1ACABKQKAIABAP0AgAAXdVCAAEKiAIAAHJuAgAAexYCAABEWIA== Date: Fri, 17 Apr 2020 19:11:18 +0000 Message-ID: References: <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <4ac9e9fc-41a3-f458-566e-f0a68d26d9ea@huitema.net> <20200416174840.GL41264@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200417010529.0c28ab50@elandnews.com> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=victor.reijs@sidn.nl; x-originating-ip: [213.127.1.166] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 14808e6e-e031-407b-a767-08d7e3031bef x-ms-traffictypediagnostic: AM0SPR01MB0060: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0376ECF4DD x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P194MB0593.EURP194.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39840400004)(366004)(136003)(376002)(346002)(396003)(66556008)(64756008)(66476007)(8936002)(76116006)(66446008)(52536014)(44832011)(54906003)(316002)(110136005)(15974865002)(66946007)(9686003)(4326008)(2906002)(86362001)(6506007)(966005)(478600001)(26005)(33656002)(7696005)(83080400001)(53546011)(55016002)(71200400001)(66574012)(186003)(5660300002)(81156014)(8676002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: sidn.nl does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JXlAPCPAXanKDYL3lW0GVbgBqRVyNh9Tk3RBa4qgiUVOa0G94aQxSq8SzpdgJHzobJ5Ampgz4+cD5bQ7OlEWwDv3bJJTQg/ijeTP8g6p2M36v3JQIyaLA03Hwm2bC6o07jyZ902Z3lI6z/WLH74p6attn7fxDEE0dKjyw5YTS8MkJBNXnjDn2Fisb7bEiyt9WfM3MkIFCF/1+SqiWEKpbd7tFgCkOuQOeX0RBEqgnWhynCKaUJXZw6LTaSMy76jxqCj64JML3xm/8WnXHA0Hr7wK+YhBsqhHcTBPXVwh6MWpAjhUfF/Inlyh8+plumBA8SkVzQPLio8D0YgtVJJZWvTGYANTQZvIFzlw4oEShcPBoDBj5cRBErNLFW5FwF0qi86b3syGaSQclv9NT5micY8TSzX9oIgvcXM7LKru6gV0u3+DNJ9Dggu9AfYTAskJCyvU9dOchxg4+Y/f7T6kxoww9wADWFkYyb6wxtDGTZ5NtcImrzg+NgKt78IKl4IvdHtn/5JqwqwLb5xzJdBrEA== x-ms-exchange-antispam-messagedata: 3gviqNZs/QRwlZ/rvR5jragiU9FA3RIimiIpke0lTqLzF4e/89W0tJ0dC5oF3KGXa67DQY0NC8z0bnRIkO8LfmtwdluRUnwKxH2JpSwcBFL6hL/0uLBi/FMP5pI9RPlzP1xrDoHBXj+wIhVZOplXrHhsU2MwM8/5Ve3VMOmA6FHKIU81fHdxxJjpolbg7C3xXGhnEcjnIZuH0kwJKV/Ah1tvSK/XFR3/yerXIz/6Mnq3iZ3DthXOnVlnmCc/Zco4Hlso+gKtHBkLDnbRsyi1/GRzab55tmVaDxLbkT9g3LpgAwdxwGY5ZyxHTid3GKFQdnmhoJWLX/9nVy0Ce5k9hMIZiyMAayIyQGDcUgcrGPc+3ZGHMiB4amAF42EQlBVJMDow7jjeK/iftkNDeTf4626UVBCQlQQ2NzNhUsgELljVWoIycS/qbZrIbQ/pOytwTWFkJwS9KiO14iXO4tf170PjFSxPMQIKQd5GJ8l8JvuqnDKi0Mn70/uFhXzRt34dV4HFteK8iN+ELfNYR7GejW7Hw0r+2hC4/G+2HY0Lz1x4RuO8M2AfY+UOu5J2hvKBbtgaVdgRBngTYcPSvtgirKy4MxrH5GWyXBLBH/tu5Ks2C1QszpQqzVSh4rxQjAdL7tNL7eRwl+2jN0YzLkWqltbwoq9oqy7D4YFwmcJtWZNdnwo2UibIqdj/Og0Ug6XTRefs8ivyFCworKyMjGC4zCLPzzCKRvpp5VJbqwTO4Cb0F896uN7vMVJ3PTxbkANzEUi867LvRKWvWPKbEw149hwnf9rSpEataExObuaj98Y= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sidn.nl X-MS-Exchange-CrossTenant-Network-Message-Id: 14808e6e-e031-407b-a767-08d7e3031bef X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2020 19:11:18.7171 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ab4d3626-c1c5-4a75-ab85-427f1a644a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: DU/BhLVJXUt38WphThxp1JlBNEpr3PDIjGMB3n2PBtb1ubePloJ6FFIWTTO0mKQbx/GLAkVduxGpyVOvJzz0ng== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0SPR01MB0060 Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 17 Apr 2020 19:11:33 -0000 VG9nZXRoZXIgd2l0aCBKdWhhIEhpbmFuZW4gZm9yIGluc3RhbmNlIGFuZCBtYW55IG90aGVyIE5S RU5zIGluIEV1cm9wZSBhbmQgdG9nZXRoZXIgdGhlIHBlb3BsZSBpbiBVU0EgKEkgdGhpbmsgYSBm ZXcgcGVvcGxlIG9mIE1FUklUIHBsYWlkIGEgbGFyZ2Ugcm9sZSBpbiBkZXZlbG9waW5nIElTLUlT IGFuZCBJRFJQKSBhbmQgdG9nZXRoZXIgd2l0aCAgQ2lzY28gd2UgYnVpbGQgYW5kIHRlc3RlZCB0 aGlzIGxhcmdlIENMTlMgbmV0d29yayBvbiBhIG11bHRpLXByb3RvY29sIG5ldHdvcmsgKHBhcnRs eSBLUE4gaW4gRXVyb3BlKS4gDQpXZSBoYWQgcHJpbnRlZCBhIGdyZWF0IFQtc2hpcnQgd2l0aCB0 aGUgVHViYSBzeW1ib2wgb24gaXQsIEkgc3RpbGwgZmluZCBpdCBhIHBpdHkgSSB0aHJldyBpdCBh d2F5ISBJdCB3b3VsZCBoYXZlIGJlZW4gYSByZWFsIGNvbGxlY3RvcnMgaXRlbS4NCg0KV2UgdXNl ZCB0aGUgZmlyc3QgSVMtSVMgaW1wbGVtZW50YXRpb25zICh3aGljaCBpcyB0aGUgb25seSB0aGlu ZyB0aGF0IGlzIGxlZnQgb2YgdGhpcyBwcm9qZWN0KSBhbmQgd2Ugd2VyZSBqdXN0IGluIHRoZSBt aWRkbGUgb2YgZGV2ZWxvcGluZyBJRFJQICh0aGUgQkdQIGluIHRoZSBDTE5TIGVudmlyb25tZW50 KSwgYW5kIHRoZW4gY2FtZSB0aGUgZGVjaXNpb24gdG8gZ28gd2l0aCBJUHY28J+YiS4NCg0KSSBt dXN0IGhhdmUgc29tZSBFUFJPTXMgZm9yIGNpc2NvIHJvdXRlciB3aXRoIHRoZSBlYXJseSBjb2Rl IHNvbWV3aGVyZS4gV291bGQgYmUgbmljZSB0byBwbGFuIGEgcmV1bmlvbi4NCg0KQWxsIHRoZSBi ZXN0IGFuZCBzdGF5IGhlYWx0aHksDQoNCg0KVmljdG9yIFJlaWpzDQpSZXNlYXJjaCBlbmdpbmVl cjogZnV0dXJlIGludGVybmV0DQoNCkF0dGVuZGFuY2UgKENFU1QpOiBNb24gOC4xNS0xNi40NSB8 IFR1ZSA4LjE1LTE2LjQ1IHwgRnJpIDkuMDAtMTcuMzANCg0KDQoNClNJRE4gfCBNZWFuZGVyIDUw MSB8IDY4MjUgTUQgfCBQb3N0YnVzIDUwMjIgfCA2ODAyIEVBIHwgQVJOSEVNIHwgVGhlIE5ldGhl cmxhbmRzDQpUICszMSAoMCkyNiAzNTIgNTUgMDAgfCBNICszMSAoMCk2IDEyIDQ1IDAwIDExDQp2 aWN0b3IucmVpanNAc2lkbi5ubCB8wqB3d3cuc2lkbi5ubA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IEpvaG4gRGF5IDxqZWFuam91ckBjb21jYXN0Lm5ldD4NCj4gU2Vu dDogRnJpZGF5LCAxNyBBcHJpbCAyMDIwIDIwOjAzDQo+IFRvOiBEaW5vIEZhcmluYWNjaSA8ZmFy aW5hY2NpQGdtYWlsLmNvbT4NCj4gQ2M6IGFyY2hpdGVjdHVyZS1kaXNjdXNzQGlldGYub3JnOyBW aWN0b3IgUmVpanMgPHZpY3Rvci5yZWlqc0BzaWRuLm5sPjsgVG9lcmxlc3MNCj4gRWNrZXJ0IDx0 dGVAY3MuZmF1LmRlPjsgUyBNb29uZXNhbXkgPHNtK2lldGZAZWxhbmRzeXMuY29tPg0KPiBTdWJq ZWN0OiBSZTogW2FyY2gtZF0gRVRTSSBsYXVuY2hlcyBuZXcgZ3JvdXAgb24gTm9uLUlQIE5ldHdv cmtpbmcgYWRkcmVzc2luZw0KPiA1RyBuZXcgc2VydmljZXMNCj4gDQo+IHRoYW5rcyBmb3IgdGhl IGNvcnJlY3Rpb24uIFllcywgdGhlIFRVQkEgYWRhcHRpb24gb2YgQ0xOUCB3YXMgZG9uZSBpbiB0 aGUgSUVURi4NCj4gSG93ZXZlciwgQ0xOUCB3YXMgYW4gSVNPIGVmZm9ydC4NCj4gDQo+ID4gT24g QXByIDE3LCAyMDIwLCBhdCAxMjoxMywgRGlubyBGYXJpbmFjY2kgPGZhcmluYWNjaUBnbWFpbC5j b20+IHdyb3RlOg0KPiA+DQo+ID4+IFRVQkEvQ0xOUyB3YXMgYW4gSVNPIGVmZm9ydC4gSXQgaXMg dHJ1ZSB0aGF0IGl0IGRvZXMgaGF2ZSBhIElUVSBudW1iZXIgYnV0DQo+IG5lYXJseSBhbGwgT1NJ IHN0YW5kYXJkcyBoYWQgYm90aCBhbiBJU08gbnVtYmVyIGFuZCBhbiBJVFUgbnVtYmVyLg0KPiA+ DQo+ID4gVGhpcyBpcyBub3QgdHJ1ZS4NCj4gPg0KPiA+IFdlIGRpZCBhbGwgdGhlIFRVQkEgd29y ayBpbiB0aGUgSUVURi4gQW5kIHdlIGhhZCBtdWx0aXBsZSBpbXBsZW1lbnRhdGlvbnMNCj4gcnVu bmluZyBpbnRlcm9wZXJhYmlsaXR5IHRlc3RzIGF0IHRoZSBBbXN0ZXJkYW0gSUVURiBpbiAxOTkz LiBSb3NzIENhbGxvbiwgUGV0ZXINCj4gRm9yZCBhbmQgUmljaGFyZCBDb2xlbGxhLCBhbW9uZyBv dGhlcnMgd2VyZSBwYXJ0IG9mIHRoZSBlZmZvcnQuDQo+ID4NCj4gPiBJIHJlbWVtYmVyIHRlbG5l dGluZyBmcm9tIGEgY2lzY28gcm91dGVyIHVzaW5nIGFuIE5TQVAgYWRkcmVzcyB0byB0ZWxuZXQg c2VydmVyDQo+IGltcGxlbWVudGF0aW9ucyBmcm9tIFBldGVyIGFuZCBSaWNoYXJkLg0KPiA+DQo+ ID4gRGlubw0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPiBBcmNoaXRlY3R1cmUtZGlzY3VzcyBtYWlsaW5nIGxpc3QNCj4gPiBBcmNo aXRlY3R1cmUtZGlzY3Vzc0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vYXJjaGl0ZWN0dXJlLWRpc2N1c3MNCg0K From nobody Fri Apr 17 12:49:16 2020 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 733AC3A139B for ; Fri, 17 Apr 2020 12:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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=comcast.net 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 0kv7ljdgO8NA for ; Fri, 17 Apr 2020 12:49:07 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (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 AFA5A3A1374 for ; Fri, 17 Apr 2020 12:49:03 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-10v.sys.comcast.net with ESMTP id PWLrjEiMBQCNTPWz0jRSK1; Fri, 17 Apr 2020 19:49:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1587152942; bh=62yK2spCgVG5Vw7DUpa+MZURWPxeyJAJzh104eMD2Zg=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=bba3OzppmjOKUcfFEyeFEHY57OKNBCYurKjrRnrXan9SnR45FQK9BhwqXYZUE06Hn qPsPthr45w9aiRCdmsLxd2qK3RfntQslrA3twXGVDD4uafI8d0eGt8tRsAphCLuZsI rqTjciyOANSPd2pPwQqMEYvcrTM1WuBRAAarUK4mrH+zkjEAN1/DbGfhwakUE7qKCj aigwkZgg7tTVm4on6MnBnOq+GRgVkW2leRHH6c64QiI85us2NOkCtt2/yglNkaRpGi AH6qgzvlZLfjvWM1zXRc1IHZcHfBV3dJNdDDyc//tcxTRSr2OQuTLu1zG2oYbKLP0H W0add66BFD7jw== Received: from [IPv6:2601:189:4300:cee9:48a:1a1c:36e9:cf55] ([IPv6:2601:189:4300:cee9:48a:1a1c:36e9:cf55]) by resomta-ch2-09v.sys.comcast.net with ESMTPA id PWyvjSoGLvglJPWywjjlZ3; Fri, 17 Apr 2020 19:48:59 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: John Day In-Reply-To: Date: Fri, 17 Apr 2020 15:48:55 -0400 Cc: "architecture-discuss@ietf.org" , Victor Reijs , Toerless Eckert , S Moonesamy Content-Transfer-Encoding: quoted-printable Message-Id: <638C298A-F60B-4479-882D-64AFF0F11092@comcast.net> References: <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <4ac9e9fc-41a3-f458-566e-f0a68d26d9ea@huitema.net> <20200416174840.GL41264@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200417010529.0c28ab50@elandnews.com> To: Dino Farinacci X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 17 Apr 2020 19:49:15 -0000 Dave Katz, Dave Oran, Lyman Chapin, Sue Hares, those guys and some = others. They were the ones who were doing CLNP, IS-IS, IDRP, etc. It was = a top-notch crew. > On Apr 17, 2020, at 12:13, Dino Farinacci wrote: >=20 >> TUBA/CLNS was an ISO effort. It is true that it does have a ITU = number but nearly all OSI standards had both an ISO number and an ITU = number.=20 >=20 > This is not true.=20 >=20 > We did all the TUBA work in the IETF. And we had multiple = implementations running interoperability tests at the Amsterdam IETF in = 1993. Ross Callon, Peter Ford and Richard Colella, among others were = part of the effort. >=20 > I remember telneting from a cisco router using an NSAP address to = telnet server implementations from Peter and Richard. >=20 > Dino >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Fri Apr 17 13:38:10 2020 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 669663A141B for ; Fri, 17 Apr 2020 13:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 uWj3Mc4HTSRS for ; Fri, 17 Apr 2020 13:38:02 -0700 (PDT) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (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 2A0303A1477 for ; Fri, 17 Apr 2020 13:36:34 -0700 (PDT) Received: by mail-pj1-x1030.google.com with SMTP id 7so2523290pjo.0 for ; Fri, 17 Apr 2020 13:36:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=v/294OE03jSY3QXXLuFSUv6oG2xWSsr00MqySJ7sZrg=; b=Qd3JOi+0hjm5gmNhsLUeHqRR1yBgv6S6vnsn+Qcu+MGyCFcFEdJeR3XKj2/n+UYlXC FI/3ypVXt9EoKsWhyYLBQ3sA+SOtyBWjAkVnGk6OqBg0fF13HZpX911Pkjb6NBt4U8qK AvNwxhNsfcYfOLs7MP4UekJsbNz78jJLTsYF3R3BqFr6HlbtHW2pFkFygXXv/NNQ8m/7 fWfeVs2R/ZcoLsMUNkaGkttINCaCJD+OIClU4ezV3p0U4HGdyz8q4otysTRROa7EmbZW uCBtPQBhZxOQmsuZFNKuEXYxjP7EOo5MnYYEPNy87JjT7U+oH2+XJHF48P7CcDfayqf7 k1Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=v/294OE03jSY3QXXLuFSUv6oG2xWSsr00MqySJ7sZrg=; b=ee7hNOSRR90AESEMp8JJuY5uh2AAABUPlGydMxKGxrQK3Q2sV8comv+xYZLpuxUUb8 b+AN8mdYBAtpV1G/mnWsqSWtFEJ1xVFM7QKRD+/wIFr8M2XybgLCgMO07p2uj7ratpux ZFwQzFsBD/uWcHRnMSj0ue5R/aANsVLiOR12zNDWfTATfOzBxvVsI/1Pgll+nKzZRGNY tZa5N2eVNTnkVjTT2icn7yCc26ZT9Qr47BIjlR/kAOUYThLoEo9JcJPmjqitTOs9P3Qf TamtoTPgs2d8eB39XnNnU0+tc3BchkZA1Fw1L8XFJcmlLyxDYcQsz+8NcEGwrQl47n0c ahWw== X-Gm-Message-State: AGi0PubDItHW9bpYtze+CNC+0izPWV0l3TfW1Hr0DCcArmnBH/S9sNiX 9gfjG8nwWVutSyqgtXOBLAo= X-Google-Smtp-Source: APiQypK/As+9E4TAOVEv6eNSICaTxYJkBhf8F6nqWB6GZCX7f0ThG72KmmBla5DiJnwjrFkI7nTwjw== X-Received: by 2002:a17:90a:2170:: with SMTP id a103mr6647548pje.181.1587155787649; Fri, 17 Apr 2020 13:36:27 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id a23sm14539968pfo.145.2020.04.17.13.36.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Apr 2020 13:36:26 -0700 (PDT) To: Dino Farinacci , John Day Cc: "architecture-discuss@ietf.org" , Victor Reijs , Toerless Eckert , S Moonesamy References: <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <4ac9e9fc-41a3-f458-566e-f0a68d26d9ea@huitema.net> <20200416174840.GL41264@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200417010529.0c28ab50@elandnews.com> From: Brian E Carpenter Message-ID: <160aa8e9-1557-437f-747e-b989bffc7794@gmail.com> Date: Sat, 18 Apr 2020 08:36:21 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 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] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 17 Apr 2020 20:38:09 -0000 On 18-Apr-20 04:13, Dino Farinacci wrote: >> TUBA/CLNS was an ISO effort. It is true that it does have a ITU number but nearly all OSI standards had both an ISO number and an ITU number. > > This is not true. > > We did all the TUBA work in the IETF. And we had multiple implementations running interoperability tests at the Amsterdam IETF in 1993. Ross Callon, Peter Ford and Richard Colella, among others were part of the effort. > > I remember telneting from a cisco router using an NSAP address to telnet server implementations from Peter and Richard. > > Dino Also, we signed a peace treaty of sorts with the ISO people: https://tools.ietf.org/html/rfc1888 Of course that led nowhere in practice, as I expected at the time. Brian From nobody Fri Apr 17 13:45:46 2020 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 A20ED3A0F7A for ; Fri, 17 Apr 2020 13:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 X6z9Vh18KB1W for ; Fri, 17 Apr 2020 13:45:36 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 686453A146C for ; Fri, 17 Apr 2020 13:44:22 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id n16so1654421pgb.7 for ; Fri, 17 Apr 2020 13:44:22 -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=VRabqy58EoFyghGlOQgPSkYmWW9//EPqHvN6u2738QE=; b=g8EkjfAlVwsw/hyzXqrcBn3F7DjMXn/40YGqcCaRlnI1SzDcEV4GTruj9nrG6MdeGW ctum6C4rbxiFkJipiiYLIXvbU3Ju/0YLdouZDX6oxfB0mIS5XYAgy6Rft9Po7u6vtGFd q59AiYTCAsWy26Sgmljre1+zDIkTRPw/1P/Eutk5Pf63ezwFKfvZW8NYIiTDoegLc9WW w113IY75mlVbPlHSO1aRvzvGcPqm7d5N5gkpjqa4t/3KLEtlSH0+p3mTjjsONpzX7rSS kri18u0zzsWYdsdRIzoQxWI1NAZ61NBaUVapOQIashbL+MgYDV1XYQvPKBMkqFjyvHWc OaRw== 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=VRabqy58EoFyghGlOQgPSkYmWW9//EPqHvN6u2738QE=; b=kndd30HIo5FVWojSQ/MteWDWzKH31Zg/QsFA+QaoAY6HIzhZhooiTgDHQvY8dSaLXo YzUSQwUdVyn7p/NHthCb0LkqTd6+TMvUHqZ+sjtOZAK53G4YjUxcOqcHOJLskjY+X5Ds lZxQ3O83v/wTXJ1rzLxxgh5oLKWBgCeDP5SIIytJVBqEoigZ2BeVswJw/Eap0h9thHX3 BJfXTmDRNMAt9hYsgJFmnX1OxUnQ1mB26Dsb0bgMDErNm90QjDBLt2eyY+z+jCAQT6pr QG3jI+wUd63KKnZRDcxL2Y8zaLxSUFcHhrfpDnJ+zM5IHTzzXrzmUWBNTN7r4873iOav sAjg== X-Gm-Message-State: AGi0PuZA2Y3nIbf+sSO8VOMzm4ib3yBp5K8Wk/GbOcruiDO+AnKsyIxy EpKyZm/p4KN/KyzH4PbXaK5A2QAKd8k= X-Google-Smtp-Source: APiQypLBaGbs0xsLJoHQsazsb+iOuvYiF+i0BJ1gV8Pk4unpwNaN2n8l2/jodHjW8H+ZmxuLduG3Jg== X-Received: by 2002:aa7:97a6:: with SMTP id d6mr5002789pfq.92.1587156261256; Fri, 17 Apr 2020 13:44:21 -0700 (PDT) Received: from ?IPv6:2601:646:9600:af10:d52c:a63a:73be:af64? ([2601:646:9600:af10:d52c:a63a:73be:af64]) by smtp.gmail.com with ESMTPSA id d20sm2219574pjs.12.2020.04.17.13.44.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Apr 2020 13:44:20 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Dino Farinacci In-Reply-To: <638C298A-F60B-4479-882D-64AFF0F11092@comcast.net> Date: Fri, 17 Apr 2020 13:44:19 -0700 Cc: "architecture-discuss@ietf.org" , Victor Reijs , Toerless Eckert , S Moonesamy Content-Transfer-Encoding: quoted-printable Message-Id: <64BE71E0-2FCC-42A0-8AF5-CC5D485A825A@gmail.com> References: <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <4ac9e9fc-41a3-f458-566e-f0a68d26d9ea@huitema.net> <20200416174840.GL41264@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200417010529.0c28ab50@elandnews.com> <638C298A-F60B-4479-882D-64AFF0F11092@comcast.net> To: John Day X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 17 Apr 2020 20:45:44 -0000 Don=E2=80=99t forget Yakov and Tony Li. Dino > On Apr 17, 2020, at 12:48 PM, John Day wrote: >=20 > Dave Katz, Dave Oran, Lyman Chapin, Sue Hares, those guys and some = others. They were the ones who were doing CLNP, IS-IS, IDRP, etc. It was = a top-notch crew. >=20 >> On Apr 17, 2020, at 12:13, Dino Farinacci = wrote: >>=20 >>> TUBA/CLNS was an ISO effort. It is true that it does have a ITU = number but nearly all OSI standards had both an ISO number and an ITU = number.=20 >>=20 >> This is not true.=20 >>=20 >> We did all the TUBA work in the IETF. And we had multiple = implementations running interoperability tests at the Amsterdam IETF in = 1993. Ross Callon, Peter Ford and Richard Colella, among others were = part of the effort. >>=20 >> I remember telneting from a cisco router using an NSAP address to = telnet server implementations from Peter and Richard. >>=20 >> Dino >>=20 >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 From nobody Fri Apr 17 13:48:17 2020 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 A61A13A144C for ; Fri, 17 Apr 2020 13:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKryUD2jebzs for ; Fri, 17 Apr 2020 13:48:10 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 5539A3A14B8 for ; Fri, 17 Apr 2020 13:45:37 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id w11so1640684pga.12 for ; Fri, 17 Apr 2020 13:45:37 -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=eDu+ZmUqsBAO2kIRCN2Qhb15cZi0rZVpdbBPSvab2R8=; b=Ggl6Mg5a8I3WGug1YAY4TGzTAkWPgmG7Tzt0YudMOJi4MyqGS5h/EQmIvnSJ9KRI6T b1CuL14+qEDwcfQQODiZmN9ASsopLBlble2zHBTQqgkb5y7JscMd72yeqiVXLdPsJc0Q GuKdJP3Wq6+L94QaCfmlNOadZoPOuidpMTqqb6Xd9CEh7Lz8poVA1eVOE2+2b2t2TfEZ 6nLG05D01Wa4vvsupksxDyo/NDZqtqNpvuBeRUaCpmPpJM8a0RhLcoPMhk/bU6k2jwXe gJRSpv3RZkC2yvpJVMD2I3Xa2TPrGWXq5Q4O8K9zEe6OSWWL7+aWSzWtZ21f2AMXTDzh Mh4A== 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=eDu+ZmUqsBAO2kIRCN2Qhb15cZi0rZVpdbBPSvab2R8=; b=BTP3HsDZoc8yJMrU1YuzM+NfWiY1K+6xEWa4YZ7dxRNPiSAgWD755qcR1SnrUqHCB/ IYRxDLNjmqxQKWjKm4xkzdJATM+sZ5nh37jOeI7J1L0u8ybnw78JLlQI+oG9VbkwHU65 i5rCs6Qr5UsO3CwTt23vdO1mKA4gADs/nvATf8Uf02TEDgX3bmCxqp+CHkw1gI7xBd9j jaXSRpJcVNmZm8oT9PbxTuHoIo8UaAikRI4vvWNkfDt6IBHgJ5LuTUIH+nhRdWmnX8o8 f8s9ThAhxXTMGVjcfC0RyAM9duVY4dUGTRDaO4PoLrTCIRcJ4tcWhU9jhBspSWG5sftq TlIw== X-Gm-Message-State: AGi0PuYFcvOnqlqr3F6c7eOix9jO7I1zwp6efmB415ZUz+p1uKhobAoL 4RHez+7LxtR8b38fwebU65Q= X-Google-Smtp-Source: APiQypKkDev3fRt8ir9nqMefT0p07jG5pAiTT8Vi21d3cd3Okk+zS9kXmvrWYvZgj5AW4CkA9Wwq7A== X-Received: by 2002:a62:18c8:: with SMTP id 191mr5139527pfy.255.1587156335736; Fri, 17 Apr 2020 13:45:35 -0700 (PDT) Received: from ?IPv6:2601:646:9600:af10:d52c:a63a:73be:af64? ([2601:646:9600:af10:d52c:a63a:73be:af64]) by smtp.gmail.com with ESMTPSA id x4sm20422086pfa.191.2020.04.17.13.45.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Apr 2020 13:45:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Dino Farinacci In-Reply-To: Date: Fri, 17 Apr 2020 13:45:33 -0700 Cc: John Day , "architecture-discuss@ietf.org" , Toerless Eckert , S Moonesamy Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <4ac9e9fc-41a3-f458-566e-f0a68d26d9ea@huitema.net> <20200416174840.GL41264@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200417010529.0c28ab50@elandnews.com> To: Victor Reijs X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 17 Apr 2020 20:48:15 -0000 Victor, thanks for the stroll down memory lane! Dino > On Apr 17, 2020, at 12:11 PM, Victor Reijs = wrote: >=20 > Together with Juha Hinanen for instance and many other NRENs in Europe = and together the people in USA (I think a few people of MERIT plaid a = large role in developing IS-IS and IDRP) and together with Cisco we = build and tested this large CLNS network on a multi-protocol network = (partly KPN in Europe).=20 > We had printed a great T-shirt with the Tuba symbol on it, I still = find it a pity I threw it away! It would have been a real collectors = item. >=20 > We used the first IS-IS implementations (which is the only thing that = is left of this project) and we were just in the middle of developing = IDRP (the BGP in the CLNS environment), and then came the decision to go = with IPv6=F0=9F=98=89. >=20 > I must have some EPROMs for cisco router with the early code = somewhere. Would be nice to plan a reunion. >=20 > All the best and stay healthy, >=20 >=20 > Victor Reijs > Research engineer: future internet >=20 > Attendance (CEST): Mon 8.15-16.45 | Tue 8.15-16.45 | Fri 9.00-17.30 >=20 >=20 >=20 > SIDN | Meander 501 | 6825 MD | Postbus 5022 | 6802 EA | ARNHEM | The = Netherlands > T +31 (0)26 352 55 00 | M +31 (0)6 12 45 00 11 > victor.reijs@sidn.nl | www.sidn.nl >=20 >> -----Original Message----- >> From: John Day >> Sent: Friday, 17 April 2020 20:03 >> To: Dino Farinacci >> Cc: architecture-discuss@ietf.org; Victor Reijs = ; Toerless >> Eckert ; S Moonesamy >> Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking = addressing >> 5G new services >>=20 >> thanks for the correction. Yes, the TUBA adaption of CLNP was done in = the IETF. >> However, CLNP was an ISO effort. >>=20 >>> On Apr 17, 2020, at 12:13, Dino Farinacci = wrote: >>>=20 >>>> TUBA/CLNS was an ISO effort. It is true that it does have a ITU = number but >> nearly all OSI standards had both an ISO number and an ITU number. >>>=20 >>> This is not true. >>>=20 >>> We did all the TUBA work in the IETF. And we had multiple = implementations >> running interoperability tests at the Amsterdam IETF in 1993. Ross = Callon, Peter >> Ford and Richard Colella, among others were part of the effort. >>>=20 >>> I remember telneting from a cisco router using an NSAP address to = telnet server >> implementations from Peter and Richard. >>>=20 >>> Dino >>>=20 >>> _______________________________________________ >>> Architecture-discuss mailing list >>> Architecture-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 From nobody Fri Apr 17 14:09:43 2020 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 5246A3A060A for ; Fri, 17 Apr 2020 14:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 x6W5NHb_BI7l for ; Fri, 17 Apr 2020 14:09:34 -0700 (PDT) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 9E22D3A05E2 for ; Fri, 17 Apr 2020 14:09:19 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id z6so1392537plk.10 for ; Fri, 17 Apr 2020 14:09:19 -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=lIy60kb+qhcqTsnbnsauwTID0PAdk6Cl9Yp7gk3P3ns=; b=BzEC24LQNRs+Fh2IQSOBwcstfJ2LxFf7fNGHZtGxweavHFU7yW2wwXvdnjuPSs7fIs OytPjebeb0ltTDlTnWjioa6Y0Hdne2OU4Bn7jc1Y8zqZbNmG1/P8dWIE7B4tbpy6gRLv ybs6O+V13m3wo2CM7/YcU8xG8p5/L4xpJChlLEdOyEHB20aiZvIqr2/zXVZJOX2MIHD/ LeuxQaNpsu6cIdUmK78dI5t1VrmeT8zFr8BGRjnr3asZlukiNvJz3pZN0GsZIfeMZzDs NwALQ9ukXQSEV7FRJKiJGyJr5Lxm4tuEbSqHhFoAN7FHoSu5Ctwg7l1l1rQdpKfA8/mM gXqQ== 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=lIy60kb+qhcqTsnbnsauwTID0PAdk6Cl9Yp7gk3P3ns=; b=e+21iEXgchzugq1KpGnlwpN3BPUkPGBd1KrblzHy0RmQgb57+v8J2AXV42uH3eRqYp SzFj6UIH7ufUJFmjd0sdWusgayzpsgsqvZMuYtouNoY4fCWIFhyHUNJDGFIcx2AYKj5G 0BpNKZ268EHLfjTfLlGoIYMlEqA2mQeWVZMkDaYcyZWKGKdnHDo2m0mY19guJasdgnRg rDd8VDmhTAmc56CPFQ699E18SQYpm7D+aycl8Cmja8azdrNcOr/xMaNo8+AbHaqLDHNp SgwWuJzn4AvtRhv2NonXMZtFpy12WIt0XFbKjglqRVqvNKYHpqDiz4F0z2CHehL1wlL6 A78Q== X-Gm-Message-State: AGi0PuZ9IplFZioppVoGmwiHbU3RJKSvsk9WX1VgZYFFnmnLncmusDJy 5ktkUEpoYoyriUm2p7MElL4= X-Google-Smtp-Source: APiQypIu79LeaN+mfMsC4hYxswNJNZgBBdwFOric+qvPnLcU9yPQxzdzFaXYcUpZTownpEitOp1Tsw== X-Received: by 2002:a17:90a:191a:: with SMTP id 26mr6659246pjg.35.1587157753269; Fri, 17 Apr 2020 14:09:13 -0700 (PDT) Received: from [10.95.88.136] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id j134sm6788212pgc.7.2020.04.17.14.09.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Apr 2020 14:09:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Tony Li In-Reply-To: <64BE71E0-2FCC-42A0-8AF5-CC5D485A825A@gmail.com> Date: Fri, 17 Apr 2020 14:09:11 -0700 Cc: John Day , Toerless Eckert , Victor Reijs , "architecture-discuss@ietf.org" , S Moonesamy Content-Transfer-Encoding: quoted-printable Message-Id: <48C98D51-4EED-4936-93B6-178D57D1770E@gmail.com> References: <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <4ac9e9fc-41a3-f458-566e-f0a68d26d9ea@huitema.net> <20200416174840.GL41264@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200417010529.0c28ab50@elandnews.com> <638C298A-F60B-4479-882D-64AFF0F11092@comcast.net> <64BE71E0-2FCC-42A0-8AF5-CC5D485A825A@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 17 Apr 2020 21:09:41 -0000 And Dino. T > On Apr 17, 2020, at 1:44 PM, Dino Farinacci = wrote: >=20 > Don=E2=80=99t forget Yakov and Tony Li. >=20 > Dino >=20 >> On Apr 17, 2020, at 12:48 PM, John Day wrote: >>=20 >> Dave Katz, Dave Oran, Lyman Chapin, Sue Hares, those guys and some = others. They were the ones who were doing CLNP, IS-IS, IDRP, etc. It was = a top-notch crew. >>=20 >>> On Apr 17, 2020, at 12:13, Dino Farinacci = wrote: >>>=20 >>>> TUBA/CLNS was an ISO effort. It is true that it does have a ITU = number but nearly all OSI standards had both an ISO number and an ITU = number.=20 >>>=20 >>> This is not true.=20 >>>=20 >>> We did all the TUBA work in the IETF. And we had multiple = implementations running interoperability tests at the Amsterdam IETF in = 1993. Ross Callon, Peter Ford and Richard Colella, among others were = part of the effort. >>>=20 >>> I remember telneting from a cisco router using an NSAP address to = telnet server implementations from Peter and Richard. >>>=20 >>> Dino >>>=20 >>> _______________________________________________ >>> Architecture-discuss mailing list >>> Architecture-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/architecture-discuss >>=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Fri Apr 17 16:02:50 2020 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 56EA93A094B for ; Fri, 17 Apr 2020 16:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 kMWmnclUd3C8 for ; Fri, 17 Apr 2020 16:02:43 -0700 (PDT) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 30EB83A0949 for ; Fri, 17 Apr 2020 16:02:36 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.151.41]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 03HN1xD0009198 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Apr 2020 16:02:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1587164533; x=1587250933; i=@elandsys.com; bh=26K7AW3BY4TYvVubThsIY8VYwUhBB2P3ijhH1uV8rfs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=rl3nWRapxlzj7GtS5/oiGgwreVnPTdwOrj0muEejOxPNHHr5CDhz4A5hy5leMcYfW xGquXxyYi3YfQbzGJldP+gvB3MW5bXa9rpVcWMjngRJ9IsxhV4xl6H3X2E0CDBc8Uq ZtpJHNebV5aYWu2fpKSU3qZoZptF0SuNISOFIo24= Message-Id: <6.2.5.6.2.20200417143206.0af4d9a8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 17 Apr 2020 15:51:04 -0700 To: Toerless Eckert , architecture-discuss@ietf.org From: S Moonesamy In-Reply-To: <20200417162738.GD5351@faui48f.informatik.uni-erlangen.de> References: <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <4ac9e9fc-41a3-f458-566e-f0a68d26d9ea@huitema.net> <20200416174840.GL41264@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200417010529.0c28ab50@elandnews.com> <20200417162738.GD5351@faui48f.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 17 Apr 2020 23:02:49 -0000 Hi Toerless, At 09:27 AM 17-04-2020, Toerless Eckert wrote: >Hahaha. Am i assuming correctly that "central planning department" is >intentionally written to sound dismissive, or am i just reading >that into your text ? The point was to convey that such an approach in another context was not successful. >We do have an official IETF photographer. Why can't we have an official >IETF cartoonist ? I would love to see a rendering of the "central planning >department of the IETF". Also the whole discussion about IETF photography, >badges and datatracker mugshots would take a real interesting turn if we >changed over to cartoons. That is a discussion for ietf@. :-) >Kidding aside: i think we need to be careful in not discouraging >innovation when it is ambitious. The sole reason why the IETF exists is to >create innovation that depends on multiple parties to become active. >And the primary place where IPsec IMHO failed to gain adoption is on >those parts IETF continues not to want to work in: host-stacks, APIs, >(policy) etc.. The innovation happens when the specification is implemented and widely deployed. For what it is worth, there was some effort to assess that. I don't remember what happened to it. >The reference seems to be more about depressing language barriers than >technical aspects. But sure, the London led collonialization of >the finance industry of this planet is coming to an end (sob ? hurray ? ;-) The acronym is from Jane Gardam's novel: https://www.bbc.co.uk/sounds/play/w3csv2bp >I have only seen few bits and pieces about those IETF outreach programs, >but it was all from people i respect and activites i felt where useful, >so i have no example data points to be cynical about. Ok. >In India, subsistence farmers get updates of different city market prices >realtime via SMS on their cell phones so they know where to sell >their produce. >In Germany, Corona case tracking is delayed for days through a multi-stage >series or FAX between different bureaucracies that manually process and >propagate information. > >Maybe IPv6 was specifically architected not to be too much better >than IPv4 to ensure that developing countries that can skip IPv4 >and start with simple IPv6 greenfields can not leap ahead of >"developed" nations with all their historic IPv4 baggage too much. I am not trying to be dismissive. I heard the greenfield argument being made around a decade ago. Around two years' ago, I had an interesting discussion with some younger persons in the region about "why don't we use IPv6 to solve the problem". As someone from the Internet Corporation of Assigned Names and Numbers discussed the topic with me a day earlier, I asked the person to explain the issues to them. I left it to the younger persons to draw their own conclusions. Regards, S. Moonesamy From nobody Sun Apr 19 11:05:51 2020 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 50B543A0EA9 for ; Sun, 19 Apr 2020 11:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sidn.nl 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 Ztx5dGVV3tE3 for ; Sun, 19 Apr 2020 11:05:43 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20070.outbound.protection.outlook.com [40.107.2.70]) (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 1F3B43A0EA8 for ; Sun, 19 Apr 2020 11:05:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LZHE6fDmwLCD/lvn4oj6iyAbqN9ezj8yKP1CdM3zZlp8rVZUwj1S4mtW9d6U5/bMH9mSTtMrts2r+5M8+g+oLUpEhYIL7Lt8Xb3WZI1TWE6Y2PcYglT0NnMC62pbXKcAOMGyQP13/GEpRR+EvGS1MIqQpMWMK3f9LYZI8bhcyKAsI+Yjm6cEp5bb2BwUeoK3CkC9nJL8KW2wkyYmq7WYg0gfs4+6kqrF3iQWdTv9SA53/hLq0IAdt39k/NPXcoUXUYPmM3gDOqdpm4w4MI+Brt07OJKvX/zfbiuzbTsF4nFwhEchvNFzay/KHHP8M69/MUkCdBlqpztQITxtbmmEBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6ZiK/Ha2Qld30s+A+qBCmtM5wp0Dd43Lzdn9E4tDehg=; b=dREuWyEAqwzFGrD0oN5oE+4/Gucj5PB0vzTTL0F2ynenAVxjT1RRoiIDC248CwDJwkn1kNS5e9zJEV76C8bFujo7MaWUyCY6hy7m+qBVZEURhrRLESUpeORhcvxfFgcCEIsJVfsNFJdFLStTQb5+aBXNr0n6f4TPzipzCIuEcsHm8kPxhR1JufJAwdFHwYGGRKY5+TozAJJ3uPwKbqd/JfFZprSMfQ7BiFpN7TN4SjRu7J4P3mgJwXDxvI2VeRAyJEd38msvV3w2OMiSNl+GxouX1r104GQSzH3bSo2UYsgHjmI+iK6TD63DAumSqiWvPbaWghrHDwHY7AnMNT8iXA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sidn.nl; dmarc=pass action=none header.from=sidn.nl; dkim=pass header.d=sidn.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sidn.nl; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6ZiK/Ha2Qld30s+A+qBCmtM5wp0Dd43Lzdn9E4tDehg=; b=ptuZD+1E4NWG3Q01FN4jI/N1QUsNxWou6dLkmpzbdQTJEFoSvlvb/8R5bq0h9VTxL4VAsxAwOKkE/rKvUxbyjlAeYn2ABSwdGj3lIsGDo1naaG9FOEdWB8YMwcpCy2HTyGDjgHquvjy4uxYaBIvv3kP52tVrOc4CQtBwr0KGbYM= Received: from AM0P194MB0593.EURP194.PROD.OUTLOOK.COM (2603:10a6:20b:166::19) by AM0P194MB0628.EURP194.PROD.OUTLOOK.COM (2603:10a6:20b:14a::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.26; Sun, 19 Apr 2020 18:05:39 +0000 Received: from AM0P194MB0593.EURP194.PROD.OUTLOOK.COM ([fe80::6012:af08:ebd9:57ad]) by AM0P194MB0593.EURP194.PROD.OUTLOOK.COM ([fe80::6012:af08:ebd9:57ad%8]) with mapi id 15.20.2921.027; Sun, 19 Apr 2020 18:05:38 +0000 From: Victor Reijs To: Dino Farinacci CC: John Day , "architecture-discuss@ietf.org" , Toerless Eckert , S Moonesamy Thread-Topic: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services Thread-Index: AQHWDWJyhUWBPnI3wkiq6mi66DMYhahuqlAAgAALyACAAN4dAIAADIkAgADi6gCAADPdgIAAGZYAgABD94CAADYPAIAByMIAgARb1ACABKQKAIABAP0AgAAXdVCAAEKiAIAAHJuAgAAexYCAABEWIIAAHDeAgAL3qPA= Date: Sun, 19 Apr 2020 18:05:38 +0000 Message-ID: References: <20200408054204.GA6005@nic.fr> <6C2A3533-7F75-45B1-9B51-19938597174B@tzi.org> <20200408194154.GJ28965@faui48f.informatik.uni-erlangen.de> <4200C5F8-9F56-4FFF-90F4-7AD76A9F4FC8@eggert.org> <20200409121941.GZ28965@faui48f.informatik.uni-erlangen.de> <20200409175431.GF28965@faui48f.informatik.uni-erlangen.de> <1e89795e-6bd9-2318-aa81-27f8327e1226@gmail.com> <4ac9e9fc-41a3-f458-566e-f0a68d26d9ea@huitema.net> <20200416174840.GL41264@faui48f.informatik.uni-erlangen.de> <6.2.5.6.2.20200417010529.0c28ab50@elandnews.com> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=victor.reijs@sidn.nl; x-originating-ip: [213.127.2.23] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 88f89b2c-d91d-4473-f07b-08d7e48c444a x-ms-traffictypediagnostic: AM0P194MB0628: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0378F1E47A x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P194MB0593.EURP194.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(136003)(376002)(396003)(39830400003)(366004)(33656002)(15974865002)(55016002)(2906002)(9686003)(71200400001)(4326008)(44832011)(186003)(5660300002)(478600001)(966005)(83080400001)(7696005)(6506007)(316002)(53546011)(66574012)(26005)(86362001)(54906003)(6916009)(66446008)(76116006)(81156014)(52536014)(8676002)(8936002)(66946007)(66476007)(66556008)(64756008); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: sidn.nl does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8967C+bwCM/ZZ9EnBxzi9QPZBDw6ankApD9ia7S0R4g0hhXdOS0L/m0pBkYbHdKKWcA1SWW8YTuRSC6GpzLMF6XWFyOPRWfpYMK8Ho8OTa4yyVUI9l79em5qssb004Pi95bTVRjC8Qt3ekdbmk2GeNCQ6RqXDn8hdZu7+KLBkON2NVzSoHsaw+VJ9Tzhp6ILwxyO/CleoabJLAM0jUEMiojxJQBRNBJY/ui8hsYpcNCpSfw8irsr78JZCcaXkiUYYfjHFP+P9iDLRjAAinuO87QidSm80dBdS65z8m7GDY6p7pPvBax0MEbU1/wntrxPxffD7UshF5l0lJFHqLCR4OH68utpwXsoF6YkTPebvEkxgOghTSZiSoMcJnrELYvMNf0yLQmiqivVVPvLfaVxr63vUeipEZb77H0GFqSEkBsHpQWdb1wP2ZKkdbMFzWzujKHRruoxpOqC+0Hi3HI2YAa/FNR79cEj8Bfl7ChCFELIJuYUcfUOJkKHBxbBuL48oZRm8vt64U6Ses5SJqKhfQ== x-ms-exchange-antispam-messagedata: qgA0eQTxV4WBZuzUrXuqGZihG8WHf3cZtXKk1TAa3C5FaYKJCYbrwAw56QqAdHmn9llp3w69gcP//b6b8Brzj+XRdz7ErKX9rdxty1P1ghEVjKbWP6JpoX5R+mfBv2mV3TznShCHcoEhOlxaLgbBeoeAH+e7li42jkB9eQ5ZBH4JiWHjhQSqkeGjMxsnptWic1OOxb9p3xc2xWEpUVpWt6tguxqkxFXr4//2bjZrssB7F5M+ctJvetSLCf5wO/wJ8dUpOuchg8IkxxaU9BcszL1jlcwE/3HbIq3URFIoaJ3/6aZcrg/3In4gAxkUgP6F0sXX6+/QGIhLuNEEC9Tj7PGqTsKM+MBXImdSnVNmCS35N3hN27U8Amt/6IWNf9ZacyK5NQkGx+3bE2QKkXUxDRms78J4S029O7AVxyVVM2Od8ynhn3Qe6Y9TiuvPBB2cctBVnhVhVOBwHndR2puW39BRHpX9+E7iKolIGPewdK82EXodIbZ+LDN/9Ub0aBpwz9oYijXka2FsUKJooBOxRvbAbEqiJ3rGr+7TzQw6Ry7gMoNeXA6P5jRQdI0jCE9O/GBfeiHqQyTxcSMw7LYc9hiNuUCJP8HPjA+T6cfYvKcIoSk7qKYwzHTYJFXQO/1kHxXLaQkpkI5wpYPSBIBLVDCEwKz6N9jMW0QPVjEHCQVF6YAx47AVBK8tX3oreIxIlD415giD1u5MJFc7LPuzYZl3ASRFRaBzXpYawlpoyEnvAE+O43SWUEqTjigrRKxastyxyPJ383kB62f444YTloYSbRHAhKgywWl+ruZw9e8= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sidn.nl X-MS-Exchange-CrossTenant-Network-Message-Id: 88f89b2c-d91d-4473-f07b-08d7e48c444a X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2020 18:05:38.6449 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ab4d3626-c1c5-4a75-ab85-427f1a644a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: y1+RGjAsA//EnOo3bZZBFL1H6CyXXpVCDf0ra3yevPl5ShXHHp5UKrjXHhhNQSgCEo4VJE5Z3+y3l762TwkDTw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P194MB0628 Archived-At: Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services 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, 19 Apr 2020 18:05:50 -0000 QW5kIHRoYW5rcyBKb2huLCBTdWUgd2FzIHRoZSBwZXJzb24gb2YgTWVyaXQgd2hvIHdhcyBpbiBv dXIgZ3JvdXAgdG8gbWFrZSB0aGUgQ0xOUy9UVUJBIG5ldHdvcmsgaW4gRXVyb3BlIGFuZCBVU0Eu IEJ5IHRoZSB3YXkgaXQgd2FzIHNwb25zb3JlZCBieSB0aGUgRUMsIEp1aGEgYW5kIEkgd2VyZSB0 aGUgcHJvamVjdGxlYWRlcnMuLi4NCg0KVmljdG9yIFJlaWpzDQpSZXNlYXJjaCBlbmdpbmVlcjog ZnV0dXJlIGludGVybmV0DQoNCkF0dGVuZGFuY2UgKENFU1QpOiBNb24gOC4xNS0xNi40NSB8IFR1 ZSA4LjE1LTE2LjQ1IHwgRnJpIDkuMDAtMTcuMzANCg0KDQoNClNJRE4gfCBNZWFuZGVyIDUwMSB8 IDY4MjUgTUQgfCBQb3N0YnVzIDUwMjIgfCA2ODAyIEVBIHwgQVJOSEVNIHwgVGhlIE5ldGhlcmxh bmRzDQpUICszMSAoMCkyNiAzNTIgNTUgMDAgfCBNICszMSAoMCk2IDEyIDQ1IDAwIDExDQp2aWN0 b3IucmVpanNAc2lkbi5ubCB8wqB3d3cuc2lkbi5ubA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IERpbm8gRmFyaW5hY2NpIDxmYXJpbmFjY2lAZ21haWwuY29tPg0KPiBT ZW50OiBGcmlkYXksIDE3IEFwcmlsIDIwMjAgMjI6NDYNCj4gVG86IFZpY3RvciBSZWlqcyA8dmlj dG9yLnJlaWpzQHNpZG4ubmw+DQo+IENjOiBKb2huIERheSA8amVhbmpvdXJAY29tY2FzdC5uZXQ+ OyBhcmNoaXRlY3R1cmUtZGlzY3Vzc0BpZXRmLm9yZzsgVG9lcmxlc3MNCj4gRWNrZXJ0IDx0dGVA Y3MuZmF1LmRlPjsgUyBNb29uZXNhbXkgPHNtK2lldGZAZWxhbmRzeXMuY29tPg0KPiBTdWJqZWN0 OiBSZTogW2FyY2gtZF0gRVRTSSBsYXVuY2hlcyBuZXcgZ3JvdXAgb24gTm9uLUlQIE5ldHdvcmtp bmcgYWRkcmVzc2luZw0KPiA1RyBuZXcgc2VydmljZXMNCj4gDQo+IFZpY3RvciwgdGhhbmtzIGZv ciB0aGUgc3Ryb2xsIGRvd24gbWVtb3J5IGxhbmUhDQo+IA0KPiBEaW5vDQo+IA0KPiA+IE9uIEFw ciAxNywgMjAyMCwgYXQgMTI6MTEgUE0sIFZpY3RvciBSZWlqcyA8dmljdG9yLnJlaWpzQHNpZG4u bmw+IHdyb3RlOg0KPiA+DQo+ID4gVG9nZXRoZXIgd2l0aCBKdWhhIEhpbmFuZW4gZm9yIGluc3Rh bmNlIGFuZCBtYW55IG90aGVyIE5SRU5zIGluIEV1cm9wZSBhbmQNCj4gdG9nZXRoZXIgdGhlIHBl b3BsZSBpbiBVU0EgKEkgdGhpbmsgYSBmZXcgcGVvcGxlIG9mIE1FUklUIHBsYWlkIGEgbGFyZ2Ug cm9sZSBpbg0KPiBkZXZlbG9waW5nIElTLUlTIGFuZCBJRFJQKSBhbmQgdG9nZXRoZXIgd2l0aCAg Q2lzY28gd2UgYnVpbGQgYW5kIHRlc3RlZCB0aGlzIGxhcmdlDQo+IENMTlMgbmV0d29yayBvbiBh IG11bHRpLXByb3RvY29sIG5ldHdvcmsgKHBhcnRseSBLUE4gaW4gRXVyb3BlKS4NCj4gPiBXZSBo YWQgcHJpbnRlZCBhIGdyZWF0IFQtc2hpcnQgd2l0aCB0aGUgVHViYSBzeW1ib2wgb24gaXQsIEkg c3RpbGwgZmluZCBpdCBhIHBpdHkgSQ0KPiB0aHJldyBpdCBhd2F5ISBJdCB3b3VsZCBoYXZlIGJl ZW4gYSByZWFsIGNvbGxlY3RvcnMgaXRlbS4NCj4gPg0KPiA+IFdlIHVzZWQgdGhlIGZpcnN0IElT LUlTIGltcGxlbWVudGF0aW9ucyAod2hpY2ggaXMgdGhlIG9ubHkgdGhpbmcgdGhhdCBpcyBsZWZ0 IG9mDQo+IHRoaXMgcHJvamVjdCkgYW5kIHdlIHdlcmUganVzdCBpbiB0aGUgbWlkZGxlIG9mIGRl dmVsb3BpbmcgSURSUCAodGhlIEJHUCBpbiB0aGUNCj4gQ0xOUyBlbnZpcm9ubWVudCksIGFuZCB0 aGVuIGNhbWUgdGhlIGRlY2lzaW9uIHRvIGdvIHdpdGggSVB2NvCfmIkuDQo+ID4NCj4gPiBJIG11 c3QgaGF2ZSBzb21lIEVQUk9NcyBmb3IgY2lzY28gcm91dGVyIHdpdGggdGhlIGVhcmx5IGNvZGUg c29tZXdoZXJlLg0KPiBXb3VsZCBiZSBuaWNlIHRvIHBsYW4gYSByZXVuaW9uLg0KPiA+DQo+ID4g QWxsIHRoZSBiZXN0IGFuZCBzdGF5IGhlYWx0aHksDQo+ID4NCj4gPg0KPiA+IFZpY3RvciBSZWlq cw0KPiA+IFJlc2VhcmNoIGVuZ2luZWVyOiBmdXR1cmUgaW50ZXJuZXQNCj4gPg0KPiA+IEF0dGVu ZGFuY2UgKENFU1QpOiBNb24gOC4xNS0xNi40NSB8IFR1ZSA4LjE1LTE2LjQ1IHwgRnJpIDkuMDAt MTcuMzANCj4gPg0KPiA+DQo+ID4NCj4gPiBTSUROIHwgTWVhbmRlciA1MDEgfCA2ODI1IE1EIHwg UG9zdGJ1cyA1MDIyIHwgNjgwMiBFQSB8IEFSTkhFTSB8IFRoZQ0KPiA+IE5ldGhlcmxhbmRzIFQg KzMxICgwKTI2IDM1MiA1NSAwMCB8IE0gKzMxICgwKTYgMTIgNDUgMDAgMTENCj4gPiB2aWN0b3Iu cmVpanNAc2lkbi5ubCB8IHd3dy5zaWRuLm5sDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPj4gRnJvbTogSm9obiBEYXkgPGplYW5qb3VyQGNvbWNhc3QubmV0Pg0KPiA+ PiBTZW50OiBGcmlkYXksIDE3IEFwcmlsIDIwMjAgMjA6MDMNCj4gPj4gVG86IERpbm8gRmFyaW5h Y2NpIDxmYXJpbmFjY2lAZ21haWwuY29tPg0KPiA+PiBDYzogYXJjaGl0ZWN0dXJlLWRpc2N1c3NA aWV0Zi5vcmc7IFZpY3RvciBSZWlqcw0KPiA+PiA8dmljdG9yLnJlaWpzQHNpZG4ubmw+OyBUb2Vy bGVzcyBFY2tlcnQgPHR0ZUBjcy5mYXUuZGU+OyBTIE1vb25lc2FteQ0KPiA+PiA8c20raWV0ZkBl bGFuZHN5cy5jb20+DQo+ID4+IFN1YmplY3Q6IFJlOiBbYXJjaC1kXSBFVFNJIGxhdW5jaGVzIG5l dyBncm91cCBvbiBOb24tSVAgTmV0d29ya2luZw0KPiA+PiBhZGRyZXNzaW5nIDVHIG5ldyBzZXJ2 aWNlcw0KPiA+Pg0KPiA+PiB0aGFua3MgZm9yIHRoZSBjb3JyZWN0aW9uLiBZZXMsIHRoZSBUVUJB IGFkYXB0aW9uIG9mIENMTlAgd2FzIGRvbmUgaW4gdGhlDQo+IElFVEYuDQo+ID4+IEhvd2V2ZXIs IENMTlAgd2FzIGFuIElTTyBlZmZvcnQuDQo+ID4+DQo+ID4+PiBPbiBBcHIgMTcsIDIwMjAsIGF0 IDEyOjEzLCBEaW5vIEZhcmluYWNjaSA8ZmFyaW5hY2NpQGdtYWlsLmNvbT4gd3JvdGU6DQo+ID4+ Pg0KPiA+Pj4+IFRVQkEvQ0xOUyB3YXMgYW4gSVNPIGVmZm9ydC4gSXQgaXMgdHJ1ZSB0aGF0IGl0 IGRvZXMgaGF2ZSBhIElUVQ0KPiA+Pj4+IG51bWJlciBidXQNCj4gPj4gbmVhcmx5IGFsbCBPU0kg c3RhbmRhcmRzIGhhZCBib3RoIGFuIElTTyBudW1iZXIgYW5kIGFuIElUVSBudW1iZXIuDQo+ID4+ Pg0KPiA+Pj4gVGhpcyBpcyBub3QgdHJ1ZS4NCj4gPj4+DQo+ID4+PiBXZSBkaWQgYWxsIHRoZSBU VUJBIHdvcmsgaW4gdGhlIElFVEYuIEFuZCB3ZSBoYWQgbXVsdGlwbGUNCj4gPj4+IGltcGxlbWVu dGF0aW9ucw0KPiA+PiBydW5uaW5nIGludGVyb3BlcmFiaWxpdHkgdGVzdHMgYXQgdGhlIEFtc3Rl cmRhbSBJRVRGIGluIDE5OTMuIFJvc3MNCj4gPj4gQ2FsbG9uLCBQZXRlciBGb3JkIGFuZCBSaWNo YXJkIENvbGVsbGEsIGFtb25nIG90aGVycyB3ZXJlIHBhcnQgb2YgdGhlIGVmZm9ydC4NCj4gPj4+ DQo+ID4+PiBJIHJlbWVtYmVyIHRlbG5ldGluZyBmcm9tIGEgY2lzY28gcm91dGVyIHVzaW5nIGFu IE5TQVAgYWRkcmVzcyB0bw0KPiA+Pj4gdGVsbmV0IHNlcnZlcg0KPiA+PiBpbXBsZW1lbnRhdGlv bnMgZnJvbSBQZXRlciBhbmQgUmljaGFyZC4NCj4gPj4+DQo+ID4+PiBEaW5vDQo+ID4+Pg0KPiA+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+ IEFyY2hpdGVjdHVyZS1kaXNjdXNzIG1haWxpbmcgbGlzdA0KPiA+Pj4gQXJjaGl0ZWN0dXJlLWRp c2N1c3NAaWV0Zi5vcmcNCj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vYXJjaGl0ZWN0dXJlLWRpc2N1c3MNCj4gPg0KDQo= From nobody Mon Apr 20 09:08:55 2020 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 70E0B3A0A0F for ; Mon, 20 Apr 2020 09:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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 DUQglUdbHD5W for ; Mon, 20 Apr 2020 09:08:51 -0700 (PDT) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 C066A3A0A10 for ; Mon, 20 Apr 2020 09:08:51 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id 03KG7dqO028793 for ; Mon, 20 Apr 2020 09:08:50 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : mime-version : subject : message-id : date : to; s=20180706; bh=t7rUtY6jX+nm3/hwNuxUZbDi5NDMudXBzCzdMvXlh4U=; b=Ck3tF+B7z4wtpcyfmN1aBuTb1VympccBfpDRcoS0y1ZmKBp/ORyj62/s6VN0MGmAevgX i/HExvCoz6rUdwlzU9rI29qSjiCqGr4qIIWuH04AJjLWxwaQOKgF6SG1BwmUXeUs0rqP JCmsNqNzCWM7vQazuF59eY9m00kbkV7ZnzrRinDHa/bgXmjQfDLNZfSA8iQHccYgP69P +flmSlgQZSvB5PMbK2HNFqXYCllz0sUh0D/vuAmjtGLygAuuw9xYxUVRu7+SM3hRxK11 tDXObjnn9c6gaw4sw6o9q6U+gvAICs+Lv7RAyxMqN4/fFvQ06qEGgvuUzjL5/Dc8UurI UA== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 30g072n5ct-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 20 Apr 2020 09:08:50 -0700 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0Q9300O4ZGUPDTL0@rn-mailsvcp-mta-lapp04.rno.apple.com> for architecture-discuss@ietf.org; Mon, 20 Apr 2020 09:08:50 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0Q9300G00GG31A00@rn-mailsvcp-mmp-lapp01.rno.apple.com> for architecture-discuss@ietf.org; Mon, 20 Apr 2020 09:08:50 -0700 (PDT) X-Va-A: X-Va-T-CD: 45d05c62cd7afaa1f9a78bcea78d799b X-Va-E-CD: 4881e33d7f91f587bac31c40f5dc21e2 X-Va-R-CD: e6a6da892a7afbaf86643effba559541 X-Va-CD: 0 X-Va-ID: 20374ccf-f59b-4044-b0be-4e5fabd20d2e X-V-A: X-V-T-CD: 45d05c62cd7afaa1f9a78bcea78d799b X-V-E-CD: 4881e33d7f91f587bac31c40f5dc21e2 X-V-R-CD: e6a6da892a7afbaf86643effba559541 X-V-CD: 0 X-V-ID: caf1f9c9-e177-4970-a21f-64038703b9a8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-20_05:2020-04-20, 2020-04-20 signatures=0 Received: from [17.234.48.87] (unknown [17.234.48.87]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0Q9300R9HGUOGD00@rn-mailsvcp-mmp-lapp01.rno.apple.com> for architecture-discuss@ietf.org; Mon, 20 Apr 2020 09:08:49 -0700 (PDT) From: Tommy Pauly Content-type: multipart/alternative; boundary="Apple-Mail=_B350115B-4262-423F-AD8E-99EE0B4117D6" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Message-id: <303F494F-F06C-4E6A-99E5-089798EB56DB@apple.com> Date: Mon, 20 Apr 2020 09:08:48 -0700 To: "architecture-discuss@ietf.org" X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-20_05:2020-04-20, 2020-04-20 signatures=0 Archived-At: Subject: [arch-d] Updates on IAB mailing lists 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, 20 Apr 2020 16:08:54 -0000 --Apple-Mail=_B350115B-4262-423F-AD8E-99EE0B4117D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello architecture-discuss, We=E2=80=99d like to share a few updates about IAB mailing lists, and = solicit the community=E2=80=99s feedback on some new text. First, Tommy Pauly will be joining Stephen Farrell on the (existing, but = rarely employed) sergeants-at-arms team to help moderate the list. Second, we=E2=80=99d like to clarify the sergeants-at-arms roles for the = lists. The current description on https://www.iab.org/iab-mailing-lists/ = does mention that the lists use = a sergeant-at-arms model for moderation, but does not describe what this = role entails. It also does not specify if this role applies to all of = the lists on the page, such as program lists. We=E2=80=99re proposing adding the following text to = https://www.iab.org/iab-mailing-lists/ = , largely based on the IETF list = SAA. We=E2=80=99d love to hear feedback on this approach! =3D=3D=3D=3D IAB mailing lists have sergeants-at-arms, whose role is ensure there are = no inappropriate postings. Inappropriate postings consist of: spam and = bulk e-mail; announcements of conferences or activities that are not = sponsored or endorsed by the Internet Society, the IETF, or the IAB; = unprofessional commentary, regardless of subject; and discussion of = subjects unrelated to IAB policy, programs, activities, or technical = concerns. The sergeants-at-arms are empowered to restrict posting by a person or = of a thread when the content is inappropriate and represents a pattern = of abuse. Complaints regarding a decision should be referred to the IAB = chair. The current sergeants-at-arms for =E2=80=9Carchitecture-discuss@ietf.org = =E2=80=9D are Stephen Farrell and = Tommy Pauly. For program-specific lists, the program chairs act as = moderators. The "rfc-interest@rfc-editor.org = =E2=80=9D list is moderated by the = Temporary RFC Series Project Manager. =3D=3D=3D=3D Third, we have many lists that are enumerated on the website that are = for closed programs or past workshops. We checked the activity on these = lists, and we believe that we can close the following lists. Any further = discussion on these topics is welcome on architecture-discuss. - caris-attendees@iab.org - emserv-discuss@iab.org - i18n-discuss@iab.org - inip-discuss@iab.org - internetgovtech@iab.org - iotsi@iab.org - iotsu@iab.org - marnew@iab.org - privsec-discuss@iab.org - stackevo-discuss@iab.org The remaining lists will be: - architecture-discuss@ietf.org - chirp@iab.org - model-t@iab.org - rfced-future@iab.org Best, Tommy Pauly, on behalf of the IAB= --Apple-Mail=_B350115B-4262-423F-AD8E-99EE0B4117D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello architecture-discuss,

We=E2=80=99d like to share a few = updates about IAB mailing lists, and solicit the community=E2=80=99s = feedback on some new text.

First, Tommy Pauly will be joining Stephen Farrell on the = (existing, but rarely employed) sergeants-at-arms = team to help moderate the list.

Second, we=E2=80=99d like to clarify = the sergeants-at-arms roles for the lists. The = current description on https://www.iab.org/iab-mailing-lists/ does mention = that the lists use a sergeant-at-arms model for moderation, but does not = describe what this role entails. It also does not specify if this role = applies to all of the lists on the page, such as program = lists.

We=E2=80=99= re proposing adding the following text to https://www.iab.org/iab-mailing-lists/, largely based on = the IETF list SAA. We=E2=80=99d love to hear feedback on this = approach!

=3D=3D=3D=3D

IAB = mailing lists have sergeants-at-arms, whose role is ensure there are no = inappropriate postings. Inappropriate postings consist of: spam and bulk = e-mail; announcements of conferences or activities that are not = sponsored or endorsed by the Internet Society, the IETF, or the IAB; = unprofessional commentary, regardless of subject; and discussion of = subjects unrelated to IAB policy, programs, activities, or technical = concerns.

The sergeants-at-arms are empowered to = restrict posting by a person or of a thread when the content is = inappropriate and represents a pattern of abuse. Complaints regarding a = decision should be referred to the IAB chair.

The current sergeants-at-arms for =E2=80=9Carchitecture-discuss@ietf.org=E2=80=9D are Stephen = Farrell and Tommy Pauly. For program-specific lists, the program chairs = act as moderators. The "rfc-interest@rfc-editor.org=E2=80=9D list is moderated by = the Temporary RFC Series Project Manager.

=3D=3D=3D=3D

Third, we have many lists that are = enumerated on the website that are for closed programs or past = workshops. We checked the activity on these lists, and we believe that = we can close the following lists. Any further discussion on these topics = is welcome on architecture-discuss.

- caris-attendees@iab.org
- emserv-discuss@iab.org
- i18n-discuss@iab.org
- inip-discuss@iab.org
- internetgovtech@iab.org
- iotsi@iab.org
- iotsu@iab.org
- marnew@iab.org
- privsec-discuss@iab.org
- stackevo-discuss@iab.org

The remaining lists will be:

- architecture-discuss@ietf.org
- chirp@iab.org
- model-t@iab.org
- rfced-future@iab.org

Best,
Tommy = Pauly, on behalf of the IAB
= --Apple-Mail=_B350115B-4262-423F-AD8E-99EE0B4117D6-- From nobody Mon Apr 20 09:11:36 2020 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 5DCB33A0AC9 for ; Mon, 20 Apr 2020 09:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 Ssi1V4JvVZik for ; Mon, 20 Apr 2020 09:11:22 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AE003A0AB1 for ; Mon, 20 Apr 2020 09:11:21 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 495WsM6YtbzyXs; Mon, 20 Apr 2020 18:11:19 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <303F494F-F06C-4E6A-99E5-089798EB56DB@apple.com> Date: Mon, 20 Apr 2020 18:11:19 +0200 Cc: "architecture-discuss@ietf.org" X-Mao-Original-Outgoing-Id: 609091879.49869-25766c6a07205f93dc0dc082d2f37f06 Content-Transfer-Encoding: quoted-printable Message-Id: References: <303F494F-F06C-4E6A-99E5-089798EB56DB@apple.com> To: Tommy Pauly X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [arch-d] Updates on IAB mailing lists 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, 20 Apr 2020 16:11:35 -0000 On 2020-04-20, at 18:08, Tommy Pauly = wrote: >=20 > - i18n-discuss@iab.org Really? That is a somewhat specialized audience I don=E2=80=99t expect = to find on architecture-discuss. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Apr 20 11:45:12 2020 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 0978D3A0C23; Mon, 20 Apr 2020 11:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.652, 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 WH-ERD8iwZaj; Mon, 20 Apr 2020 11:45:08 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C8823A0105; Mon, 20 Apr 2020 11:45:02 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 1E8C1548048; Mon, 20 Apr 2020 20:44:56 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 1836F440055; Mon, 20 Apr 2020 20:44:56 +0200 (CEST) Date: Mon, 20 Apr 2020 20:44:56 +0200 From: Toerless Eckert To: Tommy Pauly , iesg@ietf.org, ietf@ietf.org Cc: "architecture-discuss@ietf.org" Message-ID: <20200420184456.GG5351@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [arch-d] iesg: Re: Updates on IAB mailing lists 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, 20 Apr 2020 18:45:11 -0000 Dear IESG [Cc'in IETF] I would hereby like IESG to reconfirm that architecture-discuss@ietf.org is an IETF mailing list subject to IETF mailing list rules and its "about" statement and not subject to intended strict IAB controlled communications policies for IAB mailing lists as proposed by Tommy. If this is not yet the case, then please make sure that it is in the future because the proposed IAB policies do neither match the mailing lists name, the actual discussion (mostly absent IAB involvement), nor the intended discussion on it (as on mailman). See below for more detailled justification. Dear Tommy, *: Wrt to your intention to put IAB mailing lists under the following proposed policies: > Inappropriate postings consist of: spam and bulk e-mail; > unprofessional commentary, regardless of subject; OK. > announcements of conferences or activities that are not sponsored > or endorsed by the Internet Society, the IETF, or the IAB OK. > and discussion of subjects unrelated to IAB policy, > programs, activities, or technical concerns" NOK for list that go beyond those points. architecture-discuss@ietf.org clear goes beyond those points. a) I read this as a long-winding workaround to prohibit the IETF community to self-organize without official leadership support in inofficial side meetings using the IETF mailing list architecture-discuss@ietf.org I suspect these rules have especially been crafted to prohibit me to invite community members interested in architecture discussion around New IP to inofficial side meetings via the archiecture-discuss@ietf.org mailing list in the future, as i did in the past for IETF106 and IETF107. AFAIK, it is not only common practice, but quite desirable for the community to use IETF/IRTF mailing lists to self-organize into whatever form of inoffical side meeting is appropriate on topics of intererst to that mailing list. Bar BOFs not being easy in times of corona. Likewise i think that notifications about events related to a mailing lists topic are quite common. The notion that only official sponsored events can be brought up sounds quite strange to me and quite contrary to the open nature of the IETF/IRTF. b) If IAB wants to enforce such restrictive policies for communications on an intentional open mailing list such as architecture-discuss@ietf.org, then this adds severely to my concerns about how IAB operates. I think it is unbecoming for an ISOC entity. To me, architecture-discuss@iab.org is clearly not a mailing list that currently is or in the future should be subject to such IAB communication constraints: 1. It is called architecture-discuss@ietf.org, not @iab.org 2. About: https://www.ietf.org/mailman/listinfo/Architecture-discuss > The architecture-discuss list serves as a technical discussion > forum for all members of the IETF community that are interested > in larger > architectural issues. It is meant to be an open discussion > forum for all long and/or wide range architectural concerns related > to the Internet Architecture. In particular, it may be used to > discuss and bring forth different points of view on controversial > architectural questions. Discussions that drill down and dwell > on specifics of individual protocols or technologies are to be > discouraged, redirected to appropriate other fora, or re-cast to > discussions of broader implications for Internet architecture. 3. The mayority of the discussions on the mailing list are clearly not lead by IAB, but are useful for the community. There is absolutely no need for such a mailing list to be constrained to proposed new strict IAB regime. Instead i think IAB membersh should be welcome into the discussion of the community. Cheers Toerless On Mon, Apr 20, 2020 at 09:08:48AM -0700, Tommy Pauly wrote: > Hello architecture-discuss, > > We???d like to share a few updates about IAB mailing lists, and solicit the community???s feedback on some new text. > > First, Tommy Pauly will be joining Stephen Farrell on the (existing, but rarely employed) sergeants-at-arms team to help moderate the list. > > Second, we???d like to clarify the sergeants-at-arms roles for the lists. The current description on https://www.iab.org/iab-mailing-lists/ does mention that the lists use a sergeant-at-arms model for moderation, but does not describe what this role entails. It also does not specify if this role applies to all of the lists on the page, such as program lists. > > We???re proposing adding the following text to https://www.iab.org/iab-mailing-lists/ , largely based on the IETF list SAA. We???d love to hear feedback on this approach! > > ==== > > IAB mailing lists have sergeants-at-arms, whose role is ensure there are no inappropriate postings. Inappropriate postings consist of: spam and bulk e-mail; announcements of conferences or activities that are not sponsored or endorsed by the Internet Society, the IETF, or the IAB; unprofessional commentary, regardless of subject; and discussion of subjects unrelated to IAB policy, programs, activities, or technical concerns. > > The sergeants-at-arms are empowered to restrict posting by a person or of a thread when the content is inappropriate and represents a pattern of abuse. Complaints regarding a decision should be referred to the IAB chair. > > The current sergeants-at-arms for ???architecture-discuss@ietf.org ??? are Stephen Farrell and Tommy Pauly. For program-specific lists, the program chairs act as moderators. The "rfc-interest@rfc-editor.org ??? list is moderated by the Temporary RFC Series Project Manager. > > ==== > > Third, we have many lists that are enumerated on the website that are for closed programs or past workshops. We checked the activity on these lists, and we believe that we can close the following lists. Any further discussion on these topics is welcome on architecture-discuss. > > - caris-attendees@iab.org > - emserv-discuss@iab.org > - i18n-discuss@iab.org > - inip-discuss@iab.org > - internetgovtech@iab.org > - iotsi@iab.org > - iotsu@iab.org > - marnew@iab.org > - privsec-discuss@iab.org > - stackevo-discuss@iab.org > > The remaining lists will be: > > - architecture-discuss@ietf.org > - chirp@iab.org > - model-t@iab.org > - rfced-future@iab.org > > Best, > Tommy Pauly, on behalf of the IAB > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Mon Apr 20 12:30:21 2020 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 D22633A0DC6 for ; Mon, 20 Apr 2020 12:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4inAdBIpraJ for ; Mon, 20 Apr 2020 12:30:08 -0700 (PDT) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 84F9B3A0D3D for ; Mon, 20 Apr 2020 12:30:08 -0700 (PDT) Received: by mail-pj1-x1029.google.com with SMTP id e6so290532pjt.4 for ; Mon, 20 Apr 2020 12:30:08 -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=tlHHVUrAVK2oJbIXuV9tETW7sUiu02oyRF/R57OYbSQ=; b=KhCCgXoNk3wRDUsxV5qyWzi8SBaz1U1r2lDk+B+Hou+UCPlenHckmPE6C4n33sWIJe hxa1QUPWnO26emCHD2PYwC8B/xBVD17aws/m8Zu8J7pAUN2CbAjD0IKXB0dLKaLRz3H7 8MVGscU1Wyk+6oiXCKyWBJV4ZbIG6Jo6U5G2b+HslXuoyyWTNumWhwiJSZAraX4nmLBG hLp2vdum8PqdATBSqD8MOJ8BC9Ee94TwpdM+l7qU9rkAO2mmqsdvGnxwhwJeCrF5NgN6 7vXOvBgY7VBiL+oMlsM7EEIuygjLLzaYztCD1Av3pJBJqwqPCqsMw1T5QXnqCmj6eF/E tDaA== 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=tlHHVUrAVK2oJbIXuV9tETW7sUiu02oyRF/R57OYbSQ=; b=YPUGZRVwYyvYMRvnBMEsXrSRHDMwNArk5fofe5cCb+0FMj85sJXacZ+8ePLS9Gg9gY l0sv7ZfmdzIKeKxX5+oMZH/YiNE4NchObeKkx4v2R10pHdzQ9iQftCFjlIF4Ua8XuOku 2MrdPdS4FwSoGM7PQu54Mtkq9ugeNeI6oBA7lkEX6Ky0rck02wa9d6N4peI7nFh2danP IzCQpPQVMiBDsFOMpMRKlnKzzFL2IkImy7RRPMva/+2LOeoaVHeG6LP1hrisFsZK/XDQ Pcf94dnr31ktb/JzY25F8YPCJWJ+u6Q/sEqUOMFzbN+99hjNPIJEW1vHUhtSgVYALGPM p4Hw== X-Gm-Message-State: AGi0PuarWXBvaBCHs/FnzFZfc4IWQ1K+vXQxgPK2ugXq5BV8jnDVNgcR QM2mjB/YgDoNoQ4xerT+s815H85mPVJdxxki13qnyw== X-Google-Smtp-Source: APiQypK9B1sDBSqeOrUnjud5mQdWvA3UHnB9SKdEP4iTxKizYENDWWh+8t/Z1xPucSRG8OqPeldbbqz1oMqY9UOPVf4= X-Received: by 2002:a17:90a:d917:: with SMTP id c23mr1111482pjv.192.1587411007852; Mon, 20 Apr 2020 12:30:07 -0700 (PDT) MIME-Version: 1.0 References: <303F494F-F06C-4E6A-99E5-089798EB56DB@apple.com> In-Reply-To: From: Mary Barnes Date: Mon, 20 Apr 2020 14:29:56 -0500 Message-ID: To: Carsten Bormann Cc: Tommy Pauly , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003c523e05a3bded1c" Archived-At: Subject: Re: [arch-d] Updates on IAB mailing lists 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, 20 Apr 2020 19:30:21 -0000 --0000000000003c523e05a3bded1c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The third point about closing all those other lists should really go to the main IETF discussion list - it's really orthogonal to those other lists, which are intentionally very narrow in scope and were often limited to program members. Those other lists were never considered to be under the purview of the architecture-discuss mailing list (at least not when I took over as IAB executive director nor while I was an IAB member). The architecture-discuss list had been around for a long time but hadn't been used much at all until recently. I think is a good thing that it is now being used. Regards, Mary. On Mon, Apr 20, 2020 at 11:12 AM Carsten Bormann wrote: > On 2020-04-20, at 18:08, Tommy Pauly > wrote: > > > > - i18n-discuss@iab.org > > Really? That is a somewhat specialized audience I don=E2=80=99t expect t= o find on > architecture-discuss. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --0000000000003c523e05a3bded1c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The third point about closing all those other lists s= hould really go to the main IETF discussion list - it's really orthogon= al to those other lists, which are intentionally very narrow in scope and w= ere often limited to program members. Those other lists were never consider= ed to be under the purview of the architecture-discuss mailing list (at lea= st not when I took over as IAB executive director nor while I was an IAB me= mber).=C2=A0=C2=A0

The architecture-discuss list h= ad been around for a long time but hadn't been used much at all until r= ecently.=C2=A0 I think is a good thing that it is now being used.=C2=A0

Regards,
Mary.

On Mon, Apr 20, 2020 at 11:12= AM Carsten Bormann <cabo@tzi.org>= ; wrote:
On 2020= -04-20, at 18:08, Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org> wrote: >
> - i18n-discu= ss@iab.org

Really?=C2=A0 That is a somewhat specialized audience I don=E2=80=99t expec= t to find on architecture-discuss.

Gr=C3=BC=C3=9Fe, Carsten

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--0000000000003c523e05a3bded1c-- From nobody Mon Apr 20 12:34:27 2020 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 863933A0D41 for ; Mon, 20 Apr 2020 12:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 xVTHhNpYLbuu for ; Mon, 20 Apr 2020 12:34:23 -0700 (PDT) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 AF2D23A0DA4 for ; Mon, 20 Apr 2020 12:34:23 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id z6so4315833plk.10 for ; Mon, 20 Apr 2020 12:34:23 -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=1xq0TQLfzSZhZepPyYnGeD7id/WOp1jI+ZKd7LBiPxs=; b=ce4lD47/ggbVlQRO8DdbNBHVjcLHYAc8Veren6u540iUK4Miw2zmk+0mwXt6R28dkx I17Al49j7kaKytLGfeeh5APsC4eC/ctxqvUvrUBbfuIrvukKFL39Pu+hDZIP8tKbXJp3 umRHg9W2nE7SOgXQoMge0FJK375L1KLemLVVsPGoLJ934PqBwqY0QIBU75yeW+gUv8LH QSMEPbxHXzdAkJoQigdC5lSaTz/bqjjR0LTlOFr9/3mODznY+Bju2k3xEQpi2eCJxPJC fww5+N5cLYJrIjxcU+vgFFjEv3U29ki/4rAFs4g/lY71Hfh/541L+jdhUb/lEuiEdwmA 4lRg== 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=1xq0TQLfzSZhZepPyYnGeD7id/WOp1jI+ZKd7LBiPxs=; b=ggvveOjfKKIaU8+p4iU1dZHJh/6PbtBDfKlqzjunvVKxuPAjq8hgj/8l5v6a23qzd7 cJZwcw4U5kuXjuIF6ObLIRYC86ozb5MOvrBE2a5a8aHmU02CQ72lzrN+bLUgDB+CXdyc V4twEczKYovQqNemSagcB6Lunvf+olvsKGVIcH3uNsI1aWD1t7CRIObvV5tLUNuVeTsM /8Kqg3Pwdew1ep6Gcu0yKt7psxiTo5ciBGcIwMinpDHLrxDTrB7UCJzB3N3GgRBE4Ifs Fv8ExFlBz0jYZIQpjWMjCUqHVbNLrp9g04uBCPfIDTmzaBomHK1RKg59tcKM5z0pw5+o aSrw== X-Gm-Message-State: AGi0Pua7bRrlHw97KlvwyaYC6QnXzVcM2Niv4V1BDlK9EPCbNB+yAG+A Cga00DSLrpS7C8XTX/cqBtwpxXeyIEL1M95DkeI= X-Google-Smtp-Source: APiQypKA6VhTnRTaVBwW3I2zri3xknxu3Nucmrcgd/wVwERLzYaRXtRwm2LZ8eTTxCohZnuTyQVEzYUFzFKS8w52aXc= X-Received: by 2002:a17:902:148:: with SMTP id 66mr18336169plb.148.1587411263104; Mon, 20 Apr 2020 12:34:23 -0700 (PDT) MIME-Version: 1.0 References: <303F494F-F06C-4E6A-99E5-089798EB56DB@apple.com> In-Reply-To: From: Mary Barnes Date: Mon, 20 Apr 2020 14:34:11 -0500 Message-ID: To: Carsten Bormann Cc: Tommy Pauly , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="000000000000732cce05a3bdfc4c" Archived-At: Subject: Re: [arch-d] Updates on IAB mailing lists 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, 20 Apr 2020 19:34:26 -0000 --000000000000732cce05a3bdfc4c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just to be clear, my point is that architecture-discuss was not intended to be an IAB discussion list any more than IETF discussion list is scoped to IESG discussion. On Mon, Apr 20, 2020 at 2:29 PM Mary Barnes wrote: > The third point about closing all those other lists should really go to > the main IETF discussion list - it's really orthogonal to those other > lists, which are intentionally very narrow in scope and were often limite= d > to program members. Those other lists were never considered to be under t= he > purview of the architecture-discuss mailing list (at least not when I too= k > over as IAB executive director nor while I was an IAB member). > > The architecture-discuss list had been around for a long time but hadn't > been used much at all until recently. I think is a good thing that it is > now being used. > > Regards, > Mary. > > On Mon, Apr 20, 2020 at 11:12 AM Carsten Bormann wrote: > >> On 2020-04-20, at 18:08, Tommy Pauly >> wrote: >> > >> > - i18n-discuss@iab.org >> >> Really? That is a somewhat specialized audience I don=E2=80=99t expect = to find >> on architecture-discuss. >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >> > --000000000000732cce05a3bdfc4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to be clear, my point is that architecture-discuss wa= s not intended to be an IAB discussion list any more than IETF discussion l= ist is scoped to IESG discussion.=C2=A0

On Mon, Apr 20, 2020 at 2:29 PM Mary= Barnes <mary.ietf.barnes@= gmail.com> wrote:
The third point about closing all those ot= her lists should really go to the main IETF discussion list - it's real= ly orthogonal to those other lists, which are intentionally very narrow in = scope and were often limited to program members. Those other lists were nev= er considered to be under the purview of the architecture-discuss mailing l= ist (at least not when I took over as IAB executive director nor while I wa= s an IAB member).=C2=A0=C2=A0

The architecture-dis= cuss list had been around for a long time but hadn't been used much at = all until recently.=C2=A0 I think is a good thing that it is now being used= .=C2=A0

Regards,
Mary.

On Mon, Apr 20, 20= 20 at 11:12 AM Carsten Bormann <cabo@tzi.org> wrote:
On 2020-04-20, at 18:08, Tommy Pauly <tpauly=3D<= a href=3D"mailto:40apple.com@dmarc.ietf.org" target=3D"_blank">40apple.com@= dmarc.ietf.org> wrote:
>
> - i18n-discu= ss@iab.org

Really?=C2=A0 That is a somewhat specialized audience I don=E2=80=99t expec= t to find on architecture-discuss.

Gr=C3=BC=C3=9Fe, Carsten

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--000000000000732cce05a3bdfc4c-- From nobody Mon Apr 20 12:37:47 2020 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 F179E3A0DCD for ; Mon, 20 Apr 2020 12:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 D3HH9TJMt6m1 for ; Mon, 20 Apr 2020 12:37:41 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 40A193A0DCE for ; Mon, 20 Apr 2020 12:37:41 -0700 (PDT) Received: from p200300dee72701008cf2c7a7342b798a.dip0.t-ipconnect.de ([2003:de:e727:100:8cf2:c7a7:342b:798a]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1jQcEc-0002el-Ml; Mon, 20 Apr 2020 21:37:38 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Mirja Kuehlewind In-Reply-To: Date: Mon, 20 Apr 2020 21:37:38 +0200 Cc: Carsten Bormann , Tommy Pauly , "architecture-discuss@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <303F494F-F06C-4E6A-99E5-089798EB56DB@apple.com> To: Mary Barnes X-Mailer: Apple Mail (2.3445.104.14) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1587411461;07d25b7d; X-HE-SMSGID: 1jQcEc-0002el-Ml Archived-At: Subject: Re: [arch-d] Updates on IAB mailing lists 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, 20 Apr 2020 19:37:46 -0000 Hi Mary, hi Carsten, Please find some more information about these lists here: https://www.iab.org/iab-mailing-lists/ The lists we propose to close didn=E2=80=99t have any traffic for a long = time and most of them have been used for discussion related to an IAB = workshop or IAB program that doesn=E2=80=99t exist anymore. We plan to confirm on each of the list that they can be closed. Mirja =20 > On 20. Apr 2020, at 21:29, Mary Barnes = wrote: >=20 > The third point about closing all those other lists should really go = to the main IETF discussion list - it's really orthogonal to those other = lists, which are intentionally very narrow in scope and were often = limited to program members. Those other lists were never considered to = be under the purview of the architecture-discuss mailing list (at least = not when I took over as IAB executive director nor while I was an IAB = member). =20 >=20 > The architecture-discuss list had been around for a long time but = hadn't been used much at all until recently. I think is a good thing = that it is now being used.=20 >=20 > Regards, > Mary. >=20 > On Mon, Apr 20, 2020 at 11:12 AM Carsten Bormann wrote: > On 2020-04-20, at 18:08, Tommy Pauly = wrote: > >=20 > > - i18n-discuss@iab.org >=20 > Really? That is a somewhat specialized audience I don=E2=80=99t = expect to find on architecture-discuss. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Mon Apr 20 12:42:20 2020 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 4FCEA3A0DEC; Mon, 20 Apr 2020 12:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 LoDJl5vzbr9L; Mon, 20 Apr 2020 12:42:10 -0700 (PDT) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 30F243A0DED; Mon, 20 Apr 2020 12:42:10 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id nu11so311554pjb.1; Mon, 20 Apr 2020 12:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=AJEYlqkuHuqvD/31whGdBeF6eVynxsLqeDaYBSJFMpU=; b=QqJuDnVCs3XFNsHtXRvQfHRCqd2RqDUJRK9Drtl95ttyfATzo/0D83l0HnF4zk6RPv m7ycEHlWx3eugDFD9wK9PfmgWS7Jk8tbLIKfRTpPiVJeGtQH04zsxtEoRcKfwLb+pnkZ 6TFN/tIVi7InMEY3r26ciFC9G1kh0jU9A12ED1JmjG/Rcy5Ct8Vh0DYO+ChvW7wVXBSV 2B4ATB9GvZzeH3ifwEcPF7prnvLlOLwUDsObLo1BdCZEgB5fN2PxmTkMNNw66Fco00Ry LuqNd3f8QEcGrvwS7NcIgxpPt+OhCb6xixOq7CVC66uUp8pF5xmwlrdD0HrN6kQG7Eik Q/NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=AJEYlqkuHuqvD/31whGdBeF6eVynxsLqeDaYBSJFMpU=; b=bYEDYqFYFAMeZsI33uobejc0LXMj49QntY/vNzSHoufFWT2NrblZ/eoaBiapcBDzBK DXy0jWf0Q6dFEuUif1uAYw4l8+IaHpjOZ27twNH4cx/bUcDNz3+eUMVXDbCjH12Gm0S5 /R6VMEosNyk9ymm4ATg5OMRKnUymaS4o6EgPx6/Cdr0MGZ7t0bDkQaTZJ2OAvSkjur2N slr4oE0fPq/hqh+ESAXr8LhfYrJGFiXhuynkwjkbRaVsqCLphvlwWNdY3HzOVKicOUD8 bc9Lo9bmfVNBWDJK+x+2bhBP0mNXQZTmgrNjrusNWTdMfYa2dBDSb+aTN5PYYMszO+8Z FcYQ== X-Gm-Message-State: AGi0PuY+qoxkeFZiBhJoLOAchqSq4Txze7fRQiKqVbw2qY/lg4uiY0mC TmOh44AUVIJmGSRzyXPB+OYVFnVv X-Google-Smtp-Source: APiQypKVNi6eHJmkNiSB+eSnjf8NtmwjEs/beRGn5KQvS7wlgwgSqr37vxkW2gKP1NdprWmSp9ANKg== X-Received: by 2002:a17:90a:2323:: with SMTP id f32mr1127992pje.139.1587411729305; Mon, 20 Apr 2020 12:42:09 -0700 (PDT) Received: from [192.168.1.137] ([63.140.71.170]) by smtp.gmail.com with ESMTPSA id b20sm298126pff.8.2020.04.20.12.42.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Apr 2020 12:42:08 -0700 (PDT) To: Toerless Eckert , Tommy Pauly , iesg@ietf.org, ietf@ietf.org Cc: "architecture-discuss@ietf.org" References: <20200420184456.GG5351@faui48f.informatik.uni-erlangen.de> From: Melinda Shore Message-ID: Date: Mon, 20 Apr 2020 11:42:06 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200420184456.GG5351@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] iesg: Re: Updates on IAB mailing lists 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, 20 Apr 2020 19:42:12 -0000 On 4/20/20 10:44 AM, Toerless Eckert wrote: > 1. It is called architecture-discuss@ietf.org, not @iab.org Note that ietf.org hosts a number of mailing lists that are not "official" IETF activities. You can find a list of all IETF mailing lists at https://www.ietf.org/mailman/listinfo. The main reason we have so many mailing lists is to group things which are like and separate things which are not like, to keep discussions manageable. architecture-discuss exists to support the activities of the IAB. Presumably a discussion of homenet architecture would not be welcome on architecture-discuss. It seems to me that it makes more sense to request a new list for the discussions that you'd like to have than to repurpose an existing list over the objections of the list owners/managers/SAAs. Melinda From nobody Mon Apr 20 12:49:34 2020 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 D418C3A0E13; Mon, 20 Apr 2020 12:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERxxxdpi9J24; Mon, 20 Apr 2020 12:49:31 -0700 (PDT) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 5EA5E3A0E0B; Mon, 20 Apr 2020 12:49:31 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id d184so1066151pfd.4; Mon, 20 Apr 2020 12:49:31 -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=ppwTtvJoxW0AHt/VcIWvLhix9YN17QCVkk48uTPvPeU=; b=a85GzQYp+aQoi571cF9cPU+dQFndYyJIiNBTcsEdrheqtQU304hUdtVZprjD4lgjqM AWAY6QSDsntjtsYF9CDat5cul1lPrbWFl7LmtsRmvWgCYM3nGb5b66F64Sw1fF0Vb5kR AZsoNDq7VLYWX9Gw8SJN08yI7S+kgWUw6rbP5kKgiLY01HPPxGaT89N9hhaRlB1tLozW Tn8YqSR5Udvo6kg5JQFm9RH5/YrTolvi6VrFUiU4uK3eQlyOKbVdslD++2IHrZN3i8Qp 0nQMx9ovXYP+EbItKeXCVJDoKAmd4US6yQ/JeVhD9C/Fj2U0ALJQ7m23PyN9f+Pe0Z4Z OOvw== 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=ppwTtvJoxW0AHt/VcIWvLhix9YN17QCVkk48uTPvPeU=; b=Vs8mhOOFVRTpoOdt00tu43xhPKtqZ2tv+qkrhbU+wzqAoE69X41mklTJze7bTzBnoH 5B+Qwv3141NtnHMpGnZ6CtKTHbtYiP6xX5KB77WLxU8po0/cAP9CyTsSnGK+dslFwdm2 zLuvHZVHFFThb/FRjoDhB/vQ9ahDTOnqFiWA9g+xYDQlO9G9M8knmHjgzBEh1+79jxCG QClAPPneRqm7FiZbdE/BGL4A6ncIG7dx5b5vEyk2fevk/G63gw1QE6XmBoqdlrVxvd4n L3pQXFRKfMi8NhGCaPTEGRLBO8iDRMKHsbr1v84rBHe9UOLknS2tAA3xG3a9WmVdPDCb smqg== X-Gm-Message-State: AGi0PubOfMqLnagTz0pE35Gpei6s9kcWQIFl/Y/TrAsVSeujLyZV7lOn u96uir6n/kGzx1EBl//e9iWwu9DI6AKbtIG5vLU= X-Google-Smtp-Source: APiQypIb9Rzlf0zOGkhoPPfujyW0mRjqXUAp8Uhw6Lo9p+a+1CSg2Mo/3zdcFDEG2QmtcP6Z9yIsb3LrsZYT/Ex8+Ik= X-Received: by 2002:a62:cdc9:: with SMTP id o192mr18833152pfg.310.1587412170924; Mon, 20 Apr 2020 12:49:30 -0700 (PDT) MIME-Version: 1.0 References: <20200420184456.GG5351@faui48f.informatik.uni-erlangen.de> In-Reply-To: From: Mary Barnes Date: Mon, 20 Apr 2020 14:49:19 -0500 Message-ID: To: Melinda Shore Cc: Toerless Eckert , Tommy Pauly , The IESG , IETF-Discussion list , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008f67c005a3be32a6" Archived-At: Subject: Re: [arch-d] iesg: Re: Updates on IAB mailing lists 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, 20 Apr 2020 19:49:33 -0000 --0000000000008f67c005a3be32a6 Content-Type: text/plain; charset="UTF-8" If the intent is that the list is specific to IAB activities (as I said in my response, that wasn't the intent in the past), then you all should update the description. Personally, I think it's a handy list to have for purely technical discussions as opposed to all the non-technical discussions on the main IETF discussion list. On Mon, Apr 20, 2020 at 2:43 PM Melinda Shore wrote: > On 4/20/20 10:44 AM, Toerless Eckert wrote: > > 1. It is called architecture-discuss@ietf.org, not @iab.org > > Note that ietf.org hosts a number of mailing lists that are not > "official" IETF activities. You can find a list of all IETF > mailing lists at https://www.ietf.org/mailman/listinfo. The > main reason we have so many mailing lists is to group things which > are like and separate things which are not like, to keep discussions > manageable. architecture-discuss exists to support the activities of > the IAB. Presumably a discussion of homenet architecture would > not be welcome on architecture-discuss. > > It seems to me that it makes more sense to request a new list for the > discussions that you'd like to have than to repurpose an existing list > over the objections of the list owners/managers/SAAs. > > Melinda > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --0000000000008f67c005a3be32a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If the intent is that the list is specific to IAB activiti= es (as I said in my response, that wasn't the intent in the past), then= you all should update the description.=C2=A0 Personally, I think it's = a handy list to have for purely technical discussions as opposed to all the= non-technical discussions on the main IETF discussion list.=C2=A0
On Mon, A= pr 20, 2020 at 2:43 PM Melinda Shore <melinda.shore@gmail.com> wrote:
On 4/20/20 10:44 AM, Toerless Eckert wrote= :
>=C2=A0 =C2=A0 1. It is called architecture-discuss@ietf.org, not @iab.org

Note that = ietf.org hosts a number of mailing lists that are not
"official" IETF activities.=C2=A0 You can find a list of all IETF=
mailing lists at https://www.ietf.org/mailman/listinfo.=C2= =A0 The
main reason we have so many mailing lists is to group things which
are like and separate things which are not like, to keep discussions
manageable.=C2=A0 architecture-discuss exists to support the activities of<= br> the IAB.=C2=A0 Presumably a discussion of homenet architecture would
not be welcome on architecture-discuss.

It seems to me that it makes more sense to request a new list for the
discussions that you'd like to have than to repurpose an existing list<= br> over the objections of the list owners/managers/SAAs.

Melinda

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--0000000000008f67c005a3be32a6-- From nobody Mon Apr 20 12:52:07 2020 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 93E123A0E36; Mon, 20 Apr 2020 12:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 QzvlkABxdXVP; Mon, 20 Apr 2020 12:52:03 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 54E4E3A0E39; Mon, 20 Apr 2020 12:52:03 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id n16so5598538pgb.7; Mon, 20 Apr 2020 12:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=rL8u+1GWv2v0vdhBfhJdPoVN1LXd9c4zdiMDUuw5Nco=; b=unemUbJeQg/fNRPC8AXbpNdD9XEwXpooX7ldXgBcmntxyjS6sT9pwEzP57RmmQb6kH TMYUQL8ydjIHfv2jbvQ42+KEAFg45lk4Igajj6uHEgeCJy/N3hf5eQ3xjDR11O0yrmV3 nb97kr4D0iaJRRVQHq7gv71RgMy5S8hc2MEP0eJDVuhHeHpyepZ++2s84pqicSfXzFT+ N5YVWQWhzHI1ZHSsGTGBM9R3JqVZvrCgO+JCfk6FngrB+l2sFEj8fbksuuxhUJ18BQm6 v+kmtIJHw1CViQoHlDgUAcu7BvQhFncOREKHCNRzs8wivGJ2v3yv8fx7W2L6E15Lo5nJ CBDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rL8u+1GWv2v0vdhBfhJdPoVN1LXd9c4zdiMDUuw5Nco=; b=k9E+vEUPUXBkvt2OJ4KMrQd3Dfzuw/bSwazLR3xk16hy6ql8vxNeAERQjtNE3T6liP 4gPmYo42UIU3loLoOrk77m4/4DKpnvx6LeiRxQlIqGNq7ha8ar8dE90PEHhaC5bK966u N2MTvw7jOeajAiHqK623SCsV+Jey0D9gTfrVrzTf0jOb2bY1h+MgDZuvMjQOoXCWkbXh sHHftXavx+HQjMT5EcVnOYul71vMcgbzhw42RiX3Pd1zPXjUhqX541VXPq6VjkJzxA3T 5GiorhZ6ZjryVzIj9SDGw01T3VPIcL4zMuvqOzms//LFU+jWMGJizIFXEupOiwf2GV2y zDRw== X-Gm-Message-State: AGi0PuapTBOqJjRz8IPC6yXmVPZNWHpMpnlxhdlnTURhjmA3jEZ39Ye3 7F7yrQzoJfwl/dWnPjFyxOeKOAC3 X-Google-Smtp-Source: APiQypIq4RGgCvd65KqB+iQCY9M8Mg5aGmIoNy2oW4CxeVgahnxHOc0sXPKMxs9qP8G6hyEWWCvY2g== X-Received: by 2002:a63:4a01:: with SMTP id x1mr18217979pga.362.1587412322590; Mon, 20 Apr 2020 12:52:02 -0700 (PDT) Received: from [192.168.1.137] ([63.140.71.170]) by smtp.gmail.com with ESMTPSA id j32sm148280pgb.55.2020.04.20.12.52.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Apr 2020 12:52:02 -0700 (PDT) To: Mary Barnes Cc: Toerless Eckert , Tommy Pauly , The IESG , IETF-Discussion list , "architecture-discuss@ietf.org" References: <20200420184456.GG5351@faui48f.informatik.uni-erlangen.de> From: Melinda Shore Message-ID: <93a7ae7f-c2bc-a009-baa9-8671de5ee384@gmail.com> Date: Mon, 20 Apr 2020 11:52:00 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.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] iesg: Re: Updates on IAB mailing lists 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, 20 Apr 2020 19:52:05 -0000 On 4/20/20 11:49 AM, Mary Barnes wrote: > Personally, I think it's a handy list to have > for purely technical discussions as opposed to all the non-technical > discussions on the main IETF discussion list.  Right, but I think it's clear that it's not every technical discussion, which circles back around to Toerless's argument. Melinda From nobody Mon Apr 20 13:14:13 2020 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 29F603A0EDF; Mon, 20 Apr 2020 13:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 xyKTJji3SxjU; Mon, 20 Apr 2020 13:14:09 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 789A73A0EE4; Mon, 20 Apr 2020 13:14:09 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id q18so2089854pgm.11; Mon, 20 Apr 2020 13:14:09 -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=1ePCTQDy68sKGvcDOAyA0Blfe55I3t8tJJwdLGlslec=; b=bzDEw76RJJo1ka/3MiN9Ks/OrXqiwl6zw+F02NhgIQXoV3w5vVoi5DEwmGGV9Om6wb 6jQT+B0Jx8M5jzDDffQl3rzD8zKnfHu8qIGT8SjaI/+SLMVOx0SpVAgF8nedL6ue/qyY 8ny3ghaCP83HBuesYhQ6CkA2+YhDC6miAD7AZTuI30diyaDq6aOct0lrzweBiogDiD7m oD7I3S5Zeu5oQv/0FndQn2995E1ZqvyQJz7Umu8yeRZSgew/JXmxYwZumF47eKX5TKVp vVoAaDKFPuDT5svp0lwtPsu3oc2gP+0wIxQd1B7brMBwLQlsDsMfv/yf6rLDqNK19VWp rCrg== 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=1ePCTQDy68sKGvcDOAyA0Blfe55I3t8tJJwdLGlslec=; b=A/Pml/QJcmQ/rdYvUygi93cB+5y801reUqKAcTY6s0aOEAcC+rF48oxutcu0AU4o7V RNrNXvBZDoPAE+JGXe7BR/+8cwh6B0eOD/5MNjmq0FWZOe0z0zvqeCab86CAuLyRqjlw /Z6q2W3a5nIqmf8XWEkRVbZMFb+2QRKlecx8ae5MiRo4L+lznFkkUgiT4ZqLwahOPHYX Bb9e5adraqTtvlbKwiDjkh/YJsK2P2ZlP2iggXBPrcJK9QaLV2u5UKA5hlgw7DWq9xzE Zl95V4LBv/+usYcuF1Q1z0VNocAlysIYKBOd/hLPKThUQ4zGtAYmrOnt0XBImlnXl3mx zzCQ== X-Gm-Message-State: AGi0PuY0sgXdKl4UF5IIXoL3TzpNHyWuS6INXTxIsRJKZZUaui+T9w8z SZ3CwvA9OgNt4d4NjZrAlYajxJa0csA0hNzlpSI= X-Google-Smtp-Source: APiQypLdsZ74CV6egzMSW8su932xjVwE4lD9Aafu449vYZVBQpFzZwznWDt7MNTIl0kcUYeVMBZ+hPRZ/1eiG5yftvs= X-Received: by 2002:a63:c504:: with SMTP id f4mr18082748pgd.292.1587413648763; Mon, 20 Apr 2020 13:14:08 -0700 (PDT) MIME-Version: 1.0 References: <20200420184456.GG5351@faui48f.informatik.uni-erlangen.de> <93a7ae7f-c2bc-a009-baa9-8671de5ee384@gmail.com> In-Reply-To: <93a7ae7f-c2bc-a009-baa9-8671de5ee384@gmail.com> From: Mary Barnes Date: Mon, 20 Apr 2020 15:13:57 -0500 Message-ID: To: Melinda Shore Cc: Toerless Eckert , Tommy Pauly , The IESG , IETF-Discussion list , "architecture-discuss@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a56df205a3be8a25" Archived-At: Subject: Re: [arch-d] iesg: Re: Updates on IAB mailing lists 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, 20 Apr 2020 20:14:11 -0000 --000000000000a56df205a3be8a25 Content-Type: text/plain; charset="UTF-8" Thanks - I hadn't followed Toeless' thread where he encountered the problem that triggered his email. Just to make sure I understand - the architecture-discuss list is intended only for topics that the IAB deems of interest specifically to the IAB and NOT a general community list to discuss things related to the Internet architecture. Is that correct? If so, then it does seem we need a list where folks can have discussion of technical topics that aren't necessarily related to work IAB is doing. I know we've discussed in the past that the IETF discussion list is most suitable for those discussions but I think most would agree that the list has a whole lot more discussion of how we do non-technical things than technical (I would guess 90/10 for the most part). I think many don't pay near the attention to the list that they might if it were technical discussions - for example, I subscribe to that list using my general email that I use for not real work. So, one question I would have then, is whether it's thus only appropriate for someone in the community to post to architecture-discuss if they are asking specific questions on current IAB activities and documents? Regards, Mary. On Mon, Apr 20, 2020 at 2:52 PM Melinda Shore wrote: > On 4/20/20 11:49 AM, Mary Barnes wrote: > > Personally, I think it's a handy list to have > > for purely technical discussions as opposed to all the non-technical > > discussions on the main IETF discussion list. > > Right, but I think it's clear that it's not every technical > discussion, which circles back around to Toerless's argument. > > Melinda > > --000000000000a56df205a3be8a25 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks - I hadn't followed Toeless= 9; thread where he encountered the problem that triggered his email.
Just to make sure I understand - the architecture-discuss list= is intended only for topics that the IAB deems of interest specifically to= the IAB and NOT a general community list to discuss things related to the = Internet architecture.=C2=A0 Is that correct?=C2=A0 =C2=A0If so, then it do= es seem we need a list where folks can have discussion of technical topics = that aren't necessarily related to work IAB is doing.=C2=A0 =C2=A0I kno= w we've discussed in the past that the IETF discussion list is most sui= table for those discussions but I think most would agree that the list has = a whole lot more discussion of how we do non-technical things than technica= l (I would guess 90/10 for the most part).=C2=A0 =C2=A0I think many don'= ;t pay near the attention to the list that they might if it were technical = discussions - for example, I subscribe to that list using my general email = that I use for not real work.=C2=A0

So, one questi= on I would have then, is whether it's thus only appropriate for someone= in the community to post to architecture-discuss if they are asking specif= ic questions on current IAB activities and documents?=C2=A0=C2=A0

Regards,
Mary.=C2=A0

On Mon, Apr 20, 2020 at= 2:52 PM Melinda Shore <melin= da.shore@gmail.com> wrote:
On 4/20/20 11:49 AM, Mary Barnes wrote:
> Personally, I think it's a handy list to have
> for purely technical discussions as opposed to all the non-technical > discussions on the main IETF discussion list.=C2=A0

Right, but I think it's clear that it's not every technical
discussion, which circles back around to Toerless's argument.

Melinda

--000000000000a56df205a3be8a25-- From nobody Mon Apr 20 13:30:57 2020 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 E2C9C3A0F41 for ; Mon, 20 Apr 2020 13:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 mAfDAsDf7kCN for ; Mon, 20 Apr 2020 13:30:54 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94763A0F3E for ; Mon, 20 Apr 2020 13:30:53 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 495dcq6KpSzyfh; Mon, 20 Apr 2020 22:30:51 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Mon, 20 Apr 2020 22:30:51 +0200 Cc: Mary Barnes , Tommy Pauly , "architecture-discuss@ietf.org" X-Mao-Original-Outgoing-Id: 609107451.52458-bb31d9da9c2619f2864efb60de95eda5 Content-Transfer-Encoding: quoted-printable Message-Id: <18F278F7-0DFB-4902-8EB6-9EBBC3AF5640@tzi.org> References: <303F494F-F06C-4E6A-99E5-089798EB56DB@apple.com> To: Mirja Kuehlewind X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [arch-d] Updates on IAB mailing lists 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, 20 Apr 2020 20:30:56 -0000 On 2020-04-20, at 21:37, Mirja Kuehlewind wrote: >=20 > The lists we propose to close didn=E2=80=99t have any traffic for a = long time and most of them have been used for discussion related to an = IAB workshop or IAB program that doesn=E2=80=99t exist anymore. For i18n-discuss, there are occasional flares of activity, the last = significant one 2018-12. This is not =E2=80=9Cfor a long time=E2=80=9D. These flares reached exactly the right set of people. Is there a reasonable alternative that doesn=E2=80=99t waste the time of = hundreds of others? > We plan to confirm on each of the list that they can be closed. OK, so I can shut up here now. Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Apr 20 13:58:01 2020 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 944333A0FBB for ; Mon, 20 Apr 2020 13:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.203 X-Spam-Level: X-Spam-Status: No, score=0.203 tagged_above=-999 required=5 tests=[DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 mBZiSpPpv-IX for ; Mon, 20 Apr 2020 13:57:55 -0700 (PDT) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF133A0FB8 for ; Mon, 20 Apr 2020 13:57:49 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.37.130]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 03KKvXcd029391 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Apr 2020 13:57:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1587416265; x=1587502665; i=@elandsys.com; bh=BlVWYYTL9aKHnySuxT86iD3W7nkBYl1ESKhjObJs2WQ=; h=Date:To:From:Subject:In-Reply-To:References; b=p6aXcidiUEVoijjhxP+JGMhx6FjWZvWhp4Uv0Oy+/2zPAwZTcaAvnsjM8D0QzSCQt kpdVmtSXn7a7E0uPnzkDLfLDNhNAE+bM1vYoY+H5Gusm/B4UOMwesSi7zPhGhIhLTx U9JszsTaw26HwA+kWECrm8bFddfVIVG8M8fxjuAw= Message-Id: <6.2.5.6.2.20200420124357.12e4b868@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 20 Apr 2020 13:54:29 -0700 To: Tommy Pauly , architecture-discuss@ietf.org From: S Moonesamy In-Reply-To: <303F494F-F06C-4E6A-99E5-089798EB56DB@apple.com> References: <303F494F-F06C-4E6A-99E5-089798EB56DB@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] Updates on IAB mailing lists 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, 20 Apr 2020 20:58:00 -0000 Dear Mr Pauly, At 09:08 AM 20-04-2020, Tommy Pauly wrote: >We'd like to share a few updates about IAB mailing lists, and >solicit the community's feedback on some new text. > >First, Tommy Pauly will be joining Stephen Farrell on the (existing, >but rarely employed) sergeants-at-arms team to help moderate the list. > >Second, we'd like to clarify the sergeants-at-arms roles for the >lists. The current description on >https://www.iab.org/iab-mailing-lists/ does mention that the lists >use a sergeant-at-arms model for moderation, but does not describe >what this role entails. It also does not specify if this role >applies to all of the lists on the page, such as program lists. > >We're proposing adding the following text to >https://www.iab.org/iab-mailing-lists/, largely based on the IETF >list SAA. We'd love to hear feedback on this approach! I would like to thank the Internet Architecture Board for requesting feedback about the architecture-discuss@ietf.org mailing list. Given the domain name in that email address, isn't it a mailing list which falls under the Internet Engineering Task Force? There was an announcement about the moderators some time ago. I don't recall seeing them described as "sergeant-at-arms". I looked up the term and I found this: "in feudal England a sergeant at arms was an armed officer of a lord and was often one of a special body required to be in immediate attendance on the king's person, to arrest traitors and other offenders". Given some recent interventions on the ietf@ mailing list, I would not suggest the sergeant at arms as a model to follow. Regards, S. Moonesamy From nobody Mon Apr 20 14:00:43 2020 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 23F5A3A0FCD; Mon, 20 Apr 2020 14:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 sUFHhNFf5T3W; Mon, 20 Apr 2020 14:00:35 -0700 (PDT) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 D5F093A0FCB; Mon, 20 Apr 2020 14:00:34 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 03KKxpqc047498; Mon, 20 Apr 2020 14:00:29 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=SNxJ8WptW4UCrwFx/Nb1TEsfF6w6n91hKThHc73OShQ=; b=bRCk7QloigqClOZCMjVWzILNi+pXFwAWxt3tChERnteuceEVWjg2JGzDLB2ZpNPTIfaW t7hKERsgJujDobd7pXyTRnqyOhEINEqEW7YvJgZIA4oOSHLZaxhZT2JUl8/mVQxBvf/+ 7+zeNX+mKW4KYXdCqRRe98PLLHDCOJBakY3l3GFzAGyt6+XYkJGyXAPTES+03b2MRDQE 7izfYejFCVpnsVMsT1PfABth+usb59TLUk/u+u2KMo5UN9lkdWsR6jh0tV4l2ZFdl4I9 z2E5CInozDzcCXBQbEu3TF7IbG0D15lDXHKwz2ic4/aRDJf5JaBHarfDFLiXFafai5UX bQ== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 30hfm2ktt2-13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 20 Apr 2020 14:00:29 -0700 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0Q9300ULSUCSB100@rn-mailsvcp-mta-lapp01.rno.apple.com>; Mon, 20 Apr 2020 14:00:28 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0Q9300N00UB73200@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Mon, 20 Apr 2020 14:00:28 -0700 (PDT) X-Va-A: X-Va-T-CD: b7d31c02c886c19cbc2b09bcac99d6f7 X-Va-E-CD: c8ceaf7a504d9a706abb415c3056211a X-Va-R-CD: 212de666095350032512e1e53cfa430b X-Va-CD: 0 X-Va-ID: 80431bc9-8d67-4bc7-89b7-059d19cbff87 X-V-A: X-V-T-CD: b7d31c02c886c19cbc2b09bcac99d6f7 X-V-E-CD: c8ceaf7a504d9a706abb415c3056211a X-V-R-CD: 212de666095350032512e1e53cfa430b X-V-CD: 0 X-V-ID: c0302d6c-74ca-4d0b-bf6d-c72f0093c58f X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-20_08:2020-04-20, 2020-04-20 signatures=0 Received: from [17.234.48.87] (unknown [17.234.48.87]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0Q9300IN7UCN8V00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Mon, 20 Apr 2020 14:00:28 -0700 (PDT) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) From: Tommy Pauly In-reply-to: <20200420184456.GG5351@faui48f.informatik.uni-erlangen.de> Date: Mon, 20 Apr 2020 14:00:23 -0700 Cc: iesg@ietf.org, ietf@ietf.org, "architecture-discuss@ietf.org" Content-transfer-encoding: quoted-printable Message-id: References: <20200420184456.GG5351@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-20_08:2020-04-20, 2020-04-20 signatures=0 Archived-At: Subject: Re: [arch-d] iesg: Re: Updates on IAB mailing lists 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, 20 Apr 2020 21:00:37 -0000 Hi Toerless, > Dear Tommy, *: >=20 > Wrt to your intention to put IAB mailing lists under the following = proposed policies: >=20 >> Inappropriate postings consist of: spam and bulk e-mail; >> unprofessional commentary, regardless of subject; >=20 > OK. >=20 >> announcements of conferences or activities that are not sponsored >> or endorsed by the Internet Society, the IETF, or the IAB >=20 > OK. >=20 >> and discussion of subjects unrelated to IAB policy, >> programs, activities, or technical concerns" How about =E2=80=9Cand mail with content unrelated to technical = discussion, Internet architecture, or activities of the IAB=E2=80=9D? Please see further for more discussion of the intent here. >=20 > NOK for list that go beyond those points. = architecture-discuss@ietf.org > clear goes beyond those points. >=20 > a) I read this as a long-winding workaround to prohibit > the IETF community to self-organize without official leadership > support in inofficial side meetings using the IETF mailing list > architecture-discuss@ietf.org >=20 > I suspect these rules have especially been crafted to prohibit me to > invite community members interested in architecture discussion = around > New IP to inofficial side meetings via the = archiecture-discuss@ietf.org > mailing list in the future, as i did in the past for IETF106 and = IETF107. >=20 > AFAIK, it is not only common practice, but quite desirable > for the community to use IETF/IRTF mailing lists to self-organize > into whatever form of inoffical side meeting is appropriate on > topics of intererst to that mailing list. Bar BOFs not being easy > in times of corona. Likewise i think that notifications about = events > related to a mailing lists topic are quite common. The notion that > only official sponsored events can be brought up sounds quite = strange > to me and quite contrary to the open nature of the IETF/IRTF. It is not the intention of this clarification in the SAA role to at all = restrict discussion of the topics you=E2=80=99re bringing up here, such = as New IP, or to to limit discussion of side meetings about such. = Indeed, such discussion (even if it isn=E2=80=99t an event organized by = the IAB), is of relevance and interest to Internet architecture. Working on this text is certainly good to do with your input, and = others. The current text is lifted mainly from the IETF discussion list = SAA description. The goal of mentioning irrelevant activities was more to make it clear = that if someone started posting what is effectively spam to a list, that = the SAA could reach out to the person to moderate that. What is relevant = to each list is dependent on the list. Architecture-discuss is indeed a = broad list, and any discussion that is truly about Internet architecture = fits. Largely, the motivation to update and clarify this text is to ensure = that the community agrees on what the *existing* role of the SAA is for = these lists, and to ensure that if there is a instance in which the SAA = does need to step in (let=E2=80=99s say, due to spamming the list), that = there is a consistent and standard response to make. My hope is to limit = this role such that it cannot be used in the ways you mention (limiting = community discussion and organization of relevant topics). >=20 > b) If IAB wants to enforce such restrictive policies for = communications > on an intentional open mailing list such as = architecture-discuss@ietf.org, > then this adds severely to my concerns about how IAB operates. I = think=20 > it is unbecoming for an ISOC entity. >=20 > To me, architecture-discuss@iab.org is clearly not a mailing list > that currently is or in the future should be subject to such IAB > communication constraints: >=20 > 1. It is called architecture-discuss@ietf.org, not @iab.org >=20 > 2. About: https://www.ietf.org/mailman/listinfo/Architecture-discuss This list is, in fact, an IAB-sponsored activity since its inception. = The list does exist at both @ietf.org, and @iab.org. >=20 >> The architecture-discuss list serves as a technical discussion >> forum for all members of the IETF community that are interested >> in larger > architectural issues. It is meant to be an open = discussion >> forum for all long and/or wide range architectural concerns related >> to the Internet Architecture. In particular, it may be used to >> discuss and bring forth different points of view on controversial >> architectural questions. Discussions that drill down and dwell >> on specifics of individual protocols or technologies are to be >> discouraged, redirected to appropriate other fora, or re-cast to >> discussions of broader implications for Internet architecture. >=20 > 3. The mayority of the discussions on the mailing list are clearly = not > lead by IAB, but are useful for the community. There is absolutely = no > need for such a mailing list to be constrained to proposed new = strict > IAB regime. Instead i think IAB membersh should be welcome into the > discussion of the community. Indeed, the discussion on the list is to be encouraged! The goal of = clarifying the policy is to ensure that, as this list is an = IAB-sponsored activity, that the community does have a productive and = open space to discuss. The SAA=E2=80=99s role is to handle spam or abuse = only. Thanks, Tommy >=20 > Cheers > Toerless >=20 > On Mon, Apr 20, 2020 at 09:08:48AM -0700, Tommy Pauly wrote: >> Hello architecture-discuss, >>=20 >> We???d like to share a few updates about IAB mailing lists, and = solicit the community???s feedback on some new text. >>=20 >> First, Tommy Pauly will be joining Stephen Farrell on the (existing, = but rarely employed) sergeants-at-arms team to help moderate the list. >>=20 >> Second, we???d like to clarify the sergeants-at-arms roles for the = lists. The current description on https://www.iab.org/iab-mailing-lists/ = does mention that the lists use = a sergeant-at-arms model for moderation, but does not describe what this = role entails. It also does not specify if this role applies to all of = the lists on the page, such as program lists. >>=20 >> We???re proposing adding the following text to = https://www.iab.org/iab-mailing-lists/ = , largely based on the IETF list = SAA. We???d love to hear feedback on this approach! >>=20 >> =3D=3D=3D=3D >>=20 >> IAB mailing lists have sergeants-at-arms, whose role is ensure there = are no inappropriate postings. Inappropriate postings consist of: spam = and bulk e-mail; announcements of conferences or activities that are not = sponsored or endorsed by the Internet Society, the IETF, or the IAB; = unprofessional commentary, regardless of subject; and discussion of = subjects unrelated to IAB policy, programs, activities, or technical = concerns. >>=20 >> The sergeants-at-arms are empowered to restrict posting by a person = or of a thread when the content is inappropriate and represents a = pattern of abuse. Complaints regarding a decision should be referred to = the IAB chair. >>=20 >> The current sergeants-at-arms for ???architecture-discuss@ietf.org = ??? are Stephen Farrell and Tommy = Pauly. For program-specific lists, the program chairs act as moderators. = The "rfc-interest@rfc-editor.org ??? = list is moderated by the Temporary RFC Series Project Manager. >>=20 >> =3D=3D=3D=3D >>=20 >> Third, we have many lists that are enumerated on the website that are = for closed programs or past workshops. We checked the activity on these = lists, and we believe that we can close the following lists. Any further = discussion on these topics is welcome on architecture-discuss. >>=20 >> - caris-attendees@iab.org >> - emserv-discuss@iab.org >> - i18n-discuss@iab.org >> - inip-discuss@iab.org >> - internetgovtech@iab.org >> - iotsi@iab.org >> - iotsu@iab.org >> - marnew@iab.org >> - privsec-discuss@iab.org >> - stackevo-discuss@iab.org >>=20 >> The remaining lists will be: >>=20 >> - architecture-discuss@ietf.org = >> - chirp@iab.org >> - model-t@iab.org >> - rfced-future@iab.org >>=20 >> Best, >> Tommy Pauly, on behalf of the IAB >=20 >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Mon Apr 20 14:05:06 2020 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 1C3513A0FDE for ; Mon, 20 Apr 2020 14:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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 HlERbE53WjfY for ; Mon, 20 Apr 2020 14:04:59 -0700 (PDT) Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (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 67E173A0FDC for ; Mon, 20 Apr 2020 14:04:59 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 03KL2ZSa013731; Mon, 20 Apr 2020 14:04:44 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=EnvfA/gT8Sy1Ml6Q6Q4XN+hqdbw1C2gKNPgVHre+pY4=; b=bFFvLf5HCVq05gROwZWLJP+lfnoKpjFRSJEkElLlfY3KvKLyYoaWeLPcfZ7lxyRuy3nc 0PNQLhRf+M10iEOTMgVFl6vsiwmMjuUbuLFPT9Nouek7JSPKWADlqbyJ0jbYIjVmzXtv m8XE/igDAhEAFJLzU+J5WA6ZZScpA6eHcv4TJTg7d9ChwZloDBUcHDkr3pRor5coyblq ucAq9wtwtYf3Q94snVwStIQJ1o7TSpHKes/mCEPZGzY8tSPQe25+uFz8D8Nvn5Rmcf1C wr3qppe09ztr1EcOELqdpYEvVxIM6CWOjBjBkWQ9ngz6KQNGS/XJjgVvuzORr5M+4Sd0 rg== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by nwk-aaemail-lapp01.apple.com with ESMTP id 30hj7214h8-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 20 Apr 2020 14:04:44 -0700 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0Q9300MM0UJVTWA0@rn-mailsvcp-mta-lapp02.rno.apple.com>; Mon, 20 Apr 2020 14:04:43 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0Q9300N00UB73200@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Mon, 20 Apr 2020 14:04:43 -0700 (PDT) X-Va-A: X-Va-T-CD: 9ef1c94aca2a985c968936d4baa34f4e X-Va-E-CD: 9cf9b30cf458d3b18920c7b9603d62bd X-Va-R-CD: 940e86883ca42bcfe4e4c9b965eae3b0 X-Va-CD: 0 X-Va-ID: 3b7e4876-c747-483d-98f3-e0811d3434d1 X-V-A: X-V-T-CD: 9ef1c94aca2a985c968936d4baa34f4e X-V-E-CD: 9cf9b30cf458d3b18920c7b9603d62bd X-V-R-CD: 940e86883ca42bcfe4e4c9b965eae3b0 X-V-CD: 0 X-V-ID: 08e6e9a7-0a3a-4082-985d-e69f6ee36dc2 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-20_08:2020-04-20, 2020-04-20 signatures=0 Received: from [17.234.48.87] (unknown [17.234.48.87]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0Q9300HCGUJTM100@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Mon, 20 Apr 2020 14:04:43 -0700 (PDT) From: Tommy Pauly Message-id: <91AA234A-7375-4A04-872B-5B1AB3FA79FF@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_6DEFFDD1-0794-4C04-B8DE-E0CFA28BF6D8" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Date: Mon, 20 Apr 2020 14:04:41 -0700 In-reply-to: <6.2.5.6.2.20200420124357.12e4b868@elandnews.com> Cc: architecture-discuss@ietf.org To: S Moonesamy References: <303F494F-F06C-4E6A-99E5-089798EB56DB@apple.com> <6.2.5.6.2.20200420124357.12e4b868@elandnews.com> X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-20_08:2020-04-20, 2020-04-20 signatures=0 Archived-At: Subject: Re: [arch-d] Updates on IAB mailing lists 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, 20 Apr 2020 21:05:04 -0000 --Apple-Mail=_6DEFFDD1-0794-4C04-B8DE-E0CFA28BF6D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi S. Moonesamy, Thanks for your response! > On Apr 20, 2020, at 1:54 PM, S Moonesamy wrote: >=20 > Dear Mr Pauly, > At 09:08 AM 20-04-2020, Tommy Pauly wrote: >> We'd like to share a few updates about IAB mailing lists, and solicit = the community's feedback on some new text. >>=20 >> First, Tommy Pauly will be joining Stephen Farrell on the (existing, = but rarely employed) sergeants-at-arms team to help moderate the list. >>=20 >> Second, we'd like to clarify the sergeants-at-arms roles for the = lists. The current description on https://www.iab.org/iab-mailing-lists/ = does mention that the lists use a sergeant-at-arms model for moderation, = but does not describe what this role entails. It also does not specify = if this role applies to all of the lists on the page, such as program = lists. >>=20 >> We're proposing adding the following text to = https://www.iab.org/iab-mailing-lists/, largely based on the IETF list = SAA. We'd love to hear feedback on this approach! >=20 > I would like to thank the Internet Architecture Board for requesting = feedback about the architecture-discuss@ietf.org mailing list. Given = the domain name in that email address, isn't it a mailing list which = falls under the Internet Engineering Task Force? This mailing list is, in fact, an IAB-sponsored activity. The email = address is confusing for historical reasons. = architecture-discuss@iab.org is an = alias for the same list. >=20 > There was an announcement about the moderators some time ago. I don't = recall seeing them described as "sergeant-at-arms". I looked up the = term and I found this: "in feudal England a sergeant at arms was an = armed officer of a lord and was often one of a special body required to = be in immediate attendance on the king's person, to arrest traitors and = other offenders". Given some recent interventions on the ietf@ mailing = list, I would not suggest the sergeant at arms as a model to follow. The SAA role for the mailing list already existed, and the goal of this = text is to clarify what the role is on the public website. It is = primarily a way to moderate spam and ensure that a mailing list is a = respectful and productive space. If there are particular suggestions for = the content and scope of the role in terms of the textual description, = I=E2=80=99d be happy to hear them. Thanks, Tommy >=20 > Regards, > S. Moonesamy=20 --Apple-Mail=_6DEFFDD1-0794-4C04-B8DE-E0CFA28BF6D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi S. Moonesamy,

Thanks for your response!

On Apr = 20, 2020, at 1:54 PM, S Moonesamy <sm+ietf@elandsys.com> wrote:

Dear = Mr Pauly,
At 09:08 AM 20-04-2020, Tommy Pauly wrote:
We'd like to share a few = updates about IAB mailing lists, and solicit the community's feedback on = some new text.

First, Tommy Pauly will be = joining Stephen Farrell on the (existing, but rarely employed) = sergeants-at-arms team to help moderate the list.

Second, we'd like to clarify the sergeants-at-arms roles for = the lists. The current description on https://www.iab.org/iab-mailing-lists/ does mention that = the lists use a sergeant-at-arms model for moderation, but does not = describe what this role entails. It also does not specify if this role = applies to all of the lists on the page, such as program lists.

We're proposing adding the following text to = https://www.iab.org/iab-mailing-lists/, largely based on = the IETF list SAA. We'd love to hear feedback on this approach!

I would like to thank the = Internet Architecture Board for requesting feedback about the architecture-discuss@ietf.org mailing list.  Given = the domain name in that email address, isn't it a mailing list which = falls under the Internet Engineering Task Force?

This = mailing list is, in fact, an IAB-sponsored activity. The email address = is confusing for historical reasons. architecture-discuss@iab.org is an alias for the = same list.


There was an = announcement about the moderators some time ago.  I don't recall = seeing them  described as "sergeant-at-arms".  I looked up the = term and I found this: "in feudal England a sergeant at arms was an = armed officer of a lord and was often one of a special body required to = be in immediate attendance on the king's person, to arrest traitors and = other offenders".  Given some recent interventions on the ietf@ = mailing list, I would not suggest the sergeant at arms as a model to = follow.

The SAA role for the mailing list already existed, and = the goal of this text is to clarify what the role is on the public = website. It is primarily a way to moderate spam and ensure that a = mailing list is a respectful and productive space. If there are = particular suggestions for the content and scope of the role in terms of = the textual description, I=E2=80=99d be happy to hear = them.

Thanks,
Tommy

Regards,
S. Moonesamy

= --Apple-Mail=_6DEFFDD1-0794-4C04-B8DE-E0CFA28BF6D8-- From nobody Mon Apr 20 14:10:42 2020 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 B078A3A100D for ; Mon, 20 Apr 2020 14:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzIa8jZhRJME for ; Mon, 20 Apr 2020 14:10:39 -0700 (PDT) Received: from mail-pg1-x541.google.com (mail-pg1-x541.google.com [IPv6:2607:f8b0:4864:20::541]) (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 A52F03A1003 for ; Mon, 20 Apr 2020 14:10:39 -0700 (PDT) Received: by mail-pg1-x541.google.com with SMTP id t11so5707950pgg.2 for ; Mon, 20 Apr 2020 14:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=jM4R9R3cbeZ4fhKxZnoEt9OM2zyvMFc1JKFD71/9kSY=; b=PrNEUujl0M9kt/86vXy2nMKLXmypV8M+W195YdA0iQfJ1UkdJ7lWd27c5fXS6GzHNC 1ITFY+O2iDy/xL1pLHLxMwnt4cozNSjqparRfiL7/KWM+7UuOuSijlXnlpyuQRFyJOjt 7Z34k9YmLyIS61PJmtXmralEBkpUPMr+2hsw56FPcmWu3Xf8iilQd6sr2ZCppUlt7/ag 7LDdN+0fUuez1zYkrpecwkcKO8EHrVS+JgYwfVKuWy+7j77QIshnYtTUIhFIL0PmNTk/ uTRIhXFbf/D7TAwPe1Q7lu6z7wFd+HwR6+xLZMvvvhUl+ExiA/EmMJnzJJP4nHO+9kHD trIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jM4R9R3cbeZ4fhKxZnoEt9OM2zyvMFc1JKFD71/9kSY=; b=iHdB2Zi3d8eyvkf1fogluzqK79pTcupYCLzFwCIhdB69Ldype+AAzOfD1kvIuTAiyj RyK4yma6sny1eU8zaQfv/X5l/UWwsmsBSwXhIuPT558MR0M1ZJHLaeJAg5X1heQ578ZX 0mB0of1Tb7oLQwgs4ehI+z0hoOF2ZxQFpvBdjb3jcPyxzB9qSV9X100Rtu2eTXVR02uk OF43N60CqsVXSvOjuXgAAkundw0qWdXweWoG4gVwfE5kDbvkkZqSfIK5K05dS6yMgExy yu8LiaNJytQtrzv0v4TtzfiYOTQfcHRKgyaE6h8gvOq6K5Un8my6ISt+EuYjS+7SaV7M IACA== X-Gm-Message-State: AGi0PubbzLzo2ls0Eqb1tVZMXELD9dIBn+eBIe7I1wdDtJss2BZhr5gQ 5srw0wPIR36Q79J+rEAH9aO0w/WGz/A= X-Google-Smtp-Source: APiQypKzYBI7aO3hPILTEP0Hpro8ILN3ELG003RBe5gNKvjSvaUTTh6V2obHh1AM9YbgsTwydGbxVQ== X-Received: by 2002:aa7:8259:: with SMTP id e25mr18450582pfn.82.1587417038525; Mon, 20 Apr 2020 14:10:38 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id e7sm402540pfh.161.2020.04.20.14.10.36 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Apr 2020 14:10:37 -0700 (PDT) To: architecture-discuss@ietf.org References: <303F494F-F06C-4E6A-99E5-089798EB56DB@apple.com> From: Brian E Carpenter Message-ID: <3d509264-f9a5-0ed4-91de-c1a5e0155194@gmail.com> Date: Tue, 21 Apr 2020 09:10:34 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 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] Updates on IAB mailing lists 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, 20 Apr 2020 21:10:42 -0000 On 21-Apr-20 07:34, Mary Barnes wrote: > Just to be clear, my point is that architecture-discuss was not intended to be an IAB discussion list any more than IETF discussion list is scoped to IESG discussion. Not quite accurate - see below. Especially "This is an IAB-sponsored activity...". Brian -------- Forwarded Message -------- Subject: New architecture-discuss mailing list forum Date: Mon, 17 Oct 2005 16:00:54 -0400 From: Leslie Daigle To: IETF Announcement list CC: iab@ietf.org, iesg@ietf.org, architecture-discuss@ietf.org A new mailing list has been created to provide a forum for general discussion of Internet architectural issues: architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss The architecture-discuss list serves as a technical discussion forum for all members of the IETF community that are interested in larger architectural issues. It is meant to be an open discussion forum for all long and/or wide range architectural concerns related to the Internet Architecture. In particular, it may be used to discuss and bring forth different points of view on controversial architectural questions. Discussions that drill down and dwell on specifics of individual protocols or technologies are to be discouraged, redirected to appropriate other fora, or re-cast to discussions of broader implications for Internet architecture. This is an IAB-sponsored activity, but IAB members will be participating as individuals and not representatives of the IAB. As such, postings to list must not be considered as IAB opinion, and must not be quoted as such. Indeed, it is expected that IAB members will disagree with each other, at least occasionally, just like the any part of this community. :-) Note that questions asking for an official IAB opinion, issues requiring immediate action (by anyone), issues related to the way the IETF operates, do not belong on this list. Issues pertaining to IAB business should still be directed to iab@iab.org . Leslie Daigle, for the IAB. ------------------------ [Some examples of potential topics for discussion, provided by Pekka Nikkander] 1. Mobility and multi-homing The IETF currently hosts a bunch of working groups focusing on various aspects of mobility and multi homing. At the Internet Area, there are five WGs and a couple of almost-WGs charted for standards track work: MIP4, MIP6, NEMO, SHIM6, MONAMI6, and NETLMM. In addition to those, there are experimental approaches, such as HIP, and optimisations, such as MIPSHOP and MOBOPTS. Outside of the Internet area, MOBIKE is focusing on mobility and multi-homing for IPsec and SCTP and DCCP folks have had their mobility and multi- homing discussions. The wider research community is full of various proposals, including overlay approaches (such as i3) and underlay approaches (such as using MPLS tunnels to implement host routes). Given this multitude of work and even partially overlapping standards track solutions, what would be the right way or right ways forward? Could we design a way towards converging solutions? How do we ensure robustness of solutions if we attempt to deploy multiple solutions at the same time; for example, SHIM6 + Mobile IPv6 + SHIM6? How do more unified solutions, like using CGA-based mobility with SHIM6 contrast to this? What about using HIP with routable IP addresses instead of Host Identity Tags (HITs) as Upper Layer Identifiers? Going a little bit furthermore, what are the architectural impacts of doing mobility and multi-homing at the IP layer vs. other layers? 2. IP virtualisation In the recent discussion w.r.t. tunnelling at the Internet Area list, a clear need for virtualisation came up. While tunnelling with clear implementation-level virtualisation boundaries is clearly one viable way to implement virtual IP networks on the top of the "real" IP infrastructure, this issue seems to warrant some deeper digging. Tunnelling has well known drawbacks, and we may want to ask what would be the alternatives. In order to understand alternatives, if any, we need to understand better the requirements behind IP virtualisation, or what people *really* want to achieve with it. Is it merely ease of configuration, or reduced operational costs? If so, could there be other architectural ways of achieving the same ease or perhaps even larger capital and operational savings? Some people have been promoting adding "realms" as a first class service to the base IP. Would that provide an alternative solution? While the mobility and multi-homing discussion seems to more circle around evaluating existing proposals and trying to navigate towards more unified solutions, here we seem to lack genuine alternatives and deep understanding of the real problem domain. 3. Overall open architectural issues Some IAB members have been collecting open architectural issues for a while, with the intention of bringing up an up to date collection of information at a later date, probably in a form of a WikiPedia-like web site. This work is going on, and we'd like to get as much information as possible from the wider community. Hence, suggestions on what are the more pressing longer-term open issues are very welcome. To given an idea of the current issues so far identified, here is a partial list. The list doesn't say much without explanation, but it may give an idea of the type of issues we are looking at. End-to-end connectivity ======================= The original value of the Internet, the ability to connect to any host with any protocol, has eroded away during the last decade. While it is impossible to get back to the original mode of operation, largely due to security reasons, some form of better-than-today end- to-end connectivity would be very valuable. o Living with NATs, filters, and firewalls o Introducing identity realms or domains o Evolving the application interface (API) End-user experience =================== o Transparent security o Zero Configuration and Service Discovery Balancing Accessibility, Security, and Privacy ============================================== o System for plausible sender identity for received packets o Secure self-configuration o Integrating security across the stack o Dealing with bad traffic _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From nobody Mon Apr 20 14:22:18 2020 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 3E3E43A1056; Mon, 20 Apr 2020 14:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.496 X-Spam-Level: X-Spam-Status: No, score=0.496 tagged_above=-999 required=5 tests=[DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.275, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 9svJ_G0QdeQ7; Mon, 20 Apr 2020 14:22:03 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 991503A1052; Mon, 20 Apr 2020 14:22:03 -0700 (PDT) Received: from [172.17.121.48] (cpe-70-122-148-25.tx.res.rr.com [70.122.148.25]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 03KLLgP6035497 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 20 Apr 2020 16:21:44 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1587417704; bh=GULiorrDyhTiS3T7cW+zg/Ke6bevkhFUYHDmJPLbyYo=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=ULPMlXmtdunDqlCfzWxhKHe4NasDoeqP3KFOpBNPEO/UJIiA97lKXnchrCEvHLOl0 30acfBLGcpmEIVf17LjdfteybWcs36hloDj7IMamA3dQnxiTCIQl6guvrQh2dkwUjc f2QFv4+9VtBR1jodZw4g+Tmm8tTZ/X1zPmbVtMUE= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-148-25.tx.res.rr.com [70.122.148.25] claimed to be [172.17.121.48] To: Tommy Pauly , Toerless Eckert Cc: "architecture-discuss@ietf.org" , iesg@ietf.org, ietf@ietf.org References: <20200420184456.GG5351@faui48f.informatik.uni-erlangen.de> From: Adam Roach Message-ID: <0d0435d4-7b13-da18-4cea-9b3611e20cad@nostrum.com> Date: Mon, 20 Apr 2020 16:21:36 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [arch-d] iesg: Re: Updates on IAB mailing lists 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, 20 Apr 2020 21:22:06 -0000 On 4/20/2020 4:00 PM, Tommy Pauly wrote: > Indeed, the discussion on the list is to be encouraged! The goal of clarifying the policy is to ensure that, as this list is an IAB-sponsored activity, that the community does have a productive and open space to discuss. The SAA’s role is to handle spam or abuse only. For avoidance of doubt: if you're referring to the Sergeants-at-Arms appointed by the IETF chair to assist in keeping the ietf@ietf.org mailing list within its charter (as defined by RFC 3005), they have no responsibilities or authority on mailing lists other than ietf@ietf.org. Other mailing lists have their own individual owners (typically, WG chairs, area directors, directorate secretaries, or similar) that are responsible for filling equivalent roles on their mailing lists (either directly or by delegation). For most lists, you can reach these owners by sending mail to -owner@ietf.org (e.g., architecture-discuss-owner@ietf.org). /a From nobody Mon Apr 20 14:27:23 2020 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 1D1A33A1067 for ; Mon, 20 Apr 2020 14:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.203 X-Spam-Level: X-Spam-Status: No, score=0.203 tagged_above=-999 required=5 tests=[DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 a4U42F5vDqxV for ; Mon, 20 Apr 2020 14:27:16 -0700 (PDT) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEDE3A1063 for ; Mon, 20 Apr 2020 14:27:16 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.37.130]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 03KLR1Z3024919 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Apr 2020 14:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1587418033; x=1587504433; i=@elandsys.com; bh=O8Phn99+eDqBjEGIWppx4JrpAhqu671vHfigwa2V+Aw=; h=Date:To:From:Subject:In-Reply-To:References; b=2TXkkJFNg10b1/mwIgJeyKsO1MWs6epaP15qxPA8+weTal3t5CfWSyKKTdVAndKnX 4jvHn7kZgRH8+cM8vFUX8nwPhLSHqP1msZ9ijDWSbUhBwoyUFGO3m3iyUI1YR524HY BB8HaSq2S6+0wWTa1ZdrSBrawVtCJalX9fgs1xM4= Message-Id: <6.2.5.6.2.20200420141040.0e5895f0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 20 Apr 2020 14:26:49 -0700 To: Tommy Pauly , architecture-discuss@ietf.org From: S Moonesamy In-Reply-To: <91AA234A-7375-4A04-872B-5B1AB3FA79FF@apple.com> References: <303F494F-F06C-4E6A-99E5-089798EB56DB@apple.com> <6.2.5.6.2.20200420124357.12e4b868@elandnews.com> <91AA234A-7375-4A04-872B-5B1AB3FA79FF@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] Updates on IAB mailing lists 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, 20 Apr 2020 21:27:21 -0000 Dear Mr Pauly, At 02:04 PM 20-04-2020, Tommy Pauly wrote: >This mailing list is, in fact, an IAB-sponsored activity. The email >address is confusing for historical reasons. >architecture-discuss@iab.org is an alias for the same list. Ok. >The SAA role for the mailing list already existed, and the goal of >this text is to clarify what the role is on the public website. It >is primarily a way to moderate spam and ensure that a mailing list >is a respectful and productive space. If there are particular >suggestions for the content and scope of the role in terms of the >textual description, I'd be happy to hear them. Most of the mailing list I am subscribed to have a moderator. The practice is for the person to curtail spam and see that mailing list discussions do not go out of hand. If I had a suggestion to make, it would be to figure out a description which the IAB members consider as appropriate for this mailing list. It may happen that you take a decision which I disagree with. It does not mean that you are wrong or that you are doing a bad job. That is the nature of things. Regards, S. Moonesamy From nobody Mon Apr 20 14:39:18 2020 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 024F73A10C4; Mon, 20 Apr 2020 14:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.652, 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 LDJBHjzkhham; Mon, 20 Apr 2020 14:39:11 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F4893A10C2; Mon, 20 Apr 2020 14:39:11 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id E5F3C548048; Mon, 20 Apr 2020 23:39:05 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id DD0F9440041; Mon, 20 Apr 2020 23:39:05 +0200 (CEST) Date: Mon, 20 Apr 2020 23:39:05 +0200 From: Toerless Eckert To: Melinda Shore Cc: Mary Barnes , Tommy Pauly , The IESG , IETF-Discussion list , "architecture-discuss@ietf.org" Message-ID: <20200420213905.GA19381@faui48f.informatik.uni-erlangen.de> References: <20200420184456.GG5351@faui48f.informatik.uni-erlangen.de> <93a7ae7f-c2bc-a009-baa9-8671de5ee384@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <93a7ae7f-c2bc-a009-baa9-8671de5ee384@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] iesg: Re: Updates on IAB mailing lists 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, 20 Apr 2020 21:39:13 -0000 Melinda, The current description of the list is very clear and very useful, and well defines whats in and whats out of scope. It should not be changed or amended by new rules as proposed by the current IAB. Whoever sponsors the list, IAB or else, if it is an @ietf.org mailing list, it should follow what we have come to expect to be appropriate for IETF. When the IAB wants to have more constrained mailing lists, which may make perfect sense for other lists, they can have them under @iab.org. architecture-discuss@ietf.org was specifically set up there to indicate its an IETF community mailing list thats also explicitly what the description says. The IETF community does not operate under IAB rules. Cheers Toerless On Mon, Apr 20, 2020 at 11:52:00AM -0800, Melinda Shore wrote: > On 4/20/20 11:49 AM, Mary Barnes wrote: > > Personally, I think it's a handy list to have > > for purely technical discussions as opposed to all the non-technical > > discussions on the main IETF discussion list.  > > Right, but I think it's clear that it's not every technical > discussion, which circles back around to Toerless's argument. > > Melinda -- --- tte@cs.fau.de From nobody Mon Apr 20 14:54:20 2020 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 B15843A110B; Mon, 20 Apr 2020 14:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 S_i5rrA5Lj0p; Mon, 20 Apr 2020 14:54:17 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 20D243A110C; Mon, 20 Apr 2020 14:54:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 495gT46QDNz1p3YZ; Mon, 20 Apr 2020 14:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1587419656; bh=4FSIWOXKqvU4BYBzNlu6Jmi3XWKQ0EfOQ8Yg2junXk4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=rPpPa75zdkBRIT0uzJRb92aUJ4QEyTY0iGuap+DGzOipLW+VVs/aqiUR9/6Qhao1r AHebnZwTYWIAorzUEoNhgA7S6tsKz+htVhHIkdLmmLLzhuBQihayId28B9VMDCHjR3 0F72pK9ikhzLH7ndO60pc21LMCgzdz7h8LRociZ4= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 495gT42LVbz1nsfH; Mon, 20 Apr 2020 14:54:16 -0700 (PDT) To: Mary Barnes Cc: "architecture-discuss@ietf.org" , IETF-Discussion list References: <20200420184456.GG5351@faui48f.informatik.uni-erlangen.de> <93a7ae7f-c2bc-a009-baa9-8671de5ee384@gmail.com> From: "Joel M. Halpern" Message-ID: <1b3a6b47-a4b4-1527-0adc-77d4421d8947@joelhalpern.com> Date: Mon, 20 Apr 2020 17:54:12 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [arch-d] iesg: Re: Updates on IAB mailing lists 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, 20 Apr 2020 21:54:19 -0000 My read has been that architecture-discuss was for Internet Architecture topics of relevance to the IAB or IETF. That does not, in my book, include random musing about research projects that may or may not lead to something in some ill-defined time in the future. And even if you disagree with the specific example, it does mean that there are clearly things which are off-topic for architecture-discuss. Which means that someone needs to be authorized to deal with such things when they become problematic. Yours, Joel On 4/20/2020 4:13 PM, Mary Barnes wrote: > Thanks - I hadn't followed Toeless' thread where he encountered the > problem that triggered his email. > > Just to make sure I understand - the architecture-discuss list is > intended only for topics that the IAB deems of interest specifically to > the IAB and NOT a general community list to discuss things related to > the Internet architecture.  Is that correct?   If so, then it does seem > we need a list where folks can have discussion of technical topics that > aren't necessarily related to work IAB is doing.   I know we've > discussed in the past that the IETF discussion list is most suitable for > those discussions but I think most would agree that the list has a whole > lot more discussion of how we do non-technical things than technical (I > would guess 90/10 for the most part).   I think many don't pay near the > attention to the list that they might if it were technical discussions - > for example, I subscribe to that list using my general email that I use > for not real work. > > So, one question I would have then, is whether it's thus only > appropriate for someone in the community to post to architecture-discuss > if they are asking specific questions on current IAB activities and > documents? > > Regards, > Mary. > > On Mon, Apr 20, 2020 at 2:52 PM Melinda Shore > wrote: > > On 4/20/20 11:49 AM, Mary Barnes wrote: > > Personally, I think it's a handy list to have > > for purely technical discussions as opposed to all the non-technical > > discussions on the main IETF discussion list. > > Right, but I think it's clear that it's not every technical > discussion, which circles back around to Toerless's argument. > > Melinda > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > From nobody Mon Apr 20 15:19:18 2020 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 43F7E3A1193 for ; Mon, 20 Apr 2020 15:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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 p-h9qYN3Y3Bv for ; Mon, 20 Apr 2020 15:19:04 -0700 (PDT) Received: from mail-pj1-x1043.google.com (mail-pj1-x1043.google.com [IPv6:2607:f8b0:4864:20::1043]) (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 EEE943A118F for ; Mon, 20 Apr 2020 15:19:03 -0700 (PDT) Received: by mail-pj1-x1043.google.com with SMTP id a7so486061pju.2 for ; Mon, 20 Apr 2020 15:19:03 -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=JMJxBcc0z50QQD05VxviOlTkbGQ44Xb2nT7PkMIFWVU=; b=bA20VogW5QH9lYuyB8T0QbAtYbqdarPdn5xJLy6oaGO/P6ekm3O8d1SlRqaOdZ6MFd bP1FI8myJb5kNnDqGeis44ntOtzqLGmhJUcOSdAMV/ITWaXTOr6HbeOtcaRZ7sXFcqcY cubO8CT04/pZJQQ6O2XELaSjSyesvUCtNPE9ap/k24uh6yH9jsEpi6SWPwyKPberSUOg b1XQ6cDT9me/oibZG5olgCDAbX8i8L4LPHSl5iA6c8SvB0iDpXe9ovGmpt+skKSpKgro baQH+CvX7bfmzHKdMqViPc7II9E/wviJttUUtMiZ3OABZHUSUIgGMBvRW1F05KJG2hps sT9Q== 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=JMJxBcc0z50QQD05VxviOlTkbGQ44Xb2nT7PkMIFWVU=; b=nst74TfhGsm1ZQno007WNV2zcv2sfxzTFNQerJyZbYvM+4xrkuGJXqBNGnxo3kJCcz BY73bMXdK5fJp+mfAYduyPMRcYwSY8tJ+U8VE4N+Jyb0JcdBxCeMWYFlZnRHtOKqlw+A EM9COgmVBxV+kmp4Wgn/4ps111To2aRQR7jmJ9mCgg6ZfjtYbA4w9aCQQYYI8cgTYSEP Njp5/PjSLuWZFJypGllcmkSGO7AZpXJWfoAFK6O/iVno6cZhOlKr0TNn7QG8HhyCYyKF dyX+NFlqsXUudztvfnmUJtbmRDWOPofPoLhitJPQXDHYVDvn3BDo0VE+fJs6bMGK4rfU fv+w== X-Gm-Message-State: AGi0PuYk1PvCB/KhY3OO/MiUL95nr69T9PZ1bMtuIOgzLjVx/IYqy2s8 yeHSetBTKRGghD/heiF+S6IRedIjNKqjEA3pyys= X-Google-Smtp-Source: APiQypIBYV9roH7fvm34hpmOpY32viN3dTPJaYiZp9E6xLlRX3aMqTitpGUW92mLj3XcCfWV4RGB1D2glCVAaQH2zvw= X-Received: by 2002:a17:90a:a602:: with SMTP id c2mr1805575pjq.135.1587421143365; Mon, 20 Apr 2020 15:19:03 -0700 (PDT) MIME-Version: 1.0 References: <303F494F-F06C-4E6A-99E5-089798EB56DB@apple.com> <3d509264-f9a5-0ed4-91de-c1a5e0155194@gmail.com> In-Reply-To: <3d509264-f9a5-0ed4-91de-c1a5e0155194@gmail.com> From: Mary Barnes Date: Mon, 20 Apr 2020 17:18:51 -0500 Message-ID: To: Brian E Carpenter Cc: architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="0000000000005bfb2e05a3c0492a" Archived-At: Subject: Re: [arch-d] Updates on IAB mailing lists 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, 20 Apr 2020 22:19:14 -0000 --0000000000005bfb2e05a3c0492a Content-Type: text/plain; charset="UTF-8" So, that predates my tenure on the IAB by about 6 years, so we probably had rolled over a lot of the IAB at that time by then (it looks like Dave Thaler would have been the only one left from that era). It would have been more clear had the last paragraph been included as part of the list description: And, maybe it should be added now. Right now this is the list description, which says nothing specific to the IAB: The architecture-discuss list serves as a technical discussion forum for all members of the IETF community that are interested in larger architectural issues. It is meant to be an open discussion forum for all long and/or wide range architectural concerns related to the Internet Architecture. In particular, it may be used to discuss and bring forth different points of view on controversial architectural questions. Discussions that drill down and dwell on specifics of individual protocols or technologies are to be discouraged, redirected to appropriate other fora, or re-cast to discussions of broader implications for Internet architecture. Regards, Mary. On Mon, Apr 20, 2020 at 4:11 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 21-Apr-20 07:34, Mary Barnes wrote: > > Just to be clear, my point is that architecture-discuss was not intended > to be an IAB discussion list any more than IETF discussion list is scoped > to IESG discussion. > > Not quite accurate - see below. Especially "This is an IAB-sponsored > activity...". > > Brian > > -------- Forwarded Message -------- > Subject: New architecture-discuss mailing list forum > Date: Mon, 17 Oct 2005 16:00:54 -0400 > From: Leslie Daigle > To: IETF Announcement list > CC: iab@ietf.org, iesg@ietf.org, architecture-discuss@ietf.org > > A new mailing list has been created to provide a forum for general > discussion of Internet architectural issues: > > architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > > The architecture-discuss list serves as a technical discussion forum for > all members of the IETF community that are interested in larger > architectural issues. It is meant to be an open discussion forum for > all long and/or wide range architectural concerns related to the > Internet Architecture. In particular, it may be used to discuss and > bring forth different points of view on controversial architectural > questions. Discussions that drill down and dwell on specifics of > individual protocols or technologies are to be discouraged, redirected > to appropriate other fora, or re-cast to discussions of broader > implications for Internet architecture. > > This is an IAB-sponsored activity, but IAB members will be > participating as individuals and not representatives of the IAB. As > such, postings to list must not be considered as IAB opinion, and must > not be quoted as such. Indeed, it is expected that IAB members will > disagree with each other, at least occasionally, just like the any > part of this community. :-) Note that questions asking for an official > IAB opinion, issues requiring immediate action (by anyone), issues > related to the way the IETF operates, do not belong on this list. > Issues pertaining to IAB business should still be directed to > iab@iab.org . > > > Leslie Daigle, > for the IAB. > > ------------------------ > > [Some examples of potential topics for discussion, provided by Pekka > Nikkander] > > 1. Mobility and multi-homing > > The IETF currently hosts a bunch of working groups focusing on various > aspects > of mobility and multi homing. At the Internet Area, there are five WGs > and a > couple of almost-WGs charted for standards track work: MIP4, MIP6, NEMO, > SHIM6, > MONAMI6, and NETLMM. In addition to those, there are experimental > approaches, > such as HIP, and optimisations, such as MIPSHOP and MOBOPTS. Outside of > the > Internet area, MOBIKE is focusing on mobility and multi-homing for IPsec > and > SCTP and DCCP folks have had their mobility and multi- homing > discussions. The > wider research community is full of various proposals, including overlay > approaches (such as i3) and underlay approaches (such as using MPLS > tunnels to > implement host routes). > > Given this multitude of work and even partially overlapping standards > track > solutions, what would be the right way or right ways forward? Could we > design > a way towards converging solutions? How do we ensure robustness of > solutions > if we attempt to deploy multiple solutions at the same time; for example, > SHIM6 > + Mobile IPv6 + SHIM6? How do more unified solutions, like using > CGA-based > mobility with SHIM6 contrast to this? What about using HIP with routable > IP > addresses instead of Host Identity Tags (HITs) as Upper Layer > Identifiers? > Going a little bit furthermore, what are the architectural impacts of > doing > mobility and multi-homing at the IP layer vs. other layers? > > 2. IP virtualisation > > In the recent discussion w.r.t. tunnelling at the Internet Area list, a > clear > need for virtualisation came up. While tunnelling with clear > implementation-level virtualisation boundaries is clearly one viable way > to > implement virtual IP networks on the top of the "real" IP infrastructure, > this > issue seems to warrant some deeper digging. Tunnelling has well known > drawbacks, and we may want to ask what would be the alternatives. In > order to > understand alternatives, if any, we need to understand better the > requirements > behind IP virtualisation, or what people *really* want to achieve with > it. Is > it merely ease of configuration, or reduced operational costs? If so, > could > there be other architectural ways of achieving the same ease or perhaps > even > larger capital and operational savings? Some people have been promoting > adding > "realms" as a first class service to the base IP. Would that provide an > alternative solution? > > While the mobility and multi-homing discussion seems to more circle around > evaluating existing proposals and trying to navigate towards more unified > solutions, here we seem to lack genuine alternatives and deep > understanding of > the real problem domain. > > 3. Overall open architectural issues > > Some IAB members have been collecting open architectural issues for a > while, > with the intention of bringing up an up to date collection of information > at a > later date, probably in a form of a WikiPedia-like web site. This work is > going on, and we'd like to get as much information as possible from the > wider > community. Hence, suggestions on what are the more pressing longer-term > open > issues are very welcome. To given an idea of the current issues so far > identified, here is a partial list. The list doesn't say much without > explanation, but it may give an idea of the type of issues we are looking > at. > > End-to-end connectivity > ======================= > > The original value of the Internet, the ability to connect to any host > with > any protocol, has eroded away during the last decade. While it is > impossible to > get back to the original mode of operation, largely due to security > reasons, > some form of better-than-today end- to-end connectivity would be very > valuable. > > o Living with NATs, filters, and firewalls > o Introducing identity realms or domains > o Evolving the application interface (API) > > End-user experience > =================== > o Transparent security > o Zero Configuration and Service Discovery > > Balancing Accessibility, Security, and Privacy > ============================================== > o System for plausible sender identity for received packets > o Secure self-configuration > o Integrating security across the stack > o Dealing with bad traffic > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --0000000000005bfb2e05a3c0492a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So, that predates my tenure on the IAB by= about 6 years, so we probably had rolled over a lot of the IAB at that tim= e by then (it looks like Dave Thaler would have been the only one left from= that era).=C2=A0 =C2=A0It would have been more clear had the last paragrap= h been included as part of the list description:

And, ma= ybe it should be added now.=C2=A0 Right now this is the list description, w= hich says nothing specific to the IAB:=C2=A0
The architecture-discus= s list serves as a technical discussion forum for all members of the IETF c= ommunity that are interested in larger architectural issues. It is meant to= be an open discussion forum for all long and/or wide range architectural c= oncerns related to the Internet Architecture. In particular, it may be used= to discuss and bring forth different points of view on controversial archi= tectural questions. Discussions that drill down and dwell on specifics of i= ndividual protocols or technologies are to be discouraged, redirected to ap= propriate other fora, or re-cast to discussions of broader implications for= Internet architecture.

Regards,
<= div>Mary.

On Mon, Apr 20, 2020 at 4:11 PM Brian E Carpenter <brian.e.carpenter@gmail.com&g= t; wrote:
On 21-= Apr-20 07:34, Mary Barnes wrote:
> Just to be clear, my point is that architecture-discuss was not intend= ed to be an IAB discussion list any more than IETF discussion list is scope= d to IESG discussion.

Not quite accurate - see below. Especially "This is an IAB-sponsored a= ctivity...".

=C2=A0 =C2=A0Brian

-------- Forwarded Message --------
Subject: New architecture-discuss mailing list forum
Date: Mon, 17 Oct 2005 16:00:54 -0400
From: Leslie Daigle <leslie@thinkingcat.com>
To: IETF Announcement list <ietf-announce@ietf.org>
CC: iab@ietf.org, iesg@ietf.org, architecture-di= scuss@ietf.org

A new mailing list has been created to provide a forum for general
discussion of Internet architectural issues:

=C2=A0 =C2=A0architecture-discuss@ietf.org
=C2=A0 =C2=A0https://www1.ietf.org/mailma= n/listinfo/architecture-discuss

The architecture-discuss list serves as a technical discussion forum for all members of the IETF community that are interested in larger
architectural issues. It is meant to be an open discussion forum for
all long and/or wide range architectural concerns related to the
Internet Architecture. In particular, it may be used to discuss and
bring forth different points of view on controversial architectural
questions. Discussions that drill down and dwell on specifics of
individual protocols or technologies are to be discouraged, redirected
to appropriate other fora, or re-cast to discussions of broader
implications for Internet architecture.

This is an IAB-sponsored activity, but IAB members will be
participating as individuals and not representatives of the IAB. As
such, postings to list must not be considered as IAB opinion, and must
not be quoted as such. Indeed, it is expected that IAB members will
disagree with each other, at least occasionally, just like the any
part of this community.=C2=A0 :-)=C2=A0 Note that questions asking for an o= fficial
IAB opinion, issues requiring immediate action (by anyone), issues
related to the way the IETF operates, do not belong on this list.
Issues pertaining to IAB business should still be directed to
iab@iab.org .


Leslie Daigle,
for the IAB.

------------------------

[Some examples of potential topics for discussion, provided by Pekka Nikkan= der]

1. Mobility and multi-homing

The IETF currently hosts a bunch of working groups focusing on=C2=A0 variou= s aspects
of mobility and multi homing.=C2=A0 At the Internet Area,=C2=A0 there are f= ive WGs and a
couple of almost-WGs charted for standards=C2=A0 track work: MIP4, MIP6, NE= MO, SHIM6,
MONAMI6, and NETLMM.=C2=A0 In=C2=A0 addition to those, there are experiment= al approaches,
such as HIP,=C2=A0 and optimisations, such as MIPSHOP and MOBOPTS.=C2=A0 Ou= tside of the
Internet area, MOBIKE is focusing on mobility and multi-homing for=C2=A0 IP= sec and
SCTP and DCCP folks have had their mobility and multi- homing discussions.= =C2=A0 The
wider research community is full of various=C2=A0 proposals, including over= lay
approaches (such as i3) and underlay=C2=A0 approaches (such as using MPLS t= unnels to
implement host routes).

Given this multitude of work and even partially overlapping standards=C2=A0= track
solutions, what would be the right way or right ways forward?=C2=A0 =C2=A0C= ould we design
a way towards converging solutions?=C2=A0 How do we ensure=C2=A0 robustness= of solutions
if we attempt to deploy multiple solutions at=C2=A0 the same time; for exam= ple, SHIM6
+ Mobile IPv6 + SHIM6?=C2=A0 How do more=C2=A0 unified solutions, like usin= g CGA-based
mobility with SHIM6 contrast=C2=A0 to this?=C2=A0 What about using HIP with= routable IP
addresses instead of=C2=A0 Host Identity Tags (HITs) as Upper Layer Identif= iers?
Going a little=C2=A0 bit furthermore, what are the architectural impacts of= doing
mobility=C2=A0 and multi-homing at the IP layer vs. other layers?

2. IP virtualisation

In the recent discussion w.r.t. tunnelling at the Internet Area list,=C2=A0= a clear
need for virtualisation came up.=C2=A0 While tunnelling with clear
implementation-level virtualisation boundaries is clearly one viable=C2=A0 = way to
implement virtual IP networks on the top of the "real" IP=C2=A0 i= nfrastructure, this
issue seems to warrant some deeper digging.=C2=A0 =C2=A0Tunnelling has well= known
drawbacks, and we may want to ask what=C2=A0 would be the alternatives.=C2= =A0 In order to
understand alternatives, if=C2=A0 any, we need to understand better the req= uirements
behind IP=C2=A0 virtualisation, or what people *really* want to achieve wit= h it.=C2=A0 Is
it merely ease of configuration, or reduced operational costs?=C2=A0 If=C2= =A0 so, could
there be other architectural ways of achieving the same=C2=A0 ease or perha= ps even
larger capital and operational savings?=C2=A0 Some=C2=A0 people have been p= romoting adding
"realms" as a first class service=C2=A0 to the base IP.=C2=A0 Wou= ld that provide an
alternative solution?

While the mobility and multi-homing discussion seems to more circle=C2=A0 a= round
evaluating existing proposals and trying to navigate towards=C2=A0 more uni= fied
solutions, here we seem to lack genuine alternatives and=C2=A0 deep underst= anding of
the real problem domain.

3. Overall open architectural issues

Some IAB members have been collecting open architectural issues for a=C2=A0= while,
with the intention of bringing up an up to date collection of=C2=A0 informa= tion at a
later date, probably in a form of a WikiPedia-like=C2=A0 web site.=C2=A0 Th= is work is
going on, and we'd like to get as much=C2=A0 information as possible fr= om the wider
community.=C2=A0 Hence, suggestions=C2=A0 on what are the more pressing lon= ger-term open
issues are very=C2=A0 welcome.=C2=A0 To given an idea of the current issues= so far
identified,=C2=A0 here is a partial list.=C2=A0 The list doesn't say mu= ch without
explanation, but it may give an idea of the type of issues we are=C2=A0 loo= king at.

End-to-end connectivity
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The original value of the Internet, the ability to connect to any=C2=A0 hos= t with
any protocol, has eroded away during the last decade. While=C2=A0 it is imp= ossible to
get back to the original mode of operation,=C2=A0 largely due to security r= easons,
some form of better-than-today end- to-end connectivity would be very valua= ble.

o Living with NATs, filters, and firewalls
o Introducing identity realms or domains
o Evolving the application interface (API)

End-user experience
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
o Transparent security
o Zero Configuration and Service Discovery

Balancing Accessibility, Security, and Privacy
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
o System for plausible sender identity for received packets
o Secure self-configuration
o Integrating security across the stack
o Dealing with bad traffic

_______________________________________________
IETF-Announce mailing list
IETF-Announce@i= etf.org
https://www1.ietf.org/mailman/listinfo/ietf-anno= unce

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--0000000000005bfb2e05a3c0492a-- From nobody Mon Apr 20 15:47:36 2020 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 130FD3A1208 for ; Mon, 20 Apr 2020 15:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 J7hcIcqGvcuU for ; Mon, 20 Apr 2020 15:47:33 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27013A1209 for ; Mon, 20 Apr 2020 15:47:32 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1jQfCF-000LW0-PQ; Mon, 20 Apr 2020 18:47:23 -0400 Date: Mon, 20 Apr 2020 18:47:18 -0400 From: John C Klensin To: Carsten Bormann , Mirja Kuehlewind cc: Tommy Pauly , architecture-discuss@ietf.org Message-ID: In-Reply-To: <18F278F7-0DFB-4902-8EB6-9EBBC3AF5640@tzi.org> References: <303F494F-F06C-4E6A-99E5-089798EB56DB@apple.com> <18F278F7-0DFB-4902-8EB6-9EBBC3AF5640@tzi.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [arch-d] Updates on IAB mailing lists 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, 20 Apr 2020 22:47:34 -0000 Carsten, I was just about to ask the same question and make the same point. As far as I know, there are no other lists in the IETF community available for discussions of, or raising questions about, general i18n questions. The closest approximation I know of is the ART Area i18n Directorate list and I don't believe that is an open list. If the IAB wants to be rid of this one --perhaps consistent with shutting the Program down-- then may I suggest they work with the IESG as needed to get a non-WG list, ideally of the same name, set up? thanks, john --On Monday, April 20, 2020 22:30 +0200 Carsten Bormann wrote: > On 2020-04-20, at 21:37, Mirja Kuehlewind > wrote: >>=20 >> The lists we propose to close didn't have any traffic for a >> long time and most of them have been used for discussion >> related to an IAB workshop or IAB program that doesn't >> exist anymore. >=20 > For i18n-discuss, there are occasional flares of activity, the > last significant one 2018-12. This is not "for a long > time". > These flares reached exactly the right set of people. > Is there a reasonable alternative that doesn't waste the > time of hundreds of others? >=20 >> We plan to confirm on each of the list that they can be >> closed. >=20 > OK, so I can shut up here now. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Mon Apr 20 16:13:38 2020 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 EE5493A1270; Mon, 20 Apr 2020 16:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=cs.tcd.ie 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 QKi3PzDcDl_n; Mon, 20 Apr 2020 16:13:35 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 621793A1272; Mon, 20 Apr 2020 16:13:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D0ED4BE2C; Tue, 21 Apr 2020 00:13:31 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZwhzJFOpgaf; Tue, 21 Apr 2020 00:13:30 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D8C98BDCF; Tue, 21 Apr 2020 00:13:29 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1587424410; bh=RF4EVKK2zyFVdyckeOtxyweeiOHqD9PhZ75irIMd4P8=; h=To:References:From:Subject:Date:In-Reply-To:From; b=nxjKLr8l4O6I1Sg90Fk2c2bNrn5u0dwdC69kOlVAIwIz8DVMzIKmqoz+gL/gdm8LX NRrUgzgGKkieLlXuP/c/3paSH8eSQ5Zmi9BkOjytQ5XYjuExKrU5KuG5EpiDghz1ww Ccq3OqkkAMiIpC4ufDe7u464fsNK90jyyyYQZ00Q= To: S Moonesamy , Tommy Pauly , architecture-discuss@ietf.org, IETF-Discussion References: <303F494F-F06C-4E6A-99E5-089798EB56DB@apple.com> <6.2.5.6.2.20200420124357.12e4b868@elandnews.com> <91AA234A-7375-4A04-872B-5B1AB3FA79FF@apple.com> <6.2.5.6.2.20200420141040.0e5895f0@elandnews.com> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <4aec4c10-92ec-8e34-399b-3d177e6fbf7d@cs.tcd.ie> Date: Tue, 21 Apr 2020 00:13:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <6.2.5.6.2.20200420141040.0e5895f0@elandnews.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="zfXEHnYk85qR5Kk5CKpztfvOK6z0RCPFn" Archived-At: Subject: Re: [arch-d] Updates on IAB mailing lists 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, 20 Apr 2020 23:13:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --zfXEHnYk85qR5Kk5CKpztfvOK6z0RCPFn Content-Type: multipart/mixed; boundary="GLMtsSqHif9kqrk3lADAxAqGRvEs0xa88"; protected-headers="v1" From: Stephen Farrell To: S Moonesamy , Tommy Pauly , architecture-discuss@ietf.org, IETF-Discussion Message-ID: <4aec4c10-92ec-8e34-399b-3d177e6fbf7d@cs.tcd.ie> Subject: Re: [arch-d] Updates on IAB mailing lists References: <303F494F-F06C-4E6A-99E5-089798EB56DB@apple.com> <6.2.5.6.2.20200420124357.12e4b868@elandnews.com> <91AA234A-7375-4A04-872B-5B1AB3FA79FF@apple.com> <6.2.5.6.2.20200420141040.0e5895f0@elandnews.com> In-Reply-To: <6.2.5.6.2.20200420141040.0e5895f0@elandnews.com> --GLMtsSqHif9kqrk3lADAxAqGRvEs0xa88 Content-Type: multipart/mixed; boundary="------------AB5CD21BBC24727922A1A612" Content-Language: en-US This is a multi-part message in MIME format. --------------AB5CD21BBC24727922A1A612 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi SM, all, On 20/04/2020 22:26, S Moonesamy wrote: >> The SAA role for the mailing list already existed, and the goal of=20 >> this text is to clarify what the role is on the public website. It >> is primarily a way to moderate spam and ensure that a mailing list >> is a respectful and productive space. If there are particular=20 >> suggestions for the content and scope of the role in terms of the=20 >> textual description, I'd be happy to hear them. >=20 > Most of the mailing list I am subscribed to have a moderator. Yeah, that term is more familiar to me too, whereas the SAA term seems to me like an oddity, both for ietf@ietf and in this case. I'd be happy to see suggested better terms but can also live with the oddity. To be honest, when I agreed to help look after the arch-d list, I didn't actually know the SAA term was how that was described - I only copped onto that a few weeks ago when I actually looked back at the text on the web page;-) And I haven't actually had to do anything acting in an SAA-role at all in the year since, which is good. (I did send less than a handful of mails for list management reasons but zero of a "do this or else" nature.) I'm nonetheless quite happy that Tommy is willing to help out in my inactivity! Other than that, I won't try answer all the mails, but there is no intent to change what's an ok topic for discussion, nor the scope of any list - this is all just bookkeeping, so at least from my POV, not a biggie. But if, as a result, we improve how the various lists are described, and people's understanding of that, that seems like an improvement. Lastly, wrt the other lists we might close, it was me who went over those and I only checked for recent traffic, so Tommy's mail doesn't mean "we want to shut down discussion" but rather "do we still need this?" If the i18n list is still periodically useful, then that's great and it'll not end up closed. (And to be open about it, one of the reasons we wanted to sort all this out was because as soon as we touched anything, we risked creating ambiguity as to whether the IAB might own this role for rfc-interest and rfced-future - and IIRC no IAB member wanted us to own that role for those lists, so we figured these tweaks would settle that.) Hope that helps, S. --------------AB5CD21BBC24727922A1A612 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------AB5CD21BBC24727922A1A612-- --GLMtsSqHif9kqrk3lADAxAqGRvEs0xa88-- --zfXEHnYk85qR5Kk5CKpztfvOK6z0RCPFn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl6eLJYACgkQWrL68XsX K+qztRAAjI/oIInou+2pPsllMAQyJ20OI3HENVxEhJv+9PbZvCUnVsS09A6xGZPP 0O4VSoRkfuu6OWJvNyCViZJQ+8cyqfgnuVxkfDn3T/bihkv+1+CvionKMHpcG5o5 FCkx9lLhjxc50q29WjPVzJEsmBKkttETKJ/W8PiWHhAcx++h4yELAkAwd1MaG2FV xDq2EmaM7ysfCyt0kp+RPD/yx9e+BRep6/YjAo698M9nsejAvwHZwKnfuyt+z64c ra+KO9idhAIY6hepGMf8232l4K7t4/kOl8a1zo8NyFvdxda0LkEFtPETmUmFEhaK LxN0h3r2z8H79L523gfYNHI5gDPVfXCBeO0XM9iJac8+JADQWYLB49bGwTCWJsQJ 6dkB/4fMXtZboG8q7onWiYxC/BivnYSYDoN6SG7OOYp70NMC266h6v2oOdSZsf+n jOeC5NoFAB1M/iE2t6HXG4RoumZ8eQabvNiTMtaKzXEtt9NqKE3chH4KHkCWxNCZ tUP/tpm2lWIlaLBkT2uIfvRHMSC2q2ckhuZU6S52xNkSlW3O0TDGCODrljc++Bte 1rVtZHS2lHJdXv+0pFgByFj3t/Qylk70DhnAEUNacQuZlOwYTpySqlosMj6AVH5B jzNoLoCN014k3rB64fTmx/Eyg2E4d3rFMYpW3+JE32zy3RWo244= =OqCA -----END PGP SIGNATURE----- --zfXEHnYk85qR5Kk5CKpztfvOK6z0RCPFn-- From nobody Mon Apr 20 17:28:56 2020 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 C34E83A13ED; Mon, 20 Apr 2020 17:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.203 X-Spam-Level: X-Spam-Status: No, score=0.203 tagged_above=-999 required=5 tests=[DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 KJpd_klohcDM; Mon, 20 Apr 2020 17:28:49 -0700 (PDT) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 36E6F3A13EA; Mon, 20 Apr 2020 17:28:48 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.37.130]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 03L0SSA6012744 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Apr 2020 17:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1587428922; x=1587515322; i=@elandsys.com; bh=IIUjNbZtNx6dFMUOW10kUeIZz3atfDhcUWFXR6Bbn2E=; h=Date:To:From:Subject:In-Reply-To:References; b=HhgieInvlawPRBM/mGbyYk6LO9rUxIAkHjXxgJHbqil1fqoV+HhYSd2CMuzFFnQAw xMudTsdmGt6n686LWyM6JPL7/Vy9SpSS6ECAWRpXIiC7Npb82woAxMUl5lcHHrAv7g pFHDIe9so7QxBJJQ1Yfa1Vu7wjKdV3piDQJqudAo= Message-Id: <6.2.5.6.2.20200420163649.119f47e8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 20 Apr 2020 17:27:56 -0700 To: Stephen Farrell , Tommy Pauly , architecture-discuss@ietf.org, ietf@ietf.org From: S Moonesamy In-Reply-To: <4aec4c10-92ec-8e34-399b-3d177e6fbf7d@cs.tcd.ie> References: <303F494F-F06C-4E6A-99E5-089798EB56DB@apple.com> <6.2.5.6.2.20200420124357.12e4b868@elandnews.com> <91AA234A-7375-4A04-872B-5B1AB3FA79FF@apple.com> <6.2.5.6.2.20200420141040.0e5895f0@elandnews.com> <4aec4c10-92ec-8e34-399b-3d177e6fbf7d@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [arch-d] Updates on IAB mailing lists 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: Tue, 21 Apr 2020 00:28:54 -0000 Hi Stephen, Thanks for the explanation. I did a quick verification and saw that the i18n program was closed in 2017. That matches my recollection. I am aware that some of the other IAB programs were closed. I don't have an opinion about whether to keep those mailing lists running. I did not consider the rfced-future list when I wrote the email. The rfc-interest list has been running without much intervention. I may have an opinion about those lists. I'll be quiet (for now) about the SAA model. :-) Regards, S. Moonesamy From nobody Mon Apr 20 17:36:20 2020 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 32B3E3A13F7; Mon, 20 Apr 2020 17:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.251 X-Spam-Level: X-Spam-Status: No, score=0.251 tagged_above=-999 required=5 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 tVg-DsEJUr9M; Mon, 20 Apr 2020 17:36:13 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C17303A13F6; Mon, 20 Apr 2020 17:36:11 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 20326548048; Tue, 21 Apr 2020 02:36:05 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 14F5E440041; Tue, 21 Apr 2020 02:36:05 +0200 (CEST) Date: Tue, 21 Apr 2020 02:36:05 +0200 From: Toerless Eckert To: Tommy Pauly Cc: iesg@ietf.org, ietf@ietf.org, "architecture-discuss@ietf.org" Message-ID: <20200421003605.GB19381@faui48f.informatik.uni-erlangen.de> References: <20200420184456.GG5351@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] iesg: Re: Updates on IAB mailing lists 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: Tue, 21 Apr 2020 00:36:15 -0000 Thanks, Tommy, inline On Mon, Apr 20, 2020 at 02:00:23PM -0700, Tommy Pauly wrote: > >> announcements of conferences or activities that are not sponsored > >> or endorsed by the Internet Society, the IETF, or the IAB > > > > OK. Oops. That was typo on my end. Should have been NOK, because the way i read it, bar-bof/inofficial-side-meeting discussions sound like not being permitted by this. > >> and discussion of subjects unrelated to IAB policy, > >> programs, activities, or technical concerns" > > How about ???and mail with content unrelated to technical discussion, Internet architecture, or activities of the IAB???? I think the scope of the mailing list is very well reflected in the description on mail man. I don't think that type of text would improve it or could/should replace it. > It is not the intention of this clarification in the SAA role to at all restrict discussion of the topics you???re bringing up here, such as New IP, or to to limit discussion of side meetings about such. Indeed, such discussion (even if it isn???t an event organized by the IAB), is of relevance and interest to Internet architecture. Thanks. > Working on this text is certainly good to do with your input, and others. The current text is lifted mainly from the IETF discussion list SAA description. Maybe refer to the intent of a specific mailing list as descibed in its mailman "About" instead of trying to reinvent it. > The goal of mentioning irrelevant activities was more to make it clear that if someone started posting what is effectively spam to a list, that the SAA could reach out to the person to moderate that. What is relevant to each list is dependent on the list. Architecture-discuss is indeed a broad list, and any discussion that is truly about Internet architecture fits. > Largely, the motivation to update and clarify this text is to ensure that the community agrees on what the *existing* role of the SAA is for these lists, and to ensure that if there is a instance in which the SAA does need to step in (let???s say, due to spamming the list), that there is a consistent and standard response to make. My hope is to limit this role such that it cannot be used in the ways you mention (limiting community discussion and organization of relevant topics). I have not seen a need on architecture-discuss for an SAA to step in. I think we have a robust peer discussion culture on the list, and i think that there is a good balance of well-meaning attempt to create order and equally well-meaning rebuttals when those seem to go overboard. No need to make that traditional IETF equilibrium more complex through SAA roles unless IMHO there is more hard evidence of need and likelyhood of benefit. > > b) If IAB wants to enforce such restrictive policies for communications > > on an intentional open mailing list such as architecture-discuss@ietf.org, > > then this adds severely to my concerns about how IAB operates. I think > > it is unbecoming for an ISOC entity. > > > > To me, architecture-discuss@iab.org is clearly not a mailing list > > that currently is or in the future should be subject to such IAB > > communication constraints: > > > > 1. It is called architecture-discuss@ietf.org, not @iab.org > > > > 2. About: https://www.ietf.org/mailman/listinfo/Architecture-discuss > > This list is, in fact, an IAB-sponsored activity since its inception. The list does exist at both @ietf.org, and @iab.org. Sure. But the description makes this clearly an IETF activity, it does not mention IAB at all, and i think that was intended by its original sponsors and should stay this way. This is a mailing list for the IETF community and IAB is welcome to participante as IETF members. Its easy for any more iab centric activities to use @iab.org. > > 3. The mayority of the discussions on the mailing list are clearly not > > lead by IAB, but are useful for the community. There is absolutely no > > need for such a mailing list to be constrained to proposed new strict > > IAB regime. Instead i think IAB membership should be welcome into the > > discussion of the community. > > Indeed, the discussion on the list is to be encouraged! The goal of clarifying the policy is to ensure that, as this list is an IAB-sponsored activity, that the community does have a productive and open space to discuss. The SAA???s role is to handle spam or abuse only. Thanks Toerless > > Thanks, > Tommy > > > > > Cheers > > Toerless > > > > On Mon, Apr 20, 2020 at 09:08:48AM -0700, Tommy Pauly wrote: > >> Hello architecture-discuss, > >> > >> We???d like to share a few updates about IAB mailing lists, and solicit the community???s feedback on some new text. > >> > >> First, Tommy Pauly will be joining Stephen Farrell on the (existing, but rarely employed) sergeants-at-arms team to help moderate the list. > >> > >> Second, we???d like to clarify the sergeants-at-arms roles for the lists. The current description on https://www.iab.org/iab-mailing-lists/ does mention that the lists use a sergeant-at-arms model for moderation, but does not describe what this role entails. It also does not specify if this role applies to all of the lists on the page, such as program lists. > >> > >> We???re proposing adding the following text to https://www.iab.org/iab-mailing-lists/ , largely based on the IETF list SAA. We???d love to hear feedback on this approach! > >> > >> ==== > >> > >> IAB mailing lists have sergeants-at-arms, whose role is ensure there are no inappropriate postings. Inappropriate postings consist of: spam and bulk e-mail; announcements of conferences or activities that are not sponsored or endorsed by the Internet Society, the IETF, or the IAB; unprofessional commentary, regardless of subject; and discussion of subjects unrelated to IAB policy, programs, activities, or technical concerns. > >> > >> The sergeants-at-arms are empowered to restrict posting by a person or of a thread when the content is inappropriate and represents a pattern of abuse. Complaints regarding a decision should be referred to the IAB chair. > >> > >> The current sergeants-at-arms for ???architecture-discuss@ietf.org ??? are Stephen Farrell and Tommy Pauly. For program-specific lists, the program chairs act as moderators. The "rfc-interest@rfc-editor.org ??? list is moderated by the Temporary RFC Series Project Manager. > >> > >> ==== > >> > >> Third, we have many lists that are enumerated on the website that are for closed programs or past workshops. We checked the activity on these lists, and we believe that we can close the following lists. Any further discussion on these topics is welcome on architecture-discuss. > >> > >> - caris-attendees@iab.org > >> - emserv-discuss@iab.org > >> - i18n-discuss@iab.org > >> - inip-discuss@iab.org > >> - internetgovtech@iab.org > >> - iotsi@iab.org > >> - iotsu@iab.org > >> - marnew@iab.org > >> - privsec-discuss@iab.org > >> - stackevo-discuss@iab.org > >> > >> The remaining lists will be: > >> > >> - architecture-discuss@ietf.org > >> - chirp@iab.org > >> - model-t@iab.org > >> - rfced-future@iab.org > >> > >> Best, > >> Tommy Pauly, on behalf of the IAB > > > >> _______________________________________________ > >> Architecture-discuss mailing list > >> Architecture-discuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Mon Apr 20 17:50:59 2020 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 B503F3A09EB; Mon, 20 Apr 2020 17:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.251 X-Spam-Level: X-Spam-Status: No, score=0.251 tagged_above=-999 required=5 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 HODLGwYnNO7r; Mon, 20 Apr 2020 17:50:49 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC35C3A09EA; Mon, 20 Apr 2020 17:50:48 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id DADE2548046; Tue, 21 Apr 2020 02:50:43 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id CDF02440041; Tue, 21 Apr 2020 02:50:43 +0200 (CEST) Date: Tue, 21 Apr 2020 02:50:43 +0200 From: Toerless Eckert To: "Joel M. Halpern" Cc: Mary Barnes , "architecture-discuss@ietf.org" , IETF-Discussion list Message-ID: <20200421005043.GC19381@faui48f.informatik.uni-erlangen.de> References: <20200420184456.GG5351@faui48f.informatik.uni-erlangen.de> <93a7ae7f-c2bc-a009-baa9-8671de5ee384@gmail.com> <1b3a6b47-a4b4-1527-0adc-77d4421d8947@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1b3a6b47-a4b4-1527-0adc-77d4421d8947@joelhalpern.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] iesg: Re: Updates on IAB mailing lists 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: Tue, 21 Apr 2020 00:50:51 -0000 Hi Joel, Don't you think it is sufficient for the mailing list to self-manage ? i have seen nothing worse than on any of the other 9999 IETF mailling lists that are not ietf@ietf.org. Indeed, i think we have seen some good examples of self-management on the list in the past month. Tell me if you think that did or did not work well. I for once would be afraid, that if specific persons where given more power to control the scope of the discussion, we might not even have had the technical exchange to answer to specific claims made. On the other hand, i have seen bad examples of the SAA model on the ietf@ietf.org mailing list: An SAA model can quickly deteriorates IMHO into more and more passive-aggressive language policing discussion on all sides as opposed to best effort minimizing robust language and sticking to the technical topics - which i think what happens easier without SAA. I am very interested to hear you express a more specific definition of what you think should be in scope of architecture-discuss than what is written in the current mailmain "about". But probably better to discuss this in a separate thread. Cheers Toerless On Mon, Apr 20, 2020 at 05:54:12PM -0400, Joel M. Halpern wrote: > My read has been that architecture-discuss was for Internet Architecture > topics of relevance to the IAB or IETF. > > That does not, in my book, include random musing about research projects > that may or may not lead to something in some ill-defined time in the > future. > > And even if you disagree with the specific example, it does mean that there > are clearly things which are off-topic for architecture-discuss. Which means > that someone needs to be authorized to deal with such things when they > become problematic. > > Yours, > Joel > > On 4/20/2020 4:13 PM, Mary Barnes wrote: > > Thanks - I hadn't followed Toeless' thread where he encountered the > > problem that triggered his email. > > > > Just to make sure I understand - the architecture-discuss list is > > intended only for topics that the IAB deems of interest specifically to > > the IAB and NOT a general community list to discuss things related to > > the Internet architecture.  Is that correct?   If so, then it does seem > > we need a list where folks can have discussion of technical topics that > > aren't necessarily related to work IAB is doing.   I know we've > > discussed in the past that the IETF discussion list is most suitable for > > those discussions but I think most would agree that the list has a whole > > lot more discussion of how we do non-technical things than technical (I > > would guess 90/10 for the most part).   I think many don't pay near the > > attention to the list that they might if it were technical discussions - > > for example, I subscribe to that list using my general email that I use > > for not real work. > > > > So, one question I would have then, is whether it's thus only > > appropriate for someone in the community to post to architecture-discuss > > if they are asking specific questions on current IAB activities and > > documents? > > > > Regards, > > Mary. > > > > On Mon, Apr 20, 2020 at 2:52 PM Melinda Shore > > wrote: > > > > On 4/20/20 11:49 AM, Mary Barnes wrote: > > > Personally, I think it's a handy list to have > > > for purely technical discussions as opposed to all the non-technical > > > discussions on the main IETF discussion list. > > > > Right, but I think it's clear that it's not every technical > > discussion, which circles back around to Toerless's argument. > > > > Melinda > > > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Mon Apr 20 18:33:02 2020 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 D96573A1466; Mon, 20 Apr 2020 18:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 sIBr-CoUSPKA; Mon, 20 Apr 2020 18:32:55 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 473A93A14BD; Mon, 20 Apr 2020 18:32:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 495mKL7498z1p3h4; Mon, 20 Apr 2020 18:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1587432774; bh=JqV+SdSSvuEJ0mZdso6IXRI9xc5MQjoNn40BFr9k5pY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=cQkgQc49NosCYDt27IeuzGhPfGpGihLWjQjghl5viMIYlI7oijJWh9tbgkwB3lSlC MYbeylps0vc3iqzc7x6s0LF7LVCvzdDk9wQKfDHItR0V5rAuTM0mPpnsoeoz6W0TyZ 7MVsIecHjPviheofUWxs93fqnM1ULFGUCbQ7R2Ws= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 495mKK6tcfz1p3YJ; Mon, 20 Apr 2020 18:32:53 -0700 (PDT) To: Toerless Eckert Cc: "architecture-discuss@ietf.org" , IETF-Discussion list References: <20200420184456.GG5351@faui48f.informatik.uni-erlangen.de> <93a7ae7f-c2bc-a009-baa9-8671de5ee384@gmail.com> <1b3a6b47-a4b4-1527-0adc-77d4421d8947@joelhalpern.com> <20200421005043.GC19381@faui48f.informatik.uni-erlangen.de> From: "Joel M. Halpern" Message-ID: <981f1bcf-ec19-582f-14b6-3e264804c8bc@joelhalpern.com> Date: Mon, 20 Apr 2020 21:32:49 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200421005043.GC19381@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [arch-d] iesg: Re: Updates on IAB mailing lists 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: Tue, 21 Apr 2020 01:33:00 -0000 I have seen many examples on different lists around the IETF of situations where it needed someone to be able to say "no, that does not belong". Or "your question has been answered. Unless you have a new issue, please stop." Or other variations. There have been some postings on architecture-discuss that in my opinion (and I grant it is not mine to judge) were pushing the limits of what belongs. And at least some of them seemed quite unable to hear "this does not belong". (Fortunately, in the case I am thinking of, the rate is low enough we survived.) No, I do not think we need the moderator / SAA function very often. But I do think it is entirely reasonable to be clear who has that responsibility / authority. For IETF WGs, that is the chairs. On the specifics, I read the note from the SAAs as saying that the list excludes things that aare off topic. You reasonably read the note as saying something more restrictive. That part we can (and I think have) clarify. That is quite distinct from whether there should be a backstop. And given that the list was set up by the IAB, it seems appropriate that they appoint the backstop. (I am generally not in favor of the IAB or IESG grabbing extra authority. I do not see this as being of that form.) Yours, Joel On 4/20/2020 8:50 PM, Toerless Eckert wrote: > Hi Joel, > > Don't you think it is sufficient for the mailing list > to self-manage ? i have seen nothing worse than on any of > the other 9999 IETF mailling lists that are not ietf@ietf.org. > > Indeed, i think we have seen some good examples of self-management > on the list in the past month. Tell me if you think that did > or did not work well. > > I for once would be afraid, that if specific persons where > given more power to control the scope of the discussion, > we might not even have had the technical exchange to answer > to specific claims made. On the other hand, i have seen bad > examples of the SAA model on the ietf@ietf.org mailing list: > > An SAA model can quickly deteriorates IMHO into more and > more passive-aggressive language policing discussion on all sides as > opposed to best effort minimizing robust language and sticking > to the technical topics - which i think what happens easier > without SAA. > > I am very interested to hear you express a more specific definition > of what you think should be in scope of architecture-discuss than what > is written in the current mailmain "about". But probably better to > discuss this in a separate thread. > > Cheers > Toerless > > On Mon, Apr 20, 2020 at 05:54:12PM -0400, Joel M. Halpern wrote: >> My read has been that architecture-discuss was for Internet Architecture >> topics of relevance to the IAB or IETF. >> >> That does not, in my book, include random musing about research projects >> that may or may not lead to something in some ill-defined time in the >> future. >> >> And even if you disagree with the specific example, it does mean that there >> are clearly things which are off-topic for architecture-discuss. Which means >> that someone needs to be authorized to deal with such things when they >> become problematic. >> >> Yours, >> Joel >> >> On 4/20/2020 4:13 PM, Mary Barnes wrote: >>> Thanks - I hadn't followed Toeless' thread where he encountered the >>> problem that triggered his email. >>> >>> Just to make sure I understand - the architecture-discuss list is >>> intended only for topics that the IAB deems of interest specifically to >>> the IAB and NOT a general community list to discuss things related to >>> the Internet architecture.  Is that correct?   If so, then it does seem >>> we need a list where folks can have discussion of technical topics that >>> aren't necessarily related to work IAB is doing.   I know we've >>> discussed in the past that the IETF discussion list is most suitable for >>> those discussions but I think most would agree that the list has a whole >>> lot more discussion of how we do non-technical things than technical (I >>> would guess 90/10 for the most part).   I think many don't pay near the >>> attention to the list that they might if it were technical discussions - >>> for example, I subscribe to that list using my general email that I use >>> for not real work. >>> >>> So, one question I would have then, is whether it's thus only >>> appropriate for someone in the community to post to architecture-discuss >>> if they are asking specific questions on current IAB activities and >>> documents? >>> >>> Regards, >>> Mary. >>> >>> On Mon, Apr 20, 2020 at 2:52 PM Melinda Shore >> > wrote: >>> >>> On 4/20/20 11:49 AM, Mary Barnes wrote: >>> > Personally, I think it's a handy list to have >>> > for purely technical discussions as opposed to all the non-technical >>> > discussions on the main IETF discussion list. >>> >>> Right, but I think it's clear that it's not every technical >>> discussion, which circles back around to Toerless's argument. >>> >>> Melinda >>> >>> >>> _______________________________________________ >>> Architecture-discuss mailing list >>> Architecture-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/architecture-discuss >>> >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss > From nobody Tue Apr 21 11:05:00 2020 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 DEBE43A0901; Tue, 21 Apr 2020 11:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 Uem2V1gD2jpq; Tue, 21 Apr 2020 11:04:43 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95ECC3A08FE; Tue, 21 Apr 2020 11:04:42 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id EBAE1548043; Tue, 21 Apr 2020 20:04:33 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id E2ECA440041; Tue, 21 Apr 2020 20:04:33 +0200 (CEST) Date: Tue, 21 Apr 2020 20:04:33 +0200 From: Toerless Eckert To: "Joel M. Halpern" Cc: "architecture-discuss@ietf.org" , IETF-Discussion list Message-ID: <20200421180433.GA60727@faui48f.informatik.uni-erlangen.de> References: <20200420184456.GG5351@faui48f.informatik.uni-erlangen.de> <93a7ae7f-c2bc-a009-baa9-8671de5ee384@gmail.com> <1b3a6b47-a4b4-1527-0adc-77d4421d8947@joelhalpern.com> <20200421005043.GC19381@faui48f.informatik.uni-erlangen.de> <981f1bcf-ec19-582f-14b6-3e264804c8bc@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <981f1bcf-ec19-582f-14b6-3e264804c8bc@joelhalpern.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] iesg: Re: Updates on IAB mailing lists 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: Tue, 21 Apr 2020 18:04:46 -0000 Thanks, Joel. I think in general it would be good to avod creating multiple places where to look for policies about mailing lists. IMHO the "about" on mailman should be authoritative. If a non-wg maiing list seems to need some explicit management person(s), maybe add that info to the "about". I am not sure any of the current non-WG IETF mailing lists actually has any official designated persons for such a rule (except well-known exceptions such as ietf@ietf.org). IMHO self-management works usually well, and in the few case where not, one could always escalate to IESG/IAB. Whether a separate designated SAA is better i doubt, but no strong opinion. Chers Toerless On Mon, Apr 20, 2020 at 09:32:49PM -0400, Joel M. Halpern wrote: > I have seen many examples on different lists around the IETF of situations > where it needed someone to be able to say "no, that does not belong". Or > "your question has been answered. Unless you have a new issue, please > stop." Or other variations. There have been some postings on > architecture-discuss that in my opinion (and I grant it is not mine to > judge) were pushing the limits of what belongs. And at least some of them > seemed quite unable to hear "this does not belong". (Fortunately, in the > case I am thinking of, the rate is low enough we survived.) > > No, I do not think we need the moderator / SAA function very often. But I > do think it is entirely reasonable to be clear who has that responsibility / > authority. For IETF WGs, that is the chairs. > > On the specifics, I read the note from the SAAs as saying that the list > excludes things that aare off topic. You reasonably read the note as saying > something more restrictive. That part we can (and I think have) clarify. > That is quite distinct from whether there should be a backstop. And given > that the list was set up by the IAB, it seems appropriate that they appoint > the backstop. (I am generally not in favor of the IAB or IESG grabbing > extra authority. I do not see this as being of that form.) > > Yours, > Joel > > > On 4/20/2020 8:50 PM, Toerless Eckert wrote: > > Hi Joel, > > > > Don't you think it is sufficient for the mailing list > > to self-manage ? i have seen nothing worse than on any of > > the other 9999 IETF mailling lists that are not ietf@ietf.org. > > > > Indeed, i think we have seen some good examples of self-management > > on the list in the past month. Tell me if you think that did > > or did not work well. > > > > I for once would be afraid, that if specific persons where > > given more power to control the scope of the discussion, > > we might not even have had the technical exchange to answer > > to specific claims made. On the other hand, i have seen bad > > examples of the SAA model on the ietf@ietf.org mailing list: > > > > An SAA model can quickly deteriorates IMHO into more and > > more passive-aggressive language policing discussion on all sides as > > opposed to best effort minimizing robust language and sticking > > to the technical topics - which i think what happens easier > > without SAA. > > > > I am very interested to hear you express a more specific definition > > of what you think should be in scope of architecture-discuss than what > > is written in the current mailmain "about". But probably better to > > discuss this in a separate thread. > > > > Cheers > > Toerless > > > > On Mon, Apr 20, 2020 at 05:54:12PM -0400, Joel M. Halpern wrote: > > > My read has been that architecture-discuss was for Internet Architecture > > > topics of relevance to the IAB or IETF. > > > > > > That does not, in my book, include random musing about research projects > > > that may or may not lead to something in some ill-defined time in the > > > future. > > > > > > And even if you disagree with the specific example, it does mean that there > > > are clearly things which are off-topic for architecture-discuss. Which means > > > that someone needs to be authorized to deal with such things when they > > > become problematic. > > > > > > Yours, > > > Joel > > > > > > On 4/20/2020 4:13 PM, Mary Barnes wrote: > > > > Thanks - I hadn't followed Toeless' thread where he encountered the > > > > problem that triggered his email. > > > > > > > > Just to make sure I understand - the architecture-discuss list is > > > > intended only for topics that the IAB deems of interest specifically to > > > > the IAB and NOT a general community list to discuss things related to > > > > the Internet architecture.  Is that correct?   If so, then it does seem > > > > we need a list where folks can have discussion of technical topics that > > > > aren't necessarily related to work IAB is doing.   I know we've > > > > discussed in the past that the IETF discussion list is most suitable for > > > > those discussions but I think most would agree that the list has a whole > > > > lot more discussion of how we do non-technical things than technical (I > > > > would guess 90/10 for the most part).   I think many don't pay near the > > > > attention to the list that they might if it were technical discussions - > > > > for example, I subscribe to that list using my general email that I use > > > > for not real work. > > > > > > > > So, one question I would have then, is whether it's thus only > > > > appropriate for someone in the community to post to architecture-discuss > > > > if they are asking specific questions on current IAB activities and > > > > documents? > > > > > > > > Regards, > > > > Mary. > > > > > > > > On Mon, Apr 20, 2020 at 2:52 PM Melinda Shore > > > > wrote: > > > > > > > > On 4/20/20 11:49 AM, Mary Barnes wrote: > > > > > Personally, I think it's a handy list to have > > > > > for purely technical discussions as opposed to all the non-technical > > > > > discussions on the main IETF discussion list. > > > > > > > > Right, but I think it's clear that it's not every technical > > > > discussion, which circles back around to Toerless's argument. > > > > > > > > Melinda > > > > > > > > > > > > _______________________________________________ > > > > Architecture-discuss mailing list > > > > Architecture-discuss@ietf.org > > > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > > > > > > > > > _______________________________________________ > > > Architecture-discuss mailing list > > > Architecture-discuss@ietf.org > > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > -- --- tte@cs.fau.de From nobody Tue Apr 21 14:24:09 2020 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 8D0CE3A0A96 for ; Tue, 21 Apr 2020 14:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=heapingbits.net header.b=WB0RBSUT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KxzwY4Ec 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 E0Q1Gq7fYkrR for ; Tue, 21 Apr 2020 14:24:05 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B98043A0A93 for ; Tue, 21 Apr 2020 14:24:05 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id EB9B95C0129 for ; Tue, 21 Apr 2020 17:24:04 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Tue, 21 Apr 2020 17:24:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=dqzik B6ZTo747GcmKaSOnGv2bYXIoSS0DUcJ5Ik4KPM=; b=WB0RBSUTNlfR49UjH8uGl rN4YEUlah9RVP+DIzpsG1RH9u43SHtNzCcYw1YF47JJn+zLAB3fefswVa1SlUQiq BwaImZOyZgkbFlvntP5QeJDfytV32G8bS8fo+1GX+Hd14vPUdoOF0037AtP1exZa UW3azs+FW0O2FrycE69gHh17FvbWmAzfpXLVhQ/EAYNL6nzhWkMYu36/5eLwpYnY 26s9Rlbzo8unajj6Bd/1aTum/rWN+7daFOselLSrWLodhj6d9qbVt1mi7dFRfyIb Aewmpdw+q30nHqB6aJmNpZnQBdqHbj4zaWKdKcdFtn9Vp5t4CcEMiG/+n7lRNdnL A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=dqzikB6ZTo747GcmKaSOnGv2bYXIoSS0DUcJ5Ik4K PM=; b=KxzwY4EcnW1idWn6Ru5KgSCUy1OkhHVDgo8uqb+R3hLG8HfFHG0a9IMJu RcQ4N7UXkeUCtaboiWoXrKM2W+TuHLENcankZJwESsTXnrib7O0s5TgLxUfqayFh Yv5IfetF8/AKubrcc78G33TKkHPCvG9Jk93NhTls/wbykvntUSOFgUrLIjOvbYGu Pkin2PNkJQlJ4EGV3WuRIEnAJ8D1ENTXPHG6YDMrAEeWdaFiQ5ZHuTfP4KLThG9k iVFi4KsynG7819X2Fm43H4zO7qzSYRwciUohuMzxZ2dkEGzewvX1gfxTmMVdNASe D0pfu4d8R8RW6V4jsWa7gTs4T4M1w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeehgdduiedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggr fieshhgvrghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehirggsrdhorhhgne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheptggrfies hhgvrghpihhnghgsihhtshdrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5870A180091; Tue, 21 Apr 2020 17:24:04 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <303F494F-F06C-4E6A-99E5-089798EB56DB@apple.com> References: <303F494F-F06C-4E6A-99E5-089798EB56DB@apple.com> Date: Tue, 21 Apr 2020 14:23:32 -0700 From: "Christopher Wood" To: architecture-discuss@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [arch-d] Updates on IAB mailing lists 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: Tue, 21 Apr 2020 21:24:08 -0000 On Mon, Apr 20, 2020, at 9:08 AM, Tommy Pauly wrote: > Hello architecture-discuss, >=20 > We=E2=80=99d like to share a few updates about IAB mailing lists, and = solicit=20 > the community=E2=80=99s feedback on some new text. >=20 > First, Tommy Pauly will be joining Stephen Farrell on the (existing,=20= > but rarely employed) sergeants-at-arms team to help moderate the list.= Thank you both for your service! > Second, we=E2=80=99d like to clarify the sergeants-at-arms roles for t= he lists.=20 > The current description on https://www.iab.org/iab-mailing-lists/ does= =20 > mention that the lists use a sergeant-at-arms model for moderation, bu= t=20 > does not describe what this role entails. It also does not specify if=20= > this role applies to all of the lists on the page, such as program=20 > lists. >=20 > We=E2=80=99re proposing adding the following text to=20 > https://www.iab.org/iab-mailing-lists/, largely based on the IETF list= =20 > SAA. We=E2=80=99d love to hear feedback on this approach! >=20 > =3D=3D=3D=3D >=20 > IAB mailing lists have sergeants-at-arms, whose role is ensure there=20= nit: "whose role is ensure" > are no inappropriate postings. Inappropriate postings consist of: spam= =20 > and bulk e-mail; announcements of conferences or activities that are=20= > not sponsored or endorsed by the Internet Society, the IETF, or the=20= > IAB; unprofessional commentary, regardless of subject; and discussion=20= > of subjects unrelated to IAB policy, programs, activities, or technica= l=20 > concerns. >=20 > The sergeants-at-arms are empowered to restrict posting by a person or= =20 > of a thread when the content is inappropriate and represents a pattern= =20 > of abuse. Complaints regarding a decision should be referred to the IA= B=20 > chair. >=20 > The current sergeants-at-arms for =E2=80=9Carchitecture-discuss@ietf.o= rg=20 > =E2=80=9D are Stephen Farrell and= Tommy=20 > Pauly. For program-specific lists, the program chairs act as=20 > moderators. The "rfc-interest@rfc-editor.org=E2=80=9D list is moderate= d by the=20 > Temporary RFC Series Project Manager. >=20 > =3D=3D=3D=3D This seems like a fine addition to me. > Third, we have many lists that are enumerated on the website that are=20= > for closed programs or past workshops. We checked the activity on thes= e=20 > lists, and we believe that we can close the following lists. Any=20 > further discussion on these topics is welcome on architecture-discuss.= >=20 > - caris-attendees@iab.org > - emserv-discuss@iab.org > - i18n-discuss@iab.org > - inip-discuss@iab.org > - internetgovtech@iab.org > - iotsi@iab.org > - iotsu@iab.org > - marnew@iab.org > - privsec-discuss@iab.org > - stackevo-discuss@iab.org >=20 > The remaining lists will be: >=20 > - architecture-discuss@ietf.org > - chirp@iab.org > - model-t@iab.org > - rfced-future@iab.org And this seems like a sensible way to consolidate ongoing discussions.=20= Thanks for clearing and cleaning things up! Best, Chris From nobody Tue Apr 28 12:07:27 2020 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 AEC733A0C69 for ; Tue, 28 Apr 2020 12:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 CrOcJzRnSnUp for ; Tue, 28 Apr 2020 12:07:17 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 186F93A116E for ; Tue, 28 Apr 2020 12:06:14 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 1B1FD548049; Tue, 28 Apr 2020 21:06:08 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 138F3440041; Tue, 28 Apr 2020 21:06:08 +0200 (CEST) Date: Tue, 28 Apr 2020 21:06:08 +0200 From: Toerless Eckert To: architecture-discuss@ietf.org Message-ID: <20200428190608.GN62020@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [arch-d] FYI: "ISOC" "New IP" "discussion" "paper" 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: Tue, 28 Apr 2020 19:07:25 -0000 Dear architecture-discuss, Olaf I hope this forward is beneficial to the IETF architecture-discussion mailing list. - Even though the the appended email claims that this was widely cross-posted, i did NOT see it in any of the many IETF mailing lists i am subscribed to. - I could not find any actual public place (mailing list) for an open discussion about he topic of the paper: - internetpolicy@elists.isoc.org does not allow Global ISOC members to join by themselves, nor do i know if it would welcome discussion. In fact it is not even listed on the set of pubic ISOC mailing lists. So the nature of this mailing list seems to be secret to me. - NewIP-Discussion-Paper@isoc.org does seem to be just an alias for the authors. Unfortunately, the set of recipient seems to be secret, so i would not know the extend of people who will receive my emails, no would i be able to know about any other feedback (no public archive of the alias). If there was for example any US EAR entity listed recipient on that private mailing list alias, i could be violating US export regulations by sending technical detail explanations to such a non-public alias. >From these few data points, i find the proposed communication mechanisms about that paper somewhat confusing, if not concerning, but maybe i do misunderstand how ISOC is or is not an open communtiy like i have experienced IETF to be. Cheers Toerless https://www.internetsociety.org/resources/doc/2020/discussion-paper-an-analysis-of-the-new-ip-proposal-to-the-itu-t/ > On April 28, 2020 at 2:33:06 AM, Olaf Kolkman via InternetPolicy (internetpolicy@elists.isoc.org) wrote: > > Dear Colleagues, > > With the usual cross-post apologies[*]. > > In the run up to the ITU World Telecommunication Standardization Assembly (WTSA-20) later this year there has been some discussion about a proposal called the “New IPâ€. It is positioned as a top-down architecture to solve a number of use cases that are currently been developed in the ITU-T’s Future Network 2030 Focus Group. > > The Internet Society is carefully following the developments in the run-up to WTSA-20. We are trying to understand if and how the New IP works with the Internet as we know it, if it actually solves problems that cannot be solved in the Internet, and, if the ITU-T is developing standards, where other standards development organizations (SDOs) have change control. > > In order to get a sense of the environment we commissioned a discussion paper, “An analysis of the ‘New IP’ proposal to the ITU-T.†The paper helps inform us and the broader community whilst the public debate around these proposals shapes up. It also aims to inform and shape the discussion from the Internet’s Society’s perspective. Eventually the debate around it will inform our position and the potential further evolution of the discussion paper itself. Note that the paper documents the Internet Society’s emerging opinion, but does not represent a final Internet Society position. Instead, we intend it as a means to gather information and insight from our community on the topic. > > We welcome any feedback on “An analysis of the ‘New IP’ via the email address NewIP-Discussion-Paper@isoc.org > > —Olaf Kolkman > > [*] This mail has been sent to various relevant mailing lists and featured as a blog on the Internet Society website. > > Olaf M. Kolkman > Principal - Internet Technology, Policy, and Advocacy > Internet Society Tweets as: @kolkman > _______________________________________________ > To manage your Internet Society subscriptions > or unsubscribe, log into the Member Portal at > https://admin.internetsociety.org/622619/User/Login > and go to the Preferences tab within your profile. > - > View the Internet Society Code of Conduct: https://www.internetsociety.org/become-a-member/code-of-conduct/ From nobody Tue Apr 28 13:35:03 2020 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 487A33A0C83 for ; Tue, 28 Apr 2020 13:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4PbvpIEd80W for ; Tue, 28 Apr 2020 13:34:59 -0700 (PDT) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 D20373A0C80 for ; Tue, 28 Apr 2020 13:34:59 -0700 (PDT) Received: by mail-pj1-x1034.google.com with SMTP id a31so4643pje.1 for ; Tue, 28 Apr 2020 13:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=51GxSEJWkvOnebbo3AMfo4Z1RJXL4icfPk1o6aafk0A=; b=bvSksJd3y1Cseb4KEy90sJz0Si22Wyx/YwK29DYXF1e4tV3H6yqAErQuMC2GKJxmBg BzVaVmlwCQ9zRKZ2ynqJjfTAcQQUKV9oGtnR4BBILhyRHbuhNKum3piOxj/muXAT8Nug nWcaQ8zbirknEPp1YLATGwYingSp3C6MgjyeZKPn2NMo03th3Q7cU3d2bDU8Y6fGChlz M149CwMV6XAMYyAKw3+7jmKjdddVHp2xfIFtrkYjTWgmaNT5oZMeksne3VX9PNrNuHdd AQFArrRh25/JFpyKtvcluobeoP/DirZ/OzzcAQmSzDSXgCi7uCE20v/NxTbtOKHoorzp 3V1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=51GxSEJWkvOnebbo3AMfo4Z1RJXL4icfPk1o6aafk0A=; b=EZTMxgTswGRShk4jNtDV6F7dKooOm3F5bpgCZnFWCCrlXDJRkEGY6KAz9BAts8nJZV u/gSDpiPJXonlfVQiUO2xrsWDP9rVyxO+ILbGQEk+4j1ljMdZnXFy6KQhUDT3JTFBE5M 6ZD6GQb/qrgjo8La4l7qpjWO7Udp7ijYuEz9S2m1i5E+jG36Ul7Oym3hRQ6NpxRugNKI 0vpHvtV3KH55QJnpWomMW0xxYmQjgWdNhEQS/tXjA11c5hWV8GSXFz1kw8bIdWCgOtju 3mYC2xxlN9uM+9cPM3GCPN7EeVWdz+p058PJL6m7nDMzy6Gy9xp8av1nUB7sr3zEFU1v +Wwg== X-Gm-Message-State: AGi0Pubp5A7sdr8IzkTeXX0oAVfWCigEDqTG2LLetoyrMxAmYSlbbQrh E/L/clonxbKYDLRu5eofhiojsCw2hgw= X-Google-Smtp-Source: APiQypI7leutWrC8Z5W1MSmSUPZbXb56PUPMPl1rFm3TqzP12KxbcLxkFuI6NkeY5URGS76fyiUlyg== X-Received: by 2002:a17:90a:68c1:: with SMTP id q1mr7244885pjj.35.1588106098870; Tue, 28 Apr 2020 13:34:58 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.84]) by smtp.gmail.com with ESMTPSA id p64sm3011333pjp.7.2020.04.28.13.34.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2020 13:34:58 -0700 (PDT) To: Toerless Eckert References: <20200428190608.GN62020@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Cc: architecture-discuss@ietf.org Message-ID: Date: Wed, 29 Apr 2020 08:34:53 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20200428190608.GN62020@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] FYI: "ISOC" "New IP" "discussion" "paper" 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: Tue, 28 Apr 2020 20:35:01 -0000 Hi Toerless, On one point only: > internetpolicy@elists.isoc.org does not allow Global ISOC members to > join by themselves, nor do i know if it would welcome discussion. > In fact it is not even listed on the set of pubic ISOC mailing lists. > So the nature of this mailing list seems to be secret to me. You can join but not in the normal way... you have to go through a strange procedure in the Member's Portal or some such place, where I believe it's called a "Community" or some such. Can't remember, but it was very baroque. I believe Andrew said that there is work underway to change this. However, I don't see any relevant discussion in the (members only) archive. Typical subjects recently: on people not heard (was Re: Language reversion, and an idea) OneWeb bankruptcy Interview with Parminder on community ownership of data Official de-chartering of the Internet Society Ireland Chapter North-South issues in the Ditigal Economy European Commission solicits feedback on GDPR's efficiency Official de-chartering of the Internet Society Ireland Chapter Regards Brian From nobody Tue Apr 28 14:17:48 2020 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 446963A0793 for ; Tue, 28 Apr 2020 14:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 8G2OKB22Q8EF for ; Tue, 28 Apr 2020 14:17:44 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E8EA3A0781 for ; Tue, 28 Apr 2020 14:17:43 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5EFFB548043; Tue, 28 Apr 2020 23:17:37 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 56471440041; Tue, 28 Apr 2020 23:17:37 +0200 (CEST) Date: Tue, 28 Apr 2020 23:17:37 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: architecture-discuss@ietf.org Message-ID: <20200428211737.GP62020@faui48f.informatik.uni-erlangen.de> References: <20200428190608.GN62020@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] FYI: "ISOC" "New IP" "discussion" "paper" 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: Tue, 28 Apr 2020 21:17:46 -0000 Thanks, Brian, inline On Wed, Apr 29, 2020 at 08:34:53AM +1200, Brian E Carpenter wrote: > Hi Toerless, > > On one point only: > > > internetpolicy@elists.isoc.org does not allow Global ISOC members to > > join by themselves, nor do i know if it would welcome discussion. > > In fact it is not even listed on the set of pubic ISOC mailing lists. > > So the nature of this mailing list seems to be secret to me. > > You can join but not in the normal way... you have to go through a > strange procedure in the Member's Portal or some such place, where I > believe it's called a "Community" or some such. Can't remember, but it > was very baroque. Yes, i tried to exhaust my options in there, but got nowhere, this includes going to https://elists.isoc.org/mailman/private/internetpolicy/ and attempting to join via that unpublished link. I don't mind baroque as long as its published, but published information is wrong, and the fact that the list is not included in the published list of ISOC lists makes me wonder if the list lists that are only accessible to ISOC members is even published anywhere... I did send emails to support. > I believe Andrew said that there is work underway to change this. I did have a bit of discussion about the possibility of a list like "internet-future@elists.isoc.org, but was told in PM that getting new mailing lists on elists.isoc.org is a process competing with continental drift in speed. Something like such a list would be a great option IMHO for the ISOC society to participate on not only in discussions about internet history but also its future. > However, I don't see any relevant discussion in the (members only) > archive. Typical subjects recently: > > on people not heard (was Re: Language reversion, and an idea) > OneWeb bankruptcy > Interview with Parminder on community ownership of data > Official de-chartering of the Internet Society Ireland Chapter > North-South issues in the Ditigal Economy > European Commission solicits feedback on GDPR's efficiency > Official de-chartering of the Internet Society Ireland Chapter Given how seemingly non-published internetpolicy mailing list is, i wonder who is even subscribed to it. Not sure if it is possible to figure that out. I very much liked Jay Daleys reconfirmation that IETF mailing list membership is of public nature. Not sure what ISOC's policy is. Cheers Toerless > Regards > Brian -- --- tte@cs.fau.de From nobody Tue Apr 28 14:59:40 2020 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 1B2AF3A09E1 for ; Tue, 28 Apr 2020 14:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=ianpeter.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 LHvxSDwmx-Zx for ; Tue, 28 Apr 2020 14:59:32 -0700 (PDT) Received: from caracal.birch.relay.mailchannels.net (caracal.birch.relay.mailchannels.net [23.83.209.30]) (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 026B53A09DC for ; Tue, 28 Apr 2020 14:59:28 -0700 (PDT) X-Sender-Id: 8xbl3cp958|x-authuser|ian.peter@ianpeter.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 7321A360D44; Tue, 28 Apr 2020 21:59:26 +0000 (UTC) Received: from rs3-ams.serverhostgroup.com (100-96-14-17.trex.outbound.svc.cluster.local [100.96.14.17]) (Authenticated sender: 8xbl3cp958) by relay.mailchannels.net (Postfix) with ESMTPA id 59EAB360CC7; Tue, 28 Apr 2020 21:59:24 +0000 (UTC) X-Sender-Id: 8xbl3cp958|x-authuser|ian.peter@ianpeter.com Received: from rs3-ams.serverhostgroup.com (rs3-ams.serverhostgroup.com [178.62.240.214]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Tue, 28 Apr 2020 21:59:25 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: 8xbl3cp958|x-authuser|ian.peter@ianpeter.com X-MailChannels-Auth-Id: 8xbl3cp958 X-Cooperative-Imminent: 3b4b3b7a793436a0_1588111165631_4104074455 X-MC-Loop-Signature: 1588111165631:3134761726 X-MC-Ingress-Time: 1588111165631 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ianpeter.com; s=default; h=Content-Transfer-Encoding:Content-Type: Mime-Version:Reply-To:References:In-Reply-To:Message-Id:Date:Cc:Subject:To: From:Sender: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=1zOZiCFhxIj27yqKwSlxyZwccqe5ikMG/mvNksa6510=; b=lnj/KWHUMoObC+mkM3T1rJcMnv RrpUer4SU0rEynN131uDcnAgyIqjOIQVD/OooH6GhuHUmAJbHnskv6HXiNzrCuUg4hHMg8XQGma0P MnxZ9NKXo0I3YShbMQCsZjIE6bxHXsVoRUHMBs8xAKq2Ay+OBTK2E4nYrOPbmMSDpmUs=; Received: from [101.175.12.163] (port=64773 helo=[192.168.0.8]) by rs3-ams.serverhostgroup.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jTYG8-006B2e-VQ; Tue, 28 Apr 2020 23:59:21 +0200 From: "Ian Peter" To: "Toerless Eckert" , "Brian E Carpenter" Cc: architecture-discuss@ietf.org Date: Tue, 28 Apr 2020 21:58:57 +0000 Message-Id: In-Reply-To: <20200428211737.GP62020@faui48f.informatik.uni-erlangen.de> References: <20200428190608.GN62020@faui48f.informatik.uni-erlangen.de> <20200428211737.GP62020@faui48f.informatik.uni-erlangen.de> Reply-To: "Ian Peter" User-Agent: eM_Client/7.2.36908.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-AuthUser: ian.peter@ianpeter.com Archived-At: Subject: Re: [arch-d] FYI: "ISOC" "New IP" "discussion" "paper" 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: Tue, 28 Apr 2020 21:59:38 -0000 Toerless, The internetpolicy list in question was dormant for decades, but came to=20 life again a few months ago with a substantial discussion on the issues=20 surrounding ISOC's proposed sale of Public Internet Registry (PIR) .=20 It's fair to say a lot of this discussion was very critical of ISOC's=20 position, sometimes quite undiplomatically so. Perhaps some restrictions=20 were placed on new memberships in these circumstances? I do not know... The "new IP" proposal was posted there a couple of days ago. To date it=20 has not provoked much discussion, just a couple of comments equating=20 this with the OSI battles 30 years ago. Perhaps more substantial comment=20 will come in the near future. Ian Peter ------ Original Message ------ From: "Toerless Eckert" To: "Brian E Carpenter" Cc: architecture-discuss@ietf.org Sent: 29/04/2020 7:17:37 AM Subject: Re: [arch-d] FYI: "ISOC" "New IP" "discussion" "paper" >Thanks, Brian, inline > >On Wed, Apr 29, 2020 at 08:34:53AM +1200, Brian E Carpenter wrote: >> Hi Toerless, >> >> On one point only: >> >> > internetpolicy@elists.isoc.org does not allow Global ISOC members t= o >> > join by themselves, nor do i know if it would welcome discussion. >> > In fact it is not even listed on the set of pubic ISOC mailing list= s. >> > So the nature of this mailing list seems to be secret to me. >> >> You can join but not in the normal way... you have to go through a >> strange procedure in the Member's Portal or some such place, where I >> believe it's called a "Community" or some such. Can't remember, but it >> was very baroque. > >Yes, i tried to exhaust my options in there, but got nowhere, >this includes going to > >https://elists.isoc.org/mailman/private/internetpolicy/ > >and attempting to join via that unpublished link. > >I don't mind baroque as long as its published, but published information >is wrong, and the fact that the list is not included in the published >list of ISOC lists makes me wonder if the list lists that are only >accessible to ISOC members is even published anywhere... > >I did send emails to support. > >> I believe Andrew said that there is work underway to change this. > >I did have a bit of discussion about the possibility of >a list like "internet-future@elists.isoc.org, but was told in PM >that getting new mailing lists on elists.isoc.org is a >process competing with continental drift in speed. > >Something like such a list would be a great option IMHO for >the ISOC society to participate on not only in discussions about >internet history but also its future. > >> However, I don't see any relevant discussion in the (members only) >> archive. Typical subjects recently: >> >> on people not heard (was Re: Language reversion, and an idea) >> OneWeb bankruptcy >> Interview with Parminder on community ownership of data >> Official de-chartering of the Internet Society Ireland Chapter >> North-South issues in the Ditigal Economy >> European Commission solicits feedback on GDPR's efficiency >> Official de-chartering of the Internet Society Ireland Chapter > >Given how seemingly non-published internetpolicy mailing list is, >i wonder who is even subscribed to it. Not sure if it is possible >to figure that out. I very much liked Jay Daleys reconfirmation >that IETF mailing list membership is of public nature. Not sure >what ISOC's policy is. > >Cheers > Toerless > >> Regards >> Brian > >-- >--- >tte@cs.fau.de > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Tue Apr 28 15:22:34 2020 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 F071E3A0105 for ; Tue, 28 Apr 2020 15:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 OS9QcOd8kOjQ for ; Tue, 28 Apr 2020 15:22:30 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0AD63A00C1 for ; Tue, 28 Apr 2020 15:22:25 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B1623548048; Wed, 29 Apr 2020 00:22:19 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id A5CFD440041; Wed, 29 Apr 2020 00:22:19 +0200 (CEST) Date: Wed, 29 Apr 2020 00:22:19 +0200 From: Toerless Eckert To: Ian Peter Cc: Brian E Carpenter , architecture-discuss@ietf.org Message-ID: <20200428222219.GQ62020@faui48f.informatik.uni-erlangen.de> References: <20200428190608.GN62020@faui48f.informatik.uni-erlangen.de> <20200428211737.GP62020@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] FYI: "ISOC" "New IP" "discussion" "paper" 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: Tue, 28 Apr 2020 22:22:33 -0000 Thanks, Ian As said in my mail, i think it would be appropriate to how i understood the spirit of IETF/ISOC to have the ability for a public/open discussion about the subject matter, so the non-public feedback channel and the use of a lists where its unclear how to even join it is quite frustrating, and it would be great if this could be fixed. As said in response to Brian, maybe a better solution would be to create some group like "internet-future" at the isoc mail server. In any case, for a "discussion" paper as this one, it would be great to point to an actual forum where the discussion can be had. Cheers Toerless On Tue, Apr 28, 2020 at 09:58:57PM +0000, Ian Peter wrote: > Toerless, > > The internetpolicy list in question was dormant for decades, but came to > life again a few months ago with a substantial discussion on the issues > surrounding ISOC's proposed sale of Public Internet Registry (PIR) . It's > fair to say a lot of this discussion was very critical of ISOC's position, > sometimes quite undiplomatically so. Perhaps some restrictions were placed > on new memberships in these circumstances? I do not know... > > The "new IP" proposal was posted there a couple of days ago. To date it has > not provoked much discussion, just a couple of comments equating this with > the OSI battles 30 years ago. Perhaps more substantial comment will come in > the near future. > > Ian Peter > > > > > > > > ------ Original Message ------ > From: "Toerless Eckert" > To: "Brian E Carpenter" > Cc: architecture-discuss@ietf.org > Sent: 29/04/2020 7:17:37 AM > Subject: Re: [arch-d] FYI: "ISOC" "New IP" "discussion" "paper" > > > Thanks, Brian, inline > > > > On Wed, Apr 29, 2020 at 08:34:53AM +1200, Brian E Carpenter wrote: > > > Hi Toerless, > > > > > > On one point only: > > > > > > > internetpolicy@elists.isoc.org does not allow Global ISOC members to > > > > join by themselves, nor do i know if it would welcome discussion. > > > > In fact it is not even listed on the set of pubic ISOC mailing lists. > > > > So the nature of this mailing list seems to be secret to me. > > > > > > You can join but not in the normal way... you have to go through a > > > strange procedure in the Member's Portal or some such place, where I > > > believe it's called a "Community" or some such. Can't remember, but it > > > was very baroque. > > > > Yes, i tried to exhaust my options in there, but got nowhere, > > this includes going to > > > > https://elists.isoc.org/mailman/private/internetpolicy/ > > > > and attempting to join via that unpublished link. > > > > I don't mind baroque as long as its published, but published information > > is wrong, and the fact that the list is not included in the published > > list of ISOC lists makes me wonder if the list lists that are only > > accessible to ISOC members is even published anywhere... > > > > I did send emails to support. > > > > > I believe Andrew said that there is work underway to change this. > > > > I did have a bit of discussion about the possibility of > > a list like "internet-future@elists.isoc.org, but was told in PM > > that getting new mailing lists on elists.isoc.org is a > > process competing with continental drift in speed. > > > > Something like such a list would be a great option IMHO for > > the ISOC society to participate on not only in discussions about > > internet history but also its future. > > > > > However, I don't see any relevant discussion in the (members only) > > > archive. Typical subjects recently: > > > > > > on people not heard (was Re: Language reversion, and an idea) > > > OneWeb bankruptcy > > > Interview with Parminder on community ownership of data > > > Official de-chartering of the Internet Society Ireland Chapter > > > North-South issues in the Ditigal Economy > > > European Commission solicits feedback on GDPR's efficiency > > > Official de-chartering of the Internet Society Ireland Chapter > > > > Given how seemingly non-published internetpolicy mailing list is, > > i wonder who is even subscribed to it. Not sure if it is possible > > to figure that out. I very much liked Jay Daleys reconfirmation > > that IETF mailing list membership is of public nature. Not sure > > what ISOC's policy is. > > > > Cheers > > Toerless > > > > > Regards > > > Brian > > > > -- > > --- > > tte@cs.fau.de > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Tue Apr 28 19:57:04 2020 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 D7A3A3A0CDE for ; Tue, 28 Apr 2020 19:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=FOtwioUD; dkim=pass (1536-bit key) header.d=taugh.com header.b=hr6cO3mr 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 NNW3PPhfpzhM for ; Tue, 28 Apr 2020 19:57:00 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 BB8C13A0CC6 for ; Tue, 28 Apr 2020 19:56:59 -0700 (PDT) Received: (qmail 26140 invoked from network); 29 Apr 2020 02:56:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=6618.5ea8ecfa.k2004; bh=/MMRdeE4v4Y7u6si2T/Uqtx8TBsxgX35St0MimbeKvY=; b=FOtwioUDNl1r3yZ7aNUWeCIm0HVwtdWkn5mDC5Q6mNxnbHSWQD07MnGM9I/pvbTz7hFiPfXfcKFwXsX8fdTB/WG4HSu8wJ9O+WPrUHHug/pzvv3m3wAfHBRpquHzdZrjQcZsknnOK/NUYN1utO3gYU+J3gOyDUyUiyhr/MXERvOuaTKd9TzPvO/eS2JL/amumv+InTiCjfgGbUwfS6MkdkTHFWKV9+3gjzudRJ61vBTJoCwrwNnOye8jjzYMo06B DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=6618.5ea8ecfa.k2004; bh=/MMRdeE4v4Y7u6si2T/Uqtx8TBsxgX35St0MimbeKvY=; b=hr6cO3mrvp3W2KQuC39p1bDV6/9/cZD8Y9DjgqNCgdqReX+vb8NqmBPTtutd/jJgvQqIX7qnq4/Bj/ZX0lJeRlL3upXNPWe92BAwjRDc3oJ+8HSMPIIwknAZRvDXzRS/uRwjbUPbZPA/JBL/hoU1qBQhMpaA3HeqQcCnlbwwCFXKH6GI8y39LwbNi+pxivoqFM2s3vgPfPBYp5CuficOCR9ZZEWgq+32ceOuQOmu1okqdnYxEbzSSyXr3DuJyihP Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 29 Apr 2020 02:56:57 -0000 Received: by ary.qy (Postfix, from userid 501) id 940E31885341; Tue, 28 Apr 2020 22:56:56 -0400 (EDT) Date: 28 Apr 2020 22:56:56 -0400 Message-Id: <20200429025657.940E31885341@ary.qy> From: "John Levine" To: architecture-discuss@ietf.org Cc: tte@cs.fau.de In-Reply-To: <20200428190608.GN62020@faui48f.informatik.uni-erlangen.de> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [arch-d] FYI: "ISOC" "New IP" "discussion" "paper" 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, 29 Apr 2020 02:57:02 -0000 In article <20200428190608.GN62020@faui48f.informatik.uni-erlangen.de> you write: >Dear architecture-discuss, Olaf > >I hope this forward is beneficial to the IETF architecture-discussion mailing list. > >- Even though the the appended email claims that this was widely cross-posted, > i did NOT see it in any of the many IETF mailing lists i am subscribed to. To point out the obvious, there are a lot of mailing lists in the world other than the IETF's. >- I could not find any actual public place (mailing list) for an open > discussion about he topic of the paper: There has been some discussion on the internet policy list. > >- internetpolicy@elists.isoc.org does not allow Global ISOC members to > join by themselves, ... That is false, although the cruddy software interface does not make it easy to figure out how to subscribe. * start at isoc.org, click Member login at the top, and log in with your member credentials * click Edit my Profile near the upper center of the window * click the Preferences tab * in EMAIL CONSENT AND GENERAL CHANNELS click the Edit button * It should pop up a box in which you can check the lists you would like to subscribe to, with the Internet Policy list at the bottom. Check the box, also Receive Emails at the top, then Save. You do not have to tell me that this is the worst mailing list subscription interface on the face of the planet. We know. Unfortunately it is part of a larger member management system and fixing this bit is annoyingly hard. From nobody Tue Apr 28 22:59:58 2020 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 AA0083A0940 for ; Tue, 28 Apr 2020 22:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.918 X-Spam-Level: X-Spam-Status: No, score=-2.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.82, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 ypE1GqrALBt2 for ; Tue, 28 Apr 2020 22:59:52 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2066.outbound.protection.outlook.com [40.107.237.66]) (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 9BB4D3A093D for ; Tue, 28 Apr 2020 22:59:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VHPI8stbQDy1YapG5oX6oQUXl9fchrGJvNrsQbMKy7XKGXh4IbssH2HO52bmj0jNKhh4TUsFFNZkFHefm3vNgXIq1qWWhHh6w0FT2D9CiOBeSDJ9v20qs75BbsLAJgp9MoL3ltMo6FQhu6oNty3/jFdiy5F5Lh/Y7P2dpqxb2DCIOxk5qoWWZb2bLaaDv5OvAnXWcbx3tjX3NZlv8vwHvWIvoK2K7q1SwsjZWpeiUIOo3RnxrM50sq6nexRZ7fz3DLEZWcKR41BowRH8aw0ki1Roj/1XUX31IZxUBmNyWFLsIXQCGB33iH46t5DesxrechtD+tG1jd2nDl4hplLUrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+Kalt1pqlrGrCwL+pl+0I25NRazb54EZDqh5//AACZk=; b=aNCR4jL2bScQqiseogfD3k176TNQhdxMRqDqIRA5XiDEXrCrD95AKOJvJlDEPwIM7ddaYGlAbvMrCUslkFvrQHeZdsYBui+6cLMDbOkNBj7gV58gVyjWQ3aVFmx1XHOIA8DktE6hBaMR1ro6sED9ISGmwhSCVscjcWuHWYBJXcG6jjelCN5eZlMOca9Si2TWm7cKV7GOwyM1Fxtb5BwihXkuaOzlnsBeoB9eTYslVElN7ICPjxqfvVDjI7xEnYPQWIKj38Jg3yu+MmAIR490Lpj6Q2iefL1W2MWdqvh+a4UuDEwl7qgWAOBYH+Cd/wvyjYnDw4vcsE8PXz3MCHUKvQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+Kalt1pqlrGrCwL+pl+0I25NRazb54EZDqh5//AACZk=; b=BwTvJAvQNQ2ZApES1+Qjacjk1uNhPPVEOvbYv8AyVKCqEWcowDEBo+ImY/MsEm5LQFgxJ69gZRhRjY2JOgUS1dZD8bwDCMuo+n9VVuaDIcxAjbRMAWNtu0vpk06XrQE5T1Q0t41uXeKVDXK3BMeIGLFVZleMKcJ45+dUinSxmPs= Authentication-Results: cs.fau.de; dkim=none (message not signed) header.d=none;cs.fau.de; dmarc=none action=none header.from=isoc.org; Received: from DM6PR06MB6473.namprd06.prod.outlook.com (2603:10b6:5:256::9) by DM6PR06MB5724.namprd06.prod.outlook.com (2603:10b6:5:1a0::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.19; Wed, 29 Apr 2020 05:59:45 +0000 Received: from DM6PR06MB6473.namprd06.prod.outlook.com ([fe80::c1fc:dc3:b152:cf5b]) by DM6PR06MB6473.namprd06.prod.outlook.com ([fe80::c1fc:dc3:b152:cf5b%6]) with mapi id 15.20.2958.019; Wed, 29 Apr 2020 05:59:45 +0000 From: "Olaf Kolkman" To: "Toerless Eckert" Cc: architecture-discuss@ietf.org Date: Wed, 29 Apr 2020 07:59:40 +0200 X-Mailer: MailMate (1.13.1r5671) Message-ID: <3EC10BC9-119E-41F7-B0A9-5E2E39A479D9@isoc.org> In-Reply-To: <20200428190608.GN62020@faui48f.informatik.uni-erlangen.de> References: <20200428190608.GN62020@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: AM6PR10CA0058.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:209:80::35) To DM6PR06MB6473.namprd06.prod.outlook.com (2603:10b6:5:256::9) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.178.30] (2001:980:2282:1:f536:c9ce:a8f1:96e2) by AM6PR10CA0058.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:209:80::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20 via Frontend Transport; Wed, 29 Apr 2020 05:59:44 +0000 X-Mailer: MailMate (1.13.1r5671) X-Originating-IP: [2001:980:2282:1:f536:c9ce:a8f1:96e2] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 37df3ae1-50ae-462d-5f4a-08d7ec028449 X-MS-TrafficTypeDiagnostic: DM6PR06MB5724: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 03883BD916 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: QabVCh7nigii4K5PqQUGDjv/TBUF2H2VV30X2iS72xU74nBbbnw33/CjjvnP3+mCwraH/aYcOmSF+oBqc96d8Jhq8CkjKFr1cBkuTDJ1RhcLhQw9wIHfW+9F1s3TiOIySdO5Mxdic1q4wDP9lFmWVQKNy4m+ygbB77BCEQPRoj4/09GLsyHC22O6pAwbg6ORrYJXTNYwkM9oNHo+7PJMndQfyF9OB0JfYoIVTigS6IdY40J9aY0oqiR65MThjT0jn6qdZSqt47vElQScyrckrIUWe587imDKa5af4RyZeMdYOcYCB6ZEfr74bspYqwETBjkIfDCMUy0ljJHl2CQKx5VfG68U4gi/F6KdzWfOqwlo3iEd2yeKwEYwA1HBIzozeVOpdYLf/NJ6FGU1P4CNjnqO45UKYfQWdbcbK5ptz9zWT+YIylEi5m6UG8QBhm3s7Ha9jmAzKXRJHasgtiBsFN+13fJJKucTxfFVxU3uwMljgtUDuGLmEIpJvSzSKdw2LOO1x/TsA6xRGL+POyah6g== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR06MB6473.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(376002)(366004)(396003)(136003)(39840400004)(346002)(66574012)(5660300002)(66946007)(66556008)(66476007)(316002)(186003)(36756003)(33656002)(6486002)(52116002)(6666004)(16526019)(8676002)(2906002)(2616005)(8936002)(4326008)(6916009)(86362001)(966005)(478600001)(53546011); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: Z1kbYhhjc/YpLydkYF2hWYQ0ECoPWIe0DPXGg+iGQDgzVuo3nStRYa0KrUxlGgSxaWhZ+Fogpp3wr2Ai4KzhWjiL5oU6VDB2O+8+f1/bzkOZS0OwsDOEOayr28VUbFemnaE981zpuA01vzFRNScn5Surrsbuz0FYqG9LqiZlGd1pp12W0MaNq5C1FdZyVx/WwIDmshSs7C1NuvwbgVxROgCo/Vemtu3PqUV7mDAVK1RDBtKkrD5eEOUSZM6ZsGD5Zdb/fmwn2Uf44Je1NrBvK+A2MZXsXqPzWTyVgvRmBVXoo0CAyYCPi7mpeN840Gqdz8ZQvoKyVN28AdfnsHJ0JkWfcJk7X2VYs+gH6TzsKrfyQ0ACtrEY7nVsi/qyKk4LAJuZ9/guxJcR1qc/HIn2uzL9mFWSq8wX3VkCN5MFBDX8OcGoWxkNsvjzxGUleSRh4yOwbnOiF2yinDbCFGtePRv+wcDA7SwKYuc+JMdQl9dNx7DxcrqdvTbjUbtrlbpapwKje7otMpUz16677c7WByNemq6KWRBXxVrocMAXMwCgmVI7pRh2lEOhSyB9v03SD9TDQpKFc3uSgq4rQagSfamxK1eVp5QH1DArOQvjxCsQdxOJCDMpVybFWDgnc/DKB9OIf53kfzfFbhJVb44B/dQtIJC4m6mR60ACiSWGcsoOMkZKdtAfDzs2z0/sNMwNnmL0u2tSeORtZlMnbo8irVSZXGKnjvqNSsXKe4+qVWi/aCs52/Xnh2VOfg79n9RQjDE5DO7cBbw1J3nfc9k5QP3kSPeCOCDGHkW/PVM+118+ms8Bs3g4NMk696QFD82/SbM92TYkXCTjdxEMYgBn6AcSUfxkLo7zX8JpckYYcNQ= X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 37df3ae1-50ae-462d-5f4a-08d7ec028449 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Apr 2020 05:59:45.1656 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: AOLl/BIBsIJ2jZ6Rgg4NwCrsY8I+vxaO915sMHhcQmB3pGC2vVjVisQYnI9Axms5l49KP6IhgyZjyvekuIw6jg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR06MB5724 Archived-At: Subject: Re: [arch-d] FYI: "ISOC" "New IP" "discussion" "paper" 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, 29 Apr 2020 05:59:56 -0000 Hello Toerless, TL;DR: mailinglist will be available shortly. In general when the Internet Society develops a position we have a PDP=20 process by which we ask our community for feedback using a documented=20 process (see=20 https://www.internetsociety.org/about-internet-society/policy-development-p= rocess/). For this particular topic we are sill shaping our perspective and view=20 and have commissioned this discussion paper. See this paper as public=20 version of our preliminary analysis - I hope that the disclaimer on the=20 paper is clear about that. The mail alias in the draft is intended to contact the author and editor=20 - it is equal to send a mail to Chip or myself and is a way to provide=20 us - ISOC staff - feedback. It is not a substitute for public discussion=20 and intended as a convenience alias. If you feel uncomfortable using=20 that address and you want to reach any of the authors, feel free to=20 reach out to me directly. As for open discussion. We will be tracking the (ISOC) lists on which we have announced the=20 paper. A default place where members can discuss issues is the Open=20 Forum on the Internet Societies Connect platform. Those are all ISOC=20 specific, require membership, and are our default channels for=20 communication with our membership. For this sort of discussion paper=20 I=E2=80=99d agree a broader discussion makes sense. Therefore, we are setti= ng=20 up a mailing list which is open for membership and will be publicly=20 archived - As soon as its there, I will update the paper and the blog=20 with a pointer to its address, and post a follow-up here. Finally, Arch-D list is not our list and I considered our paper (only=20 slightly) off topic. So, I did not post it here. That said, and without=20 suggesting that the paper should be discussed here, we (me and my=20 colleagues) are following the discussions on this list. The discourse=20 here clearly informs us. I hope this helps, looking forward for substantive feedback once the=20 list is there. =E2=80=94Olaf On 28 Apr 2020, at 21:06, Toerless Eckert wrote: > Dear architecture-discuss, Olaf > > I hope this forward is beneficial to the IETF architecture-discussion=20 > mailing list. > > - Even though the the appended email claims that this was widely=20 > cross-posted, > i did NOT see it in any of the many IETF mailing lists i am=20 > subscribed to. > > - I could not find any actual public place (mailing list) for an open > discussion about he topic of the paper: > > - internetpolicy@elists.isoc.org does not allow Global ISOC members to > join by themselves, nor do i know if it would welcome discussion. > In fact it is not even listed on the set of pubic ISOC mailing=20 > lists. > So the nature of this mailing list seems to be secret to me. > > - NewIP-Discussion-Paper@isoc.org does seem to be just an alias for > the authors. Unfortunately, the set of recipient seems to be secret, > so i would not know the extend of people who will receive my emails, > no would i be able to know about any other feedback (no public=20 > archive > of the alias). If there was for example any US EAR entity listed > recipient on that private mailing list alias, i could be violating > US export regulations by sending technical detail explanations to > such a non-public alias. > > From these few data points, i find the proposed communication=20 > mechanisms > about that paper somewhat confusing, if not concerning, but maybe i do > misunderstand how ISOC is or is not an open communtiy like i have=20 > experienced > IETF to be. > > Cheers > Toerless > > https://www.internetsociety.org/resources/doc/2020/discussion-paper-an-an= alysis-of-the-new-ip-proposal-to-the-itu-t/ > >> On April 28, 2020 at 2:33:06 AM, Olaf Kolkman via InternetPolicy=20 >> (internetpolicy@elists.isoc.org) wrote: >> >> Dear Colleagues, >> >> With the usual cross-post apologies[*]. >> >> In the run up to the ITU World Telecommunication Standardization=20 >> Assembly (WTSA-20) later this year there has been some discussion=20 >> about a proposal called the =C3=A2?oNew IP=C3=A2?=C2=9D. It is positione= d as a=20 >> top-down architecture to solve a number of use cases that are=20 >> currently been developed in the ITU-T=C3=A2?Ts Future Network 2030 Focus= =20 >> Group. >> >> The Internet Society is carefully following the developments in the=20 >> run-up to WTSA-20. We are trying to understand if and how the New IP=20 >> works with the Internet as we know it, if it actually solves problems=20 >> that cannot be solved in the Internet, and, if the ITU-T is=20 >> developing standards, where other standards development organizations=20 >> (SDOs) have change control. >> >> In order to get a sense of the environment we commissioned a=20 >> discussion paper, =C3=A2?oAn analysis of the =C3=A2?~New IP=C3=A2?T prop= osal to=20 >> the ITU-T.=C3=A2?=C2=9D The paper helps inform us and the broader commun= ity=20 >> whilst the public debate around these proposals shapes up. It also=20 >> aims to inform and shape the discussion from the Internet=C3=A2?Ts=20 >> Society=C3=A2?Ts perspective. Eventually the debate around it will infor= m=20 >> our position and the potential further evolution of the discussion=20 >> paper itself. Note that the paper documents the Internet Society=C3=A2?T= s=20 >> emerging opinion, but does not represent a final Internet Society=20 >> position. Instead, we intend it as a means to gather information and=20 >> insight from our community on the topic. >> >> We welcome any feedback on =C3=A2?oAn analysis of the =C3=A2?~New IP=C3= =A2?T via=20 >> the email address NewIP-Discussion-Paper@isoc.org >> >> =C3=A2?"Olaf Kolkman >> >> [*] This mail has been sent to various relevant mailing lists and=20 >> featured as a blog on the Internet Society website. >> >> Olaf M. Kolkman=09 >> Principal - Internet Technology, Policy, and Advocacy=09 >> Internet Society Tweets as: @kolkman >> _______________________________________________ >> To manage your Internet Society subscriptions >> or unsubscribe, log into the Member Portal at >> https://admin.internetsociety.org/622619/User/Login >> and go to the Preferences tab within your profile. >> - >> View the Internet Society Code of Conduct:=20 >> https://www.internetsociety.org/become-a-member/code-of-conduct/ From nobody Wed Apr 29 08:11:01 2020 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 AB2E13A127A for ; Wed, 29 Apr 2020 08:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8R0aEUDFIbU for ; Wed, 29 Apr 2020 08:10:57 -0700 (PDT) Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) (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 6B4E73A1277 for ; Wed, 29 Apr 2020 08:10:57 -0700 (PDT) Received: by mail-wm1-x341.google.com with SMTP id g12so2421432wmh.3 for ; Wed, 29 Apr 2020 08:10:57 -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=5pV5Kz2eTf1H8KJGEulb6ixYu4nIdB3TPQWjJJQVnys=; b=kKAVwP9ClDuZnXM/zF3gPEi4GB6aqddT8YyYh+IeERM+AGfyRzFc87dy3MvNflQHBR YIQPynlbLBY9JKBVgQkLiIRWsdoYxA98uM6kbBdwXFtrwgaZ2I2m/Wz0npbS4Co92FYi Sfjzle5dptWU0vCFAWpmKQvOLl3G+IUvlLTIGlZO0VfIaZLHuiAQfPgFekfE3PP2CzzZ 0niOu7xn2vBAE2WGNj/fBu5x2WZ0cP2hw0TgGgtb8bRSclQFiy9n2zhexAMZ+l+BkwuU bs0kFZdIGyz9kthi1VfCANDf0GziqhaekNdZLUfVj/S6rA/qd0AYjSlYDNXwzKVTbofb 9Trw== 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=5pV5Kz2eTf1H8KJGEulb6ixYu4nIdB3TPQWjJJQVnys=; b=l03BNyTET37w21bZK9+0m+11bFXA+AF3bhKAWgh+t59EMPMjj+BE4Y/zNPK5XAlRQf gWeydlDEf0pliwa6Mt7NpmT9Z3ONISZ9OzgS1WEEXc/bODHBX74/L5j00kjRIxgIJ4Sq 1Spo3yzuQsoRu+KFbVyZ2H/fwvMjihRVd+b+xC0SzGSykeSTiqJYu3OgOJq4BK0nvxmn TFz3A0Bs67HNuB4vAMo3MZ9bVFej77hHhrp1eZFZQHXUiAFf0Q1cbXaPVJuZNZRLliEH c8rKjrNYYOiZ56xf8KubM69XGGdKeUrZM8ZKeG1fXRdoQEpcF9VQURtDm+wOeJn6j7vu HYUA== X-Gm-Message-State: AGi0PuZhUbXKzP24pmU0Acqlxqh1i/K1hl/EM2RAJEWdONQcUh7Gpo52 ufzFR1vYwBCOEyf4ckKtc+M= X-Google-Smtp-Source: APiQypJi0OnZ2gfomaT2l9iAFmX19jaBiIcSZ1BOluW2UQG/Fk+qeUqLQgWHPgIPcx08qYqOMme9tA== X-Received: by 2002:a1c:384:: with SMTP id 126mr3813507wmd.58.1588173055826; Wed, 29 Apr 2020 08:10:55 -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 u188sm8473163wmg.37.2020.04.29.08.10.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2020 08:10:54 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_F83108D0-803E-4F28-9873-48596AD0F9D7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Wed, 29 Apr 2020 08:10:46 -0700 In-Reply-To: <3d509264-f9a5-0ed4-91de-c1a5e0155194@gmail.com> Cc: Bob Hinden , architecture-discuss@ietf.org To: Brian Carpenter References: <303F494F-F06C-4E6A-99E5-089798EB56DB@apple.com> <3d509264-f9a5-0ed4-91de-c1a5e0155194@gmail.com> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [arch-d] Updates on IAB mailing lists 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, 29 Apr 2020 15:11:00 -0000 --Apple-Mail=_F83108D0-803E-4F28-9873-48596AD0F9D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brian, > On Apr 20, 2020, at 2:10 PM, Brian E Carpenter = wrote: >=20 > On 21-Apr-20 07:34, Mary Barnes wrote: >> Just to be clear, my point is that architecture-discuss was not = intended to be an IAB discussion list any more than IETF discussion list = is scoped to IESG discussion. >=20 > Not quite accurate - see below. Especially "This is an IAB-sponsored = activity=E2=80=A6". I agree. I think it is fine and correct for the Internet Architecture Board (IAB) = to have a public mailing list to allow discussion of the Internet = Architecture. That is, I would think, why we have the IAB. Bob >=20 > Brian >=20 > -------- Forwarded Message -------- > Subject: New architecture-discuss mailing list forum > Date: Mon, 17 Oct 2005 16:00:54 -0400 > From: Leslie Daigle > To: IETF Announcement list > CC: iab@ietf.org, iesg@ietf.org, architecture-discuss@ietf.org >=20 > A new mailing list has been created to provide a forum for general > discussion of Internet architectural issues: >=20 > architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 > The architecture-discuss list serves as a technical discussion forum = for > all members of the IETF community that are interested in larger > architectural issues. It is meant to be an open discussion forum for > all long and/or wide range architectural concerns related to the > Internet Architecture. In particular, it may be used to discuss and > bring forth different points of view on controversial architectural > questions. Discussions that drill down and dwell on specifics of > individual protocols or technologies are to be discouraged, redirected > to appropriate other fora, or re-cast to discussions of broader > implications for Internet architecture. >=20 > This is an IAB-sponsored activity, but IAB members will be > participating as individuals and not representatives of the IAB. As > such, postings to list must not be considered as IAB opinion, and must > not be quoted as such. Indeed, it is expected that IAB members will > disagree with each other, at least occasionally, just like the any > part of this community. :-) Note that questions asking for an = official > IAB opinion, issues requiring immediate action (by anyone), issues > related to the way the IETF operates, do not belong on this list. > Issues pertaining to IAB business should still be directed to > iab@iab.org . >=20 >=20 > Leslie Daigle, > for the IAB. >=20 > ------------------------ >=20 > [Some examples of potential topics for discussion, provided by Pekka = Nikkander] >=20 > 1. Mobility and multi-homing >=20 > The IETF currently hosts a bunch of working groups focusing on = various aspects > of mobility and multi homing. At the Internet Area, there are five = WGs and a > couple of almost-WGs charted for standards track work: MIP4, MIP6, = NEMO, SHIM6, > MONAMI6, and NETLMM. In addition to those, there are experimental = approaches, > such as HIP, and optimisations, such as MIPSHOP and MOBOPTS. Outside = of the > Internet area, MOBIKE is focusing on mobility and multi-homing for = IPsec and > SCTP and DCCP folks have had their mobility and multi- homing = discussions. The > wider research community is full of various proposals, including = overlay > approaches (such as i3) and underlay approaches (such as using MPLS = tunnels to > implement host routes). >=20 > Given this multitude of work and even partially overlapping standards = track > solutions, what would be the right way or right ways forward? Could = we design > a way towards converging solutions? How do we ensure robustness of = solutions > if we attempt to deploy multiple solutions at the same time; for = example, SHIM6 > + Mobile IPv6 + SHIM6? How do more unified solutions, like using = CGA-based > mobility with SHIM6 contrast to this? What about using HIP with = routable IP > addresses instead of Host Identity Tags (HITs) as Upper Layer = Identifiers? > Going a little bit furthermore, what are the architectural impacts of = doing > mobility and multi-homing at the IP layer vs. other layers? >=20 > 2. IP virtualisation >=20 > In the recent discussion w.r.t. tunnelling at the Internet Area list, = a clear > need for virtualisation came up. While tunnelling with clear > implementation-level virtualisation boundaries is clearly one viable = way to > implement virtual IP networks on the top of the "real" IP = infrastructure, this > issue seems to warrant some deeper digging. Tunnelling has well = known > drawbacks, and we may want to ask what would be the alternatives. In = order to > understand alternatives, if any, we need to understand better the = requirements > behind IP virtualisation, or what people *really* want to achieve = with it. Is > it merely ease of configuration, or reduced operational costs? If = so, could > there be other architectural ways of achieving the same ease or = perhaps even > larger capital and operational savings? Some people have been = promoting adding > "realms" as a first class service to the base IP. Would that provide = an > alternative solution? >=20 > While the mobility and multi-homing discussion seems to more circle = around > evaluating existing proposals and trying to navigate towards more = unified > solutions, here we seem to lack genuine alternatives and deep = understanding of > the real problem domain. >=20 > 3. Overall open architectural issues >=20 > Some IAB members have been collecting open architectural issues for a = while, > with the intention of bringing up an up to date collection of = information at a > later date, probably in a form of a WikiPedia-like web site. This = work is > going on, and we'd like to get as much information as possible from = the wider > community. Hence, suggestions on what are the more pressing = longer-term open > issues are very welcome. To given an idea of the current issues so = far > identified, here is a partial list. The list doesn't say much = without > explanation, but it may give an idea of the type of issues we are = looking at. >=20 > End-to-end connectivity > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The original value of the Internet, the ability to connect to any = host with > any protocol, has eroded away during the last decade. While it is = impossible to > get back to the original mode of operation, largely due to security = reasons, > some form of better-than-today end- to-end connectivity would be very = valuable. >=20 > o Living with NATs, filters, and firewalls > o Introducing identity realms or domains > o Evolving the application interface (API) >=20 > End-user experience > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > o Transparent security > o Zero Configuration and Service Discovery >=20 > Balancing Accessibility, Security, and Privacy > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > o System for plausible sender identity for received packets > o Secure self-configuration > o Integrating security across the stack > o Dealing with bad traffic >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss --Apple-Mail=_F83108D0-803E-4F28-9873-48596AD0F9D7 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----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl6pmPYACgkQrut0EXfn u6ifOwgAh8oFNqyvym1QGj30jou+nIcvDxTl+IXSeDAj22uUbM+IveX492KnofX9 tk6CMPGwz1rlccxOWru5kXCavnNY7B+01CfLbrZjakvsZqonsHfTRRsg0ZbcPRfN fCKyh20xNVDAOWhGcWkP6QEezZPIaeiRNJruHTI5wqDXkK20GFO4IXtUlRCdyxTs qLyGk8Dh8YytOg2CuXo3NvcUrlqUjmlDG/TAcZ33DSeRPEtYaU+9hkqIC7A6e5ga mBOrpityc44jQT/xQbCmiqzGnC0AUc8MjhvK9fH4p2faIXmMfeBnZExHM9AYmqEc PZ9mdAYVSTQtqdDGgvzdJWsMx/V86A== =5ZOT -----END PGP SIGNATURE----- --Apple-Mail=_F83108D0-803E-4F28-9873-48596AD0F9D7-- From nobody Wed Apr 29 08:54:00 2020 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 3C7A53A00C9 for ; Wed, 29 Apr 2020 08:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.918 X-Spam-Level: X-Spam-Status: No, score=-2.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.82, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 OGtE3-y1NwTy for ; Wed, 29 Apr 2020 08:53:56 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700067.outbound.protection.outlook.com [40.107.70.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 D715F3A005B for ; Wed, 29 Apr 2020 08:53:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZadsgM9UAjDt9P1q9tfgGA65c4DHU4qKpdbK9Y+y0ZPkNEIOQJFKprsvwFunjNSlfjudIjz4rnS/FVSapyhoVS+DruzhnYdxCtEifUK6QVoTsCVelnp1ycqjhCv67EkDc1i6Hb6fvFeyiBO6HkGH656xOu3klhFnWX179tGqqewW1i6Z6K2quq0s1M9i7ZWCnnOlnw1WK6h66CdUwH5DcuoVl8N9eutsnYa4IBwBSJXc6WIivIa6RO/lsQkqngcLYtOA3ALlX6b6wnTiVguYqlTFVXuCih3MQBIYxoXt90XoD4GgF0JUg4RbVhAM0vs+mYmAtYSFIVk16d5yNWdRKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jMI+cg7gD1RwFM9q9dtzzHViY+gEEjfe0913hmyFgP4=; b=GVSBnLsRhOzKNFhAlIuBkt3dTuAUengUrVvpFX9MXU2DcPW+R7GchKLZ0FaTnZVEVkMLEruOaDwEbu0Fpta4k4RCffNwjNUVC/bUD+2A9A7hpwI6L2jCnFtApWExKaBDFHwJPLU0IgwmkLjhzOQzje8oaQBH6DAbHXn0ynlUEAi4n+MTPEOxXdgWz8Kk72asS8MOK9tMw2IKbJoMKb7LUU5i8Zg56TMedGefPYUvGL8XyitELbDkaF2FAP5tWfK+2eGNnr8wfHqQqkCv9FdSyYTwG2+ODznWg5puiCchqL6lrPI9VjwyhJvXROGFMqRUffvYwJCycMr2Vxn9kQdIBQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jMI+cg7gD1RwFM9q9dtzzHViY+gEEjfe0913hmyFgP4=; b=GRbIZtozZbLotUOGqZFkJQ+fqj2Jbe9ApoTMx9dhfklCxfwXHiG3igIZ0hJ0SyduGBGiBBS/xoV+/H83TuuSBn4gC7SxIb9FrOPy9XU/ib/sVJvJt6eAIGW1F/ndJEShtIi680lixGwYKScZe9xfQrgwWCMtrSpAUk9yaqfhCnk= Authentication-Results: cs.fau.de; dkim=none (message not signed) header.d=none;cs.fau.de; dmarc=none action=none header.from=isoc.org; Received: from DM6PR06MB6473.namprd06.prod.outlook.com (2603:10b6:5:256::9) by DM6PR06MB5803.namprd06.prod.outlook.com (2603:10b6:5:1b0::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20; Wed, 29 Apr 2020 15:53:54 +0000 Received: from DM6PR06MB6473.namprd06.prod.outlook.com ([fe80::c1fc:dc3:b152:cf5b]) by DM6PR06MB6473.namprd06.prod.outlook.com ([fe80::c1fc:dc3:b152:cf5b%6]) with mapi id 15.20.2958.019; Wed, 29 Apr 2020 15:53:54 +0000 From: "Olaf Kolkman" To: "Toerless Eckert" Cc: architecture-discuss@ietf.org Date: Wed, 29 Apr 2020 17:53:53 +0200 X-Mailer: MailMate (1.13.1r5671) Message-ID: <3780B464-D8FB-455E-B3B8-4B91B79AA9AF@isoc.org> In-Reply-To: <3EC10BC9-119E-41F7-B0A9-5E2E39A479D9@isoc.org> References: <20200428190608.GN62020@faui48f.informatik.uni-erlangen.de> <3EC10BC9-119E-41F7-B0A9-5E2E39A479D9@isoc.org> Content-Type: multipart/alternative; boundary="=_MailMate_6AABD922-106E-4B9D-9CDA-B5E16B4032EF_=" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: AM6PR0502CA0069.eurprd05.prod.outlook.com (2603:10a6:20b:56::46) To DM6PR06MB6473.namprd06.prod.outlook.com (2603:10b6:5:256::9) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.178.21] (82.95.132.144) by AM6PR0502CA0069.eurprd05.prod.outlook.com (2603:10a6:20b:56::46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Wed, 29 Apr 2020 15:53:53 +0000 X-Mailer: MailMate (1.13.1r5671) X-Originating-IP: [82.95.132.144] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: eb7bd9c1-ff03-45f6-b06a-08d7ec55851e X-MS-TrafficTypeDiagnostic: DM6PR06MB5803: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7691; X-Forefront-PRVS: 03883BD916 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: r+oIGnLYBvDWpSjOFrd/lmcKVp3FkZ1SLdkoQbnmqdx9c7dXV+XVHQqVSBkq4alXHMlQOc+cdLCKy/05CmGc06IezqGrYHTvHwhj1g0WidwTl+Atc2C5OAo/j9hoNoDdNFUv0mtHRiEevaQ9g1bWZRJKWky+pRkCqZzgsaBOLAEfXIMyqTyrb/R8VbpLOubN1H6PHC97cSh5ZzfVqAfojhVe5fn8XG+ZDlZn/ifN950MY2gSDlKypX5NrEOGx9usqZg8feK/yzLQ3A6cCaKvqcCv246F53jA0Cldf4rlqXeNju5WE2WaqsyUFZXLKPkh4s4OGU5Xof+ZEm5tFQhrI5ADi5zthxQQw3o68kkpL0ExMXVbn/n8VMgefdgC0LC+RW36bRWDd2X0SZZVS2y/19tWATZ/DPhfBduvbAKlJbXstieJ1wLCW2TG4l9KUiUrR+EhgupPM6+1ze6w3gT2UFHuRWZkFRw1pKVblms5/zfJg4Wd3v9cCl0pnQHMXMoJnoT3mHybZkkfMdXG5qfXeqVsNmCRCcR4r4ISQma91hLk95mTxXUsk7DqhgxQXKXb X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR06MB6473.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(366004)(136003)(376002)(39840400004)(396003)(346002)(966005)(6486002)(478600001)(16576012)(5660300002)(2616005)(956004)(86362001)(53546011)(6916009)(316002)(186003)(33964004)(26005)(36756003)(66574012)(52116002)(16526019)(8676002)(4326008)(2906002)(66946007)(8936002)(66476007)(33656002)(66556008)(72826003); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: APlGmUv54Ej9g9LUfdNIRoKD8L4HqHJ1Wv8ZijpJS/FJwU/o+fBBH2jTo4iAkVIbdIFkg/tqjSioDUEQ+SEeBddFOkBGSP18mCVP+KrmYhJoF0+s9zM0iegqPpfjO3WGeqzkek6UKbaepBhRCV4Mrrumc4+nCMP6u5JL9B8FgH3LVgk9I7n3TASG9KdVGOI/E2MmSBvaQd4CVeJpm12DPrjn/hwVZk/bJJXBz04cG7jS+WJu7PZeauhyl29nDtou0hVjSPlu2Qm9AK3VmSTwiae0+4/8j85QpEWi3ZHvVUDplkj8ibtNLCFCzSvc5Km14pB3NB/jZ49mpJGfCLKoxdBI4oQ5n1qzgayAC6pWozDMkwz4iN1Mn+PnlhYUkAPBPvUQosxHNeuZ4xeBvL3Twd3VPnnEI1iBF5zLqcuxaGyw0N7zYQ+e5Q+Uhbugqhu3041UV4SqaoZkt53P0DvEb/Hjv6leYgSRlK0ILyoPPUtHp4Eb37oPgc77X1fpN2ZR1HB0nvZefbGYpsVgA36+1hVwlBqdc3z3VGhW8xHvr6OWYdO1SwPeBVUwgAOdOYciQ0hR0pgubIt/8dDV0PnPes1PbzPZfaNkT4/F0jQzTHOBiaSfUVsoKzyHU7qzvddCxTzZNtjaoRR57oahdOT9fbi12/ub9EVsL+4XbTJcy0pAgu3qFbTetKSaW9cPYQWBpVJjlYGKL1Cv4WZHlLcBzGcL2tQWypgG7v/rOVjl4g5MB0e1NfPD86YUX2Oqa9/iaIOGlpEW4OD6OyzQLczl4+1w7cQ20M7/Yx3MLqH6nOg= X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: eb7bd9c1-ff03-45f6-b06a-08d7ec55851e X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Apr 2020 15:53:54.7265 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Oh1TUIvtCmkCD5RFvg58p0TuX/+FuvVh7fcbb/bUQyvkubmoZyhJDjMD++d6fzS+zoqMne0zFkYm1UPO4t2X1Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR06MB5803 Archived-At: Subject: Re: [arch-d] FYI: "ISOC" "New IP" "discussion" "paper" 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, 29 Apr 2020 15:53:59 -0000 --=_MailMate_6AABD922-106E-4B9D-9CDA-B5E16B4032EF_= Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit On 29 Apr 2020, at 7:59, Olaf Kolkman wrote: > As soon as its there, I will update the paper and the blog with a > pointer to its address, and post a follow-up here. There it is: discussion-papers@elists.isoc.org The blog already refers to the list, the paper itself is being updated. —Olaf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Olaf M. Kolkman Tweets as: @kolkman Principal - Internet Technology, Policy, and Advocacy Internet Society https://www.internetsociety.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --=_MailMate_6AABD922-106E-4B9D-9CDA-B5E16B4032EF_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On 29 Apr 2020, at 7:59, Olaf Kolkman wrote:

As soon as its there, I will update the= paper and the blog with a pointer to its address, and post a follow-up her= e.

There it is: discussion-papers@elists.isoc.org=

The blog already refers to the list, the paper itself is be= ing updated.


=E2=80=94Olaf


Olaf M. Kolkman
Principal - Internet Technology, Policy, and Advo= cacy
Inte= rnet Society Tweets as: @kolkman
--=_MailMate_6AABD922-106E-4B9D-9CDA-B5E16B4032EF_=-- From nobody Wed Apr 29 09:12:19 2020 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 EC0043A13D1 for ; Wed, 29 Apr 2020 09:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.82, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.onmicrosoft.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 C4n3XpFhhVcP for ; Wed, 29 Apr 2020 09:12:04 -0700 (PDT) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110042.outbound.protection.outlook.com [40.107.11.42]) (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 A65383A1383 for ; Wed, 29 Apr 2020 09:11:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Eaupy7V9zO/xlcDLdgvAse3gYco4cFp/Dy5/86n3gapYjgcZm7+lHn/5zNV67QT+tvRcW5IT15e6PQGG/KWRTr8RDpQ7Dm/Ayeu9RwrYXg64sxnbIIjdHD75wzfYPAmRNYDfzHzeqD7g+8dQ8VCo9e3cdZOmw4MmKc3EWkexAa85ZA0iimzP2EB+yyw7b4xM0u9o+fI2qs/HtJRYoavDsxb4B82eYL69PeQpYHdoMBu2O7SxjRo0ra1/VWY4aScFKTVepBOpPhul4WvyItjNE5kgNUVrO7ZyjZoFdCz2D2MobzagRTjK8KIbXP+Ryakb5fpoPbz38+wkivct6dBIVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ciGTyDaP0ntO5rhDSSLxOKd2S5zqb9crCOi5MUePyUA=; b=aKgPKN73FjDpnjPbXdFjMwDuyXKbF7xGRvuC0GqFC3Grd6be+ygqvpDWqboshC5ZcednnG+QOtMuVnHxav0ZlJ8I5r2BzXdakTw61EWWiDNhZZi1Phi0/YlWB6G4XhMPnQRPNulLmOQqHQkan8X17gTPuDlVEbHSUQkdBXhphFUrvE4dwKHluTWUFDuMVQWIPqGLBLxn7nQe/RRqkAWjMFT59Z0EHojOXNJzbnT0nKvYZifaqrwu46ugzzxSTf+7lx9LdS/iLrIsytZ7tu9KDsJ3RszkloPdvnqglz7MlIiQQxUws877+ZhrPuD05UKHCw0BMbYBHpaqKhagGs5ARA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ciGTyDaP0ntO5rhDSSLxOKd2S5zqb9crCOi5MUePyUA=; b=NfFMPIBioOr1CpI6R9/HdiwFGP4ueUuVwY5mm4/SHf9XO+MZthYoJK+xoRSl68ytHNa7wZ9GPTWRtLAkJtHUQyWNheqbGFIL7kJZYUzNxG8ewrvMzS3unJj5kLii/aP1ur/U7OO7k3Hz7CnmjYs9n1Q+Ye7SMiomx+tYcEL4mmA= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (10.166.85.15) by LO2P265MB0637.GBRP265.PROD.OUTLOOK.COM (10.166.105.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Wed, 29 Apr 2020 16:11:43 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::683d:f224:e857:746a]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::683d:f224:e857:746a%5]) with mapi id 15.20.2937.023; Wed, 29 Apr 2020 16:11:43 +0000 From: Andrew Campling To: John Levine , "architecture-discuss@ietf.org" CC: "tte@cs.fau.de" Thread-Topic: [arch-d] FYI: "ISOC" "New IP" "discussion" "paper" Thread-Index: AQHWHjhxiVGdUCo0wk2aJHfI+zbk4qiQQwkw Date: Wed, 29 Apr 2020 16:11:43 +0000 Message-ID: References: <20200428190608.GN62020@faui48f.informatik.uni-erlangen.de> <20200429025657.940E31885341@ary.qy> In-Reply-To: <20200429025657.940E31885341@ary.qy> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: taugh.com; dkim=none (message not signed) header.d=none;taugh.com; dmarc=none action=none header.from=419.consulting; x-originating-ip: [2a00:23c4:a499:2e00:bc12:c64f:3fad:1ac0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5c1b7e00-d625-460a-9a44-08d7ec58020e x-ms-traffictypediagnostic: LO2P265MB0637: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4941; x-forefront-prvs: 03883BD916 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(366004)(346002)(396003)(39830400003)(136003)(376002)(66574012)(66946007)(71200400001)(52536014)(86362001)(76116006)(66476007)(508600001)(966005)(66556008)(66446008)(8676002)(4326008)(44832011)(64756008)(2906002)(33656002)(8936002)(9686003)(55016002)(5660300002)(53546011)(316002)(7696005)(6506007)(110136005)(186003)(46492006); DIR:OUT; SFP:1101; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: w4gW0kNl20ujE9hWDeWjJwtsgpL6w+ZO980xXH4rNfuNIx8eZWJwFGB9fSWHpy6VQGTntb4wkJVw6VkJsNCPwHccH5/lO/9HOwMIXmBGVAF/R17km8SYevgb0n2s1B/o7HKXJ97z03snOACs1Rkue80cNAb3+12FELng7ZyWFi3CYoPWkD6xV5p7jP28H9HT+RQVqyhTXxXqj3HcD/20/oa/UEis0y5oPauHltQcw+hfz213a3rH/KYjqTUwCXx4F5tBvV877R7+ATAj5McSq7g37E9dxBU0i3UZIQn/Gu4unBQX+c3vFb3geiARP35sp3to+O1cysf9kOzA7laaMgeCa2F8VVUPGr8s6RmKi+zcY379qmK1ZIg/Q5Ax9/1y/hZpcxExGC/LRcnw/U1xcfbBVzVQlxEA665XkSX+x3yPK9Z/mU+RjcWjNgStnmmSXnXSY8SWEGAr2FeXjii94jtYdcQTfNPyvacmSuuXBvC5gpK9Di9BPtgGuWajKtcL76dwlWyJV1xOJOXUepf7N3wZtB63pmC2QW4pGZ7HACBPS4UUk2PiezvK1pv4Yhbq x-ms-exchange-antispam-messagedata: olSM0oeQPkYuUZWgdIvdkO6uqwHNWpHVLWQPR9UEMpRtHu2cXOks544hKFSwTblyVrBeg95guWiPUunZZaAIQAVwoEwa+5wzCRlh13K6jNlsa+xNN32l219TyrSio3Sd1knDYc8OHc4+sco8uHzkEfgIIZgDyeGEfDWgaU/hQAxKReHt1jaDcSBDS+opBaPuH7YuKzxLIpsBD0yDTVbPp82arMkRxrPBRx61ON5oo++1DH9efhjKlhGHs9KXddVLuwIWe0oSvT7sBf/Kv5Bcp5Q8jQeGjMfevq+kp32Sjrq2laI70BWHssY8qV62XUTi2YyUe96U1ygLDy98QTEoHBEBoQ+ySSZJT9UTc0qeLYrZsr8EN2UOiJz++deK2pVnzO8w+sqjGezXPK+fgv1fOMYedGZTcIoKuWH0vCnUFIPLpsQdyUDj5NXu7J+lAJVYIAEZzhp5mir7ZxS9h5oG8V/DUEuJWfOq5KuTPaM/Brflh8uGxthAhbhgXMFxqEWY9wwC/X53bKXhpYpJdw7oVxQN0EKdr68rmm4C0zo3aCFNVJmkT+eL42QpyNWmr8SLxAdDARXuOGlNe2wJKaW3eox0URA5/8HDI9pfHXK/nhXPRb1vAsqw1fu7vhx9Lfa3g/Jli7zQorxiCAzWD8nmY1g38jrATyE6Yn0gtFFTd+UhOt96K9lo+l3B8s77Er59qgq8jzFqj3lx5kDZgk9Ht47PQHNY0H1lfbRvMKDOXzqUu/ry9ZQB0zcnR2O7+xk9QnJOX2OnwdpaGLRpAwPu6GJZ0Oa3w0HYBZR/3KAWYFGhY+49of6poYO2jVcarmYW+kf3XnyUi+xLAU5+T2Mo9GAP9t9AMFBHF0/4UGjYP9yD0564F5PA9FmjtL1NgXsG x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-Network-Message-Id: 5c1b7e00-d625-460a-9a44-08d7ec58020e X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2020 16:11:43.1433 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FcMxiKOwACe9QM1qhheYgQSb+8BbUtnJ2AZzQzY55jnvMf9VoDT28FaR/DHrGLqJ0uV4op5foTzRrs5MLSuymFeY/+vtV9hhuvb6aMs+7yI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB0637 Archived-At: Subject: Re: [arch-d] FYI: "ISOC" "New IP" "discussion" "paper" 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, 29 Apr 2020 16:12:14 -0000 T24gQXByIDI5LCAyMDIwLCBhdCAwMzo1NywgSm9obiBMZXZpbmUgPGpvaG5sQHRhdWdoLmNvbT4g d3JvdGU6DQoNCj4gSW4gYXJ0aWNsZSA8MjAyMDA0MjgxOTA2MDguR042MjAyMEBmYXVpNDhmLmlu Zm9ybWF0aWsudW5pLWVybGFuZ2VuLmRlPiB5b3Ugd3JpdGU6DQo+Pi0gaW50ZXJuZXRwb2xpY3lA ZWxpc3RzLmlzb2Mub3JnIGRvZXMgbm90IGFsbG93IEdsb2JhbCBJU09DIG1lbWJlcnMgdG8NCj4+ ICBqb2luIGJ5IHRoZW1zZWx2ZXMsIC4uLg0KDQo+VGhhdCBpcyBmYWxzZSwgYWx0aG91Z2ggdGhl IGNydWRkeSBzb2Z0d2FyZSBpbnRlcmZhY2UgZG9lcyBub3QgbWFrZSBpdCBlYXN5IHRvIGZpZ3Vy ZSBvdXQgaG93IHRvIHN1YnNjcmliZS4NCj4gKiBzdGFydCBhdCBpc29jLm9yZywgY2xpY2sgTWVt YmVyIGxvZ2luIGF0IHRoZSB0b3AsIGFuZCBsb2cgaW4gd2l0aCB5b3VyIG1lbWJlciBjcmVkZW50 aWFscw0KPiAqIGNsaWNrIEVkaXQgbXkgUHJvZmlsZSBuZWFyIHRoZSB1cHBlciBjZW50ZXIgb2Yg dGhlIHdpbmRvdw0KPiAqIGNsaWNrIHRoZSBQcmVmZXJlbmNlcyB0YWINCj4gKiBpbiBFTUFJTCBD T05TRU5UIEFORCBHRU5FUkFMIENIQU5ORUxTIGNsaWNrIHRoZSBFZGl0IGJ1dHRvbg0KPiAqIEl0 IHNob3VsZCBwb3AgdXAgYSBib3ggaW4gd2hpY2ggeW91IGNhbiBjaGVjayB0aGUgbGlzdHMgeW91 IHdvdWxkIGxpa2UgdG8gc3Vic2NyaWJlIHRvLCB3aXRoIHRoZSBJbnRlcm5ldCBQb2xpY3kgbGlz dCBhdCB0aGUgYm90dG9tLg0KPiBDaGVjayB0aGUgYm94LCBhbHNvIFJlY2VpdmUgRW1haWxzIGF0 IHRoZSB0b3AsIHRoZW4gU2F2ZS4NCj4gDQo+IFlvdSBkbyBub3QgaGF2ZSB0byB0ZWxsIG1lIHRo YXQgdGhpcyBpcyB0aGUgd29yc3QgbWFpbGluZyBsaXN0IHN1YnNjcmlwdGlvbiBpbnRlcmZhY2Ug b24gdGhlIGZhY2Ugb2YgdGhlIHBsYW5ldC4gIFdlIGtub3cuDQo+IFVuZm9ydHVuYXRlbHkgaXQg aXMgcGFydCBvZiBhIGxhcmdlciBtZW1iZXIgbWFuYWdlbWVudCBzeXN0ZW0gYW5kIGZpeGluZyB0 aGlzIGJpdCBpcyBhbm5veWluZ2x5IGhhcmQuDQoNCkkgbm90ZSB0aGF0IGEgcHVibGljLCBhcmNo aXZlZCBtYWlsaW5nIGxpc3QgaGFzIG5vdyBiZWVuIGVzdGFibGlzaGVkIHRoYXQgaXMgYWNjZXNz aWJsZSB0byBub24tSVNPQyBtZW1iZXJzLiAgSXQgd2hpY2ggY2FuIGJlIGpvaW5lZCB2aWEgbWFp bG1hbiBhdCBodHRwczovL2VsaXN0cy5pc29jLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc2N1c3Np b24tcGFwZXJzLy4gIEhvcGVmdWxseSB0aGlzIHdpbGwgZW5hYmxlIGEgbW9yZSBvcGVuLCBtdWx0 aS1zdGFrZWhvbGRlciBkaXNjdXNzaW9uIHRvIHRha2UgcGxhY2UuDQoNCkFuZHJldyANCg== From nobody Wed Apr 29 10:39:02 2020 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 8DFD93A14B3 for ; Wed, 29 Apr 2020 10:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 CKSmc9hmpka2 for ; Wed, 29 Apr 2020 10:38:57 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E98C3A14B1 for ; Wed, 29 Apr 2020 10:38:57 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id E5972548046; Wed, 29 Apr 2020 19:38:51 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id DBF0A440041; Wed, 29 Apr 2020 19:38:51 +0200 (CEST) Date: Wed, 29 Apr 2020 19:38:51 +0200 From: Toerless Eckert To: John Levine Cc: architecture-discuss@ietf.org Message-ID: <20200429173851.GR62020@faui48f.informatik.uni-erlangen.de> References: <20200428190608.GN62020@faui48f.informatik.uni-erlangen.de> <20200429025657.940E31885341@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200429025657.940E31885341@ary.qy> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] FYI: "ISOC" "New IP" "discussion" "paper" 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, 29 Apr 2020 17:39:00 -0000 On Tue, Apr 28, 2020 at 10:56:56PM -0400, John Levine wrote: > >- Even though the the appended email claims that this was widely cross-posted, > > i did NOT see it in any of the many IETF mailing lists i am subscribed to. > > To point out the obvious, there are a lot of mailing lists in the world other > than the IETF's. ;-) Not on the planet i live on. Kidding aside, my remark was primarily an explanation for forwarding to this list. > >- I could not find any actual public place (mailing list) for an open > > discussion about he topic of the paper: > > There has been some discussion on the internet policy list. > > >- internetpolicy@elists.isoc.org does not allow Global ISOC members to > > join by themselves, ... > > That is false, although the cruddy software interface does not make it easy > to figure out how to subscribe. > > * start at isoc.org, click Member login at the top, and log in with your member credentials > > * click Edit my Profile near the upper center of the window > > * click the Preferences tab > > * in EMAIL CONSENT AND GENERAL CHANNELS click the Edit button > > * It should pop up a box in which you can check the lists you would > like to subscribe to, with the Internet Policy list at the bottom. > Check the box, also Receive Emails at the top, then Save. Indeed. Thanks a lot. I was mislead by the instructions here: https://elists.isoc.org/mailman/listinfo/internetpolicy And this one here doesn't accept isoc username/password: https://elists.isoc.org/mailman/listinfo/internetpolicy Maybe fix up those. Also it would be good if those isoc lists could be listed here https://elists.isoc.org/mailman/listinfo even if that listing would just have to point to an info page including the instructions you gave above. > You do not have to tell me that this is the worst mailing list > subscription interface on the face of the planet. We know. Nah, it's ok. Just the maze of URLS attempting you not to find the right place is in need of improvement. > Unfortunately it is part of a larger member management system and > fixing this bit is annoyingly hard. For someone coming from the IETF side and knowing mailman, fixing up the mailman URLs above to show your correct instructions should be all thats needed. No need to change that member management backend. Thanks for helping! Cheers Toerless From nobody Wed Apr 29 22:40:55 2020 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 7C5363A073E for ; Wed, 29 Apr 2020 22:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ooWG6-4gNMR for ; Wed, 29 Apr 2020 22:40:52 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 4B4493A073D for ; Wed, 29 Apr 2020 22:40:52 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id q124so2231823pgq.13 for ; Wed, 29 Apr 2020 22:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=5x61UB1HcvbcFA69jGm5BYc3+ePOMrsS2kK/+SuaxzE=; b=uqYg+4IRr7efyrxVEngQRIf4hn22cZzsZqkk793NIDRTyJZ0ngAOYkfcNSBLxUXirL GWR2KyKQzv2vv09N2Myn3riaAwdBKfmxbv/sfAjb1PhO++R6idnpx6PhabHwUSqeSsXP bI5a/GxKnm3a0gQB/kLGIauonlFucHsuOCbvl7ONMhri0f1WiN+VTRtPuzY7TvKL+kFw svfed+M5xk6hwOgmSkQ8J6OJ1beqj/Mo97jSrXETktGmX2gRShX4VbaaFuEah1U/0xaf 9nliZWwy9RlzEMdwkgz8FE4QrdezU0OCzEgw/SwxEjILCJsAAhXJlOmqZQigV+gJ7+1o 6RGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=5x61UB1HcvbcFA69jGm5BYc3+ePOMrsS2kK/+SuaxzE=; b=i3F2BhQ2/i6fJHSxNYNFFHVZBp67Kk5kWEGFx+S7FibaxpOe/poypa6+YPL6Q5WXv8 2Lf865yruf+f9ydpW4HUa8Nm2395WMx2Nx0FFr4IITkHlj4h729p2ShRJe1eEHFquPgn hBkymhOMsoLipV6k7I62GsVintyb43zI3GEvrszymmsHBeJP37gKNI8pXjuCnpkfKG7Y D8SmXPgSxVSBCQU+7DzVfB7B3qcAjNA9fBmnty2f2ZIXs8WfeAQ8xqS8QRgnLAIsOY2I eFApGXHvWswKkAWiFMEGWUW9nbFo4fdwZNM+qjFFP6ZvQP62b0vmJTGuPv5GOM3vy65F HFhQ== X-Gm-Message-State: AGi0PuagNjY+yYJmDkFDzp54ovy9O4MkbjSdZVd1sQvH8qbtUmLOH7a0 jiL6hDHgxuPy0nGDqEPRmm43NwPWk1U= X-Google-Smtp-Source: APiQypJulsTaHzwbYM+n13cmjY+RhnT+zfSo/8JdZxEq5SYdfrxfsH/CItaFjEwejeC2eu9B0gVm9A== X-Received: by 2002:aa7:85d3:: with SMTP id z19mr1823285pfn.215.1588225251200; Wed, 29 Apr 2020 22:40:51 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.84]) by smtp.gmail.com with ESMTPSA id gv24sm767444pjb.6.2020.04.29.22.40.49 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2020 22:40:50 -0700 (PDT) To: architecture-discuss@ietf.org References: <20200428190608.GN62020@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <096a7bae-3997-5c77-a2c0-4d5911c0c89f@gmail.com> Date: Thu, 30 Apr 2020 17:40:46 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 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: "ISOC" "New IP" "discussion" "paper" 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, 30 Apr 2020 05:40:55 -0000 Where to Discuss a New Internet? https://www.cs.auckland.ac.nz/~brian/InterOmnesNovasRete.html Regards Brian Carpenter From nobody Thu Apr 30 04:23:03 2020 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 64B3B3A0A07 for ; Thu, 30 Apr 2020 04:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.717 X-Spam-Level: X-Spam-Status: No, score=-2.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.82, SPF_HELO_NONE=0.001, SPF_NONE=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 9QgbsazhhRTA for ; Thu, 30 Apr 2020 04:22:59 -0700 (PDT) Received: from know-smtprelay-omc-6.server.virginmedia.net (know-smtprelay-omc-6.server.virginmedia.net [80.0.253.70]) (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 14CF83A0A02 for ; Thu, 30 Apr 2020 04:22:58 -0700 (PDT) Received: from [192.168.1.35] ([79.72.166.100]) by cmsmtp with ESMTPA id U7HMjCfbkEIzOU7HMjB2wo; Thu, 30 Apr 2020 12:22:57 +0100 X-Originating-IP: [79.72.166.100] X-Authenticated-User: john.s.grant@ntlworld.com X-Spam: 0 X-Authority: v=2.3 cv=HZs6sBM8 c=1 sm=1 tr=0 a=KdT9lSvhpbvUFdjzdD3cHA==:117 a=KdT9lSvhpbvUFdjzdD3cHA==:17 a=IkcTkHD0fZMA:10 a=qNp_YjjoAAAA:8 a=le6d79QuAAAA:8 a=pKAOfxU6yZDj6g9ipNUA:9 a=QEXdDO2ut3YA:10 a=g81M8DewQ1UA:10 a=khMt8xYRSkkA:10 a=GPpaJ-c28cifDO-wfJs0:22 a=QbAMNLWdp4a7deKPGBBn:22 To: architecture-discuss@ietf.org References: <20200428190608.GN62020@faui48f.informatik.uni-erlangen.de> <096a7bae-3997-5c77-a2c0-4d5911c0c89f@gmail.com> From: John Grant Message-ID: <0dc78987-2872-8b8e-35f9-0cbdf9675b7e@ninetiles.com> Date: Thu, 30 Apr 2020 12:23:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <096a7bae-3997-5c77-a2c0-4d5911c0c89f@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-CMAE-Envelope: MS4wfOFYniZWvsor9Vmmi7OmdfwihOo7af/bCqTtOuY7dzkh6Yk4icB3w1U2QXwo2c3J4osoZuR8Y1jutBIntdZvolx1JImLx81jLF1LZzMV3HEgjOtXJog6 BzeAy90a9hLiHbVFvSrY1SGEdnaMvyQ0q+tLSFBmVCINmxGqYgHVr7yTu8Mi2qmdVoBru17G93TI1g== Archived-At: Subject: Re: [arch-d] FYI: "ISOC" "New IP" "discussion" "paper" 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, 30 Apr 2020 11:23:02 -0000 On 30/04/2020 06:40, Brian E Carpenter wrote: > Where to Discuss a New Internet? > > https://www.cs.auckland.ac.nz/~brian/InterOmnesNovasRete.html In what way does the NIN press release show that ETSI has blundered? Is it referring to the expectation that NGP could take non-IP into IETF? -- John Grant Nine Tiles, Cambridge, England +44 1223 862599 and +44 1223 511455 http://www.ninetiles.com From nobody Thu Apr 30 06:49:20 2020 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 C58DF3A0645 for ; Thu, 30 Apr 2020 06:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.82, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.onmicrosoft.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 Qj51SV6MT5q4 for ; Thu, 30 Apr 2020 06:49:14 -0700 (PDT) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110059.outbound.protection.outlook.com [40.107.11.59]) (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 850BC3A0765 for ; Thu, 30 Apr 2020 06:49:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eDrfoS6wxLFZgUz32MOioTOyuPgK4nK2tv2LqRfuc/Z/5Z3aMD92Ymu6qmgKv5f7DIxHPE2hHJHESHY398adC/OWlgmISnAaYubzsyRm0+ZMjSop+obn7xiHBe0gGGq70H8gyD9TgFwVlA7k3GdPl2Z3H+OZgL2JCHJzX4GRna0FWALCZ1wmmQ3ovRuXvUNsOW0AVfdNo6A/hz8xCFakxNT2gp6BA5BcaVXUpg2WJhYS5fQxRX2JrqPhY0YI8x5JZomxcDyD+j8ufFm/zxxdeMY943LtXRhpGDH0XVaOBeIRKp/JUAaov9ksXhgfoPTur3KTQTWfraTrG8UjAvVIhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nJV4ABL+ALxhnNfwPcpFwuL/EWirPxgiurTNzewRWh8=; b=nIwqmVfDMO3oxHYfx/2CBOK3kjlwO491UCRtiIrF4nazYK/HnjNEM2pkFqE9wksYsmjV5IKNOJU1CAWYVwirDq8Jfiip3etaptJnGRS1CjZd+ZUA0Ib/h877DtzZn7lZyXCeYptTFn1p76ligjjdIVqDUCWQ5uhnKSQaAjdCoZRG+jDLcN3qb3XF1LmFMuyH7VRaPSiVJWjA1bZgwsbZgOLVx40DvyGpRtda7Am2mZyHAy+c3QZKRbq+48sr1+L0zzIFc26sOmhUa0+HxBf5FhD0IhyhRe+57FpqSYGL7pys/OTTDDf5bKbleLwMPjPVoJZENi/zgNxdTHMUp3lA5Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nJV4ABL+ALxhnNfwPcpFwuL/EWirPxgiurTNzewRWh8=; b=OBYt3OleRODT3Fnwy3qkpqw9QOoAtu+2grUUC3qyc7KQNXMDlWWhsD5lUv9nIlhSXEI27XGzSCTWFZJR3aX6EINlhRzogcKVaAw5BBPKSWaH0Fi1taJVMOnVnPo/2R2a8csVRmQVVQDaIr7dECWc8ZQr6epgaL8PDO4ddIUaMKY= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (10.166.85.15) by LO2P265MB1022.GBRP265.PROD.OUTLOOK.COM (20.176.145.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.19; Thu, 30 Apr 2020 13:49:12 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::683d:f224:e857:746a]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::683d:f224:e857:746a%5]) with mapi id 15.20.2958.020; Thu, 30 Apr 2020 13:49:11 +0000 From: Andrew Campling To: Toerless Eckert , Ian Peter , Brian E Carpenter CC: "architecture-discuss@ietf.org" Thread-Topic: [arch-d] FYI: "ISOC" "New IP" "discussion" "paper" Thread-Index: AQHWHvYgiVGdUCo0wk2aJHfI+zbk4g== Date: Thu, 30 Apr 2020 13:49:11 +0000 Message-ID: References: <20200428190608.GN62020@faui48f.informatik.uni-erlangen.de> <20200428211737.GP62020@faui48f.informatik.uni-erlangen.de> <20200428222219.GQ62020@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200428222219.GQ62020@faui48f.informatik.uni-erlangen.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cs.fau.de; dkim=none (message not signed) header.d=none;cs.fau.de; dmarc=none action=none header.from=419.consulting; x-originating-ip: [2a00:23c4:a499:2e00:bc12:c64f:3fad:1ac0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5235cab6-3c7d-48af-fba0-08d7ed0d438b x-ms-traffictypediagnostic: LO2P265MB1022: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0389EDA07F x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jCf0d1vmDgXUWN/lX907U6WtjnZ17DvOAMImq/Zh7OXhxq40mUXTjO5hmy92Wx+GcVZF30Xh+QCcWjhofku4SU4oH0MwVYvW33OkJ3V/lZ1b+JSxa2T4DD3hv3j14Z4rLrNm8E5RLriFagvOS/WTeetlVNflhUbjXVDFWn4N1fQnovYOjeZTD5FBzpZg7hhCfQspq8ip+FwWpb4ZqGYhBHDOZULUJtethKMJt6ah4gwYlg1yvEKr8P3U54HgTCnRBQ8AIkydbST/Nw82qsnUGD1mEwLiTElmVXLeVqp2aK/ZuJ4lbMyeX+/3DUSd1+URGFmhmWceEtjZ7A38LLno+UKfpGSYB55fweZfh5KMROlmLRR4dbEDS5juJ1vCHmZeVdPfqvtG+MYFM1LjKxQf7Z5da6iQ3uzqP+SMi7CwYWJbTcgWZC3ttLbjZsyA/AmDPa6jiJQW4//yeO8PUsRmK7+VCNh4wGJrSA7HoawvdunuuzWe2i5g1CSv1IP3DbYqnDK8c/m+4CPrdAhRj70hmog+KJp6oWK1JPen5qJALMAveUl9uDwbBzkVUzvs82kb x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(136003)(366004)(376002)(39840400004)(396003)(346002)(7696005)(6506007)(186003)(33656002)(52536014)(508600001)(64756008)(66556008)(53546011)(66946007)(76116006)(66446008)(110136005)(66476007)(4326008)(316002)(4744005)(2906002)(8936002)(9686003)(71200400001)(86362001)(8676002)(55016002)(44832011)(5660300002)(46492006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: M07o68Zav0Q5mc5B6mwQ8d/ckky9zfYJPacamTHwep6mLfmySZoHGVJatfy92+qQqxj+4CKPCCpk/CKWeLxA/FJX1FSnNwQZGan5vKT1M+UaFwtmuDLkx8ZIJzsuwi0FykfdyN3PBpElzEhH9+2zRDxTXwj5iQ35xxvSWwE5t86sNLvF0bh+vVm7zJnSE6S9I0GPkj6hAqRB4FBU5ThBj43df+IfV7gJihDoArw5tRtUgs09ghBridGZOmLZI0bZi/kczpwMeFy5juZ7LtS/l5Cm6/9rdMVRvpi+ZuunrvQxSuK31RNLPuse/9COOenjxrdBqAVwNLJe+UKz7gk+gHt7Dd0Y0w35GwOu1PBOWfxTQTU3CiL0HczEOsX6g09+IwRlaPSXqF/ER5VVBAEW2zVuip4DGkffgWUeIrObI/UCrN4jwbfFYZIo+dkzbpQuB8r4SCwVXZMBoPzeJpaFYNmtITcndfuWJl8yF1C87DKUhC8HHZmfbTU28D0P7bSxzrofSrpObvh0vkRZm4TWc6mNLMfKOBCxBSFkDmmfrGEMf8206MI/mDuLUHezsihGpyC2Qi26/u+7YdeBA6uervpzYNm/7Z+XiUG1M5t92sH2yzdTs7SXDlijbhukmLyYmcYnA5E8wNwCiGZxeiJivp/KkUmF/X7ABBTLWbvE/s2ab1XUv8q9HbS6t0drJGvozduB9YXcrgczENV4dOYEVy4kNr9luorPSVwMjNM7PHmIOwW/T7F3gZyRSabCjuXUg3ewNstqlEU7BA1yGhTnX+E+zib4dQXYS6glKii6/8Gjauw6Z69S4SHxzzcGvfgKVFF0E2RGd+AsHTybFO97bC0uE0ycSiH1jpdslu/Wb78DhCxh6+HQktRGfLGkT2XD x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-Network-Message-Id: 5235cab6-3c7d-48af-fba0-08d7ed0d438b X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2020 13:49:11.8966 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: M+D+gYEjeG+ZUK5G0SKrYyJwPd8pxtVW6lnblRbRaABlLi8BvUDxwq7R5XpFPOTJAq3XyJWojbmxcFhKj452WnUW3t7XTYm2X9Whw3sqnbk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB1022 Archived-At: Subject: Re: [arch-d] FYI: "ISOC" "New IP" "discussion" "paper" 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, 30 Apr 2020 13:49:19 -0000 On Tue, Apr 28, 2020 at 23:22, Toerless Eckert wrote: > In any case, for a "discussion" paper as this one, it would be great to p= oint to an actual forum where the discussion can be had. In addition to the public mailing list that ISOC has subsequently created (= https://elists.isoc.org/mailman/listinfo/discussion-papers/), is there a su= itable forum for discussion of the "New IP" proposal within the IETF (notin= g from earlier debate that the Architecture-discuss list is technically an = IAB one)? =20 I note that there has been some pushback about the ITU looking at this, how= ever it's not clear to me that anyone else is looking seriously at longer-t= erm development like this so it appears to have left a vacuum. I could of = course be mistaken in that, look forward to being corrected as appropriate. Andrew=20 From nobody Thu Apr 30 06:54:32 2020 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 045643A077D for ; Thu, 30 Apr 2020 06:54:29 -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, 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 (1024-bit key) header.d=cs.tcd.ie 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 JTzJZViOh3Sx for ; Thu, 30 Apr 2020 06:54:27 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6C0F3A077A for ; Thu, 30 Apr 2020 06:54:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A128EBDCF; Thu, 30 Apr 2020 14:54:24 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8R4fzkImPCc; Thu, 30 Apr 2020 14:54:22 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4B160BE2C; Thu, 30 Apr 2020 14:54:15 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1588254855; bh=KWUk9PY2f1gZ7Sj5VHIA4spDV/Q2uskiPM63GoTET9A=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=PHF8K8KyXgmH/mW8tGY67POFv6hIw0VLgl1Z5kMpfSWlTP7aGZ1xMhesHcDWgCtK+ SmWDIwBHmyeFGkj0l/7K9yLnpkjsQH0DbzsdOiemoN9AxOI4hBt7pulNNJ68jnCyMQ 6EOjyBtxyThx3hL2Bu8DXJVXb2mjw7YuyOHzo5Ns= To: Andrew Campling , Toerless Eckert , Ian Peter , Brian E Carpenter Cc: "architecture-discuss@ietf.org" References: <20200428190608.GN62020@faui48f.informatik.uni-erlangen.de> <20200428211737.GP62020@faui48f.informatik.uni-erlangen.de> <20200428222219.GQ62020@faui48f.informatik.uni-erlangen.de> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Thu, 30 Apr 2020 14:54:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9gV9SmTw3iXLXqagobB22sXxrGf94ByBj" Archived-At: Subject: Re: [arch-d] FYI: "ISOC" "New IP" "discussion" "paper" 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, 30 Apr 2020 13:54:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9gV9SmTw3iXLXqagobB22sXxrGf94ByBj Content-Type: multipart/mixed; boundary="rRlYa5YsijEIv1ztnVwTrkbeSaN4GapVg"; protected-headers="v1" From: Stephen Farrell To: Andrew Campling , Toerless Eckert , Ian Peter , Brian E Carpenter Cc: "architecture-discuss@ietf.org" Message-ID: Subject: Re: [arch-d] FYI: "ISOC" "New IP" "discussion" "paper" References: <20200428190608.GN62020@faui48f.informatik.uni-erlangen.de> <20200428211737.GP62020@faui48f.informatik.uni-erlangen.de> <20200428222219.GQ62020@faui48f.informatik.uni-erlangen.de> In-Reply-To: --rRlYa5YsijEIv1ztnVwTrkbeSaN4GapVg Content-Type: multipart/mixed; boundary="------------2D1EF0699B471C9936AF7234" Content-Language: en-US This is a multi-part message in MIME format. --------------2D1EF0699B471C9936AF7234 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 30/04/2020 14:49, Andrew Campling wrote: > In addition to the public mailing list that ISOC has subsequently > created > (https://elists.isoc.org/mailman/listinfo/discussion-papers/), is > there a suitable forum for discussion of the "New IP" proposal within > the IETF (noting from earlier debate that the Architecture-discuss > list is technically an IAB one)? I'm confused. Why does it matter if arch-d is an IAB list? Seems to me that this is a reasonable list for discussion of Internet architecture. (Not such a good list to which to send unsolicited meeting invites, but that was a different issue:-) S. --------------2D1EF0699B471C9936AF7234 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------2D1EF0699B471C9936AF7234-- --rRlYa5YsijEIv1ztnVwTrkbeSaN4GapVg-- --9gV9SmTw3iXLXqagobB22sXxrGf94ByBj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl6q2IYACgkQWrL68XsX K+qa8hAAhxgjqZMtnWK3bxRI8xU4XE+e4CU7DB+txKZe5JDFh97tn6pR7DXqGSP0 3+ZbLSct7ldm1ZXyRUAl3uULkDD7z2Hk1q2jDv2PpKQkSOtqhxQprhxYhID62qR5 jtg3qNyM6z6NQboEp0FMIQThcN1dmgxD1T3IyqVRGzcn3Fd9JYTwRiCqUSWV+bTI YIR57q34ezH86SYSHlhfgVDO+8r9DuGhxOUNR+OYD6TTbpgVSBGRhkAHkdncmQZT YmcpIV3M2BCufSW4gN4BXiCt/Kiki+XiPDbq1jqxfbVONBuH2GqlLhlv02w6dvjm AuutNrGZXKc4GrPzU5XjD8sVnOOIlGWY3WA1EaZ5rmbmUDycpZWFXsZRzGJtSJeJ KFPwkucV1keTh8OD2XgqZyku1GlNzsmNcy4T/VHew0+o5rAy+u9Gpn8NyQWpt7oK ywpoeh9Qoyg8AGwj/rcrcWkC9Sltl5R6FAvLNtj6a68uGFdFSUS6Mby+Owui31LD KB8HG7DORH8yJYV2QGMvyZFULP/Pytl5+LTpNBd0HLT8Qv27xxRPV2nHdXEuT89Q tuw1tAJw5gwF9SHxfE/JRq79sVqQXslYiCnBEOau5N/DqaQ6/gHf3PHmDSmG0DrB hLZdY/QWepFLw6BnLYb+Uo+B0zeXLaeOa6czH2GoMOubCCjow4s= =xncQ -----END PGP SIGNATURE----- --9gV9SmTw3iXLXqagobB22sXxrGf94ByBj-- From nobody Thu Apr 30 07:53:21 2020 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 1DFD83A0A8F for ; Thu, 30 Apr 2020 07:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.717 X-Spam-Level: X-Spam-Status: No, score=-2.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.82, SPF_HELO_NONE=0.001, SPF_NONE=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 ZWTUbBBpu2VE for ; Thu, 30 Apr 2020 07:53:18 -0700 (PDT) Received: from know-smtprelay-omc-6.server.virginmedia.net (know-smtprelay-omc-6.server.virginmedia.net [80.0.253.70]) (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 445833A0A85 for ; Thu, 30 Apr 2020 07:53:17 -0700 (PDT) Received: from [192.168.1.35] ([79.72.166.100]) by cmsmtp with ESMTPA id UAYtjDczWEIzOUAYujBDii; Thu, 30 Apr 2020 15:53:16 +0100 X-Originating-IP: [79.72.166.100] X-Authenticated-User: john.s.grant@ntlworld.com X-Spam: 0 X-Authority: v=2.3 cv=HZs6sBM8 c=1 sm=1 tr=0 a=KdT9lSvhpbvUFdjzdD3cHA==:117 a=KdT9lSvhpbvUFdjzdD3cHA==:17 a=IkcTkHD0fZMA:10 a=-O5YPv7yAAAA:8 a=le6d79QuAAAA:8 a=W4KLshwA3pVDENfDSAYA:9 a=QEXdDO2ut3YA:10 a=E1MJKltkMhAA:10 a=TLqBRRHTddABEfEY9lce:22 a=QbAMNLWdp4a7deKPGBBn:22 To: architecture-discuss@ietf.org References: <20200428190608.GN62020@faui48f.informatik.uni-erlangen.de> <20200428211737.GP62020@faui48f.informatik.uni-erlangen.de> <20200428222219.GQ62020@faui48f.informatik.uni-erlangen.de> From: John Grant Message-ID: <436ee034-c792-167b-332c-accfa0397835@ninetiles.com> Date: Thu, 30 Apr 2020 15:53:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-CMAE-Envelope: MS4wfNqtC59Xqfr18PEgGiA96JgmpU5BX3y8KxKIibjb0loXbusITg2j0A+Im7jpjCfM+rpJXLHP8qyibiCF4FCXVeKG4XWRY5uVimT32uvYd5zCCx/0N0+R xRdL9uARZbo0qknlX/CAqCvFi/TLaW/5cvHFF/2qbt7j2KFnJXGEjtXl51+C4ZW8JFgMtuMZ6bSOaw== Archived-At: Subject: Re: [arch-d] FYI: "ISOC" "New IP" "discussion" "paper" 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, 30 Apr 2020 14:53:21 -0000 On 30/04/2020 14:49, Andrew Campling wrote: > I note that there has been some pushback about the ITU looking at this, however it's not clear to me that anyone else is looking seriously at longer-term development like this so it appears to have left a vacuum. I could of course be mistaken in that, look forward to being corrected as appropriate. Well, there is ETSI ISG NIN (see thread about 2 weeks ago). See https://www.etsi.org/technologies/non-ip-networking and sign up at https://portal.etsi.org/tb.aspx?tbid=887#/ -- John Grant Nine Tiles, Cambridge, England +44 1223 862599 and +44 1223 511455 http://www.ninetiles.com From nobody Thu Apr 30 13:24:05 2020 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 0F6523A1299 for ; Thu, 30 Apr 2020 13:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SxRR_OUCpLO for ; Thu, 30 Apr 2020 13:24:01 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 866853A1297 for ; Thu, 30 Apr 2020 13:24:01 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id n16so3420699pgb.7 for ; Thu, 30 Apr 2020 13:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=jmM6vfYv5je/AINzEDAHEGhHB7O+G/QYk049F6DVByQ=; b=KnPa+ydk1TJgJjZ9pbx8hQ+yTBkScj1wLqHLdQsCd2J82UE3fBM14gr/p8opeqEYPl bke+m3WBTKPAxA1ikE4Ki8kdp7Q4kjmnGtQaG5EFGiuKT0MAPC/Am3E6PojzX2VjqqCh QM6+1MieYrPQPnm7vuTMArc5T4P3UubwzYUxbMVHdY0SF6DBdVx8d1VUECQZUqCUq4wR 7dga+UgSGj5Fpbp1FNpMufAVTnIYzqFM4DY/PFobPbcT+SZlKqEnNV4DZ2DWC8lSw2/9 VNt1LlNIKCb3I2irdfwcDAOXNIU8qOGZ2Ti2E2Dd9FOQmyWr8vy8ceMIyW7NOd3WauOe EJJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jmM6vfYv5je/AINzEDAHEGhHB7O+G/QYk049F6DVByQ=; b=HY/YCrN/A213oGtZhmZp0qK1HifjsUp/HQtwlwXqQXZhNPvsmESkWoZizVZLxgELBl H33zBZ0GWXPmlwBodI0pHOknhhKr7wxSLHkNIDZZNn8FZaSiNjqKmGGWwvEJCMQBhmz1 RvuQMFruYeJb8bc2RPmWmxs6gbYsgEkLaOcRmPsQVmx1Nu6kgXWGGqFSxlr0hySHzoLK XK0SixbegwmHVkLYY9aD7MY+PHTwo7Dt0RNUfb2SQL5G0+41MVlBN+0FQXQyjPjJYZu9 ZI06hYEGyuxb2a5XdJ31Uacl6TJIQDH2pMAt8wf20Io5IalL0VKYg6XeBlCjTgmmTgEW X3+g== X-Gm-Message-State: AGi0PuaDAmdUjMdkuYP4dY7hFpghe2T4v6R4xarf/J9lC5/mtXLLxk5y 7jj+SPPSpRNL+u4BXcDARAHQCSJK2U8= X-Google-Smtp-Source: APiQypLDfieofHcccuvCt/86Qu/+sv9jwPQle1iMyPMjqdsfhOCwTN+UQAIQTwZwMQL7fgLkESBCLw== X-Received: by 2002:a63:4a59:: with SMTP id j25mr695704pgl.336.1588278240427; Thu, 30 Apr 2020 13:24:00 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.84]) by smtp.gmail.com with ESMTPSA id b73sm542439pfb.52.2020.04.30.13.23.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Apr 2020 13:23:59 -0700 (PDT) To: Stephen Farrell , Andrew Campling , Toerless Eckert , Ian Peter Cc: "architecture-discuss@ietf.org" References: <20200428190608.GN62020@faui48f.informatik.uni-erlangen.de> <20200428211737.GP62020@faui48f.informatik.uni-erlangen.de> <20200428222219.GQ62020@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: <728f9b75-382f-733c-d308-b5ba5101110b@gmail.com> Date: Fri, 1 May 2020 08:23:54 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 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: "ISOC" "New IP" "discussion" "paper" 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, 30 Apr 2020 20:24:04 -0000 On 01-May-20 01:54, Stephen Farrell wrote: > > Hiya, > > On 30/04/2020 14:49, Andrew Campling wrote: >> In addition to the public mailing list that ISOC has subsequently >> created >> (https://elists.isoc.org/mailman/listinfo/discussion-papers/), is >> there a suitable forum for discussion of the "New IP" proposal within >> the IETF (noting from earlier debate that the Architecture-discuss >> list is technically an IAB one)? > I'm confused. Why does it matter if arch-d is an IAB list? > > Seems to me that this is a reasonable list for discussion > of Internet architecture. As I have argued in my recent rant, the IETF (which of course appoints the IAB members) is probably the best venue we have. And the IAB's job description includes A for Architecture. So yes, as long as we don't imagine ourselves to have any power of decision. Brian