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

[Russ Housley <[e-mail]>]

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