Re: [Drip] New Version Notification for draft-ietf-drip-arch-21.txt

[Robert Moskowitz <[e-mail]>]

Tomorrow...

On 3/10/22 15:08, shuai zhao wrote:
> Dear DRIP,
> Thanks AD’s detailed review to help us produce a solid draft.
> Arch-21 addresses more than 30+ comments. Many thanks to co-author’s 
> dedication.  Also, great appreciation for Laura’s help for text 
> improvement.
> See inline confirmations (SZ/)  regarding which comments have been 
> addressed in 21.
> There are only two items left which need a bit more explanations. 
> @[e-mail] <mailto:[e-mail]>
> 1.Sec 7 " it adds two more entity types." Which ones ?
> SZ/ @[e-mail] <mailto:[e-mail]>Please 
> specify.
> 2.Sec 10 is very light and mainly focus on the private keys except for 
> the false flag issue (which deserves its own paragraph). Nothing is 
> said about privacy
> SZ/ Does it mean we should remove this section? 
> @[e-mail] <mailto:[e-mail]> anything 
> new you can add?
> Best,
> Shuai
> -----Original Message-----
> From: "Eric Vyncke (evyncke)" <[e-mail]> 
> <mailto:&lt;[e-mail]&gt;>
> Date: Wednesday, February 2, 2022 at 02:42
> To: "Stuart W. Card" <[e-mail]> 
> <mailto:&lt;[e-mail]&gt;>om>, "[e-mail]" 
> <mailto:&quot;[e-mail]&quot;> <[e-mail]> 
> <mailto:&lt;[e-mail]&gt;>
> Cc: "[e-mail]" 
> <mailto:&quot;[e-mail]&quot;> 
> <[e-mail]> 
> <mailto:&lt;[e-mail]&gt;>om>, 
> "[e-mail]" 
> <mailto:&quot;[e-mail]&quot;> 
> <[e-mail]> 
> <mailto:&lt;[e-mail]&gt;>om>, "shuaiizhao(Shuai Zhao)" 
> <[e-mail]> <mailto:&lt;[e-mail]&gt;>om>, 
> "[e-mail]" <mailto:&quot;[e-mail]&quot;> <[e-mail]> 
> <mailto:&lt;[e-mail]&gt;>
> Subject: [Internet]Re: [Drip] AD review for draft-ietf-drip-arch-20
>     Hello Stu, and thanks for your quick reply.
>     Elided the text where we agree, and comments added with EV>
>     Regards
>     -éric
>     On 02/02/2022, 04:37, "Stuart W. Card" <[e-mail]> 
> <mailto:&lt;[e-mail]&gt;> wrote:
>         Thanks Eric!
>         I agree with 90% of what you have written, and thanks for 
> catching not
>         only several nits but also several areas where we were unclear.
>         It won't surprise you that I'll offer friendly rebuttal on a 
> few points
>         as well as answers to a few questions.
>     EV> it was expected and happy to read them
>        Abstract: try to add RFC 9153 after the "requirements document" 
> else put I-D.ietf-drip-reqs
> SZ/ Added RFC9153 as a normative reference.  Or is it okay to change 
> all reference from "I-D.ietf-drip-reqs" to "RFC 9153" since RFC9153 is 
> published? @Eric Vyncke (evyncke)
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>         On 2/1/2022 11:29 AM, Eric Vyncke (evyncke) wrote:
>         > ...
>         > Sec 1: s/Unmanned Aircraft System Remote Identification and 
> tracking
>         > (UAS RID)/ Unmanned Aircraft System (UAS) Remote 
> Identification (RID)/
>         > to be consistent with the title of section 1.1
>         The acronym UAS RID really does expand with "and tracking" in 
> most of
>         the key documents, including the original Aviation Rulemaking 
> Committee
>         final report (on which almost everyone based their subsequent 
> efforts)
>         and ASTM F3411.
>     EV> feel free to keep "and tracking"; my point was rather to 
> introduce UAS and RID acronyms just after their expansion, not globally
> SZ/ agreed with @Eric Vyncke (evyncke), added as recommended.
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>        Sec 1.1: prefix "FAA" with "USA-based" ?
> SZ/ I Don’t think that is necessary. Not like EASA that Europe comes 
> with its acronym. FAA should be well-known to person who is in 
> aerospace domain. Let me know what others option and we can definitely 
> emphasis on that.
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>        Sec 1.1: the use of "commercial" is usually understand as for 
> consumer (i.e., recreative use) while I afraid that here it is more 
> for commercial aviation activities as opposed to recreative ones. 
> Worth clarifying or using a different word than commercial
> SZ/ I understood the question. However here we pretty much copy/paste 
> from FAA final rule. In FAA document, the definition of commercial, 
> non-commercial, amateur-build UAS and recreational are not well 
> defined. I would suggest we keep the FAA languages.
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>         > ...
>         > Sec 1.2.1 is it "received UAS ID" or "received UAS RID" ? If 
> "ID", is it
>         > worth explaining why "ID" is used here?
>         RID is the _process_, not the identity, not the identifier. In 
> F3411,
>         the identifier is the "UAS ID".
>     EV> fair point, the difference is clear in the -reqs document. 
> Now, I wonder whether the reader would benefit from a repetition of 
> the definitions of ID vs. RID in this document. Perhaps in § 3.3 ?
> SZ/ I suggest adding the following clarification in 1.1. Since that is 
> where arch- starts to introduce some more details about RID, not the 
> ID itself.
> *SZ/ -21 has addressed this issue. Consider this is closed. *
> Currently
> "
> 1.1.  Overview of Unmanned Aircraft System (UAS) Remote ID (RID) and
>       Standardization
>    UAS Remote Identification (RID) is an application enabler for a UAS
>    to be identified by Unmanned Aircraft Systems Traffic Management
>    (UTM) and UAS Service Supplier (USS) (Appendix A) or third parties
>    entities such as law enforcement.  Many considerations (e.g., safety)
>    dictate that UAS be remotely identifiable.
> "
> Suggested changes
> "
> 1.1.  Overview of Unmanned Aircraft System (UAS) Remote ID (RID) and
>       Standardization
>    UAS Remote Identification (RID) is an application enabler which 
> consists of UAS ID verification process for a UAS
>    to be identified by Unmanned Aircraft Systems Traffic Management
>    (UTM) and UAS Service Supplier (USS) (Appendix A) or third parties
>    entities such as law enforcement.  Many considerations (e.g., safety)
>    dictate that UAS be remotely identifiable.
> "
>         Sec 1.2.1 please expand LOS at first use in " RF LOS" (perhaps 
> also expand "RF") at the expanse of readability
> SZ/ updated in -21.
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>         Sec 1.2.1 " link based ID" same question about "ID" vs. "RID" 
> (there should also be a '-' as in "link-based")
> SZ/ updated to "link-based".  Later comments regarding not using 
> RID/ID alone should clarify
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>         Sec 1.2.2 " GNSS" expand at first use
> SZ/ updated to "e.g. their respective Global Navigation Satellite 
> System (GNSS) derived locations."
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>         Sec 1.2.2 add a note somewhere about the "4-D airspace" as not 
> everyone is aware of the change of rules based on time of the day
> SZ/ @Card, Stu, I am looking for input from you about this comment.  
> "4-D" was defined in RFC9153, should we repeat the definition here? So 
> maybe I did not understand Eric's concern.
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>         Sec 1.2.2 increment the year in " currently (in the year of 2021)"
> SZ/ Make sense to me.  Updated to 2022
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>         > ...
>         > Section 1.2: this section appears as FAA-only. While this is 
> not too
>         > good for the IETF, this could be OK but the document must be 
> clear that
>         > section 1.2 is the US FAA position, not a global one.
>         It was based on F3411 and intended to be generic. Indeed, FAA 
> does not
>         yet permit Network RID as a means of compliance with its RID 
> rule. Is
>         there something specific here that conflicts with a European 
> or other
>         non-US concept?
>     EV> my concern is about the applicability of an IETF document, 
> which needs to be defined. May I suggest to add some pre-amble in sec 
> 1.2 stating that the following sub-sections are applicable / related 
> to F3411 ? The title of section 1.2 could also include F3411 to be 
> clear about its applicability.
> SZ/ How about changing the title of section 1.2, from "Overview of 
> Types of UAS Remote ID" to "Overview of Types of UAS Remote ID from FAA"
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>          Sec 3: I would move this section as a sub-section of 1.2.2
> SZ/ I assume Eric meant section 1.3 here, not Section 3.  So, if it is 
> Section 1.3, I have no issues of moving it under section 1.2, since 
> the assumption of Section 1.3 is under the network RID.
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>          Sec 1.4 is " general UAS RID usage scenario" really general ? 
> I.e., is it applicable outside of US FAA/CA CAA ?
> SZ/ I believe that’s what we think DRIP architecture should look like. 
> Should be change the sentence from " general UAS RID usage scenario "  
> to " DRIP UAS RID usage scenario"? @Card, Stu?
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>          Sec 1.4: please expand V2I, V2V, and DAA
> SZ/ updated the following definitions for Figure 4 and removed "(for 
> brevity in this figure)".
> "
> DAA:  Detect And Avoid
> GPOD: General Public Observer Device
> PSOD: Public Safety Observer Device
> V2I:  Vehicle-to-Infrastructure
> V2V:  Vehicle-to-Vehicle
> "
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>         > ...
>         > Sec 3.1: why only crypto abbreviations ? There are so many 
> aeronautical
>         > acronyms that they should be there as well and this § 3.1 
> should be
>         > moved ahead just after §1 (assuming that §1.1 and others become
>         > top-level sections)
>         We weren't focusing specifically on crypto, but listed only those
>         acronyms that weren't defined in -reqs, which is the DRIP 
> terminology
>         reference.
>     EV> text of sec 3.3 should then be included in this section for 
> consistency
> SZ/ I think its fine to move current section 3 "Terms and Definitions" 
> up to section 2, which is what I have done in -21. Please let me know 
> if that is going to be an issue for you all. I have also added " This 
> document uses terms defined in [I-D.ietf-drip-reqs]." At the beginning 
> of abbreviation to address Eric's comment.
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>         Sec 3.2 add reference to HIP
> SZ/ I am not sure section 3.2 is the right place to add HIP reference 
> since HIP was not even mentioned.  The place where we should is in 
> section 4.
> " It justifies and explains the use of Hierarchical Host Identity 
> Tags  (HHITs) [RFC7401] as self-asserting IPv6 addresses suitable as a 
> UAS ID type  and more generally as trustworthy multipurpose remote 
> identifiers."
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>          Sec 4: please specify that this section is only applicable to 
> US FAA (if so)
> SZ/ I don’t have a clear answer for that. I am assuming the design of 
> DRIP RID is for "general" purpose, which is not only for FAA-based 
> RID. @Card, Stu?
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>          Sec 4 at multiple places, the text is rather dense and dry, 
> could there be some figures to help understanding ?
> SZ/ rewriting each of the sentence in this section might be tough. It 
> might be better to point out which part needs some tuning/figures.
>         Sec 4.1: the last paragraph is a single sentence of 7 
> lines...Please consider rewriting in an easier to read paragraph.
> SZ/ updated as following:
> " Likewise, the maximum ASTM RID {{F3411}} Authentication Message 
> payload is 201 bytes for most authentication types. A type 5 is also 
> added in this revision for IETF and other SDOs to develop Specific 
> Authentication Methods as extensions to ASTM RID. One byte out of 201 
> bytes is consumed to index the sub-type which leaves only 200 for DRIP 
> authentication payloads, including one or more DRIP entity identifiers 
> and associated authentication data."
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>         > ...
>         > Sec 4.2: what is the difference between "RID" "Remote ID" 
> and "ID" ?
>         > please try to use a consistent vocabulary. Same later for 
> "cryptographic ID"
>         I'm not sure we were consistent. What we should be doing:
>           "RID" never used alone
>           "UAS RID" ::= "Unmanned Aircraft System[s] Remote 
> Identification and
>         tracking"
>           "ID" never used alone
>           "UAS ID" ::= "Unmanned Aircraft System Identifier"
>     EV> happy if the document is reviewed to ensure that "ID" and 
> "RID" are never used alone.
> SZ/ based current comments, I think we agree to replace all "RID" with 
> "UAS RID", "ID" with "UAS ID", right?  There are some places such as 
> Net-RID, I don’t think we need to replace those right?
> Currently in -21, I have done all the replacement, but I need second 
> eyes to make sure all replacements are done correctly.
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>         Sec 4.2: unsure whether "HI" was defined before
> SZ/  It was expanded in its first usage for sure. Bu in -21, I also 
> add "HI" in "abbreviations" section for completeness.
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>        Sec 4.2: I cannot parse " This is in contrast to general IDs 
> (...) as the subject in an X.509 certificate."
> SZ/ @Robert Moskowitz@Robert Moskowitz I will need Bob's help here.
>       Sec 4.2: " by avoiding an explicit encoding technology like 
> ASN.1 or CBOR", so what encoding should be used ?
> SZ/ @Robert Moskowitz@Robert Moskowitz Needs Bob's input.
>         > ...
>         > Sec 4.4: what is the meaning of "extant" ?
>         "still in existence" which is probably not what we want here. Bob?
>     EV> learned a new word, suggest using simple wording ;-)
> SZ/ updated to "existing", let me know everyone knows a better word 
> for replacement.  Or "obvious" or.......
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>         > ...
>         > Sec 5: what are "public and private UAS information" ? The 
> different
>         > types of info were not defined earlier in the document or 
> provide a
>         > forward reference to sec 5.1 & 5.2
>         We should cite the definition in -reqs PRIV-1 "private 
> information
>         (i.e., any and all information designated by neither cognizant 
> authority
>         nor the information owner as public, e.g., personal data)."
>     EV> indeed, easier for the reader
> SZ/ Updated as " DRIP registries hold both public and private UAS 
> information (See PRIV-1 in {{I-D.ietf-drip-reqs}}) resulting from the 
> DRIP identifier registration process."
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>        Sec 5.1.1 s/ public registry/ public information registry/
> SZ/ Updated.
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>         > ...
>         > Sec 5.1.1 should "opaque" be used rather than "silent" in 
> "they may be
>         > silent to the Observer" ?
>         What was meant was that an Observer might actually _see_ (with 
> eyes) an
>         aircraft, and if it was participating in RID, but Network RID 
> only, not
>         Broadcast, the Observer would not _receive_ any RID messages, 
> instead
>         would have to query a Net-RID DP for any aircraft in the vicinity.
>     EV> then indeed 'opaque' is the wrong word but I am not sure that 
> 'silent' is better. No proposal of mine though :(
> SZ/ @Card, Stu, what is your final word choice? __
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>       Sec 5.1.2 after reading this §, it is still unclear to me what 
> are the private information...
> SZ/ Do you mean section 5.2?  If it is 5.2, I updated the first 
> paragraph of section 5 as Stu suggest above: " DRIP registries hold 
> both public and private UAS information (See PRIV-1 in 
> {{I-D.ietf-drip-reqs}}) resulting from the DRIP identifier 
> registration process.". Does it solve the confusion?
>         > ...
>         > Sec 6: I was unable to find a definition of 
> "trustworthiness" in
>         > [I-D.ietf-drip-reqs]
>         You got me. :-) We use the word in -reqs section 12 on page 
> 10, we imply
>         generally what we want but we never define it. I use the word 
> frequently
>         (not just in the context of UAS RID and DRIP), and I identify 
> several
>         dimensions of it (reliability, scalability, security, etc.), 
> but I have
>         never actually attempted to define it rigorously. I am afraid 
> to try.
>         Perhaps we should reword this so it doesn't imply that we have 
> a formal
>         definition?
>     EV> good idea, simply enumerate (reliability, scalability, ...) 
> rather than using "as specified in " ;-)
> SZ/ @Card, Stu it seems to me you may have a solution for this comment?
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>         Sec 6: " DET (DRIP Entity Tag which is an HHIT-based UA ID)" 
> should be at least written as "DRIP Entity Tag (DET), which is an 
> HHIT-based UAS RID." And it probably deserves a definition / 
> introduction on its own (perhaps in § 3.1)
> SZ/  I agree. Updated as suggested.
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>         Sec 7 " One obvious opportunity is to enhance the architecture 
> with gateways from Broadcast RID to Network RID.", while I do not 
> disagree, this section is not the right place to open the discussion. 
> This should be in the § 1 (with perhaps a forward reference to § 7)
> SZ/ @Robert Moskowitz @Robert Moskowitzneed input from Bob.
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>        Sec 7 " crowd-sourced" indeed many ADS-B receivers are run by 
> amateurs (like my own) for flightradar24, flightaware, ... perhaps add 
> a reference ?
> SZ/ @Eric, do you have a specific reference to add? Not sure I 
> understood your comment correctly.
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>        Sec 7 " it adds two more entity types." Which ones ?
> SZ/ @Robert Moskowitz @Robert Moskowitz Please specify.
> > ...
>         > Sec 7.1 this should really be part of the overall 
> architecture of section 1
>         The "CS-RID Finder" defined in 7.1 and the "CS-RID SDSP" 
> defined in 7.2
>         are _additions_: they are not part of UAS RID as contemplated 
> by anyone
>         other than the DRIP WG; they are not even part of basic DRIP, 
> but an
>         extension.
>         > ...
>         > Sec 8 "DRIP contact" is nice indeed but same comment as for 
> the CS-RID:
>         > this should really be part of the global architecture 
> description and
>         > not pushed at the end
>         This is another extension relative to UAS RID but I think 
> fundamental to
>         our DRIP approach, so yes we should briefly introduce it 
> earlier, before
>         elaborating upon it here.
> EV> yes, please introduce those parts (CS-RID & contact) earlier in 
> the document.
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>     EV> As F3411 is the basis this I-D, should those extensions be 
> clearly identified as not included in F3411 ?
> SZ/ @Card, Stu, I feel like more discussion is needed regarding how to 
> address this section. Please let me know what is your thinking.
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>         Sec 7.2 " multilateration" should briefly be described, 
> perhaps in the terminology section
> SZ/ @Card, Stu "multilateration" was not described in req. Should we 
> do it here?
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>         >
>         > Sec 8: should be less descriptive and perhaps not even 
> mention HIP & BEET
>         This really goes back to what has been a fundamental recurring 
> debate
>         since we started DRIP: is it based on HHITs and thus related 
> closely to
>         (although not entirely dependent upon) HIP; or is it generic? 
> So far, no
>         one has come to the DRIP WG and proposed anything other than 
> the HHIT
>         based approach. We are far along with that approach. Given the 
> use of
>         that approach, the contact requirement is trivially satisfied 
> by using a
>         HIP initiated BEET; there is no need to reinvent any wheels.
>     EV> I also like the HHIT approach and the extension of DRIP 
> contact. But I believe that mentioning HIP & BEET is venturing too 
> much in a detailed solution especially since there is not even a draft 
> about it. HIP may be mentioned as a potential solution but no more as 
> its mention puts constraints on the work of the DRIP WG. I strongly 
> suggest to remove " An Observer equipped with HIP can... V2X 
> communications (e.g., [MAVLink]), etc" and possibly also the last 
> sentence.
>         Thanks again. I will wait for responses from my co-authors and 
> our
>         editor before proposing any more replacement language to 
> clarify these
>         points where our meaning did not come through.
> SZ/ @Card, Stu should we trim down the details regarding HIP/BEET?
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>     EV> that is the goal of review by a pair of fresh eyes. As soon as 
> a revised I-D is uploaded, then I will initiate the IETF Last Call. We 
> can still hope to get this I-D approved by the IESG before IETF-113 
> (end of March 2022)
>         Sec 10 is very light and mainly focus on the private keys 
> except for the false flag issue (which deserves its own paragraph). 
> Nothing is said about privacy
> SZ/ Does it mean we should remove this section? @Robert 
> Moskowitz@Robert Moskowitz anything new you can add?
>