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

[Robert Moskowitz <[e-mail]>]

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
>

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