Subject: Re: [Drip] IETF DRIP Architecture WGLC, revision 13

From: shuai zhao <[email-masked]>
Date: Sun, 27 Jun 2021 18:13:22 -0700

( Email subject is supposed to be for revision 13, not 12. Corrected)

Hi Stu, see reply inline.  Please look for each of my comment and confirm it. 

Attached the diff, which also includes fix based on comments in GitHub. 

At this moment, All the issues needs confirmation/discussion are listed as open in https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues>

I request Stu, Med and Daniel going to the Github, close or comment back on the issues if my proposal looks fine to you. Lets reduce the issue number and get -14 out based on the solution I currently implemented in -14. We probably need a -15/-16 for the final. 

Best,
Shuai

> On Jun 6, 2021, at 2:44 PM, Card, Stu <[email-masked]> wrote:
> 
> Sorry this thorough review is so late!
> I've been more focused on the ASTM F3411 update for the past few months.
> Fortunately, that is now mostly "in the bag",
> including all we need for DRIP to be a recognized set of extensions.
> :-)
> 
> In the course of reviewing -arch, I had to reference -reqs,
> where I discovered a couple of issues, which I list first below.
> 
> The vast majority of my comments are editorial.
> 
> *** My only major objection, and it is a big fundamental one, is
> to the gutting of all actual architectural specifications, especially
> registries in Section 5. ***
> 
> You may recall my saying in WG presentations that the high level UAS RID
> architecture is already defined external to IETF, so we need to document
> a specific DRIP solution architecture, how it fits into the pre-existing
> high level architecture, and how it provides benefits otherwise lacking.
> 
> As yet, we here have only promised such benefits, not actually defined
> an architecture.
> 
> I do _not_ blame editor Shuai: he only did as he understood direction
> based on others' comments.
> 
> If you do not have time for this whole review, please just consider my
> comments on Sections 4 & 5.
> 
> ====
> 
> -reqs Table 1
> 
> "Section 5.4.5" link is dead:
> no such section exists in -reqs;
> it was meant to refer to that section in F3411
> 
> ==
> 
> -reqs GEN-3 (& elsewhere?)
> 
> UAS ID Type 3 may need to be generalized:
> the F3411 update presumably will introduce Type 4
> 
> ==
> 
> -reqs Section 2.2
> 
> Should SDO, SDSP, etc. be listed in alphabetical order of the acronyms
> rather than their expanions?
> 
> ==
> 
> -reqs Appendix A
> 
> "do not necessary" -> "... necessarily"
> 
> ====
> 
> -arch Abstract
> 
> "DRIP requirements" -> "DRIP Requirements";
> 
> "satisfies" or "can satisfy" or "complies with" or "is consistent with"
> or "supports satisfaction of"? as -arch does not cite specific numbered
> requirements, we cannot be sure it satisfies them

<shuai>
	update ‘r’ to ‘R’
	update to "This architecture adheres to the requirements listed in the DRIP Requirements document
</shuai>
> 
> ==
> 
> -arch Introduction
> 
> "DRIP requirements" -> "DRIP Requirements" when referring to the
> specific document
> 
> "adheres to" language could be used also in Abstract

<shuai>
	updated ‘r’ to ‘R’

</shuai>
> 
> ==
> 
> -arch Section 1.1
> 
> first 2 sentences order should be reversed
> 
> current 1st / to-be 2nd sentence clauses should be reversed
> as RID is primarily for neither UTM nor USS but Observers
> 
> "both 4G and 5G network." -> "... networks."

<shuai>
	both are updated. 
</shuai>
> 
> ==
> 
> -arch section 1.2.1
> 
> "UAS RID as a key" -> "UAS ID..."
> as RID is the process/system not the identifier/identity
> 
> "The Broadcast RID" -> simply "Broadcast RID" (definite article is
> superfluous) or "Broadcast RID data flow" or "The minimal Broadcast RID
> scenario"?
> 
> "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)
> 
<shuai>:
	All updated.
</shuai>

> ==
> 
> -arch Section 1.2.2
> 
> "The Network RID" -> simply "Network RID" (definite article is
> superfluous) or "Network RID data flow" or "The minimal Network RID
> scenario"
> 
> "For all, but the simplest" -> "For all but the simplest" (comma is
> superfluous)
> 
> "subscribed Net-RID DP, typically a USS" drop the "a",
> as here both Net-RID DP and USS are typically plural
> 
<shuai>
	all updated
