Subject: [Tm-rid] comments on draft-card-tmrid-uas

From: Daniel Migault <[email-masked]>
Date: Wed, 18 Mar 2020 14:05:53 -0400

Hi,

Please find my comments for draft-card-tmrid-uas-01. At this stage it is
unclear to me if there will be an informational use case document. I do not
believe that is necessary, so I do not necessarily expect the document
being updated. As the text is the use case and requirements document might
be common, I believe that comments provided should probably be addressed in
the requirement document.

Some comments or questions are clearly due to my lake of knowledge of the
UAS ecosystem. I guess other people will find themselves in the same
situation and it would be good to describe the different elements that are
expected to interact between each other in the scope of DRIP.

Yours,
Daniel

                             UAS Remote ID
                        draft-card-tmrid-uas-01

1.  Introduction

[...]
   ASTM International, Technical Committee F38 (UAS), Subcommittee
   F38.02 (Aircraft Operations), Work Item WK65041 (UAS Remote ID and
   Tracking), is a Proposed New Standard [WK65041].  It defines 2 means
   of UAS remote identification (RID): Network RID via the Internet; and
   Broadcast RID via a one-way data link direct from the Unmanned
   Aircraft (UA) to the observer's device.  Network RID depends upon
   Internet connectivity between the observer and either the UA itself
   or any of various proxies.  Broadcast RID should need Internet (or
   other Wide Area Network) connectivity only for UAS registry
   information lookup using the directly locally received UAS ID as a
   key.

<mglt>
At this stage of the document it am wondering if there are two different
types of RIDs versus different ways the RID is received/collected. In the
case of Network RID there do not seem to have radio constraints and so the
these constraints only seem to apply to the broadcast scenario.

I am usually tempted to have an ID that is independent from the way it is
received collected, thought the RID format needs to adapt the constraints
associated to the transport used.
</mglt>

[...]
   The need for near-universal deployment of UAS RID is pressing.  This
   implies the need to support use by observers of already ubiquitous
   mobile devices (smartphones and tablets).
<mglt> This sounds like an operational requirement that the technology we
design should be easily implemented on common devices. I keep this as a
note for the requirement document. This also make me think that we might
have to clarify how trusted these devices will be. I would be tempted to
considered them as untrusted.
</mglt>

 [...]
   Heavyweight security protocols are infeasible, yet trustworthiness of
   UAS RID information is essential.  Even the most basic datum, the UAS
   ID string (typically number) itself, under [WK65041], can be merely
   an unsubstantiated claim.

<mglt>Though it is always better to have something lightweight, I am
wondering where the lightweight constraint comes from. In term of
bandwidth, I understand a limited size that fits Bluetooth or other radio
protocol, and we expect the length to fit the radio frames. What is unclear
to me is the necessity of having limited resources associated to the
encryption or security processing. It would be fine to clarify which are
the targeted resources.
</mglt>

   Further, an ID is not an end in itself; it exists to enable lookups
   and provision of services complementing mere identification, e.g.
   dynamic establishment of secure communications between the observer
   and the UAS pilot.  [WK65041] neither fully specifies nor appears to
   facilitate these functions, especially in the case where the observer
   lacks real time Internet access.

   Finally, [WK65041] proposes the use of plaintext and mostly static
   UAS ID strings.

<mglt>plaintext probably needs additional clarifications. I am wondering if
it means a specific byte format such as ascii/UTF-8 text or simply human
readable ? If that is a requirement I expect to find it in the requirement
draft.
</mglt>

[...]
2.  Terms and Definitions
[...]
3.1.  Network RID

   Network RID has several variants.  The UA may have persistent onboard
   Internet connectivity, in which case it can consistently source RID
   information directly over the Internet.

<mglt> If I understand this Network RID concept, it means the drone is
typically updating its information on a given server located in a data
center for example via the GCS. </mglt>

   The UA may have intermittent
   onboard Internet connectivity, in which case a proxy must source RID
   information whenever the UA itself is offline.  The UA may not have
   Internet connectivity of its own, but have instead some other form of
   communications to a (typically ground) node that can relay RID
   information to the Internet; this would typically be the GCS (which
   to perform its function must know where the UA is) or USS (which in
   the UTM system is required to be kept informed by the UAS operator).
   The UA may have no means of sourcing RID information, in which case
   the GCS, USS or other proxy may source it.  In the extreme case, this
   would be the pilot using a web browser to designate, to a USS or
   other UTM entity, a time-bounded airspace volume in which an
   operation will be conducted; this may impede disambiguation of ID if
   multiple UAS operate in the same or overlapping spatio-temporal
   volumes.

