[LEAPSECS] stale leap second information

[Warner Losh]

> On Jan 16, 2015, at 10:14 AM, Rob Seaman <seaman at noao.edu> wrote:
> 
> On Jan 16, 2015, at 8:57 AM, Warner Losh <imp at bsdimp.com> wrote:
> 
>> I’m *loving* this.
> 
> It's a bit of a goof...but that doesn't necessarily invalidate the gimmick.

The IPv6 thing is a bit of a gimmick, and I understood that… That’s kinda
why I was thinking TXT records since that’s more general…  And would
prevent misdirected packet traffic. I once helped the owner of localhost.com
cope with huge waves of packets from misconfigured DNS clients that resulted
in all lookups of ‘localhost’ turning into localhost.com which resulted in lots of
traffic to his DSL link...

>> In fact, you could actually make the lookups easier if you leveraged the domain
>> system. <month>.<year>.lastsec.utc.int would be the lookup.
> This also avoids whatever practical or prescribed limit there is to an IPV6 list as used here.

Well, that’s kinda the idea. One could also encode this info in a 127.0.0.<58,59,60> IPv4 address
that has well know not-routable properties if people really wanted to have a gethostbyname interface :)

>> This could also be trivially extended to DUT1 where monthly, or even daily, DUT1 measurements could be published by looking up increasingly specific numbers.
> 
> Not sure "trivial" is the right word and the different scheduling of knowledge of these (in advance or retroactively) will start to get in the way.

True. A lot depends on the accuracy needed. But TTLs can be used to expire data that’s known to have a limited shelf life, forcing a new query. And different TTLs can be given for different records.

But, yea, if you need nanosecond accuracy, and minute-to-minute urgency, there are several operational issues that would present.

> The solution needs to remain scalable whatever features are added.

I’d imagine that this solution would top out at hour-by-hour estimates.

>> I don’t imagine this would happen on a scale measured in anything less than decades :(.
> 
> More dramatic progress on many other projects has happened more quickly.

You’d think :)

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20150116/3948d3a9/attachment-0001.pgp>