TeapotChat Administrator Council
Request For Comments: 2
Category: Standards Track
Status: Standard
Netizen Land - The Internet
Wael Karram
December 2023
This document describes the proposal for and ratification process for a TeapotChat RFC memo. Subject to amendment at a later date.
This document specifies a
standards track for the TeapotChat network, and requests
discussion and suggestions for improvement.
Distribution of this memo is limited strictly to authorized
network administrators within the teapot chat network or any
third party authorized by them.
Copyright (C) 2023 TeapotChat Administrator Council. All rights reserved.
Table of Contents
|
1. Introduction |
. . . . . . . . . . . . . . . . . . . . . . .
3
|
1.1. Overview |
. . . . . . . . . . . . . . . . . . . . .
3
|
1.2. Terminology |
. . . . . . . . . . . . . . . . . . . .
3
|
2. Proposal |
. . . . . . . . . . . . . . . . . . . . . . . . .
4
|
3. Revision |
. . . . . . . . . . . . . . . . . . . . . . . . .
4
|
4. Ratification |
. . . . . . . . . . . . . . . . . . . . . . .
4
|
5. Limitations |
. . . . . . . . . . . . . . . . . . . . . . .
4
The process of proposal, revision and ratification of new TeapotChat RFCs is detailed within this document. Together with RFC 1, these two documents form the basis upon which all TeapotChat RFCs sit.
Keywords denoting requirements,
including optional requirements, shall be interpreted as
defined in IETF RFC 2119.
Definition:
An RFC Sponsor is a core council member who chooses
to sponsor a certain RFC through the process of
ratification, and shall be in charge of tracking suggestions
and revisions throughout the process. Note that a core
council member may sponsor an RFC on behalf of a
lower council member - as only the core council can propose
and ratify RFCs.
Definition:
An Administrative RFC, is an RFC which does not have
any direct effect on network services or resources.
This document inherits keywords from RFC 1, see
section 1.2. "Terminology".
The keywords denoting requirements, including optional
requirements, shall be interpreted as defined in IETF
RFC 2119.
Any upper council member (see
TeapotChat RFC 1, section 3 -
Core/Administrator Council) may propose a new RFC and
as such become an RFC Sponsor.
RFC proposal shall be limited to once a in two weeks per
RFC, such that failed RFCs do get a chance to
be voted on again, though it shall also be mandated in the
case an RFC fails to get ratified, it cannot be voted
on again unchanged unless there is a unanimous vote by the
core council. Moreover, in case an RFC failed to
ratify by being vetoed by a council member, then the
aforementioned restrictions apply with the addition of a
requirement for significant deliberation on the vetoed
parts.
Following the initial proposal, a two-week window for revision is open, allowing the RFC Sponsor to incorporate revisions suggested by other council members before a vote is held. Note that within the two week window, the proposal can still be brought to a vote before the end of said period if the sponsor sees it to be fit or by a unanimous vote of the council.
Once a draft RFC is brought to a vote and the vote passes unanimously, then from that moment on it is considered to be ratified in case of an administrative RFC, all other types of RFCs (especially those that require operational modification) have a grace period of one week for ratification past the vote - subject to extension by the core council under a regular vote.
Each RFC can be proposed at most once a month by a sponsor, though the same RFC may be proposed more times by different sponsors in case of differences in the RFC. The same sponsor is allowed to sponsor it in the same month-long period under the stipulation that large parts of it were changed or under a major vote by the council.
Authors’ Addresses:
Wael Karram - wael@waelk.tech/wael@teapot.chat