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

Warren Kumari <> Thu, 04 July 2019 17:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C29F31200FA for <>; Thu, 4 Jul 2019 10:17:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0YfYUGl9ItwI for <>; Thu, 4 Jul 2019 10:17:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E0556120140 for <>; Thu, 4 Jul 2019 10:17:03 -0700 (PDT)
Received: by with SMTP id d23so8686569qto.2 for <>; Thu, 04 Jul 2019 10:17:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KCzEcmg/y61feTmhoetSA0H/knq45L1Vd1r8qW0Lj3k=; b=hSjudAq13EvYAZQHMtC43+w3tXNYWBUeqXkf9cIk9FDWW3te77zVmUO1RtiHYdWBzL N45FgjUSSi8rL9BUli1p9QRX2mL/xcF8BoHsLAbVFUaJVbwMh6GLrdzHiPPpXDijFG4q KWEtCgvf3zIn7aCNAIttla5yAecdKgxEab7V2JNn5T3o65sTpYIyrA0XIFezZHYUjUx+ R9gATg17io3+6meclCKgZwG87/cqtd/rOjd7pOxqx4D/mDuUS1aXzHqfxpr2zXmkTBJF XQM74Q3fEQ73B+mEi/gFkh/4+tACWFRKnsNj0weyZr4uwUBDb6xIAD+zlBuQx0JGb//W jS2w==
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=KCzEcmg/y61feTmhoetSA0H/knq45L1Vd1r8qW0Lj3k=; b=CJsZNI81XIgbvpJLe+sVtqEbuyZt+e3oDFe9YO/3BQgciJ6EJdBA+HcjZxdI3VAJH9 MZOYAvcaHswGCbF3vPPfFXHyXGgo0R+G+jwdPlD6WeQvalfutYz/EQip3NZAHhYke+Ar xb/aBkYHNKCN2eOikKBlvrE5um8WOfvG2C7CqYbTD5+LGkXk1hR1lkXzeZWeIe5cM6d6 7mX2lWo26Y04rzkhNghxpVR4ElyHoJEta/ymNjUMmcOdVHzjiwjo2H+1dCLVkEMGIEXf 80ss2k2i28zDCH1MsBPbN7cvMp4D3Q5iH87kdlBNO5J0aAL5RxPx9Vjfh+w2DTmeBZx4 t95w==
X-Gm-Message-State: APjAAAW8CP+15rEc97YVPX8hDWn4DTH7ikZdq5tKvLF8uVw2xApcG0nF csoaO5zDQDk6FeI1BNrIi1Q2X0zrZen9PSHjf2tsag==
X-Google-Smtp-Source: APXvYqzjn9C62AIfu/fSj35kT1YK8Jphkq0W8F6ZcovEAT7vpYIIyJSHYQ500cIPRQpoqqBq6H8OJhLwkk2Vdw7JMdY=
X-Received: by 2002:a0c:acef:: with SMTP id n44mr38960711qvc.39.1562260622559; Thu, 04 Jul 2019 10:17:02 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Warren Kumari <>
Date: Thu, 4 Jul 2019 10:16:24 -0700
Message-ID: <>
To: Barry Leiba <>
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 17:17:08 -0000

On Thu, Jul 4, 2019 at 9:26 AM Barry Leiba <> wrote:

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


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