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

From: shuai zhao <[email-masked]>
Date: Thu, 10 Mar 2022 20:08:04 +0000

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. @[email-masked]<mailto:[email-masked]>

1.       Sec 7 " it adds two more entity types." Which ones ?

SZ/ @[email-masked]<mailto:[email-masked]> 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? @[email-masked]<mailto:[email-masked]> anything new you can add?

Best,

Shuai

-----Original Message-----

From: "Eric Vyncke (evyncke)" <[email-masked]><mailto:&lt;[email-masked]&gt;>

Date: Wednesday, February 2, 2022 at 02:42

To: "Stuart W. Card" <[email-masked]><mailto:&lt;[email-masked]&gt;>om>, "[email-masked]"<mailto:&quot;[email-masked]&quot;> <[email-masked]><mailto:&lt;[email-masked]&gt;>

Cc: "[email-masked]"<mailto:&quot;[email-masked]&quot;> <[email-masked]><mailto:&lt;[email-masked]&gt;>om>, "[email-masked]"<mailto:&quot;[email-masked]&quot;> <[email-masked]><mailto:&lt;[email-masked]&gt;>om>, "shuaiizhao(Shuai Zhao)" <[email-masked]><mailto:&lt;[email-masked]&gt;>om>, "[email-masked]"<mailto:&quot;[email-masked]&quot;> <[email-masked]><mailto:&lt;[email-masked]&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" <[email-masked]><mailto:&lt;[email-masked]&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?

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 10 Mar 2022 15:54:19 -0500

Tomorrow...

On 3/10/22 15:08, shuai zhao wrote:
> Arch-21 addresses more than 30+ comments. Many thanks to co-author’s 
> dedication.  Also, great appreciation for Laura’s help for text 
> improvement.
> There are only two items left which need a bit more explanations. 
> @[email-masked] <mailto:[email-masked]>
> 1.Sec 7 " it adds two more entity types." Which ones ?
> SZ/ @[email-masked] <mailto:[email-masked]>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? 
> @[email-masked] <mailto:[email-masked]> anything 
> new you can add?
> Best,
> Shuai
> To: "Stuart W. Card" <[email-masked]> 
> <mailto:&lt;[email-masked]&gt;>om>, "[email-masked]" 
> <mailto:&quot;[email-masked]&quot;> <[email-masked]> 
> <mailto:&lt;[email-masked]&gt;>
> Cc: "[email-masked]" 
> <mailto:&quot;[email-masked]&quot;> 
> <[email-masked]> 
> <mailto:&lt;[email-masked]&gt;>om>, 
> "[email-masked]" 
> <mailto:&quot;[email-masked]&quot;> 
> <[email-masked]> 
> <mailto:&lt;[email-masked]&gt;>om>, "shuaiizhao(Shuai Zhao)" 
> <[email-masked]> <mailto:&lt;[email-masked]&gt;>om>, 
> "[email-masked]" <mailto:&quot;[email-masked]&quot;> <[email-masked]> 
> <mailto:&lt;[email-masked]&gt;>
>     On 02/02/2022, 04:37, "Stuart W. Card" <[email-masked]> 
> <mailto:&lt;[email-masked]&gt;> wrote:
>         Thanks Eric!
> 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. *
>         > ...
>         > 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
>     EV> feel free to keep "and tracking"; my point was rather to 
> introduce UAS and RID acronyms just after their expansion, not globally
> *SZ/ -21 has addressed this issue. Consider this is closed. *
> 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?
>     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
> "
>    UAS Remote Identification (RID) is an application enabler which 
> consists of UAS ID verification process for a UAS
>         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/ -21 has addressed this issue. Consider this is closed. *
> *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. *
> *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.
>     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. *
> 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. *
> *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)
> 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. *
> 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. *
> 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.
> " 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"
> 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. *
> 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."
>       Sec 4.2: " by avoiding an explicit encoding technology like 
> ASN.1 or CBOR", so what encoding should be used ?
>         > ...
>         > Sec 4.4: what is the meaning of "extant" ?
> *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
> 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. *
> *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" ?
>     EV> then indeed 'opaque' is the wrong word but I am not sure that 
> 'silent' is better. No proposal of mine though :(
> *SZ/ -21 has addressed this issue. Consider this is closed. *
> 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]
> *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/ -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/ -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/ -21 has addressed this issue. Consider this is closed. *
>         > Sec 7.1 this should really be part of the overall 
> architecture of section 1
>         > ...
>         > 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
> *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. *
> *SZ/ -21 has addressed this issue. Consider this is closed. *
>         >
>         > Sec 8: should be less descriptive and perhaps not even 
> mention HIP & BEET
>     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.
> *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?
>

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 11 Mar 2022 13:15:29 -0500

