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

["shuaiizhao(Shuai Zhao)" <[e-mail]>]

DRIP Enthusiast,

Revision 17 is uploaded which is trying to address the comments received during IETF week. Please see attached emails thread for previous conversations.

Best,
Shuai

-------------------------------------------------------------------------------

A new version of I-D, draft-ietf-drip-arch-17.txt
has been successfully submitted by Shuai Zhao and posted to the
IETF repository.

Name:                    draft-ietf-drip-arch
Revision:                17
Title:                       Drone Remote Identification Protocol (DRIP) Architecture
Document date:    2021-11-10
Group:                    drip
Pages:                    26
URL:            https://www.ietf.org/archive/id/draft-ietf-drip-arch-17.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-drip-arch/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-drip-arch
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-drip-arch-17

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




The IETF Secretariat

--- Begin Message ---

Thanks Bob, see reply inline. 

On 10/31/21, 2:42 PM, "Tm-rid on behalf of Robert Moskowitz" <[e-mail] on behalf of [e-mail]> wrote:

    Continuing with Sec 5.

    All is good IMO in sec 5.

    Sec 6.

    Para 2:

    Would a reader know what "offline or online" mean?  This is the first 
    and only use of both terms.  So we need to actually define them here.

    Also I do not think Broadcast RID needs to send messages that 
    authenticate all the way to the root.  This is rarely done in other 
    protocols.  Having something signed by the HDA and the HDA's HHIT,HI is 
    necessary, but sufficient along with access to a cache of the rest of 
    the hierarchy.  Similar to web browser CA root cache and DNS root cache.

    so

        An optimization of different DRIP Authentication Messages allows an
        Observer, without Internet connection (offline) or with (online), to be
        able to validate a UAS DRIP ID in real-
        time.  First is the sending of Broadcast Attestations (over
        DRIP Link Authentication Messages) containing the relevant registration
        of the UA's DRIP ID in the claimed Registry.  Next is
        sending DRIP Wrapper Authentication Messages that sign over
        both static (e.g. above registration) and dynamically changing data
        (such as UA location data).  Combining
        these two sets of information an Observer can piece together a chain
        of trust and real-time evidence to make their determination of the
        UAs claims.

Shuai/ Implemented as suggested . Please let me know if anyone has different option. 

    Sec 7

    In 1.3, we used: Surveillance Supplemental Data Service Provider

    We should follow through with that class of SDSP here or drop it in 1.3.

    And in 7.2 perhaps:

        A CS-RID SDSP should appear (i.e. present the same interface) to a
        Net-RID SP as a Net-RID DP.  A CS-RID SDSP aggregates and processes
        (e.g., estimates UA location using including using multilateration when
        possible) information collected by CS-RID Finders.

Shuai/ Implemented as suggested. However, we will update 1.3, so added a reminder in " Editor-note-8: double check above paragraph after editor-note-1 is resolved."

    Sec 8.

    One of the ways in which DRIP can enhance [F3411-19] with


Shuai/ Implemented as suggested

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

    And that completes my review.

    Bob


    -- 
    Tm-rid mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/tm-rid

--- End Message ---

--- Begin Message ---

Sounds good to me. Updated in -17. 

Best,
Shuai

On 11/2/21, 1:51 PM, "Tm-rid on behalf of Robert Moskowitz" <[e-mail] on behalf of [e-mail]> wrote:

    per F3411 reference.

    Adam and I have worked out just to have [F3411] and leave off the ver 
    (year) suffix.

    And the year as n.d.

    Yogi's famous quote about the lady singing, Adam and I are comfortable 
    that any last minute changes will not impact the content put in for 
    DRIP's needs in the next version due out sometime in the foreseeable future.

    This cleans up references to ASTM in all of our documents.

    Bob

    On 11/1/21 8:33 AM, Robert Moskowitz wrote:
    > I few more comments:
    >
    >    [F3411-19] ASTM International, "Standard Specification for Remote ID
    >               and Tracking", February 2020,
    > <http://www.astm.org/cgi-bin/resolver.cgi?F3411>.
    >
    > and
    >
    >    [MAVLINK]  "Micro Air Vehicle Communication Protocol", 2021,
    >               <http://mavlink.io/>.
    >
    >
    >

    -- 
    Tm-rid mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/tm-rid

