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

[Eric Rescorla <[e-mail]>]

On Wed, Feb 17, 2021 at 7:54 AM 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.
>

This seems right to me as well.

-Ekr


> 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
>