Minutes interim-2020-drip-01: Wed 11:00

Meeting Minutes Drone Remote ID Protocol (drip) WG Snapshot
Title Minutes interim-2020-drip-01: Wed 11:00
State Active
Other versions plain text
Last updated 2020-04-22

Meeting Minutes

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 **********************************

- Webex:
https://ietf.webex.com/ietf/j.php?MTID=m55592b255b3106bfd11854d9be550754 -
Slides: https://datatracker.ietf.org/meeting/interim-2020-drip-01/session/drip

**** Agenda ************************************

1. Note well, logistics and introduction  [Chairs]       5 min
Slides (1-7): 

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


Slide 2:
    Big picture we need to fit into
    Lots of interface and standardization is ongoing
    Lots of USS and most will support many
Slide 3:
    Key standard is ASTM, standardized Broadcast and Network
    Broadcast over data LINK, Network over networks
    Only specified the framing, no security
Slide 4:
Broadcast Use case
Slide 5:
    Network use case
    USS A is both Service and Display
Slide 6:
    Matix of rules for FAA and EASA
    Gap analysis comparing rules to standard
Slide 7:
    Highlights will get RID and do a query into a registry to get data about
    uas and operator
Slide 8:
    Top level reqs and approach
    Operators can lie or misinform, so confirmation of reports would be good
Slide 9:
    Stick man called "Pilot/Operator" lots of entities could be co-located
    Same with Registry
Slide 10:
    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?

Note well!
Bob M:
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.
Slide 11:
    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)
Slide 12:
    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
Slide 13:
    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
Slide 14:
    Unumbers requirement
    If recievers can stamp recieved broadtcast rid messages then cool stuff can
Slide 15:
    ID requirements
    Length <= 20 bytes
    Needs to point to registry
    ID2 + ID3 must adhere to GEN4
    Batches of messages?
Slide 16:
    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?
Slide 17:
    Privacy reqs!
    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
    Allisa Cooper:
    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.
Slide 18:
    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?
    Michael Richardson:
        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
    Eric Vyncke:
        Agree w/Michael. What is source? Just FAA, others? Mark requirements
        with sources.
    Yes agree to all. Can mark up, familair with FAA.
    Eric Vyncke:
        Find someone with knowledge of EASA requirements.
        Many manned groups don't want to see UA stuff on there stuff, only
        minimal information
        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.
Slide 19:
    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

Slides (1-19):

3. Architecture Discussion                              15 min
     - draft-card-drip-arch          [Stuart]  5 min
     - Discusion                     [ALL]     10 min

Slide 21
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!

Slide 22
Registration transactions
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

Slide 23
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

Slide 24
Two tweaks have been proposed to ASTM, they say would be easy lift but up to

Slide 25
Propose stuff for the DNS stuff
Implemented ~baseline python ASTM standard

Slide 26
Arch draft needs work
Next steps
Harmonization issues?

Questions (prompt by Daniel)
Eric V
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

Iain Sharp
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.

Slides (20-26):

4. Open Mic                                              5 min

5. Closing                               [Chairs]        5 min
Slides (9): 

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

Name                                  Affiliation
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