Resend as the last part of my sent message did not reach my inbox through the 
lists.

Sent from my Verizon, Samsung Galaxy smartphone
Get Outlook for Android<https://aka.ms/AAb9ysg>

________________________________
From: Stu Card <stu.c...@axenterprize.com>
Sent: Tuesday, January 23, 2024 1:12:11 PM
To: Robert Moskowitz <r...@labs.htt-consult.com>; Behcet Sarikaya 
<sarik...@ieee.org>; iot-director...@ietf.org <iot-director...@ietf.org>
Cc: draft-ietf-drip-auth....@ietf.org <draft-ietf-drip-auth....@ietf.org>; 
last-c...@ietf.org <last-c...@ietf.org>; tm-...@ietf.org <tm-...@ietf.org>; 
gen-art@ietf.org <gen-art@ietf.org>
Subject: Re: [Drip] Iotdir telechat review of draft-ietf-drip-auth-45

Thanks for the IoTdir review!

Bob has answered the ASTM name question. As to why IETF rather than ASTM: the 
latter is a fine SDO for _aviation_ standards; but immediately actionable, 
trustworthy UAS RID requires expertise in strong cryptographic network 
protocols; so we brought the work of extending this ASTM standard to IETF.

Adam will check whether any acronyms or terms are missing from this draft's 
Section 2 Terminology and the therein referenced RFC 9153 DRIP Requirements & 
Terminology, then add any that are missing.

Extended transports are specified in ASTM F3411 and listed in this draft's 
Section 2.2. Both legacy & extended _Broadcast_ RID transports are direct use, 
by the RID application, of link layers, so do not admit an IP stack. _Network_ 
RID indeed uses an IP stack, but that will be the subject of a later separate 
DRIP document; the scope of this current draft is only broadcast.

Thanks for catching our failure to cite RFC 9374 on our first use of HI & DET; 
Adam is editing the draft to fix that as I write this email. :-)

We agree that most UAS today are IoT devices (even if not typically thought of 
as such) and that some of the work done in the DRIP WG for the urgent primary 
objective of trustworthy UAS RID is likely to be more broadly applicable to 
IoT. We will add text to this effect.

Expect a minimally revised draft very soon. Thanks!

________________________________
From: Robert Moskowitz <r...@labs.htt-consult.com>
Sent: Monday, January 22, 2024 11:00:54 PM
To: Behcet Sarikaya <sarik...@ieee.org>; iot-director...@ietf.org 
<iot-director...@ietf.org>
Cc: draft-ietf-drip-auth....@ietf.org <draft-ietf-drip-auth....@ietf.org>; 
last-c...@ietf.org <last-c...@ietf.org>; tm-...@ietf.org <tm-...@ietf.org>; 
gen-art@ietf.org <gen-art@ietf.org>
Subject: Re: [Drip] Iotdir telechat review of draft-ietf-drip-auth-45

Actually, ASTM changed their name to just ASTM International.

Kind of like Dominican Factory Steel of Canada becoming DFaSCO or something 
like that so they did not have to come up with an equivalent French name for 
Quebec .  ASTM wanted to put on an international name so dropped the old 
expansion.  You will still find it, but they don't use it.

On 1/22/24 15:10, Behcet Sarikaya via Datatracker wrote:

Reviewer: Behcet Sarikaya
Review result: Ready with Issues

I am the assigned reviewer of this draft for IoTdir.

The draft’s main purpose seems to be to define trusted authentication in 
Unmanned Aircraft
 Systems. Trust is provided by way of enhancing the previously defined F3411 
protocol
 with a registration hierarchy.

>From IoT perspective, integration of drones with IoT is very important but IoT 
>is not even
 mentioned in the draft. In the Introduction, second paragraph mentions UAS RID 
must also
 be accessible with ubiquitous and inexpensive devices without modification 
which should
 probably add IoT there.

The draft is missing an RFC reference for Host Identity.
In Section 6.2, no example is given for extended transports. Since legacy 
transport is
link layer, the extended transport should contain an IP stack.

The draft would benefit a lot from the addition of a list of acronyms for 
readability.

ASTM stands for American Society for Testing and Materials.
The acronym is heavily used in the draft but never expanded.
The protocol F3411 mentioned above was developed by ASTM.
I personally wondered why this work (and its derivatives) also could not be
developed at ASTM.




--
Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      r...@labs.htt-consult.com<mailto:r...@labs.htt-consult.com>

There's no limit to what can be accomplished if it doesn't matter who gets the 
credit


_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to