Subject: Re: [Tm-rid] Draft charter

From: Robert Moskowitz <[email-masked]>
Date: Thu, 3 Oct 2019 18:47:53 -0400

Updated charter:

Governmental agencies worldwide, including the United States Federal 
Aviation Administration (FAA), are embarking on rule making processes to 
define Remote Identification (RID) requirements for Unmanned Aircraft 
Systems (UAS). ASTM International (formerly the American Society for 
Testing and Materials) F38 Committee Work Item WK65041, “Standard 
Specification for UAS Remote ID and Tracking”, addresses such 
anticipated requirements. Broadcast RID defines a set of messages for 
UAS to send one-way over Bluetooth or IEEE 802.11. Network RID defines 
how the same information (and potentially more) can be made available 
via the Internet. The ASTM draft does not address how to ensure or at 
least assess trustworthiness of information communicated via RID.

The Host Identity Protocol (HIP) Host Identity Tag (HIT) is ideally 
suited to work within this RID effort. For each Unmanned Aircraft (UA), 
a HIT can consolidate the 4-tuple of (UA ID, UA physical location, UA 
onboard host ID, UA onboard host logical location [IP address list]) to 
a 3-tuple (HIT, UA physical location, UA onboard host logical location) 
and thereby provide significant benefits.

For HIP to be used effectively in this environment, it needs updates.

- Hierarchical HITs (HHIT) enabling scalable and trustable registration: 
HHIT was part of the original design of HIP, but was dropped for lack of 
a clear use case. RID messages containing HHITs will enable use of DNS 
to access information about the UAS.

- expanded HIP Registration for HHITs: This registration process will 
provide proof of authenticity and prevent duplicate HHITs from 
occurring. Further, these Registries will provide the UAS DNS 
information and other services (including support of RVS for Network RID 
and related applications).

- new cryptographic algorithms: Extremely compact keys and signatures 
(such as are enabled by EdDSA and Keccak functions) are needed to meet 
the severely constrained UAS environment.

Additionally, tm-rid will offer specifications for HIP-augmented ASTM 
RID messages. Initially this will consist of additional RID 
Authentication Messages that use the HI in public key signing 
operations: to prove UAS ownership of the HHIT; to authenticate other 
claims made via RID, such as position and velocity, as having been made 
by the owner of that HHIT; and to provide observers lacking current 
Internet connectivity with locally verifiable UAS proof-of-registration 
objects.

Further work will emerge as experience is gained in using HIP for UAS 
RID. For example, some UAS Traffic Management (UTM) systems envision 
using OAuth for Ground Control Systems (GCS) and authorized safety 
personnel. HIP as an OAuth method may help in merging HIP into these 
systems.

The goal is to complete these updates to HIP by the end of 2020.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 10 Oct 2019 08:21:01 +0000

Bob and others,

During the BoF approval call with IESG & IAB, the TM-RID BoF has been approved as a non-WG-forming BoF as the charter is not completely mature (see below).

It was also preferred to have TM-RID as a stand-alone WG: based on experience, a dedicated/focus group is lighter and more efficient. So, HIP is unchanged but all work done around HIP for TM-RID will end up (like now) into HIP WG.

The TM-RID charter will have to be discussed in the BoF meeting in Singapore and must include a privacy statement/work item. The IAB/IESG feedback was also that the current charter is too much on HIP and would like to explore whether other technologies (including layer-2 ones) could be applicable.

All the above does not prevent the current work on TM-RID related drafts of course.

So, let’s talk in Singapore at the BoF

-éric

From: Tm-rid <[email-masked]> on behalf of Robert Moskowitz <[email-masked]>
Date: Friday, 4 October 2019 at 00:48
To: "[email-masked]" <[email-masked]>
Subject: Re: [Tm-rid] Draft charter

Updated charter:

Governmental agencies worldwide, including the United States Federal Aviation Administration (FAA), are embarking on rule making processes to define Remote Identification (RID) requirements for Unmanned Aircraft Systems (UAS). ASTM International (formerly the American Society for Testing and Materials) F38 Committee Work Item WK65041, “Standard Specification for UAS Remote ID and Tracking”, addresses such anticipated requirements. Broadcast RID defines a set of messages for UAS to send one-way over Bluetooth or IEEE 802.11. Network RID defines how the same information (and potentially more) can be made available via the Internet. The ASTM draft does not address how to ensure or at least assess trustworthiness of information communicated via RID.

