Re: [Iasa20] Warren Kumari's Discuss on draft-ietf-iasa2-rfc7437bis-08: (with DISCUSS and COMMENT)

[Warren Kumari <[e-mail]>]

On Thu, Jul 4, 2019 at 9:26 AM Barry Leiba <[e-mail]> wrote:
>
[SNIP]

> > 8: 4.16.  Selection Process
> > The selection method must produce an ordered list of volunteers.
> > Er, why? (genuinely interested, not snark :-)) -- I can see why the *input*
> > must be ordered (so we can all verify the algorithm was run correctly), but why
> > must the output be ordered? E.g A new algorithm could be used where everyone is
> > put in a pool, and candidates deterministically ejected until only N remain.
> > This would result in an unordered, but publicly verifiable pool.  I personally
> > think that RFC3797 is awesome, but if you are allowing other methods I don't
> > understand this limitation.
>
> As it's currently done:
>
> 1. We go through the list in order, selecting person 1, then 2, then
> 3, and so on.  If, say, persons 1, 3, and 5 have the same affiliation,
> we skip person 5 and use 6 instead.
>
> 2. if someone has to drop off (is selected and decides not to serve,
> for example), the "next" person who hadn't been selected replaces her,
> and an unordered list has no "next" person.
>
> Those two mechanisms only work with an ordered list.  It's certainly
> possible to change things so that an unordered list is feasible, but
> that would be a significant change.
>

Oh. I must admit that I had misunderstood -- I had thought that if
person 5 had the same affiliation to removed them, and reran the
algorithm on the smaller pool. Guess I'd misunderstood.
I *personally* think that we should just always use RFC3797, but
seeing as we don't specify this, I'm still somewhat uncomfortable that
we list this as a requirement for the output of whatever is used --
but, I'm perfectly fine to be uncomfortable -- feel free to view this
as a comment and not part of the DISCUSS...

W


> > 10: 5.15.  Confirming Candidates
> > "A nominee may not know they were a candidate."
> > I'll happily cop to this being a pet peeve, but could you please change this to
> > "might not"? This sounds like an imperative...  and from now on, every time you
> > are on a plane, and hear "although the bag on the oxygen mask may not inflate,
> > oxygen is flowing to the mask" you can thank me :-P
>
> I share your pet.  Thanks.  :-)
>
> Barry



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf