Subject: [Tm-rid] Fwd: New Version Notification for draft-moskowitz-drip-crowd-sourced-rid-00.txt

From: Robert Moskowitz <[email-masked]>
Date: Thu, 12 Mar 2020 16:06:28 -0400

Besides changing the draft name to use drip rather than tmrid....

There is a NEW feature in this draft.

I did a little topological twist last night and realized that the 
Finders can provide information for the SPDP and UTM to create a 
monitoring map.  That is the geospace covered by active Finders. This 
allows authorized observers to not only see where there is UA activity, 
but also were there is not UA activity.

There is also an Appendix where for now is a place holder and actually a 
call for help/input.  That is:

If the Finder has LIDAR (or other active space monitoring technology) 
would it be able to find all UA within its observing area?  If so it 
could report that information to the SPDP and on to the UTM providing 
information on non-participating UAs.

What would it take to do this?  Are LIDARs being developed for connected 
cars have full hemisphere observation, or only at road level?  Could 
they distinguish between a hovering UA and a street light?

This could really open up the value for CS-RID Finders.

All comments welcomed.  I really need a co-author conversant in CBOR to 
help with the actual packet format and text for the ID.

Thanks!

-------- Forwarded Message --------
Subject: 	New Version Notification for 
draft-moskowitz-drip-crowd-sourced-rid-00.txt
Date: 	Thu, 12 Mar 2020 12:58:57 -0700
From: 	[email-masked]
To: 	Stuart Card <[email-masked]>, Adam Wiethuechter 
<[email-masked]>, Robert Moskowitz 
<[email-masked]>, Stuart W. Card <[email-masked]>

A new version of I-D, draft-moskowitz-drip-crowd-sourced-rid-00.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-drip-crowd-sourced-rid
Revision: 00
Title: Crowd Sourced Remote ID
Document date: 2020-03-12
Group: Individual Submission
Pages: 12
URL: 
https://www.ietf.org/internet-drafts/draft-moskowitz-drip-crowd-sourced-rid-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-moskowitz-drip-crowd-sourced-rid/
Htmlized: 
https://tools.ietf.org/html/draft-moskowitz-drip-crowd-sourced-rid-00
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-moskowitz-drip-crowd-sourced-rid

Abstract:
This document describes using the ASTM Broadcast Remote ID (B-RID)
specification in a "crowd sourced" smart phone environment to provide
much of the FAA mandated Network Remote ID (N-RID) functionality.
This crowd sourced B-RID data will use multi-lateration to add a
level of reliability in the location data on the Unmanned Aircraft
(UA). The crowd sourced environment will also provide a monitoring
coverage map to authorized observers.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Wed, 18 Mar 2020 06:47:40 +0000

Dear Bob,

I have few comments and hopefully can learn more about this draft from your reply.

In General, I like the crowd-sourcing idea considering the SWAP limitation of a UA. Add adding this feature, it indeed broaden the B-RID coverage by allowing the finders to do the proxy work. However this feature might only be useful for small UAs which can only fly around 400 feet. For commercial drones, that might not be helpful. Correct me if I am wrong.

I would suggest to change the “smart phone” in the introduction section to “internet-connect devices” or IoT devices. I believe the “Finders” should include not only phones also tablet, internet-connected watches or internet-connect vehicles and internet-connected devices as you mentioned in page 3.

Add the full name for SPDP (Supplemental Data Service Provider) in the introduction since this is the first time you mention it.

The definition of SPDP is not very clear to me. Is it an entity inside of an USS? Would be beneficial to provide a use case of SPDP even though it is out of scope for this draft?

I also concerned the trustworthy of the cs-rid data as you left out on section 3.2. My understanding of SPDP is like a Finder’s registration server. So there might be some connectivity related process between Finder and SPDP which is not elaborated in this draft, such as things like which protocol they might use TCP or UDP and how Finder’s ID is being assigned by SPDP?. Ignore those comments if that is also out of scope.

Would you provide a reference to the Apple "Find My Device" presentation at the International Association for Cryptographic Research’s Real World Crypto 2020 conference. It seems to me an important concept for people to understand how “Crowd Sourcing” is utilized by Apple, now here for TM-RID. I did a little dig in RWC’s website and their YouTube channel and could find the relevant reference.

I also suggest to add the definition of EDDSA.

And there are actually four public keys from your list in page 6. Will TLS be considered as one of them or it is just too heavy to use for this purpose?

