Subject: [Rfced-future] Consensus Call for Chairs Proposal: Please comment by April 13th

From: Eliot Lear <[email-masked]>
Date: Tue, 30 Mar 2021 19:51:20 +0200

The chairs appreciate comments received, and we now believe that it is ok to start a  consensus call on the chairs’ proposal on both the draft evolution process and the RSE hire and accountability text, taken as a whole.  If you have already indicated your support for the proposal, the chairs will note this.  We would like to hear from all interested participants.  If you would like to indicate either support or objection, please feel free to do so by Tuesday, April 13th.

If there is rough consensus, this text will be included in the editor’s draft.  It can be further amended with rough consensus, and the chairs expect there to be some of that.  Again, we see this as compromise text, and so we are hoping that this is a good enough starting point for further modifications.

As a reminder, we have an interim meeting scheduled for next Tuesday, April 6th, 2021, at 20:00 GMT, when of course this proposal will be on the agenda for people to discuss.  More about that agenda in the next day or two.

The text can be found on GitHub in two parts at the following URLs:

https://github.com/intarchboard/program-rfced-future/blob/master/draft-evolution-process.md <https://github.com/intarchboard/program-rfced-future/blob/master/draft-evolution-process.md>
https://github.com/intarchboard/program-rfced-future/blob/master/rse-hire-and-accountability.md <https://github.com/intarchboard/program-rfced-future/blob/master/rse-hire-and-accountability.md>

And it is below for your consideration as well.

Brian and Eliot

DRAFT RFC Evolution Process

 <https://github.com/intarchboard/program-rfced-future/blob/master/draft-evolution-process.md#scope>
Scope

This procedure is applicable to the evolution processes relating to the management and evolution of the RFC series, including format, tooling, publication, dissemination, and overall management of the series.

 <https://github.com/intarchboard/program-rfced-future/blob/master/draft-evolution-process.md#structure>
Structure

The RFC evolution process is governed as follows:

The RFC Working Group, whose job it is to develop proposed changes, and establish community consensus of those changes.
The The RFC Approval Board, whose job it is to provide final review of proposals.
Each group is described below.

 <https://github.com/intarchboard/program-rfced-future/blob/master/draft-evolution-process.md#the-rfc-working-group-rfcwg>
The RFC Working Group (RFCWG)

All RFCWG meetings are open to any participant, subject to intellectual property policies which must be consistent to those of the IETF [Note Well]. At body's initial formation, all discussions are to take place on open mailing lists, and anyone is welcome to comment / discuss. The RFCWG may decide by rough consensus to use additional forms of communication (for example, Github as specified in [RFC8874]) that are consistent with [RFC2418]. The group will conform itself to an anti-harassment policy consistent with [RFC7154,RFC7776].

IETF chair and the Independent Submissions Editor shall each appoint and oversee a co-chair of the RFCWG.

 <https://github.com/intarchboard/program-rfced-future/blob/master/draft-evolution-process.md#the-rfc-approval-board-rfcab>
The RFC Approval Board (RFCAB)

The RFC Approval Board consists of representatives from each RFC stream (at the time of this writing, the IAB, the IETF, the IRTF, and the Indepenent Series), as well as the RS[EA]. The sole function of this group is to review draft proposals approvedby the RFCWG. The RFCAB may choose its chair as it sees fit. The group is primarily expected to operate via email and through any necessary tooling. A record of all proceedings (no matter the form) will be kept.

 <https://github.com/intarchboard/program-rfced-future/blob/master/draft-evolution-process.md#update-process>
Update Process

The following procedure is used to update the RFC process:

Someone writes a draft proposal in the form of an Internet-Draft.

If there is sufficient interest in the proposal, RFCWG will adopt the proposal as a working draft, much the same way a working group of the IETF would.

The RFCWG will then further develop the proposal. All members of the RFCAB are expected to participate in discussion relating to all proposals.

At some point, if the chairs believe there may be rough consensus exists for the proposal to advance, they will issue a working group last call.

After a suitable period of time, the chairs will determine whether rough consensus for the proposal exists.  If comments have been received and substantial changes have been made, it is expected that additional last calls may be made.

Once working group consensus is established, a community call for comments will be issued. Should substantial comments be received, the working group will again consider those comments and make revisions as they see fit. At this same time, the RFCAB will consider the proposal.

Should substantial changes be made, additional community calls for comment should be issued, and again comments considered.

Once all comments have been been addressed, the working group chairs will transmit the latest proposal to the RFCAB.

