I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-raw-ldacs-10 Reviewer: Dale R. Worley Review Date: 2022-03-31 IETF LC End Date: 2022-04-04 IESG Telechat date: not known Summary: This draft is basically ready for publication, but it seems to me to have open issues, depending on the intended scope of the document. Issues: There are a number of minor editorial issues listed below. But the one issue that might be significant is the lack of detail about how LDACS is expected to utilize the IP infrastructure as defined by the IETF. Strictly speaking, this document is an informational document about a particular data-link layer, and in that sense, layer 3 is out of scope, but what the IETF audience would be most informed by would be how the data-link layer integrates with IPv6 and existing IPv6 protocols. 3. Motivation and Use Cases It refers to the mostly proprietary exchange of data between the aircraft of the airline, its operation centers, and its service partners. Not being in the airline industry, my initial reading of this was that aircraft had operation centers and service partners. Perhaps this could be clarified for the naive as It refers to the mostly proprietary exchange of data between the aircraft of the airline and the airline's operation centers and service partners. 3.1. Voice Communications Today Voice links are used for Air/Ground (A/G) and Air/Air (A/A) communications. The communications equipment is either ground-based working in the High Frequency (HF) or VHF frequency band or satellite-based. By comparison, 5.2.2 states that A/A communication is only considered as a possible extension for LDACS, which seemed surprising to read at that point. This could be clarified if 3.1 noted that LDACS is not currently planned to implement A/A communication, even for voice. 5.2. Application (sending Ground Based Augmentation System (GBAS) correction data) Naively, this reads as "data to correct GBAS data". Perhaps clearer as "Ground Based Augmentation System (GBAS) data to correct GNSS" or even just "GNSS correction data" as is used in 5.2.3. 7. Characteristics Achieving the stringent continuity, availability, and integrity requirements defined in [DO350A] will require the specification of layer 3 and above mechanisms (e.g. reliable crossover at the IP layer). Fault management mechanisms are similarly undefined. This limitation seems to be strictly correct, given that this document is only scoped to the data link layer. But it would be useful to the reader to give an outline of how IP interacts with the data link layer. In particular, are the packets sent over the link IPv6 packets (perhaps encoded in some special way)? What is the general IP addressing architecture of the LDACS sub-network (i.e. AS, GS, and AR)? Similarly, what existing protocols (if any) are expected to reach the AS? These latter points are the ones that most directly intersect the IETF's business. 7.3. LDACS Protocol Stack The last entity resides within the sub-network layer: the Sub-Network Protocol (SNP). Given the context of this sentence, "the last entity" could refer to either functional block five, or to item (4) in the immediately preceding list (the LME). This would be less ambiguous as "The fifth block ...". The LDACS network is externally connected to voice units, radio control units, and the ATN network layer. How does this mesh with the architecture shown in Figure 1 of 7.1, which shows only the connection of LDACS to ATN? -- Figure 2 doesn't show the positioning of the VI functional block. 8.2. Layer 1 and 2 The figures in this section have very little information for a diagram of a frame structure. E.g. the length of an SF is specified (240ms = 2000 symbols), but the lengths of MF, BCCH, and RACH are not specified. Similarly, the lengths of the divisions of the MF aren't specified. The layout and size of the transmission time slots aren't discussed. FL and RL boundaries are aligned in time (from the GS perspective) Given that a cell can be as large as 200 nautical miles, which is 1235 microseconds at light-speed, and a symbol is 120 microseconds, while the FL and RL frame structures are synchronized at the GS, they can be desynchronized by ~20 symbols at the AS. This seems to be handled by propagation guard times but it would be useful to describe the guard time placements in the frame structures. 8.3. Beyond Layer 2 This means proliferating the number of terrestrial ground stations. However, the scarcity of aeronautical spectrum for data link communication (in the case of LDACS: tens of MHz in the L-band) and the long range (in the case of LDACS: up to 200 nautical miles) make this quite hard. Naively, the available bandwidth for the LDACS system as a whole in a geographical region should scale with the number of cells. The above statement suggests that is not true in LDACS, and it would be useful to explain why. 9.5.1. Entities The document seems to be using "LDACS access network" in 9.5.1 and "LDACS Sub-Network" in Figure 1 of 7.1 to mean the same thing. Neither term is defined in 2. Can these be unified into one term? Would it help to insert it in the glossary? [END]