Re: [Rfced-future] 2nd draft : Non-approval resolution

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 17 February 2021 19:47 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B6C3A0E65 for <rfced-future@ietfa.amsl.com>; Wed, 17 Feb 2021 11:47:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 3p5uhWYlqybU for <rfced-future@ietfa.amsl.com>; Wed, 17 Feb 2021 11:47:46 -0800 (PST)
Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 F23293A1CE8 for <rfced-future@iab.org>; Wed, 17 Feb 2021 11:47:45 -0800 (PST)
Received: by mail-pl1-x62e.google.com with SMTP id b8so7969994plh.12 for <rfced-future@iab.org>; Wed, 17 Feb 2021 11:47:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=foOxuzHd3glQYeIWJDyD431ElU3280NGwvFooi/XEHo=; b=ZzNm7SeDfVl7IyUUCygbawTYottofzNgdzltcL51H0dHUD+glIEZIke9rDY2+cDUpT ONxJOtHZr2RT+mPJw75G78no6WaDbtJLUo62TQjYF2A0gsJoTwXk3wGDMeoEbiOytWeq reQ4xxySStTF4QSwd4IU5Vx1GOk31+cofKBRVgeJCZq754Rw0rMIZh/7SgNqdquuYt7B 1l8tQxmmsLbidD2ptC0Js7Kd5Y+SlhSIzdA+pmNxmNrE2wGw4wAiQH6BkxlychyIGRL0 aWoLiBZkugdl2brBUdSJtZ0RnhcOlF1Ant3muD6ZGRon5DIEwjUmwUgs4O48SuCagAus hQEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=foOxuzHd3glQYeIWJDyD431ElU3280NGwvFooi/XEHo=; b=N68d0JK1EBNALw7fiMLnQTRrL7VE6/0almfaK9EwN8kSr3ZfzI4jjNqvn5QwQTtZj/ 9UFp0RRb0Rc4OmnTu/DFH9hQvROj2zqnb3QeAjtXZVSQ1SQ7mmy0SJEFrTEyXlZoEqZd SXeL7YyR1LxFboykb8In4xJ3Ww1/ElPk/mzhsYyx4ni/n/qWXU8EgpoP6A1U+vUUGX7o qBBetPr5cNPn4q2oKv8AOWy+SktRuL4MDURZXlQeFWP62s9idmG4EkvpagafXqoYG9cT oypume3nD5sBlCK2JavVnsht/WMbIs4Z85Qx1McgfjPe8BKKt9RkcIoq6uhUzlGTryyl d1wQ==
X-Gm-Message-State: AOAM530dog2AsQxFdpngm6slWyu37AIGY+skgHkIsA5kOPn+FtIWTzPV LtgSPCm4YL2yPAHWqAS2TZceKqwDPwib9Q==
X-Google-Smtp-Source: ABdhPJyDWa4PxsctFhQuo5LJEEdRJWVyB8HLyyBrWybBM7rN7f2zGnitW6r02OP/uYh2yb2zI1DFhg==
X-Received: by 2002:a17:90a:bd84:: with SMTP id z4mr381598pjr.179.1613591264675; Wed, 17 Feb 2021 11:47:44 -0800 (PST)
Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id fz24sm2995529pjb.35.2021.02.17.11.47.42 for <rfced-future@iab.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Feb 2021 11:47:44 -0800 (PST)
To: rfced-future@iab.org
References: <028b01d7047a$84329e30$8c97da90$@olddog.co.uk> <5D4A110C-9FC3-4533-9827-67BB9CD520A6@mnot.net> <DD70DA92-C7A8-403E-AAE2-3B88748EC08B@vigilsec.com> <FB25DFB1-8294-45DA-8A92-5AF77FF019B5@cisco.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <e699bcaf-8570-3c63-9fe7-beced23dcbd0@gmail.com>
Date: Thu, 18 Feb 2021 08:47:41 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <FB25DFB1-8294-45DA-8A92-5AF77FF019B5@cisco.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/vuU7ntGfHa_rAGHaWx3iBLtmp3g>
Subject: Re: [Rfced-future] 2nd draft : Non-approval resolution
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program <rfced-future.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/rfced-future>, <mailto:rfced-future-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfced-future/>
List-Post: <mailto:rfced-future@iab.org>
List-Help: <mailto:rfced-future-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/rfced-future>, <mailto:rfced-future-request@iab.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Feb 2021 19:47:48 -0000

