On Tue, May 5, 2020 at 12:02 PM Daniel Migault <mglt.i...@gmail.com> wrote:
> Hi Bob, > > I apology the previous email has just been sent unexpectedly. > > Thanks for the comments. The new version of the file is available here [1] > and a diff is available at [2]. > > I propose the following text for clarification. Feel free to let me know > if that addresses your concern. > > OLD: > Not updating the configuration file prevents a failed synchronization to > to the absence of write permission that are hardly in the control of the > software." > > NEW > Avoiding the configuration file to be updated prevents old configuration > file to survive to writing error on read-only file systems. > I understand that we do not want the system to fail due to missing write permissions. It seems like this could be handled two ways: 1. Just keep in memory, and do not try to write a new configuration. That works, until the old trust anchor is removed, then it fails if the service is restarted. 2. Attempt to write a new configuration, but keep going even if that fails. If the write succeeds, then this works even after the old trust anchor is removed. I would prefer the second method. I think that is what some software already does. (BIND?) -- Bob Harold > > Please inline other comments. > > Yours, > Daniel > > [1] > https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/blob/master/draft-mglt-dnsop-dnssec-validator-requirements.mkd > [2] > https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/commit/f8ab674b12442aff6ba3c72a3ca8f795f24b2df9#diff-c7cc8f0bdd4d7cce2082828d70d2bf35 > > > On Tue, May 5, 2020 at 11:52 AM Daniel Migault <daniel.migault= > 40ericsson....@dmarc.ietf.org> wrote: > >> Hi Bob, >> >> Thanks for the comments. The new version of the file is available here >> [1] and diff can be seen at [2]. >> >> I propose the following text. Does it clarify the concern ? >> Avoiding the configuration file to be updated prevents old configuration >> file to survive to writing error on read-only file systems. >> >> >> "Not updating the configuration file prevents a failed >> synchronization to to the absence of write permission that are hardly >> in the control of the software." >> >> <mglt> >> </mglt> >> >> [1] >> https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/blob/master/draft-mglt-dnsop-dnssec-validator-requirements.mkd >> [2] >> https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/commit/f8ab674b12442aff6ba3c72a3ca8f795f24b2df9#diff-c7cc8f0bdd4d7cce2082828d70d2bf35 >> >> ------------------------------ >> *From:* Bob Harold <rharo...@umich.edu> >> *Sent:* Monday, May 4, 2020 4:29 PM >> *To:* Daniel Migault <daniel.miga...@ericsson.com> >> *Subject:* Fwd: [DNSOP] The DNSOP WG has placed >> draft-mglt-dnsop-dnssec-validator-requirements in state "Call For Adoption >> By WG Issued" >> >> Minor nits: >> >> 7. Trust Anchor Related Recommendations >> >> Last sentence, last few words: >> "in section Section 8" > "in Section 8" >> >> <mglt> >> addressed >> </mglt> >> >> 7.2.1. Automated Updates to DNSSEC Trust Anchors >> >> "TA updates is" > "TA updates are" >> >> <mglt> >> addressed >> </mglt> >> >> "but due to human" > "due to human" >> >> <mglt> >> addressed >> </mglt> >> >> 7.2.2. Automated Trust Anchor Check >> >> "Not updating the configuration file prevents a failed >> synchronization to to the absence of write permission that are hardly >> in the control of the software." >> >> <mglt> >> I propose the following text. Does it clarify the concern ? >> Avoiding the configuration file to be updated prevents old configuration >> file to survive to writing error on read-only file systems. >> </mglt> >> >> Seems confusing, please rewrite. >> >> "The TA can be queries" > "The TA can be queried" >> >> <mglt> >> addressed >> </mglt> >> >> "does not only concerns" > "does not only concern" >> <mglt> >> addressed >> </mglt> >> "if the mismatch result" > "if the mismatch resulted" >> <mglt> >> addressed >> </mglt> >> >> 8. Negative Trust Anchors Related Recommendations >> >> "disable the signature check for that key the time" > "disable the >> signature check for that key until the time" >> <mglt> >> addressed >> </mglt> >> >> "This does not prevents" > "This does not prevent" >> <mglt> >> addressed >> </mglt> >> "either an attack or a failure into" > "either an attack or a failure in" >> <mglt> >> addressed >> </mglt> >> 10.1. Automated Reporting >> >> "will take the appropriated steps" > "will take the appropriate steps" >> <mglt> >> addressed >> </mglt> >> -- >> Bob Harold >> >> >> ---------- Forwarded message --------- >> From: *Bob Harold* <rharo...@umich.edu> >> Date: Mon, May 4, 2020 at 4:28 PM >> Subject: Re: [DNSOP] The DNSOP WG has placed >> draft-mglt-dnsop-dnssec-validator-requirements in state "Call For Adoption >> By WG Issued" >> To: IETF DNSOP WG <dnsop@ietf.org> >> >> >> Looks useful, I will review. >> >> -- >> Bob Harold >> >> >> On Mon, May 4, 2020 at 3:13 PM IETF Secretariat < >> ietf-secretariat-re...@ietf.org> wrote: >> >> >> The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in >> state Call For Adoption By WG Issued (entered by Tim Wicinski) >> >> The document is available at >> >> https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/ >> >> > > -- > Daniel Migault > Ericsson >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