Missing the conventions section which can be easily added:
  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP<https://tools.ietf.org/html/bcp14> 14<https://tools.ietf.org/html/bcp14> [RFC2119<https://tools.ietf.org/html/rfc2119>] [RFC8174<https://tools.ietf.org/html/rfc8174>] when, and only when, they appear in all capitals, as shown above.

W.r.t to your LIDAR detection for airborne UA, I am no expert of LIDAR but my understanding is that LIDAR uses lasers for scanning and it should be possible to identify a UA from the space as long as it’s in LIDAR’s range.  As matter of fact, using LIDAR not only can provide the GPS location of the UA also possible the fly path of UA by calculating the UA moving pattern. But please don’t take my words for it. ☺

And last, I would love do the labor work for the CBOR implementation once I know what is the end goal for this implementation. ☺

Sorry for the lengthy/silly comments. Looking forward to your feedback.

Best,
Shuai Zhao

From: Tm-rid <[email-masked]> on behalf of Robert Moskowitz <[email-masked]>
Date: Thursday, March 12, 2020 at 13:07
To: "[email-masked]" <[email-masked]>
Subject: [Tm-rid] Fwd: New Version Notification for draft-moskowitz-drip-crowd-sourced-rid-00.txt(Internet mail)

I did a little topological twist last night and realized that the Finders can provide information for the SPDP and UTM to create a monitoring map.  That is the geospace covered by active Finders.  This allows authorized observers to not only see where there is UA activity, but also were there is not UA activity.

There is also an Appendix where for now is a place holder and actually a call for help/input.  That is:

If the Finder has LIDAR (or other active space monitoring technology) would it be able to find all UA within its observing area?  If so it could report that information to the SPDP and on to the UTM providing information on non-participating UAs.

What would it take to do this?  Are LIDARs being developed for connected cars have full hemisphere observation, or only at road level?  Could they distinguish between a hovering UA and a street light?

All comments welcomed.  I really need a co-author conversant in CBOR to help with the actual packet format and text for the ID.

Thanks!

-------- Forwarded Message --------
Subject:

New Version Notification for draft-moskowitz-drip-crowd-sourced-rid-00.txt

Date:

Thu, 12 Mar 2020 12:58:57 -0700

From:

[email-masked]<mailto:[email-masked]>

To:

Stuart Card <[email-masked]><mailto:[email-masked]>, Adam Wiethuechter <[email-masked]><mailto:[email-masked]>, Robert Moskowitz <[email-masked]><mailto:[email-masked]>, Stuart W. Card <[email-masked]><mailto:[email-masked]>

Name: draft-moskowitz-drip-crowd-sourced-rid
Revision: 00
Title: Crowd Sourced Remote ID
Document date: 2020-03-12
Group: Individual Submission
Pages: 12
URL: https://www.ietf.org/internet-drafts/draft-moskowitz-drip-crowd-sourced-rid-00.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-drip-crowd-sourced-rid/
Htmlized: https://tools.ietf.org/html/draft-moskowitz-drip-crowd-sourced-rid-00
Htmlized: https://datatracker.ietf.org/doc/html/draft-moskowitz-drip-crowd-sourced-rid

Abstract:

The IETF Secretariat

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 18 Mar 2020 08:48:24 -0400

Shuai,

Thank for the comments.

On 3/18/20 2:47 AM, shuaiizhao(Shuai Zhao) wrote:
> In General, I like the crowd-sourcing idea considering the SWAP 
> limitation of a UA. Add adding this feature, it indeed broaden the 
> B-RID coverage by allowing the finders to do the proxy work. However 
> this feature might only be useful for small UAs which can only fly 
> around 400 feet. For commercial drones, that might not be helpful. 
> Correct me if I am wrong.
>

It comes down to radios on ground connected devices and transmission ranges.

So if the commercial drones are doing N-RID over a 900Mhz 802.16t 
PHY/MAC (there was good attendance at the Jan 802 wireless session for 
starting this up) or sat, then no ground listeners other than the 
commercial towers.  They MAY use B-RID for DAA (a point I missed in my 
FAA NPRM comments that a colleague here in Detroit area pointed out), 
they are probably out of range from ground listeners.

> I would suggest to change the “smart phone” in the introduction 
> section to “internet-connect devices” or IoT devices. I believe the 
> “Finders” should include not only phones also tablet, 
> internet-connected watches or internet-connect vehicles and 
> internet-connected devices as you mentioned in page 3.
>

