Re: [Raw] [Last-Call] Genart last call review of draft-ietf-raw-ldacs-10

Lars Eggert <lars@eggert.org> Wed, 20 April 2022 12:29 UTC

Return-Path: <lars@eggert.org>
X-Original-To: raw@ietfa.amsl.com
Delivered-To: raw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54DD3A0FB0; Wed, 20 Apr 2022 05:29:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uq5E7IvUSgTw; Wed, 20 Apr 2022 05:29:50 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 088D43A0F74; Wed, 20 Apr 2022 05:29:49 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:9180:dfcf:fc10:7f39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 403511DA90B; Wed, 20 Apr 2022 15:29:38 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1650457778; bh=FMVQRS2PLVFV5DiBMe4DAYZiJXsiCBl3UK4JqDHklhI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=idLVZjsIke6ObzTJHKi0bvVKd0H2rlfuZoWrhx69fLO2Xm4T/Z6xdc8Qa2iKOSxHc /lL5Q6mY/3eZckZf/HHU147In1XXfvu0ChbvDyLBMzXj9dY0dLaWLXdxU0yn2JUd0h RKIQPiK8FXipNnk3WFXQMKTq07eNnjxqKDt5asCs=
Content-Type: multipart/signed; boundary="Apple-Mail=_5F986BE9-CEEC-4C93-9E8E-F1F4A1A01F13"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
From: Lars Eggert <lars@eggert.org>
In-Reply-To: <164878144157.4375.2911687927753975757@ietfa.amsl.com>
Date: Wed, 20 Apr 2022 15:29:26 +0300
Cc: General Area Review Team <gen-art@ietf.org>, last-call@ietf.org, raw@ietf.org, draft-ietf-raw-ldacs.all@ietf.org
Message-Id: <BD6C2AD8-9871-4B22-B6F4-94819955A416@eggert.org>
References: <164878144157.4375.2911687927753975757@ietfa.amsl.com>
To: Dale Worley <worley@ariadne.com>
X-MailScanner-ID: 403511DA90B.A40FA
X-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/raw/YpWYZQQ8SSFWdHTQPz2lu6s0pvI>
Subject: Re: [Raw] [Last-Call] Genart last call review of draft-ietf-raw-ldacs-10
X-BeenThere: raw@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: reliable and available wireless <raw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/raw>, <mailto:raw-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/raw/>
List-Post: <mailto:raw@ietf.org>
List-Help: <mailto:raw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/raw>, <mailto:raw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Apr 2022 12:29:55 -0000

Dale, thank you for your review. I have entered a No Objection ballot for this document.

Lars


> On 2022-4-1, at 5:50, Dale Worley via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: Dale Worley
> Review result: Ready with Issues
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> 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.
> 
> Issues:
> 
> There are a number of minor editorial issues listed below.  But the
> one issue that might be significant is the lack of detail about how
> LDACS is expected to utilize the IP infrastructure as defined by the
> IETF.  Strictly speaking, this document is an informational document
> about a particular data-link layer, and in that sense, layer 3 is out
> of scope, but what the IETF audience would be most informed by would
> be how the data-link layer integrates with IPv6 and existing IPv6
> protocols.
> 
> 3.  Motivation and Use Cases
> 
>   It refers to the mostly
>   proprietary exchange of data between the aircraft of the airline, its
>   operation centers, and its service partners.
> 
> Not being in the airline industry, my initial reading of this was that
> aircraft had operation centers and service partners.  Perhaps this
> could be clarified for the naive as
> 
>   It refers to the mostly
>   proprietary exchange of data between the aircraft of the airline and
>   the airline's operation centers and service partners.
> 
> 3.1.  Voice Communications Today
> 
>   Voice links are used for Air/Ground (A/G) and Air/Air (A/A)
>   communications. The communications equipment is either ground-based
>   working in the High Frequency (HF) or VHF frequency band or
>   satellite-based.
> 
> By comparison, 5.2.2 states that A/A communication is only considered
> as a possible extension for LDACS, which seemed surprising to read at
> that point.  This could be clarified if 3.1 noted that LDACS is not
> currently planned to implement A/A communication, even for voice.
> 
> 5.2.  Application
> 
>   (sending Ground Based Augmentation System (GBAS) correction data)
> 
> Naively, this reads as "data to correct GBAS data".  Perhaps clearer
> as "Ground Based Augmentation System (GBAS) data to correct GNSS" or
> even just "GNSS correction data" as is used in 5.2.3.
> 
> 7.  Characteristics
> 
>   Achieving the stringent continuity, availability, and integrity
>   requirements defined in [DO350A] will require the specification of
>   layer 3 and above mechanisms (e.g. reliable crossover at the IP
>   layer). Fault management mechanisms are similarly undefined.
> 
> This limitation seems to be strictly correct, given that this document
> is only scoped to the data link layer.  But it would be useful to the
> reader to give an outline of how IP interacts with the data link
> layer.  In particular, are the packets sent over the link IPv6 packets
> (perhaps encoded in some special way)?  What is the general IP
> addressing architecture of the LDACS sub-network (i.e. AS, GS, and AR)?
> Similarly, what existing protocols (if any) are expected to reach the
> AS?  These latter points are the ones that most directly intersect the
> IETF's business.
> 
> 7.3.  LDACS Protocol Stack
> 
>    The last entity resides within the sub-network layer: the
>    Sub-Network Protocol (SNP).
> 
> Given the context of this sentence, "the last entity" could refer to
> either functional block five, or to item (4) in the immediately
> preceding list (the LME).  This would be less ambiguous as "The fifth
> block ...".
> 
>   The LDACS network is externally
>   connected to voice units, radio control units, and the ATN network
>   layer.
> 
> How does this mesh with the architecture shown in Figure 1 of 7.1,
> which shows only the connection of LDACS to ATN?
> 
> --
> 
> Figure 2 doesn't show the positioning of the VI functional block.
> 
> 8.2.  Layer 1 and 2
> 
> The figures in this section have very little information for a diagram
> of a frame structure.  E.g. the length of an SF is specified (240ms =
> 2000 symbols), but the lengths of MF, BCCH, and RACH are not
> specified.  Similarly, the lengths of the divisions of the MF aren't
> specified.  The layout and size of the transmission time slots aren't
> discussed.
> 
>   FL and RL boundaries are aligned in time (from the GS perspective)
> 
> Given that a cell can be as large as 200 nautical miles, which is 1235
> microseconds at light-speed, and a symbol is 120 microseconds, while
> the FL and RL frame structures are synchronized at the GS, they can be
> desynchronized by ~20 symbols at the AS.  This seems to be handled by
> propagation guard times but it would be useful to describe the guard
> time placements in the frame structures.
> 
> 8.3.  Beyond Layer 2
> 
>   This means proliferating the number of terrestrial ground
>   stations. However, the scarcity of aeronautical spectrum for data
>   link communication (in the case of LDACS: tens of MHz in the
>   L-band) and the long range (in the case of LDACS: up to 200
>   nautical miles) make this quite hard.
> 
> Naively, the available bandwidth for the LDACS system as a whole in a
> geographical region should scale with the number of cells.  The above
> statement suggests that is not true in LDACS, and it would be useful
> to explain why.
> 
> 9.5.1.  Entities
> 
> The document seems to be using "LDACS access network" in 9.5.1 and
> "LDACS Sub-Network" in Figure 1 of 7.1 to mean the same thing.
> Neither term is defined in 2.  Can these be unified into one term?
> Would it help to insert it in the glossary?
> 
> [END]
> 
> 
> 
> --
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call