Subject: [Drip] draft-ietf-drip-reqs-10 changes & editor's responses to AD review of -9

From: "Card, Stu" <[email-masked]>
Date: Wed, 28 Apr 2021 16:07:18 -0400

all --

Please review drip-reqs-10, which has many changes triggered by AD Eric's
review, and my responses (in some cases rebuttals) to his comments below.
The draft is now more complete in its treatment of concerns and
constraints, and more comprehensible by IETFers unfamiliar w/aviation and
its SDOs thanks to more background info. It will need another edit once we
have come to consensus on these points, especially the numbered
requirements, which I did not want to touch until we were all satisfied
with the text that motivates/constrains them.

==

Andrei --

Please address Eric's 1st comment on Appendix A and check my attempt at
addressing his 3rd comment on Appendix A.

==

Eric --

I have made a serious effort at addressing your comments on all but the
numbered requirements: I'd like to come to closure on the former before
attempting to address the latter; I hope we can do both quickly.

In most cases, I made changes that I hope will satisfy your concerns. In
others, I attempted rebuttals: please consider my responses; then let me
know on which comments you still want further changes. Our dialog follows
in-line.

==

Comments are from Eric, except where noted as being a response from Med or
Stu. This email contains a few corrections to what I sent to a few of you
at 02:30. ;-)

==

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...

[Stu] inserted "(e.g., initiation of identity based network sessions
supporting UAS applications)"

-- 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 ?

[Stu] rewrote as "(500 meters in under 13 seconds by the fastest consumer
mass market drones available in early 2021)"

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

[Stu] completely rewrote paragraph to actually make its intended point

Please expand "Wi-Fi NAN"

[Stu] expanded and corrected to "Wi-Fi Neighbor Awareness Networking (NAN,
also known as Wi-Fi Aware) and/or IEEE 802.11 Beacon modes"

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 ?).

[Stu] I am guessing that the several consecutive paragraphs with references
to multiple EU documents are the worst. Fortunately, these are all just
informative references, cited as context under "Motivation and External
Influences", rather than anything that the reader must grok.

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

[Stu] As seems to be common practice, I put it immediately after the
"Requirements Language" section required by RFC 7322. At 7 pages, the
definitions section is longer than any currently before it, and is even
more dry; I fear losing readers if we subject them to that before even
motivating the problem. I put a forward reference to the terminology
section at the beginning of the introduction.

"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 ?

[Stu] The context "<xref target="ASDRI" format="default"/> contemplated"
has been inserted, and the clarification "(European) state".

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

[Stu] inserted the one word "corresponding" to yield "The corresponding
private ID part will contain 3 characters which are not broadcast..." to
clarify that the "private ID part" is not actually in the list of "will
broadcast locally", but an external item that relates to a data element in
the list.

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

[Stu] clarified as "the subsequent regulations or international SDO
technical specifications, other than DRIP, known to the authors as of early
2021."

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

[Stu] Each SDO has its own cultural context for this distinction. I have
added ICAO's definitions to the terminology section.

-- Section 1.2 --

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

[Stu] inserted brief parenthetical explanation

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

[Stu] done

"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
?

[Stu] quoted the term and inserted brief explanation in context

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

[Stu] removed those commas

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

[Stu] entire section reorganized for clarity and flow; also the one-way
nature of Broadcast RID is stated 4 more times after this in the document

-- Section 1.3 --

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

[Stu] done

Suggest to remove the old name TM-RID

[Stu] that is our WG's IETF mailing list address, and the "fingerprint" of
Adam's, Bob's and my funding source to do this work, so I'd really rather
not lose it

-- Section 1.4 --

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

[Stu] inserted

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

[Stu] done

-- 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.

[Stu] see response to previous terminology section comment above

"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.

[Stu] understood; we need _adoption_ of DRIP, not only by IETF, but also by
the aviation community

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

[Stu] yes, that this is US only now further emphasized by citing FAA as the
authority

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

[Stu] "Net-RID" is used only as an abbreviation in the defined labels
"Net-RID SP" (Network RID Service Provider) and "Net-RID DP" (Network RID
Display Provider)

'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.

[Stu] clarified definition of PII and cited GDPR

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

[Stu] there is a table of messages, but this is the only place in this
document where all ASTM RID messages are described in prose with important
details; there are other groups of related definitions that could also be
grouped, but alphabetical organization is understand by all

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

[Stu] clarified

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

[Stu] could put in a "sic" if you wish to flag the arguable grammatical
error, but can't change it, as it is an attributed direct quotation

