[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Another IESG Charter revision



you owe me big sushi

>    It is meant to document the charter of the IESG as presently
>    understood (Jan 2003).
                 ^^^

>    STATUS NOTE (to be removed from RFC):
>    This document is intended for publication as an Informational
>    document, detailing the instructions to the IESG that the IESG thinks
>    it has been operating under up to 2003.  It does not claim to
                                      ^ and including

> 1.1 The role of the IESG
> 
>    The Internet Engineering Steering Group (IESG) is the group that
>    exists to perform the overarching operational and technical
>    management functions of the Internet Engineeering Task Force (IETF).

s/exists to//
s/overarching//

>    As part of this function, the IESG is tasked with making the
>    management decisions about working groups in the IETF, and with the
>    final review and approval of documents published as IETF standards-
>    track documents.

only standards track?

>    o  The IETF Chair, who may also function as an Area Director when
>       appropriate

who is also the director of the general area.  do not imply that
this gives you the position to be the AD for arbitrary wgs.

>    The IETF Executive Director is appointed by the IETF Chair,

are iab chair and isoc vp stds not involved here?

>    For the purpose of judging consensus, only the IETF Chair and the
>    Area Directors are counted.
    ^other

>    However, discussion of personnel matters and possibly legal and
>    financial matters may sometimes be required to be kept confidential,
>    and the chair may, with the consent of the full members, exclude
>    liaison and ex officio members whose presence is seen as
>    inappropriate for the particular discussion from such discussions.

also exclusion of conflicted folk when discussing things such as
appeals

>    The IESG is in charge of managing the working group process.  While
>    the process of running a working group is delegated to the working
>    group chairs, the IESG is in charge of those processes that are
>    beyond the scope of the working group chair's role.  Many of these
>    functions are delegated by the IESG to a single Area Director - the
>    "responsible Area Director" for the group.

s/many of these//

>    The AD is responsible for ensuring that a working group being
>    chartered fulfils the criteria for WG formation given in BCP 25.  The
>    charter is the result of a negotiation between the AD and the
>    community of interest, with review and advice by the IAB.
                          ^ and the rest of the iesg

>    The AD is also responsible for selecting chairs for the working group
>    that he thinks will be up to the task.

s/that he/which the ad/

>    In a well functioning working group, main responsibility for these
                                          ^the
>    things rests with the chairs; the AD will normally be able to
>    concentrate on supporting the working group chairs' work.

> 5. The IESG role in document review
> 
>    The IESG is expected to ensure that the documents are of a sufficient
>    quality for release as an RFC,

a/an rfc/rfcs/

>    that they describe their subject matter well, and that there
>    are no outstanding engineering issues that should be addressed
>    before publication.  The degree of review will vary with the
>    intended status of the documents.
                    ^ and the perceived relative importance

>    When there are problems that occur frequently, the IESG may publish
                            ^ or solutions
>    documents describing the problems and how to avoid them, such as
>    "IANA considerations" (BCP 26 [8]), or publish web pages with
>    commonly used guidelines.

> 5.2.1 Standards-track
                       ^documents

>    o  Whether or not the specification needs review by one or more
>       existing WGs               or coordination with ^

>    The IESG may decide that a document submitted for standards-track
>    publication should instead be published as Experimental or
>    Informational.

or bcp

> 5.2.2 Informational and Experimental
> 
>    These documents are submitted to the RFC Editor in accordance with
>    the procedures of BCP 9 [1] section 4.2.3 and BCP 25 [2] section 8.
>    The IESG is asked to review all documents submitted in this fashion
>    for conflicts with the IETF standards process or work done in the
>    IETF community; this is a modification of the BCP 9 [1] procedure,
>    and documented in BCP 25 [2] section 8.

info and experimental can also come from anyomne through an AD,
yes?

>    If the document is referred to a WG, the WG can recommend that the
                                                 to the AD(s) ^
>    document be adopted as a WG document, that it be published (possibly
>    with comments), or that the IESG recommend to the RFC Editor that it
>    not be published.  The responsible AD for the WG is responsible for
>    getting a response from the WG in a timely manner.

>    Changes to the area structure affect the IETF in many ways; decisions
>    to change the area structure will be taken in consultation with the
>    community

s/will be/are/

>    The primary task of area management is done by one or two Area
>    Directors per area.  An AD may be advised by one or more
>    directorates, which is selected and chaired by the AD (BCP 25 [2]
>    section 1).

s/is/are/

>    The IESG decides which areas groups belong to.
                                 ^ working

> 7.1 Staff supervision
> 
>    The IETF Chair has primary responsibility for supervising the work of
>    the IETF Executive Director and the IETF Secretariat, with the advice
>    and consent of the IESG and the IAB.

again, are not iab chair and isoc vp stds co-equals here?

randy