[LEAPSECS] Bulletin C and all that

[Rob Seaman]

I'm very much enjoying the dueling perl / python and CRC / SHA competition here :-)

On Feb 10, 2015, at 9:45 AM, Zefram <zefram at fysh.org> wrote:

> Rob Seaman wrote:
>> 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.
> 
> Not really.  Local computation is cheap, getting cheaper relative to
> network traffic, and still easier to manage than network-related APIs.
> The lightweight nature of DNS queries (not to mention its ability to
> pass proxies and firewalls) is still a valuable feature when the client
> is sophisticated enough to stringify the month.

Well, no disagreement but there is some design trade-off to balance out.  No particular reason that more than one of these leap second, DUT1, DTAI, etc. mini-apis couldn't be deployed.

>> 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)
> 
> If you have the month in the domain name, then the RR that is returned
> only needs to encode the TAI-UTC difference, not any date as well.

Correct.

> So it gets much more comfortable to fit it into an A record.  Say,
> represent (TAI-UTC)/s in 16 bits, including sign bit, then there's room
> for a 12-bit check field.

Correct.

> I think it's a safe bet that AAAA lookups
> will be commonly available before we exceed the 16-bit range.

One hopes, but the A lookups would then already be in the field.

> I'd also
> base the check field on a cryptographic hash function rather than a CRC,
> because we're not trying to detect line noise, we're trying to detect
> addresses that weren't intended to be used in this protocol.

zefram says it better than I tried to in the past.  However, a hash is a hash.  The main benefit realized here is of 12-bits versus 8-bits.  The fraction of false positives will be identical overall for 8-bits of this versus 8-bits of pseudorandom that.  A 1's complement checksum would be good, too.  Aside from the slight style points for zeroing the checksum one way or another, the bigger benefit is if a method for SHA is built into numerous languages, for instance.  The 2004 citation for CRCs implies that this will not be true for them.

> Test values for the above encoding:

./zefram.pl
255.194.128.0 -> -32768
248.211.216.240 -> -10000
250.199.252.24 -> -1000
245.118.255.156 -> -100
253.93.255.246 -> -10
242.43.255.255 -> -1
245.79.0.0 -> 0
252.228.0.1 -> 1
250.83.0.10 -> 10
255.127.0.100 -> 100
245.137.3.232 -> 1000
243.246.39.16 -> 10000
242.222.127.255 -> 32767

Well, I can recover your numbers, whatever we choose to make them mean :-)

>> 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?
> 
> That's not a good naming scheme for use in the protocol.  It's importing
> irrelevant information by virtue of the unhealthy focus on Bulletin C
> per se.  Just name it for the month concerned.

Not necessarily.  As Kevin points out the culture matters.  This is a discussion about how UTC is used in a social context with normative standards.  Not just what is the mapping between timescale A and timescale B, but when does this event legally occur?

> For Bulletin D you can perfectly well put the complete date in the
> domain name and just encode the DUT1 value itself in the RR.

Yes, if you separate the independent and dependent variables.  For Bulletin D the calendar date is really the dependent variable.  (At least, one can look at it that way.)  "When will DUT1 reach the value of -0.5s?"  Answer: Christmas 2014.  It's a multi-valued waveform.

> As an A record, perhaps 16-bit number of milliseconds (anticipating future
> finer resolution as well as increased tolerance),

Right, and that's what I prototyped a couple of weeks ago, but found myself on the fence about.

It's an implementation detail with signed/unsigned, etc.

> same encoding as I suggested for DTAI but using a different magic number in
> the check field computation.

I like that gimmick.  Any comments on how you selected the magic number?  Is the value you used well known?

> If you really want to publish information about spans of days to
> which the same DUT1 applies, you still don't have to squeeze date
> and DUT1 value into the same RR.  They can go in separate RRs in one
> RRset, or be stored under different domain names (value.d121.example,
> prevchangedate.d121.example, nextchangedate.d121.example).

Right, the question is whether multiple DNS queries are simpler than a single web service request.

> The date also doesn't need to be broken up into month and day-of-month: a linear
> day count will do just fine.

Right, but since the month encoding was already needed for Bull C, it seemed reasonable to use the same thing for D.

I guess we still have some design issues to consider.  Very interesting!

Rob