Subject: Re: [Raw] AD review of draft-ietf-raw-ldacs-09

From: "Dr. Corinna Schmitt" <[email-masked]>
Date: Mon, 14 Mar 2022 16:30:13 +0100

Dear John,

thanks for the feedback. We just included it but cannot upload it on the 
tracker, as the submission is closed. Attached the new document v10 
which we will upload as soon as possible. Nils will present the changes 
at the IETF 113 and come back to you with personal mail.

Regards, Corinna

Am 27.02.22 um 02:57 schrieb John Scudder:
> Hi Authors,
>
> Thanks for this document, which I as a non-expert in wireless 
> technologies and a neophyte at aviation, found interesting, readable, 
> and accessible. I have only a few things I’d like to bring up before 
> moving it along.
>
> Thanks,
>
> —John
>
>
> Major
>
> 1. I’m a little concerned that you have a number of normative 
> references which aren’t freely accessible. Usually in IETF documents 
> we like to know that normative references have been reviewed, or at 
> least could have been reviewed, by community members. That doesn’t 
> seem to be the case here.
>
> On the other hand, I reviewed the document without consulting the 
> normative references, and found it quite usable as (to quote Pascal’s 
> shepherd writeup), a “description … of an externally-defined 
> link-layer”. Since it doesn’t define a protocol, it’s OK that the 
> underlying documents aren’t freely available, I think the desired 
> information is communicated anyway.
>
> The relevant IESG statement on normative vs. informative references 
> (https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/) 
> describes normative this way: “Normative references specify documents 
> that must be read to understand or implement the technology in the new 
> RFC, or whose technology must be present for the technology in the new 
> RFC to work.” Since your document doesn’t specify a technology, the 
> “understand” part is the only one that might apply, but in my opinion 
> reading the references isn’t a must for being able to understand the 
> draft.
>
> In short, I suggest moving the references to informative, so there 
> would be no normative references. I don’t insist on this, but it seems 
> to me like it would remove a potential impediment to progression of 
> the document.
>
>
> Minor
>
> 1. In Section 3.1 you have
>
>    All VHF and HF voice communications are operated
>    via open broadcast channels without authentication, encryption or
>    other protective measures.  The use of well-proven communications
>    procedures via broadcast channels can help to enhance the safety of
>    communications.
>
> I was able to correctly guess the meaning of the second sentence 
> (about “well-proven communications procedures”), but it’s not quite 
> obvious in context to a non-expert. I suggest you either elaborate in 
> line, or provide a forward reference to Section 9.1 where you have
>
>    Currently, information security is mainly
>    procedural, based by using well-trained personnel and proven
>    communications procedures.
>
> (The mention of “personnel” provides context that I found illuminating.)
>
> 2. In Section 3.2 you have
>
>    The data communications networks, used for the transmission of data
>    relating to the safety and regularity of flight, must be strictly
>    isolated from those providing entertainment services to passengers.
>
> I assume this is for regulatory reasons, and you allude to that in 
> places later in the document. Maybe add those words, “for regulatory 
> reasons,” either at beginning or end of the sentence?
>
> 3. In Section 6 you have
>
>    Ideally the aeronautical IP internetwork and the Internet should be
>    completely separated.
>
> First, in looking into this, I realized that you don’t define what you 
> mean by “aeronautical IP internetwork”. I guess it probably means the 
> network LDACS connects to, which supports (only) communications 
> related to safety and regularity of flight?
>
> As you probably are aware, “complete separation” of networks is a very 
> high bar to set. I would guess it’s not achievable for this network, 
> since to achieve literal complete separation would entail building a 
> complete parallel infrastructure to existing communications 
> infrastructure, up to and including laying new fiber. The word 
> “ideally” helps, since it’s a hint to the reader that the authors 
> accept this complete separation may not happen in reality (since real 
> life isn’t ideal). But I suggest you might provide a little more 
> context here, since I anticipate other reviewers might also focus on 
> this point. For example (and this is only an example) you could say “… 
> completely separated at Layer 3”.
>
> 4. Thank you for including the tables in Appendix A. But, I don’t 
> understand what the “(safety)” and “(efficiency)” notations that 
> appear twice mean. Can you help me?
>
>
> Editorial/Nits
>
> 1. Page 4: “In the context of WG-RAW…” This doesn’t scan too well and 
> besides, “WG-RAW” isn’t common usage. I guess replacing “WG-RAW” with 
> “the Reliable and Available Wireless (RAW) working group” would be 
> good enough.
>
> 2. In Section 5.2.4 you end with “i.e., engine maintenance data”. Do 
> you really mean the “significant amounts of data” are exclusively due 
> to engine maintenance data, as the “i.e.” suggests? (I informally 
> expand “i.e.” as “in other words”.) I’m guessing not, and that you 
> mean “e.g.” which I informally expand as “for example”.
>
> 3. In Section 7 you have
>
>    Input
>    from the working group will be appreciated here.
>
> While this is great, and suitable in an Internet Draft, the RFC Series 
> is archival with a long shelf life. I’m not sure what the best 
> resolution would be here, options include
>
> - Do nothing
> - Remove the sentence
> - Re-word the sentence in some more generic form
>
> 4. Section 7.3.2.3 ends with
>
>    The creation and selection
>    of voice circuits is performed.
>
> Even though not formally a sentence fragment, I think something is 
> missing here?
>
> 4. In Section 8.2 you have
>
>    It employs selective repeat ARQ with transparent fragmentation and
>    reassembly to the resource allocation size to achieve low latency and
>    a low overhead without losing reliability.
>
> It seems to me “low latency” is in the eye of the beholder; the 
> latency figures given elsewhere in the document would be considered so 
> high as to cause users of consumer Internet services to change 
> providers. :-) I realize context is everything, perhaps the wording “… 
> to minimize latency and overhead” would be a little more precise?
>
> 5. These two sentences in Section 8.3 seem to need a little re-work:
>
>    The deployment of a larger number of
>    small cells is certainly possible, suffers, however, also from the
>    scarcity of spectrum.
>
> And
>
>    Support for high
>    reliability and availability for IP connectivity over LDACS is
>    therefore, highly desirable, needs, however, to be adapted to the
>    specific use case.
>
> 6. In Section 9.1,
>
>    Thus, future digital communications
>    waveforms will need additional embedded security features
>
> I’m almost certain “waveforms” can and should be deleted. If deleting 
> the word would NOT be appropriate, that means I don’t understand what 
> you’re trying to say here, and need help…
>
> 7. In Section 9.5.1 you have what looks like a spurious open parenthesis:
>
>    (access routers to the different
>
> 8. In Section 9.5.4 you refer to “the air gap”. In my experience “air 
> gap” generally is used in a security context, to refer to one system 
> not being connected to another, e.g. 
> https://csrc.nist.gov/glossary/term/air_gap, “Air gap: An interface 
> between two systems at which (a) they are not connected physically and 
> (b) any logical connection is not automated (i.e., data is transferred 
> through the interface only manually, under human control).” Probably 
> this isn’t what you mean, and you mean something more like “wireless 
> link”?
>
> 9. You don’t provide a URL for [GRA2019]. Is 
> https://www.ldacs.com/wp-content/uploads/2013/12/SESAR2020_PJ14_D3_3_030_LDACS_AG_Specification_00_02_02-1_0.pdf 
> suitable?
>
> -- 
> RAW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/raw

-- 
******************************************************

PD Dr. rer. nat. habil. Corinna Schmitt
Head of Secure IoT

Research Institute CODE
Universität der Bundeswehr München

Werner-Heisenberg-Weg 39
85577 Neubiberg, Germany

Email:[email-masked]
Phone: +49 (0)89 6004 7314
Mobil: +49 (0)1514 4821490
https://www.unibw.de/code
https://www.corinna-schmitt.de

---

From: John Scudder <[email-masked]>
Date: Mon, 14 Mar 2022 15:34:15 +0000

Hi Corinna,

Thanks! I’d be glad to take a look at your “preprint”, but would you mind sending me the plain text version (or XML is fine too)? That way I can diff it against the previous.

Regards,

—John

On Mar 14, 2022, at 11:30 AM, Dr. Corinna Schmitt <[email-masked]<mailto:[email-masked]>> wrote:

Dear John,

thanks for the feedback. We just included it but cannot upload it on the tracker, as the submission is closed. Attached the new document v10 which we will upload as soon as possible. Nils will present the changes at the IETF 113 and come back to you with personal mail.

Regards, Corinna

Thanks for this document, which I as a non-expert in wireless technologies and a neophyte at aviation, found interesting, readable, and accessible. I have only a few things I’d like to bring up before moving it along.

Thanks,

—John

Major

1. I’m a little concerned that you have a number of normative references which aren’t freely accessible. Usually in IETF documents we like to know that normative references have been reviewed, or at least could have been reviewed, by community members. That doesn’t seem to be the case here.

On the other hand, I reviewed the document without consulting the normative references, and found it quite usable as (to quote Pascal’s shepherd writeup), a “description … of an externally-defined link-layer”. Since it doesn’t define a protocol, it’s OK that the underlying documents aren’t freely available, I think the desired information is communicated anyway.

The relevant IESG statement on normative vs. informative references (https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/<https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/__;!!NEt6yMaO-gk!VwaC_-QPMf5NT6C25OudTFqK6CCTtiTPNebG-kx0_rtivr1CD5NTr8ZMERBSow$>) describes normative this way: “Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work.” Since your document doesn’t specify a technology, the “understand” part is the only one that might apply, but in my opinion reading the references isn’t a must for being able to understand the draft.

In short, I suggest moving the references to informative, so there would be no normative references. I don’t insist on this, but it seems to me like it would remove a potential impediment to progression of the document.

Minor

I was able to correctly guess the meaning of the second sentence (about “well-proven communications procedures”), but it’s not quite obvious in context to a non-expert. I suggest you either elaborate in line, or provide a forward reference to Section 9.1 where you have

I assume this is for regulatory reasons, and you allude to that in places later in the document. Maybe add those words, “for regulatory reasons,” either at beginning or end of the sentence?

3. In Section 6 you have

First, in looking into this, I realized that you don’t define what you mean by “aeronautical IP internetwork”. I guess it probably means the network LDACS connects to, which supports (only) communications related to safety and regularity of flight?

As you probably are aware, “complete separation” of networks is a very high bar to set. I would guess it’s not achievable for this network, since to achieve literal complete separation would entail building a complete parallel infrastructure to existing communications infrastructure, up to and including laying new fiber. The word “ideally” helps, since it’s a hint to the reader that the authors accept this complete separation may not happen in reality (since real life isn’t ideal). But I suggest you might provide a little more context here, since I anticipate other reviewers might also focus on this point. For example (and this is only an example) you could say “… completely separated at Layer 3”.

4. Thank you for including the tables in Appendix A. But, I don’t understand what the “(safety)” and “(efficiency)” notations that appear twice mean. Can you help me?

Editorial/Nits

1. Page 4: “In the context of WG-RAW…” This doesn’t scan too well and besides, “WG-RAW” isn’t common usage. I guess replacing “WG-RAW” with “the Reliable and Available Wireless (RAW) working group” would be good enough.

2. In Section 5.2.4 you end with “i.e., engine maintenance data”. Do you really mean the “significant amounts of data” are exclusively due to engine maintenance data, as the “i.e.” suggests? (I informally expand “i.e.” as “in other words”.) I’m guessing not, and that you mean “e.g.” which I informally expand as “for example”.

3. In Section 7 you have

   Input

While this is great, and suitable in an Internet Draft, the RFC Series is archival with a long shelf life. I’m not sure what the best resolution would be here, options include

- Do nothing
- Remove the sentence

Even though not formally a sentence fragment, I think something is missing here?

It seems to me “low latency” is in the eye of the beholder; the latency figures given elsewhere in the document would be considered so high as to cause users of consumer Internet services to change providers. :-) I realize context is everything, perhaps the wording “… to minimize latency and overhead” would be a little more precise?