I will do something to clean this up.

> Add the full name for SPDP (Supplemental Data Service Provider) in the 
> introduction since this is the first time you mention it.
>

Thanks.  Good catch.  This is supposed to be 'standard' writing style.

> The definition of SPDP is not very clear to me. Is it an entity inside 
> of an USS? Would be beneficial to provide a use case of SPDP even 
> though it is out of scope for this draft?
>

Oops.  All SPDP are being replaced with the proper: SDSP.

This is in FAA UAS CONOPS v 2.0 sec 2.3.2.3

Grumble...

> I also concerned the trustworthy of the cs-rid data as you left out on 
> section 3.2. My understanding of SPDP is like a Finder’s registration 
> server. So there might be some connectivity related process between 
> Finder and SPDP which is not elaborated in this draft, such as things 
> like which protocol they might use TCP or UDP and how Finder’s ID is 
> being assigned by SPDP?. Ignore those comments if that is also out of 
> scope.
>

Finders are registered, through some process out-of-scope here, to an 
SPDP, sec 4 alludes to this.

Perhaps more is needed in sec 4.

> Would you provide a reference to the Apple "Find My Device" 
> presentation at the International Association for Cryptographic 
> Research’s Real World Crypto 2020 conference. It seems to me an 
> important concept for people to understand how “Crowd Sourcing” is 
> utilized by Apple, now here for TM-RID. I did a little dig in RWC’s 
> website and their YouTube channel and could find the relevant reference.
>

I have also dug there, and did not find anything.  Nor on the video 
links.  A presenter is allowed to NOT provide any information, other 
that what the participants see, per IACR policy.  I suspect Apple took 
that option.  There is little out there, I did see one screen capture on 
a blog:

https://blog.ironcorelabs.com/highlights-from-real-world-crypto-2020-91f4d8b01915

https://miro.medium.com/max/1024/1*Yv_iCTl6R9mzo_JRStrZ1A.jpeg

> I also suggest to add the definition of EDDSA.

RFC 8032.  Added.

> And there are actually four public keys from your list in page 6. Will 
> TLS be considered as one of them or it is just too heavy to use for 
> this purpose?
>

You mean Authenticating messaging options?  Not really "public keys".  
TLS seems too much state for this purpose.  UDP is for many reasons the 
way to go; I just did not feel it was worth explaining that.

> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>
>    "OPTIONAL" in this document are to be interpreted as described in 
> BCP <https://tools.ietf.org/html/bcp14> 14 
> <https://tools.ietf.org/html/bcp14> [RFC2119 
> <https://tools.ietf.org/html/rfc2119>] [RFC8174 
> <https://tools.ietf.org/html/rfc8174>] when, and only when, they 
> appear in all capitals, as shown above.
>

Sec 2.1?

> W.r.t to your LIDAR detection for airborne UA, I am no expert of LIDAR 
> but my understanding is that LIDAR uses lasers for scanning and it 
> should be possible to identify a UA from the space as long as it’s in 
> LIDAR’s range.  As matter of fact, using LIDAR not only can provide 
> the GPS location of the UA also possible the fly path of UA by 
> calculating the UA moving pattern. But please don’t take my words for 
> it. ☺
>

I am actively doing research on this.  According to one prof at Michigan 
State Univ (my alma mater) there are two coverage patterns:  cylinder 
and hemisphere; we need the later.  And range is 20 - 250M.  We want 30M 
minimum.

> And last, I would love do the labor work for the CBOR implementation 
> once I know what is the end goal for this implementation. ☺
>

We will talk more then!

> *From: *Tm-rid <[email-masked]> on behalf of Robert Moskowitz 
> <[email-masked]>
> *Date: *Thursday, March 12, 2020 at 13:07
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[Tm-rid] Fwd: New Version Notification for 
> draft-moskowitz-drip-crowd-sourced-rid-00.txt(Internet mail)
>
> allows authorized observers to not only see where there is UA 
> activity, but also were there is not UA activity.
>
> What would it take to do this?  Are LIDARs being developed for 
> connected cars have full hemisphere observation, or only at road 
> level?  Could they distinguish between a hovering UA and a street light?
>
> All comments welcomed.  I really need a co-author conversant in CBOR 
> to help with the actual packet format and text for the ID.
>
> Thanks!
>
>
>
> *Subject: *
> *Date: *
> *From: *
> [email-masked] <mailto:[email-masked]>
>
> *To: *
>
> 	
>
> Stuart Card <[email-masked]> 
> <mailto:[email-masked]>, Adam Wiethuechter 
> <[email-masked]> 
> <mailto:[email-masked]>, Robert Moskowitz 
> <[email-masked]> <mailto:[email-masked]>, Stuart 
> W. Card <[email-masked]> <mailto:[email-masked]>
>
>
>
>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email-masked]

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