</shuai>
> ==
> 
> -arch Section 1.3
> 
> "Each UAS is registered to at least one USS" is only true in the
> context of UTM, but: UTM is not yet fully specified, not yet
> operationally deployed, not required for RID, so Figure 3 only applies
> in the context of UTM and/or Network RID
> 
> Figure 3 "UA1"->"UAS1", "UA2"->"UAS2"
> as the path/link to the USS can be from any part of the UAS (UA + GCS)
> 
> Figure 3 "USS-1"->"USS1", "USS-2"->"USS2" for consistency w/numbering
> of UA, UAS, etc.
> 
<shuai>
	all updated. 
</shuai>

> ==
> 
> -arch Sections 2 & 3
> 
> Let's merge these, as we did in -reqs, with the current 2 becoming 2.1.
> 
> The only abbreviations listed here that are not in the glossary in
> -reqs are: EdDSA, HHIT, HIT, HIP, RID (which stand-alone, outside
> "UAS RID", should be used with care); should we add these to the
> glossary in -reqs and delete them here, or leave well enough alone?
> 
> Also, -reqs says
>    [RFC4949] provides a glossary of Internet security terms that should
>    be used where applicable.
> 
>    In the UAS community, the plural form of acronyms generally is the
>    same as the singular form, e.g., Unmanned Aircraft System (singular)
>    and Unmanned Aircraft Systems (plural) are both represented as UAS.
>    On this and other terminological issues, to encourage comprehension
>    necessary for adoption of DRIP by the intended user community, that
>    community's norms are respected herein, and definitions are quoted in
>    cases where they have been found in that community's documents.  Most
>    of the listed terms are from that community (even if specific source
>    documents are not cited); any that are DRIP-specific or invented by
>    the authors of this document are marked "(DRIP)".
> Do we want to repeat this, in whole or in part, here in -arch?

<shuai>
	will merge section 2 and 3.
	new issues listed in GitHub to remind me merging them later: https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/29 <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/29>
	otherwise I am afraid we will lose numbering control for current comments.
</shuai>

> 
> ==
> 
> -arch Section 3.3
> 
> I love such clear and concise definitions!
> Thank you, reviewers, co-authors and editor Shuai,
> for fixing Adam's and my initial rough drafts of them.
> Let's be careful about using these terms accordingly in other DRIP docs.
> ;-)
> 
<shuai>
	:) NTH to update. 
</shuai>
> ==
> 
> -arch Section 4
> 
> "HHIT for DRIP Entity Identifier
> This section describes the basic requirements of a DRIP entity
> identifier per regulation constrains from ASTM [F3411-19] and
> explains the use of Hierarchical Host Identity Tags (HHITs) as self-
> asserting IPv6 addresses and thereby a trustable DRIP identifier for
> use as the UAS Remote ID.  HHITs self-attest to the included explicit
> hierarchy that provides Registrar discovery for 3rd-party ID
> attestation."
> ->
> "HHIT as the Primary DRIP Entity Identifier
> This section describes the DRIP architectural approach to meeting
> the basic requirements of a DRIP entity identifier within external
> technical standard ASTM [F3411-19] and regulatory constraints. It
> justifies and explains the use of Hierarchical Host Identity Tags
> (HHITs) as self-asserting IPv6 addresses suitable as a UAS ID type
> and more generally as trustworthy multipurpose remote identifiers.
> A HHIT, together with the Host Identity (HI) from which it is partly
> derived, self-attests to its included explicit registration hierarchy,
> providing Registrar discovery for 3rd-party attestation of identity
> and lookup of related information.”
> 

<shuai>
	All updated
</shuai>

> ==
> 
> -arch Section 4.1
> 
> This section does 2 things: recapitulate some of what is in -reqs;
> and begin to introduce/justify HHITs. I would be much happier if it
> cited -reqs generally for the motivation, then one by one went through
> its specific numbered requirements and showed how HHITs, together with
> private and public registries (inc. DNS) satisfy them.
> 

<shuai>
	I will a GitHub issue https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/30 <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/30> 
	will address it later
</shuai>

> ==
> 
> -arch Section 4.2
> 
> good, but should be merged with Section 4.4

<shuai>
	Just to clarify that you would to merge all text from Section 4.4 and remove the original 4.4, right? 
	I have no issue with that. Since those text is really trying to explain how HHIT handle crypto for a DRIP ID. 