And

   Support for high

6. In Section 9.1,

I’m almost certain “waveforms” can and should be deleted. If deleting the word would NOT be appropriate, that means I don’t understand what you’re trying to say here, and need help…

8. In Section 9.5.4 you refer to “the air gap”. In my experience “air gap” generally is used in a security context, to refer to one system not being connected to another, e.g.https://csrc.nist.gov/glossary/term/air_gap<https://urldefense.com/v3/__https://csrc.nist.gov/glossary/term/air_gap__;!!NEt6yMaO-gk!VwaC_-QPMf5NT6C25OudTFqK6CCTtiTPNebG-kx0_rtivr1CD5NTr8YbLUZ69A$>, “Air gap: An interface between two systems at which (a) they are not connected physically and (b) any logical connection is not automated (i.e., data is transferred through the interface only manually, under human control).” Probably this isn’t what you mean, and you mean something more like “wireless link”?

9. You don’t provide a URL for [GRA2019]. Is https://www.ldacs.com/wp-content/uploads/2013/12/SESAR2020_PJ14_D3_3_030_LDACS_AG_Specification_00_02_02-1_0.pdf<https://urldefense.com/v3/__https://www.ldacs.com/wp-content/uploads/2013/12/SESAR2020_PJ14_D3_3_030_LDACS_AG_Specification_00_02_02-1_0.pdf__;!!NEt6yMaO-gk!VwaC_-QPMf5NT6C25OudTFqK6CCTtiTPNebG-kx0_rtivr1CD5NTr8bNnhRJ8Q$> suitable?