The Host Identity Protocol (HIP) Host Identity Tag (HIT) is ideally suited to work within this RID effort. For each Unmanned Aircraft (UA), a HIT can consolidate the 4-tuple of (UA ID, UA physical location, UA onboard host ID, UA onboard host logical location [IP address list]) to a 3-tuple (HIT, UA physical location, UA onboard host logical location) and thereby provide significant benefits.

- Hierarchical HITs (HHIT) enabling scalable and trustable registration: HHIT was part of the original design of HIP, but was dropped for lack of a clear use case. RID messages containing HHITs will enable use of DNS to access information about the UAS.

- expanded HIP Registration for HHITs: This registration process will provide proof of authenticity and prevent duplicate HHITs from occurring. Further, these Registries will provide the UAS DNS information and other services (including support of RVS for Network RID and related applications).

- new cryptographic algorithms: Extremely compact keys and signatures (such as are enabled by EdDSA and Keccak functions) are needed to meet the severely constrained UAS environment.

Additionally, tm-rid will offer specifications for HIP-augmented ASTM RID messages. Initially this will consist of additional RID Authentication Messages that use the HI in public key signing operations: to prove UAS ownership of the HHIT; to authenticate other claims made via RID, such as position and velocity, as having been made by the owner of that HHIT; and to provide observers lacking current Internet connectivity with locally verifiable UAS proof-of-registration objects.

Further work will emerge as experience is gained in using HIP for UAS RID. For example, some UAS Traffic Management (UTM) systems envision using OAuth for Ground Control Systems (GCS) and authorized safety personnel. HIP as an OAuth method may help in merging HIP into these systems.

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 10 Oct 2019 10:32:24 +0200

Congratulation TM-RID'lers,

this is great news!

Viele Grüße,

Henk

On 10.10.19 10:21, Eric Vyncke (evyncke) wrote:
> Bob and others,
> 
> During the BoF approval call with IESG & IAB, the TM-RID BoF has been 
> approved as a non-WG-forming BoF as the charter is not completely mature 
> (see below).
> 
> It was also preferred to have TM-RID as a stand-alone WG: based on 
> experience, a dedicated/focus group is lighter and more efficient. So, 
> HIP is unchanged but all work done around HIP for TM-RID will end up 
> (like now) into HIP WG.
> 
> The TM-RID charter will have to be discussed in the BoF meeting in 
> Singapore and must include a privacy statement/work item. The IAB/IESG 
> feedback was also that the current charter is too much on HIP and would 
> like to explore whether other technologies (including layer-2 ones) 
> could be applicable.
> 
> *From: *Tm-rid <[email-masked]> on behalf of Robert Moskowitz 
> <[email-masked]>
> *Date: *Friday, 4 October 2019 at 00:48
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [Tm-rid] Draft charter
> 
> 
> 
> 
> 
> Updated charter:
>

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 10 Oct 2019 08:00:58 -0400

Eric

Sigh,  this is why I posted a Charter here and hoped that there would be 
comments...

HIP first of all because this is "Trustworthy Remote ID": thus HITs and 
the rest flows from that.  ASTM has lots of IDs, none are self-provable, 
that is Trustworthy.

The only IETF ID similar to HITs are the hashed Public Keys in CORE.  I 
need to find the appropriate RFCs/IDs to review and compare.

Did you really mean "Layer-2" or Layer-3?  The only other layer-2 keying 
is IKE, which does not directly have a ID like HIP.  Both IKE and HIP 
use ESP.  Diet-ESP should be preferred when we get to NetworkID and C2 
(Command and Control).  Too many different C2 tech out there to 
recommend a Layer-3 or -4 approach.

But this is it in a quick response.

More later (particularly after breakfast!).

Bob

