Re: [Din] Updated charter proposal

Paulo Mendes <paulo.mendes@ulusofona.pt> Fri, 13 July 2018 09:07 UTC

Return-Path: <paulo.mendes@ulusofona.pt>
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 C06F31277CC for <din@ietfa.amsl.com>; Fri, 13 Jul 2018 02:07:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ulusofona-pt.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 ikVQImJblxbD for <din@ietfa.amsl.com>; Fri, 13 Jul 2018 02:07:55 -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 856DF130E0E for <din@irtf.org>; Fri, 13 Jul 2018 02:07:54 -0700 (PDT)
Received: by mail-wr1-x42b.google.com with SMTP id c13-v6so24316848wrt.1 for <din@irtf.org>; Fri, 13 Jul 2018 02:07:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ulusofona-pt.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=FRsgWmrgraZ68y63fnzs2tLoiURj9RNx3WaejUBYdz4=; b=UtsdGbGeFd+5V/5N1bEAUQoTOEuGn2oUbK20Bm3hkAWQrbw9QAdsJRv6rbF6C4OqpZ bear6EUBd35PrhUPzuhXQEbNWt9lWylW+7JLAP42AVt9alD1TsjrbQ4xpm/EmWuZZnCW 135X1o8qhENh6fBr7kVz5iKbgVzvUe+2Pt2ivMef93pRAg5imUXS5mjZ7o3fAwUzv22W RiW8bQYVPGx8dPKi+864abjzXUfPjOuUJX/EsrnHqViQdM5sjJpl5thrdS99KuoSNd9S wOkFUVg8Z6L8yovWdoS4UOy6xHIcXePBy5P+9kPpzzajU23IjbIhAGZXO+AVu35wZgIy +2bQ==
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 :message-id:references:to; bh=FRsgWmrgraZ68y63fnzs2tLoiURj9RNx3WaejUBYdz4=; b=fTh7Dley4D8wxazYtemuI4/xHJIbe6K/3Xfp0F1kQdrWCkU4iyZIf6y563rxITEn5X j9/LrLnNYbhqhtd9xCjXMrjQYcEwq77fqecqc3TsOnGk6b3pMvoYa3DKmNsXoGpkqIAl 6Ej10zCaFA1PYjFSD0ANVntTZoiHtv5QQJAcHvPJTr0PGSQLO6fnYWZMk7YdSudENEnD xdHPFU0KFe/ZjbZJrfcJi4qCsR1Bfq/pASxEYIwxwnUSSBi7zx4WvGP1BZWr4bYEwy1K LK+UWrUzT3FJJlu7aqKY7Ho4D+y+uUkXa/KB8z14DZIgG0nyP5HqMBq9m4+ZiYacx6yo nxrA==
X-Gm-Message-State: AOUpUlHItVuzv0p8m4yBOH2cHus2sbezOzYzJbduTqtSqgdx7SMrfTDN NQmLzspR/m4nWRDlbwybyeD2fwY8PlM=
X-Google-Smtp-Source: AAOMgpfGennCzGi32lnteY0ehIxkoPEODPjZuVicmw1yp4TezKmBZLpb4XgBIrBL1LXigi1CoY2pew==
X-Received: by 2002:adf:8162:: with SMTP id 89-v6mr4076589wrm.192.1531472872231; Fri, 13 Jul 2018 02:07:52 -0700 (PDT)
Received: from [12.0.0.47] (sitivoip.ulusofona.pt. [193.137.75.156]) by smtp.gmail.com with ESMTPSA id p3-v6sm39361241wrg.47.2018.07.13.02.07.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 13 Jul 2018 02:07:51 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E45E4DF9-25BB-4924-B3FD-D925D55EA806"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Paulo Mendes <paulo.mendes@ulusofona.pt>
In-Reply-To: <76cd5da5-c2ba-dc04-e1bb-6ffd49f94eb3@nomountain.net>
Date: Fri, 13 Jul 2018 10:07:45 +0100
Cc: "din@irtf.org" <din@irtf.org>
Message-Id: <D56BEA89-1EDA-47C1-8072-102DB2B1361A@ulusofona.pt>
References: <76cd5da5-c2ba-dc04-e1bb-6ffd49f94eb3@nomountain.net>
To: Melinda Shore <melinda.shore@nomountain.net>
X-Mailer: Apple Mail (2.3112)
Archived-At: <https://mailarchive.ietf.org/arch/msg/din/urjKIdpNn79OtKbwJ9gvYkMhpa8>
Subject: Re: [Din] Updated charter proposal
X-BeenThere: din@irtf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" <din.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/din>, <mailto:din-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/din/>
List-Post: <mailto:din@irtf.org>
List-Help: <mailto:din-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/din>, <mailto:din-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Jul 2018 09:07:59 -0000

