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

[Elwyn Davies <[e-mail]>]

Hi, Bob.

Sorry for the tardy reply.  Thanks for the responses, and, yes, I think 
the changes clear up the nits I identified.  Now good to go.

Cheers,
Elwyn

On 16/05/2022 13:32, Robert Moskowitz wrote:
> 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
>>
>
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art