On 10/10/19 4:21 AM, Eric Vyncke (evyncke) wrote:
> approved as a non-WG-forming BoF as the charter is not completely 
> mature (see below).
>
> feedback was also that the current charter is too much on HIP and 
> would like to explore whether other technologies (including layer-2 
> ones) could be applicable.
>
> Aviation Administration (FAA), are embarking on rule making processes 
> to define Remote Identification (RID) requirements for Unmanned 
> Aircraft Systems (UAS). ASTM International (formerly the American 
> Society for Testing and Materials) F38 Committee Work Item WK65041, 
> “Standard Specification for UAS Remote ID and Tracking”, addresses 
> such anticipated requirements. Broadcast RID defines a set of messages 
> for UAS to send one-way over Bluetooth or IEEE 802.11. Network RID 
> defines how the same information (and potentially more) can be made 
> available via the Internet. The ASTM draft does not address how to 
> ensure or at least assess trustworthiness of information communicated 
> via RID.
>
> suited to work within this RID effort. For each Unmanned Aircraft 
> (UA), a HIT can consolidate the 4-tuple of (UA ID, UA physical 
> location, UA onboard host ID, UA onboard host logical location [IP 
> address list]) to a 3-tuple (HIT, UA physical location, UA onboard 
> host logical location) and thereby provide significant benefits.
>
> - Hierarchical HITs (HHIT) enabling scalable and trustable 
> registration: HHIT was part of the original design of HIP, but was 
> dropped for lack of a clear use case. RID messages containing HHITs 
> will enable use of DNS to access information about the UAS.
>
> information and other services (including support of RVS for Network 
> RID and related applications).
>
> claims made via RID, such as position and velocity, as having been 
> made by the owner of that HHIT; and to provide observers lacking 
> current Internet connectivity with locally verifiable UAS 
> proof-of-registration objects.
>

-- 
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: "Card, Stu" <[email-masked]>
Date: Thu, 10 Oct 2019 11:13:39 -0400

Thanks Eric!

Although HIP seems to me a strong candidate for this application, and we
are already prototyping & flight testing with it, there are countless other
protocols with which I am far less familiar (or completely unaware) that
may help.

Also privacy concerns are close to my heart and very important to some
major UAS operators.

I look forward to Singapore!

-- Stu

On Thu, Oct 10, 2019, 04:21 Eric Vyncke (evyncke) <[email-masked]> wrote:

> experience, a dedicated/focus group is lighter and more efficient. So, HIP
> is unchanged but all work done around HIP for TM-RID will end up (like now)
> into HIP WG.
>
>
>
> like to explore whether other technologies (including layer-2 ones) could
> be applicable.
>
>
>
> *From: *Tm-rid <[email-masked]> on behalf of Robert Moskowitz <
> [email-masked]>
> Specification for UAS Remote ID and Tracking”, addresses such anticipated
> requirements. Broadcast RID defines a set of messages for UAS to send
> one-way over Bluetooth or IEEE 802.11. Network RID defines how the same
> information (and potentially more) can be made available via the Internet.
> The ASTM draft does not address how to ensure or at least assess
> trustworthiness of information communicated via RID.
>
>
>
> The Host Identity Protocol (HIP) Host Identity Tag (HIT) is ideally suited
> to work within this RID effort. For each Unmanned Aircraft (UA), a HIT can
> consolidate the 4-tuple of (UA ID, UA physical location, UA onboard host
> ID, UA onboard host logical location [IP address list]) to a 3-tuple (HIT,
> UA physical location, UA onboard host logical location) and thereby provide
> significant benefits.
>
>
>
> HHIT was part of the original design of HIP, but was dropped for lack of a
> clear use case. RID messages containing HHITs will enable use of DNS to
> access information about the UAS.
>
>
>
> provide proof of authenticity and prevent duplicate HHITs from occurring.
> Further, these Registries will provide the UAS DNS information and other
> services (including support of RVS for Network RID and related
> applications).
>
>
>
> (such as are enabled by EdDSA and Keccak functions) are needed to meet the
> severely constrained UAS environment.
>
>
>
> Additionally, tm-rid will offer specifications for HIP-augmented ASTM RID
> messages. Initially this will consist of additional RID Authentication
> Messages that use the HI in public key signing operations: to prove UAS
> ownership of the HHIT; to authenticate other claims made via RID, such as
> position and velocity, as having been made by the owner of that HHIT; and
> to provide observers lacking current Internet connectivity with locally
> verifiable UAS proof-of-registration objects.
>
>
>
> Further work will emerge as experience is gained in using HIP for UAS RID.
> For example, some UAS Traffic Management (UTM) systems envision using OAuth
> for Ground Control Systems (GCS) and authorized safety personnel. HIP as an
> OAuth method may help in merging HIP into these systems.
>
>
>
> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 10 Oct 2019 12:01:17 -0400

Eric,

In the area of privacy, there are conflicting issues.

In the USofA, NO civil UAV can have privacy of its Identity.  The FAA 
'owns' all airspace at 1' above the ground, if I have that right (and 
Stu will correct me).  Thus according to law, a person does not have any 
claim to privacy flying a UAV over their own property.