Within a reasonable period of time, the RFCAB will then poll on the proposal. Positions may be as follows:

"YES": the proposal should be approved
"CONCERN" : the proposal raises substantial concerns that must be addressed.
"RECUSE" : the person holding the position has a conflict of interest.
Anyone holding a "CONCERN" position MUST explain their concern to the community in detail. The explanation may or may not be actionable.

A CONCERN may be made for two reasons:

The proposal represents a serious problem for the group a particular member represents.
The member believes that the proposal would cause serious harm to the overall series, including harm to the long term health and viability of the series.
No CONCERN should ever come as a surprise to the RFCWG.

If a CONCERN exists, discussion will take place within the RFCWG. Again, all RFCAB members MUST participate.

If all CONCERN positions are addressed, then the proposal is approved. Again, if substantial changes have been made, an additional call for community input should be made.

If, after a suitable period of time, any CONCERN positions remain, a formal vote of the RFCAB is taken. If a majority of RFCAB members vote to approve, the proposal is approved. Otherwise, it is returned to the RFCWG. In the case of a tie, the proposal is approved.

When a proposal is approved, a notification is sent to the community, and it is published as an RFC.

 <https://github.com/intarchboard/program-rfced-future/blob/master/draft-evolution-process.md#the-roles-of-the-llc-board-and-ed>
The roles of the LLC Board and ED

LLC Board members, staff, and the Executive Director, are invited to participate as community members in the RFCWG to the extent permitted by any relevant LLC policies.

 <https://github.com/intarchboard/program-rfced-future/blob/master/draft-evolution-process.md#appeals>
Appeals

Appeals of RFCAB decisions may only be made based on process failures, and not on the substance of a proposal. These appeals SHALL be made to the ISOC BoT within thirty days of the RFCAB decision. The ISOC BoT MAY decide only whether a process failure occurred, and what if any corrective action should take place.

 <https://github.com/intarchboard/program-rfced-future/blob/master/draft-evolution-process.md#discussion>
Discussion

The intent of this policy is to provide an open forum by which policies and procedures of the RFC series are evolved. The general expectation is that all interested parties will participate in the RFCWG, and that only under extreme circumstances should the RFCAB members have to hold "CONCERN" positions. To avoid that situation, WG members are encouraged to take RFCAB concerns seriously, and RFCAB members are encouraged to make those concerns known early, and to be responsive to the community. In particular, people are encouraged to respect the value of each stream, and the long term health and viability of the RFC series.

This process is intended to be one of continuous consultation. In particular, RFCAB members should be consulting with their constuent groups on an ongoing basis, so that when the time comes to consider a proposal, there should be no surprises. Appointing bodies are expected to establish whatever processes they deem appropriate to facilitate this goal.

DRAFT DRAFT DRAFT

 <https://github.com/intarchboard/program-rfced-future/blob/master/rse-hire-and-accountability.md#rsea-selection>
RS[EA] Selection

The RS[EA] will be searched for and vetted by a committee formed by the ED, taking into account the role definition <https://github.com/intarchboard/program-rfced-future/blob/master/Issue12-RSE-role.md> and any detailed job description that we further develop. The search committee may ask others to take part in the selection process in confidence. The initial length of service shall be for one year, but then further extensions will be for three to five years.

 <https://github.com/intarchboard/program-rfced-future/blob/master/rse-hire-and-accountability.md#rsea-ongoing-performance-evaluation>
RS[EA] Ongoing Performance Evaluation

Periodically, the ED will send out to the community a call for input on the performance of the RS[EA]. The evaluation will be based on criteria specified in the role definition. Was the RS[EA] an active participant in all/most meetings? Did the RS[EA] provide useful advice to the RPC and to the WG? Did the RS[EA] exercise good judgment in terms of any role he or she would have had on the Approval Body? Was the RS[EA] effective in advising the community on appropriate actions to take or not take?

The ED will then review the feedback, consulting with stream manager representatives, and then produce a recommendation to the LLC Board. The LLC will then make a decision, taking into account that recommendation.

Whether the RS[EA] role is structured as a contractual or employee relationship is left to the LLC and ED to determine.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 30 Mar 2021 16:46:23 -0400

I support using those two pieces of text as the WG starting point for 
building a document and process we can get (rough) consensus on.

Yours,
Joel

