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

From: Daniel Migault <[email-masked]>
Date: Tue, 31 Aug 2021 10:07:17 -0400

Hi,

I am just following up the discussion. My expectation is that arch-16 will
address the comments made during the IETF week. I am wondering if I am
missing anything and if not I am wondering when this version is expected to
be published.

Yours,
Daniel

On Tue, Jul 27, 2021 at 7:23 PM Card, Stu <[email-masked]> wrote:

> Shuai --
>
> Thanks again!
>
> Your -arch-15 is greatly improved over previous revisions, addresses most
> of my editorial nits and begins to address my substantive concerns.
>
> I have gone back through the points in my previous 2 reviews, checked how
> they look in the new version and written my updated review below.
>
> ==
>
> -arch Section 1.1
>
> "CAAs currently promulgate performance-based regulations that do not
>    specify techniques, but rather cite industry consensus technical
>    standards as acceptable means of compliance."
>
> should follow
>
> "Civil Aviation Authorities (CAAs) worldwide are mandating UAS RID."
>
>
> also "For example, the
>    European Union Aviation Safety Agency (EASA) has published
>    [Delegated] and [Implementing] Regulations."
>
> gives EASA less apparent weight than
>
>    "Federal Aviation Administration (FAA)
>
>       The FAA published a Notice of Proposed Rule Making [NPRM] in 2019
>       and whereafter published the "Final Rule" in 2021 [FAA_RID].  In
>       FAA's final rule, it is clearly stated that Automatic Dependent
>       Surveillance Broadcast (ADS-B) Out and transponders can not be
>       used to serve the purpose of an remote identification.  More
>       details about ADS-B can be found in Appendix B."
>
> but really the FAA paragraph is about ADS-B.
> This should be reorganized to give EASA and FAA equal weight,
> clarify that they are regulators unlike ASTM and 3GPP which follow,
> and separate the ADS-B discussion from the FAA introduction.
>
> ==
>
> -arch section 1.2.1
>
> "With queries sent over the Internet using harvested RID (see
>    Section 6), the Observer may gain more information about those
>    visible UAS" is only true if the locally observed UAS is (or very
>    recently was) observed somewhere else; harvesting RID is not so much
>    about learning more about directly observed nearby UAS as it is about
>    surveillance of areas too large for local direct visual observation &
>    direct RF link based ID (e.g., an entire air force base, or even
>    larger, a national forest)"
>
> inserts text from me that was commentary, not intended to be in-lined.
> The text I suggested after reviewing -arch-14 follows.
>
> "Broadcast RID provides information only about UA within direct RF LOS,
> typically similar to visual LOS, with a range on the order of 1 km.
> This information may be 'harvested' from received broadcasts and made
> available via the Internet (see Section 6), enabling surveillance of
> areas too large for local direct visual observation or direct RF link
> based ID (e.g., an entire military base or a national forest)."
>
> ==
>
> -arch Section 1.2.2
>
> "network RID" -> "Network RID" everywhere
>
> "fulfill Observers the RID data query to the NET-RID DP."
> ->
> "fulfill Observer's queries to the Net-RID DP."
>
> "[F3411-19] prescribes the protocols only between the Net-RID SP, Net-
>    RID DP, and the Discovery and Synchronization Service (DSS).  DRIP
>    can address standardization of protocols between the UA and GCS,
>    between the UAS and the Net-RID SP, and/or between the Net-RID DP and
>    Observer devices."
>
> and
>
> "[F3411-19] prescribes the protocols between the Net-RID SP, Net-RID
>    DP, and the Discovery and Synchronization Service (DSS).  It also
>    prescribes data elements (in JSON) between Observer and DSS.  DRIP
>    addresses standardization of secure protocols between the UA and GCS
>    (over direct wireless and Internet connection), between the UAS and
>    the Net-RID SP, and/or between the Net-RID DP and Observer devices."
>
> are redundant. The second version is better, but still not quite right.
> "DRIP addresses" is an overstatement at present: DRIP _could_ address
> these things; it might require a charter change; we don't do it yet.
>
> "The summary of network RID data flows work as follows:
>
>    *  The UA's RID data is generated from a UAS which consists of UAs
>       and GCSs.
>
>    *  The RID data is transferred from the UA to the GCS via a RF (Radio
>       Frequency) link.
>
>    *  The GCS or UA (e.g.  BVLOS and autonomous operation) provides the
>       UA's RID data to a NET_RID_SP via a secure internet connection.
>
>    *  NET_RID_DP as a NET_RID_SP subscriber and satisfies the Observer's
>       query request also via a secure internet connection."
>
> needs some rewording, which I can do if you wish?
>
> "The mimunum Network RID data flow is illustrated in Figure 2:"
> mis-spells "minimum" as reported in my review of -arch-14.
>
> ==
>
> -arch Section 1.3
>
> "Observers can be providing information about observed UA to a USS."
> is incorrect, there is no such concept in UTM, but if you change
> "USS" -> "Surveillance SDSP" then it would be true.
>
> ASCII art in Figure 3 has some mistakes.
>
> ==
>
> -arch Section 4
>
> Really the only text that needs to be here is that from
> subsections 4.2 and 4.4. Section 4.1 is a redundant restatement
> of information contained in the Requirements document. Section 4.3
> should partly go in Section 4 and partly in Section 5.
>
> ==
>
> -arch Section 4.1
>
> Some old problems have been fixed, others remain, some new ones
> have crept in. If this section is to be retained, here is my
> suggested replacement text.
>
>    A DRIP entity identifier needs to be "trustworthy" (see GEN-1, ID-4
>    and ID-5 in [I-D.ietf-drip-reqs]). This means that given a sufficient
>    collection of RID messages, an Observer can establish that the
> identifier
>    claimed therein uniquely belongs to the claimant: that the only way
>    for any other entity to prove ownership of that identifier would be to
>    obtain information that ought to be available only to the legitimate
>    owner of the identifier (e.g., a cryptographic private key).
>
>    To satisfy DRIP requirements and maintain important security properties,
>    the DRIP identifier should be self-generated by the entity it names
>    (e.g., a UAS) and registered (e.g., with a USS).
>
>    Broadcast RID, especially its support for Bluetooth 4, imposes severe
>    constraints. ASTM [F3411-19] allows a UAS ID of types 1, 2 and 3 of 20
>    bytes; the new type 4, created to enable Session IDs to be standardized
>    by IETF and other SDOs as extensions to ASTM [F3411-19], consumes one
>    of those bytes to index the sub-type, leaving only 19 for the
> identifier.
>    Likewise, the maximum ASTM [F3411-19] Authentication Message payload is
>    201 bytes for most authentication types, but for type 5, created for
>    IETF and other SDOs to develop Specific Authentication Methods as
>    extensions to ASTM [F3411-19], 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.
>
> ==
>
> -arch Sections 4.2 & 4.4
>
> My previously proposed replacement text for 4.4, which should be
> merged into 4.2, is
>
> "HHIT as a Cryptographic Identifier
> The only (known to the authors at the time of this writing) extant
> types of IP address compatible identifiers cryptographically derived
> from the public keys of the identified entities are Cryptographically
> Generated Addresses (CGAs) [RFC3972] and Host Identity Tags (HITs)
> [RFC7401].  CGAs and HITs lack registration/retrieval capability.
> To provide this, each HHIT embeds plaintext information designating
> the hierarchy within which it is registered and a cryptographic hash
> of that information concatenated with the entity's public key, etc.
> Although hash collisions may occur, the registrar can detect them
> and reject registration requests rather than issue credentials, e.g.,
> by enforcing a first-claimed, first-attested policy."
>
> ==
>
> -arch Section 5
>
> This section is considerably improved over the past few revisions.
> I would still like it to be strengthened from merely stating options
> to making specifications that provide guidance to system developers
> and enable interoperability of implementations.
>
> Section 1.4 used to say "This document outlines the UAS RID architecture
> into which DRIP must fit and the architecture for DRIP itself."
>
> We don't actually do that here:
> the entities and interfaces already present in the UAS RID architecture
> into which DRIP must fit are not even listed;
> of those introduced by DRIP, the identifier is justified, but nothing
> is actually specified, much less positioned in an architecture.
>
> To see what I mean, just search the text for architectural keywords,
> such as "interface", that are essential to a usable architecture
> specification, but lacking here.
>
> ==
>
> -arch Section 5.1.2
>
> It is not just that "A DRIP identifier is amenable to handling as an
> Internet domain name..." and "Thus DNS can provide all the needed
> public DRIP information..." A DRIP identifier MUST be registered in
> DNS, or we miss the entire point of DRIP as stated in the charter
> "The working group will primarily leverage Internet standards
> (including HIP, EPP, RDAP, and DNS) and infrastructure as well as
> domain name registration business models". Leveraging proven Internet
> domain name registration and lookup processes is fundamental to DRIP.
>
> ==
>
> missing section
>
> We need a section on the actual authentication protocols or at least
> authentication data formats. Just as 4 introduces HHITs, which are
> detailed in Bob's draft; and 5 introduces registries, which will be
> detailed in Michael's draft; a new section 6 (renumbering subsequent
> sections accordingly) needs to introduce authentication protocols
> (methods and data formats), which are detailed in Adam's draft.
>
> ==
>
> -arch Section 6
>
> "(which may have a natural time lag as it is)"
>
> can be deleted as it is now redundant with the subsequent text
>
> "subject not only to natural time lag"
>
> ==
>
> -arch Section 9
>
> This approach depends upon the UAS being registered with & connected
> during flight to a USS, and the Observer being able to contact
> (directly or indirectly, e.g., via a DSS) that USS, which pretty much
> implies UTM: this should be explicitly noted in the text; see also
> comment above on Section 1.3.
>
> ==
>
> -arch Section 7
>
> "IANA Consideration" -> "IANA Considerations"
>
> ==
>
> -arch Appendix A.2
>
> "UAS's flight plan application and approval process
> for airspace authorization"
> ->
> "UAS operational intent (flight plan) submission
> and application for airspace authorization"
>
> "Notice to Airman" -> "Notice to Airmen"
>
> These 2 changes still need to be made.
>
> ==
>
> I look forward to our discussions tomorrow.
> My proposed slides have not yet appeared in the meeting materials,
> and the agenda has not yet been updated to reflect my addressing Adam's
> items,
> but I assume our chairs will handle that soon,
>
> -- Stu
>
>
> On Mon, Jul 26, 2021 at 2:55 PM shuai zhao <[email-masked]> wrote:
>
>> Hi Stu,
>>
>> Both Bob and I have tried to address all of your comments, editorial or
>> not and I have send out the updated text to the mailing list also
>> implemented in -15.
>>
>> I have closed all of the Github issues with feedback, as well as the
>> comments you sent to the mailing list (20+).
>>
>> I would suggest we have a group call after IETF 111 if you still think
>> there is more to address.
>>
>>
>> Best,
>> Shuai
>>
>>
>> On Jul 26, 2021, at 12:12 PM, Card, Stu <[email-masked]>
>> wrote:
>>
>> Shuai --
>>
>> Thank you for your efforts producing -arch-15.
>>
>> I see that you have addressed some of my concerns.
>>
>> I hope that you can address more of them in the next revision.
>>
>> I have not yet been able to go through the ~200 messages pertaining to
>> -arch since I gave you my review, but will ASAP.
>>
>> -- Stu
>>
>>
>> On Sun, Jul 25, 2021 at 2:30 PM <[email-masked]> wrote:
>>
>>>
>>> A new version of I-D, draft-ietf-drip-arch-15.txt
>>> has been successfully submitted by Shuai Zhao and posted to the
>>> IETF repository.
>>>
>>> Name:           draft-ietf-drip-arch
>>> Revision:       15
>>> Title:          Drone Remote Identification Protocol (DRIP) Architecture
>>> Document date:  2021-07-25
>>> Group:          drip
>>> Pages:          23
>>> URL:
>>> https://www.ietf.org/archive/id/draft-ietf-drip-arch-15.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-15
>>>
>>> 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
>>>
>>>
>>>
>>

-- 
Daniel Migault
Ericsson