Drip Status PagesDrone Remote ID Protocol (Active WG)
Int Area: Éric Vyncke, Erik Kline | 2020-Feb-21 —Chairs:
IETF-110 drip minutes
Session 2021-03-09 1700-1900: Room 3 - drip chatroom
DRIP IETF 110 [meetecho](https://meetings.conf.meetecho.com/ietf110/?group=drip&short=&item=1) [codim](https://codimd.ietf.org/notes-ietf-110-drip) [material](https://datatracker.ietf.org/meeting/110/session/drip) # Agenda * Agenda bashing 5min * Note well, logistics, and introduction * DRIP Architecture: WGLC Summary & Next Steps (Shuai) 30 min * Solutions & Implementations * DRIP Implementation Update (Andrei) 30 min * UAS Remote ID (draft-ietf-drip-rid) (Bob) 15 min * DRIP Authentication Formats (draft-ietf-drip-auth) (Adam) 15 min * DRIP Registries (draft-wiethuechter-drip-registries) (Adam) 15 min * Open Mic 5 min * Closing 5 min # Working Group status * WGLC draft-ietf-drip-arch-11 draft-ietf-drip-reqs-09 * WG documents draft-ietf-drip-auth-00 draft-ietf-drip-rid-07 * WGLC received multiple comments * How do we want to use Git Hub ? * we need to be able to: * track every issue raised * to have people participating in the review * interim meetings ? * XMLv3 submission # Note on XMLv3 submission ## kdrfc If you say kdrfc -3chi draft-x.md You get: — draft-x.txt - draft-x.html - draft-x.v2v3.xml …and an idnits report. Submit the draft-x.v2v3.xml at https://datatracker.ietf.org/submit/ (Do NOT submit the .txt at the same time — that will be regenerated.) ## online tools To convert a markdown file (specifically kramdown) to v3 XML, you can use the converter available here: https://xml2rfc.tools.ietf.org/experimental.html Please select Input type: kramdown Other: convert v2 to v3 XML v3 FAQ: https://xml2rfc.tools.ietf.org/xml2rfc-doc.html (Details on what to do after converting to v3: https://www.rfc-editor.org/materials/FAQ-xml2rfcv3.html#name-after-converting-an-xml-fil) xml2rfc mailing list: https://www.ietf.org/mailman/listinfo/xml2rfc # minutes commenced at 16:02 UTC # chairs introduction Daniel M. proposed putting reviewer comments into GitHub and discussing them on the mailing list; there were no objections but Shuai Zhao suggested making them pull requests or open issues rather than just text in the docs Daniel also recommended use of xml2rfc v3; Bob M. pointed out that our current drafts are already there # Shuai Z. presented Architecture draft progress Shuai Z. raised the questions: - which sections 4-6 belong there? - should we use normative language there? As -arch is in WGLC, need WG consensus on how to proceed. Bob M. highlighted the value of -arch _as is_ in exposing IETF DRIP work to other SDOs and stakeholders. Stu C. pointed out that CS-RID Finders and SDSPs are the only additional entities we are introducing into the DRIP arch. vs the pre-defined UAS RID arch. Éric V. clarified that his main concerns were use of normative language in an informational document and the need to maintain consistency between -arch and solution space detail docs. BCP14 template will be removed and all normative language is already replaced. Daniel M. suggested a middle ground, where -arch introduces our solution approach and its basic entities, but relegates details to other documents; Eric V. concurred. Adan W. expressed mixed feelings about including CS-RID section 6 as it is UAS RID specific. Bob M. suggested softening the language re: solution approach to present it as _an_ approach vs _the_ approach. Daniel M. gave a specific example of how to do that: make Section 4 not HHIT as DRIP ID but rather DRIP ID with HHIT as an illustration and our initial choice. Shuai Z. wrapped up, getting us back on schedule. # Andrei G. presented implementation progress Andrei G. explained that HIPv2 imposes new requirements on HIP implementations (including specifically OpenHIP), and DRIP imposes new requirements not only on implementatons but also on ORCHID creation and interpretation specifications. New ORCHID method has shorter hash -> greater probability of collision -> hopefully detected in registration of _Hierarchical_ HIT. Andrei G's students have made great progress implementing DRIP on UA-mountable Raspberry Pi transmitters and Observer Android receivers. Andrei G. warned that vendors' implementations of Bluetooth 5 do not all make the features needed available to us and of WiFi do not all make broadcast reception available to us. Andrei G's students also prototyped a DRIP registry. Stu C. proposed a test of the interoperability of the implementations developed independently by Andrei G's students and at the New York Unmanned Aircraft Systems Test Site: Daniel M. inquired of our AD how helpful that might be; Eric V. responded that is always helpful to have 2+ interoperating implementations documented somewhere (wiki, ...); Bob M. reminded us of the short broadcast range vs tele-hackathons; Shuai Z. said we need an open platform for widespread experimentation. # Bob M. presented DRIP UAS RID draft progress Bob M. updated everyone on regulatory and external SDO changes. Bob M. introduced, from the FAA "final" rule, the concept of "broadcast module", its requirement to us ANSI/CTA-2063-A serial numbers (rather than Session IDs), motivating encoding HHITs (as our first DRIP Entity Identifiers) as such. Daniel M. inquired why FAA had dropped all requirements for cybersecurity; Bob M. & Stu C. gave short answers. Bob M. requested review: of Appendices E and F as he merges them to address replays; and of DNS examples, to catch typos, and to accomodate non-AERO domains for other applications. Bob M. requested WGLC after those items are resolved. # Adam W. & Michael P. presented Authentication & Registry progress Adam W. reported a pause in some DRIP work while ASTM F38.02 updates F3411 to ensure compliance with the FAA rule. Adam W. and Michael P. are identifying the necessary Repository Object Identifiers (ROIDs) and data elements. Michael P. is standing up a prototype DRIP registry using the .cz open source FRED code. Michael P. proposed a hybrid DNS heirarchy for DRIP, involving both a common TLD and country code ccTLDs. Daniel M. inquired regarding overlap of information among multiple registries; Michael P. answered at high level. Michael P. illustrated concepts using automotive parallels. Adam W. introduced the 5 (so far known) unique ID keys involved in cross-registry lookups. Daniel M. inquired about the role of DNS: Adam W. deferred specific use-case dependent answers; Stu C. gave our main DNS use case of finding the specific registries in which other information resides. Shuai Z. inquired about the ability to look up dynamic data, such as flight plans ("operational intents"): Stu C. gave a "textbook" answer based on the current FAA rule; Bob M. indicated that there is discussion among regulators and SDOs but not yet any consensus in this area. Michael P. alerted us to EU regulatory activity relevant to cybersecurity of aviation related data and domain registries, including supply chain issues. Daniel M. inquired about other EU regulations, esp. pertaining to data privacy; Michael P. answered that they are all interconnected and require attention. # chairs concluded session Daniel M. solicited input on interims etc. Adam W. said monthly interims could improve and accelerate at least the registries draft. Med B. reminded all of open WGLC on -arch. Meeting adjourned at 17:56 UTC. These notes taken mostly by Stu C., who solicits corrections.