[LEAPSECS] "not my job" ?

[Michael Sokolov]

Rob Seaman <seaman at noao.edu> wrote:


> Obviously we would be forced to adapt.  We can't all be a "one-man

> micronation" like Michael :-)  More power to him, but that isn't a

> "coordinated" plan either.


My "one-man micronation" is connected to the Internet with its own
public, static, world-reachable IPv4 address block and a few domains.
My UTR time server will have a public, world-reachable IPv4 address
(IPv6 connectively will probably be added soon too), and all of you
will be more than welcome to get time from it.  So it *is* a viable
solution for more than just me.

Furthermore, although my preference is to implement my UTR time server
with custom PowerPC hardware rather than mere software hacks on a
garden variety x86 box, I will publish all of my hardware schematics,
PCB and gerber files etc (as in release all that into the public
domain), so anyone else would be able to build his/her own UTR server
identical to mine.  I will also offer actual hardware units for the
cost of what I have to pay for the PCBs, parts and assembly, i.e.,
zero profit margin for me.  And if someone else finds a way to
implement a functionally equivalent UTR server using only software
instead of custom hardware, more power to them.

As for my plan not being "coordinated", I beg to disagree as well.  I
have already posted a draft of the formal technical specification for
the UTR timescale, which includes a mechanism for having all UTR users
agree on exactly the same rubberizations.  Brief summary:

* An open-participation mailing list needs to be created on which all
  UTR users could gather, although I would prefer it to be a little
  more inclusive to *all* forms of Mean Solar Time in a post-UTC
  world, hence the proposed name MST Users.  You, Rob, are personally
  invited to join, as are Michael Cook and Markus Kuhn.

* The UTR specification does not stipulate any specific set of
  rubberizations, although for the sake of ease of implementation it
  requires the duration of each rubber second to be an integral number
  of SI milliseconds.  But there are many possible rubberizations
  which would meet this constraint, and my vision is to have some
  community consensus rather than fiat drive that choice.

Even if our Mean Solar Time Users mailing list has only 3 members
initially (e.g., me, you and Michael Cook), our UTR timescale can be
fully coordinated between the 3 of us.  The official UTR timescale is
defined by the utrdef.txt file, an ASCII text file whose format/syntax
is defined by the UTR specification, but the consensus at to exactly
when should rubberizations occur and what shape they should take
should be reached on the mailing list first.  My vision is that we
would reach consensus on our mailing list, then the maintainer of the
actual utrdef.txt on the official server would merely encode the
consensus decision in the standard file format/syntax.

All actual UTR time server implementations, whether it's my preferred
PowerPC hardware implementation or someone else's functionally
equivalent software implementation, would periodically poll the server
holding the master copy of the official utrdef.txt, and automatically
pull down any updates well advance of each rubberization.  As a result
all UTR users will independently regenerate exactly the same UTR time
scale, with rubberizations occurring at exactly the same agreed-upon
times, regardless of which actual hw/sw implementation they choose to
use.  No worse than the current UTC, i.e., no less coordinated.

MS