</shuai>

> 
> ==
> 
> -arch Section 4.3
> 
> This is the closest we come, in this nominally Architecture document,
> to actually specifying an architecture, so to that extent it is good.
> However, even here, the focus is entirely on the HHIT (none of the
> other entities or their interfaces), and the language is always "can"
> rather than "must", "should", "may", "shall", "will", "does" or "is".
> 

<shuai>
	Med has some comments for section 4.3 which suggests to integrate some text to 4.2. I have proposed the changes in https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/27 <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/27>. Please comment on the GitHub. 

The newly proposed text is always “can” now in GitHub. 

</shuai>

> ==
> 
> -arch Section 4.4
> 
> should be merged wih Section 4.2
> 
> "HHIT for DRIP Identifier Cryptographic
> The only (known to the authors of this document at the time of its
> writing) extant fixed-length ID cryptographically derived from a
> public key are the Host Identity Tag [RFC7401], HITs, and
> Cryptographically Generated Addresses [RFC3972], CGAs.  However, both
> HITs and CGAs lack registration/retrieval capability.  HHIT, on the
> other hand, is capable of providing a cryptographic hashing function,
> along with a registration process to mitigate the probability of a
> hash collision (first registered, first allowed)."
> ->
> "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."
> 

<shuai>
	This will be updated once you have confirmed your previous comments in section 4.2. 
	I have created a issue in GitHub to track it. https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/31 <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/31>
	once you have confirmed, I will then update. 
</shuai>

> ==
> 
> -arch Section 5
> 
> I disagree strongly with removal of definitive specifications here.
> 
> It is not just that "UAS registries can hold both public and private UAS
> information resulting from the DRIP identifier registration process";
> they MUST hold such information, or they aren't registries at all, and
> don't satisfy regulator or F3411 UAS RID, much less DRIP, requirements!
> 
> It is not just that "A DRIP identifier is amenable to handling as an
> Internet domain name..." and "can be registered in at least a
> pseudo-domain"; it MUST be so registered, 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" and
> restated in -arch Section 1.4 "DRIP is meant to leverage existing
> Internet resources (standard protocols, services, infrastructures, and
> business models) to meet UAS RID and closely related needs. DRIP will
> specify how to apply IETF standards, complementing [F3411-19] and other
> external standards, to satisfy UAS RID requirements. 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".
> 
> I will not comment specifically on the details of the text in Section 5,
> as I fundamentally disagree with not actually specifying an architecture
> in the DRIP Architecture document. I am happy to support alternatives
> to DNS, EPP, RDAP, etc. _in addition_ to those protocols (indeed, I am
> fond of blockchain based approaches), but leveraging proven Internet
> domain name registration and lookup processes is fundamental to DRIP.
> 
> ==

<shuai>
	this is a larger issue. We shall discuss this in the WG. 
	a issue tracker in https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/32 <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/32>

</shuai>

> 
> -arch Section 6
> 
> "FAA RID Final Rules only specifies" -> "... only specify"
> 
> "(which may have a natural time lag as it is),
> which are entirely operator self-reported in UAS RID and UTM."
> ->
> "which are entirely operator self-reported in UAS RID and UTM,
> and thus are subject not only to natural time lag and error
> but also operator misconfiguration or intentional deception."
> 
> insert reference citations
> 

<shuai>
	All updated
</shuai>

> ==
> 
> -arch Section 6.1
> 
> "it can not interface directly with"
> ->
> "it should not depend upon a direct interface with"
> 
> "needs to be" -> "should be"
> 

<shuai>
	All updated
</shuai>

> ==
> 
> -arch Section 6.2
> 
> replace with:
> "A CS-RID SDSP would present a TBD interface to a CS-RID Finder;
> this interface should be based upon but readily distinguishable from
> that between a GCS and a Net-RID SP. A CS-RID SDSP should appear
> (i.e. present the same interface) to a Net-RID SP as a Net-RID DP."
> 

<shuai>
	All updated
</shuai>

