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

Barry Leiba <> Thu, 04 July 2019 16:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9EF2212011F; Thu, 4 Jul 2019 09:26:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Xhf1pfDKsKRE; Thu, 4 Jul 2019 09:26:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4FC62120130; Thu, 4 Jul 2019 09:26:42 -0700 (PDT)
Received: by with SMTP id s7so13824527iob.11; Thu, 04 Jul 2019 09:26:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1TSH0bM+DzD7Wckthak7pvl7RqHCv5Gj4XKyeK1jt/s=; b=KPge41eMIYzaDMP6YuPIMqzlofZaM95+T6y33JZRfnG5G+CozQW+Q8vYpCXx7uYdlC hvLBbpPw4nKISDvna0mtSEYQ+3G/SeV8voq8T5SuDlbOVypxcvLmIb7q4EDm7aHu+OOH wsyf2EegnRCXpupri9QH2ice3pCh7tb0NgWzSkTBbtgJS5YqhldefVMkukK+Tj+cpcKb M5BxE0LJoJW9xTCI2I8HmhZqVWwMviS/sCC/Yu9Z8O4EQBti/sk7XedIxsZWYq4NE/j4 hKrmYarlKwrcctG4w7yhZAV7Z88/7rRRE8ykjAu1RL2coZekhRxYypEgrEf8AL7zj8Eh XdMQ==
X-Gm-Message-State: APjAAAUSDKbQ/Jw08DycJpNsiFElF7zfr0AEe4WYxt+QEwzht2MCPV/t 8T23Y/RFpC1FcfsQIlNsmRqQ0YNg5TtE+4DrbgM=
X-Google-Smtp-Source: APXvYqwA6yds8P0ggvYMLC7J/JjTiLKWbU5MrsrZH+Qwd4nguAIu2Naz5mUab9e7PRdc5T/LajfOGEckXn9xWDS+jsc=
X-Received: by 2002:a6b:fb0f:: with SMTP id h15mr29878715iog.266.1562257601056; Thu, 04 Jul 2019 09:26:41 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Barry Leiba <>
Date: Thu, 4 Jul 2019 12:26:30 -0400
Message-ID: <>
To: Warren Kumari <>
Cc: The IESG <>, Jon Peterson <>, IASA 2 WG <>,,
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Iasa20] Warren Kumari's Discuss on draft-ietf-iasa2-rfc7437bis-08: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Jul 2019 16:26:44 -0000

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