Skip to main content

Early Review of draft-ietf-dnsop-dnssec-validator-requirements-01
review-ietf-dnsop-dnssec-validator-requirements-01-dnsdir-early-gannon-2022-11-23-00

Request Review of draft-ietf-dnsop-dnssec-validator-requirements
Requested revision No specific revision (document currently at 07)
Type Early Review
Team DNS Directorate (dnsdir)
Deadline 2022-11-28
Requested 2022-11-08
Requested by Warren "Ace" Kumari
Authors Daniel Migault , Edward Lewis , Dan York
I-D last updated 2022-11-23
Completed reviews Dnsdir Early review of -01 by James Gannon (diff)
Secdir Last Call review of -04 by Charlie Kaufman (diff)
Comments
This was requested at the DNSOP meeting by the chairs and Geoff.

Feel free to adjust date - I chose it at random.
Assignment Reviewer James Gannon
State Completed
Request Early review on draft-ietf-dnsop-dnssec-validator-requirements by DNS Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/dnsdir/0m_rHZo8cAmnXjGjecQLvE2YLM4
Reviewed revision 01 (document currently at 07)
Result On the Right Track
Completed 2022-11-23
review-ietf-dnsop-dnssec-validator-requirements-01-dnsdir-early-gannon-2022-11-23-00
Reviewer: James Gannon
Review Result: On the right track

As this is an early review (And also my first ietf review so please feel free
to offer feedback on its usefulness!) its a mix of general comments and some
more detailed comments on sections that from a non-DRO operator perspective
dont seem to be overly logical.

   - The recommendations do not come with the same level of requirements and
     some are likely to be required.  Other are optional and may be
     followed by more advanced DROs.

Suggestion to tighten up the language in this paragraph, if the authors wish to
assign priority to the reccomendations then they should do so, however if it is
up to the implementer to determine the applicability then state so clearly.

    - When these devices are re-plugged the initial time is set to January 1
    1970.

As this is not universally true it is not valuable or required context and
should be considered for removal.

    -Because of this, it is recommended that implementations make the root
   zone trust anchor obvious to the operator while still enabling
   configuration of general trust points.

If this is considered a RECCOMENDATION as per the document please use
consistent langugage and categorise it as with the other recs

    -7.1.3.  Configuration Generation

   The generation of a configuration file associated to the TA is
   expected to be implementation independent.  The necessity of tweaking
   the data depending of the software implementer or eventually the
   software version introduces a vector for configuration errors.

No action for a DRO is associated with this section. Consider need of section
or move to a general considerations section?

Overall comment: The document is quite verbose and "wordy" I would suggest for
a reccomendations document that the content is slimmed down to direct
reccomendations and any required context for implementors, rather than
extensive supporting information and general context

Overall comment: Considering that there are no actual requirements in the draft
consider retitling it from -requirements to -reccomendations.

Overall comment: For the document to be valuable its critical that these
reccomendations are actually aligned with the needs and practices of DROs, has
their input been considered in the drafting of these reccomendations.

Overall comment: I would suggest also requesting a review from a current DRO
operator to gain some domain specific feedback that may catch some operational
concerns that I may have overlooked.