Re: [Raw] [Gen-art] Genart last call review of draft-ietf-raw-ldacs-10

[[e-mail]]

Dale Worley via Datatracker <[e-mail]> writes:
> 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.

Trying to make clearer my main concern about this draft, which is hard
to express clearly:  What is the scope of this document?  It seems to be
a high-level architectural overview and it also provides a great deal of
the context of ATM communications which motivates the architecture.  But
it includes certain lower-level details, such as the breakdown of the
protocol stack into its major components, the frequency and width of the
bands and channels, the lowest-level modulation technique (ODFMA), the
partitioning of the channels into specific control channels and data
channels, and some information about the super-frame and multi-frame
structure.

But other than the breakdown of the protocol stack, none of these
descriptions is carried through to the point that you understand the
subject -- the coding system(s) on top of ODFMA aren't mentioned
(excepting for what is done on the control channels), the detailed frame
formats aren't given, the data link message format and control protocols
aren't fully described.  It seems like it would be natural to delete the
various partial descriptions to scope the document purely to high-level
architecture and the motivating context, and of course, limited to the
zone between the aircraft and the Access Router connecting to a set of
cell Ground Stations.

On the other hand, it seems that one aspect of the architecture that is
easily visible "from the outside", that is, from the ATN side of the
Access Router, is how the flow of IPv6 packets is handled.  And this is
naturally in-scope for an IETF document regarding LDACS.  One can
imagine that the architectural IPv6 interface that is the terminus of
packets is the Access Router, presumably with different ports on that
interface communicating with functions in different aircraft.  At the
other extreme, one can imagine that distinct devices or services in
aircraft are allocated IPv6 addresses and the architectural IPv6
interfaces are there.  That latter structure means that IPv6 (possibly
in some reformatted form) is explicitly carried from the Access Router
to the Ground Station to the aircraft and across a network within the
aircraft.  Whatever choice LDACS makes will be reflected in numerous
IPv6 infrastructure services in ways that are visible on the ATN side of
the Access Router, and seems like it should be in this document.

Dale