Re: [Raw] Éric Vyncke's Discuss on draft-ietf-raw-ldacs-10: (with DISCUSS and COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Hello Nils,

Thank you for your prompt reply and, please accept my apologies for belated reply (I took some days off)...

With all your proposed changes, I am planning to clear my DISCUSS once a revised I-D is uploaded.

See below for EV> for additional non-blocking comments.

Regards

-éric

-----Original Message-----
From: "[e-mail]" <[e-mail]>
Date: Thursday, 21 April 2022 at 12:29
To: Eric Vyncke <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Pascal Thubert <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: AW: Éric Vyncke's Discuss on draft-ietf-raw-ldacs-10: (with DISCUSS and COMMENT)

    Dear Éric Vyncke,

    Thank you for your comments. Please find out answers inline below.

    Best,
    Nils Mäurer

    -----Ursprüngliche Nachricht-----
    Von: Éric Vyncke via Datatracker <[e-mail]> 
    Gesendet: Dienstag, 19. April 2022 10:42
    An: The IESG <[e-mail]>
    Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
    Betreff: Éric Vyncke's Discuss on draft-ietf-raw-ldacs-10: (with DISCUSS and COMMENT)

    Éric Vyncke has entered the following ballot position for
    draft-ietf-raw-ldacs-10: Discuss


    ----------------------------------------------------------------------
    DISCUSS:
    ----------------------------------------------------------------------

    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)?

    - Reply: Working on the "IPv6 over LDACS" specification was our original motivation to approach IETF, so the plan is to work on it inside an IETF WG. Aeronautical data traffic over LDACS will be routed via the Aeronautical Telecommunications Network (ATN)/Internet Protocol Suite (IPS) for safety-critical IPv6 communications in aviation. The current version specifying the ATN/IPS (ICAO Doc 9896 Edition 3) is considering LISP for mobility and multilink functionality (ICAO has approach IETF about drafts draft-ietf-lisp-rfc6830bis and draft-ietf-lisp-rfc6833bis). This demonstrates, that ICAO is actively seeking out the IETF support, and believe a similar cooperation is considerable for specifying exactly how IPv6 traffic is translated to the data-link layer below i.e., LDACS (or any other Future Communications Infrastructure (FCI) data-links such as AeroMACS, Iridium Certus and Inmarsat SB).

EV> the above explanation could be summarized into "The ICAO plans to work with the IETF to add the support of IPv6 over LDACS" (or something similar) and added into the text.

    ## 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).

    - Reply: As mentioned above, ATN/IPS is considering LISP as mobility and multilink functionality, however also PMIPv6 (see my response to Carlos Bernardos) is currently talked about. Since this point is unclear at the moment, we will investigate and come back to you with a detailed answer.

EV> as above, adding some text in the document "ICAO will work with the IETF on this multi-homed mobile IPv6 networks".


    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------

    # 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.

    - Reply: We will use RFC 8200 as reference for IPv6 and move explanations about ICAO involvement in LDACS the appendix for the interested reader.

    ## Section 2

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

    - Reply: We will rename it to "Acronyms".

    ## Section 5.2.5

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

    - Reply: LDACS can be used as terrestrial navigation alternative ( Alternative Positioning Navigation and Timing (APNT)). As LDACS is a cellular system, and current cell planning over Europe shows about 84 LDACS cells to be sufficient, if more than three Ground Stations (GS) are visible by the aircraft, via knowing the exact positions of these and having a good channel estimation (which LDASC does due to numerous works mapping the L-band channel characteristics) it is possible to calculate the position of the aircraft via measuring signal round-trip times to each GS. In flight trials in 2019 with one aircraft (and airborne radio inside it) and just four GS, we demonstrated navigation feasibility within the footprint of all four GS with a 95th percentile position-domain error of 171.1m. As such LDACS can be used totally independent of GNSS as navigation alternative with way smaller position-domain errors with more deployed GS. We will add a paragraph explaining that in the draft.

EV> cool not only about the technology itself but also adding a paragraph on this topic.

    ## Section 8.2

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

    - Reply: We will add them.

    ## Section 9.2

    Should the section title include the word "security" ?

    - Reply: We will add the word "security" here.

    ## Section 9.3

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

    - Reply: Agreed. :-) We will change it accordingly.

    ## Section 9.5.2

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

    - Reply: ICAO assigns a unique 24bit address to each and every aircraft and until now (via the "plain old" Aircraft Communications Addressing and Reporting System (ACARS) and the ATN/Open Systems Interconnection (OSI) from the 90s), addressing from/to the aircraft radio actually worked via this specific address. If you have a look at the ACARS system in a commercial airplane (unfortunately I only know their position in a Lufthansa Airbus 320 - there it is installed right in the middle between CPT and FO) - the radio is configured to be addressed by the A/C ICAO code, which is exactly that 24bit address. This unique address is used in the LDACS protocol for cell entry/exit purposes, and is also incorporated in the IPv6 address the following way: ICAO prefix 16bit, Aircraft Type (Operator based) 4 bit, Operator Code 16 bit, Aircraft ID 24bit, Application Type 4bit. We will clarify this in the draft.

EV> just wondering whether it is an "address" or an "ID" in this case... I understand that this is the 'good old' ICAO 24-bit notably used on transponders mode S and that ICAO uses "address" for this concept. May I suggest to rephrase "ICAO unique address of an aircraft" into "the 24-bit ICAO identifier of an aircraft"  ? And add a reference for this 24-bit 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

    - Reply: We will use a better spell-checking and grammar tool in future updates.