Skip to main content

L-band Digital Aeronautical Communications System (LDACS)
draft-ietf-raw-ldacs-10

Discuss


Yes

John Scudder

No Objection


No Record

Francesca Palombini
Martin Duke
Murray Kucherawy
Paul Wouters
Warren Kumari

Summary: Has 4 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.

Alvaro Retana Discuss

Discuss (2022-05-12)
[I'm updating the text of my DISCUSS ballot from Apr/18.  This is a clarification 
to avoid misinterpretations when considering the ballot in a general context.]

[Authors:  Thank you for the work!  There's no action required from you.  My
opinion below is to be discussed with the IESG.]


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) 
[1].  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 [2] -- the other was the 
single WGLC reply from the document shepherd [3].

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.


[1] https://www.ldacs.com/wp-content/uploads/2013/12/SESAR2020_PJ14_D3_3_030_LDACS_AG_Specification_00_02_02-1_0.pdf
[2] https://mailarchive.ietf.org/arch/msg/raw/iyext4Ub8MgUjNYYPE7XOPpq1Y0
[3] https://mailarchive.ietf.org/arch/msg/raw/L-ByflWTn_3vcGC8NNfMO-blkJU

Andrew Alston Discuss

Discuss (2022-04-19)
Firstly thank you to the authors of the document for the good work.

I however must agree with Alvaro's ballot and further expand on it.  I have a concern that publishing a document that merely describes an outside standard, that is not developed within the IETF, could open a significantly problematic door to people developing standards outside of the IETF, and then using a mechanism like this, to effectively get a rubber stamp on something that the IETF has no control over.  To me, this document would seem better suited to the ISE rather than the IETF track.

Roman Danyliw Discuss

Discuss (2022-04-20)
** 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.
Comment (2022-04-20)
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. 

** Section 1.  Editorial

(2) the introduction of IPv6 based networking protocols in
   aeronautical networks [RFC4291], [RFC7136], [ICAO2015].

I didn’t understand the link between [RFC4291] and [RFC7136] and aeronautical networks.  If these are only intended to be citations to IPv6, then the text would be clearer as:

(2) the introduction of IPv6 based networking protocols [RFC4291], [RFC7136] in aeronautical networks  [ICAO2015].

** Section 5.2.1

The related protocol
   stack is currently under development by ICAO, within SESAR, and the
   IETF [I-D.haindl-lisp-gb-atn] [I-D.ietf-rtgwg-atn-bgp]

Judged entirely on datatracker meta-data, it appears to be a mis-characterization to say that draft-haindl-lisp-gb-atn is under-development in the IETF.  All I can confirm is the existence of an individual submission that has been updated a number of times over 4+ years that has not been adopted by a WG.

** From idnits:
  == Missing Reference: 'KOB1987' is mentioned on line 1211, but not defined

Éric Vyncke Discuss

Discuss (2022-04-19)
Thank you for the work put into this document. It is also important for the IETF to welcome new work. The content is really interesting to read (especially for a private pilot!); albeit, it appears more like a roadmap / plan to use IETF protocols for aviation rather than being focused only on LDACS.

Please find below some blocking DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

I also support Alvaro Retana's DISCUSS on using the right publication stream, which should have been ISE in this case as often done for documents describing specifications done outside the IETF. I notice that this document as an "unknown" status for the consensus boilerplate and setting it to "No" (if possible) would probably address Alvaro's concern.

Special thanks to:

- Pascal Thubert for the shepherd's write-up including the WG consensus and the intended status. 

- Carlos Bernardos for his INT directorate review at https://mailarchive.ietf.org/arch/msg/int-dir/oRK9fXWx48Xj6VhdJMMarEPFB3c/ which also raises the same issue as Alvaro but also has other points deserving a reply

I hope that this helps to improve the document,

Regards,

-éric

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

## Section 4

Raising a DISCUSS just to get a discussion with authors, RAW WG, ICAO representatives, and the community:
  "There is currently no "IPv6 over LDACS" specification
   publicly available; however, SESAR2020 has started the testing of
   IPv6-based LDACS testbeds."
Is the plan to have this "IPv6 over LDACS" be specified in an IETF WG (e.g., intarea) ? Or will ICAO work alone on this specification (and perhaps not using the experience of the IETF community)?

## Section 5.2.1

Let me share Carlos' point, which I second (it would be enough to state the intention about MIPv6 to address it):

- "Technically the FCI multilink concept will be realized by multi-homed mobile
IPv6 networks in the aircraft." --> how is Mobile IPv6 going to be used and
which specific protocol of the Mobile IPv6 family? just MIPv6 and/or PMIPv6?
implications on mobility and RAW are unclear at this point (probably this is
for the RAW WG to evaluate, but just wanted to point it out).
Comment (2022-04-19)
# COMMENTS

## Section 1

As Erik Kline, please use RFC 8200 as a reference to IPv6.

The last two paragraphs are more a liaison statement of the ICAO than an integral part of an IETF stream document.

## Section 2

It is not really a terminology section but rather an acronym list. I.e., suggest renaming this section ?

## Section 5.2.5

Some explanations on how positioning can be done in the absence of GNSS would be welcome.

## Section 8.2

Suggest to also add the well-known SNMP & NETCONF as the acronyms are more often known than their expansions.

## Section 9.2

Should the section title include the word "security" ?

## Section 9.3

"Currently" won't age well ;-) Suggest to write "Work in 2022 includes..."

## Section 9.5.2

What is "ICAO unique address of an aircraft" ? Is it a layer-2 address ?


# NITS  

## Section 1
s/area of the world, that suffers/area of the world that suffers/ ?
s/east- and west- cost of the US/East and West Coast of the USA/ ?

and many other typos... Strongly suggest using a tool to improve the grammar / spelling

John Scudder Yes

Erik Kline No Objection

Comment (2022-04-18)
# 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/?

Lars Eggert No Objection

Comment (2022-04-20)
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.

Robert Wilton No Objection

Comment (2022-04-20)
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

Zaheduzzaman Sarker No Objection

Comment (2022-04-21)
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.

Francesca Palombini No Record

Martin Duke No Record

Murray Kucherawy No Record

Paul Wouters No Record

Warren Kumari No Record