[Din] Re: next steps for DINRG
Lixia Zhang <lixia@cs.ucla.edu> Mon, 21 October 2024 13:54 UTC
Return-Path: <lixia@cs.ucla.edu>
X-Original-To: din@ietfa.amsl.com
Delivered-To: din@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADCAC1CAE7F for <din@ietfa.amsl.com>; Mon, 21 Oct 2024 06:54:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.004
X-Spam-Level:
X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cs.ucla.edu
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvgzHXPZbi1B for <din@ietfa.amsl.com>; Mon, 21 Oct 2024 06:54:28 -0700 (PDT)
Received: from mail.cs.ucla.edu (mail.cs.ucla.edu [131.179.128.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3E93C23A843 for <din@irtf.org>; Mon, 21 Oct 2024 06:54:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 551FE3C011BC5; Mon, 21 Oct 2024 06:54:20 -0700 (PDT)
Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id fjDj9VUm8TFI; Mon, 21 Oct 2024 06:54:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 9BB983C011BDD; Mon, 21 Oct 2024 06:54:19 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 9BB983C011BDD
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1729518859; bh=8pbNHvzuTa5G6BQp1MWoKqnjD7UGhNVhCHWeABw5ymg=; h=From:Message-Id:Mime-Version:Date:To; b=e3cGTbc4l67kDvOtsooiCuSHwWYNrjjzPoBt+8pA+Y+HsbWteqGfZBz8+xP3wxaXy MVVGXzO5yj6un08iWcYCbbDZsOM4Zb4cxryUh4OUqgQs9ZaoqwqB8X21Gg194p5eRi YQ1QqZ61gNkM9LBJmhAhsXl7vQOD80euE7G8BuoueGrnfH0aKvjJ1xLBGXQP1qjQoS HGPm1A2mX8QRu0r/zNZV1VrZGY7xkKB0lzt/UJE3sDCKOBIqiQlzGG6+wZCoBngp+h Bfi96YvCIhff17lqn4nugDCIhRnFh/BgTt3JXwNW58Ajvyun6rY7tmUevIo2oCnpST ArQlMy82uXQNg==
X-Virus-Scanned: amavis at mail.cs.ucla.edu
Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id 6fDWsz5H2whS; Mon, 21 Oct 2024 06:54:19 -0700 (PDT)
Received: from smtpclient.apple (syn-076-091-005-005.res.spectrum.com [76.91.5.5]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 63E023C011BC5; Mon, 21 Oct 2024 06:54:19 -0700 (PDT)
From: Lixia Zhang <lixia@cs.ucla.edu>
Message-Id: <F0DCA536-FBE4-4292-923A-796977A90052@cs.ucla.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EDFB1E57-FE3E-4478-9750-F94F3EE6D6A6"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3818.100.11.1.3\))
Date: Mon, 21 Oct 2024 06:54:09 -0700
In-Reply-To: <BYAPR01MB4391391642D149D59316D9F0CB402@BYAPR01MB4391.prod.exchangelabs.com>
To: Thomas Hardjono <hardjono@MIT.EDU>
References: <18BAB346-D64A-40A3-A29B-9146562E5674@dkutscher.net> <6d66bdb8-b546-40b1-b723-ee8ac80b8adb@app.fastmail.com> <BYAPR01MB4391391642D149D59316D9F0CB402@BYAPR01MB4391.prod.exchangelabs.com>
X-Mailer: Apple Mail (2.3818.100.11.1.3)
Message-ID-Hash: EOBWZ4SULKQSTDAXBSIOZ2YIEPHJD2NW
X-Message-ID-Hash: EOBWZ4SULKQSTDAXBSIOZ2YIEPHJD2NW
X-MailFrom: lixia@cs.ucla.edu
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-din.irtf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Chad Kohalyk <chad@kohalyk.com>, "din@irtf.org" <din@irtf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Din] Re: next steps for DINRG
List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" <din.irtf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/din/j_073TjgjPWRPSG-Ustgh0NtJwI>
List-Archive: <https://mailarchive.ietf.org/arch/browse/din>
List-Help: <mailto:din-request@irtf.org?subject=help>
List-Owner: <mailto:din-owner@irtf.org>
List-Post: <mailto:din@irtf.org>
List-Subscribe: <mailto:din-join@irtf.org>
List-Unsubscribe: <mailto:din-leave@irtf.org>
Hi Thomas, thanks for your great set of questions. Just a personal comment: most of your questions seem to me related to one basic question one way or another: what is exactly the definition of "Internet decentralization" that we are aiming at? I think clarifying this definition would directly answer the questions about VMs vs bare-metal, machine locations etc. This would also indirectly touch on some other questions (e.g. do so-called Web3 systems have bake-in decentralization). I also appreciate your suggestion of identifying potential relations between DINRG and some WGs work. Lixia > On Oct 18, 2024, at 12:30 PM, Thomas Hardjono <hardjono@MIT.EDU> wrote: > > Just some quick thoughts on the “What’s next” question. > > One of the things DINRG could focus on is the standards (architectures, protocols, etc.) and tools to measure the degree of decentralization of systems and networks (notably those DLT-based offerings that claim to be “decentralized”). > > Let’s say a DLT network (e.g. blockchain) has 100 nodes and the network claims to be operating in decentralized manner. What if it turns out that 90% of those nodes are actually VMs running in the cloud, and what if it turns out that 90% of those cloud-based VMs are running on the same Cloud Provider? (worse, what if they’re running on the same Zones, like US-West and US-East). Would you accept their claim of decentralization seriously? > > Some possible future work for DINRG: > > -- Could DIN look at protocols that report on which nodes are running on bare-metal, versus physically separated VMs, versus VMs clustered in a given zone. > > -- Could Device-ID and device-stack identifiers be useful (building on protocols defined in the RATS WG and TEEP WG). > > -- Could DIN leverage the work already being done in the IEF WGs (e.g. RATS, SCITT, etc), and also from other industry bodies (e.g. TCG DICE; OpenCompute; Confidential Computing Consortium; etc). > > -- Could DIN be the funnel/filter into which near-mature proposal can be fed into working groups in the IETF. An example of this was the Group Security RG (GSEC) that funneled some ready items into the MSEC WG. > > https://www.irtf.org/concluded/gsec.html > https://datatracker.ietf.org/wg/msec/about/ > > PS. Yes I’m aware of economic papers/analysis stating that efficiency and cost-savings favors centralization. In contrast, I’m referring to future so-called Web3 systems that bake-in decentralization patterns to avoid these concentrations of power. > > > Best > > --thomas > > From: Chad Kohalyk <chad@kohalyk.com <mailto:chad@kohalyk.com>> > Date: Friday, October 18, 2024 at 12:41 PM > To: din@irtf.org <mailto:din@irtf.org> <din@irtf.org <mailto:din@irtf.org>> > Subject: [Din] Re: next steps for DINRG > > Thanks Dirk. > > One possibility is to discuss “What now?” > > I think that was one of the conclusions of the IETF120 discussion: who should DINRG collaborate with in order to effect change? > > In other words, what is DINRG’s theory of change? Where does the research go once it is complete? Is DINRG’s role purely observatory? On who’s behalf? (merely the IRTF?) > > Possibly these were answered when DINRG was stood up, but based on the conversation in Vancouver it didn’t seem like the community understood what’s next. > > So I submit this as a topic suggestion. > > Thank you, > > Chad Kohalyk > > On Fri, Oct 18, 2024, at 1:41 AM, Dirk Kutscher wrote: > Dear all, > > in Dublin, we are planning to continue our discussion on next steps for DINRG. > > To that end, we are soliciting suggestions, interests indications, and questions here. If you have a suggestion, please feel free to share it here or by personal e-mail. > > We will collect everything and then prepare a summary before the meeting. > > As a bit of background: > > As chartered, DINRG has different objectives: > > Investigation of the root causes of Internet centralization, and articulation of the impacts of the market economy, architecture and protocol designs, as well as government regulations; > Measurement of the Internet centralization and the consequential societal impacts; > Characterization and assessment of observed Internet centralization; > Development of a common terminology and understanding of (de-)centralization; > Interaction with the broader research community to explore new research topics and technical solutions for decentralized system and application development; > Documentation of the outcome from the above efforts via different means (e.g., research papers and RFCs) as inputs to the broader conversation around centralization; and > Facilitation of discussions between researchers, organizations and individuals involved in Internet standards and regulations. > Let us know, which of these objectives should be emphasized in your view, and whether you have specific interests within these topics that should be discussed more. > > Best regards, > Dirk and Lixia > _______________________________________________ > Din mailing list -- din@irtf.org <mailto:din@irtf.org> > To unsubscribe send an email to din-leave@irtf.org <mailto:din-leave@irtf.org> > > > Attachments: > signature.asc > > _______________________________________________ > Din mailing list -- din@irtf.org <mailto:din@irtf.org> > To unsubscribe send an email to din-leave@irtf.org <mailto:din-leave@irtf.org>
- [Din] next steps for DINRG Dirk Kutscher
- [Din] Re: next steps for DINRG Chad Kohalyk
- [Din] Re: next steps for DINRG Thomas Hardjono
- [Din] Re: next steps for DINRG 김우태(Operation연구TF)
- [Din] Re: next steps for DINRG Re: 202410191733.A… Abraham Y. Chen
- [Din] Re: next steps for DINRG Lixia Zhang
- [Din] Re: next steps for DINRG Lixia Zhang
- [Din] Re: next steps for DINRG William Lehr
- [Din] Re: next steps for DINRG Thomas Hardjono
- [Din] Re: next steps for DINRG Re: 202410191733.A… Lixia Zhang
- [Din] Re: next steps for DINRG eburger-l@standardstrack.com
- [Din] Re: next steps for DINRG Lixia Zhang
- [Din] Re: next steps for DINRG Christian Huitema
- [Din] Re: next steps for DINRG Jon Crowcroft
- [Din] Re: next steps for DINRG William Lehr
- [Din] Re: next steps for DINRG Thomas Hardjono
- [Din] Re: next steps for DINRG Re: 202410191733.A… William Lehr
- [Din] Re: next steps for DINRG Re: 202410191733.A… Jens Finkhäuser
- [Din] Re: next steps for DINRG Dirk Trossen
- [Din] Re: next steps for DINRG Dirk Trossen
- [Din] Re: next steps for DINRG Re: 202410230956.A… Abraham Y. Chen
- [Din] Re: next steps for DINRG Re: 2024110211733.… Abraham Y. Chen
- [Din] Re: next steps for DINRG Re: 202410231010.A… Abraham Y. Chen
- [Din] Re: next steps for DINRG Re: 2024110211733.… William Lehr