<mglt>
If I understand correctly this scenario, in this case the information is
not updated directly by the drone itself, but instead by a proxy. The drone
is connected to that proxy. At first, at first if the proxy is simply
relaying the information from the UA, the two scenario seems similar in
some ways. I suppose the second scenario considers the proxy as originating
the information about the UA. I do not necessarily understand the need of a
proxy for updating information related to the UAS. However, I would
consider it useful mostly for real-time responses when the UAS is not
directly reachable. Am I correctly understanding the purpose of the proxy ?
</mglt>

   In most cases in the near term, if the RID information is fed to the
   Internet directly by the UA or remote pilot, the first hop data links
   will be cellular Long Term Evolution (LTE) or WiFi, but provided the
   data link can support at least IP and ideally TCP, its type is
   generally immaterial to the higher layer protocols.  The ultimate
   source of Network RID information feeds a RID Service Provider (SP),
   which essentially proxies for that and other sources; the ultimate
   consumer of Network RID information obtains it from a RID Display
   Provider (DP).  Each DP aggregates information from all SPs that have
   UA currently operating in the airspace for which that DP is
   cognizant.

<mglt>
I expect the following elements to be represented in the architecture
document:
*  The ultimate source of Network RID information: the UAS or drone
*  RID Service Provider (SP): the entity collecting the UAS information. I
see this mostly as a data base.
*  RID Display Provider (DP): a client to collect the information stored in
the data base. I see this as the application used by a third party that
request and present the necessary information related to an observed drone
to let me decide if the drone is authorized or not.

What would probably need to be clarified in the architecture document or
the requirement document is the trust model we are relying on. Is the
information authenticated by the SP or the UAS ? Similarly, information
from the UA may come from the pilot or the owner as well as the UA
manufacturer.... I have the impression that the origin of the information
will play a major role in the trust associated to the information.
</mglt>

   Network RID is the more flexible and less constrained of the UAS RID
   means specified in [WK65041].  Any IETF work needed to support or
   leverage it is left for later efforts; it is not further addressed
   herein or in other initial tm-rid documents.

3.2.  Broadcast RID

 [...]

   The selection of the Broadcast medium was driven by research into
   what is commonly available on 'ground' units (smartphones and
   tablets) and what was found as prevalent or 'affordable' in UA.
   Further, there must be an API for the UAS receiving application to
   have access to these messages.  At this time, only Bluetooth 4.X
   support is readily available, thus the current focus is on working
   within the 26 byte limit of the Bluetooth 4.X "Broadcast Frame" that
   goes out on the beacon channels.

<mglt>
The assumption is, I suppose that we do not want to have the ID being split
into multiple frames.
</mglt>

 [...]
3.3.  TM-RID Focus Problem Space

   TM-RID will focus on adding immediate usability, thus trust to,
   Broadcast RID.  The one-way nature of Broadcast RID precludes any
   stateful security protocol.  Under [WK65041], any UA can announce a
   RID and an observer would be seriously challenged to validate it or
   any other information about the UA looked up from it.  Thus providing
   trust in the RID and related trust for all Broadcast messages is
   critical for the safe and secure operation of UAs.

<mglt>
The paragraph above is a bit unclear to me, especially the sentences:
"""
The one-way nature of Broadcast RID precludes any
   stateful security protocol.
"""

I am reading it as broadcasting makes it hard to send authenticated
messages that could be checked without prior knowledge. broadcasting
authenticated information does not for example seems sufficient as the key
will be needed to check the signature as well as information of the key
owner. All these information is likely to require more than 26 bytes. Am I
correctly understanding the sentence above ?
</mglt>

   Three levels of functionality will be considered:

   1.  verify that HHIT is duly registered with a known registry AND
       that any messages signed with its key came from it;

   2.  look up not only static UAS registry and dynamic UTM information
       but also Intenet direct contact information for services relating
       to the UA, its current mission, etc., including communications
       with the remote pilot (or proxy) and USS;

   3.  dynamically establish strongly mutually authenticated, E2E
       strongly encrypted communications with the UAS RID sender and
       entities looked up via (2) above.