> SZ/ @[email-masked] <mailto:[email-masked]>Please 

I don't think these are the exact words I used on whatever comment, but 
that is probably not important.

Actually 3 entity types:

Entity 1:

Finders

Entity 2:

Although 9153 does define SDSP, it is not in the DRIP architecture. 
CS-RID specifically defines a SDSP that correlates the harvested 
information, performs multilateration when possible and feeds the 
information into the UTM.

Entity 3:

The second is non-broadcasting UA discovered by 'visual' harvesting (via 
camera, LIDAR, etc.).

So the added entity types are:  SPDP and non-RID UA.

So how to say that here.

... it adds the following entity types:

*   Remote ID Finders
*   A Supplemental Data Service Provider (SDSP) to correlate UA 
observations and forward to UTM.
*   non-RID UA or "hidden" UA.

> @[email-masked] <mailto:[email-masked]> anything 

I missed this.  I could have added more, basically lifting text from 
drip-rid.  Let's see what I might do here and not open a whole can of 
worms for review and comments.

================

The security provided by asymmetric cryptographic techniques depends
upon protection of the private keys.  It may be necessary for the GCS
to have the key pair to register the HHIT to the USS.  Thus it may be 
the GCS
that generates the key pair and delivers it to the UA, making the GCS a 
part of
the key security boundary.  Leakage of the private key either from the 
UA or GCS
to the component manufacturer is a valid concern and steps need to be in
place to ensure safe keeping of the private key.

The size of the public key hash in the HHIT is also of concern.  It is 
well within
current server array technology to compute another key pair that hashes 
to the
same HHIT.  Thus an adversary could impersonate a validly registered UA.
This attack would only be exposed when the HI in DRIP authentication message
is checked back to the USS and found not to match.

Finally, the RID sender of a small harmless UA (or the entire UA) could 
be carried
by a larger dangerous UA as a "false flag."  Compromise of a registry 
private key
could do widespread harm.  Key revocation procedures are as yet to be
determined.  These risks are in addition to those involving Operator
key management practices.

============================

There is probably more I can extract from drip-rid security 
considerations, but this may be enough for the highlights here.

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit

---

From: "Card, Stu" <[email-masked]>
Date: Fri, 11 Mar 2022 14:01:10 -1000

I was referring to 7.1 Finders & 7.2 CS-RID SDSP.

SDSP (generically) is a term listed in the RFC 9153 glossary but CS-RID
SDSP is introduced in -arch.

Non-participating UA are indeed entities but they have no _protocol_
interactions in DRIP.

On Fri, Mar 11, 2022, 08:16 Robert Moskowitz <[email-masked]>
wrote:

