| Network Working Group | S. Moonesamy |
| Internet-Draft | |
| Updates: 7437 (if approved) | J. Klensin |
| Intended status: Best Current Practice | March 23, 2019 |
| Expires: September 24, 2019 |
Revision of the Recall Initiation Model
draft-moonesamy-recall-rev-00
The procedures for initiating a recall specified in RFC 7437 restrict signatories to those who are "nomcom qualified". This document suggests those limitations were unanticipated and undesirable side-effects and proposes to remove them. It also proposes that remote participants should be allowed to seek redress through the procedures and decreases the number of signatories required for a recall petition.
This document is intended to update RFC 7437.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 24, 2019.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
[RFC7437] defines the procedures for a Member Recall. The first step of those procedures is to request a Member Recall by signed petition. This document suggests that making IAB and IESG members ineligible to initiate recalls was an undesirable side-effect and proposes to remove it. It also proposes to address the unfairness to which remote participants are subject by allowing them to be signatories of a recall petition. Section 2 discusses some of the issues affecting that step and provides the rationale. The updated text is in Section 3.
The procedures for initiating a recall specified in [RFC7437] restrict signatories to those who are "nomcom qualified". Perhaps inadvertently, this prohibits members of the IESG and IAB from initiating these procedures. This is probably not in the best interests of the community: if there is a problem within the IESG or IAB, other members of those bodies are likely to be aware of it before the IETF community.
Conversely, members of a sitting nomcom, since they are, by definition, nomcom-eligible, are now permitted to initiate recalls. For them to do so appears to be a singularly poor idea, especially in principle. The nomcom should not be in a position to lead in determining which positions are open, nor should its members be in a position to initiate removal of someone whom they hope to replace. In addition, any recall action initiated by sitting nomcom members, especially if they presume to act on behalf of the community, would inevitably raise suspicions that confidentiality had been compromised.
Some of the IETF Trustees [RFC4371] and IETF LLC Directors are appointed by NomCom. The procedures in [RFC7437] for a "recall petition" specifies "any sitting" member instead of the members who were appointed by Nomcom. There is a requirement to include a justification for a "recall petition". There is also a requirement for the member being recalled to be given an opportunity to present a written statement and consult with third parties. There is an assumption that those requirements are adequate for due process. As such, Section 3 does not distinguish between NomCom appointees and other appointing bodies.
In 2017, the IESG set a requirement for the registration of remote participants at IETF meetings. However, the procedures exclude those IETF participants from making a request for a Member Recall by signed petition.
According to [RFC3777], "Volunteers are expected to be familiar with the IETF processes and procedures, which are readily learned by active participation in a working group and especially by serving as a document editor or working group chair." There is also a "no more than two signatories may have the same primary affiliation" restriction. Restricting signatories to those who are "nomcom qualified" disenfranchises active remote participants who reside in emerging countries as they lack the extensive travel resources required to seek redress.
The "nomcom qualified" requirement for a recall petition is contrary to the spirit and one of the goals of the Internet Standards Process [RFC2026] about procedures which are intended to be fair.
[RFC7437] requires at least 20 signatories for a recall petition with no more than two of the signatories having the same primary affiliation. That sets a very high barrier for a recall petition even though the recall petition requires a, justification, an investigation by a Recall Committee and a 3/4 majority of the members of the Recall Committee who vote on the recall decision. This document also proposes to decrease the number of signatures required to avoid making it impractical to invoke the first step of the recall procedures.
The first paragraph of Section 7.1 of [RFC7437] is replaced by the following:
At any time, at least 10 members of the IETF community, may request by signed petition (email is acceptable) to the Internet Society President the recall of any sitting IAB or IESG member, IETF Trustee or IETF LLC Director. All signatories must have registered to attend and have participated physically or remotely at least three out of the previous five IETF meetings.
The last sentence in the fourth paragraph of Section 7.1 of [RFC7437] is replaced by the following:
A valid petition must be signed by qualified signatories as specified in this section.
The authors would like to thank Adrian Farrel for some of the text in Section 3. and Brian Carpenter and Spencer Dawkins for several discussions and comments that helped stimulate this draft.
This document does not require any IANA actions,
This document discusses IETF procedures. It raises no security issues for the Internet.
The risks of permitting IESG or IAB members, or remote participants from abusing process by initiating a recall seem minimal: they remain ineligible to be members of the recall committee itself and the community would presumably swiftly oppose such abuse.
| [RFC7437] | Kucherawy, M., "IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", BCP 10, RFC 7437, DOI 10.17487/RFC7437, January 2015. |
| [RFC2026] | Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996. |
| [RFC3777] | Galvin, J., "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", RFC 3777, DOI 10.17487/RFC3777, June 2004. |
| [RFC4371] | Carpenter, B. and L. Lynch, "BCP 101 Update for IPR Trust", BCP 101, RFC 4371, DOI 10.17487/RFC4371, January 2006. |
RFC Editor: Please remove this appendix before publication.
The original recall procedure, as specified in RFC 2027, allowed a single person, without any restrictions, to petition the Internet Society President and initiate a recall any sitting IAB or IESG member. That model was continued with successor documents through RFC 2727. Because of concerns about the possibilities of frivolous recall attempts and about what would effectively be denial of service attacks on the IETF's ability to get work done, RFC 3777 increased that to 20 signatories and introduced qualifications for the signatories that were expressed as "nomcom eligibility".
RFC Editor: Please remove this appendix before publication.