On 18-Feb-21 05:28, Eliot Lear wrote:
> Well, that’s a question:
> 
> What is the likely nature of the appeal?  If it is a question of whether or not the DISCUSSes are permitted, that seems pretty close to technical.  Will this change harm the series?  Will this change harm the stream?  Who gets to second guess on that?  Anyone?  Or are we talking about process appeals a’la were A-G properly followed?

In the IETF process, the IAB's appeal role is limited by:

"is final with respect to the question of whether or
not the [Internet standards] procedures have been followed and with
respect to all questions of technical merit."

and the ISOC Board's role is limited by:

"only in cases in which the procedures
themselves (i.e., the procedures described in this document) are
claimed to be inadequate or insufficient to the protection of the
rights of all parties in a fair and open [Internet Standards] Process."

It seems to me we could wordsmith equivalent limits for this case,
basically by removing the words in brackets, as long as the IAB and
ISOC Board's roles are carefully limited.

(I also believe that at the end of all this, the IAB Charter will
need a little tweak, but that can be left aside for now.)

Regards
   Brian C

> 
> Eliot
> 
> 
>> On 17 Feb 2021, at 16:53, Russ Housley <housley@vigilsec.com> wrote:
>>
>> The IAB charter (RFC 2850) makes me think that the IAB should handle appeals.  The ISOC BoT could be a second level for non-technical concerns.
>>
>> Russ
>>
>>
>>> On Feb 17, 2021, at 1:20 AM, Mark Nottingham <mnot@mnot.net> wrote:
>>>
>>> This looks good.
>>>
>>> Regarding appeals -- perhaps we could make progress by listing possible destinations for appeals and their positive/negative aspects.
>>>
>>> To get us started:
>>>
>>> * The IESG -- not a good idea; only the IETF. Already represented on the approval group.
>>> * The IAB -- Better than IESG in that it has a broader/long-term function, but also represented on the approval group.
>>> * Internet Society BoT (or Chair) -- has appropriate scope / distance; relationship to Series is a bit fuzzy?
>>>
>>> Any other candidates?
>>>
>>> Cheers,
>>>
>>>
>>>> On 17 Feb 2021, at 2:43 am, Adrian Farrel <adrian@olddog.co.uk> wrote:
>>>>
>>>> Hi,
>>>>
>>>> As previously noted, Eliot (lawd bless 'im) has bullied^H^H^H persuaded me
>>>> to take a second pass trying to factor in some of the comments on the list.
>>>>
>>>> I can't promise that I have captured *exactly* what everyone said,
>>>> especially as some of the opinions were conflicting. What I have done is try
>>>> to move the text towards something that might be a compromise between the
>>>> positions. FWIW, I went back to the "Discuss" position because it carries
>>>> some implication that we are all going to try to get together and resolve
>>>> this.
>>>>
>>>> I also tried to cut some of the waffle. I do tend to waffle.
>>>>
>>>> There are two open points. I'd humbly suggest that the people who raised
>>>> these issues might try to throw some text at a solution.
>>>>
>>>> 1. At point C there is the concept of a "community last call". This was
>>>> raised by Martin and Russ, and I suggest that they put forward a proposal.
>>>> The challenge might be to find a way to identify and reach the "community"
>>>> (it's easy in the IETF, but very hard for "the world").
>>>>
>>>> 2. At point J there is the concept of "an appeal" in the case of Discusses
>>>> being unreconcilable. This was raised by Adam and Mark. The challenge, as
>>>> they noted, is working out to whom one appeals.
>>>>
>>>> Hope this is useful (which is, after all, the only point).
>>>>
>>>> Adrian
>>>>
>>>> ====
>>>>
>>>> Decision-making procedures
>>>>
>>>> A. Development Cycle
>>>> The WG is expected to show its work to the approval group and attempt to be
>>>> aware of issues that the approval group might be concerned about.
>>>> The members of the approval group are expected to pay attention to the work
>>>> of the WG and speak up when they have concerns.
>>>> The intention is early discovery of issues and avoidance of late surprises.
>>>>
>>>> B. WG last call
>>>> The WG last calls its work following the model of an IETF WG. It is assumed
>>>> that all members of the approval group will participate the WG last call, in
>>>> an attempt to expose any of their concerns that still remain, and to reach
>>>> agreement.
>>>>
>>>> C. Community last call / public comment
>>>> It is unclear whether this step (corresponding to IETF last call) exists and
>>>> how it would be operated. Further discussion needed per Martin and Russ.
>>>>
>>>> D. Participation by members of the approval group
>>>> As noted in steps A and B, participation in WG work by members of the
>>>> approval group is expected.
>>>> It is understood that, from time to time, a member of the approval group may
>>>> find it impossible to participate in a particular discussion: in this case,
>>>> they are encourage to send delegates.
>>>>
>>>> E. Discussion by the approval group
>>>> The approval group shall discuss the output of the WG.
>>>> Such discussion is to take place normally within 2 weeks of the WG making a
>>>> request.
>>>> The 2 week period may be stretched by holidays or IETF meetings, but the WG
>>>> must be notified if this is the case.
>>>> All comments and concerns shall be documented to the WG which may take them
>>>> into consideration.
>>>>
>>>> F. Approval by the approval group
>>>> The voting members of the approval group shall formally ballot by the end of
>>>> the discussion period in E.
>>>> Each voting member may ballot one of:
>>>> - Yes: Means "I support this work." A Yes ballot may be accompanied by
>>>> comments indicating thoughts and issues that should be looked at, but are
>>>> non-blocking.
>>>> - Discuss: Means "I have a serious concern that I would like to Discuss
>>>> before this work can proceed." Voting members are expected to actively
>>>> engage in resolving their Discuss positions.
>>>> - No Position: Only used in exceptional cases such as illness or long
>>>> vacation. Voting members are expected to try to present a different ballot
>>>> position.
>>>> - Abstain: Means "I have a serious concern, but recognise that it will not
>>>> be resolved." An Abstain ballot is a way for a voting member to get out of
>>>> the way of progress even though it worries them. The existence of an Abstain
>>>> ballot does not imply the work is flawed, but indicates a genuinely
>>>> irreconcilable difference of opinion.
>>>> - Recuse: Means "It would be improper for me to have a position." For
>>>> example, if the proposal was to remunerate the voting member.
>>>>
>>>> G. Reasons for a Discuss
>>>> The approval group shall maintain a list of reasons for a Discuss ballot. A
>>>> Discuss that does not conform to one of these reasons shall not be valid,
>>>> and must be re-balloted.
>>>> An initial draft of this list is as follows:
>>>> - The proposal would cause significant harm to one of the streams
>>>> - The proposal would cause significant harm to the series
>>>> - The proposal would cause inconvenience to a group of consumers, the
>>>> benefit of the change does not outweigh the cost of the inconvenience, and
>>>> that inconvenience could be overcome by using a different approach
>>>>
>>>> G. Work proceeds if...
>>>> At the end of the discussion period (point E) or at any later time, there is
>>>> at least one "Yes" and no "Discuss" ballot. That is, work fails to proceed
>>>> unless it has approval.
>>>>
>>>> H. Resolution of Discusses
>>>> A voting member who ballots Discuss shall explain their concerns to the WG
>>>> and shall engage in discussions attempting to resolve the concerns and
>>>> arrive at a compromise or other agreement.
>>>> When such agreement is reached, the voting member should transition their
>>>> ballot to a "Yes".
>>>> A voting member may transition their ballot to an "Abstain" at any time,
>>>> although all parties are encouraged to attempt to reach agreement.
>>>>
>>>> I. Single Discuss resolution
>>>> In the event of there being exactly one Discuss ballot, and there being no
>>>> timely progress to agreement between the WG and the member of the approval
>>>> group who issued the ballot, the WG may request that the approval group
>>>> exercise an exception resolution process as follows:
>>>> - The approval group will discuss the concern giving rise to the ballot and
>>>> any proposed resolution from the WG
>>>> - The approval group shall attempt to reach consensus on whether to sustain
>>>> the Discuss or to release the work, but failing that shall vote with a
>>>> simple majority determining the outcome
>>>> - If the Discuss is sustained, return to step H
>>>> - If the work is released, the Discuss ballot shall be changed to an Abstain
>>>> and the work shall progress
>>>>
>>>> J. Appeals
>>>> In the event that more than one Discuss cannot be resolved or that a single
>>>> Discuss is sustained by the approval group, there is a right of appeal.
>>>> The details of this need to be worked out per Adam and Mark.
>>>>
>>>>
>>>>
>>>> --
>>>> Rfced-future mailing list
>>>> Rfced-future@iab.org
>>>> https://www.iab.org/mailman/listinfo/rfced-future
>>>
>>> --
>>> Mark Nottingham   https://www.mnot.net/
>>>
>>> --
>>> Rfced-future mailing list
>>> Rfced-future@iab.org
>>> https://www.iab.org/mailman/listinfo/rfced-future
>>
>> --
>> Rfced-future mailing list
>> Rfced-future@iab.org
>> https://www.iab.org/mailman/listinfo/rfced-future
> 
>