---

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Fri, 20 Mar 2020 02:02:33 +0000

Thanks Bob,

Tencent recently joined ASTM as an organization membership. However, it looks like we still don’t have the access to WK65041. Do you know what takes to get a copy of that?

Best,
Shuai Zhao

From: Robert Moskowitz <[email-masked]>
Date: Wednesday, March 18, 2020 at 05:49
To: "shuaiizhao(Shuai Zhao)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Tm-rid] Fwd: New Version Notification for draft-moskowitz-drip-crowd-sourced-rid-00.txt(Internet mail)

Shuai,

Thank for the comments.

So if the commercial drones are doing N-RID over a 900Mhz 802.16t PHY/MAC (there was good attendance at the Jan 802 wireless session for starting this up) or sat, then no ground listeners other than the commercial towers.  They MAY use B-RID for DAA (a point I missed in my FAA NPRM comments that a colleague here in Detroit area pointed out), they are probably out of range from ground listeners.

Grumble...

Finders are registered, through some process out-of-scope here, to an SPDP, sec 4 alludes to this.

I have also dug there, and did not find anything.  Nor on the video links.  A presenter is allowed to NOT provide any information, other that what the participants see, per IACR policy.  I suspect Apple took that option.  There is little out there, I did see one screen capture on a blog:

RFC 8032.  Added.

You mean Authenticating messaging options?  Not really "public keys".  TLS seems too much state for this purpose.  UDP is for many reasons the way to go; I just did not feel it was worth explaining that.

Sec 2.1?

I am actively doing research on this.  According to one prof at Michigan State Univ (my alma mater) there are two coverage patterns:  cylinder and hemisphere; we need the later.  And range is 20 - 250M.  We want 30M minimum.

We will talk more then!

Best,
Shuai Zhao

From: Tm-rid <[email-masked]><mailto:[email-masked]> on behalf of Robert Moskowitz <[email-masked]><mailto:[email-masked]>
Date: Thursday, March 12, 2020 at 13:07
To: "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: [Tm-rid] Fwd: New Version Notification for draft-moskowitz-drip-crowd-sourced-rid-00.txt(Internet mail)

Thanks!

-------- Forwarded Message --------
Subject:

Date:

From:

To:

Abstract:

The IETF Secretariat

--
Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      [email-masked]<mailto:[email-masked]>

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

---

From: "Stuart W. Card" <[email-masked]>
Date: Sun, 22 Mar 2020 21:07:34 -0400

On 3/18/2020 8:48 AM, Robert Moskowitz wrote:
> ...
>> ...
> Thanks.  Good catch...
> This is in FAA UAS CONOPS v 2.0 sec 2.3.2.3...

For all those not yet familiar with UAS Traffic Management (UTM): a SDSP
is an entity that participates in the UTM system, but provides services
beyond those specified as basic UTM system functions, thus "supplemental
data". This includes e.g. weather but also specifically "surveillance".
In addition to the section 2.3.2.3 Bob already cited, see Figure 3 on
page 9 of the FAA UTM CONOPS v2.0 at

https://www.faa.gov/uas/research_development/traffic_management/media/UTM_ConOps_v2.pdf

- -- 
- -----------------------------------------
Stuart W. Card, PhD, Principal Engineer
AX Enterprize, LLC  www.axenterprize.com
4947 Commercial Drive, Yorkville NY 13495

---

From: "Da Silva, Saulo" <[email-masked]>
Date: Mon, 23 Mar 2020 16:28:22 +0000