<mglt>

3. seems to indicate the UAS RID is the RID SP. Is that correct ?

One thing that comes to my mind reading these lines is that care should be
brought to avoid an RID broadcast to be replayed. It might be what 3. is
trying to catch with "dynamic" connection, but this may be a little bit
harder if authentication is provided by the UAS while connectivity is set
with the RID SP.

</mglt>

4.  Alternatives for IETF work on Trustworthy IDs

-- 
Daniel Migault
Ericsson

---

From: "Wiethuechter, Adam" <[email-masked]>
Date: Wed, 18 Mar 2020 16:01:11 -0400

Daniel,

Thanks for the thorough comments on Stu's draft. While I am not Stu (I
hope), I have enough knowledge to answer most of your questions.
My comments to yours are interspersed and in red.

> associated to the transport used.

<atw>
You are correct that there are two different ways RID is collected
(Broadcast and Network). Broadcast the constraint of the physical wireless
link and various existing protocol overheads associated with it. Network
has less constraints to it as it is "just connected to the Internet the way
it can".

In regards to having "an ID that is independent from the way it is received
collected" I think that having two different IDs is just a bad idea. The
main reason is that in the FAA NPRM it is noted that a UA under the
Standard RID rules MUST do both Broadcast and Network. This can be found on
page 74 of the NPRM.
</atw>

> encryption or security processing. It would be fine to clarify which are

<atw>
While this may change in the near future (as we continue to improve
hardware) many legacy UA do not have the processing power necessary to
perform encryption/security processing fast enough. This can be fixed with
adding addition processors to existing airframes (thus increasing cost,
weight, etc). Newer UA being built (or special built) can be designed to
accommodate such requirements, but its still up to the UA manufacturer to
include them. Which they may not as a cost cutting feature.
</atw>

> <mglt>plaintext probably needs additional clarifications. I am wondering
> if it means a specific byte format such as ascii/UTF-8 text or simply human
<atw>
Noted, that is a difference.
</atw>

[...]
> center for example via the GCS. </mglt>
<atw>
Yes. The UA and/or GCS is updating a server (called the RID Service
Provider). In the FAA Standard RID rule the UA MUST operate Broadcast RID
and either the UA (at the same time) or the GCS MUST operate Network RID.
Under the FAA Limited RID rule ONLY the GCS operates Network RID - it is
illegal for the UA to also be broadcasting.

I will repeat this here that we need to agree on the terms to use. Yes the
FAA and ASTM use different terms to mean the same thing, we need to pick
one of them and stick with it. I believe in our interim slides I created a
handy table doing just this.
</atw>

> directly reachable. Am I correctly understanding the purpose of the proxy ?
<atw>
I do believe you understand this part. Stu can amend my comment otherwise.
</atw>

> *  RID Display Provider (DP): a client to collect the information stored
> in the data base. I see this as the application used by a third party that

<atw>
I think you have all the pieces here and understand their basic
relationship. Now to your questions.

"Is the information authenticated by the SP or the UAS ?"
Not in scope for the ASTM or the FAA so as it stands now; no. ASTM
"provides" the API of the RID Service Provider end-points. How or if this
is secured via authentication is up to the implementer of said UA, GCS,
and/or RID Service Provider and its (unfortunately most of the time
proprietary) software.
</atw>

> The assumption is, I suppose that we do not want to have the ID being
> split into multiple frames.
> </mglt>
>

<atw>
Oh how optimistic you are. One of the severe shortcomings of the ASTM
standard IMO is that the ID is found in ONE message type (Basic ID). In no
other message is it provided meaning its completely detached. The vector
message of ASTM Broadcast RID has all the information for vector
information, but no ID field to link it to a UA. This is done by using the
MAC address to correlate messages.
</atw>

> correctly understanding the sentence above ?

<atw>
This is something Stu will need to answer, after re-reading this even I am
a bit mythed.
</atw>

> 4.  Alternatives for IETF work on Trustworthy IDs
<atw>
I'm sure what you mean by UAS RID here. What Stu is refering to here is
that in case contact needs to be made with the pilot it can be a simple hit
the button and you have a connection to the guy in question. For obvious
reasons we would want this to have the properties he listed (E2E, strong
encryption, etc). This is between the Observer device and the Pilot device
(not the UA and the RID SP).
</atw>