--- End Message ---

--- Begin Message ---

All Udpated. Thanks Bob. 

On 11/1/21, 5:34 AM, "Tm-rid on behalf of Robert Moskowitz" <[e-mail] on behalf of [e-mail]> wrote:

    I few more comments:

        [F3411-19] ASTM International, "Standard Specification for Remote ID
                   and Tracking", February 2020,
    <http://www.astm.org/cgi-bin/resolver.cgi?F3411>.

    and

        [MAVLINK]  "Micro Air Vehicle Communication Protocol", 2021,
                   <http://mavlink.io/>.



    -- 
    Tm-rid mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/tm-rid

--- End Message ---

--- Begin Message ---

Hi Bob and All, 


On 10/29/21, 12:41 PM, "Tm-rid on behalf of Robert Moskowitz" <[e-mail] on behalf of [e-mail]> wrote:

    in 1.2:

    We just had fig 2 showing the Observer communicating with the Net-RID 
    DP, then say:

    It also prescribes data elements (in JSON) between Observer and USS

    I think that needs to be Net-RID DP.

    An Observer may well not have any relationship with any USS, though 
    Net-RID DP may well be a service provided within many USS systems.

Shuai/ Update to Net-RID DP, please speak up if this is wrong. 

    in 1.3:

    Where does "Surveillance Supplemental Data Service Provider (SDSP)" come 
    from?  It is only mentioned here.  I do not see this term in F3411-19 or 
    in WK63418 UAS Traffic Management (UTM) UAS Service Supplier (USS) 
    Interoperability Specification ver 0.4.1 (in ballot).  SDSP normally 
    means Supplemental Data Service Provider, so here it probably should be 
    SSDSP?

    Also we need to add that these SSD

    I like the term and should "upgrade" from just SDSP in crowd-source-rid?

    Should, can we, reference a source for this concept?

Shuai/ Stu will update this figure. I have add the editor-note as reminder

    Sec 3:

    Should this really be sec 2.4?  Its content is Definitions of terms.

    Seems I mentioned this in past reviews.

Shuai/ Ah... It is not. I don’t remember Back when, we agreed this to be a separated section.  I added the editor-note-7 as reminder to us to make a final agreement. 

    Sec 4.1:

    We are in a bit of a timing quandary, in that we can only reference 
    F3411-19, yet need to talk about the next version currently being 
    balloted.  This will either be F3411-21 or -22 (and interesting if they 
    quickly get the NEXT work item down and end up with TWO -22 versions!).

    Since we cannot reference ASTM draft documents (not unlike IEEE 802, 
    actually), how do we handle this?  I think we need some clarifying text 
    that the text here is about a draft version; we cannot provided any 
    information on its likelihood of being published.

    Also we may well have this RFC published prior to F3411-21!

    So:

    Broadcast RID, especially its support for Bluetooth 4, imposes severe
    constraints.  ASTM RID [F3411-19] allows a UAS ID of types 1, 2 and 3 of
    20 bytes; a revision to [F3411-19], currently in balloting (as of Oct 
    2021),
    adds type 4, Session IDs, to be
    standardized by IETF and other standard development organizations
    (SDOs) as extensions to ASTM RID, consumes one of those bytes
    to index the sub-type, leaving only 19 for the identifier (see
    Requirement ID-1).  Likewise, the maximum ASTM RID [F3411-19]
    Authentication Message payload is 201 bytes for most authentication
    types, but for type 5, also added in this revision, for IETF and other 
    SDOs to develop
    Specific Authentication Methods as extensions to ASTM RID, one
    byte is consumed to index the sub-type, leaving only 200 for DRIP
    authentication payloads, including one or more DRIP entity
    identifiers and associated authentication data.