Hi Rob.
I just read the draft-moskowitz-tmrid-crowd-sourced-rid, and to have a regulation that can be harmonized on a global basis, some definitions should be aligned with what the international civil aviation community is doing.
Some examples are:
1) CAA- it means Civil Aviation Authority, and not "Civil Aeronautics Administration".  By the same token, we should avoid using FAA as an example considering its structure and the fact that this makes the document very much US centric.
2) UA - Unmanned aircraft. To be coherent with the civil aviation vocabulary it should be simply: "An aircraft which is intended to operate with no pilot on board." This definition took years to be accepted by the global aviation community and changing it now will for sure bring other discussions that would not help to progress the document.
3) UTM - UAS Traffic Management - This definition refers to only FAA which is only one service provider/regulator. Besides UTM is not for uncontrolled operations considering that a set of standards are to be specified for this type of operations to be able to be harmonized with the current ATM operations. To serve the global community the international civil aviation community defines as: "Unmanned aircraft system traffic management (UTM). A specific aspect of air traffic management which manages UAS operations safely, economically and efficiently through the provision of facilities and a seamless set of services in collaboration with all parties and involving airborne and ground-based functions."

Saulo

-----Original Message-----
From: Tm-rid [mailto:[email-masked]] On Behalf Of Stuart W. Card
Sent: 22-Mar-20 9:08 PM
To: [email-masked]
Cc: Robert Moskowitz <[email-masked]>; shuaiizhao(Shuai Zhao) <[email-masked]>
Subject: Re: [Tm-rid] Fwd: New Version Notification for draft-moskowitz-drip-crowd-sourced-rid-00.txt(Internet mail)

On 3/18/2020 8:48 AM, Robert Moskowitz wrote:
>> Add the full name for SPDP (Supplemental Data Service Provider) in 
>> the introduction since this is the first time you mention it.
> 
> Thanks.  Good catch...
> 
>> The definition of SPDP is not very clear to me. Is it an entity 
>> inside of an USS? Would be beneficial to provide a use case of SPDP 
>> even though it is out of scope for this draft?
> 

For all those not yet familiar with UAS Traffic Management (UTM): a SDSP is an entity that participates in the UTM system, but provides services beyond those specified as basic UTM system functions, thus "supplemental data". This includes e.g. weather but also specifically "surveillance".
In addition to the section 2.3.2.3 Bob already cited, see Figure 3 on page 9 of the FAA UTM CONOPS v2.0 at

https://secure-web.cisco.com/1A3wOE80fvI-riblc4bdaOYD9-TsI8esXlH0YANnXUgdE70i5edKVycupDHMOHq_5jwixtIG4rFf-4F6s9tiTdqjlSBV_Y3O65Lg4Ujqyeks47fHXEMxv3aiJHBqZCT68Ldxdz6skl9jWCny25pd1R1t_XZq3UpcSPe_vB95hh7i363JNCGwKYg7hr-c8cbtf82zVo0RZLLYc9CTBTRzzlpPr4aMnMau41JH9e2Z_h_zyTk20COzJCGrwsJzVIFykayZWM_kdXSyykMesbnel8jL2VvUcuZMt9acVSNDjwV3bDEC3cFJU46lGvGcUMNqOJyqIdOeB6FiHhlvOhXOqkg/https%3A%2F%2Fwww.faa.gov%2Fuas%2Fresearch_development%2Ftraffic_management%2Fmedia%2FUTM_ConOps_v2.pdf

- --
- -----------------------------------------
Stuart W. Card, PhD, Principal Engineer
AX Enterprize, LLC  www.axenterprize.com
4947 Commercial Drive, Yorkville NY 13495 -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://secure-web.cisco.com/19CVXTs-TpbAXvsMztg7cl_DrzVRgde9qbzq-hkIIPDxBjgWfZQ_-ZyOYI_IP-QpoyKi10xvag9L8JOUZVwuA-ajksRwXYRG65xp-U8k0ghPa4O0R1e89pw5vIDbMqpq58SX4pYTY3uj8h122YFcdRJCPHKCwFyL5nrNQ7r1Nszv-Kbpmg7TNH7ERcv-ul-gGslLw7mP3o4lcesfrE4nPcqtxfngyxQjMO-Iy8FFtNETHM5dUrzqtJEU92hjAB0u-frJiwyCkQ_lH6AcbgLjDqgJz2ovWZNJYFtkJIlOTHxOnFHa3d3BJL-YzdZo7kD4q/http%3A%2F%2Fenigmail.mozdev.org%2F

iEYEARECAAYFAl54C9YACgkQS7PQ0a2weL5i/QCfa5AuR4Tw0k5hPwWS3cKiCk9w
iooAoJWE1VFa4SwjENMBUjvq5VIyDJ3Q
=y4Rv
-----END PGP SIGNATURE-----