> There are only two items left which need a bit more explanations. @[email-masked] <[email-masked]>
>
>
>
> SZ/ @[email-masked] <[email-masked]> Please specify.
>
>
> SZ/ Does it mean we should remove this section? @[email-masked] <[email-masked]> anything new you can add?
>
>
> drip-rid.  Let's see what I might do here and not open a whole can of worms
> for review and comments.
>
> ================
>
> to have the key pair to register the HHIT to the USS.  Thus it may be the
> GCS
> the key security boundary.  Leakage of the private key either from the UA
> or GCS
> current server array technology to compute another key pair that hashes to
> the
> Finally, the RID sender of a small harmless UA (or the entire UA) could be
> carried
> From: "Eric Vyncke (evyncke)" <[email-masked]> <&lt;[email-masked]&gt;>
>
> To: "Stuart W. Card" <[email-masked]> <&lt;[email-masked]&gt;>om>, "[email-masked]" <&quot;[email-masked]&quot;> <[email-masked]> <&lt;[email-masked]&gt;>
>
> Cc: "[email-masked]" <&quot;[email-masked]&quot;> <[email-masked]> <&lt;[email-masked]&gt;>om>, "[email-masked]" <&quot;[email-masked]&quot;> <[email-masked]> <&lt;[email-masked]&gt;>om>, "shuaiizhao(Shuai Zhao)" <[email-masked]> <&lt;[email-masked]&gt;>om>, "[email-masked]" <&quot;[email-masked]&quot;> <[email-masked]> <&lt;[email-masked]&gt;>
>
>     On 02/02/2022, 04:37, "Stuart W. Card" <[email-masked]> <&lt;[email-masked]&gt;> wrote:
>
>
>
>         Thanks Eric!
>
>
>
> Robert Moskowitz
> C:      248-219-2059
> F:      248-968-2824
> E:      [email-masked]
>
> There's no limit to what can be accomplished if it doesn't matter who gets
> the credit
> --
> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>

---

From: Robert Moskowitz <[email-masked]>
Date: Sat, 12 Mar 2022 20:42:58 -0500

> I was referring to 7.1 Finders & 7.2 CS-RID SDSP.

I did not think I caught that....

>
> SDSP (generically) is a term listed in the RFC 9153 glossary but 
> CS-RID SDSP is introduced in -arch.

So a "see below" would be sufficient.

> Non-participating UA are indeed entities but they have no _protocol_ 

Good point so they do not, as such, belong in arch.

