IESG
Click on the red underlined text to get to the source
... channel for
Internet standards documents and other publications of the IESG, IAB,
and Internet community ...
... directly as "Experimental" or "Informational" RFCs at the discretion
of the RFC Editor in consultation with the IESG (see section 4.2).
...
... unchanged in the Internet-Drafts directory for more than six months
without being recommended by the IESG for publication as an RFC, is
simply removed from the Internet-Drafts ...
...
The entry-level maturity for the standards track is "Proposed
Standard". A specific action by the IESG is required to move a
specification onto the standards track at the "Proposed Standard"
...
...
The IESG may require implementation and/or operational experience
prior to granting Proposed Standard status to a specification that
...
... Proposed Standard should have no known technical omissions with
respect to the requirements placed upon it. However, the IESG may
waive this requirement in order to allow a specification to advance
...
... Experimental and Informational
designations are not misused to circumvent the Internet Standards
Process, the IESG and the RFC Editor have agreed that the RFC Editor
will refer to the IESG any document submitted for Experimental ...
... Internet Standards
Process, the IESG and the RFC Editor have agreed that the RFC Editor
will refer to the IESG any document submitted for Experimental or
Informational publication which, in the opinion of the RFC Editor,
...
... may be related to work being done, or expected to be done, within the
IETF community. The IESG shall review such a referred document
within a reasonable period of time, and recommend either that it be
published as originally submitted or referred to the IETF ...
...
If (a) the IESG recommends that the document be brought within the
IETF and progressed within the IETF ...
... IETF context, but the author declines
to do so, or (b) the IESG considers that the document proposes
something that conflicts with, or is actually inimical to, an
established IETF ...
... IETF effort, the document may still be published as an
Experimental or Informational RFC. In these cases, however, the IESG
may insert appropriate "disclaimer" text into the RFC either in or
immediately following the "Status of this Memo" section in order to
...
... Documents proposed for Experimental and Informational RFCs by IETF
Working Groups go through IESG review. The review is initiated using
the process described in section 6.1.1.
...
...
While it is recognized that entities such as the IAB and IESG are
composed of individuals who may participate, as individuals, in the
technical work of the IETF ...
... BCP process is similar to that for proposed standards. The BCP
is submitted to the IESG for review, (see section 6.1.1) and the
existing review process applies, including a Last-Call on the IETF
...
... IETF
Announce mailing list. However, once the IESG has approved the
document, the process ends and the document is published. The
resulting document is viewed as having the technical approval of the
...
... The mechanics of the Internet Standards Process involve decisions of
the IESG concerning the elevation of a specification onto the
standards track or the movement of a standards-track ...
... from one maturity level to another. Although a number of reasonably
objective criteria (described below and in section 4) are available
to guide the IESG in making a decision to move a specification onto,
along, or off the standards track, there is no algorithmic guarantee
of elevation to or progression along the standards track for any
...
... along, or off the standards track, there is no algorithmic guarantee
of elevation to or progression along the standards track for any
specification. The experienced collective judgment of the IESG
concerning the technical quality of a specification proposed for
elevation to or advancement in the standards track is an essential
...
... advancing it within, or removing it from, the standards track -- must
be approved by the IESG.
...
... associated with a Working Group, a recommendation by an individual to
the IESG.
...
... IESG Review and Approval ...
...
The IESG shall determine whether or not a specification submitted to
it according to section 6.1.1 satisfies the applicable criteria for
the recommended action (see sections 4.1 and 4.2), and shall in
...
... In order to obtain all of the information necessary to make these
determinations, particularly when the specification is considered by
the IESG to be extremely important in terms of its potential impact
on the Internet or on the suite of Internet protocols ...
... on the Internet or on the suite of Internet protocols, the IESG may,
at its discretion, commission an independent technical review of the
specification.
...
... The IESG will send notice to the IETF of the pending IESG
consideration of the document(s) to permit a final review by the
general Internet community ...
... an IETF Working Group, in which case the Last-Call period shall be no
shorter than four weeks. If the IESG believes that the community
interest would be served by allowing more time for comment, it may
decide on a longer Last-Call period or to explicitly lengthen a
...
...
The IESG is not bound by the action recommended when the
specification was submitted. For example, the IESG may decide to
...
... The IESG is not bound by the action recommended when the
specification was submitted. For example, the IESG may decide to
consider the specification for publication in a different category
than that requested. If the IESG ...
... IESG may decide to
consider the specification for publication in a different category
than that requested. If the IESG determines this before the Last-
Call is issued then the Last-Call should reflect the IESG's view.
...
... than that requested. If the IESG determines this before the Last-
Call is issued then the Last-Call should reflect the IESG's view.
The IESG could also decide to change the publication category based
...
... Call is issued then the Last-Call should reflect the IESG's view.
The IESG could also decide to change the publication category based
on the response to a Last-Call. If this decision would result in a
specification being published at a "higher" level than the original
...
... specification being published at a "higher" level than the original
Last-Call was for, a new Last-Call should be issued indicating the
IESG recommendation. In addition, the IESG may decide to recommend
the formation of a new Working Group ...
... Last-Call was for, a new Last-Call should be issued indicating the
IESG recommendation. In addition, the IESG may decide to recommend
the formation of a new Working Group in the case of significant
...
...
In a timely fashion after the expiration of the Last-Call period, the
IESG shall make its final determination of whether or not to approve
the standards action, and shall notify the IETF of its decision via
...
... intervals shall be measured from the date of publication of the
corresponding RFC(s), or, if the action does not result in RFC
publication, the date of the announcement of the IESG approval of the
action.
...
...
A specification may be (indeed, is likely to be) revised as it
advances through the standards track. At each stage, the IESG shall
determine the scope and significance of the revision to the
specification, and, if necessary and appropriate, modify the
...
... revision may require that the specification accumulate more
experience at its current maturity level before progressing. Finally,
if the specification has been changed very significantly, the IESG
may recommend that the revision be treated as a new document, re-
entering the standards track at the beginning.
...
... technical error that does not represent a change in overall function
of the specification, may need to be corrected immediately. In such
cases, the IESG or RFC Editor may be asked to republish the RFC (with
a new number) with corrections, and this will not reset the minimum
time-at-level clock.
...
... Internet
Standard level but has remained at the same maturity level for
twenty-four (24) months, and every twelve (12) months thereafter
until the status is changed, the IESG shall review the viability of
the standardization effort responsible for that specification and the
usefulness of the technology. Following each such review, the IESG ...
... IESG shall review the viability of
the standardization effort responsible for that specification and the
usefulness of the technology. Following each such review, the IESG
shall approve termination or continuation of the development effort,
at the same time the IESG ...
... IESG
shall approve termination or continuation of the development effort,
at the same time the IESG shall decide to maintain the specification
at the same maturity level or to move it to Historic status. This
decision shall be communicated to the IETF ...
... should be retired. In this case, or when it is felt for some other
reason that an existing standards track specification should be
retired, the IESG shall approve a change of status of the old
specification(s) to Historic. This recommendation shall be issued
with the same Last-Call and notification ...
... If the disagreement cannot be resolved by the Area Director(s) any of
the parties involved may then appeal to the IESG as a whole. The
IESG shall then review the situation and attempt to resolve it in a
...
... the parties involved may then appeal to the IESG as a whole. The
IESG shall then review the situation and attempt to resolve it in a
manner of its own choosing.
...
...
If the disagreement is not resolved to the satisfaction of the
parties at the IESG level, any of the parties involved may appeal the
decision to the IAB. The IAB ...
... Internet Standards Process, and
the technical viability of the standards created. The IESG is the
principal agent ...
... principal agent of the IETF for this purpose, and it is the IESG that
is charged with ensuring that the required procedures have been
followed, and that any necessary prerequisites to a standards action
...
...
If an individual should disagree with an action taken by the IESG in
this process, that person should first discuss the issue with the
ISEG Chair ...
... this process, that person should first discuss the issue with the
ISEG Chair. If the IESG Chair is unable to satisfy the complainant
then the IESG ...
... IESG Chair is unable to satisfy the complainant
then the IESG as a whole should re-examine the action taken, along
with input from the complainant, and determine whether any further
action is needed. The IESG ...
... IESG as a whole should re-examine the action taken, along
with input from the complainant, and determine whether any further
action is needed. The IESG shall issue a report on its review of the
complaint to the IETF.
...
...
Should the complainant not be satisfied with the outcome of the IESG
review, an appeal may be lodged to the IAB. The IAB ...
...
If circumstances warrant, the IAB may direct that an IESG decision be
annulled, and the situation shall then be as it was before the IESG
...
... IAB may direct that an IESG decision be
annulled, and the situation shall then be as it was before the IESG
decision was taken. The IAB may also recommend an action to the IESG ...
... IESG
decision was taken. The IAB may also recommend an action to the IESG,
or make such other recommendations as it deems fit. The IAB may not,
...
... IAB may not,
however, pre-empt the role of the IESG by issuing a decision which
only the IESG is empowered to make.
...
... requirements of section 10. If the other proprietary specification
is not widely and readily available, the IESG may request that it be
published as an Informational RFC.
...
...
The IESG generally should not favor a particular proprietary
specification over technically equivalent and competing
specification(s) by making any incorporated vendor ...
... organizations involved in the development and approval of Internet
Standards includes the IETF, the IESG, the IAB, all IETF Working
Groups, and the Internet Society ...
... Working Group is constituted, upon the recommendation of an ad hoc
committee), the IESG may enter a particular specification into, or
advance it within, the standards track even though some of the
requirements ...
... advance it within, the standards track even though some of the
requirements of this document have not or will not be met. The IESG
may approve such a variance, however, only if it first determines
that the likely benefits to the Internet community ...
... noncompliance with the requirements in this document. In exercising
this discretion, the IESG shall at least consider (a) the technical
merit of the specification, (b) the possibility of achieving the
goals of the Internet Standards Process ...
... Internet Standards Process without granting a variance,
(c) alternatives to the granting of a variance, (d) the collateral
and precedential effects of granting a variance, and (e) the IESG's
ability to craft a variance that is as narrow as possible. In
determining whether to approve a variance, the IESG ...
... IESG's
ability to craft a variance that is as narrow as possible. In
determining whether to approve a variance, the IESG has discretion to
limit the scope of the variance to particular parts of this document
and to impose such additional restrictions or limitations as it
...
... The proposed variance must detail the problem perceived, explain the
precise provision of this document which is causing the need for a
variance, and the results of the IESG's considerations including
consideration of points (a) through (d) in the previous paragraph.
The proposed variance shall be issued as an Internet Draft ...
... consideration of points (a) through (d) in the previous paragraph.
The proposed variance shall be issued as an Internet Draft. The IESG
shall then issue an extended Last-Call, of no less than 4 weeks, to
allow for community comment upon the proposal.
...
...
In a timely fashion after the expiration of the Last-Call period, the
IESG shall make its final determination of whether or not to approve
the proposed variance, and shall notify the IETF of its decision via
...
... (A) Where any patents, patent applications, or other proprietary
rights are known, or claimed, with respect to any specification on
the standards track, and brought to the attention of the IESG, the
IESG shall not advance the specification without including in the
...
... the standards track, and brought to the attention of the IESG, the
IESG shall not advance the specification without including in the
document a note indicating the existence of such rights, or
claimed rights. Where implementations are required before
...
... purpose of showing the adequacy of the specification.
(B) The IESG disclaims any responsibility for identifying the
existence of or for evaluating the applicability of any claimed
copyrights, patents, patent applications, or other rights in the
...
... validity or scope of any such rights.
(C) Where the IESG knows of rights, or claimed rights under (A), the
IETF Executive Director shall attempt to obtain from the claimant
...
... IETF Executive Director shall attempt to obtain from the claimant
of such rights, a written assurance that upon approval by the IESG
of the relevant Internet standards track specification(s), any
...
... IETF
Executive Director in this effort. The results of this procedure
shall not affect advancement of a specification along the
standards track, except that the IESG may defer approval where a
delay may facilitate the obtaining of such assurances. The
results will, however, be recorded by the IETF Executive Director ...
... results will, however, be recorded by the IETF Executive Director,
and made available. The IESG may also direct that a summary of
the results be included in any RFC published containing the
specification.
...
...
The IESG will not make any explicit determination that the assurance
of reasonable and non-discriminatory terms for the use of a
technology has been fulfilled in practice. It will instead use the
...
... PARTICULAR PURPOSE."
(D) Where the IESG is aware at the time of publication of
proprietary rights claimed with respect to a standards track
document, or the technology described or referenced therein, such
...
... Internet Engineering Steering Group (IESG) ...
... IETF Area Directors and the IETF Chair. The IESG is responsible
for the management, along with the IAB ...
... A group chartered by the IESG and IAB to work on a
specific specification, set of specifications or topic. ...
... IESG ...