> --
> Daniel Migault
> Ericsson
> --
> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>

Some closing thoughts, I think if we agree on the terms to use the
confusion might be mitigated. We also need to elaborate more where Daniel
has pointed out. Your feedback is extremely helpful as myself, Stu and Bob
have had ours heads in this for a number of months and are used to the
confusion. A new set (or sets) of eyes is extremely helpful to get our
explinations clearer.

-- 
73's,
Adam T. Wiethuechter
AX Enterprize, LLC

---

From: Daniel Migault <[email-masked]>
Date: Thu, 19 Mar 2020 10:40:03 -0400

Thanks for the clarifications!
Yours,
Daniel

On Wed, Mar 18, 2020 at 4:01 PM Wiethuechter, Adam <
[email-masked]> wrote:

> In regards to having "an ID that is independent from the way it is
> received collected" I think that having two different IDs is just a bad
> idea. The main reason is that in the FAA NPRM it is noted that a UA under
> the Standard RID rules MUST do both Broadcast and Network. This can be
> found on page 74 of the NPRM.
> </atw>
>

<mglt>
I agree that having two format should be avoided. It is good to know that
UA must advertise their RID in both ways. What I am wondering if  - at
least in principle -  anything I can ask directly the UA could be asked to
the GCS as well. Static information is easy, but what I am wondering is
regarding dynamic information such as the position of the UA.
</mglt>

>> *  RID Service Provider (SP): the entity collecting the UAS information.
>> I see this mostly as a data base.
>> One thing that comes to my mind reading these lines is that care should
>> be brought to avoid an RID broadcast to be replayed. It might be what 3. is

-- 
Daniel Migault
Ericsson

---

From: "Wiethuechter, Adam" <[email-masked]>
Date: Thu, 19 Mar 2020 11:09:47 -0400

In theory, yes. It all depends on the control link between the UA and GCS.

I just discussed with someone here at AX and they said below a certain
price point the control links are generally one-way themselves (he cited
that some use PWM). Unless your GCS can show more information (such as UA
battery health, distance from Pilot, etc) then it's safe to assume that the
GCS has no information on the UA (due to not having a two-way link).
Interestingly these links, when bidirectional, between UA and GCS are
generally encrypted - to protect against hijacking control of a UA.

On Thu, Mar 19, 2020 at 10:40 AM Daniel Migault <[email-masked]> wrote:

>>> Some comments or questions are clearly due to my lake of knowledge of
>>> the UAS ecosystem. I guess other people will find themselves in the same
>>> I am usually tempted to have an ID that is independent from the way it
>>> is received collected, thought the RID format needs to adapt the
>>> constraints associated to the transport used.
>>> </mglt>
>>>
>>
>> <atw>
>>> <mglt> This sounds like an operational requirement that the technology
>>> we design should be easily implemented on common devices. I keep this as a
>> I will repeat this here that we need to agree on the terms to use. Yes
>> the FAA and ASTM use different terms to mean the same thing, we need to
>> pick one of them and stick with it. I believe in our interim slides I
>> created a handy table doing just this.
>> </atw>
>>
>>
>> This is something Stu will need to answer, after re-reading this even I
>> am a bit mythed.
>> </atw>
>>
>>>

-- 
73's,
Adam T. Wiethuechter
AX Enterprize, LLC

---

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

Thank you Daniel for reviewing this draft.

As you suspected, I don't plan to continue work on this one (unless the
DRIP WG decides that is how we should proceed), as per guidance received
it was split into -reqs and -arch, but will reflect your comments in
revisions of one or the other of those child drafts.

My responses are interspersed.

On 3/18/2020 2:05 PM, Daniel Migault wrote:
> ...
> unclear to me if there will be an informational use case document. I do
> not believe that is necessary, so I do not necessarily expect the
> document being updated. As the text is the use case and requirements
> document might be common, I believe that comments provided should
> probably be addressed in the requirement document.

<swc> Agreed. </swc>

> situation and it would be good to describe the different
> elements that are expected to interact between each other in the scope
> of DRIP...

<swc> Shuai Zhao said essentially the same thing. While we probably
don't want to embed a UAS or UAS Traffic Management (UTM) tutorial into
a draft, we clearly need a bit more context for those coming from
outside the UAS community. I will endeavor to add it, primarily to -reqs
but in some cases (entities and relationships) to -arch. </swc>