>
>
> On Fri, Mar 11, 2022, 08:16 Robert Moskowitz 
> <[email-masked]> wrote:
>
>
>
>>     Arch-21 addresses more than 30+ comments. Many thanks to
>>     co-author’s dedication.  Also, great appreciation for Laura’s
>>     help for text improvement.
>>     SZ/ @[email-masked]
>>     <mailto:[email-masked]>Please specify.
>
>     I don't think these are the exact words I used on whatever
>     comment, but that is probably not important.
>
>     Actually 3 entity types:
>
>     Entity 1:
>
>     Finders
>
>     Entity 2:
>
>     Although 9153 does define SDSP, it is not in the DRIP
>     architecture.  CS-RID specifically defines a SDSP that correlates
>     the harvested information, performs multilateration when possible
>     and feeds the information into the UTM.
>
>     Entity 3:
>
>     The second is non-broadcasting UA discovered by 'visual'
>     harvesting (via camera, LIDAR, etc.).
>
>
>>     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
>>     anything new you can add?
>
>     I missed this.  I could have added more, basically lifting text
>     from drip-rid.  Let's see what I might do here and not open a
>     whole can of worms for review and comments.
>
>     ================
>
>     to have the key pair to register the HHIT to the USS.  Thus it may
>     be the GCS
>     that generates the key pair and delivers it to the UA, making the
>     GCS a part of
>     the key security boundary.  Leakage of the private key either from
>     the UA or GCS
>     The size of the public key hash in the HHIT is also of concern. 
>     It is well within
>     current server array technology to compute another key pair that
>     hashes to the
>     Finally, the RID sender of a small harmless UA (or the entire UA)
>     could be carried
>     by a larger dangerous UA as a "false flag."  Compromise of a
>     registry private key
>>     <mailto:&lt;[email-masked]&gt;>om>, "shuaiizhao(Shuai
>>     Zhao)" <[email-masked]>
>>     <mailto:&lt;[email-masked]&gt;>om>, "[email-masked]"
>>     <mailto:&quot;[email-masked]&quot;> <[email-masked]>
>>     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)
>>             > Sec 1: s/Unmanned Aircraft System Remote Identification
>>     and tracking
>>     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.
>>            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.
>>             > Sec 1.2.1 is it "received UAS ID" or "received UAS RID"
>>     ? If "ID", is it
>>         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.
>>        UAS Remote Identification (RID) is an application enabler
>>     which consists of UAS ID verification process for a UAS
>>             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.
>>             Sec 1.2.1 " link based ID" same question about "ID" vs.
>>     "RID" (there should also be a '-' as in "link-based")
>>             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.
>>             > 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
>>         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/ 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.
>>              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?
>>             > 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
>>     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/ 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.
>>     Tags  (HHITs) [RFC7401] as self-asserting IPv6 addresses suitable
>>     as a UAS ID type  and more generally as trustworthy multipurpose
>>     remote identifiers."
>>     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?
>>              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.
>>     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."
>>             > 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"
>>     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/  It was expanded in its first usage for sure. Bu in -21, I
>>     also add "HI" in "abbreviations" section for completeness.
>>            Sec 4.2: I cannot parse " This is in contrast to general
>>     IDs (...) as the subject in an X.509 certificate."
>>     SZ/ updated to "existing", let me know everyone knows a better
>>     word for replacement.  Or "obvious" or.......
>>             > Sec 5: what are "public and private UAS information" ?
>>     The different
>>             > types of info were not defined earlier in the document
>>     or provide a
>>     information (See PRIV-1 in {{I-D.ietf-drip-reqs}}) resulting from
>>     the DRIP identifier registration process."
>>             > Sec 5.1.1 should "opaque" be used rather than "silent"
>>     in "they may be
>>         EV> then indeed 'opaque' is the wrong word but I am not sure
>>     that 'silent' is better. No proposal of mine though :(
>>     paragraph of section 5 as Stu suggest above: " DRIP registries
>>     hold both public and private UAS information (See PRIV-1 in
>>         EV> good idea, simply enumerate (reliability, scalability,
>>     ...) rather than using "as specified in " ;-)
>>             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)
>>             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)
>>            Sec 7 " crowd-sourced" indeed many ADS-B receivers are run
>>     by amateurs (like my own) for flightradar24, flightaware, ...
>>     perhaps add a reference ?
>>             > Sec 8 "DRIP contact" is nice indeed but same comment as
>>     for the CS-RID:
>>         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.
>>     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.
>>         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)
>>     except for the false flag issue (which deserves its own
>>     paragraph). Nothing is said about privacy
>     There's no limit to what can be accomplished if it doesn't matter
>     who gets the credit
>     -- 
>     Tm-rid mailing list
>     [email-masked]

---

From: <[email-masked]>
Date: Mon, 14 Mar 2022 07:01:39 +0000

Hi Bob, Shuai, all,

What about proceeding with this change:

OLD:
   Further, gateways with additional sensors (e.g., smartphones with
   cameras) can provide independent information on the UA type and size,
   confirming or refuting those claims made in the UAS RID messages.
   This Crowd Sourced Remote ID (CS-RID) would be a significant
   enhancement, beyond baseline DRIP functionality; if implemented, it
   adds two more entity types.

NEW:
   Further, gateways with additional sensors (e.g., smartphones with
   cameras) can provide independent information on the UA type and size,
   confirming or refuting those claims made in the UAS RID messages.

   Sections 6.1 and 6.2 define two additional entities that are required
   to provide this Crowd Sourced Remote ID (CS-RID).

I suggest to also make the following changes:

* s/One obvious opportunity/One opportunity

* s/a TBD interface to a CS-RID SDSP/a new interface to a CS-RID SDSP

Thank you.

Cheers,
Med

