Dale, thank you for your review. I have entered a No Objection ballot for this document. Lars > On 2022-4-1, at 5:50, Dale Worley via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Dale Worley > Review result: Ready with Issues > > 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 > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > 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] > > > > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