> 1.  Introduction
> 
>    ...Network RID via the Internet; and
>    Aircraft (UA) to the observer's device....
> 
> <mglt>
> types of RIDs versus different ways the RID is received/collected. In
> the case of Network RID there do not seem to have radio constraints and
> so the these constraints only seem to apply to the broadcast scenario. 
> 

<swc> In the US, the FAA plans to require that the elements of
information (starting with the ID itself) are the same between Broadcast
RID and Network RID, merely transported differently. </swc>

> we design should be easily implemented on common devices. I keep this as
> a note for the requirement document. This also make me think that we
> might have to clarify how trusted these devices will be. I would be
> tempted to considered them as untrusted.
> </mglt>

<swc> Yes, supporting ubiquitous existing devices is a major
requirement, identified 3 years ago by the FAA Aviation Rulemaking
Committee, which drove the ASTM standard making. The devices themselves
probably should indeed be regarded as untrusted by anyone other than the
individual user/owner of a given device. This plays more heavily in
Bob's CS-RID than in basic DRIP, although the possibility of forging RID
messages or recording them in one location and asserting they were
received in another is a threat we could try to address with some kind
of "Fair Witness" TBD. </swc>

> bandwidth, I understand a limited size that fits Bluetooth or other
> radio protocol, and we expect the length to fit the radio frames. What
> is unclear to me is the necessity of having limited resources associated
> to the encryption or security processing. It would be fine to clarify
> which are the targeted resources.
> </mglt>

<swc> As I think Bob commented elsewhere, the UA themselves are often
tiny and inexpensive, so Cost, Size, Weight and Power ($SWaP) of any
added RID gear is a major issue. Even for larger UA, battery life is
short, and any additional power drain reduces flying time, altitude and
range. There is not a specific target $SWaP, as small UA range from
consumer hobby to defense and public safety applications, from under 250
grams to 25 kg, from under 50 USD on up, etc. There are also large UA,
for which UAS RID is not initially contemplated by regulators. </swc>

> ...
> if it means a specific byte format such as ascii/UTF-8 text or simply
> human readable ? If that is a requirement I expect to find it in the
> requirement draft.
> </mglt>

<swc> ASTM 3411 UAS ID Type 1 is an ANSI/CTA-2063-A serial number, the
encoding is specified in ASTM 3411 only as ASCII string.

ASTM 3411 UAS ID Type 3 is a UTM system assigned ID, which is specified
in separate UTM documents as a version 4 UUID, and specified in ASTM
3411 as 128 bits, binary encoded, Network Byte Order.

I will add these details to whichever draft the WG deems appropriate.
They are requirements only if we try to provide UAS ID Type 1 and/or 3;
we have been lobbying for an additional UAS ID Type (4?) to be assigned
by ASTM for DRIP. </swc>

> center for example via the GCS. </mglt>

<swc> Yes, that is the process, but the proximate source can be either
the drone itself, or another entity acting as its proxy, per the
following. </swc>

> not updated directly by the drone itself, but instead by a proxy. The
> drone is connected to that proxy. At first, at first if the proxy is
> simply relaying the information from the UA, the two scenario seems
> similar in some ways. I suppose the second scenario considers the proxy
> as originating the information about the UA. I do not necessarily
> understand the need of a proxy for updating information related to the
> UAS. However, I would consider it useful mostly for real-time responses
> when the UAS is not directly reachable. Am I correctly understanding the
> purpose of the proxy ?
> </mglt>

<swc> The most common case of a proxy is where the UA itself (the flying
drone) has no on-board RID support of any kind. The GCS is in this case
not only the proximate but also the ultimate source of RID information.
Indeeed, under US FAA NPRM proposed rules, for small UAS flying within
400 foot Visual Line Of Sight under Limited RID rules, the location
information sent is that of the GCS only, not that of the UA itself.
OTOH under Standard RID rules, Broadcast RID must be transmitted
directly by the UA itself, and provide the location of that UA; the same
information must be transmitted via Network RID (whether directly from
the UA, from the GCS or otherwise), but how the Broadcast and Network
transmissions are coordinated to agree is intentionally left unspecified
by the regulators. </swc>

> in the data base. I see this as the application used by a third party
> that request and present the necessary information related to an
> observed drone to let me decide if the drone is authorized or not.

