Re: [DNSOP] [IANA #1285116] expert review for draft-ietf-dnsop-dns-error-reporting (Underscored and Globally Scoped DNS Node Names)
> On 31 Oct 2023, at 23:38, Paul Wouters wrote: > > On Oct 31, 2023, at 19:17, Frederico A C Neves wrote: >> >> Dear David, >> >> Section 7 of the draft is sufficiently clear, precise, and complete. >> >> This registration at the time it is approved by the IESG, taking in >> account the fact that currently there is no other request for TXT _er >> on the "virtual request queue", is reviewed as OK and approved. > > I agree, although I do wonder what “er” stands for. Error Report? Why not use > “_err” which is more intuitively an error ? Hi Paul, Thanks for your feedback. The “er” in “_er” stands for error report. Since it is used twice in a single error reporting query, we’d like it to be short. Hope this helps, Warmly, Roy > > Paul > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [IANA #1285116] expert review for draft-ietf-dnsop-dns-error-reporting (Underscored and Globally Scoped DNS Node Names)
On 1 Nov 2023, at 12:50, Frederico A C Neves wrote: > Because of the additive nature of the spec on cascading/concatenating > error situations I would guess that the authors opted for the shortest > node name available to fit as much errors as possible. Also if the only remaining point of discussion about the draft is whether to use "er" or "err" then I think that means the draft is in pretty good shape :-) Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [IANA #1285116] expert review for draft-ietf-dnsop-dns-error-reporting (Underscored and Globally Scoped DNS Node Names)
Paul, On Wed, Nov 01, 2023 at 12:38:09AM +0100, Paul Wouters wrote: > On Oct 31, 2023, at 19:17, Frederico A C Neves wrote: > > > > Dear David, > > > > Section 7 of the draft is sufficiently clear, precise, and complete. > > > > This registration at the time it is approved by the IESG, taking in > > account the fact that currently there is no other request for TXT _er > > on the "virtual request queue", is reviewed as OK and approved. > > I agree, although I do wonder what “er” stands for. Error Report? Why not use > “_err” which is more intuitively an error ? > Because of the additive nature of the spec on cascading/concatenating error situations I would guess that the authors opted for the shortest node name available to fit as much errors as possible. > Paul Fred ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Editorial Errata Reported] RFC8806 (7692)
Doh! That is correct… Thank you! W On Tue, Oct 31, 2023 at 8:59 AM, Joe Abley wrote: > Verified. > > On 31 Oct 2023, at 04:10, RFC Errata System > wrote: > > The following errata report has been submitted for RFC8806, > "Running a Root Server Local to a Resolver". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid7692 > > -- > Type: Editorial > Reported by: Deliang Chang > > Section: 3 > > Original Text > - > There is a risk that a system using a local authoritative server for the > root zone cannot refresh the contents of the root zone before the expire > time in the SOA. A system using a local authoritative server for the root > zone MUST NOT serve stale data for the root zone. To mitigate the risk that > stale data is served, the local root server MUST immediately switch to > using non-local root servers when it detects that it would be serving state > data. > > Corrected Text > -- > There is a risk that a system using a local authoritative server for the > root zone cannot refresh the contents of the root zone before the expire > time in the SOA. A system using a local authoritative server for the root > zone MUST NOT serve stale data for the root zone. To mitigate the risk that > stale data is served, the local root server MUST immediately switch to > using non-local root servers when it detects that it would be serving stale > data. > > Notes > - > Based on the context, it seems that in the last sentence the intended word > is "stale" as in stale data, instead of "state". So, I believe there might > be a typo in the text, and the correct interpretation would be to swith > back to the non-local root when stale data is detected. > > Instructions: > - > This erratum is currently posted as "Reported". (If it is spam, it will be > removed shortly by the RFC Production Center.) Please use "Reply All" to > discuss whether it should be verified or rejected. When a decision is > reached, the verifying party will log in to change the status and edit the > report, if necessary. > > -- > RFC8806 (draft-ietf-dnsop-7706bis-12) > -- > Title : Running a Root Server Local to a Resolver Publication Date : June > 2020 > Author(s) : W. Kumari, P. Hoffman > Category : INFORMATIONAL > Source : Domain Name System Operations Area : Operations and Management > Stream : IETF > Verifying Party : IESG > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
