-------- In message <20150116205656.in5lwal6%[email protected]>, Steffen Nurpmeso write s:
>The IETF should [...] Don't even get me started on what the IETF should or should not do. I tried to find out when the last time I thought "Good job IETF" and I realized that was soooo many years ago that it hurts to think about. >I consider it bad style to (1) misuse publically available A/AAAA >records with faked addresses and then in addition (2) use >non-private address ranges that may possibly clash real server >addresses. I can enumerabte the number of f**ks I give about that kind of high-horse moral grand-standing in a single bit. (Hint: it won't be a one). It is *exactly* because of impotent political standardization we are in the shitty situation with respect to leap seconds, and at this point in time I'll support anything that works towards making it more manageable in the short term. >I think having a plain 16-bit signed integer for the offset in >seconds and a 16-bit signed integer for the number of days since >the laster leap second (negative, no new leapsecond envisaged), >and to the next leap second (positive, new leapsecond announced), >respectively. 16-bit should be plenty for either counts. Amongst many other flaws, this require a DNS TTL significantly less than one day in order to not give trouble near leap-seconds. My proposal could run with 6 months TTL. >I'm sure you have a nice weekend regarding the CRC checksum... The CRC is there to detect when DNS replies are rewritten to point everything at captive portals, as is the case on a lot of "free WIFI" networks etc. Your idea offers no way to detect that... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [email protected] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