> ==
> 
> -arch Section 7
> 
> 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.
> 
> Given the current immaturity of UTM relative to UAS RID, the mood of
> Section 7, where it appears we are not actually specifying the exclusive
> DRIP architecture for "Privacy for Broadcast PII" but just laying out
> one possible approach, and moving it to a "considerations" section, both
> seem appropriate.
> 
> "symmetric encryption of the PII using a
> key known to the UAS and its USS"
> ->
> "symmetric encryption of the PII using a
> session key known to the UAS and its USS"
> to confine the scope of decryption
> (see comment after next below)
> 
> "(to entities such as USS of the Observer,
> or to the UAS in which the UAS ID is registered
> or to a Public Safety USS)"
> ->
> ("to the USS in which the UAS ID is registered if that can be
> determined, e.g., from received Broadcast RID information
> such as the UAS ID itself, or to the Observer's USS,
> or to a Public Safety USS)"
> 
> "directly decrypt all future PII content from the UA"
> ->
> "directly decrypt all PII content sent by that UA
> during that session (UAS operation)"
> 
> "from operational instructions to even permit flying in a space/time"
> ->
> "as part of UTM operation authorization"
> 
> last 2 sentences order should be reversed
> 
> 

<shuai>
	Text are updated. 
</shuai>

> ==
> 
> -arch Sections 7 & 8
> 
> Let's insert IANA Considerations (null?) as Section 7,
> leave Security Considerations as Section 8, rename
> "Privacy for Broadcast PII" -> "Privacy & Transparency Considerations"
> and move it to Section 9 (incrementing subsequent section numbers
> accordingly), to make it parallel -reqs for ease of cross-reference
> 

<shuai>
	Currently I did the following update:
	- add section 7 “IANA consideration”
	- add section 9 “Privacy & Transparency Considerations”

I create a issue tracer to see if ppl likes this or not. 
</shuai>

> ==
> 
> -arch Section 9 Acknowledgements
> 
> RFC 7322 places Acknowedgements after Appendices and before Authors
> 

<shuai>
	 updated per requests. 
</shuai>

> ==
> 
> -arch Section 10 References
> 
> [TS-22.825] "UAS RID requirement study" ->
> "Study on Remote Identification of Unmanned Aerial Systems (UAS)"
> 
> all should be checked for accuracy & accessibility
> 

<shuai>
	update the proposed one for now.
	A new issue tracker in https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/34 <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/34> to remind me to do the rest. 
</shuai>

> ==
> 
> -arch Appendix A
> 
> glitch in formatting of title: partially but not entirely bold
> 

<shuai>
	how do you mean?
</shuai>

> ==
> 
> -arch Appendix A.1
> 
> "FAAs'" -> "FAA's"
> 
> "leads to the development" -> "led to the development"
> 
> "is published in 2020" -> "was published in 2020"
> 
> "development and implementation
> are conducted by the UTM research transition team"
> ->
> "concept refinement, initial prototype implementation and testing
> were conducted by the UTM research transition team"
> 
> "make sure safe" -> "ensure safe"
> 
> "UTM composes of" -> "UTM comprises"
> 
> "UAS's safe" -> "safe UAS"
> 

<shuai>
	all Updated
</shuai>

> ==
> 
> -arch Appendix A.2
> 
> "monitor and planning" -> "monitoring and planning"
> 
> "USS(s)" -> "USS" (plural acronym same as singular)
> 
> "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"
> 

<shuai>
	all updated, expect the USSs. F3411-19 does use “USSs” for multiple USS. 
	Med also has a comments about this in GitHub https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/12 <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/12>. 
	At this moment, I would suggest lets use USSs if there are more than one….agreeable? 
</shuai>

> ==
> 
> -arch Appendix A.3
> 
> "takeoff or land" -> "taking off or landing"
> 
> "United States" -> "the United States"
> 
> "USS where UAS is currently communicating with"
> ->
> "USS under which the UAS is operating"
> 
> "for UAS's registration"
> ->
> "for verifying UA registration"
> 
> "UAS's fly plan" -> "UAS operational intent (flight plan)"
> 
> "UAS fly path" -> "UA flight path"
> 
> "safe boundary" -> "safe margins"
> 
> "pre-authorized route"
> ->
> "pre-authorized sequence of authorized 4-D volumes (route)"
> 
> 
> "and take off or land" -> "and taking off or landing"
> 
> "pre-fly" -> "pre-flight"
> 
> "(BVLOS) operation" -> "(BVLOS)"
> 
> "received intended fly plan"
> ->
> "received operational intent (flight plan)"
> 
> "current fly data" -> "current flight data"
> 
> "traffic monitor" -> "traffic monitoring"
> 

<shuai>
	all updated
</shuai>

