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

[Barry Leiba <[e-mail]>]

> D2: 6.  Dispute Resolution Process
> " 4.  After consultation with the two principal parties to the issue, the
> arbiter decides on a resolution." Can this be changed to "After consultation
> with the principal parties..."? Disputes get messy and I don't see what
> specifying "two" adds here.

Adding my support to this DISCUSS point.

> D3: :7.6.  3/4 Majority
>    "A 3/4 majority of the members who vote on the question is required  for a
>    recall."
> "3/4 majority of the members who vote", or "eligible voting members"? If only
> one person actually casts their vote does that equal 100%? I'm perfectly fine
> if that is the intent, just wanted to make sure I'm reading it correctly. I
> personally feel that everyone should be expected to vote on this - I dislike
> the idea that people can abstain from voting because they don't want to get
> their hands dirty, and instead wait for one of their colleagues to stand up and
> make the hard decision. I also realize that this is already covered in the
> general confidentiality discussions, but I suspect that there is / will be more
> drama and intrigue around recalls - might it be worth reiterating that voting
> is confidential and / or should they be secret ballots? I really don't want
> anyone to feel uncomfortable voting to recall someone because they fear
> repercussions....

I tripped on this one too, and came up with some justification for it
in my mind, which I no longer recall.  So I'm adding my support to
this DISCUSS point as well.

> 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.

> 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