Think about it.  Just because it is on their property does not mean it 
is not interacting with others.

So no privacy of ID or basic associated information.

And to proper authorities more information.

This is not to say that the ID is forever.  Some use cases can justify 
an ID per flight/mission.  The delivery services (read UPS, FedEX) have 
already identified and justified the need of ID per mission.  But again, 
for that delivery, the fact that the UAV belongs to delivery service Q 
will be available.

NetworkID takes this farther.  It is not just the UAV in your VLOS 
(Visual Line of Sight), but also those that were there in the last 60s 
or MAY be there in the next 60s.  It could also, for authorized 
personnel, extend out further.

Now when we get to C2 (Command and Control), there are some privacy 
aspects, but again the operator of a UAV (why it is called UAS for 
system) has limited privacy.  To authorized personnel the operators 
location MUST be known.  There is a Self-ID broadcast message part of 
the basic BT messages, but it is informational only (like a Realtor 
saying which property s/he is videoing for a posting).

Bob

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 10 Oct 2019 17:53:38 +0000

Bob,

I hope that your breakfast was a good one ;-)

More seriously, the privacy issue simply needs to be addressed by a document (or part of a document). If regulations say ‘no privacy’, then this is also a statement. But, I would believe that it is also privacy towards ‘normal citizens’ but again I can be wrong about the FAA rules. TM-RID needs a privacy consideration.

Per your previous email, yes: I meant that IESG wants to ensure that HIP is the right solution and no other layer-2 or layer-3 techniques fit the requirements. So, another document to be prepared for this specific TM-RID use case.

So, all “i” must be dotted and “t” crossed ;-)

Regards

-éric

From: Tm-rid <[email-masked]> on behalf of Robert Moskowitz <[email-masked]>
Date: Thursday, 10 October 2019 at 19:27
To: Eric Vyncke <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Tm-rid] Draft charter

Eric,

In the USofA, NO civil UAV can have privacy of its Identity.  The FAA 'owns' all airspace at 1' above the ground, if I have that right (and Stu will correct me).  Thus according to law, a person does not have any claim to privacy flying a UAV over their own property.

Think about it.  Just because it is on their property does not mean it is not interacting with others.

This is not to say that the ID is forever.  Some use cases can justify an ID per flight/mission.  The delivery services (read UPS, FedEX) have already identified and justified the need of ID per mission.  But again, for that delivery, the fact that the UAV belongs to delivery service Q will be available.

NetworkID takes this farther.  It is not just the UAV in your VLOS (Visual Line of Sight), but also those that were there in the last 60s or MAY be there in the next 60s.  It could also, for authorized personnel, extend out further.

Now when we get to C2 (Command and Control), there are some privacy aspects, but again the operator of a UAV (why it is called UAS for system) has limited privacy.  To authorized personnel the operators location MUST be known.  There is a Self-ID broadcast message part of the basic BT messages, but it is informational only (like a Realtor saying which property s/he is videoing for a posting).

Bob

-éric

From: Tm-rid <[email-masked]><mailto:[email-masked]> on behalf of Robert Moskowitz <[email-masked]><mailto:[email-masked]>
Date: Friday, 4 October 2019 at 00:48
To: "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: Re: [Tm-rid] Draft charter

Updated charter:

--
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: Robert Moskowitz <[email-masked]>
Date: Thu, 10 Oct 2019 16:24:41 -0400

Eric,

Typical breakfast.  Not too creative only what morning tea to have on a 
given day.

On 10/10/19 1:53 PM, Eric Vyncke (evyncke) wrote:
> Standard
> More seriously, the privacy issue simply needs to be addressed by a 
> document (or part of a document). If regulations say ‘no privacy’, 
> then this is also a statement. But, I would believe that it is also 
> privacy towards ‘normal citizens’ but again I can be wrong about the 
> FAA rules. TM-RID needs a privacy consideration.
>

Stu can speak better to this than me, but from what I heard, the FAA 
controls all the airspace in the US and if you have something there, you 
can be called on it.

In the past, most of this has been in the noise that has not gotten 
attention.  Other than when someone's RF plane flies over an airport 
because a gust of wind blew it past control of the operator.

Now with little UAV, again going out of RF range of the teen controlling 
them, flying in front of landing aircraft (it is so cool to fly your UAV 
in the neat field by the airport...).  Any exception would be the case 
that caused the accident.

