I'm very much enjoying the dueling perl / python and CRC / SHA competition here :-)
On Feb 10, 2015, at 9:45 AM, Zefram <zef...@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 _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs