DRIP UAS RID (Robert Moskowitz) =============================== draft-ietf-drip-rid-08 Bob presents: audience for this draft is mainly for ppl who is outside of IETF. Why should they take IETF approach (both manufacturers and civilian aviation authorities)? update since 07: - most appendices move to core draft - X.509 related text was improved. Appendices to core Doc: - consoidated HHITs into CTA2063-A sections - improving naming, possibly from Adam please review IANA considerations. EdDSA: - still a draft - EdDSA is not yet a NIST standard Expand X.509 comparison: - text was improved. - there is a connection to explain between HHIT and X.509, work is TBD ToDO: - check out DNS example? is this a reasonable way to do that? - Adam has a python script to add HHIT as CTA 2063-A numbers - ASTM now in ballot of v1.1 of F3411 (should be F3411-21) - where to python code (hhit-gen.py)? how do we handle code in our draft? in github with reference? - Secdir review. - 09 revision will address the current comments in few weeks. Eric: (lost audio....) Bob: will take it to the list Daniel: right way to do, possibly put a link in RFC. Bob: Adam did million HHIT generations with no collisions. RID Arch (Shuai Zhao) =============================== Currenly -15, addressed a lot of comments Stu concerns - Bob and Shuai attempted to address Saw Stu response but has yet to read Compiled issues from ML and github Looking for comments and feedback for next revision Big issue to discuss and get a solid result: slide 3 Bob has said do not like primacy Bob: audiance is uas regulatory committee we need to speak out as a voice to do this in a trustworthy manner. Qualcomm is pushing 1609.2 as their way --> 3GPP. This is how we see it work with our tech 2 years, no other things put forward here Dan: because its arch, generic by potentional other solutions. you look now, not so sure. if another solution comes it would have major impact on document. personal feeling is to not try and say - not expecting multiple solutions to be standardized (??) - document to integrate/replace would be needed. should not open door to something to be open Bob: MLS arch! it is for the one Stu: started coming from avaition community and going to bob, and found the hit as a good identifier - agree with bob to not weaken our position Eric: we should respect the charter! its a document for wg and then ietf community Dan: do not see this going against charter Stu: charter is silent on singular/plural Dan: is there anyone agaisnt removing the word Primary? Shuai what was the reason for keeping Primary? Shuai: it was there when he had draft, why was it there to begin with? Dan: version -15 next week? Shuai: Stu gave some comments recently, looks mostly editorial, something about section 5 Dan: Req related issues (Stu) =============================== Stu: the relationship among drafts in DRIP, before we can proccedd for arch-revision DRIP is a enhancment of ASTM F3411 and successfully interoprated with a baseline ASTM F3411 We ask F3411 UAS ID type 4, subtype 1 = IETF DRIP, and could be other subtype2 FAA need help for session IDs, hopefully DRIP ID can be accepted by FAA as a way of managing Session IDs. Roman Danilyw's comments: concern is there places having caveats to strenght the req-. The best efforts requiremetn is not consistent with RFCxxxx, either MUST or a SHOULD. Daniel: agree, we can not have MUST with exceptions. having a SHOULD is going to be EOW? Stu: need to work on using the appropriate language. Bob: Will help Stu with language. Stu: is it WG concensus to change the wording after WGLC. Eric: it is a editorial thing. we address Roman's comments in next week. Stu: - put "more complete scenairo figure" to arch- - ASTM and CAA drive the req-, once arch is defined, the we can refine other solutions. - fundamental drip: - USA only or cyber-physical entities? - section 5, have to talk a little about authentication...