Re: [Iasa20] Ballot positions on draft-ietf-iasa2-rfc7437bis

Bob Hinden <bob.hinden@gmail.com> Mon, 08 July 2019 15:19 UTC

Return-Path: <bob.hinden@gmail.com>
X-Original-To: iasa20@ietfa.amsl.com
Delivered-To: iasa20@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823B91201E9; Mon, 8 Jul 2019 08:19:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.703
X-Spam-Level:
X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVJBOa4rvIxD; Mon, 8 Jul 2019 08:19:05 -0700 (PDT)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1301912018E; Mon, 8 Jul 2019 08:19:05 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id f9so17558717wre.12; Mon, 08 Jul 2019 08:19:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=pA77oj8r/xSRxeDjFC/7CmUglLNSyRdxklUQ0IxiIxA=; b=Ft9aLGR28/mvzRwVHKsG5pEyV2W8t8BHxJ6HEyS0gEEfE86MQk92CxP76GxDcSURWG Fgd+x/HXgkrnT1TVxHJ+VTu0R1XEnjjzsEJ2sOT+w8YgumtZO4tGBHYpol7nVFMSK+N/ AKVbvLzBszQoF1z32YfCImj+1zUCRcjw/2O1s07mlMF/g43VevEX620ESbHCYmtooqdU 8yuWJ7WtKamyZRAxXKDbPu6KoXLK+FFPnfcCRC3WVRZ/eRzm9zRlWZ/Cm3BmT5LNPN3g yToht2Oed90PtfpVEMH4rwhHQJf0XcUg7e5Twu1f5U20lb3CITpg2f1/jg2gYitVWeLH N20w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=pA77oj8r/xSRxeDjFC/7CmUglLNSyRdxklUQ0IxiIxA=; b=W1Skuzhwg1SuEbi11s7ONHVp2HXAo8tN9b4wW3s/oZW2x9hJTc5/bkXC3X5G5Fh5Eo FTz6VJyI0n7pi6AP5RVhTKj6CfxFNUl8jsMuoA7shHYvH2LQBb34QzYXX5RI1MbAOtSM azT93sd77UMHOPuDIElc1TK+jBrMi6RRZZ8L0V35dSf/AL/h0Qg6uvhAjZsbBlIp0Iwx uzufGVrgTvInChb+yIaSfrpxmJavn5Zaa5MjzKlXWR0HP2YEzOuEAyeK4lqKyl4AYjAN U5GzyxaHxkp5DPXe00IraVu9s8a40nnKh0twtTfogKtkQmCurGHWkL6KlffD7sdYQ3Fu crcw==
X-Gm-Message-State: APjAAAV/wCNHeZ69EaHRXKVHYGiEEA/vF6G3XL7JnvzUHMq1D6QUF8gs dpHpWq5rQe3eFNZGOIgRAxo=
X-Google-Smtp-Source: APXvYqwf5tFcyBDmoK669O3z/xQq+zgwuDeQunS8RybP41t6/5Ghf0qR2cp3/oDefZQXtkkcWZeQMg==
X-Received: by 2002:a05:6000:9:: with SMTP id h9mr16814234wrx.271.1562599143553; Mon, 08 Jul 2019 08:19:03 -0700 (PDT)
Received: from [10.0.0.199] (c-24-5-53-184.hsd1.ca.comcast.net. [24.5.53.184]) by smtp.gmail.com with ESMTPSA id x17sm13784338wrq.64.2019.07.08.08.19.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jul 2019 08:19:02 -0700 (PDT)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <6B48AD3B-41B4-499F-B5B8-63BFB88075CB@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_234D9F86-6F5C-4DA2-A480-D2B94488AAA3"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 8 Jul 2019 08:18:57 -0700
In-Reply-To: <CALaySJ+eVjbrfFkO1B0ZoGLOyWDwBT2O7Ap4ktt9rH3+U8XAkQ@mail.gmail.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, IASA 2 WG <iasa20@ietf.org>, Alissa Cooper <alissa@cooperw.in>, IESG <iesg@ietf.org>, Brian Carpenter <brian.e.carpenter@gmail.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: Barry Leiba <barryleiba@computer.org>
References: <AC12184D-B315-43B9-8691-EF0F7D901199@cooperw.in> <98cf5edb-29a4-57b0-4e0f-206b6b9c1e5d@gmail.com> <FB091C9A-80C2-440C-964F-D89E7F55F67A@gmail.com> <8fd54995-8f5a-0efb-4d94-c363ea81b286@cs.tcd.ie> <CAHw9_iLDNBp08b=iTZadncvixkoEw-pazmD8B8xW8itzrPFvqQ@mail.gmail.com> <2962D9D5-314D-4E4F-A619-49948D01D3E9@gmail.com> <CALaySJ+eVjbrfFkO1B0ZoGLOyWDwBT2O7Ap4ktt9rH3+U8XAkQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/tRn-v-n5nP7CMQR2NjC_Yz3AGt0>
Subject: Re: [Iasa20] Ballot positions on draft-ietf-iasa2-rfc7437bis
X-BeenThere: iasa20@ietf.org
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?= <iasa20.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iasa20>, <mailto:iasa20-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iasa20/>
List-Post: <mailto:iasa20@ietf.org>
List-Help: <mailto:iasa20-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iasa20>, <mailto:iasa20-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Jul 2019 15:19:08 -0000

