L-Band Digital Aeronautical Communications System (LDACS)
Note: This ballot was opened for revision 10 and is now closed.
(was Discuss) Yes
Comment (2022-10-21 for -13) Sent
Thank you, Nils and other authors, for addressing my previous blocking DISCUSS and non-blocking COMMENT points per: https://mailarchive.ietf.org/arch/msg/raw/WnMNGy4YMhqUHtPW6UC45CJ6KXI/ Thanks again for the work done: I have enjoyed reading this document. Regards -éric PS: thanks also to Carlos Bernardos for his INT directorate review.
(was Discuss) No Objection
Comment (2022-11-06 for -13) Sent for earlier
My thanks to the authors for addressing my discuss point. As such I am balloting no objection on this document.
Comment (2022-04-18 for -10) Sent
# 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/?
Comment (2022-04-20 for -10) Sent
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.
Comment (2022-04-20 for -10) Sent
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
Comment (2022-04-21 for -10) Sent
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.
(was Discuss) Abstain
Comment (2022-10-31 for -13) Sent
Thank you to Russ Housley for the SECDIR review. Thank you to the authors for their response to my original ballot (https://mailarchive.ietf.org/arch/msg/raw/O-oD5YszJPL8ia1RCoVgNHqykLk/) I am changing my ballot from DISCUSS to ABSTAIN. This change is not because my DISCUSS feedback have been addressed but because subsequent revisions of the document (-11 to -13) now makes clear that there is no IETF protocol behavior to review. My feedback was either on actual or planned work being done in other SDOs. This content and the process to arrive at consensus as enumerated in Alvaro’s ballot leads me to share his concerns on the ability to meet the rough consensus bar set by RFC8789 to become an IETF stream RFC. Finally, as I noted in my original DISCUSS position, I do not believe this work is in scope for the WG. ==[ DISCUSS on -10 ** With the upfront acknowledgement that I have little familiarity with LDACS, I had significant difficulty in assessing the alignment of most this document to the defined charter of RAW. It appears to me that only a narrow portion of the document is in-charter scope. References were provided for LDACS (e.g., [ICAO2015]), but as they were behind a paywall I was not able to review them. Relying primarily on Section 7.3 and Figure 3 of the [MAE20192], it appears that LDACS is a series of technologies that operate below layer-3. Operating on top of LDACS at layer3+ is the FCI. Section 4 reminds us that “The IPv6 architecture for the aeronautical telecommunication network is called the FCI.” Per the RAW charter, “RAW will stay abstract to the radio layers underneath, addressing the Layer 3 aspects in support of applications requiring high reliability and availability.” With that in mind, I was looking for the in scope RAW work items to produce “Use Cases, Requirements, Architecture/Framework Aspects for a Wireless Network, and an Evaluation of Existing IETF Technologies and Gap Analysis” for technologies at or above layer 3. In Section 5.2.3, I first found specifics on FCI that appear to a use cases within that scope. In Section 7.3.3, there is text on the SNP which describes activity germane to handling layer-3 services. However, this section also excludes this work as out of scope -- “[t]his work is ongoing and not part of this document.” In my assessment the overwhelming majority of the text in this document is describing technologies and architecture not in RAW’s in-scope remit of layer 3+. If the WG finds documenting this otherwise paywalled information in an information document valuable, I see no issue keeping this material in an Appendix. However, the framing of this document needs to be clearer to highlight the in-scope materials around FCI. ** Section 9. Please explicitly document the Security Considerations of FCI (i.e., the IPv6/layer behaviors). Is that Section 9.2? -- Section 9, Per “These requirements imply that LDACS must provide layer 2 security in addition to any higher layer mechanisms”, it isn’t clear how this is in-scope given the remit of RAW (see above). -- Section 9.1 is helpful background but what of that applies to layer 3? The specifics in the threat analysis of [STR2016] and the advent of SDRs appears to be largely data link considerations. -- Section 9.2 How does [MAE20181] inform layer 3 threats as it’s explicitly focused on data link issues? -- Section 9.3. Which of these security objectives apply to the FCI? -- Section 9.5.3. Architecturally, it isn’t clear how IPSec, TLS are being used by the FCI. ==[ COMMENTs on -10 I was unable to review the security claims of this document as several of the references were not available to me. For example, [ARI2021], [ICAO2015], and [ICA2018]. I leave it the judgement of the responsible AD to that the WG had appropriate access and that they are being appropriately used.
Alvaro Retana Former IESG member
(was Discuss) Abstain
Abstain (2022-10-25 for -13) Sent for earlier
I am changing my position from DISCUSS to ABSTAIN. After discussion in the IESG, it is clear that I am in the rough. I am leaving the DISCUSS text below for reference. ===== I found this document very informative, and there is value in publishing it as an RFC. However, I don't believe it can pass the rough consensus bar set by rfc8789 to become an IETF Stream RFC. As mentioned by the Shepherd, this document is a "description by matter specialists of an externally-defined link-layer". The technology described is an overview of work done in another standards development organization (SDO) . There was no discussion of the content on the mailing list, which shows only two messages from non-authors: one asking for more information; the reply was a pointer to the LDACS external specification  -- the other was the single WGLC reply from the document shepherd . I want to discuss this question with the IESG: Can the IETF reach rough consensus on a document that describes technology developed by a different SDO? My opinion is that documents that describe technology developed by a different SDO cannot be published as IETF RFCs given the requirement in rfc8789.  https://www.ldacs.com/wp-content/uploads/2013/12/SESAR2020_PJ14_D3_3_030_LDACS_AG_Specification_00_02_02-1_0.pdf  https://mailarchive.ietf.org/arch/msg/raw/iyext4Ub8MgUjNYYPE7XOPpq1Y0  https://mailarchive.ietf.org/arch/msg/raw/L-ByflWTn_3vcGC8NNfMO-blkJU