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
- [Raw] Genart last call review of draft-ietf-raw-l… Dale Worley via Datatracker
- Re: [Raw] [Gen-art] Genart last call review of dr… worley
- Re: [Raw] Genart last call review of draft-ietf-r… Nils.Maeurer
- Re: [Raw] [Last-Call] Genart last call review of … Lars Eggert