Last Call Review of draft-ietf-raw-ldacs-10
review-ietf-raw-ldacs-10-genart-lc-worley-2022-03-31-00

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]