[Gen-art] Re: [Ext] Genart last call review of draft-ietf-dnsop-rfc7958bis-03

[Dan Romascanu <[e-mail]>]

Hi Paul,

Thank you for your quick response. I am fine with your answers. I am
wondering whether adding some text clarifying the two minor issues would
help.

Regards,

Dan



On Sat, Aug 3, 2024 at 2:52 AM Paul Hoffman <[e-mail]> wrote:

> Thanks for your review.
>
> On Aug 2, 2024, at 07:06, Dan Romascanu via Datatracker <[e-mail]>
> wrote:
>
> > Summary:
> >
> > The document is clear and detailed in all its technical aspects. I have
> two
> > issues that I would suggest to be addressed before approval. If they are
> > already addressed indirectly I would be glad to be pointed to the text. I
> > categorized them as Minor, as they probably do not impact
> interoperability
> > within the same version of the mechanism.
> >
> > Major issues:
> >
> > Minor issues:
> >
> > 1. Section 1.2 includes a detailed list of changes from RFC 7985 which
> is fine.
> > What I am missing, however, is a clear description of the motivation
> that led
> > to the update. Was that to include the content of the Errata? Was it
> because of
> > operational or security problems in the deployment? Something else.
>
> The initial motivations were a significant errata, and also requests for
> two new features (the PublicKey entity and XML comments).
>
> > 2. Is there a requirement for backwards interoperability with the format
> and
> > publication mechanisms described in RFC 7958.
>
> Somewhat. DNS has a backwards-compatibility problem as strong as most
> other parts of the Internet protocols. The assumption in this version is
> that a relying party who is reading the trust anchor file is using a normal
> XML processor (so it won't barf on XML comments) and that the processor can
> handle new entities if given a new RELAX NG schema.
>
> > If yes, how is this ensured?
>
> It cannot be. If software that retrieves a file with the extended format
> fails, it will not have any trust anchors. This would hopefully be noticed
> by the operator.
>
> > In
> > any case, what is IANA instructed to do with the old records?
>
> There are no such instructions. There is only one URL in the RFC and
> draft, for the current trust anchor file.
>
> > Nits/editorial comments:
> >
> > Section 1.2 mentions 'Added an IANA Considerations section' as a change
> from
> > RFC 7598. Actually there is an IANA Considerations section in RFC 7598.
> So
> > probably what was meant was probably 'Updated the RFC Considerations
> Section'.
>
> Good catch; fixed.
>
> --Paul Hoffman
>
>