De : Robert Moskowitz <[email-masked]>
Envoyé : dimanche 13 mars 2022 02:43
À : Card, Stu <[email-masked]>
Cc : shuai zhao <shuai.zhao=[email-masked]>; [email-masked]; Robert Moskowitz <[email-masked]>; Adam Wiethuechter <[email-masked]>; Laura Welch <[email-masked]>; Andrei Gurtov <[email-masked]>; Eric Vyncke (evyncke) <[email-masked]>; BOUCADAIR Mohamed INNOV/NET <[email-masked]>; Daniel Migault <[email-masked]>
Objet : Re: [Drip] New Version Notification for draft-ietf-drip-arch-21.txt

SDSP (generically) is a term listed in the RFC 9153 glossary but CS-RID SDSP is introduced in -arch.

Non-participating UA are indeed entities but they have no _protocol_ interactions in DRIP.

On Fri, Mar 11, 2022, 08:16 Robert Moskowitz <[email-masked]<mailto:[email-masked]>> wrote:

Dear DRIP,

I don't think these are the exact words I used on whatever comment, but that is probably not important.

Actually 3 entity types:

Entity 1:

Finders

Entity 2:

Although 9153 does define SDSP, it is not in the DRIP architecture.  CS-RID specifically defines a SDSP that correlates the harvested information, performs multilateration when possible and feeds the information into the UTM.

Entity 3:

The second is non-broadcasting UA discovered by 'visual' harvesting (via camera, LIDAR, etc.).

So how to say that here.

*   Remote ID Finders
*   A Supplemental Data Service Provider (SDSP) to correlate UA observations and forward to UTM.
*   non-RID UA or "hidden" UA.

I missed this.  I could have added more, basically lifting text from drip-rid.  Let's see what I might do here and not open a whole can of worms for review and comments.

================

The security provided by asymmetric cryptographic techniques depends
upon protection of the private keys.  It may be necessary for the GCS
to have the key pair to register the HHIT to the USS.  Thus it may be the GCS
that generates the key pair and delivers it to the UA, making the GCS a part of
the key security boundary.  Leakage of the private key either from the UA or GCS
to the component manufacturer is a valid concern and steps need to be in
place to ensure safe keeping of the private key.

The size of the public key hash in the HHIT is also of concern.  It is well within
current server array technology to compute another key pair that hashes to the
same HHIT.  Thus an adversary could impersonate a validly registered UA.
This attack would only be exposed when the HI in DRIP authentication message
is checked back to the USS and found not to match.

Finally, the RID sender of a small harmless UA (or the entire UA) could be carried
by a larger dangerous UA as a "false flag."  Compromise of a registry private key
could do widespread harm.  Key revocation procedures are as yet to be
determined.  These risks are in addition to those involving Operator
key management practices.

There is probably more I can extract from drip-rid security considerations, but this may be enough for the highlights here.

Best,

Shuai

-----Original Message-----

    Regards

    -éric

        Thanks Eric!

        and ASTM F3411.

Currently

"

      Standardization

"

Suggested changes

"

      Standardization

"

SZ/ updated in -21.

        non-US concept?

"

DAA:  Detect And Avoid

V2V:  Vehicle-to-Vehicle

"

        reference.

          "RID" never used alone

        tracking"

          "ID" never used alone

SZ/ Updated.

        definition?

        extension.

--
Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      [email-masked]<mailto:[email-masked]>

There's no limit to what can be accomplished if it doesn't matter who gets the credit
--
Tm-rid mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tm-rid

--
Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      [email-masked]<mailto:[email-masked]>

There's no limit to what can be accomplished if it doesn't matter who gets the credit

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Card, Stu" <[email-masked]>
Date: Mon, 14 Mar 2022 03:28:04 -0400

I have no objection to this suggested rewording, but Eric had asked us to
make clear that, just as DRIP optionally extends baseline F3411, CS-RID and
direct contact (e.g. w/HIP) each optionally extend baseline DRIP, so some
further tweaking of the wording may be needed.

On Mon, Mar 14, 2022 at 3:01 AM <[email-masked]> wrote:

