L-Band Digital Aeronautical Communications System (LDACS)
draft-ietf-raw-ldacs-14

# Internet AD comments for draft-ietf-raw-ldacs-10
CC @ekline

## Comments

### S1

* The use of RFCs 4291 and 7136 for "IPv6 based networking protocols" seems
  a bit odd to me.  These are addressing architecture and interface
  identifier documents; why not just RFC 8200 itself?

### S4, S7.3.3

* I'm sure 6MAN wg might be interested in hearing if anything special is
  required of IPv6 w.r.t. operating over the sub-IP layer here.

### S7.3.2

* Just an FYI: consider having a look at RFC 3366 ("Advice to link designers
  on link Automatic Repeat reQuest (ARQ)"), just in case there's anything
  helpful in there.  (To be clear: no action requested vis. this draft.)

### S9, S9.5.4

* I'm very glad to see that L2 integrity is a requirement.  Without it, many
  IPv6 on-link attacks become possible.

  However, even with L2 integrity, some consideration should be given to
  IPv6 operational security.  Please consider RFC 9099, along with several
  of the documents it references (RFC 4942, etc).

## Nits

### S3.2

* s/While the aircraft is on ground/While the aircraft is on the ground/?

Thanks for working on this document. This was interesting read. However, it felt a bit short on the purpose of such a documentation about LDACS and FCI description. 

I was trying to see how much of this document is actually leading to usecase / requirements and how much of it just description of something done outside of IETF. I concluded that this merely a description of other related technology which might be using RAW. I see that is what the shepherd also wrote. Hence, I find it as support material and in that category we are supposed to encourage the WG to use other tools to publish something which does not have archiving values. A simple reference to the LDAC spec or something in appendix or use of WG wiki could serve the purpose and save WG's time and energy.More than that I found this is below layer-3 and to me that seems to be out of scope of RAW.

It might be the way the document is written where the scope and intention is not clear from the document itself. yes, this might be good information for RAW work, but may be it should then focus on those part which are relevant and need a IETF consensus to really agree on those relevant parts to work in RAW.

For this I am supporting Roman's and Alvero's discuss.

My thanks to the authors for addressing my discuss point.  As such I am balloting no objection on this document.

The datatracker state does not indicate whether the consensus boilerplate
should be included in this document.

No reference entries found for: [KOB1987].

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "master"; alternatives might be "active", "central", "initiator",
   "leader", "main", "orchestrator", "parent", "primary", "server"

Thanks to Dale Worley for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/DhJCJ3dvXjga7paQ8GrXYswpX6E).

-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 7.3.3, paragraph 1, nit:
-    Lastly, the SNP handles the transition from IPv6 packts to LDACS
+    Lastly, the SNP handles the transition from IPv6 packets to LDACS
+                                                         +

Document references draft-haindl-lisp-gb-atn-06, but -07 is the latest
available revision.

Document references draft-ietf-rtgwg-atn-bgp-14, but -17 is the latest
available revision.

Paragraph 2076, nit:
> band's increasing saturation in high- density areas and the limitations posed
>                                 ^^^^^^^^^^^^^
This word seems to be formatted incorrectly. Consider fixing the spacing or
removing the hyphen completely.

Paragraph 2256, nit:
> ications System (LDACS). Since central Europe has been identified as the area
>                                ^^^^^^^^^^^^^^
If the term is a proper noun, use initial capitals.

Paragraph 2315, nit:
> ically LDACS enables IPv6 based air- ground communication related to aviation
>                                 ^^^^^^^^^^^
This word seems to be formatted incorrectly. Consider fixing the spacing or
removing the hyphen completely.

Paragraph 2604, nit:
> cols, the ATN/OSI, failed in the market place. In the context of safety-relat
>                                  ^^^^^^^^^^^^
This is normally spelled as one word.

Paragraph 5565, nit:
> sponsible to guide the aircraft. Currently this is done by the air crew manu
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Currently".

Paragraph 5863, nit:
> eceiver via a separate data link. Currently the VDB data link is used. VDB is
>                                   ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Currently".

Paragraph 5870, nit:
> VDB data link is used. VDB is a narrow-band single-purpose datalink without
>                                 ^^^^^^^^^^^
This word is normally spelled as one.

Paragraph 7117, nit:
> .1. LDACS Sub-Network An LDACS sub-network contains an Access Router (AR) an
>                                ^^^^^^^^^^^
This word is normally spelled as one. (Also elsewhere.)

Paragraph 7315, nit:
> imultaneously support multiple bi-directional communications to the ASs unde
>                                ^^^^^^^^^^^^^^
This word is normally spelled as one. (Also elsewhere.)

Paragraph 9499, nit:
> data links are handled by the FCI multi- link concept. 8. Reliability and Ava
>                                   ^^^^^^^^^^^
This word seems to be formatted incorrectly. Consider fixing the spacing or
removing the hyphen completely.

Paragraph 10374, nit:
> DiffServ) based solution with a small number of priorities is to be expected
>                               ^^^^^^^^^^^^^^^^^
Specify a number, remove phrase, use "a few", or use "some".

Paragraph 15162, nit:
> tps://sike.org/>. [ROY2020] Roy, S.S.. and A. Basso, "High-Speed Instruction
>                                     ^^
Two consecutive dots.

Paragraph 15855, nit:
> f Flight Measurement Results", IEEE 32th Digital Avionics Systems Conference
>                                     ^^^^
The suffix does not match the ordinal number.

Paragraph 16248, nit:
> nich, N., Micallef, J., Klauspeter, H.., MacBride, J., Sacre, P., v.d. Eiden
>                                      ^^
Two consecutive dots.

Hi,

Thanks for this document.

I have some sympathy with other ADs opinions that this may be better published via the ISE, although it isn't entirely clear to me that this should be out of scope for an IETF informational document.

I didn't read the document in complete detail, but I did wonder whether it would be helpful to have a short section describing management considerations?  E.g., what management interface/protocols would be used to configure/manage the solution?  Would this be done via YANG + NETCONF, or a different network management stack.

Regards,
Rob