Shuai/ Implemented as suggested in revision -17. Please speak up if you don’t agree. 

    4.2:


        A UAS equipped for DRIP Broadcast RID SHOULD be provisioned not only 
    with
        its HHIT but also with the HI key pair from which the HHIT was
        derived to enable message
        signature.  A UAS equipped for DRIP Network RID SHOULD be provisioned
        likewise; the private key resides only in the ultimate source of
        Network RID messages (i.e. on the UA itself if the GCS is merely
        relaying rather than sourcing Network RID messages).  Each Observer
        device SHOULD be provisioned either with public keys of the DRIP
        identifier root registries or certificates for subordinate
        registries.

    And I think that first "UAS" should be "UA".


Shuai/ Updated to "UA" in revision 17. 

        A self-attestation of a HHIT used as a UAS ID can be done in as
        little as 84 bytes, by avoiding an explicit encoding technology like
        ASN.1 or Concise Binary Object Representation (CBOR [RFC8949]). This
        attestation consists of only the HHIT, a timestamp, and the EdDSA
        signature on them.

    I should point out that though this is true, Adam, Stu, and I are 
    debating the 'final' format (Adam 36 bytes to this).  I feel this is 
    correct for the architecture.

Shuai/ no actions.

        A DRIP registration process based on the explicit hierarchy within a
        HHIT provides manageable uniqueness of the HI for the HHIT (defense
        against a cryptographic hash second pre-image attach on the HHIT
        (e.g. multiple HIs yielding the same HHIT, see Requirement ID-3).  A
        lookup of the HHIT into this registration data provides the
        registered HI for HHIT proof.  A first-come-first-serve registration
        for a HHIT provides deterministic access to any other needed
        actionable information based on inquiry access authority (more
        details in Section 5.2).


    /s/attach/attack/  It was correct in -15.

Shuai/ Updated now. thanks,

    You have parenthesis nested within parenthesis above and it is 
    confusing.  Instead:

        A DRIP registration process based on the explicit hierarchy within a
        HHIT provides manageable uniqueness of the HI for the HHIT.  This is 
    the defense
        against a cryptographic hash second pre-image attack on the HHIT
        (e.g. multiple HIs yielding the same HHIT, see Requirement ID-3).  A
        lookup of the HHIT into this registration data provides the
        registered HI for HHIT proof.  A first-come-first-serve registration
        for a HHIT provides deterministic access to any other needed
        actionable information based on inquiry access authority (more
        details in Section 5.2.

Shuai/ Updated now. thanks,

    sec 4.4

    Minor edit:

        hierarchy within which is registered and a cryptographic hash of

    I think I got that right....

    At this point I am stopping and will pick up shortly with sec 5.

    Bob

Shuai/ Updated now. thanks,


    On 10/25/21 3:18 PM, [e-mail] wrote:
    > A New Internet-Draft is available from the on-line Internet-Drafts directories.
    > This draft is a work item of the Drone Remote ID Protocol WG of the IETF.
    >
    >          Title           : Drone Remote Identification Protocol (DRIP) Architecture
    >          Authors         : Stuart W. Card
    >                            Adam Wiethuechter
    >                            Robert Moskowitz
    >                            Shuai Zhao
    >                            Andrei Gurtov
    > 	Filename        : draft-ietf-drip-arch-16.txt
    > 	Pages           : 26
    > 	Date            : 2021-10-25
    >
    > Abstract:
    >     This document describes an architecture for protocols and services to
    >     support Unmanned Aircraft System Remote Identification and tracking
    >     (UAS RID), plus RID-related communications.  This architecture
    >     adheres to the requirements listed in the DRIP Requirements document.
    >


    -- 
    Tm-rid mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/tm-rid

--- End Message ---

--- Begin Message ---

Hi Stu, 

 

 

From: "Card, Stu" <[e-mail]>
Date: Tuesday, November 9, 2021 at 7:43 PM
To: "shuaiizhao(Shuai Zhao)" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, Daniel Migault <[e-mail]>, Robert Moskowitz <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: [Internet]Re: RE: upcoming DRIP session (multi sub-topics, was : IETF#112: Note Taker)

 

I went through all of these issues while preparing the comprehensive review that I submitted last night. 

Some I felt had been addressed adequately in -arch-16,

On some, I just acquiesced to the current text, even if I don't like it, and didn't re-list them.

On some, I just repeated/clarified my previous point, which had not yet been addressed.

Shuai/ Since am getting email from different email thread, I somewhat lost track of what has not been addressed. Please let me know where new text needs to be changed/updated

On some, I updated my point to reflect changes that have been made,

I also added some new points that arose due to changes that have been made.

I did not provide suggested replacement text, but promised that I would today.

I am just starting on those replacement text blurbs now and will send some before I sleep.

Shuai/ please either confirm or give me a clear instruction/text for the 13 issues I listed below. 

 

I would appreciate if you can provide fix for all of the remaining comments in this email thread then I can fix them together. 

 

 

On Tue, Nov 9, 2021 at 1:18 PM shuaiizhao(Shuai Zhao) <[e-mail]> wrote:

Hi All,

Since revision -16, I have received 3 emails from Stu and Bob for reviews. 

Comments and replies are getting messy, to avoid missing any of your previous comments, I am listing things below which still need Stu's feedback. 

I saw Stu provides another comment but not related to the things we are desperately need for publication. 

I suggest we fix them one by one, either confirm or propose text. 

1.
-------------
> FAA paragraph:
> - "whereafter" -> "thereafter"
> - Sentence 2 could be deleted if Sentence 1 had appended to it "imposing
> requirements on UAS manufacturers and operators".
>
> Shuai/ Not sure what do you mean here. Some ppl liked and insisted on
> referring to ADS-B in arch-.
>
------------
2. 
------------
> p. 4 EASA paragraphs:
> -[Delegated] and [Implementing] don't make sense without the word
> "Regulations" after each of them.
>
> Shuai/ I don’t see why we have to a add “regulation” after each word
> since the context here said they are “regulations”. Adding the
> “Regulations” after each word also does not make sense.  See below:
>
>>The EASA has published the {{Delegated}}regulationsin 2019 to provide
> regulations for unmanned aircraft systems and on third-country operators
> of unmanned aircraft systems and followed with implementation regulation
> on the rules and procedures for the operation of unmanned aircraft
> Regulations {{Implementing}} regulations.
>
>
------------

3. 
------------
> p. 5 Section 1.2.1:
> - Figure 1 still uses stick figures and aircraft silhouettes, which were
> replaced with boxes in the Requirements document, based on comments
> received, I suggest replacing w/Requirements Figure 4
>
>
> - last sentence in section: move 1st parenthetical notation "(see
> Section 7)" to replace 2nd "(e.g., an entire military base or a national
> forest)"
>
> Shuai/ If I understood you right, you want to cut (e.g. around airports,
> public  gatherings, and other sensitive areas) from Section 7 and
> replace "(e.g., an entire military base or a national forest)” in
> Section 2, right?
------------

4. 
------------
>
> p. 5 Section 1.2.2
> - After spelling out "Network Remote ID" once, further instances can all
> be shortened to "Network RID" or even "Net-RID".
> - "A RID data dictionary and data flow for Network RID are defined in
> [F3411-19]" -> "[F3411-19] defines a RID data dictionary and data flow
> for Internet based information delivery"
> - "Observer" is our own DRIP term; F3411 calls the consumer of Network
> RID information the "client", which word previously appeared here; we
> could say "Observer's Network RID client device".
> - A definition of UAS does not belong here. If one must be placed in
> this document, singular and plural forms need to agree.
>
> Shuai/ Stu,  I recall we had this conversation long time ago, not sure
> why we are going down this path again. Please choose one then we stick
> to it.

------------

5. 
------------
> - Figure 3 is confusing:
>   = the Observer _sees_ (or hears, or otherwise senses) UAS but does not
> _connect_ to them;
>   = the Observer can connect via the Internet to another USS (and thence
> via the DSS) for queries re: the UAS.
>
> Shuai/ This require a little more drawing. I am thinking postponing to
> another revision once we have agreed on the final drawing.
>

6
------------
> p. 8 Section 1.4:
> - Most of the 1st paragraph (all but reference to Figure 4) belongs
> earlier in Section 1, certainly before Sections 1.2 & 1.3
>
> Shuai/ Is that necessary to remove this at all? Can we live with it? 
>
------------

7
------------
> - In our debates over figures this past summer, I think we agreed to
> replace this Figure 4 with the attached figure, which was deemed too
> detailed for the Requirements doc.
>
> Shuai/ I recall chair prefer not to change the figure. There are many
> terms are not used/explained such as GPOD, PSOD….
------------

8
------------
> p. 9 Section 1.4:
> - "This document outlines the UAS RID architecture" -> "This document
> outlines the DRIP architecture in the context of the UAS RID architecture"
> - ("including DNS:" -> "(DNS)"
> - need a line about authentication formats/protocols (after DNS etc.,
> before "Harvesting")
> - need a line about Observer to Pilot (O2P) comms (after "Harvesting",
> before "Privacy")
>
> Shuai/ in order to reduce debate on the wording, please provide the
> sentence you would like to see for both of above bullet points.
>
------------

9
------------
> p. 13 Section 4.2:
> - "the HHIT RID" -> "a HHIT used as a UAS ID" because "RID" is neither
> "Remote Identity" nor "Remote Identifier" but "Remote Identification" so
> "RID" should never be used this way, instead use "UAS ID"
> - last paragraph of this section is suspect, we need both Adam and Bob
> to review it carefully
>
> Shuai/ Bob and Adam, please review as Stu pointed out.
------------

10 
------------
> pp. 17ff All references should be checked for accurate titles, live
> links, citation style, etc.
>
> Shuai/ Left for another revision
>
------------


11
------------
> pp. 20ff Section A needs some tweaking to be standard English grammar,
> punctuation and style.
>
> Shuai/ Left for another revision
>
------------

12
------------
> p. 21 Section A.2:
>   - TFR is Temporary Flight Restriction (not Rule);
>   - "fly rules" is non-standard terminology; see also next comment.
> p. 22 Section A.3: "UAS fly map" appears only in this document and one
> 3GPP document; is there a standard term?
>
> Shuai/ it is referent to
> https://www.faa.gov/uas/commercial_operators/uas_facility_maps/
> <https://www.faa.gov/uas/commercial_operators/uas_facility_maps/>, The
> FAA Facility Map. Changed to “UAS Facility map”
>
------------

13.
------------
> p. 23 Acknowledgements should be updated to include everyone who has
> helped, other than authors.
>
> Shuai/ Please provide a list and text.
------------



On 11/8/21, 10:50 PM, "[e-mail]" <[e-mail]> wrote:

    Hi Stu, all, 

    Thank you for accepting to take minutes. Much appreciated, as usual.

    Agree with your both points on the arch draft. The figure fits the arch to illustrate a usage scenario. However, we need to make sure that:
    * all the acronyms/interfaces should be called out in the text.
    * make it clear that some interfaces are not within the scope of drip (DAA/V2V, for example). 

    BTW, may I remind us all that the plan for the arch I-D was as follows: 

    ==
    In order to help Shuai digest and integrate any pending proposed change, I suggest the following plan:

    .   Any listed author (including the editor) to reply before November 3rd whether you are OK with the latest version or raise any issue you have. 
    .   If an issue is raised, please make sure a text change is proposed.
    .   Shuai to prepare a revised version to be submitted in the IETF week. 

    Please note that we are not seeking for a perfect I-D :-)
    ==

    Thank you. 

    Cheers,
    Med

    > -----Message d'origine-----
    > De : Daniel Migault <[e-mail]>
    > Envoyé : lundi 8 novembre 2021 20:37
    > À : Stuart W. Card <[e-mail]>; BOUCADAIR Mohamed
    > INNOV/NET <[e-mail]>; shuaiizhao(Shuai Zhao)
    > ([e-mail]) <[e-mail]>
    > Cc : [e-mail]
    > Objet : Re: upcoming DRIP session (multi sub-topics, was : IETF#112: Note
    > Taker)
    > 
    > 
    > 
    > ________________________________________
    > From: Stuart W. Card <[e-mail]>
    > Sent: Monday, November 8, 2021 1:01 PM
    > To: [e-mail]; shuaiizhao(Shuai Zhao)
    > ([e-mail])
    > Cc: [e-mail]
    > Subject: upcoming DRIP session (multi sub-topics, was : IETF#112: Note
    > Taker)
    > 
    > Med, Shuai, et al --
    > 
    > As Shuai is presenting and I am not, I can more easily take notes.
    > 
    > 
    > mglt: great thanks!
    > 
    > I would not mind being allocated 1 minute during the introduction to give
    > a quick oral (no slides unless you want me to make 1-2) update:
    > 
    > mglt: during the status, that should be ok, please add yourself on the
    > agenda on the etherpad, so we are sure we donot forget you.
    > 
    > - Currently proposed (consensus of the ASTM working group but not yet
    > balloted upon) changes in ASTM F3411 enable and recognize our DRIP
    > extensions thereto.
    > 
    > - Multiple US Federal agencies now recognize the need to instantly
    > establish Observer to Pilot (O2P) private communications based on RID.
    > 
    > Perhaps Bob should use 1 minute to update everyone on his interactions in
    > the ICAO Trust Framework Study Group?
    > 
    > Perhaps Adam should use 1 minute to update everyone on his prototype
    > implementation of much of DRIP (including solution space designs that are
    > still individual rather than working group drafts)?
    > 
    > I am going to send today my review of Shuai's latest -arch. There is
    > confusion on some points, including:
    > 
    > 
    > - Do we really want to redundantly define in -arch a subset of the terms
    > defined in -reqs despite having declared that -reqs would serve as the
    > common glossary for DRIP?
    > 
    > mglt: that is good. no, just mention the one not defined in reqs.
    > 
    > - The attached figure that I proposed several months ago to show the big
    > picture, which I believe you said did not belong in -reqs but did belong
    > in -arch, Shuai has the impression you don't want in -arch either? Note
    > that GPOD and PSOD are not terms we intend to use anywhere else, just
    > abbreviations to keep the figure compact, which we define as such in the
    > legend below the figure. The figure requires a disclaimer that it does not
    > show one way Broadcast RID wireless links from each UA to all receivers in
    > range (which would clutter the figure confusingly).
    > 
    > mglt: my last recollection of the draft is very very old. do whatever you
    > think is best and will speed up the draft to be in a state ready to be
    > published. ;-)
    > 
    > After resolving a few such content issues and cleaning up a few remaining
    > mundane editorial issues, -arch should move forward.
    > 
    > mglt: I hope so.
    > 
    > Thanks.
    > 
    > -- Stu
    > 
    > On 11/8/2021 9:35 AM, [e-mail] wrote:
    > > Hi Stu, Shuai,
    > >
    > > Would you be willing to take minutes for the forthcoming drip session?
    > >
    > > Thank you in advance.
    > >
    > > Cheers,
    > > Med
    > --
    > -----------------------------------------
    > Stuart W. Card, PhD, Principal Engineer
    > AX Enterprize, LLC  https://protect2.fireeye.com/v1/url?k=4771b1b2-
    > 18ea889f-4771f129-8692dc8284cb-6d846366b7baec10&q=1&e=7a467ce1-a2d6-4239-
    > 9406-d65e113e0df7&u=http%3A%2F%2Fwww.axenterprize.com%2F
    > 4947 Commercial Drive, Yorkville NY 13495

    _________________________________________________________________________________________________________________________

    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.

--- End Message ---