Thanks how I read it the first time as well, but then Erik Kline hit me with the clue-bat.
The original says that both zones and caches use the absolute time format, but the description in 6.1.3 says otherwise… I’m still somewhat confused though, and am fine being hit again… W On Mon, Jun 7, 2021 at 10:14 PM Mark Andrews <[email protected]> wrote: > While there is nothing wrong with the change it isn’t actually a > errata as it is referring the reader back to section 6.1.3 where > both forms where discussed together. > > > > On 8 Jun 2021, at 06:20, Warren Kumari <[email protected]> wrote: > > > > Hi all, > > > > I believe that this Errata should be marked as Verified; does anyone > disagree? > > > > Please let me know by Friday if you disagree, > > W > > > > ---------- Forwarded message --------- > > From: RFC Errata System <[email protected]> > > Date: Mon, Jun 7, 2021 at 12:57 AM > > Subject: [Technical Errata Reported] RFC1035 (6601) > > To: <[email protected]> > > Cc: <[email protected]>, <[email protected]> > > > > > > The following errata report has been submitted for RFC1035, > > "Domain names - implementation and specification". > > > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid6601 > > > > -------------------------------------- > > Type: Technical > > Reported by: Patrick Ni <[email protected]> > > > > Section: 7.1 > > > > Original Text > > ------------- > > This timestamp uses the absolute time format previously discussed for RR > storage in zones and caches > > > > Corrected Text > > -------------- > > This timestamp uses the absolute time format previously discussed for RR > storage in caches > > > > Notes > > ----- > > In section 6.1.3. Time, it says "while data in the zone stays with > constant TTL ... The RRs in zones use relative times; the refresh timers > and cache data use absolute times" > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC1035 (no draft string recorded) > > -------------------------------------- > > Title : Domain names - implementation and specification > > Publication Date : November 1987 > > Author(s) : P.V. Mockapetris > > Category : INTERNET STANDARD > > Source : Legacy > > Area : Legacy > > Stream : IETF > > Verifying Party : IESG > > > > > > > > -- > > The computing scientist’s main challenge is not to get confused by the > > complexities of his own making. > > -- E. W. Dijkstra > > _______________________________________________ > > DNSOP mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/dnsop > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: [email protected] > > -- Perhaps they really do strive for incomprehensibility in their specs. After all, when the liturgy was in Latin, the laity knew their place. -- Michael Padlipsky
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