On 3/30/2021 1:51 PM, Eliot Lear wrote:
> The chairs appreciate comments received, and we now believe that it is 
> ok to start a  consensus call on the chairs’ proposal on both the draft 
> evolution process and the RSE hire and accountability text, taken as a 
> whole.  If you have already indicated your support for the proposal, the 
> chairs will note this. *We would like to hear from all interested 
> participants*.  If you would like to indicate either support or 
> objection, please feel free to do so by Tuesday, April 13th.
> 
> If there is rough consensus, this text will be included in the editor’s 
> draft.  It can be further amended with rough consensus, and the chairs 
> expect there to be some of that.  Again, we see this as compromise text, 
> and so we are hoping that this is a good enough starting point for 
> further modifications.
> 
> As a reminder, we have an interim meeting scheduled for next Tuesday, 
> April 6th, 2021, at 20:00 GMT, when of course this proposal will be on 
> the agenda for people to discuss.  More about that agenda in the next 
> day or two.
> 
> https://github.com/intarchboard/program-rfced-future/blob/master/draft-evolution-process.md 
> <https://github.com/intarchboard/program-rfced-future/blob/master/draft-evolution-process.md>
> https://github.com/intarchboard/program-rfced-future/blob/master/rse-hire-and-accountability.md 
> <https://github.com/intarchboard/program-rfced-future/blob/master/rse-hire-and-accountability.md>
> 
> This procedure is applicable to the evolution processes relating to the 
> management and evolution of the RFC series, including format, tooling, 
> publication, dissemination, and overall management of the series.
> 
> 
>   * The RFC Working Group, whose job it is to develop proposed changes,
>     and establish community consensus of those changes.
>   * The The RFC Approval Board, whose job it is to provide final review
>     of proposals.
> 
> All RFCWG meetings are open to any participant, subject to intellectual 
> property policies which must be consistent to those of the IETF [Note 
> Well]. At body's initial formation, all discussions are to take place on 
> open mailing lists, and anyone is welcome to comment / discuss. The 
> RFCWG may decide by rough consensus to use additional forms of 
> communication (for example, Github as specified in [RFC8874]) that are 
> consistent with [RFC2418]. The group will conform itself to an 
> anti-harassment policy consistent with [RFC7154,RFC7776].
> 
> The RFC Approval Board consists of representatives from each RFC stream 
> (at the time of this writing, the IAB, the IETF, the IRTF, and the 
> Indepenent Series), as well as the RS[EA]. The sole function of this 
> group is to review draft proposals approvedby the RFCWG. The RFCAB may 
> choose its chair as it sees fit. The group is primarily expected to 
> operate via email and through any necessary tooling. A record of all 
> proceedings (no matter the form) will be kept.
> 
> 
>  1.
>  2.
>     If there is sufficient interest in the proposal, RFCWG will adopt
>     the proposal as a working draft, much the same way a working group
>     of the IETF would.
> 
>  3.
> 
>     The RFCWG will then further develop the proposal. All members of the
>     RFCAB are expected to participate in discussion relating to all
>     proposals.
> 
>  4.
> 
>     At some point, if the chairs believe there may be rough consensus
>     exists for the proposal to advance, they will issue a working group
>     last call.
> 
>  5.
> 
>     After a suitable period of time, the chairs will determine whether
>     rough consensus for the proposal exists.  If comments have been
>     received and substantial changes have been made, it is expected that
>     additional last calls may be made.
> 
>  6.
> 
>     Once working group consensus is established, a community call for
>     comments will be issued. Should substantial comments be received,
>     the working group will again consider those comments and make
>     revisions as they see fit. At this same time, the RFCAB will
>     consider the proposal.
> 
>  7.
> 
>     Should substantial changes be made, additional community calls for
>     comment should be issued, and again comments considered.
> 
>  8.
> 
>     Once all comments have been been addressed, the working group chairs
>     will transmit the latest proposal to the RFCAB.
> 
>  9.
> 
>       * "YES": the proposal should be approved
>       * "CONCERN" : the proposal raises substantial concerns that must
>         be addressed.
>       * "RECUSE" : the person holding the position has a conflict of
>         interest.
> 
>     Anyone holding a "CONCERN" position MUST explain their concern to
>     the community in detail. The explanation may or may not be actionable.
> 
>       * The proposal represents a serious problem for the group a
>         particular member represents.
>       * The member believes that the proposal would cause serious harm
>         to the overall series, including harm to the long term health
>         and viability of the series.
> 
> 10.
>     If a CONCERN exists, discussion will take place within the RFCWG.
>     Again, all RFCAB members MUST participate.
> 
> 11.
> 
>     If all CONCERN positions are addressed, then the proposal is
>     approved. Again, if substantial changes have been made, an
>     additional call for community input should be made.
> 
> 12.
> 
>     If, after a suitable period of time, any CONCERN positions remain, a
>     formal vote of the RFCAB is taken. If a majority of RFCAB members
>     vote to approve, the proposal is approved. Otherwise, it is returned
>     to the RFCWG. In the case of a tie, the proposal is approved.
> 
> 13.
> 
>     When a proposal is approved, a notification is sent to the
>     community, and it is published as an RFC.
> 
> 
> LLC Board members, staff, and the Executive Director, are invited to 
> participate as community members in the RFCWG to the extent permitted by 
> any relevant LLC policies.
> 
> 
> Appeals of RFCAB decisions may only be made based on process failures, 
> and not on the substance of a proposal. These appeals SHALL be made to 
> the ISOC BoT within thirty days of the RFCAB decision. The ISOC BoT MAY 
> decide only whether a process failure occurred, and what if any 
> corrective action should take place.
> 
> 
> The intent of this policy is to provide an open forum by which policies 
> and procedures of the RFC series are evolved. The general expectation is 
> that all interested parties will participate in the RFCWG, and that only 
> under extreme circumstances should the RFCAB members have to hold 
> "CONCERN" positions. To avoid that situation, WG members are encouraged 
> to take RFCAB concerns seriously, and RFCAB members are encouraged to 
> make those concerns known early, and to be responsive to the community. 
> In particular, people are encouraged to respect the value of each 
> stream, and the long term health and viability of the RFC series.
> 
> This process is intended to be one of continuous consultation. In 
> particular, RFCAB members should be consulting with their constuent 
> groups on an ongoing basis, so that when the time comes to consider a 
> proposal, there should be no surprises. Appointing bodies are expected 
> to establish whatever processes they deem appropriate to facilitate this 
> goal.
> 
> 
>   DRAFT DRAFT DRAFT
> 
> 
> The RS[EA] will be searched for and vetted by a committee formed by the 
> ED, taking into account the role definition 
> <https://github.com/intarchboard/program-rfced-future/blob/master/Issue12-RSE-role.md> and 
> any detailed job description that we further develop. The search 
> committee may ask others to take part in the selection process in 
> confidence. The initial length of service shall be for one year, but 
> then further extensions will be for three to five years.
> 
> 
> Periodically, the ED will send out to the community a call for input on 
> the performance of the RS[EA]. The evaluation will be based on criteria 
> specified in the role definition. Was the RS[EA] an active participant 
> in all/most meetings? Did the RS[EA] provide useful advice to the RPC 
> and to the WG? Did the RS[EA] exercise good judgment in terms of any 
> role he or she would have had on the Approval Body? Was the RS[EA] 
> effective in advising the community on appropriate actions to take or 
> not take?
> 
> The ED will then review the feedback, consulting with stream manager 
> representatives, and then produce a recommendation to the LLC Board. The 
> LLC will then make a decision, taking into account that recommendation.
> 
> Whether the RS[EA] role is structured as a contractual or employee 
> relationship is left to the LLC and ED to determine.
> 
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 30 Mar 2021 23:12:19 +0100