> *De :* Robert Moskowitz <[email-masked]>
> *Envoyé :* dimanche 13 mars 2022 02:43
> *À :* Card, Stu <[email-masked]>
> *Cc :* shuai zhao <shuai.zhao=[email-masked]>; [email-masked];
> Robert Moskowitz <[email-masked]>; Adam Wiethuechter <
> [email-masked]>; Laura Welch <
> [email-masked]>; Andrei Gurtov <[email-masked]>; Eric
> Vyncke (evyncke) <[email-masked]>; BOUCADAIR Mohamed INNOV/NET <
> [email-masked]>; Daniel Migault <[email-masked]>
> *Objet :* Re: [Drip] New Version Notification for
> draft-ietf-drip-arch-21.txt
>
>
>
>
>

---

From: <[email-masked]>
Date: Mon, 14 Mar 2022 07:38:59 +0000

Re-,

That comments is already covered by this text:

      -  Harvesting Broadcast RID messages for UTM inclusion, with the
         optional DRIP extension of Crowd Sourced Remote ID (CS-RID,
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
         Section 6), using the DRIP support for gateways required by
         GEN-5 [RFC9153].

No need to be redundant.

Cheers,
Med

De : Tm-rid <[email-masked]> De la part de [email-masked]
Envoyé : lundi 14 mars 2022 08:02
À : Robert Moskowitz <[email-masked]>; Card, Stu <[email-masked]>; shuai zhao <shuai.zhao=[email-masked]>
Cc : [email-masked]
Objet : Re: [Drip] New Version Notification for draft-ietf-drip-arch-21.txt

Hi Bob, Shuai, all,

OLD:

NEW:

Thank you.

Cheers,
Med

De : Robert Moskowitz <[email-masked]<mailto:[email-masked]>>
Envoyé : dimanche 13 mars 2022 02:43
À : Card, Stu <[email-masked]<mailto:[email-masked]>>
Cc : shuai zhao <shuai.zhao=[email-masked]<mailto:shuai.zhao=[email-masked]>>; [email-masked]<mailto:[email-masked]>; Robert Moskowitz <[email-masked]<mailto:[email-masked]>>; Adam Wiethuechter <[email-masked]<mailto:[email-masked]>>; Laura Welch <[email-masked]<mailto:[email-masked]>>; Andrei Gurtov <[email-masked]<mailto:[email-masked]>>; Eric Vyncke (evyncke) <[email-masked]<mailto:[email-masked]>>; BOUCADAIR Mohamed INNOV/NET <[email-masked]<mailto:[email-masked]>>; Daniel Migault <[email-masked]<mailto:[email-masked]>>
Objet : Re: [Drip] New Version Notification for draft-ietf-drip-arch-21.txt

Dear DRIP,

Actually 3 entity types:

Entity 1:

Finders

Entity 2:

Entity 3:

So how to say that here.

*   Remote ID Finders

================

Best,

Shuai

-----Original Message-----

    Regards

    -éric

        Thanks Eric!

        and ASTM F3411.

Currently

"

      Standardization

"

Suggested changes

"

      Standardization

"

SZ/ updated in -21.

        non-US concept?

"

DAA:  Detect And Avoid

V2V:  Vehicle-to-Vehicle

"

        reference.

          "RID" never used alone

        tracking"

          "ID" never used alone

SZ/ Updated.

        definition?

        extension.

Thank you.

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 14 Mar 2022 12:29:27 -0400

On 3/14/22 03:01, [email-masked] wrote:
> Standard

I am OK with this.

> * s/a TBD interface to a CS-RID SDSP/a new interface to a CS-RID SDSP

Agree.