<swc> Indeed, the architecture must show sources and sinks, but we
cannot specify the ultimate source of Network RID information: the
regulators and ASTM external standards developers have left that up to
operators, as should we; the UAS includes both the UA (the flying drone
itself) and its GCS, so we must support both options. The RID SP
function of an USS is indeed essentially a database that accepts reports
from its subscribers (UAS operators). The RID DP function (of the same
or another USS, or potentially a service not integrated with an USS) is
not expected to reside on the ultimate consumer's display device, but on
an intermediate server. </swc>

> manufacturer.... I have the impression that the origin of the
> information will play a major role in the trust associated to the
> information.  
> </mglt>

<swc> Agreed! The FAA NPRM demands authenticity and integrity/FEC; ASTM
3411 provides a framing structure for authentication data but
intentionally leaves unspecified the authentication algorithm etc. DRIP
can specify how to verify the binding of a RID message to its alleged
UAS proximate source, and of that UAS to a registry (wherein operator
data can be looked up), but the ultimate sources of both registry data
and UA position/velocity are outside our scope (although the latter may
be checked with CS-RID multilateration). </swc>

>    herein or in other initial tm-rid documents.

<swc> We are going to have to pay more attention to Network RID than
anticipated as it is the baseline in the recent FAA NPRM. </swc>

> split into multiple frames.

<swc> Yet such splitting is inevitable as 26 bytes cannot fit an ID, a
position and a velocity, much less a signature. We must fit regulator
required elements of information, in ASTM defined message structures,
into 17-23 byte chunks, and larger structures into sequences of no more
than 10 such chunks (to stay under 255 bytes total, for BT 5 and WiFi
framing, potentially w/FEC). </swc>

> authenticated information does not for example seems sufficient as the
> key will be needed to check the signature as well as information of the
> key owner. All these information is likely to require more than 26
> bytes. Am I correctly understanding the sentence above ?
> </mglt>

<swc> Perhaps we should say "precludes any challenge-response protocol."
A paged message of up to 17 + 23*9 = 224 bytes can indeed carry an 8 bit
Reed-Solomon FEC protected RID message, with a HHIT as an ID, with a
signature made using the private key corresponding to the public key
from which the HHIT was derived, using the "new crypto" proposed for HIP
by Bob. Another such message can be signed with the registry key,
proving that the HHIT is indeed in that registry, provided that
observers are equipped with _registry_ public keys (only) as "prior
knowledge". Specifics of how this can be achieved, of course, do not
belong in the -reqs draft, and probably not in -arch either, but rather
in Adam's authentication wrapper and Bob's registration docs. </swc>

> 3. seems to indicate the UAS RID is the RID SP. Is that correct ?

<swc> Sorry, I don't understand the question. (3) was meant to say that
any observer could use information received via RID to establish
communications with the UAS RID sender (the UA itself, or its GCS,
whichever was signing and sending the RID messages), with its registry,
etc. -- any node that can be looked up in DNS or in the registry,
starting from the UAS ID (HHIT) </swc>.

> be brought to avoid an RID broadcast to be replayed. It might be what 3.
> is trying to catch with "dynamic" connection, but this may be a little
> bit harder if authentication is provided by the UAS while connectivity
> is set with the RID SP.
> </mglt>

<swc> Agreed! Replay attacks, by another UAS or a device pretending to
be an UAS, must be defeated. This requires something dynamic in the
signed messages, which cannot be an observer provided challenge/nonce,
as Broadcast RID is a one-way transmission.  This is trivial with a
position/velocity Vector message, but not with a Basic ID message.
"Message Pack" structures that combine a Vector message (or any other
dynamic message) with a Basic ID (or any other static message) can use
the dynamic message variation to protect also the static message. </swc>

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

---

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Mon, 23 Mar 2020 03:12:57 +0000

Hi Stuart, let me know if there any section you would like me to contribute to.
For one, I can for sure compile  some sections about USS/UTM from various sources such as ASTM F38, FAA, NASA and etc.

Best,
Shuai

From: Tm-rid <[email-masked]> on behalf of "Stuart W. Card" <[email-masked]>
Date: Sunday, March 22, 2020 at 19:53
To: "[email-masked]" <[email-masked]>
Cc: Daniel Migault <[email-masked]>
Subject: Re: [Tm-rid] comments on draft-card-tmrid-uas(Internet mail)

<swc> Agreed. </swc>

