[DNSOP] Dnsdir early review of draft-ietf-dnsop-dnssec-validator-requirements-01

James Gannon via Datatracker <noreply@ietf.org> Thu, 24 November 2022 07:07 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 155B2C14CF15; Wed, 23 Nov 2022 23:07:20 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: James Gannon via Datatracker <noreply@ietf.org>
To: dnsdir@ietf.org
Cc: dnsop@ietf.org, draft-ietf-dnsop-dnssec-validator-requirements.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 9.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <166927364007.46969.10243749372224772919@ietfa.amsl.com>
Reply-To: James Gannon <james@policywonk.xyz>
Date: Wed, 23 Nov 2022 23:07:20 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2q7t_iW2Am6FeXOyzUIDCChy0bk>
Subject: [DNSOP] Dnsdir early review of draft-ietf-dnsop-dnssec-validator-requirements-01
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Nov 2022 07:07:20 -0000

Reviewer: James Gannon
Review result: On the Right Track

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.