Skip to main content

Last Call Review of draft-ietf-drip-rid-24

Request Review of draft-ietf-drip-rid
Requested revision No specific revision (document currently at 37)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2022-05-11
Requested 2022-04-27
Authors Robert Moskowitz , Stuart W. Card , Adam Wiethuechter , Andrei Gurtov
I-D last updated 2022-05-10
Completed reviews Secdir Early review of -07 by Magnus Nyström (diff)
Iotdir Early review of -07 by Michael Richardson (diff)
Intdir Last Call review of -26 by Pascal Thubert (diff)
Iotdir Last Call review of -24 by Brian Haberman (diff)
Genart Last Call review of -24 by Elwyn B. Davies (diff)
Assignment Reviewer Elwyn B. Davies
State Completed
Request Last Call review on draft-ietf-drip-rid by General Area Review Team (Gen-ART) Assigned
Posted at
Reviewed revision 24 (document currently at 37)
Result Ready w/nits
Completed 2022-05-10
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


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

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:

Minor issues:

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).