Thanks Eliot and Brian for the work you’ve put into this.

I can support this version forming the basis of an I-D that we tinker with a little.

Nits (which can wait, but might as well be fixed going into the I-D):

s/the Indepenent Series/the Independent Stream/

s/approvedby/approved by/

s/there may be rough consensus exists/rough consensus exists/

s/constuent/constituent/

Cheers,

Adrian

From: Rfced-future <[email-masked]> On Behalf Of Eliot Lear
Sent: 30 March 2021 18:51
To: [email-masked]
Subject: [Rfced-future] Consensus Call for Chairs Proposal: Please comment by April 13th

Brian and Eliot

Scope

Structure

*	The RFC Working Group, whose job it is to develop proposed changes, and establish community consensus of those changes.
*	The The RFC Approval Board, whose job it is to provide final review of proposals.

Update Process

1.	Someone writes a draft proposal in the form of an Internet-Draft.
2.	If there is sufficient interest in the proposal, RFCWG will adopt the proposal as a working draft, much the same way a working group of the IETF would.
3.	The RFCWG will then further develop the proposal. All members of the RFCAB are expected to participate in discussion relating to all proposals.
4.	At some point, if the chairs believe there may be rough consensus exists for the proposal to advance, they will issue a working group last call.
5.	After a suitable period of time, the chairs will determine whether rough consensus for the proposal exists.  If comments have been received and substantial changes have been made, it is expected that additional last calls may be made.
6.	Once working group consensus is established, a community call for comments will be issued. Should substantial comments be received, the working group will again consider those comments and make revisions as they see fit. At this same time, the RFCAB will consider the proposal.
7.	Should substantial changes be made, additional community calls for comment should be issued, and again comments considered.
8.	Once all comments have been been addressed, the working group chairs will transmit the latest proposal to the RFCAB.
9.	Within a reasonable period of time, the RFCAB will then poll on the proposal. Positions may be as follows:

