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
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
