[Drip] Re: AD review of draft-ietf-drip-registries-23

["Eric Vyncke (evyncke)" <[e-mail]>]

Adam,

Thank you for the PR, this represents a lot of work during your WE.

For information, I have not seen anything on my points 14) and 25)

I also noticed that there are still “Apex” rather than “apex” in the PR and I forgot to mention s/i.e./i.e.,/

Regards

-éric

From: Adam Wiethuechter <[e-mail]>
Date: Monday, 3 March 2025 at 05:54
To: Eric Vyncke (evyncke) <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: AD review of draft-ietf-drip-registries-23
Eric,

Thank you for your AD review. A branch (and PR) has been made on the GitHub [1] if you wish to track the changes being made commit by commit (numbered to align to your comments).

As of this email the following issues have not been addressed: 1, 22, 34, 36, 39, 40, 41, 42, 43, 48.
I hope I can get something out before the deadline, even if it is the current working copy as of this evening as we work through the remaining issues.

[1] https://github.com/ietf-wg-drip/draft-ietf-drip-registries/pull/48<https://github.com/ietf-wg-drip/draft-ietf-drip-registries/pull/48>
--------
73,
Adam T. Wiethuechter
Software Engineer; AX Enterprize, LLC
________________________________
From: Eric Vyncke (evyncke) <evyncke=[e-mail]>
Sent: Wednesday, February 26, 2025 5:20 AM
To: [e-mail] <[e-mail]>
Subject: [Drip] AD review of draft-ietf-drip-registries-23


Adam, Jim, and DRIP WG,



Thanks for your patience waiting for this AD review 😊 and thanks for the work done, we are now close to achieve all work items of our charter.



As usual, I will proceed with the next steps of the publication process once all the points below have been addressed (e.g., by an email answer and/or a revised I-D).



1.      Choice of  the “Public Information Registries” wording is possibly too close to “Public Interest Registry”. Any chance to change the wording ? or at least avoid the capitalization.

2.      Section 1, inserting the figure 4 of RFC 9434 will help the readers

3.      Section 1 s/ (DIME) which manages/ (DIME), which manages/ ?

4.      Section 1, please do not use “we” as it is ambiguous...authors ? DRIP WG ? IETF community ?

5.      Section 1.1, even if obvious, please add an informative reference to DNS

6.      Section 1.1, s/ DIME's/ DIMEs/ AFAIK it is better to use this plural form

7.      Section 1.1, no need to expand DNS twice

8.      Section 1.1, is there a reason why ` Public Information` is capitalized ?

9.      Section 1.1, s/ AAA mechanisms, Personally/ AAA mechanisms*;* Personally/

10.  Section 1.1 PII is only used once further down, then let’s rather use the expanded PII in section 2.2

11.  Section 1.1 s/ are not described/ are not specified/ this I-D is intended to be a PS

12.  Section 1.2 is there any informative reference for ` registrant-registrar-registry model`? Having one graphic could be helpful.

13.  Section 1.2 `In DRIP,` is rather vague, please use a reference to RID/DET

14.  Section 1.2 should `zone apex` be defined somewhere for the non-DNS readers ?

15.  Section 1.2, add informative reference to WHOIS & RDAP

16.  Section 1.2, unsure whether paragraph 3 is useful, suggest deleting it (possibly also paragraph 4) or change the section title and add introduction text to indicate “choice of DNS model for DIMEs” (or similar)

17.  Section 1.2, add a reference to the 2001:0030:: DETs prefix when talking about 3.0.0.1.0.0.2.ip6.arpa

18.  Section 1.2, expand CAA and HHIT (for the later, add a reference), HHIT is also defined in section 3 (avoid duplication then)

19.  Section 1.2, ` to need a unique authentication token` or simply credentials ?

20.  Section 1.2, s/ , the scope of its activities are usually/ , the scope of its activities *is* usually/

21.  Section 1.2, s/However/However,/

22.  Section 2, should probably appear earlier in the I-D, e.g., before 1.2`

23.  Section 3 s/ It's format is/ Its format is/

24.  Section 3, please expand RAA before first use

25.  Section 3, s/28-bits/28 bits/ ?

26.  Section 3, be more assertive in ` A subset of RAAs have preallocations`, e.g., “this document has preallocated...”

27.  Section 3, s/Apex/apex/

28.  Section 3, any reason why ` National Matters` is capitalized ?

29.  Section 5.1, figure 2 seems to indicate that the RRtype always returns an answer aligned on 32-bit boundary. Please be explicit in the text.

30.  Section 5.1, a reference to figure 2 should appear in the text even if obvious

31.  Section 5.1.1, please add a normative reference to base64

32.  Section 5.1.2, please make a link between the CDDL attribute (e.g., “type”) and the legend below (e.g., “HHIT Entity Type”)

33.  Section 5.1.2, s/ In some cases it/ In some cases, it/

34.  Section 5.1.2, having a standard field (abbreviation) in a PS with ` The specific contents of this field are not defined here.` is not correct IMHO.

35.  Section 5.2.2, please indicate which section of ASTM F3411

36.  Section 5.2.2, once again a normative reference behind a paywall. Can the authors/WG ensure that IETF Last Call/IESG reviewers will have a free access to the ASTM standard ?

37.  Section 6.1, s/DRIP Prefix/DET Prefix/

38.  Section 6.1, s/Expert/Experts/

39.  Section 6.1, there is a missing “to xyz” in ` This document requests that the IANA delegate the 3.0.0.1.0.0.2.ip6.arpa domain`

40.  Section 6.2.1, why is the experimental range reserved to DRIP WG (especially when DRIP WG will be closed) same comment about the last paragrah, suggest to also add a FCFS range

41.  Section 6.2.1 it is unclear whether IANA should copy the Github CSV in the registry, please be explicit

42.  IANA expert review, RFC 8126 section 4.5 also requires clear guidance for the expert

43.  Section 7.1, all “SHOULD” should come with the consequences of by-passing the SHOULD guidance

44.  Section 7.1, DPS acronym is never used, please remove

45.  Section 7.2, please explain ` until it is required`

46.  Section 8, being contributors means to have provided text and not only ideas/reviews else it is about ackowledgements

47.  Section 9.2, ISO 3166 must be normative as well as ASTM F3411, CBOR, WHOIS, RDAP, ...

48.  More generally, some examples of reverse names/mapping for a DET would be a plus



Hope this helps improving the document and making its path to publication easier and faster



Regards



-éric