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

Bob Hinden <bob.hinden@gmail.com> Sun, 07 July 2019 16:12 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 BB419120046; Sun, 7 Jul 2019 09:12:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 13raeMujzVxp; Sun, 7 Jul 2019 09:12:51 -0700 (PDT)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 CB7C812001A; Sun, 7 Jul 2019 09:12:50 -0700 (PDT)
Received: by mail-wr1-x42f.google.com with SMTP id n4so14505343wrs.3; Sun, 07 Jul 2019 09:12:50 -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=enIg5i+me474C5rsgU2PkqDW/zbYrHqxsUH3N/yMptw=; b=TyQNbsvn1g1sxbU2+2wXdeaCWOF9sIdwwXVQ0D55+/VB2Tb4Qsh6A193Dtyj5xEkKA lk1j3yUiQavjbk9U8dkkGV7dA5ElzJ43zUVnp3g6fP9p3HOJPm1SC66gli591ZUeR7P0 rMsxd+NHmqK5k0KVJ4dtGpXuP96j5G0nFilZayeMUHxAFCibFoWewNgvUpUXesfUeEbe vAM7G2s5t+SOBG5GsKNmU4gH1stbrhCwLDGhrsIPFMxUCNYkDEJSlMG3KZ1IoOsPrbbL 1G3hKyZAiwXZXgQw0KkE32Zy0Oa150RHbKIBLLlcKAWDbEUjjXo/GiGVeChQgucNlCG+ +vXQ==
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=enIg5i+me474C5rsgU2PkqDW/zbYrHqxsUH3N/yMptw=; b=hoTf8HhxB4bbByz2J9BFuhbYIWQIjyqIbDJdMltV3fhEIFdTOJmugzuNCYSC4wGHQX efTqXm7Y9cEykzGn76Ha4nXUx1K+6WE0m3tQZK5U0+3zXJ7N3ffKPMz5dLrap9PMQDaw 7Uo/de0ICrt52mj7CPHbpHRANmQKX5At8AZLCyAh9QUjCUOhJpXtg/TiqfdyztC7WoRX hzMMpN5/aIGRxutAFCeRwWWtiBhTdn+BoPKOmly91qvLnYR/LbuqsJD7nVlmnhChjG2s v5/kQTQxyWGOvsSCG8mbU9akDy2aV6L54cCX5Jo5xdBap0nc9AXY5A3oKmh601Rv+6Pb QmZg==
X-Gm-Message-State: APjAAAU3fRXx7a1soGfq+MYpQ0O+PShTjA6sGRPNjQsvshgQfwhHYGoY K34G+UsztH5G2nibiPbRKzc=
X-Google-Smtp-Source: APXvYqxPQNLz8IH9iBF2cC+pQmyPispVHcw/eo2lzkV5M6TBIZn8HWc3HghLJqL9gr5cjWhEuV16NA==
X-Received: by 2002:a05:6000:14b:: with SMTP id r11mr14261783wrx.196.1562515969266; Sun, 07 Jul 2019 09:12:49 -0700 (PDT)
Received: from ?IPv6:2601:647:5a00:ef0b:7156:c06c:df94:4f8a? ([2601:647:5a00:ef0b:7156:c06c:df94:4f8a]) by smtp.gmail.com with ESMTPSA id z1sm14773632wrv.90.2019.07.07.09.12.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Jul 2019 09:12:48 -0700 (PDT)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <2962D9D5-314D-4E4F-A619-49948D01D3E9@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_C42C88C5-0D1E-4627-B7A5-B37719D8CD51"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sun, 07 Jul 2019 09:12:44 -0700
In-Reply-To: <CAHw9_iLDNBp08b=iTZadncvixkoEw-pazmD8B8xW8itzrPFvqQ@mail.gmail.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Brian Carpenter <brian.e.carpenter@gmail.com>, IASA 2 WG <iasa20@ietf.org>, Alissa Cooper <alissa@cooperw.in>, IESG <iesg@ietf.org>
To: Warren Kumari <warren@kumari.net>
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>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/NXkO2gZCgIj-kLGtmT821p4G3XI>
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: Discussions relating to reorganising the IETF administrative structures in the so called “IASA 2.0” project. <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: Sun, 07 Jul 2019 16:12:54 -0000

Warren,

