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

[Robert Moskowitz <[e-mail]>]

On 3/14/22 03:01, [e-mail] wrote:
> Standard
>
> 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 am OK with this.

> 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

Agree.

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

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

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