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

["Card, Stu" <[e-mail]>]

Thanks Eric!

Yes, as Med says, we will try to do the right thing, right after IETF 110,
but will need some back and forth on a few points, as I am not sure how to
address them.


On Mon, Mar 8, 2021 at 9:20 AM <[e-mail]> wrote:

> Hi Eric,
>
>
>
> Thank you for the review. I trust the authors will do the right thing.
>
>
>
> As a shepherded, please see below two points.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Tm-rid [mailto:[e-mail]] *De la part de* Eric
> Vyncke (evyncke)
> *Envoyé :* lundi 8 mars 2021 14:45
> *À :* [e-mail]
> *Objet :* [Drip] AD review of draft-ietf-drip-reqs-09
>
>
>
> 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.
>
>
>
> [Med] Agree. This is section is maintained on purpose.
>
>
>
> --- 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)
>
> [Med] A pointer to https://tools.ietf.org/html/rfc8576#section-5.9 may be
> sufficient here.
>
>
>
> 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
> --
> Tm-rid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tm-rid
>