> ==
> 
> -arch Appendix A.4 should be Appendix B as ADS-B is not part of UTM
> 

<shuai>
	all updated
</shuai>

> ==
> 
> On Sat, Jun 5, 2021 at 9:00 PM Daniel Migault <[email-masked] <mailto:[email-masked]>> wrote:
> Hi, 
> 
> I tend to think the same, I will provide my comments as issues in github, so we can track them. 
> 
> Yours, 
> Daniel
> 
> On Sat, Jun 5, 2021 at 6:45 PM Card, Stu <[email-masked] <mailto:[email-masked]>> wrote:
> We definitely need a -14 before taking it to IESG.
> I have many small editorial changes & one major issue.
> I have one section left to review so will send you my comments tomorrow.
> 
> 
> On Fri, Jun 4, 2021 at 12:42 PM Stuart W. Card <[email-masked] <mailto:[email-masked]>> wrote:
> I will carefully review -13 between now and Sunday evening. Thanks!
> 
> On 6/4/2021 10:43 AM, Robert Moskowitz wrote:
> > I had reviewed -13 and was satisfied with this draft.
> > 
> > Stu?
> > 
> > On 6/4/21 9:46 AM, Daniel Migault wrote:
> >> Hi,
> >>
> >> I am planning to review the arch doc to move it to the IESG. Just want 
> >> to check that -13 has all the changes or if I should wait for a -14 ?
> >>
> >> Yours,
> >> Daniel
> >>
> >> On Mon, May 10, 2021 at 11:52 AM Robert Moskowitz <[email-masked] <mailto:[email-masked]> 
> >> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >>
> >>     I am going to have to think about Stu's comments before I recommend
> >>     changed text.
> >>
> >>     Shaui, if you have everything else complete before I comment, push it
> >>     out and any changes will go into a -13.  :)
> >>
> >>     Bob
> >>
> >>     On 5/10/21 10:33 AM, Card, Stu wrote:
> >>     > Thread is getting long so I am cutting & pasting only the parts to
> >>     > which I am responding.
> >>     >
> >>     >
> >>     > [rgm] "Typically a USS"  Other than what?
> >>     >
> >>     > [swc] A Net-RID SP is not required by F3411 to be a USS; in the FAA
> >>     > NPRM, it was, but then Net-RID was not in the "final" FAA rule. A
> >>     > Net-RID DP is not required by F3411 to be a USS; in the FAA
> >>     NPRM, it
> >>     > was not even recognized as a distinct entity. There is nothing
> >>     > stopping anyone from building a Net-RID DP that is not a USS (i.e.,
> >>     > does not offer all the services that a USS must offer to be
> >>     so-called).
> >>     >
> >>     >
> >>     > [F3411-19] prescribes the protocols only between the Net-RID SP,
> >>     > Net-RID DP, and the Discovery and Synchronization Service (DSS).
> >>     >
> >>     > [rgm] Is this right?  It at least is missing the JSON from Observer
> >>     > to/from Net-RID DP.  I really don't think it has the DSS well
> >>     defined,
> >>     > that follows the NASA paper, but not in F3411?
> >>     >
> >>     > [swc] F3411 prescribes the _protocols_ only SP to DP, aided by the
> >>     > DSS. It prescribes the _data dictionary_ end to end (UAS to
> >>     Observer).
> >>     > Re: DSS definition, ASTM groups standardizing RID and UTM each
> >>     tend to
> >>     > assume the other's stuff is available and standardized according to
> >>     > assumed consensus CONOPS/architecture. ;-) The idea is that DSS
> >>     helps
> >>     > USS find each other when necessary, esp. when one has an
> >>     "operational
> >>     > intent" in a 4-D volume overlapping that of another's approved
> >>     > "operation", and does as little beyond that as possible. I agree
> >>     that
> >>     > the incompletely thought out DSS presents some gaps and a serious
> >>     > flaw: if one USS tells the DSS that it has an operation in a 4-D
> >>     > volume, then goes unresponsive, no other USS can approve any
> >>     further
> >>     > operations in any 4-D volumes that overlap with it, as no dialog
> >>     > between the two involved USS is possible; when you realize that
> >>     some
> >>     > USS are likely to be nationwide and have operations in many high
> >>     > traffic volumes, this could bring UTM to a screeching halt. That,
> >>     > however, is not a UAS RID, but rather a UTM, problem, so not in
> >>     DRIP
> >>     > scope [yet].
> >>     >
> >>
> >>
> >>
> >> -- 
> >> Daniel Migault
> >> Ericsson
> > 
> 
> 
> -- 
> -----------------------------------------
> Stuart W. Card, PhD, Principal Engineer
> AX Enterprize, LLC  www.axenterprize.com <http://www.axenterprize.com/>
> 4947 Commercial Drive, Yorkville NY 13495
> 
> 
> -- 
> Daniel Migault
> Ericsson

