Re: NomCom selection Fwd: Notification for draft-eastlake-rfc3797bis-00.txt

[Donald Eastlake <[e-mail]>]

On Wed, May 10, 2023 at 10:37 PM Toerless Eckert <[e-mail]> wrote:
>
> It seems as if the concerns about added delay could indeed be eliminated for
> all practical purposes if we could find a random source that publishes
> future randomn numbers in short intervals (hourly ?!)  - and keeps them published for
> a sufficient long period for verification.

The other substantial component of the delay is the time it takes for
the Nomcom Chair to make a reasonable effort to contact the new
tentatively selected person or persons and determine if they are
actually contactable and are still willing to serve.

> I am not so sure that i would want to trust the independent randomness of some
> strage URL like https://api3.drand.sh though.

I would say it is most important for the public to have a reasonable
level of trust in the randomness so any cute technical place producing
frequent random numbers but which the public has never heard of does
not, in my opinion, qualify.

> Aka: It would also be lovely to pick a random source that we all feel is likely
> to be around for some decades unchanged.

Why would we specify the exact source? We never have before. We
specify the desirable criteria for the source and the Nomcom Chair
picks the source/sources.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]

> Cheers
>     Toerless
>
> On Fri, Apr 28, 2023 at 03:06:13PM -0400, Michael StJohns wrote:
> > On 4/26/2023 1:49 PM, Salz, Rich wrote:
> > > Does anyone disagree with the following?
> > > - 8713 will not be updated in time to take effect for this NomCom's selection process.
> > > - The text of 8713 specifies a process that, if followed, means a delay of at least one week, and perhaps at least two weeks.
> > >
> > > "Picking next one the list" is the process recommended by at least the last half-dozen NomCom chairs, and followed by at least one of them (me); perhaps more than one. Yes, this can be gamed.  So what; security is about trade-offs and saving time is more important for now.
> > >
> > > Some folks might want to review the errata athttps://www.rfc-editor.org/errata/rfc8713. I have no idea where discussions of that should happen.
> > >
> > > It wasn't clear to me if Rob was proposing an interpretation of 8713, or providing input to a revision.
> > >
> > > I had to disqualify one potential volunteer. They said yes, and then I was unable to interact with them for the next three days (it was the weekend).  One day is not enough. And weekends aren't the same globally, once you allow for timezones or countries that observe the classic Sabbath.
> > >
> > >
> >
> > I actually disagree.
> >
> > 4.16 requires that you announce the list and the selection method ahead of
> > time.  It does not require that for each and every iteration except that
> > "The method must depend on random data whose value is not known or available
> > until the date on which the random selection will occur.".
> >
> > The phrase that you might be giving more weight to that necessary is "The
> > announcement should be made at least one week prior to the date on which the
> > random selection will occur." - note the "should" vs a must.     In any
> > event, you could consider that a requirement for the initial roll, but as
> > long as you meet the requirement that the random data is unknown in advance
> > you could announce a re-roll to occur in a half hour, as long as the
> > announcement makes it to the list prior to the roll.  See below for an
> > example.
> >
> > Requiring a re-roll is necessary in certain circumstances:  "A method is
> > unbiased if no one can influence its outcome in favor of a specific
> > outcome."  I think that applies in all circumstances if someone needs to be
> > replaced because the outcome of the replacement can be predicted.
> >
> >
> > Example using the league of randomness.  I'm proposing to use round 2909292
> > of the first chain (8990...b2ce) as the randomness for a future roll.
> >
> >
> > https://api3.drand.sh/chains
> >
> > >>>
> >
> > 0     "8990e7a9aaed2ffed73dbd7092123d6f289930540d7651336225dc172e51b2ce"
> > 1     "dbd506d6ef76e5f386f41c651dcb808c5bcbd75471cc4eafa3f4df7ad4e4c493"
> >
> > https://api3.drand.sh/8990e7a9aaed2ffed73dbd7092123d6f289930540d7651336225dc172e51b2ce/info
> >
> > >>>
> >
> > public_key "868f005eb8e6e4ca0a47c8a77ceaa5309a47978a7c71bc5cce96366b5d7a569937c529eeda66c7293784a9402801af31"
> >
> > period        30  --- 2 rounds per minute
> > genesis_time  1595431050
> > hash  "8990e7a9aaed2ffed73dbd7092123d6f289930540d7651336225dc172e51b2ce"
> > groupHash "176f93498eac9ca337150b46d21dd58673ea4e3581185f869672e59fa4cb390a"
> > schemeID      "pedersen-bls-chained"
> > metadata
> > beaconID      "default"
> >
> >
> > >>> Current round
> >
> > https://api3.drand.sh/8990e7a9aaed2ffed73dbd7092123d6f289930540d7651336225dc172e51b2ce/public/latest
> >
> > round         2909232
> > randomness
> > "1303dd35336091d56d95dff1c21acb11a25a4c1be66593dd8392a147a19ea231"
> > signature "b80ebdab37f95217694beb2d45b172f003f66bf027556b8ff09dc5faff68715727dfa12364d9e912366a95ceb8b2ab01161ebbf93f59631a4be3c17193e1012a4e15d704eda2ab37dd28947b8036ec9a9e9ae21d08ded75e1cb3fe168e85b465"
> >
> > previous_signature "99b23a8e422dbaab411db82b18cd23ffaa944c6a76d5792e09367505c2f763b9570e15ecb0248ae751bb87539823a863108f8fa30538fef397b753131d3b87e465d621d1f5dc1324791a565ce55d1ae0a4e6c0180b33c483449715b17548e8fd"
> >
> >
> > Current round was at (2909232 * 30) + 1595431050 -> 1,682,708,010 Fri Apr 28
> > 2023 14:53:30 GMT-0400 (Eastern Daylight Time)
> >
> > >>> Target round (30 minutes) = 60 +  2909232 => 2909292
> >
> > https://api3.drand.sh/8990e7a9aaed2ffed73dbd7092123d6f289930540d7651336225dc172e51b2ce/public/2909292
> >
> > Not available as of the time I'm writing this note - server appears to wait
> > until it is.
> >
> > Mike
> >
> >
> >
> >
>
> --
> ---
> [e-mail]
>