1.  Introduction

[...]

  [...]

...

[...]
2.  Terms and Definitions
[...]
3.1.  Network RID

<mglt>

3.2.  Broadcast RID
  [...]

  [...]

<mglt>

- --

--
Tm-rid mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tm-rid

---

From: "Stuart W. Card" <[email-masked]>
Date: Mon, 23 Mar 2020 01:01:10 -0400

Thanks Adam for your reply, much more prompt than mine. I'll comment
further only where needed.

> This is something Stu will need to answer, after re-reading this even I

<swc> See my previous email in this thread. Basically, we should have
said "precludes any challenge-response security protocol, e.g. observers
providing nonces to UA to include in signed messages". </swc>

> confusion might be mitigated. We also need to elaborate more where
> Daniel has pointed out. Your feedback is extremely helpful as myself,
> Stu and Bob have had ours heads in this for a number of months and are
> used to the confusion. A new set (or sets) of eyes is extremely helpful
> to get our explinations clearer.

Amen!

- --

---

From: "Stuart W. Card" <[email-masked]>
Date: Mon, 23 Mar 2020 03:25:00 -0400

Shuai Zhao --

If you could draft a section providing background on USS/UTM, plus lists
of normative and informative references, including efforts by other
SDOs, that would address many of Daniel's points related to lack of
context. Thank you for whatever you can do in this area!

- -- Stu

On 3/22/2020 11:12 PM, shuaiizhao(Shuai Zhao) wrote:
> For one, I can for sure compile  some sections about USS/UTM from
> various sources such as ASTM F38, FAA, NASA and etc.
> 
>  
> 
> Best,
> 
> Shuai
> 
>  
> 
> *From: *Tm-rid <[email-masked]> on behalf of "Stuart W. Card"
> <[email-masked]>
> *Date: *Sunday, March 22, 2020 at 19:53
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *Daniel Migault <[email-masked]>
> *Subject: *Re: [Tm-rid] comments on draft-card-tmrid-uas(Internet mail)
> 
>  
> 
> Hash: SHA1
> 
>  
> 

- -- 

Tm-rid mailing list

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

- --

---

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Mon, 23 Mar 2020 07:52:15 +0000

Hi Stuart, consider it done. It might take me a week or so due to my current workload. Cheers. ☺

Best,
Shuai Zhao

From: "Stuart W. Card" <[email-masked]>
Date: Monday, March 23, 2020 at 00:25
To: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Daniel Migault <[email-masked]>
Subject: Re: [Tm-rid] comments on draft-card-tmrid-uas(Internet mail)

Shuai Zhao --

- -- Stu

On 3/22/2020 11:12 PM, shuaiizhao(Shuai Zhao) wrote:
Hi Stuart, let me know if there any section you would like me to
contribute to.
For one, I can for sure compile  some sections about USS/UTM from
various sources such as ASTM F38, FAA, NASA and etc.

Best,
Shuai

*From: *Tm-rid <[email-masked]<mailto:[email-masked]>> on behalf of "Stuart W. Card"
<[email-masked]<mailto:[email-masked]>>
*Date: *Sunday, March 22, 2020 at 19:53
*To: *"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
*Cc: *Daniel Migault <[email-masked]<mailto:[email-masked]>>
*Subject: *Re: [Tm-rid] comments on draft-card-tmrid-uas(Internet mail)

Hash: SHA1

<swc> Agreed. </swc>

     1.  Introduction

     [...]

       [...]
         Heavyweight security protocols are infeasible, yet
     trustworthiness of
         UAS RID information is essential.  Even the most basic datum,
     the UAS
         ID string (typically number) itself, under [WK65041], can be merely
         an unsubstantiated claim.

     ...

     [...]
     2.  Terms and Definitions
     [...]
     3.1.  Network RID
         Network RID has several variants.  The UA may have persistent
     onboard

         Internet connectivity of its own, but have instead some other
     form of
         the GCS, USS or other proxy may source it.  In the extreme case,
     this

         Internet directly by the UA or remote pilot, the first hop data
     links
         Provider (DP).  Each DP aggregates information from all SPs that
     have

     <mglt>

     3.2.  Broadcast RID
       [...]

       [...]
         any other information about the UA looked up from it.  Thus
     providing

     <mglt>

             but also Intenet direct contact information for services
     relating

- --

Tm-rid mailing list

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

- --