Hi Melinda,

Were are my 2cents about the charter:

a) Since the charter is focused on *network services* it would be good to enumerate some services that really depend on a decentralised operation. I can deploy a trust management or identity management mechanism based on a centralised service. It is true that decentralising such services may increase their performance, but that would diminish the proposed of the charter towards “only” network optimisation issues. To make the charter stronger I would suggest to clear identity services that really require a decentralised/distributed infrastructure to operate, and those that although can be deployed in a centralised manner, gain a lot (e.g. in terms of performance) from the decentralised / distributed network operation. IMO, the services mentioned in the charter fit the latter case. I would say that examples of services that really require decentralised / distirbuted are: fog and edge computing (at least they require a decentralised approach, which fog arch pointing to the need for cooperation among fog devices); intermittent connect networks (in this case all the services mentioned in the charter must be decentralised / distributed); Data privacy (from the centralised silos to personal clouds); Network automation (which requires network devices to be more autonomous); Distributed ledge technology. In the latter case I agree in stating that this is not the only case, due to the current hype.

b) Besides the mentioned technical use-cases / services, the charter should highlight that DINRG is aware that decentralising / distributing requires a set of core drivers: trust, incentives (may be technical or economic) and consensus. At least those were the ones that I mentioned in the London meeting. IMO, it will not be possible to build decentralised / distributed services if involved peers do not trust each other, have no incentives to cooperate and have no basic mechanism to reach consensus to solve conflicting operations.

c) The name of the research group mention “Decentralised” but the charter mention decentralisation as well as distribution, which are different things. So, a may doubt is if the charter will limite the work to decentralisation aspects, or if it will also tackle distributed services.

e) As for the motivation, the question is how DINRG will contribute the revert the centralisation of the network operation, as is the case of Network Cloudification, which goal is to centralize and virtualize networking into data centers. This can actually be a good use-case: to show that CAPEX and OPEX can be reduced relaying in a full distributed approach (e.g. deployed at network edges) instead of relying on data centres (which of course can be seen as a distributed computing system :-) ).

As for the interface with other IETF/IRTF groups, I would include NMRG. The work with other groups should be useful to keep DINRG focused on the its core objectives.

As for the Objectives it may be difficult for a RG to operate actual implementations, although I agree that it should be the responsibility of any RG to demonstrate that proposed solutions work, by working on proof-of-concepts (before going to IETF). Besides this I would like to see the following objectives:
- Bring attention of the scientific community to DIN issues and challenges by organising workshops, tutorials, international conferences.
- Describe the use-case that really need decentralisation to be deployed, and the use-cases that rely in decentralisation for a better performance.
- Specify the drivers for DIN, without which decentralisation is not possible.
- Clearly create task-forces (commitment) in order to reach a set of proof-of-concepts. I know that IETF is a self-organised organisation :), but sometimes we need push models :) to go beyond what is expected from a RG.

Melhores Cumprimentos / Best Regards / Mit freundlichen Grüßen
------------------------------------------------
Paulo Mendes, Ph.D
Coordinator SITI group @ COPELABS (http://siti.ulusofona.pt)
Director of NEMPS PhD program (http://nemps.ulusofona.pt <http://nemps.ulusofona.pt/>)
Associated Professor at University Lusofona, Portugal

http://www.paulomilheiromendes.com <http://www.paulomilheiromendes.com/>
Tel: +351 217 50 50 22

> On 08 Jul 2018, at 21:34, Melinda Shore <melinda.shore@nomountain.net> wrote:
> 
> Hi, all:
> 
> We've updated the proposed charter based on discussions we've
> had with participants over the past several weeks, and we're
> looking for additional feedback.  Please take a look and send
> comments to the mailing list.  As I think most of you know,
> proposed research groups may meet for a year before a decision
> is made to charter them, or not, and we will be at the one-year
> mark in Montreal.  We want to make sure the charter text
> reflects the direction we'd like to take and the work we'd
> intend to undertake once chartered.
> 
> The current draft is at:
> https://docs.google.com/document/d/17V6dAawxdda_oiul3p1ssRDYSlHFOe9CnXn-4iLTCdI/edit?usp=sharing
> 
> Many thanks,
> 
> Melinda & Dirk
> 
> -- 
> Software longa, hardware brevis
> 
> PGP fingerprint: 4F68 2D93 2A17 96F8 20F2
>                 34C0 DFB8 9172 9A76 DB8F
> 
> _______________________________________________
> Din mailing list
> Din@irtf.org
> https://www.irtf.org/mailman/listinfo/din