Barry,

> On Jul 8, 2019, at 7:43 AM, Barry Leiba <barryleiba@computer.org> wrote:
> 
>> Doesn’t it count for something that this document was approved by an earlier IESG in 2014?
> 
> You're being disingenuous.

Really?  The definition of disingenuous is:

  adjective
     not candid or sincere, typically by pretending that one knows
     less about something than one really does.


> THIS document was never put before the
> IESG before.  The draft that became RFC 7437 was, but that was a
> different document.

But most of the text has been before the IESG before.  That’s why I said:

   Doesn’t it count for something that this document was approved by an
   earlier IESG in 2014?

> 
> Today, we're being asked to review draft-ietf-iasa2-rfc7437bis, not
> draft-kucherawy-rfc3777bis.
> 
> Now, first, it would have been nice to have been alerted that a
> thorough editorial review was not welcome *before* the document was
> put on the telechat agenda and a ballot was opened.  I spent a few
> hours working on it and being thorough, and would liked to have not
> wasted my time on things that will be ignored.

I agree that would have been better, but please note, I am only the document editor here.

> 
> Second, the working group charter says this:
> 
>   Aside from instances where they presently relate to IASA, it is outside the
>   scope of this working group to consider any changes to anything related to
>   the oversight or steering of the standards process as currently conducted by
>   the IESG and IAB, the appeal chain, the confirming bodies for existing IETF
>   and IAB appointments, the IRTF, or ISOC's memberships in other organizations.
> 
> I see a huge difference between not considering changes to the process
> (and oversight and steering)... and not considering editorial changes
> that correct or clarify existing text.  Clearly, not everyone agrees
> with me on that, but it's part of the job to which I've been appointed
> to review documents for correctness and clarity, and to call out areas
> where I think the documents fail.

If we want to make a lot of changes, then I think it will need at least another IETF last call, or given the other NomCom related issues being discussed recently, a new w.g.


> I'll note, for example, that in the text I've been trying to get
> discussed, in Section 3.8, this document -- THIS document -- already
> makes changes to what was in 7437, some of which were not required for
> the IASA2 changes.  It changes "nominating committee" to "NomCom" (why
> does that relate to IASA2?) and merges bullets 3 and 4 from the
> original.  I'm not suggesting that those changes should not have been
> made, nor that they caused the issue I'm questioning.  I'm only saying
> that we're already not being rigorous about limiting text changes to
> those absolutely necessary.  So let's get some perspective here.
> 

The intent for this change was to use the term that is in common use, but if it’s an issue we could go back to “nominating committee”.  I think that’s different than for example rewriting the text in Section 3.8. "Sitting Members and Directors” regarding the exception for the IAB.


>> In my view, this behavior from ADs does not add to the overall quality of the IETFs work,
>> it just makes more work for everyone and slows everything down.
> 
> Is it your view that if an error is missed once, we're stuck with it forever?

No, I don’t think I said that.


> 
> Am I really not adding to overall quality by asking for clarity in
> text that I think simply doesn't work as written?  I could be wrong
> when I say the text appears to be broken, but we're not having a real
> discussion about it, so I wouldn't know.  Maybe it's attempts to
> deflect discussions, rather than actually have them and resolve the
> issues, that makes more work for everyone and slows everything down.
> 
> I am not trying to block this document; quite the opposite: I think
> it's a critically important document, and I'm helping to make sure
> it's clear and correct in what it's saying.  I don't want to make
> changes to the process here.  I want to make sure there isn't
> something that, when something comes up that sends us to it, isn't
> clearly understandable.
> 
>> p.s. As the document editor, I will make the changes need to move this forward once I get direction from the w.g. chairs.
> 
> I have a large number of comments that are editorial, and which are
> not in the DISCUSS group.  Some of those are important, and some
> directly relate to errors in the text about IASA2 issues.  Please make
> sure you go through those and incorporate at least those in the latter
> group, along with any others that seem important enough to include.

Will do.

Bob


> 
> Barry