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

[Eliot Lear <[e-mail]>]

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?

Eliot


> On 17 Feb 2021, at 16:53, Russ Housley <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
>>> [e-mail]
>>> https://www.iab.org/mailman/listinfo/rfced-future
>> 
>> --
>> Mark Nottingham   https://www.mnot.net/
>> 
>> --
>> Rfced-future mailing list
>> [e-mail]
>> https://www.iab.org/mailman/listinfo/rfced-future
> 
> --
> Rfced-future mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/rfced-future