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

[Robert Moskowitz <[e-mail]>]

Per Wikipedia:

"Multilateration is a technique for determining a stationary or moving 
"vehicle's" position based on measurement of the times of arrival (TOAs) 
of virtually any type (physical phenomenon) of energy wave having a 
known waveform and propagation speed when traveling either from 
(navigation) or to (surveillance) multiple system stations."

1st modern use was WW1 audio multilateration of artillery.  Anyway that 
is what I was once told...

I guess with this audience, that should be defined...

I will go over your comments and get back to you.

Bob

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!)
>
> 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.
>
> s1, para 3: s/are updated, these/are updated, but these/
>
> s3.2: Query:  Is there are good reason for leaving the HIT/HHIT Suite ID value
> 4 unused?
>
> 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.
>
> 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./
>
> 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).
>
> s4, para 2: 'The 2022 forthcoming ...' is not future proof. Suggest adding an
> RFC editor note to remove '2022 forthcoming' during editing.
>
> s5, para 1: s/does not intent/does not intend/
>
> s5:  The examples should be using the 'example' top level domain.
>
> 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)'.
>
> s8.1,  last item:  'False?': A decision needs to be taken on what value should
> be here.
>
> s9.1, para 4:  Is 'multilateration' sufficiently well understood to be used
> without explanation?
>
> App A, para 1: s/EU/The EU/ (2 places).
>
>
>