[LEAPSECS] stale leap second information

[Warner Losh]

> On Jan 17, 2015, at 7:33 PM, Rob Seaman <seaman at noao.edu> wrote:
> 
> On Jan 17, 2015, at 4:12 PM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> 
>> If you need the historical information, you can afford the TCP
>> connection to IERS.
> 
> There's also value in implementing a single ICD for all use cases, but point taken.

So long as the file is signed (not just check-summed) that would work. Not
all applications can do this, but many can.

>> I'm focused on how NTP/PTP clients will be able to get/validate leapsecond information efficiently and reliably.
> 
> The python script tests the encoded values:
> 
> % ./leap.py
> YYYY MM before  after  encoded crc IP               Decoded
> -------------------------------------------------------------------------
> 1972  1      9     10 f0002500  fb    240.0.37.251 -> OK  1972  1   +9 +1
> 1972  7     10     11 f0182900  b1   240.24.41.177 -> OK  1972  7  +10 +1
> 1973  1     11     12 f0302d00  45    240.48.45.69 -> OK  1973  1  +11 +1
> 
> but doesn't pair them with string addresses.  Were you thinking like Warner suggested, requesting feedback for a specific month/year?  So a client would poll at startup / reset / etc, but would need to understand the June/December convention (and ignore the other technically legal months)?

I think he’s looking to get just the current value as an IPv4 address. My notion was to tunnel the info over DNS, but I’m starting to think that’s a cool idea, but one that’s perhaps not as valuable in practice as one might hope.

>>> Unless there is an overriding value in efficient encoding,
>> 
>> There is.  getaddrinfo(3) is almost always available and works
>> about as well as any protocol on the internet can work.
> 
> Doesn't getaddrinfo support IPv6, too?  Parsing the longer string won't be dramatically slower.

Even at this late date, IPv6 isn’t universally supported. And many IPv4 only machines specifically compile out the IPv6 support and/or filter IPv6 replies.

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/20150118/f13fa939/attachment.pgp>