*	"YES": the proposal should be approved
*	"CONCERN" : the proposal raises substantial concerns that must be addressed.
*	"RECUSE" : the person holding the position has a conflict of interest.

*	The proposal represents a serious problem for the group a particular member represents.
*	The member believes that the proposal would cause serious harm to the overall series, including harm to the long term health and viability of the series.

10.	If a CONCERN exists, discussion will take place within the RFCWG. Again, all RFCAB members MUST participate.
11.	If all CONCERN positions are addressed, then the proposal is approved. Again, if substantial changes have been made, an additional call for community input should be made.
12.	If, after a suitable period of time, any CONCERN positions remain, a formal vote of the RFCAB is taken. If a majority of RFCAB members vote to approve, the proposal is approved. Otherwise, it is returned to the RFCWG. In the case of a tie, the proposal is approved.
13.	When a proposal is approved, a notification is sent to the community, and it is published as an RFC.

Appeals

Discussion

DRAFT DRAFT DRAFT

RS[EA] Selection

---

From: Nevil Brownlee <[email-masked]>
Date: Wed, 31 Mar 2021 16:48:22 +1300

Hi Eliot:
I agree that these two documents reflect all this group's discussions
to date, and make a good starting point for a final RFC.
I note that the "Role of the RSE/A" is in a separate file, that makes
it three documents to combine.
Also, since the "RSE/A Selection" document proposes that the LLC ED
will be responsible for the RSE/A, I wonder whether Jay has been
consulted about it?
CHeers, Nevil

On Wed, Mar 31, 2021 at 6:51 AM Eliot Lear
<lear=[email-masked]> wrote:
> The RS[EA] will be searched for and vetted by a committee formed by the ED, taking into account the role definition and any detailed job description that we further develop. The search committee may ask others to take part in the selection process in confidence. The initial length of service shall be for one year, but then further extensions will be for three to five years.
>
> --
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future

--
-----------------------------------
Nevil Brownlee, Taupo, NZ

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 31 Mar 2021 11:02:39 +0200

Hi Eliot, hi all,

Thanks for putting this together. I think this is a good starting point for a document. There are a couple of topics that didn’t get a lot of discussion yet and probably will need some more. E.g. I would consider the follow three points in that category:

- selection of the wg chairs
- ISOC in the appeal chain (if we all agree that we want that, we really should contact the BoT early on)
- Creation of the search committee

Mirja

> On 30. Mar 2021, at 19:51, Eliot Lear <lear=[email-masked]> wrote:
> 
> 	• The RFC Working Group, whose job it is to develop proposed changes, and establish community consensus of those changes.
> 	• The The RFC Approval Board, whose job it is to provide final review of proposals.
> 	• Someone writes a draft proposal in the form of an Internet-Draft.
> 
> 	• If there is sufficient interest in the proposal, RFCWG will adopt the proposal as a working draft, much the same way a working group of the IETF would.
> 
> 	• The RFCWG will then further develop the proposal. All members of the RFCAB are expected to participate in discussion relating to all proposals.
> 
> 	• At some point, if the chairs believe there may be rough consensus exists for the proposal to advance, they will issue a working group last call.
> 
> 	• After a suitable period of time, the chairs will determine whether rough consensus for the proposal exists.  If comments have been received and substantial changes have been made, it is expected that additional last calls may be made.
> 
> 	• Once working group consensus is established, a community call for comments will be issued. Should substantial comments be received, the working group will again consider those comments and make revisions as they see fit. At this same time, the RFCAB will consider the proposal.
> 
> 	• Should substantial changes be made, additional community calls for comment should be issued, and again comments considered.
> 
> 	• Once all comments have been been addressed, the working group chairs will transmit the latest proposal to the RFCAB.
> 
> 	• Within a reasonable period of time, the RFCAB will then poll on the proposal. Positions may be as follows:
> 
> 		• "YES": the proposal should be approved
> 		• "CONCERN" : the proposal raises substantial concerns that must be addressed.
> 		• "RECUSE" : the person holding the position has a conflict of interest.
> 		• The proposal represents a serious problem for the group a particular member represents.
> 		• The member believes that the proposal would cause serious harm to the overall series, including harm to the long term health and viability of the series.
> 	• If a CONCERN exists, discussion will take place within the RFCWG. Again, all RFCAB members MUST participate.
> 
> 	• If all CONCERN positions are addressed, then the proposal is approved. Again, if substantial changes have been made, an additional call for community input should be made.
> 
> 	• If, after a suitable period of time, any CONCERN positions remain, a formal vote of the RFCAB is taken. If a majority of RFCAB members vote to approve, the proposal is approved. Otherwise, it is returned to the RFCWG. In the case of a tie, the proposal is approved.
> 
> 	• When a proposal is approved, a notification is sent to the community, and it is published as an RFC.
> 
>

