> On Nov 7, 2024, at 8:38 PM, Stefan Ubbink > <[email protected]> wrote: > > On 7 Nov 2024 18:36:34 +0000 > "John Levine" <[email protected]> wrote: > >> It appears that Shane Kerr <[email protected]> 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 -- [email protected] To unsubscribe send an email to [email protected]