--
RAW mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/raw<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/raw__;!!NEt6yMaO-gk!VwaC_-QPMf5NT6C25OudTFqK6CCTtiTPNebG-kx0_rtivr1CD5NTr8ZMYti7PA$>

Research Institute CODE

Werner-Heisenberg-Weg 39
85577 Neubiberg, Germany

Email: [email-masked]<mailto:[email-masked]>
Phone: +49 (0)89 6004 7314
Mobil: +49 (0)1514 4821490
https://www.unibw.de/code<https://urldefense.com/v3/__https://www.unibw.de/code__;!!NEt6yMaO-gk!VwaC_-QPMf5NT6C25OudTFqK6CCTtiTPNebG-kx0_rtivr1CD5NTr8YdKZzVbw$>
https://www.corinna-schmitt.de<https://urldefense.com/v3/__https://www.corinna-schmitt.de__;!!NEt6yMaO-gk!VwaC_-QPMf5NT6C25OudTFqK6CCTtiTPNebG-kx0_rtivr1CD5NTr8ZIWISjug$>

<draft-ietf-raw-ldacs-10.pdf>

---

From: <[email-masked]>
Date: Mon, 14 Mar 2022 15:37:29 +0000

Hi John,

Please find attached the text version of the current draft.
I will respond to your comments momentarily.

