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

[Stu Card <[e-mail]>]

Thanks Eric!

Only 1 quick response from me just now.

Public Information Registry & Private Information Registry were defined as part of the DRIP Architecture in RFC 9434. It would be confusing to rename them now.

Adam & I have an employer mandatory thing through Friday close of business, then can return attention to this draft.

Sent from my Verizon, Samsung Galaxy smartphone
Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Eric Vyncke (evyncke) <evyncke=[e-mail]>
Sent: Wednesday, February 26, 2025 5:20:18 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