Subject: Re: [Drip] [Internet]Re: AD review for draft-ietf-drip-arch-20

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Wed, 23 Feb 2022 21:13:06 +0000

Thanks Eric and Stu for the comment, 

It took longer to reply than I expected. Please see my feedback inline with SZ/. 

Names are called, please response with your feedback. __

Best,
Shuai

-----Original Message-----
From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wednesday, February 2, 2022 at 02:42
To: "Stuart W. Card" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "shuaiizhao(Shuai Zhao)" <[email-masked]>, "[email-masked]" <[email-masked]>
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]> 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)

        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. 

       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. 

       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 
        > 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. 

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.

        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 

        Sec 1.2.2 " GNSS" expand at first use
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

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. 
 
        Sec 1.2.2 increment the year in " currently (in the year of 2021)"

SZ/ Make sense to me.  Updated to 2022

        > ...
        > 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"

         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. 
 
         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 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
" 

        > ...
        > 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. 

        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."

         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? 
 
         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."

        > ...
        > 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. 

        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.  

       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.......

        > ...
        > 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."

       Sec 5.1.1 s/ public registry/ public information registry/

SZ/ Updated. 

        > ...
        > 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? __

      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? 

        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. 
       
        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. 

       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 " 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.

    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
SZ/ @Card, Stu "multilateration" was not described in req. Should we do it here? 

        > 
        > 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? 

    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: <[email-masked]>
Date: Thu, 24 Feb 2022 07:31:28 +0000

Hi Shuai, all,

Thank you for taking care of the comments. 

Please see one minor comment inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Tm-rid <[email-masked]> De la part de shuaiizhao(Shuai
> Zhao)
> Envoyé : mercredi 23 février 2022 22:13
> À : Stuart W. Card <[email-masked]>; [email-masked]; Eric
> Vyncke (evyncke) <[email-masked]>; Eric Vyncke (evyncke)
> <evyncke=[email-masked]>
> Cc : [email-masked]; [email-masked];
> [email-masked]
> Objet : Re: [Drip] [Internet]Re: AD review for draft-ietf-drip-arch-20
> 
> Cc: "[email-masked]"
> <[email-masked]>, "[email-masked]"
> <[email-masked]>, "shuaiizhao(Shuai Zhao)"
> <[email-masked]>, "[email-masked]" <[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)

[Med] I-D.ietf-drip-reqs should be replaced with 9153. For the abstract, please note that https://www.ietf.org/how/ids/guidelines/ says:

"An abstract should be complete in itself, so it should not contain citations unless they are completely defined within the abstract."

Rather than using [RFC9153], I suggest we simply go for the following in the abstract: 

   This document describes an architecture for protocols and services to
   support Unmanned Aircraft System (UAS) Remote Identification (RID)
   and tracking, plus UAS RID-related communications.  This architecture
   adheres to the requirements listed in the DRIP Requirements document
   (RFC 9153).

Thanks. 

_________________________________________________________________________________________________________________________

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: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Fri, 25 Feb 2022 03:25:06 +0000

Thanks Med for the advice, I will share a updated revision later.

Best,
Shuai

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Wednesday, February 23, 2022 at 23:31
To: "shuaiizhao(Shuai Zhao)" <[email-masked]>, "Stuart W. Card" <[email-masked]>, "[email-masked]" <[email-masked]>, "Eric Vyncke (evyncke)" <[email-masked]>, "Eric Vyncke (evyncke)" <evyncke=[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Internet]RE: [Drip] Re:  AD review for draft-ietf-drip-arch-20

    Hi Shuai, all,

    Cheers,
    Med

    Thanks.