Dale Worley via Datatracker <noreply@xxxxxxxx> 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
