[Coin] Some comments on draft-mcbride-edge-data-discovery-overview-03

Ike Kunze <Ike.Kunze@comsys.rwth-aachen.de> Fri, 17 April 2020 10:59 UTC

Return-Path: <Ike.Kunze@comsys.rwth-aachen.de>
X-Original-To: coin@ietfa.amsl.com
Delivered-To: coin@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359D03A0903 for <coin@ietfa.amsl.com>; Fri, 17 Apr 2020 03:59:48 -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, 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 oKYlbNVCl_ke for <coin@ietfa.amsl.com>; Fri, 17 Apr 2020 03:59:40 -0700 (PDT)
Received: from mail-out-4.itc.rwth-aachen.de (mail-out-4.itc.rwth-aachen.de [IPv6:2a00:8a60:1:e501::5:49]) (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 A5E723A08FF for <coin@irtf.org>; Fri, 17 Apr 2020 03:59:39 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2CAMAAfi5le/xUN4olmgkOBUiQxWRNYLyqEHY54m2UTgWcKAQEBAQEBAQEBCCMKAgQBAYREGYF4JDoEDQIQAQEGAQEBAQEFBG2FKgYmAQuGGzA4AUcDAgQwFBMEExuDCwGBfn4BDq8VgTKFT4NKgUCBOYw2D4FMP4ERJw8NgU+FTFWCezKCLQSOSoJVhg6aPweBS3wEfZZeHY9ZjF0dj0idB4EyOggXgVdNJE8qAYI+CUcYDYEelGCGAIQidAKBJ44aAQE
X-IPAS-Result: A2CAMAAfi5le/xUN4olmgkOBUiQxWRNYLyqEHY54m2UTgWcKAQEBAQEBAQEBCCMKAgQBAYREGYF4JDoEDQIQAQEGAQEBAQEFBG2FKgYmAQuGGzA4AUcDAgQwFBMEExuDCwGBfn4BDq8VgTKFT4NKgUCBOYw2D4FMP4ERJw8NgU+FTFWCezKCLQSOSoJVhg6aPweBS3wEfZZeHY9ZjF0dj0idB4EyOggXgVdNJE8qAYI+CUcYDYEelGCGAIQidAKBJ44aAQE
X-IronPort-AV: E=Sophos; i="5.72,394,1580770800"; d="scan'208,217"; a="69588007"
Received: from lists.comsys.rwth-aachen.de ([137.226.13.21]) by mail-in-4.itc.rwth-aachen.de with ESMTP; 17 Apr 2020 12:59:37 +0200
Received: from messenger-mbx.win.comsys.rwth-aachen.de (messenger-mbx.win.comsys.rwth-aachen.de [137.226.13.43]) by lists.comsys.rwth-aachen.de (Postfix) with ESMTPS id BD544C09CF for <coin@irtf.org>; Fri, 17 Apr 2020 12:59:36 +0200 (CEST)
Received: from MESSENGER-MBX.win.comsys.rwth-aachen.de (2a00:8a60:1014::43) by messenger-mbx.win.comsys.rwth-aachen.de (2a00:8a60:1014::43) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 17 Apr 2020 12:59:36 +0200
Received: from MESSENGER-MBX.win.comsys.rwth-aachen.de ([fe80::c109:b55e:3715:5c2c]) by messenger-mbx.win.comsys.rwth-aachen.de ([fe80::c109:b55e:3715:5c2c%12]) with mapi id 15.00.1347.000; Fri, 17 Apr 2020 12:59:36 +0200
From: Ike Kunze <Ike.Kunze@comsys.rwth-aachen.de>
To: "coin@irtf.org" <coin@irtf.org>
Thread-Topic: Some comments on draft-mcbride-edge-data-discovery-overview-03
Thread-Index: AQHWFKdI/5u57fXODk66XZ0uVSZELQ==
Date: Fri, 17 Apr 2020 10:59:36 +0000
Message-ID: <2523377A-6E49-4B3D-829F-FA3A4C3C1EBC@comsys.rwth-aachen.de>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [2003:e3:f25:658:d10b:e43c:6cb1:9f5a]
Content-Type: multipart/alternative; boundary="_000_2523377A6E494B3D829FFA3A4C3C1EBCcomsysrwthaachende_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/coin/dwCj_Uyv9Y_pnAOb_sF0lHI1_TE>
Subject: [Coin] Some comments on draft-mcbride-edge-data-discovery-overview-03
X-BeenThere: coin@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "COIN: Computing in the Network" <coin.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/coin>, <mailto:coin-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/coin/>
List-Post: <mailto:coin@irtf.org>
List-Help: <mailto:coin-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/coin>, <mailto:coin-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Apr 2020 10:59:48 -0000

Hi Mike, Hi Dirk, Hi Eve, Hi Carlos,

I have some comments on the latest version of the edge data discovery draft, mainly regarding the structure of the draft.
Note that I am unsure whether the checkmarks on slide 5 of your interim slides mean that you have already implemented changes for the corresponding feedback or whether
you still plan on doing them (I am sorry if I missed your comments on that, but I believe the latter is true).
So some feedback might be redundant as you might already have it on your agenda.

Sec 1.4:
1. I like the distinction between device & infrastructure edge.
Maybe separate bullet points for them could make them more visible as they are quite important for the rest of the document.
2. Why introduce ICN here if it is not mentioned in the rest of the document (converting the NDN discussion to ICN discussion still to do?)

Sec. 2.1 & 2.2:
I like that the document mentions possible data origins and types, as well as data access control and data access problems.
I think that restructuring the two sections could make these aspects easier to understand.
Maybe start with data origins (was first paragraph of 2.1) and types (first paragraph of 2.2) in one section and then follow that up with
data access control (2nd par. of 2.1) and data access problems (2nd par. of 2.2).
That makes it more straightforward, at least for me.

Sec 2.2.1:
The idea of illustrating the aspects of 2.1/2.2 using an example is great.
I am unsure whether the draft really needs the list of possible meta-data information, because to me this feels as too much of a detour.
I believe that the text around the listing alone nicely illustrates the scenario, although it could be better integrated into the context of the draft (also already on your agenda?).

Sec. 3 & 4:
I really like the content of the sections.
Similar to 2.1 & 2.2, I think a different structure could convey the content more clearly.
What currently confuses me is that the three discovery scenarios in sec 3 and the types of discovery in sec 4.1 are separated (by the definition of the edge data discovery problem) as they are, in my opinion, closely entangled.
Have you thought about integrating sec 3 as the first or second subsection of sec 4?
That way the draft would first define the edge data discovery problem and then take a look at two important aspects of it, namely which types of discovery might be needed and in which scenarios that might be useful.

Moreover, I think that defining the problem and proposing possible solutions could be separated a bit more clearly, too.
Maybe split these aspects into two sections? First, Edge Data Discovery Problem. Then, Possible Solutions for Edge Data Discovery?
Although I am unsure where the NDN discussion should go then…

Sec. 5.:
Having the use cases to illustrate the application settings of possible solutions here at the end of the draft is nice.

I hope you find the feedback helpful.

Best,
Ike
--
Ike Kunze, M.Sc.
Researcher, Ph.D. Student

COMSYS - Communication and Distributed Systems
RWTH Aachen University
Ahornstr. 55
52074 Aachen, Germany
Tel: +49 241 80-21422
ike.kunze@comsys.rwth-aachen.de<mailto:ike.kunze@comsys.rwth-aachen.de>
http://www.comsys.rwth-aachen.de/team/ike-kunze/