-- Section 3 --

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

[Stu] collapsed

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

[Stu] unsure how to more clearly and concisely say "connectivity other than
the direct Broadcast RID data link, which might be Internet, or not
Internet but still IP, or not even IP, but likely to be multi-hop, to reach
a registry or cache of registry data"

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

[Stu] rephrased as "the primary unique key for database lookup"

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

[Stu] expanded earlier in response to previous Wi-Fi NaN comment above

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

[Stu] the F3411 Common Data Dictionary names are "UAS ID" and "UAS ID
Type", reflected in our draft terminology definitions; but this list and
subsequent text needed to be more consistent in usage, which I have
attempted, thanks for catching it

-- 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" ?

[Stu] that wouldn't be technically correct when UA are operating
autonomously, as they are then commanded rather than controlled; more
important, the UAS community calls this the "C2 link", even when it is not
actually a data link, but rather something else such as a transport
connection

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

[Stu] corrected figure to agree with F3411-derived draft text, thanks,
sharp eyes!

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

[Stu] implied but not fully specified in F3411 or regulations; revised as
"(and other middle layer protocols, e.g., TLS/TCP or DTLS/UDP)"

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

[Stu] it is not a pure pub-sub system, but a pub-sub-query system

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

[Stu] this is the first use in the text, other than the definition itself

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

[Stu] changed to "(via means unspecified by [F3411] etc., but generally
presumed to be web browser based)."

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

[Stu] done, and the opportunity used to explain the different scenarios at
slightly greater length

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

[Stu] revised as "the pilot or other agent of the operator"

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

[Stu] done

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

[Stu] collapsed

-- section 3.2 --

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

[Stu] to be consistent, we would need to add more than the operator, but
the point of this figure is to show explicitly that only these two actors
and one data link are involved

"other middle layer protocols" is also unclear

[Stu] simplified to "(without IP)" as w/o IP presumably no one should
expect to run UDP etc.

s/ web based verifier/ web-based verifier/

[Stu] expanded with the full F3411 term "web-based Broadcast Authentication
Verifier Service"

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

[Stu] collapsed on all but first use; IEEE 802.11 Beacon and Bluetooth 4 vs
5 also updated

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

[Stu] collapsed, and thanks for the pointer

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

[Stu] taking my cue from RFC 8949, added entry to terminology section
'byte: Used here in its now-customary sense as a synonym for "octet" as
"byte" is used exclusively in definitions of data structures specified in
<xref target="F3411-19" format="default"/>'

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

[Stu] added to terminology section and expanded somewhat here

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

[Stu] noted this and expanded the discussion of impacts of payload length
limitations

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

[Stu] done

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' ?

[Stu] needed; clarified

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

[Stu] neither; clarified

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

[Stu] clarified

-- Section 4.1 --

[Stu] moved these comments to the end so we can address everything but the
numbered requirements first

-- Section 6 --

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

[Stu] Google hits: "Man In The Middle" & attack 41M; "on path attacker" 5k;
both 4k; so for broad reader recognition, "interception by on-path attacker
of (i.e., Man In The  Middle attacks on) registration messages"

-- 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 ;-)

[Stu] I call author Andrei's attention to this one as I do not know his
intent

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

[Stu] done

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

[Stu] attempted, Andrei please review and correct what I wrote

Please make a separate § for CPLDC

[Stu] done, assuming you just wanted a paragraph break, not a longer
paragraph on it?

It is not "LORA" but "LoraWAN" AFAIK

[Stu] the lower layers are LoRa, the optional middle and higher layers are
LoRaWAN; corrected to the former in this context

[Stu] comments below are on numbered requirements, to be addressed after
resolving all those above (quickly, we all hope)

-- 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 ?

---

From: Andrei Gurtov <[email-masked]>
Date: Thu, 29 Apr 2021 10:25:32 +0200

Hi,

The requested links:

https://www.flightradar24.com/

https://opensky-network.org/

ICAO ID paragraph seems fine.

br Andrei

