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

Hi James,

Thanks for the review. Please see inline my responses as well as the
changes below:

https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/commit/074ff71844b076b6e83ba8e0134a224b5f5617f9

Yours,
Daniel

On Thu, Nov 24, 2022 at 2:07 AM James Gannon via Datatracker <
noreply@ietf.org> wrote:

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

That is an interesting comment. In one part SHOULD  / MUST are expected to
provide some sort of priority. We could eventually as I think you are
suggesting have our own way to prioritize the recommendations, but I am not
sure we will be able to make it, so I am inclined to prefer staying with
the maybe large categories created by SHOULD/MUST and let the
operational team to select what is appropriated to them according to their
deployments and policies. I propose to add the following sentence:
It is up to the DRO to determine their applicability

I think this addresses your concern.

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

I think it describes pretty well what the problem is, so I think it might
be preferred to  indicate it as an example. I propose the following lines:

With Raspberry Pi for example, when these devices are re-plugged their time
is res
et to some initial values like (January 1, 1970 for example) until they get
re syn
chronized  via NTP.

>     -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
>
> Current recommendations for DRO mostly describe how to handle the TA, but
do not provide some recommendations regarding which TA should be trusted.
I do see a slight difference between recommending how to operate the set of
TA and recommending what should be trusted. The recommendation in question
is also more addressed to implementers as DRO. As result, I agree that the
use of normative language  may be considered, but we probably do not want
to issue a specific DRO recommendation. I propose to replace
s/recommended/RECOMMENDED/. I hope this addresses your concern.

    -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?
>
> Configuration Generation and DNSSEC Resolver Instantiation could be merged
but I do think that it increases clarity of the purpose to have different
sections.

> 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
>
> The document is intended to be read to non DNSSEC experts and we believe
the context being provided will be helpful to the target audience
especially to help them balance the various trade-off.

Overall comment: Considering that there are no actual requirements in the
> draft
> consider retitling it from -requirements to -reccomendations.
>
>
Correct. There was only one word that has been changed. The name of the
file cannot be changed, but I agree it would have been more appropriate.
Initially we were targeting some requirements for implementations, and
latter changed to recommendations for DRO which was what we are aiming at.

> 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.
>
> yes. We started this document as I was working for an ISP. Currently we
are providing such guidance so MNO can deploy DNSSEC for some of our
products.

> 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.
>
 We did have such reviews - of course more such reviews are welcome. I can
only agree with you.

>
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>

-- 
Daniel Migault
Ericsson