---

From: "Stuart W. Card" <[email-masked]>
Date: Mon, 28 Jun 2021 10:12:57 -0400

Med -- I just accepted the Github invitation, thanks.

Shuai -- It will take me a day or two to get through your suggested 
fixes for all my comments/issues, thanks.

On 6/27/2021 9:13 PM, shuai zhao wrote:
> At this moment, All the issues needs confirmation/discussion are listed 
> as open in https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues 
> <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues>
> 
> I request Stu, Med and Daniel going to the Github, close or comment back 
> on the issues if my proposal looks fine to you. Lets reduce the issue 
> number and get -14 out based on the solution I currently implemented in 
> -14. We probably need a -15/-16 for the final.
> 
> Best,
> Shuai
> 
> 
> 
> 
> 
>> On Jun 6, 2021, at 2:44 PM, Card, Stu <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
> update to "This architectureadheres tothe requirements listed in the 
> DRIP Requirements document
> </shuai>
>>
>> ==
>>
>> -arch Introduction
>>
> new issues listed in GitHub to remind me merging them later: 
> https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/29 
> <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/29>
> I will a GitHub issue 
> https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/30 
> <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/30>
> will address it later
> </shuai>
> 
>> ==
>>
>> -arch Section 4.2
>>
> Med has some comments for section 4.3 which suggests to integrate some 
> text to 4.2. I have proposed the changes in 
> https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/27 
> <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/27>. Please 
> comment on the GitHub.
> 
> I have created a issue in GitHub to track it. 
> https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/31 
> <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/31>
> a issue tracker in 
> https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/32 
> <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/32>
> 
> </shuai>
> 
>>
>> -arch Section 6
>>
> A new issue tracker in 
> https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/34 
> <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/34> to 
> remind me to do the rest.
> </shuai>
> 
>> ==
>>
>> -arch Appendix A
>>
> Med also has a comments about this in GitHub 
> https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/12 
> <https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/12>.
>>     On Sat, Jun 5, 2021 at 6:45 PM Card, Stu
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         On Fri, Jun 4, 2021 at 12:42 PM Stuart W. Card
>>         <[email-masked] <mailto:[email-masked]>>
>>         wrote:
>>
>>             >> On Mon, May 10, 2021 at 11:52 AM Robert Moskowitz
>>             <[email-masked] <mailto:[email-masked]>
>>             >>     > Thread is getting long so I am cutting & pasting
>>             only the parts to
>>             >>     > which I am responding.
>>             >>     >
>>             >>     >
>>             >>     > [rgm] "Typically a USS"  Other than what?
>>             >>     >
>>             >>     > [swc] A Net-RID SP is not required by F3411 to be
>>             a USS; in the FAA
>>             >>     > NPRM, it was, but then Net-RID was not in the
>>             "final" FAA rule. A
>>             >>     > Net-RID DP is not required by F3411 to be a USS;
>>             in the FAA
>>             >>     NPRM, it
>>             >>     > was not even recognized as a distinct entity.
>>             There is nothing
>>             >>     > stopping anyone from building a Net-RID DP that
>>             is not a USS (i.e.,
>>             >>     > does not offer all the services that a USS must
>>             offer to be
>>             >>     so-called).
>>             >>     >
>>             >>     >
>>             >>     > [F3411-19] prescribes the protocols only between
>>             the Net-RID SP,
>>             >>     > Net-RID DP, and the Discovery and Synchronization
>>             Service (DSS).
>>             >>     >
>>             >>     > [rgm] Is this right?  It at least is missing the
>>             JSON from Observer
>>             >>     > to/from Net-RID DP.  I really don't think it has
>>             the DSS well
>>             >>     defined,
>>             >>     > that follows the NASA paper, but not in F3411?
>>             >>     >
>>             >>     > [swc] F3411 prescribes the _protocols_ only SP to
>>             DP, aided by the
>>             >>     > DSS. It prescribes the _data dictionary_ end to
>>             end (UAS to
>>             >>     Observer).
>>             >>     > Re: DSS definition, ASTM groups standardizing RID
>>             and UTM each
>>             >>     tend to
>>             >>     > assume the other's stuff is available and
>>             standardized according to
>>             >>     > assumed consensus CONOPS/architecture. ;-) The
>>             idea is that DSS
>>             >>     helps
>>             >>     > USS find each other when necessary, esp. when one
>>             has an
>>             >>     "operational
>>             >>     > intent" in a 4-D volume overlapping that of
>>             another's approved
>>             >>     > "operation", and does as little beyond that as
>>             possible. I agree
>>             >>     that
>>             >>     > the incompletely thought out DSS presents some
>>             gaps and a serious
>>             >>     > flaw: if one USS tells the DSS that it has an
>>             operation in a 4-D
>>             >>     > volume, then goes unresponsive, no other USS can
>>             approve any
>>             >>     further
>>             >>     > operations in any 4-D volumes that overlap with
>>             it, as no dialog
>>             >>     > between the two involved USS is possible; when
>>             you realize that
>>             >>     some
>>             >>     > USS are likely to be nationwide and have
>>             operations in many high
>>             >>     > traffic volumes, this could bring UTM to a
>>             screeching halt. That,
>>             >>     > however, is not a UAS RID, but rather a UTM,
>>             problem, so not in
>>             >>     DRIP
>>             >>     > scope [yet].
>>             >>     >
>>             >>
>>             >>
>>             >>
>>             >> --
>>             >> Daniel Migault
>>             >> Ericsson
>>             >
>>
>>
>>             -- 