Of course there will always be problems.  The UAV sold in a garage sale 
and the new owner NOT updating the registration information. But expect 
the FAA to act as it needs to.  Plus the penalties can be harsh.

Look at MacTaggart's comment about building inspections and a spec of 
paint on a sprinkler.

https://www.cnn.com/2019/10/10/tech/alastair-mactaggart/index.html

Regs get put in place because of lessons learned and everyone is 
learning lots of lessons with UAS and everyone is behind the curve. Of 
course the claim is that the biggest user of drone deliver are the drug 
dealers...

Now HOW the USS manages the data it has on the operators is out of scope 
of this work and gets into real policy legislation.

> Per your previous email, yes: I meant that IESG wants to ensure that 
> HIP is the right solution and no other layer-2 or layer-3 techniques 
> fit the requirements. So, another document to be prepared for this 
> specific TM-RID use case.
>

I am looking at 'invent HITs for IKE' argument.  Stu will have to 
provide the l2 vs l3 discussion as he has the knowledge about the 
systems in use today.

> So, all “i” must be dotted and “t” crossed ;-)

I have docs to write.  I know.  I did the easy ones first.

> *Date: *Thursday, 10 October 2019 at 19:27
> *To: *Eric Vyncke <[email-masked]>, "[email-masked]" <[email-masked]>
> Stu will correct me).  Thus according to law, a person does not have 
> any claim to privacy flying a UAV over their own property.
>
> an ID per flight/mission.  The delivery services (read UPS, FedEX) 
> have already identified and justified the need of ID per mission.  But 
> again, for that delivery, the fact that the UAV belongs to delivery 
> service Q will be available.
>
>     During the BoF approval call with IESG & IAB, the TM-RID BoF has
>     been approved as a non-WG-forming BoF as the charter is not
>     completely mature (see below).
>
>     experience, a dedicated/focus group is lighter and more efficient.
>     So, HIP is unchanged but all work done around HIP for TM-RID will
>     end up (like now) into HIP WG.
>
>     Singapore and must include a privacy statement/work item. The
>     IAB/IESG feedback was also that the current charter is too much on
>     HIP and would like to explore whether other technologies
>     (including layer-2 ones) could be applicable.
>
>     *From: *Tm-rid <[email-masked]>
>     <mailto:[email-masked]> on behalf of Robert Moskowitz
>     <[email-masked]> <mailto:[email-masked]>
>     *To: *"[email-masked]" <mailto:[email-masked]> <[email-masked]>
>     <mailto:[email-masked]>
>     Governmental agencies worldwide, including the United States
>     Federal Aviation Administration (FAA), are embarking on rule
>     making processes to define Remote Identification (RID)
>     requirements for Unmanned Aircraft Systems (UAS). ASTM
>     International (formerly the American Society for Testing and
>     Materials) F38 Committee Work Item WK65041, “Standard
>     anticipated requirements. Broadcast RID defines a set of messages
>     defines how the same information (and potentially more) can be
>     made available via the Internet. The ASTM draft does not address
>     how to ensure or at least assess trustworthiness of information
>     communicated via RID.
>
>     The Host Identity Protocol (HIP) Host Identity Tag (HIT) is
>     ideally suited to work within this RID effort. For each Unmanned
>     Aircraft (UA), a HIT can consolidate the 4-tuple of (UA ID, UA
>     physical location, UA onboard host ID, UA onboard host logical
>     location [IP address list]) to a 3-tuple (HIT, UA physical
>     location, UA onboard host logical location) and thereby provide
>     significant benefits.
>
>     dropped for lack of a clear use case. RID messages containing
>     HHITs will enable use of DNS to access information about the UAS.
>
>     - expanded HIP Registration for HHITs: This registration process
>     will provide proof of authenticity and prevent duplicate HHITs
>     from occurring. Further, these Registries will provide the UAS DNS
>     information and other services (including support of RVS for
>     Network RID and related applications).
>
>     - new cryptographic algorithms: Extremely compact keys and
>     signatures (such as are enabled by EdDSA and Keccak functions) are
>     needed to meet the severely constrained UAS environment.
>
>     Additionally, tm-rid will offer specifications for HIP-augmented
>     ASTM RID messages. Initially this will consist of additional RID
>     operations: to prove UAS ownership of the HHIT; to authenticate
>     other claims made via RID, such as position and velocity, as
>     having been made by the owner of that HHIT; and to provide
>     observers lacking current Internet connectivity with locally
>     Further work will emerge as experience is gained in using HIP for
>     UAS RID. For example, some UAS Traffic Management (UTM) systems
>     envision using OAuth for Ground Control Systems (GCS) and
>     authorized safety personnel. HIP as an OAuth method may help in
>     merging HIP into these systems.
>
> E: [email-masked] <mailto:[email-masked]>
>