> *Cc :* shuai zhao <shuai.zhao=[email-masked]>; 
> [email-masked]; Robert Moskowitz <[email-masked]>; Adam 
> Wiethuechter <[email-masked]>; Laura Welch 
> <[email-masked]>; Andrei Gurtov <[email-masked]>; Eric 
> Vyncke (evyncke) <[email-masked]>; BOUCADAIR Mohamed INNOV/NET 
> <[email-masked]>; Daniel Migault <[email-masked]>
>             co-author’s dedication.  Also, great appreciation for
>             Laura’s help for text improvement.
>
>             There are only two items left which need a bit more
>             explanations. @[email-masked]
>             <mailto:[email-masked]>
>
>         architecture.  CS-RID specifically defines a SDSP that
>         correlates the harvested information, performs multilateration
>         when possible and feeds the information into the UTM.
>
>         Entity 3:
>
>             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
>
>             @[email-masked]
>             <mailto:[email-masked]> anything new you can add?
>
>
>         I missed this.  I could have added more, basically lifting
>         text from drip-rid.  Let's see what I might do here and not
>         open a whole can of worms for review and comments.
>
>         ================
>
>             <mailto:&lt;[email-masked]&gt;>om>,
>             "[email-masked]" <mailto:&quot;[email-masked]&quot;>
>             <[email-masked]> <mailto:&lt;[email-masked]&gt;>
>
>             <mailto:&lt;[email-masked]&gt;>om>,
>             "shuaiizhao(Shuai Zhao)" <[email-masked]>
>             <mailto:&lt;[email-masked]&gt;>om>,
>             "[email-masked]" <mailto:&quot;[email-masked]&quot;>
>             <[email-masked]> <mailto:&lt;[email-masked]&gt;>
>
>                    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)
>
>                     > Sec 1: s/Unmanned Aircraft System Remote
>             Identification and tracking
>
>                 EV> feel free to keep "and tracking"; my point was
>             rather to introduce UAS and RID acronyms just after their
>             expansion, not globally
>
>             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.
>
>                    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
>
>             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.
>
>                     > Sec 1.2.1 is it "received UAS ID" or "received
>             UAS RID" ? If "ID", is it
>
>             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.
>
>                UAS Remote Identification (RID) is an application
>             enabler which consists of UAS ID verification process for
>             a UAS
>
>                     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.
>
>                     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 "e.g. their respective Global Navigation
>             Satellite System (GNSS) derived locations."
>
>                     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
>
>             comment.  "4-D" was defined in RFC9153, should we repeat
>             the definition here? So maybe I did not understand Eric's
>             concern.
>
>                     > 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
>
>             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/ 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.
>
>                      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?
>
>                     > 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
>
>             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/ 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/ 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?
>
>                      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.
>
>             " 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."
>
>                     > 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"
>
>             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/  It was expanded in its first usage for sure. Bu in
>             -21, I also add "HI" in "abbreviations" section for
>             completeness.
>
>                    Sec 4.2: I cannot parse " This is in contrast to
>             general IDs (...) as the subject in an X.509 certificate."
>
>                   Sec 4.2: " by avoiding an explicit encoding
>             technology like ASN.1 or CBOR", so what encoding should be
>             used ?
>
>             SZ/ updated to "existing", let me know everyone knows a
>             better word for replacement.  Or "obvious" or.......
>
>                     > Sec 5: what are "public and private UAS
>             information" ? The different
>
>                     > types of info were not defined earlier in the
>             document or provide a
>
>             SZ/ Updated as " DRIP registries hold both public and
>             private UAS information (See PRIV-1 in
>             registration process."
>                     > Sec 5.1.1 should "opaque" be used rather than
>             "silent" in "they may be
>
>                 EV> then indeed 'opaque' is the wrong word but I am
>             not sure that 'silent' is better. No proposal of mine
>             though :(
>
>                   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?
>
>                     > ...
>
>                 EV> good idea, simply enumerate (reliability,
>             scalability, ...) rather than using "as specified in " ;-)
>
>                     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)
>
>             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)
>
>                    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.
>
>                     > Sec 7.1 this should really be part of the
>             overall architecture of section 1
>
>                     > 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
>
>                 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.
>
>                     Sec 7.2 " multilateration" should briefly be
>             described, perhaps in the terminology section
>
>                     > Sec 8: should be less descriptive and perhaps
>             not even mention HIP & BEET
>
>                 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.
>
>                 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
>