weblink of the minutes:
Drone Remote ID Protocol (drip)
Virtual Interim Meeting Agenda
Wed 2020-04-22 15:00 to 16:00 UTC
Co-Chairs: Daniel Migault & Mohamed Boucadair
*** Logistics **********************************
**** Agenda ************************************
1. Note well, logistics and introduction [Chairs] 5 min
please sign bluesheet here, slides online, jabber?
active drafts, focus will be -reqs and -arch for common understanding and
solutions Today will be -reqs then -arch Please do not hesitate to ask
questions over the course of presentations Hand over to Stu
2. Requirements Discussion 30 min
- draft-card-drip-reqs [Stuart] 30 min
- Discussion [ALL] 30 min
Big picture we need to fit into
Lots of interface and standardization is ongoing
Lots of USS and most will support many
Key standard is ASTM, standardized Broadcast and Network
Broadcast over data LINK, Network over networks
Only specified the framing, no security
Broadcast Use case
Network use case
USS A is both Service and Display
Matix of rules for FAA and EASA
Gap analysis comparing rules to standard
Highlights will get RID and do a query into a registry to get data about
uas and operator
Top level reqs and approach
Operators can lie or misinform, so confirmation of reports would be good
Stick man called "Pilot/Operator" lots of entities could be co-located
Same with Registry
Real subject for day!
If claim ID must prove ownership of ID
How do we bind message to ID?
Proving that ID is in a given registry?
GEN-1 need to be clear UA, not the UAS. Device ID not the Operator ID!
ID is mapped one to one to aircraft! Documents are a bit misleading with the
Minimal levels of safey, authentication not being compliant (avoid
replay/spoof), what is probabily?
No external -reqs from SDOs but we can guess it
We had down to 0 in the important structures, everything (including
registeries) tied together. We believe 100% reliability.
All here relate
GEN-5 we believe not just access control!
GEN-6 for enabling actions to trigger off RID data
GEN-7 all this needs to be put somewhere (variously levels of dyanamic and
static info) Questions? Shuai:
Readability, only ID or information inside the ID?
Would say some but not all fields. ID and anything beyond ID
Is that data within scope of the group?
Yes, goes beyond what ASTM defines.
Two ways to get info; 1. using other broadcast messages, 2. looking things
up via unique key (which is UAS ID)
Getting side requirements
Lots needs to be protected by AAA and governed by policy and layer all them
"Finger" is temp. name; establishing connection
QoS requirements, mostly from regulators
UA move! GCS can move!
Consider delivery trucks that slowly move through neighborhood with UA
taking off and landing to deliver package to door UA need to do frequent RF
link switches Multicast to support pub/sub use cases
If recievers can stamp recieved broadtcast rid messages then cool stuff can
Length <= 20 bytes
Needs to point to registry
ID2 + ID3 must adhere to GEN4
Batches of messages?
Unnumbered reqs for IDs
Do not want to correlate ID to patterns of use (Walmart vs Amazon)
Next 2 might be redundant
Who will generate ID?
Regulators are very loosely saying UTM system will assign UTM ID....what
does that mean?
GCS location broadcast in clear, fear mob with baseball bats going after
operator (located at GCS) PRIV-3 is little beyond our world but might be
useful Satisfying PRIV reqs could require Internet to exchange keys with
USS to perform decryption, if lost UA would need to fallback to plaintext
Questions? Sean Turner:
Not sure how to write to get things here to there.
That one out of our purview
Security consideration pointing to it
IDs exist as keys in registries, permanant record of IDs seen. If you have
temproal uniqueness then can it be correlated
Intersection of ID and PRIV reqs
This would be correct, but only registry would have access to such, genie
could get out of bottle (fear), adversary should not be able to rebuild without
a lot of coverage.
We are driving from fluid work via regulators and SDOs
Some might not apply to certain contexts
We were formally "TMRID" but not DRIP and mailing lsit still TMRID
How do we handle this fluid motion of other organizations?
GO with first part, forward with doc, go with security and priv review
and that will be valuable work even if we want to wait for other
stakeholders, if want to go to RFC then go so that we can point to
others. Won't get response to drafts
Agree w/Michael. What is source? Just FAA, others? Mark requirements
Yes agree to all. Can mark up, familair with FAA.
Find someone with knowledge of EASA requirements.
Many manned groups don't want to see UA stuff on there stuff, only
Reacrhed out to Brussel for U-Space reqs, no out but in comment period.
So might be hard
EU945, 947 is all we have to go on.
Any other -reqs? Modify what exists?
Call or adoption that closes in May
Jabber: Shuai: Not sure if the KPIs specified in the F3411 needs to be
mentioned in the requirement Stu: probably
3. Architecture Discussion 15 min
- draft-card-drip-arch [Stuart] 5 min
- Discusion [ALL] 10 min
Fit the functionality in the tight constraints
Predefined entities already exist
Private info is very similar to what is needed for domain name (from Internet
domain name). Leverage stuff to use it! Have UAS look like a domain Public
information is pushed out via Broadcast and displayed ia internet CSRID.
optional functionality but might be super useful!
Registry to CAA -- FAA will not pull off what they are thinking (run THE
registry). Looks like Internet domain arch. Operation transactions Most here
are standard RID stuff Last 3 are above and beyond we hope to add
Focus on what will fit in BT4 constrain from ASTM
ID that seems to fit is HIT from HIP
We have asked ASTM to define new ID type for HHIT
We can do tricks to fit it into other ID types from ASTM
Two tweaks have been proposed to ASTM, they say would be easy lift but up to
Propose stuff for the DNS stuff
Implemented ~baseline python ASTM standard
Arch draft needs work
Questions (prompt by Daniel)
Liason statement from ASTM?
Will ask Gabriel Cox to see what he says
Another org is ICAO that has informally asked for participation for Aviation
Trust Framework UTM is future of ATM
Size important, but you want to use domain name IDs?
Yes, if unconstrained fqdn. HHIt is 16 byets and create an ugly FQDN
Trust framework sec. they have lots of participation from others (FAA, and
manufacturers) internation regs
Just pointing out current prototype implementation of FQDN lookup stuff
Continue to work on docs, but need feedback on mailing list!
How do we proceed approval from SDOs?
Two things 1. documents should be adopted by WG, 2. getting liasons both ways
to validate reqs in drafts. This means that we can ask the SDOs to comment
during the ellaboration of the documents and provide them the resulting
document for a kind of validation of the requirements.
US only next comment. ANSI serves as coordinator between groups. Intends to
comment on document. Get IETF as an active SDO in area under ANSI document.
Will ask above and continue to work on it.
4. Open Mic 5 min
5. Closing [Chairs] 5 min
Already put call for -reqs and show support on mailing list. Issue call for
adoption for -arch as we need comments. More feedback now is better More
coordinations with other organizations! Thank you all talk next time!
*** Participants **********************************
webex: 21 people
jabber: 5 people
Stuart W. Card AX Enterprize, LLC
Andrei Gurtov LiU&LFV
Mohamed Boucadair Orange
Adam Wiethuechter AX Enterprize, LLC
Daniel Migault Ericsson
Sean Turner, sn3rd
Susan Hares Hickory Hill
tim costello, BT
Eric Vyncke, Cisco
Shuai Zhao, Tencent
Michael Richardson, Sandelman Software Works
Iain Sharp, ATIS
David Chen Federal Aviation Administration
Robert Moskowitz, HTT Consulting
Murray Kucherawy, Facebook
Pardeep Kumar, Swansea Uni
Kiran Makhijani, Futurewei
Amelia Andersdotter, CENTR