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 <paul.hoffman@xxxxxxxxx> wrote:
Thanks for your review.
On Aug 2, 2024, at 07:06, Dan Romascanu via Datatracker <noreply@xxxxxxxx> 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
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
