Re: [Gen-art] [Drip] Genart last call review of draft-ietf-drip-rid-24

[Robert Moskowitz <[e-mail]>]

Elwyn,

I believe your comments are the only opens left.  Does this response and 
the current drip-rid-26 address your points?

Note that the question sec 8.1 was addressed by IANA and is reflected in 
-26.

Thank you.

Bob

On 5/10/22 21:13, Robert Moskowitz wrote:
>
>
> 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
>