--
Tm-rid mailing list
[email-masked]
https://secure-web.cisco.com/1z2W70f9P10BQjqR6I3Vt1lKjlcXz_T_i588YB26cdsyDPGPihs2uC6dXNIzcg2XjrwXRzihKzeaQMLNYLtvSuWuEfWgUoW5bwQNpiKwwxVBe23yk-BAVoeQYbHC8yJNSXcctjPtFZ9FpRE8q5VB8EJqagU6vkin7MSp1R2qT-M6CkXQ7Q09MvEz8Cwd8rQ7qu3K5G9v9kY9RTSknfKVq-mXSENuphxOHue21RyH3AMJV3Jd0UASdA--9A0VqaRuBIj5KfcWQWPR8ROQMK8TOiNSxVkCfcQ2rnlS2g_WS8yvF6Xz11j6Yk3jpbqAPbMCsEeK72gaUb6EcRNb30CXXPA/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftm-rid

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 23 Mar 2020 12:31:46 -0400

Thanks Saulo,

I will get these into the next rev.

Bob

On 3/23/20 12:28 PM, Da Silva, Saulo wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

---

From: "Card, Stu" <[email-masked]>
Date: Mon, 23 Mar 2020 12:59:28 -0400

Thanks Saulo! Harmonizing globally, in part by aligning definitions &
engaging with ICAO (inc. but not limited to IATF/GRAIN), will be essential,
and we need your help with that.

On Mon, Mar 23, 2020, 12:28 Da Silva, Saulo <[email-masked]> wrote:

> Hi Rob.
> I just read the draft-moskowitz-tmrid-crowd-sourced-rid, and to have a
> regulation that can be harmonized on a global basis, some definitions
> should be aligned with what the international civil aviation community is
> doing.
> Some examples are:
> 1) CAA- it means Civil Aviation Authority, and not "Civil Aeronautics
> Administration".  By the same token, we should avoid using FAA as an
> example considering its structure and the fact that this makes the document
> very much US centric.
> 2) UA - Unmanned aircraft. To be coherent with the civil aviation
> vocabulary it should be simply: "An aircraft which is intended to operate
> with no pilot on board." This definition took years to be accepted by the
> global aviation community and changing it now will for sure bring other
> discussions that would not help to progress the document.
> 3) UTM - UAS Traffic Management - This definition refers to only FAA which
> is only one service provider/regulator. Besides UTM is not for uncontrolled
> operations considering that a set of standards are to be specified for this
> type of operations to be able to be harmonized with the current ATM
> operations. To serve the global community the international civil aviation
> community defines as: "Unmanned aircraft system traffic management (UTM). A
> specific aspect of air traffic management which manages UAS operations
> safely, economically and efficiently through the provision of facilities
> and a seamless set of services in collaboration with all parties and
> involving airborne and ground-based functions."
>
> Saulo
>
>
>
>
>
> Subject: Re: [Tm-rid] Fwd: New Version Notification for
> Comment: Using GnuPG with Mozilla -
> http://secure-web.cisco.com/19CVXTs-TpbAXvsMztg7cl_DrzVRgde9qbzq-hkIIPDxBjgWfZQ_-ZyOYI_IP-QpoyKi10xvag9L8JOUZVwuA-ajksRwXYRG65xp-U8k0ghPa4O0R1e89pw5vIDbMqpq58SX4pYTY3uj8h122YFcdRJCPHKCwFyL5nrNQ7r1Nszv-Kbpmg7TNH7ERcv-ul-gGslLw7mP3o4lcesfrE4nPcqtxfngyxQjMO-Iy8FFtNETHM5dUrzqtJEU92hjAB0u-frJiwyCkQ_lH6AcbgLjDqgJz2ovWZNJYFtkJIlOTHxOnFHa3d3BJL-YzdZo7kD4q/http%3A%2F%2Fenigmail.mozdev.org%2F
>

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 23 Mar 2020 13:09:10 -0400

> 1) CAA- it means Civil Aviation Authority, and not "Civil Aeronautics Administration".  By the same token, we should avoid using FAA as an example considering its structure and the fact that this m…

I should point out it was the FAA's NPRM move away from B-RID that was 
the root of this idea, and I do want to capture that in the 
Introduction.  From there, focusing on CAA sounds right.

 From the few comments on the NPRM that I saw, it seems the FAA's 
position as at odds with other CAAs, but CS-RID would benefit all.