Best regards,
Nils

Von: John Scudder <[email-masked]>
Gesendet: Montag, 14. März 2022 16:34
An: Dr. Corinna Schmitt <[email-masked]>
Cc: [email-masked]; [email-masked]; Mäurer, Nils <[email-masked]>; Gräupl, Thomas <[email-masked]>; [email-masked]
Betreff: Re: [Raw] AD review of draft-ietf-raw-ldacs-09

Hi Corinna,

Regards,

—John

Dear John,

Thanks,

—John

Major

The relevant IESG statement on normative vs. informative references (https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/<https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statements/normative-informative-references/__;!!NEt6yMaO-gk!VwaC_-QPMf5NT6C25OudTFqK6CCTtiTPNebG-kx0_rtivr1CD5NTr8ZMERBSow$>) describes normative this way: “Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work.” Since your document doesn’t specify a technology, the “understand” part is the only one that might apply, but in my opinion reading the references isn’t a must for being able to understand the draft.

Minor

3. In Section 6 you have

Editorial/Nits

3. In Section 7 you have

   Input

- Do nothing
- Remove the sentence

And

   Support for high

6. In Section 9.1,

8. In Section 9.5.4 you refer to “the air gap”. In my experience “air gap” generally is used in a security context, to refer to one system not being connected to another, e.g.https://csrc.nist.gov/glossary/term/air_gap<https://urldefense.com/v3/__https:/csrc.nist.gov/glossary/term/air_gap__;!!NEt6yMaO-gk!VwaC_-QPMf5NT6C25OudTFqK6CCTtiTPNebG-kx0_rtivr1CD5NTr8YbLUZ69A$>, “Air gap: An interface between two systems at which (a) they are not connected physically and (b) any logical connection is not automated (i.e., data is transferred through the interface only manually, under human control).” Probably this isn’t what you mean, and you mean something more like “wireless link”?

