[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [ietf-nomcom Home]
Subject: diff from RFC2727
Although the draft contains a section of changes from RFC 2727, a list of "single sentences" hardly does the changes justice. Worse, if anyone has tried to do a "diff" of the revision against 2727 I'm sure you were overwhelmed by the differences. In creating this draft I've made use of the xml2rfc tool. One interesting point about how it works is that its default enumeration style differs from that used in RFC2727. So a diff of the draft against the RFC will kick out every nested list item. What I did was convert the RFC to the XML format, create a baseline document, and then I diff'ed the draft against the baseline. I removed all the header/footer differences and was left with the file included below. This should help you find the differences for review. Comments on the currently incorporated changes are welcome; please post them here. I'll say more about the proposed changes early next week. There were still a few subscriptions this morning so I'll wait the weekend. Thanks, Jim
63c63 < This document is a revision of and supercedes RFC2282. [2] It is a --- > This document is a revision of and supercedes RFC2727. [1] It is a 81,83c81,87 < reference. The time frames assume that the IETF meets at least once < per calendar year. This document specifies time frames relative to < the first IETF of the calendar year, or simply "First IETF". --- > reference. The time frames assume that the IETF meets three times > per calendar year with approximately equal amounts of time between > them. The meetings are referred to as the First IETF, Second IETF, > or Third IETF as needed. > > A sitting member of either the IAB or IESG is a person who is > currently serving a term of membership in that committee. 104,108c108 < predecessor: RFC2282. [2] < < < < --- > predecessor: RFC2727. [1] 218c218 < 6. All deliberations and supporting information that relates to --- > 6. All deliberations and supporting information that relate to 239c239,257 < 7. Unless otherwise specified, the advise and consent model is used --- > 7. The Chair is responsible for ensuring all information related to > the selection and confirmation of candidates is archived with the > Internet Society President upon completion of the nominating > committee's responsibilities. > > Information includes but is not limited to the archive of any > electronic discussion forum used by the nominating committee, for > example, a mailing list. > > All electronic information should be collected and formatted as a > single file using a popular application format, for example, zip > or tar, to facilitate its management and storage. > > Electronic information should be encrypted using a popular and > generally well regarded security application. Encryption keys > must be provided separately to the Internet Society President in > a mutually agreed upon format. > > 8. Unless otherwise specified, the advise and consent model is used 375a376,383 > The appointment must be completed no later than the Second IETF > meeting to ensure it can be announced during a plenary session at > that meeting as determined by the IETF secretariat. This ensures > the Chair has approximately two months to conduct the selection > process for the nominating committee members and approximately > one month to organize one or more initial meetings of the > nominating committee prior to the Third IETF meeting. > 381,388d388 < The list of open positions is published with the solicitation to < facilitate community members choosing between volunteering for an < open position and volunteering for the nominating committee. < < The list and solicitation must be publicized using at least the < same mechanism used by the IETF secretariat for its < announcements. < 396a397,409 > The list of open positions is published with the solicitation to > facilitate community members choosing between volunteering for an > open position and volunteering for the nominating committee. > > The opportunity to volunteer must be available for at least one > month. The opportunity to volunteer must end no later than one > week prior to the earliest time at which the selection process > may begin. > > The list and solicitation must be publicized using at least the > same mechanism used by the IETF secretariat for its > announcements. > 399a413,417 > The 3 meetings are the three most recent meetings that ended > prior to the date on which the solicitation for nominating > committee volunteers was submitted for distribution to the IETF > community. > 403,404c421,425 < 6. The Chair announces the pool of volunteers from which the 10 < voting volunteers will be randomly selected. --- > 6. The Chair announces an enumerated list of the pool of volunteers > from which the 10 voting volunteers will be randomly selected. > > The announcement must be made at least one week prior to the > earliest time the selection process may begin. 408a430,435 > The enumerated list should be announced incrementally to ensure > the pool of volunteers is unbiased. The enumeration is immutable > such that if a volunteer withdraws or is otherwise ineligible to > be selected, that slot is left blank and is skipped during the > execution of the selection process. > 419,421c454,466 < names will be chosen from the list. The output of the selection < algorithm must depend on random data whose value is not known at < the time the list and algorithm are announced. --- > names will be chosen from the list. > > The method must depend on random data whose value is not known at > the time the list and algorithm are announced and can not be > known for at least one week from the time of the announcement. > > As soon as the random data is available it must be possible for > anyone with access to it to execute the method and confirm that > the correct 10 voting volunteers were selected. > > If a selected volunteer is unable to complete their commitment > for any reason, it must be possible to iterate the method and > randomly select the next eligible volunteer in turn. 423c468 < One possible method is described in RFC2777 [1]. --- > One possible method is described in RFC2777 [2]. 650c650,661 < 13. The nominating committee advises the confirming bodies of their --- > 13. A candidate may not be confirmed to serve for both an IESG and > an IAB position concurrently. > > A nominee may be a sitting member of either the IESG or the IAB > and confirmed for an alternate position in either the IESG or > the IAB. > > If the term of the sitting role does not end coincident with the > start of the term of the new role, the confirmed candidate must > choose exactly one role. > > 14. The nominating committee advises the confirming bodies of their 658c669,677 < 14. With respect to any action to be taken in the context of --- > > > > Galvin Expires July 24, 2002 [Page 12] > > Internet-Draft IAB and IESG Selection January 2002 > > > 15. With respect to any action to be taken in the context of 789c845 < 6. Changes From RFC2282 --- > 6. Changes From RFC2727 795,831c851 < 1. The frame of reference for timeframes was changed from the < seasonal "Spring IETF" reference to the less geographic and more < temporal "First IETF" reference. < < 2. The terms of the sitting members and their respective confirmed < candidates is explicitly permitted to overlap during the First < IETF as determined by their mutual agreement. < < 3. Nominating committee members who have served on prior committees < are explicitly permitted to advise the current committee on the < deliberations and results of the prior committee. < < 4. The role and opportunity for additional advisors and liaisons to < the nominating committee was clarified. < < 5. A reference to a documented and accepted fair and unbiased < mechanism for randomly selecting nominating committee members < from the pool of volunteers was added. < < 6. The option for the prior year's Chair to select a designee to < serve as liaison to the current year's committee was clarified to < ensure the Chair selected a non-voting liaison from a pool < composed of the prior year's voting members and all prior < committee Chairs. < < 7. The responsibility and authority for the activities of the < nominating committee rests with the committee as a whole, not < with the Chair. The operation of the committee was clarified to < require changes in process and the handling of exceptions to be < approved by the committee as a whole as opposed to being at the < discretion of the Chair. < < 8. The rule that prevented nominating committee members from being < eligible to be considered for any open position was clarified to < explicitly state that the rule applies from the point in time < that the committee membership is announced through the entire < term of the current committee. --- > 1. A definition for "sitting member" was added. 832a853,871 > 2. An information retention policy was added requiring the Chair to > submit a collection of all information related to the operation > of and execution of the responsibilities of the nominating > committee to the Internet Society President for long-term > storage. Previous Chairs have done this so the addition is just > a formalization of existing practice. > > 3. A timeframe for the appointment of the Chair was added. The > timeframe could always be inferred from the text but to avoid > confusion it is now explicitly stated. > > 4. Some explicit guidance was added regarding the timeframe for > volunteering to serve on the nominating committee. > > 5. Some explicit guidance was added to the process of selecting the > nominating committee members. Among other things it must be > possible to iterate the selection method more than just 10 times > to ensure that unavailable or ineligible volunteers can be > replaced. 833a873,874 > 6. It is now explicitly stated that no person may serve on both the > IESG and the IAB concurrently. 870a927,930 > 2000 - Avia Doria > > 2001 - Ted T'so > 959,962c1015 < [1] Eastlake, D., "Publicly Verifiable Nomcom Random Selection", RFC < 2777, February 2000. < < [2] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall --- > [1] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall 964c1017,1020 < 10, RFC 2282, February 1998. --- > 10, RFC 2727, February 2000. > > [2] Eastlake, D., "Publicly Verifiable Nomcom Random Selection", RFC > 2777, February 2000.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [ietf-nomcom Home]
Powered by eList eXpress LLC