---

From: Eliot Lear <[email-masked]>
Date: Wed, 31 Mar 2021 14:09:40 +0200

[resend]

Thanks, Mirja.  Yes, I suspect that there will be a lot of discussion on the points you mentioned as we amend the base text.  Just to explain the logic of each of these:

> On 31 Mar 2021, at 11:02, Mirja Kuehlewind <[email-masked]> wrote:
> 
> Hi Eliot, hi all,
> 

These two address a point that Mike made: the IAB has an outsized influence on the AB because two members are directly appointed (the IAB stream representative and the ISE), and it has influence on two others (the IRTF stream and  IESG stream representatives).  As a stream manager, the IAB is conflicted.  Thus it should not be involved in process appeals when it could very easily be a party.  This, I believe, was Brian’s Carpenters original logic.  We similarly attempted to balance power in the chairs, recognizing that the ISOC BoT would probably not be in a good position to pick them.

Feel free to propose alternatives as we enter the next phase of this process.

> - Creation of the search committee

That was part and parcel of the proposal for oversight, which we thought had to be married to hiring.  Again, feel free to propose alternatives.

Eliot

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 31 Mar 2021 16:05:14 +0000

Nice job, I support this as the basis for moving forward.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 31 Mar 2021 18:16:15 +0200

Hi Eloit,

Just one quick comment/reply, or actually two, below (without intending to move this discussion too far for now).

> On 31. Mar 2021, at 14:09, Eliot Lear <lear=[email-masked]> wrote:
> 
> [resend]
> 

It’s very often the case for appeals to the IESG (if an appeal happen) that one of the ADs is part of the action that the appealed. Usually that’s not a problem as that AD of course recuses from any discussion of that appeal. If the appeal is against a decision of the AB (it could also be about a wg decision), the IAB stream manager and IRTF chair should recuse as well. I’m less concerned about the IAB picking the IRTF chair and ISE because usually these positions are rather long term (so it’s not the same IAB) and there is not influence by the IAB on these two people after the selection.

Regarding ISOC, I’m not sure how the BoT would feel about being kind of the first contact for an appeal (rather than something like a last resort as they are today). So what I was saying is if thee group wants that, we should urgently talk to them. But it feels to me that we first need to discuss a bit more to be sure what we want.

Mirja

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 1 Apr 2021 09:23:57 +1100

Hi Eliot,

I'm fine with this text, provided that we can file issues against this text and expect to have them seriously considered by the group. In other words, I'm interpreting your question here as what we'd consider a Call for Adoption in the WGs I participate in regularly -- this text is a good starting point, but isn't sacrosanct, and doesn't have any higher bar for changes than usual.

If your intent differs from that (e.g., we need some sort of consensus to even consider an issue), please say so.

Cheers,

> On 31 Mar 2021, at 4:51 am, Eliot Lear <lear=[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 1 Apr 2021 14:43:09 +1300

Support (repeating myself, I think). As long as we are not also adopting the draft on the RS[EA] role, which I feel needs more work before adoption.

Regards
   Brian Carpenter

On 31-Mar-21 06:51, Eliot Lear wrote:
> The chairs appreciate comments received, and we now believe that it is ok to start a  consensus call on the chairs’ proposal on both the draft evolution process and the RSE hire and accountability text, taken as a whole.  If you have already indicated your support for the proposal, the chairs will note this.  *We would like to hear from all interested participants*.  If you would like to indicate either support or objection, please feel free to do so by Tuesday, April 13th.
>