9. You don’t provide a URL for [GRA2019]. Is https://www.ldacs.com/wp-content/uploads/2013/12/SESAR2020_PJ14_D3_3_030_LDACS_AG_Specification_00_02_02-1_0.pdf<https://urldefense.com/v3/__https:/www.ldacs.com/wp-content/uploads/2013/12/SESAR2020_PJ14_D3_3_030_LDACS_AG_Specification_00_02_02-1_0.pdf__;!!NEt6yMaO-gk!VwaC_-QPMf5NT6C25OudTFqK6CCTtiTPNebG-kx0_rtivr1CD5NTr8bNnhRJ8Q$> suitable?

--
RAW mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/raw<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/raw__;!!NEt6yMaO-gk!VwaC_-QPMf5NT6C25OudTFqK6CCTtiTPNebG-kx0_rtivr1CD5NTr8ZMYti7PA$>

--

Head of Secure IoT

Research Institute CODE

Werner-Heisenberg-Weg 39

85577 Neubiberg, Germany

https://www.unibw.de/code<https://urldefense.com/v3/__https:/www.unibw.de/code__;!!NEt6yMaO-gk!VwaC_-QPMf5NT6C25OudTFqK6CCTtiTPNebG-kx0_rtivr1CD5NTr8YdKZzVbw$>

https://www.corinna-schmitt.de<https://urldefense.com/v3/__https:/www.corinna-schmitt.de__;!!NEt6yMaO-gk!VwaC_-QPMf5NT6C25OudTFqK6CCTtiTPNebG-kx0_rtivr1CD5NTr8ZIWISjug$>
<draft-ietf-raw-ldacs-10.pdf>

---

From: "Dr. Corinna Schmitt" <[email-masked]>
Date: Mon, 14 Mar 2022 20:13:31 +0100

Hallo John,

here all file-formats. Please work only on these. Do not use the file 
from Nils mail of this afternoon. I will upload v10 on the March 19, 
when the portal is active again.

Regards, Corinna