> On Jul 7, 2019, at 6:03 AM, Warren Kumari <warren@kumari.net> wrote:
> 
> [ Replying midway through the thread, because this seemed to be the
> most appropriate message to reply to ]
> 
> On Fri, Jul 5, 2019 at 1:59 PM Stephen Farrell
> <stephen.farrell@cs.tcd.ie> wrote:
>> 
>> 
>> On 05/07/2019 21:43, Bob Hinden wrote:
>>> Hi,
>>> 
>>>> On Jul 5, 2019, at 1:10 PM, Brian E Carpenter
>>>> <brian.e.carpenter@gmail.com> wrote:
>>>> 
>>>> I'm with Alissa on this. There are quite a lot of reasons why we
>>>> might need RFC7437bisbis, some of which are much more serious than
>>>> the various points raised by several ADs, but I believe we should
>>>> first wrap up the changes required by the creation of IETF LLC.
>>> 
>>> I agree.  Especially since we have a working LLC signing contracts
>>> for us, spending money, etc, etc.  The IETF process documents like
>>> RFC7437 need to be aligned as soon a possible.
>>> 
>>>> 
>>>> I don't think rechartering IASA2 for this purpose would be
>>>> appropriate at all. Starting a process that might lead to a new
>>>> version of the POISED, POISED95 or POISSON WG would seem more
>>>> suitable. See https://datatracker.ietf.org/wg/poisson/about/ for
>>>> example.
>>> 
>>> I also agree.  Making changes to the NomCom process needs a new w.g.
>>> focused on that.   That is not the focus on the IASA 2.0 w.g., nor
>>> should it be.
>> 
>> FWIW, I also agree with Brian and Bob.
>> 
>> I'm not sure how much real energy there may be for a
>> concrete set of work items for a POISED-like thing,
>> but I do agree there're a set of potential work items
>> each of which likely has a bunch of people who'd like
>> to see 'em addressed.
>> 
>> But yes, not in this WG, and not in a way that'd
>> prevent finishing the chartered work here.
> 
> I've just changed my position from DISCUSS to NoObjection, and added:
> -----
> NOTE:
> My original position was DISCUSS - I'm changing it to NoObjection, but
> I'm still quite uncomfortable with this -- I view NoObjection as
> signalling that I'm comfortable with the document.
> "The IESG is expected to ensure that the documents are of a sufficient
> quality for release as RFCs, that they describe their subject matter
> well, and that there are no outstanding engineering issues that should
> be addressed before publication. The degree of review will vary with
> the intended status and perceived importance of the documents."
> (RFC3710).

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

  https://datatracker.ietf.org/doc/rfc7437/ballot/

As far as I can tell, your comments all relate to original text approved in 2014.   The datatracker shows that Barry was on that IESG and he voted YES.

Why is it OK for ADs to create new Discusses on something an earlier IESG approved.   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.

Also, a great deal of irony that most of the current IESG was appointed by the process defined in this document.  It seems like it works.

Bob

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 view this document as very important, but as whole I don't think it
> is "of a sufficient quality for release as RFC" and that it
> "describe(s) their subject matter well" - there are some open
> questions / places where clarification would help. I fully understand
> the need to patch this to support IASA2 (and it's the right thing to
> do), and the reasoning behind not opening up the entire document for
> review and fixing all the bugs...
> The paragraph which says "This revision addresses only the changes
> required for IASA 2.0;should the community agree on other changes,
> they will be addressed in future documents." addresses basically all
> of my concerns, but I'd be **much** happier (and would be comfortable
> voting "Yes") if it were moved from the Introduction into the Abstract
> or made more prominent in some other way. "
> ------
> 
> I *did* read the "This revision addresses only the changes ..." when
> originally reviewing document, but it is somewhat buried. I nodded,
> thought "fair 'nuff, makes sense", and then stumbled when I found nits
> / areas to be clarified.
> I think that this is a really important document, and support us
> making it compatible with IASA 2.0 (duh!) -- but I really don't want
> others to miss this important bit and think that No Objection means
> that I think all of the document is perfect, or that we don't still
> have areas for improvement.
> 
> W
> 
> 
> 
>> 
>> S.
>> 
>>> 
>>> Thanks, Bob
>>> 
>>> 
>>>> 
>>>> Regards Brian Carpenter
>>>> 
>>>> On 06-Jul-19 06:41, Alissa Cooper wrote:
>>>>> Dear IESG,
>>>>> 
>>>>> I wanted to draw your special attention to this text in
>>>>> draft-ietf-iasa2-rfc7437bis:
>>>>> 
>>>>> "This revision addresses only the changes required for IASA 2.0;
>>>>> should the community agree on other changes, they will be
>>>>> addressed in future documents.”
>>>>> 
>>>>> As well as this text in the IASA2 WG charter:
>>>>> 
>>>>> "This working group is chartered to document the normative
>>>>> changes to IETF administrative structures and processes necessary
>>>>> to effectuate [the change to IASA 2.0].”
>>>>> 
>>>>> If the IESG is not going to allow draft-ietf-iasa2-rfc7437bis or
>>>>> other IASA2 documents to progress unless changes unrelated to
>>>>> IASA 2.0 are made, I think the WG needs to be rechartered. The
>>>>> authors and the WG purposefully did not make any other changes to
>>>>> the base documents, so making other changes as a result of IESG
>>>>> evaluation does not seem appropriate. I think the appropriate
>>>>> thing to do would be for ADs who want to see that happen to start
>>>>> a thread about re-chartering on the iasa20 list. (Note: this is
>>>>> not my preference since I suspect it will delay the minimal
>>>>> changes related to IASA 2.0 from being published for a long time,
>>>>> but if that’s what the community wants I’ll support it.)
>>>>> 
>>>>> Thanks, Alissa
>>>>> 
>>>>> 
>>>>> _______________________________________________ iasa20 mailing
>>>>> list iasa20@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/iasa20
>>>>> 
>>>> 
>>>> _______________________________________________ iasa20 mailing
>>>> list iasa20@ietf.org https://www.ietf.org/mailman/listinfo/iasa20
>>> 
>>> 
>>> _______________________________________________ iasa20 mailing list
>>> iasa20@ietf.org https://www.ietf.org/mailman/listinfo/iasa20
>>> 
> 
> 
> 
> --
> 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