Re: [Gen-art] [Drip] Genart last call review of draft-ietf-drip-rid-24
Robert Moskowitz <rgm@labs.htt-consult.com> Wed, 11 May 2022 01:14 UTC
Return-Path: <rgm@labs.htt-consult.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97015C159487; Tue, 10 May 2022 18:14:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.753
X-Spam-Level:
X-Spam-Status: No, score=-8.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.857, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYBHMtxpEW6w; Tue, 10 May 2022 18:14:03 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77B30C159486; Tue, 10 May 2022 18:14:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 4A67162569; Tue, 10 May 2022 21:13:14 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cPzmn6TT+Rc3; Tue, 10 May 2022 21:13:05 -0400 (EDT)
Received: from [192.168.160.11] (unknown [192.168.160.11]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 45E1E6247F; Tue, 10 May 2022 21:12:57 -0400 (EDT)
Message-ID: <7934cf85-98d7-8cd0-942f-b8244222ff7c@labs.htt-consult.com>
Date: Tue, 10 May 2022 21:13:40 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0
Content-Language: en-US
To: Elwyn Davies <elwynd@dial.pipex.com>, gen-art@ietf.org
Cc: draft-ietf-drip-rid.all@ietf.org, last-call@ietf.org, tm-rid@ietf.org
References: <165219993739.31003.15943195085450775813@ietfa.amsl.com>
From: Robert Moskowitz <rgm@labs.htt-consult.com>
In-Reply-To: <165219993739.31003.15943195085450775813@ietfa.amsl.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/P3K5Xma0XssX7cLfsLsvPuJBRA8>
Subject: Re: [Gen-art] [Drip] Genart last call review of draft-ietf-drip-rid-24
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 May 2022 01:14:06 -0000
On 5/10/22 12:25, Elwyn Davies via Datatracker wrote: > Reviewer: Elwyn Davies > Review result: Ready with Nits > > 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-drip-rid-24 > Reviewer: Elwyn Davies > Review Date: 2022-05-10 > IETF LC End Date: 2022-05-11 > IESG Telechat date: Not scheduled for a telechat > > Summary: > Ready with nits. I can't speak for the robustness of the security choices but > the document is well written apart from a couple of pieces of deep jargon that > may need explanation for more naive readers (notably multilateration - > definitely a new one on me!) Multilateration occurs once in the draft, sec 9.1. It is a main part of draft-moskowitz-crowd-sourced-rid where I have the definition: Multilateration: Multilateration (more completely, pseudo range multilateration) is a navigation and surveillance technique based on measurement of the times of arrival (TOAs) of energy waves (radio, acoustic, seismic, etc.) having a known propagation speed. Do you think it should be added here in the definitions section? I really don't want to pull it from 9.1, and I don't see adding this whole definition into 9.1. Multilateration is an important tool in aviation traffic management. Oh and this is fundamental to GPS. I do expect, at some point soon, that crowd-sourced-rid will become a wg draft... > > Major issues: > None > > Minor issues: > None > > Nits/editorial comments: > Abstract/s1: The term 'self-asserting IPv6 address' is defined in Section 3 > of the DRIP architecture. AFAICS 'self-asserting' is novel terminology, at > least in this context, and I think it would be good to point to the > architecture in the Abstract and to make it a little clearer that the term > self-asserting (IPv6 address) is defined in the architecture - I missed that on > first reading - as well as the idea of HHITs. para 2 of the Intro references Architecture, but what do you think of: This document describes the use of Hierarchical Host Identity Tags (HHITs) as self-asserting IPv6 addresses, as described in the DRIP Architecture, and thereby a trustable identifier for use as the Unmanned Aircraft System Remote Identification and tracking (UAS RID). > > s1, para 3: s/are updated, these/are updated, but these/ Fixed for -25 > > s3.2: Query: Is there are good reason for leaving the HIT/HHIT Suite ID value > 4 unused? Because draft-moskowitz-hip-new-crypto has it as '5', and that draft (which will be needed for secure-nrid-c2) proposed 5 (and 6) because a dead draft used 4... I will see if I can move them all up. I do have to check with implementors to see if there are any issues that I am forgetting. > > s3.2, s3.4.2, s8.2 and s8.4: After the definition of the EdDSA/cSHAKE128 value > '(RECOMMENDED)' is appended. What or who is this recommendation aimed at? > The users of the specification or IANA in relation to TBD3? The registry > doesn't seem to have scope for recording this recommendation. If it is aimed > at users, I think there should be words to this effect in s3.2 and it is > probably not relevant in s3.4.2. To implementors. This is a copy from 7401, and maybe it is no longer the style? From 7401: HIT Suite Four-bit ID Eight-bit encoding RESERVED 0 0x00 RSA,DSA/SHA-256 1 0x10 (REQUIRED) ECDSA/SHA-384 2 0x20 (RECOMMENDED) ECDSA_LOW/SHA-1 3 0x30 (RECOMMENDED) Can someone provide guidance on current style for me? > > s3.4.1.1 and s8.4: Similar question regarding '(RECOMMENDED)'. > > s3.4, para 2: s/As such the following updates HIP parameters./The subsections > of this section document the required updates of HIP parameters./ Fixed. Thanks, I like this improved wording. > > s3.5.2.1, s3.5.3 and s3.5.4: I suggest adding a reference to the HITv2 archive > where the prefix 2001:20::'28 is allocated (3 places). is it enough to put in 3.5.2.1 a reference to sec 6, RFC7343? For HIPv2, the Prefix is 2001:20::/28 (Section 6 of [RFC7343]). 'Info' is zero-length (i.e., not included), and OGA ID is 4-bit. > > s4, para 2: 'The 2022 forthcoming ...' is not future proof. Suggest adding an > RFC editor note to remove '2022 forthcoming' during editing. the doc is in ASTM editor's hands now. But we all know about final editing processes! Does this resolve your concern: Note to RFC Editor: This, and all references to F3411 need to be updated to this new version which is in final ASTM editing. A new link and replacement text will be provided when it is published. > > s5, para 1: s/does not intent/does not intend/ fixed > s5: The examples should be using the 'example' top level domain. It was the authors' intent to show an example of an aviation related top level domain. Is such an intention incompatible with FQDN examples? Note that icao.int IS the current ICAO domain. It is not established, at this time, that DETs will be in this TLD. It IS being discussed in ICAO, and the authors are part of that discussion. > s5, para 7: The phrase 'If we assume a prefix of 2001:30::/28,' is confusing. > This prefix is the one the document is asking IANA to allocate for the HHITs so > I suggest 'Using the allocated prefix for HHITs TBD6 [suggested value > 2001:30::/28] (See Section 3.1)'. Done > s8.1, last item: 'False?': A decision needs to be taken on what value should > be here. I check in 7343, sec 6 and there 'False' is used. I don't know this part of IANA considerations and need guidance. > s9.1, para 4: Is 'multilateration' sufficiently well understood to be used > without explanation? In aviation. See beginning of the reply. I am defining it in draft--drip-crowd-sourced-rid > App A, para 1: s/EU/The EU/ (2 places). Done And thank you for your review. Bob
- [Gen-art] Genart last call review of draft-ietf-d… Elwyn Davies via Datatracker
- Re: [Gen-art] [Drip] Genart last call review of d… Robert Moskowitz
- Re: [Gen-art] [Drip] Genart last call review of d… Robert Moskowitz
- Re: [Gen-art] [Drip] Genart last call review of d… Robert Moskowitz
- Re: [Gen-art] [Drip] Genart last call review of d… Elwyn Davies