> On Nov 7, 2024, at 8:38 PM, Stefan Ubbink > <Stefan.Ubbink=40sidn...@dmarc.ietf.org> wrote: > > On 7 Nov 2024 18:36:34 +0000 > "John Levine" <jo...@taugh.com> wrote: > >> It appears that Shane Kerr <sh...@time-travellers.org> said: >>>>>> Since I noticed the ZONEVERSION RFC 9660, I was thinking that >>>>>> this could be extended to include a version at the database. >>>> I think this is prime example of a Private Use value. It would be >>>> specific to SIDN implementation and does not need any code >>>> assignment. Just do it! >>> >>> I think the idea is that this might be widely-used enough to benefit >>> from standardization, rather than using a Private Use value. >>> >>> I guess it depends exactly on the semantics, but having an actual >>> timestamp available for a zone seems generally useful. >> >> You have to know what kind of version numbers the database uses to >> know what the value means. I agree this is a private extension. > > I would argue that you wouldn't need to know what the value means, if > it is a number and it always changes in a predictable way. Or when the > publisher of the value has documented somewhere what it means. > > The current RFC 9660 uses SOA-SERIAL and it doesn't really matter if > the value is 1, 98643, 2024110711 or 1731011381.
I think there are two reasons to consider standardization instead of just private-use: 1) to define the meaning of the version as something like “database timestamp, expressed in a specific format” (epoch, ISO 8601, etc). 2) to specify how a name server knows where to get the version value. For example, extract from a regular expression match in a TXT RR located at the zone apex or some other name. DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