---

From: "Card, Stu" <[email-masked]>
Date: Thu, 10 Oct 2019 17:32:19 -0400

The privacy issue is debated among FAA, pilots, et al. Clearly, duly
constituted authority needs to be able to look up the operator etc. from
info provided by RID. However, the guy who just doesn't like UAS should not
be facilitated in his harassment of their legitimate operators. So while
the ID that is transmitted by/for the UA will be in plaintext for all to
read, the lookup from that to the pilot's bag of meat ID may be restricted.
Even knowing what organization is the operator is too much info: Amazon
could use it to learn Walmart delivery patterns. These registry issues are
critical & so far have been punted by ASTM (in fairness they admit openly
to having punted so far).

On Thu, Oct 10, 2019, 16:10 Eric Vyncke (evyncke) <[email-masked]> wrote:

> document (or part of a document). If regulations say ‘no privacy’, then
> this is also a statement. But, I would believe that it is also privacy
> towards ‘normal citizens’ but again I can be wrong about the FAA rules.
> TM-RID needs a privacy consideration.
>
>
>
> Per your previous email, yes: I meant that IESG wants to ensure that HIP
> is the right solution and no other layer-2 or layer-3 techniques fit the
> requirements. So, another document to be prepared for this specific TM-RID
> use case.
>
>
>
> 'owns' all airspace at 1' above the ground, if I have that right (and Stu
> will correct me).  Thus according to law, a person does not have any claim
> to privacy flying a UAV over their own property.
>
> This is not to say that the ID is forever.  Some use cases can justify an
> ID per flight/mission.  The delivery services (read UPS, FedEX) have
> for that delivery, the fact that the UAV belongs to delivery service Q will
> be available.
>
> NetworkID takes this farther.  It is not just the UAV in your VLOS (Visual
> Line of Sight), but also those that were there in the last 60s or MAY be
> there in the next 60s.  It could also, for authorized personnel, extend out
> further.
>
> aspects, but again the operator of a UAV (why it is called UAS for system)
> has limited privacy.  To authorized personnel the operators location MUST
> be known.  There is a Self-ID broadcast message part of the basic BT
> messages, but it is informational only (like a Realtor saying which
> property s/he is videoing for a posting).
>
> Bob
>
> *From: *Tm-rid <[email-masked]> <[email-masked]> on
> behalf of Robert Moskowitz <[email-masked]>
> *To: *"[email-masked]" <[email-masked]> <[email-masked]>
> <[email-masked]>
> E:      [email-masked]
>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 11 Oct 2019 16:21:01 +0000

Actually, we do not need a _solution_ for privacy _now_ but rather a consideration section in one document and esp on the BoF agenda (which is accepted as you may have seen in a different email)

-éric

From: "Card, Stu" <[email-masked]>
Date: Thursday, 10 October 2019 at 23:32
To: Eric Vyncke <[email-masked]>
Cc: Robert Moskowitz <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Tm-rid] Draft charter

The privacy issue is debated among FAA, pilots, et al. Clearly, duly constituted authority needs to be able to look up the operator etc. from info provided by RID. However, the guy who just doesn't like UAS should not be facilitated in his harassment of their legitimate operators. So while the ID that is transmitted by/for the UA will be in plaintext for all to read, the lookup from that to the pilot's bag of meat ID may be restricted. Even knowing what organization is the operator is too much info: Amazon could use it to learn Walmart delivery patterns. These registry issues are critical & so far have been punted by ASTM (in fairness they admit openly to having punted so far).

On Thu, Oct 10, 2019, 16:10 Eric Vyncke (evyncke) <[email-masked]<mailto:[email-masked]>> wrote:
Bob,

Regards

-éric

From: Tm-rid <[email-masked]<mailto:[email-masked]>> on behalf of Robert Moskowitz <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 10 October 2019 at 19:27
To: Eric Vyncke <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Tm-rid] Draft charter

Eric,

Bob

-éric

Updated charter:

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--
Tm-rid mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tm-rid