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.