On 4/28/2021 10:07 PM, Card, Stu wrote:
> all --
>
> Please review drip-reqs-10, which has many changes triggered by AD
> Eric's review, and my responses (in some cases rebuttals) to his
> comments below.  The draft is now more complete in its treatment of
> concerns and constraints, and more comprehensible by IETFers
> unfamiliar w/aviation and its SDOs thanks to more background info. It
> will need another edit once we have come to consensus on these points,
> especially the numbered requirements, which I did not want to touch
> until we were all satisfied with the text that motivates/constrains them.
>
> ==
>
> Andrei --
>
> Please address Eric's 1st comment on Appendix A and check my attempt
> at addressing his 3rd comment on Appendix A.
>
> ==
>
> Eric --
>
> I have made a serious effort at addressing your comments on all but
> the numbered requirements: I'd like to come to closure on the former
> before attempting to address the latter; I hope we can do both quickly.
>
> In most cases, I made changes that I hope will satisfy your concerns.
> In others, I attempted rebuttals: please consider my responses; then
> let me know on which comments you still want further changes. Our
> dialog follows in-line.
>
> ==
>
> Comments are from Eric, except where noted as being a response from
> Med or Stu. This email contains a few corrections to what I sent to a
> few of you at 02:30. ;-)
>
> ==
>
> 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.
>
> 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 ?
>
> [Stu] rewrote as "(500 meters in under 13 seconds by the fastest
> consumer mass market drones available in early 2021)"
>
>
> Unsure whether the paragraph starting with "Diverse other applications
> can be enabled or facilitated by RID." Has any added value. Consider
> removing it.
>
> [Stu] expanded and corrected to "Wi-Fi Neighbor Awareness Networking
> (NAN, also known as Wi-Fi Aware) and/or IEEE 802.11 Beacon modes"
>
>
> 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 ?).
>
> [Stu] I am guessing that the several consecutive paragraphs with
> references to multiple EU documents are the worst. Fortunately, these
> are all just informative references, cited as context under
> "Motivation and External Influences", rather than anything that the
> reader must grok.
>
>
> definitions section is longer than any currently before it, and is
> even more dry; I fear losing readers if we subject them to that before
> even motivating the problem. I put a forward reference to the
> terminology section at the beginning of the introduction.
>
>
> 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 ?
>
> [Stu] The context "<xref target="ASDRI" format="default"/>
> contemplated" has been inserted, and the clarification "(European) state".
>
>
> There is also an ambiguity between 'not broadcast' in the list of
> 'will broadcast locally' ;-)
>
> [Stu] inserted the one word "corresponding" to yield "The
> corresponding private ID part will contain 3 characters which are not
> broadcast..." to clarify that the "private ID part" is not actually in
> the list of "will broadcast locally", but an external item that
> relates to a data element in the list.
>
>
> technical specifications, other than DRIP, known to the authors as of
> early 2021."
>
>
> [Stu] Each SDO has its own cultural context for this distinction. I
> have added ICAO's definitions to the terminology section.
>
>
> -- Section 1.2 --
>
> '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.
>
> [Stu] entire section reorganized for clarity and flow; also the
> one-way nature of Broadcast RID is stated 4 more times after this in
> the document
>
>
> -- Section 1.3 --
>
> Thank you for repeating the DRIP WG charter. You may want to replace
> 'goal' by 'charter' in the 1st paragraph
>
> [Stu] done
>
>
> [Stu] that is our WG's IETF mailing list address, and the
> "fingerprint" of Adam's, Bob's and my funding source to do this work,
> so I'd really rather not lose it
>
>
> -- Section 1.4 --
>
> 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.
>
> [Stu] understood; we need _adoption_ of DRIP, not only by IETF, but
> also by the aviation community
>
>
> [Stu] yes, that this is US only now further emphasized by citing FAA
> as the authority
>
>
> Should "Net-RID" also be defined ? Some other places use "network
> RID", is it the same concept ?
>
> "Net-RID SP" (Network RID Service Provider) and "Net-RID DP" (Network
> RID Display Provider)
>
>
> '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
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8576%23section-5.9&data=04%7C01%7Candrei.gurtov%40liu.se%7C782942517fcf43a8f75c08d90a81433b%7C913f18ec7f264c5fa816784fe9a58edd%7C0%7C0%7C637552373296421621%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cZvJoHNY0Nf2QqHd5DsFbJkiE0U6H3NrgsJ3MfAXFv0%3D&reserved=0>
> 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 ?
>
> document where all ASTM RID messages are described in prose with
> important details; there are other groups of related definitions that
> could also be grouped, but alphabetical organization is understand by all
>
>
> "Although called "UAS ID", unique to the UA," I wonder whether the
> first comma is sensible.
>
> [Stu] clarified
>
>
> [Stu] could put in a "sic" if you wish to flag the arguable
> grammatical error, but can't change it, as it is an attributed direct
> quotation
>
>
> -- Section 3 --
>
> Unsure whether " (or other Wide Area Network)" is useful here... Or do
> you mean IP connectivity ?
>
> [Stu] unsure how to more clearly and concisely say "connectivity other
> than the direct Broadcast RID data link, which might be Internet, or
> not Internet but still IP, or not even IP, but likely to be multi-hop,
> to reach a registry or cache of registry data"
>
>
> "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 ;-)
>
> Type", reflected in our draft terminology definitions; but this list
> and subsequent text needed to be more consistent in usage, which I
> have attempted, thanks for catching it
>
>
> -- 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" ?
>
> important, the UAS community calls this the "C2 link", even when it is
> not actually a data link, but rather something else such as a
> transport connection
>
>
> "(and other middle layer protocols)" what is this 'middle layer' ? Is
> it an application-layer protocol ?
>
> [Stu] implied but not fully specified in F3411 or regulations; revised
> as "(and other middle layer protocols, e.g., TLS/TCP or DTLS/UDP)"
>
>
> s/ via unspecified (generally presumed to be webÂ  browser based)
> means/via means that are out of scope of this document/ ?
>
> [Stu] changed to "(via means unspecified by [F3411] etc., but
> generally presumed to be web browser based)."
>
>
> [Stu] done, and the opportunity used to explain the different
> scenarios at slightly greater length
>
>
> Figure 4, suggest to add the operator (even if doing nothing in this
> case) to be consistent with figure 3.
>
> [Stu] to be consistent, we would need to add more than the operator,
> but the point of this figure is to show explicitly that only these two
> actors and one data link are involved
>
>
> [Stu] expanded with the full F3411 term "web-based Broadcast
> Authentication Verifier Service"
>
>
> [Stu] collapsed on all but first use; IEEE 802.11 Beacon and Bluetooth
> 4 vs 5 also updated
>
>
> API has already been expanded and this is a well-known term, hence,
> not even a need to expand it. See also
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fmaterials%2Fabbrev.expansion.txt&data=04%7C01%7Candrei.gurtov%40liu.se%7C782942517fcf43a8f75c08d90a81433b%7C913f18ec7f264c5fa816784fe9a58edd%7C0%7C0%7C637552373296431616%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZOgIPIXJNTi%2BeZ%2BWgK%2F3%2BpQzHHTAhXnysDG%2FOfWEHAk%3D&reserved=0>
>
> s/ within the 25 byte limit/ within the 25-octet limit/. I.e., do not
> use ambiguous 'byte' but rather use 'octet'
>
> 'byte: Used here in its now-customary sense as a synonym for "octet"
> as "byte" is used exclusively in definitions of data structures
> specified in <xref target="F3411-19" format="default"/>'
>
>
> "on the basis of MAC address" just beware that IEEE 802.11ag/ah (if
> not mistaken) starts to randomize MAC addresses...
>
> [Stu] noted this and expanded the discussion of impacts of payload
> length limitations
>
>
> in " To satisfy EASA and FAA rules, all types are needed" is it
> 'needed' or 'mandatory' ?
>
> [Stu] needed; clarified
>
>
> "far too short for conventional certificates" while I am unsure what
> is a 'conventional' certificate, could the cert be fetch off-line ?
>
> [Stu] clarified
>
>
> -- Section 4.1 --
>
> [Stu] moved these comments to the end so we can address everything but
> the numbered requirements first
>
>
> -- Section 6 --
>
> On this International Women Day, some will suggest to replace 'Man In
> The Middle' by 'on path attacker'
>
> [Stu] Google hits: "Man In The Middle" & attack 41M; "on path
> attacker" 5k; both 4k; so for broad reader recognition, "interception
> by on-path attacker of (i.e., Man In The  Middle attacks on)
> registration messages"
>
>
> -- 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 ;-)
>
> [Stu] I call author Andrei's attention to this one as I do not know
> his intent
>
>
> "It transmits a four-digit squawk code" should be qualified as four
> octal digits.
>
> [Stu] done
>
>
> The I-D does not discuss the 24-bit ICAO identifier in mode-S
> transponder. For sake of completeness, please mention it.
>
> [Stu] the lower layers are LoRa, the optional middle and higher layers
> are LoRaWAN; corrected to the former in this context
>
>
> [Stu] comments below are on numbered requirements, to be addressed
> after resolving all those above (quickly, we all hope)
>
> -- Section 4.1 --
>
> GEN-4: 'readability' is rather vague... is it about clear text vs.
> cipher text ? is about structure/format ?
>
> GEN-7: unsure whether the message frequency is really about QoS
> (suggest to find an alternative to QoS)
>
> 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 --
>