-- 
-----------------------------------------
Stuart W. Card, PhD, Principal Engineer
AX Enterprize, LLC  www.axenterprize.com
4947 Commercial Drive, Yorkville NY 13495

---

From: "Card, Stu" <[email-masked]>
Date: Tue, 29 Jun 2021 17:51:21 -0400

Thanks very much Shuai!
I have accepted Med's invitation to Github, reviewed all the open issues
there, commented on many of them.
Please find attached a file with my original review, updated based on your
work and citing the Github issues.
I have trimmed this email and responded in-line to just a few.

On Sun, Jun 27, 2021 at 9:13 PM shuai zhao <[email-masked]> wrote:

> ...
> Hi Stu, see reply inline.  Please look for each of my comment and confirm
> it...
> https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues close or
> comment back on the issues...
>
> -arch Section 4.2
Right.

> -arch Section 5
>
> I disagree strongly with removal of definitive specifications here...
> leveraging proven Internet domain name registration and lookup processes
> is fundamental to DRIP.
>
> </shuai> this is a larger issue. We shall discuss this in the WG.
> a issue tracker in
Indeed!

> -arch Appendix A.2...
> https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/12.
I did not find any of these updated except the first one. Generally I find
more instances of USS being used as the plural than USSs, and standard
English appends "es" (not "s") to pluralize words ending in "s", but this
is not important to me; making this a real architecture specification is.

---

From: <[email-masked]>
Date: Wed, 30 Jun 2021 06:21:36 +0000

Hi Stu, all,

Focusing on the one below.

Cheers,
Med

De : Card, Stu [mailto:[email-masked]]
Envoyé : mardi 29 juin 2021 23:51
À : shuai zhao <[email-masked]>
Cc : Daniel Migault <[email-masked]>; BOUCADAIR Mohamed INNOV/NET <[email-masked]>; shuaiizhao(Shuai Zhao) <[email-masked]>; [email-masked]
Objet : Re: IETF DRIP Architecture WGLC, revision 13

<shuai>
all updated, expect the USSs. F3411-19 does use “USSs” for multiple USS.
Med also has a comments about this in GitHub https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/12.

[Med] This was a comment from Daniel :-)

At this moment, I would suggest lets use USSs if there are more than one….agreeable?
</shuai>
I did not find any of these updated except the first one. Generally I find more instances of USS being used as the plural than USSs, and standard English appends "es" (not "s") to pluralize words ending in "s", but this is not important to me; making this a real architecture specification is.

[Med] Agree with Stu on architectural part. For the terminology, we used to have this discussion in the past and the agreement is what we recorded in draft-ietf-drip-reqs:

Let’s be consistent with what we agreed. Thank you.

_________________________________________________________________________________________________________________________

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.