[LEAPSECS] Bulletin C and all that

[Rob Seaman]

Hi zefram,

> Rob Seaman wrote:
>>           leap26.leapsec.com  ->  250.10.36.152   -> OK 2015  7  36  1  (1, 0)
> ...
>>              c48.leapsec.com  ->  242.4.35.72     -> OK 2015  1  35  0  (0, 0)
> 
> I think it's a mistake to encode Bulletin C per se, or even to concentrate
> on leap events.  What clients need to know is the relationship between
> UTC and TAI, which (post-1972) takes the form of a piecewise constant
> difference.  What should be encoded is that difference, for each monthly
> piece.  A client can be expected to know which months it is interested in.

I don't disagree and I was working on something similar with DUT1:

       dut1.201501.leapsec.com  ->  240.210.218.53  -> -46022 -> -0.46022 seconds
       dut1.201502.leapsec.com  ->  240.198.80.149  -> -49232 -> -0.49232 seconds
       dut1.201503.leapsec.com  ->  240.184.18.42   -> -52878 -> -0.52878 seconds
       dut1.201504.leapsec.com  ->  240.166.142.108 -> -57362 -> -0.57362 seconds
       dut1.201505.leapsec.com  ->  240.150.39.208  -> -61561 -> -0.61561 seconds
       dut1.201506.leapsec.com  ->  240.137.158.247 -> -64770 -> -0.64770 seconds
       dut1.201507.leapsec.com  ->  242.10.187.39   ->  33819 ->  0.33819 seconds
       dut1.201508.leapsec.com  ->  242.9.149.181   ->  33525 ->  0.33525 seconds
       dut1.201509.leapsec.com  ->  242.2.114.186   ->  31698 ->  0.31698 seconds
       dut1.201510.leapsec.com  ->  241.245.33.186  ->  28289 ->  0.28289 seconds
       dut1.201511.leapsec.com  ->  241.227.208.63  ->  23856 ->  0.23856 seconds
       dut1.201512.leapsec.com  ->  241.213.32.100  ->  20096 ->  0.20096 seconds

With the thought that the client would interpolate between these monthly numbers from the Bulletin A predictions.

You can access these addresses:

	% dig +short dut1.201502.leapsec.com a
	240.198.80.149

But don't worry about the encoding, since I don't plan to continue on this line.  The trouble with encoding dates in the names and interpolating in the client is that by the time you're done it would have been easier to simply use a web service.  This starts to be a very different interaction than just "get Bulletin D".

The question isn't what a web service should provide.  See Tom Van Baak's prototype http://dut1.org:

	DUT1=-0.503
	MJD=57063
	DATE=2015-02-10
	TIME=14:35:44
	STOD=52544
	fMJD=57063.608148
	HELP=dut1.org/help.htm

A web service can either compute the current value or deliver a detailed table.  More to the point it can remain up to date with the frequent Bulletin A updates, or even replace Bulletin A numbers with the final numbers from Bulletin B retroactively.  A web service (or a table delivered in some other way) can provide rich information with a complete set of Earth orientation parameters and related technical information.

The question, rather, is precisely how to improve delivery of Bulletin C.  And in the example above of Bulletin D.  These two bulletins are normative to UTC, unlike A (predictions) and B (retroactive final numbers) which are inputs to the leap second / DUT1 decision-making.

I share the same vision of a focused scope for this DNS mechanism that PHK has expressed.  We need to converge on the precise encoding, but I think this is pretty close:

	bulletin-c.leapsec.com  ->  250.10.36.152   -> OK 2015  7  36  1  (1, 0)

> Encoding Bulletin C is especially problematic because your encoding
> necessarily makes some fairly strong assumptions about the scope of
> each bulletin, assumptions which are not inherent features of UTC but
> merely epiphenomena of how UTC is currently administered.

Indeed.  The issue to resolve with Bulletin C is how it should best support likely variations of future policies.  Warner and I and others share the opinion that IERS could profitably lengthen the forecast for future leap seconds.  Suggestions are that this could extend past two years (or perhaps longer) right now.  In that case a single bulletin might announce the presence or absence of leaps seconds for several half years in a row.  The naming would need to handle this.

> There is no inherent requirement that Bulletin C be issued at particular
> intervals, or that there be a one-to-one correspondence between bulletins
> and leap opportunities (even when only considering June and December to
> be opportunities).

Right, but the proposed encoding supports any month for more than a century to come.  There will either be a leap or no leap at the end of each month.  If the policy changes to permit months other than June and December we're ready - as long as we figure out what to call it in such cases.  c48a, c48b, c48c?

> Bulletin C's real significance is to announce some
> previously-unknown monthly pieces of the definition of UTC, and there's
> no inherent need for those pieces to have any particular relationship.

Well, they are likely to always be contiguous and monotonic in date, if not in leap second offsets.

> Once they've been announced, there's no inherent persistent grouping
> between the offset segments that happened to be announced at the same time.

Right, but the encoding itself supports this.  As long as we figure out functionally what to call the different events, they can be populated in whatever order they are announced.

I don't think I replied to your previous message:

>> I'd arrange the DNS mechanism such that the queried domain name encodes the month

and

>> The TAI-UTC difference may also be encoded in A and AAAA records to support lookup via gethostbyname().

As you can see I had tried both of these with dut1.  Rather, now I think that we do want to express Bulletin D explicitly, and the trick is to encode both the date and the value in the few bytes provided by IPv4.  Something like:

	% dig +short bulletin-d.leapsec.com a
	242.3.25.251

This is just example coding and will undoubtedly differ by the time we're done with it.  Here the first two bytes are the same as for bulletin-c, a class E prefix, a leap flag, and the count of months.  In this example these say "no leap" and the month number corresponding to December 2014.

The third byte (in this example) is the day of the month.  The fourth byte is the 2's complement signed published DUT1 from the latest Bulletin D 121, in tenth seconds, of -0.5s beginning 25 December 2014.  About 1 out of 10 Bulletin D's correspond to a leap second, so the leap flag will be useful when DUT1 sawtooths back with each one.

We need 5 bits for the day of the month and 5 for the current 0.9s range.  (I believe all historical values could just barely squeeze into 4 bits.)  This would allow 6 bits for a CRC.  Alternately we might want to permit a larger range for DUT1, trading off bits in the CRC.  Perhaps PHK also ran the 6-bit and 4-bit exhaustive tests to choose polynomials?

A somewhat more expansive encoding could be used with IPv6.  DNS permits efficient, robust and widely available access to focused information.  Web services (or simply pages) would be used for detailed tabular information or up-to-the-minute calculations.  The two can work together to check each other, etc.

Rob