Re: [Eligibility-discuss] NomCom selection Fwd: Notification for draft-eastlake-rfc3797bis-00.txt

[Donald Eastlake <[e-mail]>]

Hi Paul,

On Mon, May 29, 2023 at 6:27 PM Paul Hoffman <[e-mail]>
wrote:

> By a weird coincidence, I was creating a new, simpler choosing
> protocol when this discussion came up. A colleague was seeing if RFC
> 3979 fit their need to select m of n people, but had problems with
> the implementation of 3797.

And what were these implementation problems? People don't seem to have
much problem duplicating the nomcom Chair's results when the Chair
choses to use RFC 3797. IANA didn't seem to have much problem using it
to select the ACE Prefix. I'd have to go dig up the details but there
was also a case where an IEEE 802.11 TG Chair used it to select some
802.11 parameter and sent me mail afterwards saying they were
surprised it was so easy to use. Of course, these two cases were
simply selecting 1 value from n.

> When I looked at draft-eastlake-rfc3797bis-02, I saw that the
> pitfalls that were in 3797 were still there, and this spurred me to
> come up with something as good but simpler.

The goal of rfc3797bis was to add a way to re-randomize when the
selection has to be extended. This makes it more complex. Your draft
would, to satisfy some people, have to be similarly extended and made
more complex. In your Section 4 you just punt and imply there is no
problem here.

> Please see
> <https://datatracker.ietf.org/doc/draft-hoffman-genarea-random-candidate-selection/>.
> It may be of interest for the discussion of
> draft-eastlake-rfc3797bis.

Your method is very reminiscent of the method for which there was a
burst of interest some years ago. The method in 3797 requires, for
public confidence, that, after it is frozen, the volunteer list from
which selection is to be made not be changed in length or order. This
never seemed like such a severe restriction to me. (You repeatedly
talk about pitfalls in 3797 but don't say what they are.  Perhaps it
is that restriction.) If I remember correctly, this suggestion years
ago was that a hash-based scheme would be superior. The scheme I
remember being suggested was that the names in the volunteer list
would be hashed and sorted and then selection would be made by
calculating a sequence of pseudo-random numbers, as in 3797, but
rather than selecting the Nth entry using the remainder modulo the
remaining list length, the selected entry would be the one whose hash
was, for example, the next higher hash (using ring arithmetic) from
the random hash. I considered adding something based on this hash based
method to rfc3797bis but it didn't seem worth the effort. People are
used to the existing method and I hadn't heard any complaints for a
long while except for those in connection with extending selection.

(It is of course, clear that, in the hash scheme described above,
someone's chance of being selected would depend on how large a gap
there was below them in the sorted sequence of hashes, which means
someone could affect their chance of selection by their choice of
name. The obvious solution is to salt the names with something
unpredictable. At which point, the probing for selection becomes
unnecessary and the top x can be selected which is what you
propose. So, maybe, if I had decided to add a hash-based method to
3797, I would have thought of this and duplicated much of what you
came up with. Or maybe I would have missed it...)

Your hash method is simpler than the above hash method in that it
produces the list in selection order with the sort rather than using
multiple probes into the list to select and remove the selectees in
order.  However, while it would be the case that you could remove
ineligible people from the list without affecting the results, you
still couldn't add anyone and you have the new criteria that the exact
binary "name" on the list must be absolutely immutable after the list
is frozen.  If someone complains that their name has changed or their
name is wrong on the list, you just have to tell them "Too bad, it
can't be changed".

While your hash method is simpler than the hash method initially
described above, I don't think your selection method is significantly
simpler than 3797.  Your method of getting randomness is simpler
because you are content with poorer quality randomness with less
entropy. But if you are selecting m entries from a pool of n entries,
3797 has you do m hashes each of which selects one and then you are
done. Your draft has you do substantially more hashes (n of them,
since normally n > m) and then requires a sort which is not needed by
3797.

One way to view 3797 is that it selects m integers from the first n
integers (1...n). The binding between integers and names is entirely
outside of the code. Your scheme intimately convolves the exact names
with the selection.

Perhaps it is somewhat of a matter of opinion how "simple" each
is but, even assuming 3797 is a little more complex, given that there
is working trusted code, does it matter?

> Please note that the proposal could be turned into an RFC even if
> the IETF wants to keep using the protocol in
> draft-eastlake-rfc3797bis; there is good reason to have a simpler
> protocol defined for others who want to have the same result as what
> we have for NomCom, but using an easier-to-understand alternative.

I don't know why you say "...the IETF wants to keep using...". It is
up to the Nomcom Chair what method they use. Section 4.16 of RFC 8713
says is "One possible selection method is described in [RFC3797]."

Admittedly, RFC 3797 is a Best Current Practice (as opposed to its
predecessor RFC 2777 which was Informational). There is no particular
reason why there could not be multiple methods available to the Nomcom
Chair, whether in separate RFCs or in one combined RFC.

See miscellaneous other comments below:

> --Paul Hoffman

I really don't like stock prices or indexes. They are not guaranteed
to exist on any particular day because markets close in emergencies,
etc., so you have to be careful to word it something like "the X on
date Y or the first date after Y that X is available". Sometimes they
are represented in more than one way. There is little obligation on
the source to maintain any particular format or schedule. On the other
hand, with lotteries, governments are very careful to do the drawing
for every scheduled day and if there is a problem, they still do the
drawing for that day even if it is delayed a little. Basically, all
the stuff in 3797 about random sources applies, in my opinion, to your
draft.

In my opinion, your randomness is too weak and, while it doesn't hurt,
your hash function is grossly stronger than needed.

I'm puzzled by this sentence: "Such reestablishing of the candidate
pool [where extended selection has to be done] can cause confusion and
hurt among the candidates who were first selected, then later
unselected, due to no fault of the their own." I can understand why a
candidate who would be selected but isn't because they are from a
sponsor that already has two selectees or because they are
uncontactable could be "hurt". (Surely if they are not selected for
the third possible reason, that they decline, then it's their own
problem.) I also don't know what sort of "confusion" you are talking
about. In any case, the nomcom has real deadlines. While the nomcom
Chair has to make a substantial good-faith effort to contact
selectees, if they can't in a limited amount of time, they have to
move on or they risk failing to meet deadlines. Regardless of whether
you view this as a problem, it is completely independent of what
algorithm is used for selection from the volunteer pool and has
nothing to do with re-randomization.

You incorrectly claim that RFC 3797 requires re-randomization when the
selection process has to be extended. While the current rfc3797bis
draft does specify how to do re-randomization and requires it when the
selection process is extended, it would only require a few words
change to make it optional so the Nomcom Chair could decide if they
want to bother with it.

I don't get this stuff about how people should use the HTML version.
The only weirdness I see is the italic letters S and D which seems
insignificant. I think it is a better practice to write documents so
the .txt is easily usable.

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