Re: [Last-Call] [Drip] Iotdir telechat review of draft-ietf-drip-auth-45

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


From: Stu Card <stu.card@xxxxxxxxxxxxxxxx>
Sent: Tuesday, January 23, 2024 1:12:11 PM
To: Robert Moskowitz <rgm@xxxxxxxxxxxxxxxxxxxx>; Behcet Sarikaya <sarikaya@xxxxxxxx>; iot-directorate@xxxxxxxx <iot-directorate@xxxxxxxx>
Cc: draft-ietf-drip-auth.all@xxxxxxxx <draft-ietf-drip-auth.all@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx>; tm-rid@xxxxxxxx <tm-rid@xxxxxxxx>; gen-art@xxxxxxxx <gen-art@xxxxxxxx>
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 <rgm@xxxxxxxxxxxxxxxxxxxx>
Sent: Monday, January 22, 2024 11:00:54 PM
To: Behcet Sarikaya <sarikaya@xxxxxxxx>; iot-directorate@xxxxxxxx <iot-directorate@xxxxxxxx>
Cc: draft-ietf-drip-auth.all@xxxxxxxx <draft-ietf-drip-auth.all@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx>; tm-rid@xxxxxxxx <tm-rid@xxxxxxxx>; gen-art@xxxxxxxx <gen-art@xxxxxxxx>
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:      rgm@xxxxxxxxxxxxxxxxxxxx

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


-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux