[Drip] AD review of draft-ietf-drip-reqs-09

["Eric Vyncke (evyncke)" <[e-mail]>]

As usual when a WG requests the publication of a draft, I do my own AD review before proceeding.



First of all, thank you to the authors and the WG for the text that has been developed in 18 months or so (draft-card-tmrid-uas-00 is dated Nov 2019), a record !



Except when noted, a reply or a revised I-D should address the review comments below. The amount of points below is not about the quality of the document itself but more about my interest in this one :-)



The section 1-3 (esp. "problem space") are not really related to the topic of this document, which is about 'requirements'. They would better fit in the architecture document IMHO but we already discussed about this issue over the mailing list.



--- Abstract ---



Can be ignored by the authors but in “security, safety, and other purposes", the "other purposes" is rather vague...



-- Section 1.1 --



Can be ignored but "they can quickly close (500 meters in under 17 seconds at 60 knots);" may be cryptic with the use of "close" and "knots". For the latter, use km/h or mph ?



Unsure whether the paragraph starting with "Diverse other applications can be enabled or facilitated by RID." Has any added value. Consider removing it.



Please expand "Wi-Fi NAN"



The paragraphs with all the long reference is pretty heavy and dry and I am afraid that the actual information in those paragraphs could be lost by the reader. Unsure how to fix the issue though (perhaps repeating in a summary all those references ?).



A terminology section could also help if placed at the beginning.



"The data will be sent in plain text and the UAS operator registration

   number will be represented as a 16-byte string including the state

   code.  The private id part will contain 3 characters which are not

   broadcast but used by authorities to access regional registration

   databases for verification."



Unsure what the 'state' is in the above... Is a status ? a US state ? If a status, then how can it be included in a registration number? If a US state, then what about non-US countries ?

There is also an ambiguity between 'not broadcast' in the list of 'will broadcast locally' ;-)



" it is not addressed in any of the subsequent  regulations or technical specifications." Specifications from whom ?



Where is the difference between safety/security oriented RID defined ?



-- Section 1.2 --



The concept of 'Ground Control Station' should be introduced (possibly earlier in the document).



"by a software process on the GCS" as everything is in SW, what about adding 'transparent and automated' or something in the same vein ?



"dead reckoning" as a private pilot I understand but what about the 'normal' reader ? better to remove those 2 words or add ',i.e.,' after them ?



In " error in but also of intentional falsification of this data", I wonder about the usefulness of the commas.



A key sentence "Broadcast RID uses one-way data links" is lost is in the middle of a long paragraph.



-- Section 1.3 --

Thank you for repeating the DRIP WG charter. You may want to replace 'goal' by 'charter' in the 1st paragraph



Suggest to remove the old name TM-RID



-- Section 1.4 --

Is there a need for the Oxford comma in "privacy and  Transparency" ?



s/Internet based approach/Internet-based approach/ ?



-- Terminology section 2.2 --



This section comes a little late (after the critical section 1) for such a 'unusual' domain, it is probably very useful to have a single place where many concepts/terms are defined BEFORE the section 1.



"community's norms are respected herein" but in IETF documents, the custom is to use IETF wording/vocabulary/conventions. I do not mind too much but we may expect some pushbacks on this.



The 400 ft  in LAANC, isn't it US specific ?



Should "Net-RID" also be defined ? Some other places use "network RID", is it the same concept ?



'PII' is mainly a US concept, how is it related to the EU GDPR ? (and of course other countries similar definitions)



I wonder whether the different messages should be in this section as they are described later (I guess) or should be grouped together ?



"Although called "UAS ID", unique to the UA," I wonder whether the first comma is sensible.



For UTM, is it 'that' or 'which' in "management which manages UAS operations safely" ?



-- Section 3 --

CAA was already expanded, no need to expand it again ;-)



Unsure whether " (or other Wide Area Network)" is useful here... Or do you mean IP connectivity ?



