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.hoff...@icann.org> wrote: > Thanks for your review. > > On Aug 2, 2024, at 07:06, Dan Romascanu via Datatracker <nore...@ietf.org> > 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 > >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