Am 14.03.22 um 16:34 schrieb John Scudder:
> Hi Corinna,
>
> Thanks! I’d be glad to take a look at your “preprint”, but would you 
> mind sending me the plain text version (or XML is fine too)? That way 
> I can diff it against the previous.
>
> Regards,
>
> —John
>
>> On Mar 14, 2022, at 11:30 AM, Dr. Corinna Schmitt 
>> <[email-masked]> wrote:
>>
>> Dear John,
>>
>> thanks for the feedback. We just included it but cannot upload it on 
>> the tracker, as the submission is closed. Attached the new document 
>> v10 which we will upload as soon as possible. Nils will present the 
>> changes at the IETF 113 and come back to you with personal mail.
>>
>> Regards, Corinna
>>
>>
>>> technologies and a neophyte at aviation, found interesting, 
>>> readable, and accessible. I have only a few things I’d like to bring 
>>> up before moving it along.
>>>
>>> Thanks,
>>>
>>> —John
>>>
>>>
>>> Major
>>>
>>> normative references, and found it quite usable as (to quote 
>>> Pascal’s shepherd writeup), a “description … of an 
>>> externally-defined link-layer”. Since it doesn’t define a protocol, 
>>> it’s OK that the underlying documents aren’t freely available, I 
>>> think the desired information is communicated anyway.
>>>
>>> describes normative this way: “Normative references specify 
>>> documents that must be read to understand or implement the 
>>> technology in the new RFC, or whose technology must be present for 
>>> the technology in the new RFC to work.” Since your document doesn’t 
>>> specify a technology, the “understand” part is the only one that 
>>> might apply, but in my opinion reading the references isn’t a must 
>>> for being able to understand the draft.
>>>
>>> would be no normative references. I don’t insist on this, but it 
>>> seems to me like it would remove a potential impediment to 
>>> progression of the document.
>>>
>>>
>>> Minor
>>>
>>> obvious in context to a non-expert. I suggest you either elaborate 
>>> in line, or provide a forward reference to Section 9.1 where you have
>>>
>>> First, in looking into this, I realized that you don’t define what 
>>> you mean by “aeronautical IP internetwork”. I guess it probably 
>>> means the network LDACS connects to, which supports (only) 
>>> communications related to safety and regularity of flight?
>>>
>>> As you probably are aware, “complete separation” of networks is a 
>>> very high bar to set. I would guess it’s not achievable for this 
>>> network, since to achieve literal complete separation would entail 
>>> building a complete parallel infrastructure to existing 
>>> communications infrastructure, up to and including laying new fiber. 
>>> The word “ideally” helps, since it’s a hint to the reader that the 
>>> authors accept this complete separation may not happen in reality 
>>> (since real life isn’t ideal). But I suggest you might provide a 
>>> little more context here, since I anticipate other reviewers might 
>>> also focus on this point. For example (and this is only an example) 
>>> you could say “… completely separated at Layer 3”.
>>>
>>> 1. Page 4: “In the context of WG-RAW…” This doesn’t scan too well 
>>> and besides, “WG-RAW” isn’t common usage. I guess replacing “WG-RAW” 
>>> with “the Reliable and Available Wireless (RAW) working group” would 
>>> be good enough.
>>>
>>> you really mean the “significant amounts of data” are exclusively 
>>> due to engine maintenance data, as the “i.e.” suggests? (I 
>>> informally expand “i.e.” as “in other words”.) I’m guessing not, and 
>>> that you mean “e.g.” which I informally expand as “for example”.
>>>
>>> 3. In Section 7 you have
>>>
>>>    Input
>>> While this is great, and suitable in an Internet Draft, the RFC 
>>> Series is archival with a long shelf life. I’m not sure what the 
>>> best resolution would be here, options include
>>>
>>> - Do nothing
>>> - Remove the sentence
>>> latency figures given elsewhere in the document would be considered 
>>> so high as to cause users of consumer Internet services to change 
>>> providers. :-) I realize context is everything, perhaps the wording 
>>> “… to minimize latency and overhead” would be a little more precise?
>>>
>>> I’m almost certain “waveforms” can and should be deleted. If 
>>> deleting the word would NOT be appropriate, that means I don’t 
>>> understand what you’re trying to say here, and need help…
>>>
>>> 8. In Section 9.5.4 you refer to “the air gap”. In my experience 
>>> “air gap” generally is used in a security context, to refer to one 
>>> system not being connected to another, 
>>> e.g.https://csrc.nist.gov/glossary/term/air_gap, “Air gap: An 
>>> interface between two systems at which (a) they are not connected 
>>> physically and (b) any logical connection is not automated (i.e., 
>>> data is transferred through the interface only manually, under human 
>>> control).” Probably this isn’t what you mean, and you mean something 
>>> more like “wireless link”?
>>>
>>> 9. You don’t provide a URL for [GRA2019]. 
>>> Ishttps://www.ldacs.com/wp-content/uploads/2013/12/SESAR2020_PJ14_D3_3_030_LDACS_AG_Specification_00_02_02-1_0.pdfsuitable?
>>>
>>> --
>>> RAW mailing list
>>> [email-masked]

Research Institute CODE

Werner-Heisenberg-Weg 39
85577 Neubiberg, Germany