"UAS Identifier  (UAS ID) as a key.", suggest to use a different word than 'key' (which could mean encryption key), e.g., identifier ?



The expansion " Neighbor Awareness Networking" comes a little late in the document ;-)



"specifies three UAS ID types" is it 'ID' or 'RID' or 'identification'  ?



-- Section 3.1 --



"There must be some information flow path (direct

   or indirect) between the GCS and the UA, for the former to exercise

   C2 over the latter."



Is a little too complex for my personal taste, what about "... to control the UA" ?



Figure 3 uses "_" while text uses "-"



" (and other middle layer protocols)" what is this 'middle layer' ? Is it an application-layer protocol ?



" publish-subscribe-query" looks like an oxymoron to me what about " publish-subscribe system" ?



Bullet 2 " Network RID Service Provider (Net-RID SP)" as the term has already been defined, no need for expansion anymore.



s/ via unspecified (generally presumed to be web  browser based) means/via means that are out of scope of this document/ ?



Suggest to use bullet points for " Network RID has several variants."



Humm " this could be the pilot" pilot or operator ?



Consider removing " Long Term Evolution (LTE)" as it brings little value



Later "feeds a Network RID Service Provider (Net-RID SP," is again explained while it was defined before ;-)



-- section 3.2 --



Figure 4, suggest to add the operator (even if doing nothing in this case) to be consistent with figure 3.



" other middle layer protocols" is also unclear



s/ web based verifier/ web-based verifier/



" Neighbor Awareness Networking" has been expanded before, no need to redo it



API has already been expanded and this is a well-known term, hence, not even a need to expand it. See also https://www.rfc-editor.org/materials/abbrev.expansion.txt



s/ within the 25 byte limit/ within the 25-octet limit/. I.e., do not use ambiguous 'byte' but rather use 'octet'



Some explanations may be required about <("paging")> (either in this section or in the terminology section ?)



" on the basis of MAC address" just beware that IEEE 802.11ag/ah (if not mistaken) starts to randomize MAC addresses...



" see  Message Pack below", "below" is rather vague, can you point to a section or a table ?



s/ 4 bit message type field/ 4-bit  message type field/



in " To satisfy EASA and FAA rules, all types are needed" is it 'needed' or 'mandatory' ?



Table 1, is 'message pack' mandatory or optional ?



" far too short for conventional certificates" while I am unsure what is a 'conventional' certificate, could the cert be fetch off-line ?



-- Section 4.1 --



GEN-4: 'readability' is rather vague... is it about clear text vs. cipher text ? is about structure/format ?



GEN-6: should the communications also be authenticated ?



GEN-7: unsure whether the message frequency is really about QoS (suggest to find an alternative to QoS)



GEN-8: what is meant by mobility ? Geographic move ? or change of IP connectivity ? (switching cellular providers)



The last two § would gain of having either a bullet list format or one § per requirement (and also grouped in a sub-section 'rationale')



-- Section 4.2 --



ID-4: isn't uniqueness implicit for an ID ?



ID-5: I wonder whether 'non-spoofable' is an ID property or an authentication property... So, moving ID-5 to another requirements section



ID-6: isn't it more about 'privacy' than 'identifier' ?



Add references to HIP & DTLS ?



-- Section 4.3 --



PRIV-2: is the crypto disabling total or only for partial data ?



-- Section 4.4 --



REG-4: are those policies machine or human readable ?



-- Section 6 --



On this International Women Day,  some will suggest to replace ' Man In The Middle' by 'on path attacker' 😉



-- Appendix A --



Should a reference to " OpenSky and Flightradar" be added ? BTW, I believe you meant 'FlightAware' and not "FlightRadar' BTW2 my own raspeberry PI is part of those community ;-)



" It transmits a four-digit squawk code" should be qualified as four octal digits.



The I-D does not discuss the 24-bit ICAO identifier in mode-S transponder. For sake of completeness, please mention it.



Please make a separate § for CPLDC



It is not "LORA" but "LoraWAN" AFAIK





Hope this helps



-éric