[Iotops] Review of draft-hsothers-iotsens-ps-02

Jan-Frederik Rieckers <rieckers@dfn.de> Wed, 12 October 2022 16:38 UTC

Return-Path: <rieckers@dfn.de>
X-Original-To: iotops@ietfa.amsl.com
Delivered-To: iotops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E21BC1527A1 for <iotops@ietfa.amsl.com>; Wed, 12 Oct 2022 09:38:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dfn.de
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 7aTEC7pHYqc9 for <iotops@ietfa.amsl.com>; Wed, 12 Oct 2022 09:38:27 -0700 (PDT)
Received: from c1004.mx.srv.dfn.de (c1004.mx.srv.dfn.de [IPv6:2001:638:d:c303:acdc:1979:2:58]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B74F8C15271C for <iotops@ietf.org>; Wed, 12 Oct 2022 09:38:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dfn.de; h= content-transfer-encoding:content-type:content-type:organization :subject:subject:from:from:content-language:user-agent :mime-version:date:date:message-id:received; s=s1; t=1665592700; x=1667407101; bh=lWPTOCRenw9icDEZOYy/e5di+Rs7Q3LagzNP4PvTPM4=; b= YsBY0fc9fY+2u79OWZVosv2+vB06RXZHKh3XRvR7OYUpplXDPD/WqA384smaP7/Y JxLiykf27AynHgFGkKGAOWD/4YfXldUvMioaM/8wG7zM+MI3SPiGspzvvGRRQ51y yCRPLF2sHUH7lrRc5m/DXptVVzuyR5HwqPpdSIkIIYs=
Received: from mail.dfn.de (mail.dfn.de [194.95.245.150]) by c1004.mx.srv.dfn.de (Postfix) with ESMTPS id A158C1200B0 for <iotops@ietf.org>; Wed, 12 Oct 2022 18:38:19 +0200 (CEST)
Received: from [IPV6:2001:638:d:1016::1000] (unknown [IPv6:2001:638:d:1016::1000]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mspool2.srv.dfn.de (Postfix) with ESMTPSA id B3E7A103 for <iotops@ietf.org>; Wed, 12 Oct 2022 18:38:18 +0200 (CEST)
Message-ID: <00c17a24-c856-e6ef-c268-b76d2dcb836f@dfn.de>
Date: Wed, 12 Oct 2022 18:38:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0
Content-Language: en-US
To: iotops@ietf.org
From: Jan-Frederik Rieckers <rieckers@dfn.de>
Organization: DFN e.V.
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/iotops/X6QSJVQVKrniioP5-gK-g0Xd2Ao>
Subject: [Iotops] Review of draft-hsothers-iotsens-ps-02
X-BeenThere: iotops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IOT Operations <iotops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iotops>, <mailto:iotops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iotops/>
List-Post: <mailto:iotops@ietf.org>
List-Help: <mailto:iotops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iotops>, <mailto:iotops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Oct 2022 16:38:31 -0000

Hi to all,

during the iotops session at IETF114 I volunteered to review the 
hsothers-iotsens-ps draft.
I am very sorry that it took me so long, but finally I can post this 
review here:



The direction this draft takes was not immediately clear to me, and I 
needed three reads of the introduction to come up with a hypothesis of 
what the draft is trying to say.
I have had brief contact with the authors who gave a short explanation 
of what the draft actually wants to accomplish. I would suggest to 
reword the abstract to explain more clearly what the draft is actually 
about.

Generally, I feel that the structure of the draft needs to be revised. 
Especially the introduction lists a number of use cases, where it was 
not really clear to me if the examples given are the desired or the 
undesired methods.
Clearly pointing out what "currently is" and what "will be" will help 
people reading the draft to get a clear picture.
The actual goal of the document is listed at the beginning of Section 3, 
so maybe the first sentence there (or its general statement) could be 
included in the abstract and introduction in some way.

Regarding the flow of reading I had a few problems to read the draft, 
which also lead to the high delay. (English is not my native language 
and I need to have the mental capacity for reading long or difficult texts).

The draft has a high number of long sentences, where it was not always 
clear to me how the sentence is structured, so it took me two or three 
attempts to read some sentences to understand them.
Also a number of sentences have parts in parentheses, sometimes 
excessively. This made it very difficult for me to get the actual 
statement of a sentence or even to keep track where in the sentence I was.
It also uses phrases where it is not always clear if it is a description 
or the name of a protocol/method/... (e.g. "LED light" in section 4.1).

The later sections (namely 4 and 5) appear to be in a early 
work-in-progress stage, from both a formal and content perspective.
Based on the sentence structure I assumed that at some point in the 
description of EAP-NOOB there should be an itemized list of steps, but 
it was displayed as continuous text.


I was also a bit puzzled by the explanation of EAP-NOOB in this draft. 
It seems to leave out quite a bit on what the protocol is actually about 
and includes things not specified in EAP-NOOB (e.g. 802.15.4, ZigBee and 
CoAP are not mentioned in RFC9140 at all, the smartphone does not 
necessarily need to be connected to the AAA server using 4G/5G, there is 
no specified need for user accounts on the server)

There are also issues in the explanation of BRSKI (e.g. mentioning the 
meaning of the abbreviation twice). I dindn't quite get why a BRSKI 
explanation was included in this draft in the first place.


In conclusion, although I find the general idea of using WiFi sensing as 
a possible Out-of-Band channel quite interesting, I do not feel that the 
  draft really explains (yet) how this could be used.
The problems with the current OOB methods are not explained in a 
structured understandable manner (at least from my understanding) and 
the benefits of using WiFi sensing are not clear.


Going forward I would suggest to the authors to restructure the draft, 
maybe even starting over with the complete text body based on a revised 
outline more fitted to the statement this draft wishes to communicate.
This would hopefully lead to a text with better flow of reading.



I hope this review helps the authors, and I would be happy to review 
upcoming versions (as far as my other work allows).


Greetings

Janfred

-- 
E-Mail: rieckers@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
Pronomen: er/sein | Pronouns: he/him
__________________________________________________________________________________

DFN - Deutsches Forschungsnetz | German National Research and Education 
Network
Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
www.dfn.de

Vorstand: Prof. Dr. Odej Kao (Vorsitzender) | Dr. Rainer Bockholt | 
Christian Zens
Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729B | USt.-ID. DE 1366/23822