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

From: John Scudder <[email-masked]>
Date: Sun, 27 Feb 2022 01:57:28 +0000

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?