From ietf-nomcom-errors@lists.elistx.com Tue Oct 7 11:15:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HME00M047OUFK@eListX.com> (original mail from harald@alvestrand.no); Tue, 07 Oct 2003 11:14:54 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HME00M017OTFI@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 07 Oct 2003 11:14:53 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HME00M017OTFH@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 07 Oct 2003 11:14:53 -0400 (EDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HME00K5W7OSZU@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 07 Oct 2003 11:14:53 -0400 (EDT) Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DB46861C13 for ; Tue, 07 Oct 2003 17:14:29 +0200 (CEST) Date: Tue, 07 Oct 2003 17:13:04 +0200 From: Harald Tveit Alvestrand Subject: IESG issues with draft-ietf-nomcom-rfc2727bis-07 To: ietf-nomcom@lists.elistx.com Message-id: <123801667.1065546784@[192.168.11.231]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.0b8 (Win32) Content-type: text/plain; FORMAT=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: The IESG on October 2 evaluated the nomcom document. It found a number of details that may need to be fixed, and three substantive issue that it seems to the IESG that it is necessary to fix. The first 2 substantive issue was raised by Margaret Wasserman: ------------------------------------------------------------- >In section 2: > The nominating committee will be given the title of the positions > to be reviewed and a brief description of the desirable set of > qualifications of the candidate that is nominated to fill each > position. Is this information sent publicly or privately? There are two issues here: 1) I think that the "description of the desirable set of qualifications" should be posted publicly, along with the list of open positions when the call for nominations is sent. 2) The IESG and IAB should know, unambiguously, whether or not the information will be publicly disseminated before providing it. ------------------------------------------------------------------ >From section 3, subsection 8: > It is consistent with these rules for the announcements of a > resignation, of the existence of a mid-term vacancy, and of the > confirmed candidates to all occur at the same time as long as the > actual sequence of events that occurred did so in the following > order. > > * The nominating committee completes the advice and consent > process for the candidate already sitting on another body. > > * The newly confirmed candidate resigns from their current > position. > > * The body with the new mid-term vacancy requests that the > nominating committee fill the position. > > * The Executive Director of the IETF informs the nominating > committee of the mid-term vacancy. > > * The nominating committee acts on the request to fill the > mid-term vacancy This section indicates that a position may be vacated and filled without the community being notified that a position is open. IMO, no position should be filled without public notice that the position is open and a public call for nominations. I understand one shool of thought that says that this is okay for IAB positions during the normal selection cycle. Because IAB members don't have separate responsibilities, it _might_ be okay to pick 6 IAB members from a candidate pool for 5 open positions, for example. However, even in this case, the community might want to know if a person with a particular specialty/area of expertise was moving, so that folks with that type of expertise could be nominated. This section would also be problematic for IESG positions. This could arise in any case where one IESG position is filled by a sitting IESG member who is not up for renewal. For example, consider a situation where the IESG chair does not volunteer for another term and is replaced by a sitting IESG member who is not up for renewal. Even though there are two ADs for most areas, the ADs often divide up the area into logical sections, requiring different expertise for each position. There are also issues with filling any postition according to this section if it is applied to interim vacancies. For example, the nomcom should not be empowered to move an IAB member to the IESG to fill and interim vacancy and replace the IAB member without making a public call for nominations for the open IAB position. ---------------------------------------------------------------- The third substantive issue was raised by Thomas Narten: > Liaisons from the IESG, IAB, and Internet Society Board of > Trustees are expected to review the operation and executing > process of the nominating committee and to report any concerns > or issues to the Chair of the nominating committee immediately. > If they can not resolve the issue between themselves liaisons > must report the issue to their respective bodies. If their > respective body agrees that there is an issue the liaison must > report it according to the dispute resolution process stated > elsewhere in this document. I worry that there will be problems with the above in practice. In particular, the text requires that a liaison report problems back to their respective group (i.e., IESG or IAB) before invoking the formal dispute resolution mechanism. But confidentiality rules rather limit what the liaison can say to their body, and in the case where dispute resolution may need invoking, it seems like details will be important. I worry that this will create problems in practice, with it being unclear what can be said. And if that is the case, it is unclear what value the discussion within the respective I* would actually have. This is perhaps more a problem for the IESG, since it has no confirming role, but it seems like a general issue. There are ways of dealing with this, but I'm not sure what is best or what the WG might think. Some initial thoughts: - I note that the current wording doesn't mention the obvious, i.e., have the liaisons and previous chair get together and discuss before escalating. One could also have the liaison (independently) decide whether to formally appeal after such a consultation. This avoids the confidentiality issue and would seem like a necessary check as part of escalating issues. - add some wording saying that confidentiality rules allow sharing of info as needed to assess whether to file a formal complaint. -------------------------------------------------------------------- I think these needs to be discussed in the WG, and that they need to either have new text crafted or a justification for the current choices given. The more-or-less minor issues can be found in the ID tracker: and are also given below in raw format. These are, in the opinion of the IESG, "non-show-stopper" issues - not things that are critical enough to block/delay publication of the document on their own, but important enough to be worth mentioning, in case they can be quickly fixed while the document is "open". It is up to the WG what to do with these. -------------------------------------------------------------------------- Steve Bellovin: Comment: The recall section makes no provision or even suggestion that the Recall Chair verify the putative signers. Section 5, Point 12 suggests that the committee consult with the sitting members of the IAB and IESG. I think that consultation with WG chairs should be suggested. Ted Hardie: Comment: I note that the oral tradition section indicates that no person should serve on both the IESG and IAB, except the IETF Chair who serves on both by definition. I believe that there is some lack of clarity on whether the IAB Chair's role ex officio in the IESG means she "serves on", and that this is probably not the place to resolve that or go into the liaisons from one body to the other. To capture the same thing, how about: "No person should serve both on the IAB and as an Area Director, except the IETF Chair whose roles as an IAB member and Area Director of the General Area is set out elsewhere". Thomas Narten: If a voting volunteer member is recalled the committee may > choose to proceed with only 9 voting volunteers at its own > discretion. In all other cases the Chair must repeat the random > selection process including an announcement of the iteration > prior to the actual selection as stated elsewhere in this > document. The above implies to me that the nomcome is required to find a replacement for a resignation, but is not for a recall. Shouldn't the nomcom be allowed to also not replace resignations? I.e, I assume that the nomcom would have the option of filling or not filling any nomcom opening, regardless of how it occurs. > It is consistent with this rule for the nominating committee to > choose one or more of the currently open positions to which it > may assign a term greater than 2 years in order to ensure the > ideal application of this rule in the future. s/greater than 2 years/of up to 3 years/ (right now, in theory, nomcom could pick the length of time, though I suspect a lot of folk would be surprised if this ever happend...) > committee. The addition must be approved by all members of the > committee according to its established voting mechanism. > Advisors participate as individuals. > "all members" wording implies everyone must agree. What is the intent here? Is it "must be approved by a quorum of the committee according to its established voting mechanism"? Note: similar wording appears elsewhere. > conducted. A member may recalled if at least a quorum of all > committee members agree, including the vote of the member being > recalled. What does this mean? simple majority if there is a quorum? (I ask because in most cases this document doesn't proscribe rules, leaving that to the nomcom to decide.) > 4. Confirmed candidates are expected to serve at least a 2 year > term. not consistent with interim appointments > First, when there is only one official nominating committee the add comma after committee > As of the publication of this document the current mechanism is ^ > an email message to both the "ietf" and the "ietf-announce" > mailing lists. comma above > None of the Chair, liaisons, or advisors vote on the selection > of candidates. They do vote on all other issues before the > committee unless otherwise specified. s/specified/specified in this document/? (what is the intent?) > 6. A Chair, in consultation with the Internet Society President, > may appoint a temporary substitute. Better to say "... for the Chair position". > If they can not resolve the issue between themselves liaisons comma after themselves. > The confirmation process must be completed at least one month > prior to the First IETF. s/must/should/ other parts of the document imply should on this topic. > The term of a nominating committee begins when its members are > officially announced. The term ends at the Third IETF (not > three meetings) after the next nominating committee's term > begins. ambigous wording. Reword: The term ends at the Third IETF (not three meetings), that is, the IETF after the next nominating committee's term begins. Jon Peterson: Comment: The Introduction fastidiously notes that the organization of the IESG is outside the scope of the document. However, in so far as Section 3 bullet 3 explains that half of the IESG positions are reviewed by the NomCom per year, would it make sense to mention at a high level that IESG members serve in specific Areas, and that the review process is staggered to preserve continuity and institutional memory within Areas? This seems like an important detail of the NomCom process to omit, even if it might change as the IETF changes. I'd note that Section 3 bullet 3 already has a caveat about future IESG reorganization, so I'm not sure how it would hurt to talk about the current IESG structure, in the interests of fully depicting the existing practice. Margaret Wasserman: Comment: EDITORIAL: >Abstract > > The process by which the members of the IAB and IESG are selected, > confirmed, and recalled is specified. This document is a > self-consistent, organized compilation of the process as it was known > at the time of publication. Very weak... I also don't think that the last sentence is true, as this document changes some things. Suggestions: Add a bit more information (i.e mention the Nominations Commitee?) and remove "as it was known at the time of publication". The section numbering in this document doesn't match usual conventions. This makes it harder to refer to sections in this document unambiguously. > 3. One-half of each of the then current IESG and IAB positions is > selected to be reviewed each year. s/One-half of each of/One-half of/ s/positions is/positions are/ > The intent of this rule to ensure the review of approximately > one-half of each of the IESG and IAB sitting members each year. s/one-half of each of/one-half of/ > 4. Confirmed candidates are expected to serve at least a 2 year > term. This isn't always true. Replacement candidates may serve terms of less than two years. > A term may begin or end no sooner than the > first day of the meeting and no later than the last day of the > meeting as determined by the mutual agreement of the currently > sitting member and the confirmed candidate. The confirmed > candidate's term may overlap the sitting member's term during the > meeting as determined by their mutual agreement. How does this apply to IAB terms? In the case where there is more than one new IAB member, I don't think that it is defined which IAB member each new member is replacing. >In section 4, subsection 7: > Liaisons from the IESG, IAB, and Internet Society Board of > Trustees are expected to review the operation and executing > process of the nominating committee and to report any concerns There is a mention here of a liaison from the ISOC board. But, there in section 4.3 there is a list of nomcom members that indicates how they are selected, and the ISOC liaison is not listed. The organization of this document seems to result in repeating a lot of information. There are also a lot of forward references. This makes it difficult to find the part(s) of the document that apply to a particular part of the process. From ietf-nomcom-errors@lists.elistx.com Tue Oct 7 11:15:04 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HME00M047OWFV@eListX.com> (original mail from harald@alvestrand.no); Tue, 07 Oct 2003 11:14:56 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HME00M017OVFT@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 07 Oct 2003 11:14:55 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HME00M017OUFQ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 07 Oct 2003 11:14:54 -0400 (EDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HME00IDP7OT8D@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 07 Oct 2003 11:14:54 -0400 (EDT) Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8AF9761C13 for ; Tue, 07 Oct 2003 17:14:31 +0200 (CEST) Date: Tue, 07 Oct 2003 17:14:28 +0200 From: Harald Tveit Alvestrand Subject: IESG issues with draft-ietf-nomcom-rfc2727bis-07 To: ietf-nomcom@lists.elistx.com Message-id: <123885858.1065546868@localhost> MIME-version: 1.0 X-Mailer: Mulberry/3.1.0b8 (Win32) Content-type: text/plain; FORMAT=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: The IESG on October 2 evaluated the nomcom document. It found a number of details that may need to be fixed, and three substantive issue that it seems to the IESG that it is necessary to fix. The first 2 substantive issue was raised by Margaret Wasserman: ------------------------------------------------------------- >In section 2: > The nominating committee will be given the title of the positions > to be reviewed and a brief description of the desirable set of > qualifications of the candidate that is nominated to fill each > position. Is this information sent publicly or privately? There are two issues here: 1) I think that the "description of the desirable set of qualifications" should be posted publicly, along with the list of open positions when the call for nominations is sent. 2) The IESG and IAB should know, unambiguously, whether or not the information will be publicly disseminated before providing it. ------------------------------------------------------------------ >From section 3, subsection 8: > It is consistent with these rules for the announcements of a > resignation, of the existence of a mid-term vacancy, and of the > confirmed candidates to all occur at the same time as long as the > actual sequence of events that occurred did so in the following > order. > > * The nominating committee completes the advice and consent > process for the candidate already sitting on another body. > > * The newly confirmed candidate resigns from their current > position. > > * The body with the new mid-term vacancy requests that the > nominating committee fill the position. > > * The Executive Director of the IETF informs the nominating > committee of the mid-term vacancy. > > * The nominating committee acts on the request to fill the > mid-term vacancy This section indicates that a position may be vacated and filled without the community being notified that a position is open. IMO, no position should be filled without public notice that the position is open and a public call for nominations. I understand one shool of thought that says that this is okay for IAB positions during the normal selection cycle. Because IAB members don't have separate responsibilities, it _might_ be okay to pick 6 IAB members from a candidate pool for 5 open positions, for example. However, even in this case, the community might want to know if a person with a particular specialty/area of expertise was moving, so that folks with that type of expertise could be nominated. This section would also be problematic for IESG positions. This could arise in any case where one IESG position is filled by a sitting IESG member who is not up for renewal. For example, consider a situation where the IESG chair does not volunteer for another term and is replaced by a sitting IESG member who is not up for renewal. Even though there are two ADs for most areas, the ADs often divide up the area into logical sections, requiring different expertise for each position. There are also issues with filling any postition according to this section if it is applied to interim vacancies. For example, the nomcom should not be empowered to move an IAB member to the IESG to fill and interim vacancy and replace the IAB member without making a public call for nominations for the open IAB position. ---------------------------------------------------------------- The third substantive issue was raised by Thomas Narten: > Liaisons from the IESG, IAB, and Internet Society Board of > Trustees are expected to review the operation and executing > process of the nominating committee and to report any concerns > or issues to the Chair of the nominating committee immediately. > If they can not resolve the issue between themselves liaisons > must report the issue to their respective bodies. If their > respective body agrees that there is an issue the liaison must > report it according to the dispute resolution process stated > elsewhere in this document. I worry that there will be problems with the above in practice. In particular, the text requires that a liaison report problems back to their respective group (i.e., IESG or IAB) before invoking the formal dispute resolution mechanism. But confidentiality rules rather limit what the liaison can say to their body, and in the case where dispute resolution may need invoking, it seems like details will be important. I worry that this will create problems in practice, with it being unclear what can be said. And if that is the case, it is unclear what value the discussion within the respective I* would actually have. This is perhaps more a problem for the IESG, since it has no confirming role, but it seems like a general issue. There are ways of dealing with this, but I'm not sure what is best or what the WG might think. Some initial thoughts: - I note that the current wording doesn't mention the obvious, i.e., have the liaisons and previous chair get together and discuss before escalating. One could also have the liaison (independently) decide whether to formally appeal after such a consultation. This avoids the confidentiality issue and would seem like a necessary check as part of escalating issues. - add some wording saying that confidentiality rules allow sharing of info as needed to assess whether to file a formal complaint. -------------------------------------------------------------------- I think these needs to be discussed in the WG, and that they need to either have new text crafted or a justification for the current choices given. The more-or-less minor issues can be found in the ID tracker: and are also given below in raw format. These are, in the opinion of the IESG, "non-show-stopper" issues - not things that are critical enough to block/delay publication of the document on their own, but important enough to be worth mentioning, in case they can be quickly fixed while the document is "open". It is up to the WG what to do with these. -------------------------------------------------------------------------- Steve Bellovin: Comment: The recall section makes no provision or even suggestion that the Recall Chair verify the putative signers. Section 5, Point 12 suggests that the committee consult with the sitting members of the IAB and IESG. I think that consultation with WG chairs should be suggested. Ted Hardie: Comment: I note that the oral tradition section indicates that no person should serve on both the IESG and IAB, except the IETF Chair who serves on both by definition. I believe that there is some lack of clarity on whether the IAB Chair's role ex officio in the IESG means she "serves on", and that this is probably not the place to resolve that or go into the liaisons from one body to the other. To capture the same thing, how about: "No person should serve both on the IAB and as an Area Director, except the IETF Chair whose roles as an IAB member and Area Director of the General Area is set out elsewhere". Thomas Narten: If a voting volunteer member is recalled the committee may > choose to proceed with only 9 voting volunteers at its own > discretion. In all other cases the Chair must repeat the random > selection process including an announcement of the iteration > prior to the actual selection as stated elsewhere in this > document. The above implies to me that the nomcome is required to find a replacement for a resignation, but is not for a recall. Shouldn't the nomcom be allowed to also not replace resignations? I.e, I assume that the nomcom would have the option of filling or not filling any nomcom opening, regardless of how it occurs. > It is consistent with this rule for the nominating committee to > choose one or more of the currently open positions to which it > may assign a term greater than 2 years in order to ensure the > ideal application of this rule in the future. s/greater than 2 years/of up to 3 years/ (right now, in theory, nomcom could pick the length of time, though I suspect a lot of folk would be surprised if this ever happend...) > committee. The addition must be approved by all members of the > committee according to its established voting mechanism. > Advisors participate as individuals. > "all members" wording implies everyone must agree. What is the intent here? Is it "must be approved by a quorum of the committee according to its established voting mechanism"? Note: similar wording appears elsewhere. > conducted. A member may recalled if at least a quorum of all > committee members agree, including the vote of the member being > recalled. What does this mean? simple majority if there is a quorum? (I ask because in most cases this document doesn't proscribe rules, leaving that to the nomcom to decide.) > 4. Confirmed candidates are expected to serve at least a 2 year > term. not consistent with interim appointments > First, when there is only one official nominating committee the add comma after committee > As of the publication of this document the current mechanism is ^ > an email message to both the "ietf" and the "ietf-announce" > mailing lists. comma above > None of the Chair, liaisons, or advisors vote on the selection > of candidates. They do vote on all other issues before the > committee unless otherwise specified. s/specified/specified in this document/? (what is the intent?) > 6. A Chair, in consultation with the Internet Society President, > may appoint a temporary substitute. Better to say "... for the Chair position". > If they can not resolve the issue between themselves liaisons comma after themselves. > The confirmation process must be completed at least one month > prior to the First IETF. s/must/should/ other parts of the document imply should on this topic. > The term of a nominating committee begins when its members are > officially announced. The term ends at the Third IETF (not > three meetings) after the next nominating committee's term > begins. ambigous wording. Reword: The term ends at the Third IETF (not three meetings), that is, the IETF after the next nominating committee's term begins. Jon Peterson: Comment: The Introduction fastidiously notes that the organization of the IESG is outside the scope of the document. However, in so far as Section 3 bullet 3 explains that half of the IESG positions are reviewed by the NomCom per year, would it make sense to mention at a high level that IESG members serve in specific Areas, and that the review process is staggered to preserve continuity and institutional memory within Areas? This seems like an important detail of the NomCom process to omit, even if it might change as the IETF changes. I'd note that Section 3 bullet 3 already has a caveat about future IESG reorganization, so I'm not sure how it would hurt to talk about the current IESG structure, in the interests of fully depicting the existing practice. Margaret Wasserman: Comment: EDITORIAL: >Abstract > > The process by which the members of the IAB and IESG are selected, > confirmed, and recalled is specified. This document is a > self-consistent, organized compilation of the process as it was known > at the time of publication. Very weak... I also don't think that the last sentence is true, as this document changes some things. Suggestions: Add a bit more information (i.e mention the Nominations Commitee?) and remove "as it was known at the time of publication". The section numbering in this document doesn't match usual conventions. This makes it harder to refer to sections in this document unambiguously. > 3. One-half of each of the then current IESG and IAB positions is > selected to be reviewed each year. s/One-half of each of/One-half of/ s/positions is/positions are/ > The intent of this rule to ensure the review of approximately > one-half of each of the IESG and IAB sitting members each year. s/one-half of each of/one-half of/ > 4. Confirmed candidates are expected to serve at least a 2 year > term. This isn't always true. Replacement candidates may serve terms of less than two years. > A term may begin or end no sooner than the > first day of the meeting and no later than the last day of the > meeting as determined by the mutual agreement of the currently > sitting member and the confirmed candidate. The confirmed > candidate's term may overlap the sitting member's term during the > meeting as determined by their mutual agreement. How does this apply to IAB terms? In the case where there is more than one new IAB member, I don't think that it is defined which IAB member each new member is replacing. >In section 4, subsection 7: > Liaisons from the IESG, IAB, and Internet Society Board of > Trustees are expected to review the operation and executing > process of the nominating committee and to report any concerns There is a mention here of a liaison from the ISOC board. But, there in section 4.3 there is a list of nomcom members that indicates how they are selected, and the ISOC liaison is not listed. The organization of this document seems to result in repeating a lot of information. There are also a lot of forward references. This makes it difficult to find the part(s) of the document that apply to a particular part of the process. From ietf-nomcom-errors@lists.elistx.com Tue Oct 7 13:15:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HME00704CVASL@eListX.com> (original mail from rja@extremenetworks.com) ; Tue, 07 Oct 2003 13:06:46 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HME00701CV9SJ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 07 Oct 2003 13:06:46 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HME00701CV9SI@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 07 Oct 2003 13:06:45 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HME004CZCV8GV@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 07 Oct 2003 13:06:45 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.103]) by gnat.inet.org (Postfix) with ESMTP id A39A767113 for ; Tue, 07 Oct 2003 13:09:39 -0400 (EDT) Date: Tue, 07 Oct 2003 13:06:18 -0400 From: RJ Atkinson Subject: Re: IESG issues with draft-ietf-nomcom-rfc2727bis-07 In-reply-to: <123801667.1065546784@[192.168.11.231]> To: ietf-nomcom@lists.elistx.com Message-id: <916B2A98-F8E8-11D7-86F8-00039357A82A@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Tuesday, Oct 7, 2003, at 11:13 America/Montreal, Harald Tveit Alvestrand wrote: > Ted Hardie: > Comment: > I note that the oral tradition section indicates that no person should > serve on both the IESG and IAB, except the IETF Chair who serves on > both by > definition. I believe that there is some lack of clarity on whether > the IAB > Chair's role ex officio in the IESG means she "serves on", and that > this is > probably not the place to resolve that or go into the liaisons from one > body to the other. To capture the same thing, how about: > > "No person should serve both on the IAB and as an Area Director, except > the IETF Chair whose roles as an IAB member and Area Director of the > General Area is set out elsewhere". That proposed fix seems problematic. An alternative phrasing, which I prefer (yet also suspect is consistent with Ted's intent) might be: "No person should serve both as a sitting member of the IAB and as a member of the IESG." Kindly recall that the IESG Chair (== IETF Chair) is not a "sitting member of the IAB", neither now nor in the past, but is instead an "ex-officio member of the IAB". I'll defer commenting on the other IESG comments, for now. One last item. It would seem sensible to collect any extant IAB inputs and any extant ISoC BoT inputs now, in the interest of minimising the number of word-smithing iterations that this document undergoes. Legally at least, the ISoC BoT has to approve this document before it goes into effect. While that might usually be pro forma approval, it certainly would be polite and sensible to ask them for input on this draft right now. Yours, Ran rja@extremenetworks.com From ietf-nomcom-errors@lists.elistx.com Tue Oct 7 14:05:19 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HME00B04FJZQY@eListX.com> (original mail from kre@munnari.OZ.AU); Tue, 07 Oct 2003 14:04:47 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HME00B01FJZQV@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 07 Oct 2003 14:04:47 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HME00B01FJZQU@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 07 Oct 2003 14:04:47 -0400 (EDT) Received: from fuchsia.home ([192.150.250.67]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HME00A4JFJWN4@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 07 Oct 2003 14:04:46 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h97I3oIl010873; Wed, 08 Oct 2003 01:03:51 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h97HxeU15977; Wed, 08 Oct 2003 00:59:41 +0700 (ICT) Date: Wed, 08 Oct 2003 00:59:40 +0700 From: Robert Elz Subject: Re: IESG issues with draft-ietf-nomcom-rfc2727bis-07 In-reply-to: <123885858.1065546868@localhost> To: iesg@ietf.org Cc: ietf-nomcom@lists.elistx.com Message-id: <25047.1065549580@munnari.OZ.AU> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <123885858.1065546868@localhost> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Date: Tue, 07 Oct 2003 17:14:28 +0200 From: Harald Tveit Alvestrand Message-ID: <123885858.1065546868@localhost> | ------------------------------------------------------------- | >In section 2: | > The nominating committee will be given the title of the positions | > to be reviewed and a brief description of the desirable set of | > qualifications of the candidate that is nominated to fill each | > position. | | Is this information sent publicly or privately? I'll just comment on this one for now ... RFC2727 says: At a minimum, the nominating committee will be given the title of the position to be reviewed. The nominating committee may be given a desirable set of qualifications for the candidate nominated to fill each position. The replacement text is not substantially different. 2727 makes no mention of whether or not that information is given publicly or privately. Perhaps it should, perhaps this is something that doesn't need to be stated. There is nothing being changed here however. One thing that is clear, is that if one were to desire that this be made more precise, one way or the other, the correct procedure would have been to bring it up to the working group when the document was being considered. It is totally unacceptable for IESG members, however well motivated, to use their position on the IESG to force through changes to documents that haven't been raised properly through the normal working group procedures. The truly stupid thing about this objection, is that if it were to cause the IESG to reject the document, then the IETF will be left in exactly the position that the objection complains about. What should be done here, is to note this issue for the next time that this document is to be revised, and if appropriate, fix it then. kre ps: if one were to decide that this document should be re-opened for new issues, then all the stuff that got dropped before because of a desire to get this done quickly, will reappear. But, now that it seems that the IESG delayed it long enough already that it is too late for this year's nomcom, perhaps that is what should happen anyway. From ietf-nomcom-errors@lists.elistx.com Tue Oct 7 15:45:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HME00L04K1LHF@eListX.com> (original mail from Margaret.Wasserman@nokia.com); Tue, 07 Oct 2003 15:41:45 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HME00L01K1LHD@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 07 Oct 2003 15:41:45 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HME00L01K1LHC@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 07 Oct 2003 15:41:45 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HME00I7OK1KQ8@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 07 Oct 2003 15:41:44 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h97JfL613134 for ; Tue, 07 Oct 2003 22:41:21 +0300 (EET DST) Received: from daebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 07 Oct 2003 22:41:21 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 07 Oct 2003 12:41:20 -0700 Date: Tue, 07 Oct 2003 15:41:18 -0400 From: Margaret.Wasserman@nokia.com Subject: RE: IESG issues with draft-ietf-nomcom-rfc2727bis-07 To: kre@munnari.OZ.AU, iesg@ietf.org Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE Thread-Topic: IESG issues with draft-ietf-nomcom-rfc2727bis-07 Thread-Index: AcOM/X2MEuZ+cLJEQzmfxjFIs5S32gABcNBg content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: X-OriginalArrivalTime: 07 Oct 2003 19:41:20.0101 (UTC) FILETIME=[FB409950:01C38D0A] Hi Robert, > | ------------------------------------------------------------- > | >In section 2: > | > The nominating committee will be given the title=20 > | > of the positions to be reviewed and a brief description= =20 > | > of the desirable set of qualifications of the candidate= =20 > | > that is nominated to fill each position. > |=20 > | Is this information sent publicly or privately? >=20 > I'll just comment on this one for now ... >=20 > RFC2727 says: >=20 > At a minimum, the nominating committee will be given the titl= e=20 > of the position to be reviewed. The nominating committee may= be > given a desirable set of qualifications for the candidate > nominated to fill each position. >=20 > The replacement text is not substantially different. =20 In my opinion, there are two substantial differences: =091) Providing a set of desirable qualifications is no longer =09=09optional. As far as I know, it hasn't been done in =09=09the past, so this is a new requirement. =092) The new document says who would provide this information =09 and how it would be sent to the nomcom, which was not=20 specified in RFC 2727: "The IESG and IAB are responsible for providing a list of = the qualifications desired of the candidates selected for thei= r respective open positions to the Executive Director. The lists are to be provided to the nominating committee for i= ts consideration." The list of positions is posted publicly along with the call for nominations. So, would this information (which will come in through the same channel, probably at the same time) also be posted publicly? Or is it to be assumed, given that this communication is not explicit= ly exempted from the nomcom confidentiality rules, that the description = of desirable qualifications would be kept confidential?=20 > The truly stupid thing about this objection, is that if it=20 > were to cause the IESG to reject the document, then the IETF will= =20 > be left in exactly the position that the objection complains about. Not true. Under the new draft, the IAB and IESG are required to provide a set of desirable qualifications, and it is unclear whether that information will be distributed publicly or kept confidential. Under RFC 2727, the IESG and IAB were not required to submit this information at all. In general, I think that this information was gathered by the nomcom through interviews with IESG and IAB members, among others, and was therefore covered by nomcom confidentiality rules. > One thing that is clear, is that if one were to desire that this be > made more precise, one way or the other, the correct procedure woul= d > have been to bring it up to the working group when the document was > being considered. >=20 > It is totally unacceptable for IESG members, however well motivated= , > to use their position on the IESG to force through changes to=20 > documents that haven't been raised properly through the normal work= ing=20 > group procedures. Nice posturing. In reality, I think that everyone understands that it is not humanly= =20 possible for each IESG member to actively track and participate in every IETF WG... And, yet, we do require that the IESG review all of our documents for= =20 quality before publication. IMO, the quality of a BCP process docume= nt=20 is largely related to its clarity and consistency. I am not saying that the WG has to change its position on whether this information is disseminated publicly or kept private, or that it has to follow my preferences regarding which one it chooses. I am just saying that the document is unclear and incomplete because= =20 it doesn't specify this. Margaret From ietf-nomcom-errors@lists.elistx.com Tue Oct 7 23:05:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00M0443T54@eListX.com> (original mail from avri@acm.org); Tue, 07 Oct 2003 22:55:05 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00M0143S52@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 07 Oct 2003 22:55:04 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00M0143S51@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 07 Oct 2003 22:55:04 -0400 (EDT) Received: from psg.com (psg.com [147.28.0.62]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF00FMI43R7O@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 07 Oct 2003 22:55:03 -0400 (EDT) Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A74TG-0008RQ-Eq; Wed, 08 Oct 2003 02:54:39 +0000 Date: Wed, 08 Oct 2003 11:53:55 +0900 From: Avri Doria Subject: Re: IESG issues with draft-ietf-nomcom-rfc2727bis-07 In-reply-to: <123801667.1065546784@[192.168.11.231]> To: ietf-nomcom@lists.elistx.com Cc: Harald Alvestrand Message-id: MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII; delsp=yes Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: I have taken the text of IESG comment and have broken it up into the specific issues and numbered them. I also added some discussion based on a review of some of the issues discussed by the WG on the list and in meetings and have added some questions that need to be answered in processing the issues. The questions are not meant to be a complete list, and do not include some possible follow up questions. I expect the detailed questions to evolve during the discussion. Also they are not meant to be a poll at this point, but rather an indication of recommended focus for discussions. In order to keep this discussion clear, I ask that discussion of each issue be in a separate email and that the issue number be included in the subject line. In order to complete the discussion in bounded time, I ask that the discussion period be limited to the next 2 weeks, ending 22 October. After that time, if a revision of the draft is required, it can, hopefully, still be submitted prior to the deadline for IETF58 submissions (27 October). I have not yet requested a meeting slot at IETF58, but will consider doing so if we cannot close all of the issues in the next 2 weeks. Issue 1-3 are 'showstopper" Issues that must be resolved before the document will be allowed to proceed. ------------------ IESG Issue 1: ------------------ > The first 2 substantive issue was raised by Margaret Wasserman: > ------------------------------------------------------------- >> In section 2: >> The nominating committee will be given the title of the positions >> to be reviewed and a brief description of the desirable set of >> qualifications of the candidate that is nominated to fill each >> position. > > Is this information sent publicly or privately? There are two issues > here: > > 1) I think that the "description of the desirable set of > qualifications" > should be posted publicly, along with the list of open positions when > the call for nominations is sent. > > 2) The IESG and IAB should know, unambiguously, whether or not the > information will be publicly disseminated before providing it. > History: This issue was not discussed Questions: Should it be mandatory that the required qualifications list be made public? If not, should the required qualifications list be confidential? > ------------------------------------------------------------------ ----------------- IESG Issue 2 ----------------- > raised by Margaret Wasserman: >> From section 3, subsection 8: >> It is consistent with these rules for the announcements of a >> resignation, of the existence of a mid-term vacancy, and of the >> confirmed candidates to all occur at the same time as long as the >> actual sequence of events that occurred did so in the following >> order. >> >> * The nominating committee completes the advice and consent >> process for the candidate already sitting on another body. >> >> * The newly confirmed candidate resigns from their current >> position. >> >> * The body with the new mid-term vacancy requests that the >> nominating committee fill the position. >> >> * The Executive Director of the IETF informs the nominating >> committee of the mid-term vacancy. >> >> * The nominating committee acts on the request to fill the >> mid-term vacancy > > This section indicates that a position may be vacated and filled > without the community being notified that a position is open. IMO, no > position should be filled without public notice that the position is > open and a public call for nominations. > > I understand one shool of thought that says that this is okay for IAB > positions during the normal selection cycle. Because IAB members > don't have separate responsibilities, it _might_ be okay to pick 6 IAB > members from a candidate pool for 5 open positions, for example. > However, even in this case, the community might want to know if a > person with a particular specialty/area of expertise was moving, so > that folks with that type of expertise could be nominated. > > This section would also be problematic for IESG positions. This could > arise in any case where one IESG position is filled by a sitting IESG > member who is not up for renewal. For example, consider a situation > where the IESG chair does not volunteer for another term and is > replaced by a sitting IESG member who is not up for renewal. Even > though there are two ADs for most areas, the ADs often divide up the > area into logical sections, requiring different expertise for each > position. > > There are also issues with filling any postition according to this > section if it is applied to interim vacancies. For example, the > nomcom should not be empowered to move an IAB member to the IESG to > fill and interim vacancy and replace the IAB member without making a > public call for nominations for the open IAB position. Background: The issue was first brought up http://lists.elistx.com/archives/ietf-nomcom/200303/msg00020.html >>> >>>> >>Insert in section 3 as paragraph 6 and renumber all subsequent >>>> paragraphs: >>>> >>>> "Nomcom-caused Mid-term Vacancies: >>>> >>>> From time to time the Nomcom may propose moving a serving Area >>>> Director or >>>> IAB member from one position to another. (E.g. moving a Transport >>>> AD to >>>> cover O&M). If the serving member is at the end of their normal >>>> term there >>>> is no change in procedures. Otherwise, this is treated as a mid-term >>>> vacancy and mid-term procedures are used with the following >>>> exceptions: >>>> >>>> a) If the vacancy will occur on the IAB due to a move from the IAB >>>> to the >>>> IESG, the Nomcom may, upon confirmation of nominee/IAB member, >>>> submit for >>>> confirmation as part of the normal slate of candidates another >>>> nominee to >>>> complete the term of the departing IAB member. If the Nomcom >>>> declines to >>>> nominate a replacement as part of the annual process, the IAB may, >>>> at any >>>> time after the confirmation of the departing member, ask the Nomcom >>>> to fill >>>> the slot using mid-term procedures. >>>> >>>> b) If the vacancy will occur on the IESG, either as a move to >>>> another IESG >>>> slot or as a move to the IAB, the Nomcom must use mid-term >>>> procedure rules. >>>> Most importantly, they must advertise the vacancy, and must >>>> consider all >>>> new candidates as equitably as any previously considered. The IESG >>>> chair is >>>> responsible for notifying the IETF Executive director of the >>>> vacancy and >>>> who in turn is responsible for asking the Nomcom select the >>>> replacement. >>>> The Nomcom is explicitly barred from proceeding without an explicit >>>> request >>>> from the IESG chair. The term of the nominee shall be for the >>>> remainder of >>>> the term of the vacated position." The recommended text change was never discussed on the list. The issue surrounding the 'poaching' issue was discussed but the discussion centered on the serialization described in 2727bis-07. However, none of the discussions were about the result of moving someone from a non open seat on the IESG to fill an IAB slot and thus having to fill an unannounced IESG slot. Questions: Does the document need to be explicit about treating the replacement of an IESG member in an non open chair differently the the replacement of an IAB member in a non open seat? Do full mid term replacement rules, including public announcement apply to this case? > ---------------------------------------------------------------- ------------------ IESG Issue 3; ------------------ > The third substantive issue was raised by Thomas Narten: > >> Liaisons from the IESG, IAB, and Internet Society Board of >> Trustees are expected to review the operation and executing >> process of the nominating committee and to report any concerns >> or issues to the Chair of the nominating committee immediately. >> If they can not resolve the issue between themselves liaisons >> must report the issue to their respective bodies. If their >> respective body agrees that there is an issue the liaison must >> report it according to the dispute resolution process stated >> elsewhere in this document. > > I worry that there will be problems with the above in practice. In > particular, the text requires that a liaison report problems back to > their respective group (i.e., IESG or IAB) before invoking the formal > dispute resolution mechanism. But confidentiality rules rather limit > what the liaison can say to their body, and in the case where dispute > resolution may need invoking, it seems like details will be > important. I worry that this will create problems in practice, with it > being unclear what can be said. And if that is the case, it is unclear > what value the discussion within the respective I* would actually > have. This is perhaps more a problem for the IESG, since it has no > confirming role, but it seems like a general issue. > > There are ways of dealing with this, but I'm not sure what is best or > what the WG might think. Some initial thoughts: > > - I note that the current wording doesn't mention the obvious, i.e., > have the liaisons and previous chair get together and discuss > before escalating. One could also have the liaison (independently) > decide whether to formally appeal after such a consultation. This > avoids the confidentiality issue and would seem like a necessary > check as part of escalating issues. > > - add some wording saying that confidentiality rules allow sharing of > info as needed to assess whether to file a formal complaint. Background: This particular issue was never discussed, but the issue of confidentiality was frequently discussed in many different contexts. Section 10, Security, discusses the extension of confidentiality to those outside the Nomcom when necessary, though it is not explicit that this extension would also apply to the IAB, IESG or ISOC in the case of Nomcom operational issues. I also note that in the text Thomas quoted, it does state that after reporting the Issues to the chair or committee they only escalate if ' they cannot resolve the issue between themselves'. It is, perhaps, implicit in this that they can and should discuss with the past chair. Questions: Does content need to be added to the text to allow extension of confidentiality to the Liaison in the case of reporting issues having to do with the internal operations of the Nomcom? Does content need to be added to explicitly state that liaisons should consult among themselves and with the past chair before escalating an issue to their respective I-groups? > ----------------------------------------------------------------------- > --- Issue 4-26 are not considered 'showstoppers' but should be addressed before sending the document back to the IESG ------------------ IESG Issue 4: ------------------ > Steve Bellovin: > Comment: > The recall section makes no provision or even suggestion that the > Recall Chair verify the putative signers. Note: the Recall Chair would probably not be selected until there was a requirement for a recall committee and would probably be avaialble to verify the signatories. Questions: Should text be added to clarify that signatories must be confirmed to be qualified members of the IETF community according to Nomcom selection rules? If so, should it be done by the IETF Secretariat as is the case in verifying Nomcom volunteers. ------------------ IESG Issue 5: ------------------ > > Section 5, Point 12 suggests that the committee consult with the > sitting members of the IAB and IESG. I think that consultation with > WG chairs should be suggested. Question: Should WG chairs be added to the list of those who should be consulted? ----------------- IESG Issue 6 ----------------- > > Ted Hardie: > Comment: > I note that the oral tradition section indicates that no person should > serve on both the IESG and IAB, except the IETF Chair who serves on > both by > definition. I believe that there is some lack of clarity on whether > the IAB > Chair's role ex officio in the IESG means she "serves on", and that > this is > probably not the place to resolve that or go into the liaisons from one > body to the other. To capture the same thing, how about: > > "No person should serve both on the IAB and as an Area Director, except > the IETF Chair whose roles as an IAB member and Area Director of the > General Area is set out elsewhere". Question: Should this text, or some other text, replace the current text in A2 ----------------- IESG Issue 7 ----------------- > > Thomas Narten: > > If a voting volunteer member is recalled the committee may >> choose to proceed with only 9 voting volunteers at its own >> discretion. In all other cases the Chair must repeat the >> random >> selection process including an announcement of the iteration > >> prior to the actual selection as stated elsewhere in this >> document. > > The above implies to me that the nomcome is required to find a > replacement for a resignation, but is not for a recall. Shouldn't the > nomcom be allowed to also not replace resignations? I.e, I assume that > the nomcom would have the option of filling or not filling any nomcom > opening, regardless of how it occurs. Questions: Is a change to the text required to make the two situation consistent? ----------------- IESG Issue 8 ----------------- > >> It is consistent with this rule for the nominating committee to >> choose one or more of the currently open positions to which it >> may assign a term greater than 2 years in order to ensure the >> ideal application of this rule in the future. > > s/greater than 2 years/of up to 3 years/ > (right now, in theory, nomcom could pick the length of time, though I > suspect a lot of folk would be surprised if this ever happend...) Questions: Is the editorial change accepted? Is text making it explicit that the maximum assignable term is 3 years needed? ----------------- IESG Issue 9 ----------------- > >> committee. The addition must be approved by all members of the >> committee according to its established voting mechanism. >> Advisors participate as individuals. >> > > "all members" wording implies everyone must agree. What is the intent > here? Is it "must be approved by a quorum of the committee according > to its established voting mechanism"? Note: similar wording appears > elsewhere. Background: Section 4.3 indicates that non volunteers vote on all issues other then candidate selection. Questions: Should the participation of the non volunteers in voting issues be made explicit? Should the non volunteers be excluded from voting on voting rules? ----------------- IESG Issue 10 ----------------- > >> conducted. A member may recalled if at least a quorum of all >> committee members agree, including the vote of the member being >> recalled. > > What does this mean? simple majority if there is a quorum? (I ask > because in most cases this document doesn't proscribe rules, leaving > that to the nomcom to decide.) Background: While the document discusses the quorum that must be present for a vote, the actual voting mechanisms are to be be determined by the Nomcom itself. Question: should text be added making an explicit rule for the voting in a Nomcom recall be specified in the document. ----------------- IESG Issue 11 ----------------- > >> 4. Confirmed candidates are expected to serve at least a 2 year >> term. > > not consistent with interim appointments Question: Should clarifying text indicate that the Confirmed candidates, chosen by the standard process, as opposed to mid term appointments, be expected to seve at least 2 years. ----------------- IESG Issue 12 ----------------- > >> First, when there is only one official nominating committee the > > add comma after committee Question: Is the editorial change accepted? ----------------- IESG Issue 13 ----------------- > >> As of the publication of this document the current mechanism is > ^ >> an email message to both the "ietf" and the "ietf-announce" >> mailing lists. > > comma above Question: Is the editorial change accepted? ----------------- IESG Issue 14 ----------------- > > >> None of the Chair, liaisons, or advisors vote on the selection >> of candidates. They do vote on all other issues before the >> committee unless otherwise specified. > > s/specified/specified in this document/? (what is the intent?) Questions: Is the editorial change accepted? Is further explanation necessary indicating that the non volunteers participate in all votes except those dealing with candidate selection? ----------------- IESG Issue 15 ----------------- > >> 6. A Chair, in consultation with the Internet Society President, >> may appoint a temporary substitute. > > Better to say "... for the Chair position". Question: Is the editorial change accepted? ----------------- IESG Issue 16 ----------------- > >> If they can not resolve the issue between themselves liaisons > > comma after themselves. Question: Is the editorial change accepted? ----------------- IESG Issue 17 ----------------- > >> The confirmation process must be completed at least one month >> prior to the First IETF. > > s/must/should/ other parts of the document imply should on this topic. Questions; Is this an editorial or content change? Is the change accepted? ----------------- IESG Issue 18 ----------------- > >> The term of a nominating committee begins when its members are >> officially announced. The term ends at the Third IETF (not >> three meetings) after the next nominating committee's term >> begins. > > ambigous wording. Reword: > > The term ends at the Third IETF (not three meetings), that is, > the IETF after the next nominating committee's term begins. Question: Is the more explicit rewording accepted? ----------------- IESG Issue 19 ----------------- > > Jon Peterson: > Comment: > The Introduction fastidiously notes that the organization of the IESG > is outside the scope of the document. However, in so far as Section 3 > bullet 3 explains that half of the IESG positions are reviewed by the > NomCom per year, would it make sense to mention at a high level that > IESG members serve in specific Areas, and that the review process is > staggered to preserve continuity and institutional memory within > Areas? This seems like an important detail of the NomCom process to > omit, even if it might change as the IETF changes. I'd note that > Section 3 bullet 3 already has a caveat about future IESG > reorganization, so I'm not sure how it would hurt to talk about the > current IESG structure, in the interests of fully depicting the > existing practice. > Question: Should the discussion in Section 3 bullet 3, be expanded to include a discussion of why 1/2 at a time? ----------------- IESG Issue 20 ----------------- > Margaret Wasserman: > > Comment: > EDITORIAL: > >> Abstract >> >> The process by which the members of the IAB and IESG are selected, >> confirmed, and recalled is specified. This document is a >> self-consistent, organized compilation of the process as it was known >> at the time of publication. > > Very weak... I also don't think that the last sentence is true, > as this document changes some things. Suggestions: Add a bit > more information (i.e mention the Nominations Commitee?) and remove > "as it was known at the time of publication". Background: this text was never discussed in the working group. Question: Should the second sentence be removed or reworked? ----------------- IESG Issue 21 ----------------- > > The section numbering in this document doesn't match usual > conventions. This makes it harder to refer to sections in this > document unambiguously. Question: Should the document be renumbered using a more conventional numbering scheme? ----------------- IESG Issue 22 ----------------- > >> 3. One-half of each of the then current IESG and IAB positions is >> selected to be reviewed each year. > > s/One-half of each of/One-half of/ > s/positions is/positions are/ > >> The intent of this rule to ensure the review of approximately >> one-half of each of the IESG and IAB sitting members each year. > > s/one-half of each of/one-half of/ Discussion: Seems largely editorial. But the added precision does not make the English incorrect. Nor does its removal. question: Is the changed accepted. ----------------- IESG Issue 23 ----------------- > >> 4. Confirmed candidates are expected to serve at least a 2 year >> term. > > This isn't always true. Replacement candidates may serve > terms of less than two years. Same as issue 11 ----------------- IESG Issue 24 ----------------- > >> A term may begin or end no sooner than the >> first day of the meeting and no later than the last day of the >> meeting as determined by the mutual agreement of the currently >> sitting member and the confirmed candidate. The confirmed >> candidate's term may overlap the sitting member's term during the >> meeting as determined by their mutual agreement. > > How does this apply to IAB terms? In the case where there is > more than one new IAB member, I don't think that it is > defined which IAB member each new member is replacing. Questions: Should the question of starting time for IAB be separated from the question of IESG? Should it be pointed out that since IAB members do not replace specific IAB members, it is consistent that new IAB members may overlap with retiring IAB members? ----------------- IESG Issue 25 ----------------- >> In section 4, subsection 7: >> Liaisons from the IESG, IAB, and Internet Society Board of >> Trustees are expected to review the operation and executing >> process of the nominating committee and to report any concerns > > There is a mention here of a liaison from the ISOC board. > But, there in section 4.3 there is a list of nomcom members > that indicates how they are selected, and the ISOC liaison > is not listed. Clarification: The first mention of the possible appointment of a Internet Society liaison is in 4.9 There seem to be two issues here, - an editorial one dealing with a forward reference and the fact that there may not be a ISOC liaison - an issue of whether the Nomcom procedures should specify how the ISOC Trustees choose a liaison if they decide to offer one. Possible remedy to the editorial issue: - move the content of 4.9 into 4.3 and edit the text in 4.7 to add the phrase 'if one has been appointed', right after Trustees. Question: should this or some other change be made to the text? Discussion of the second issue: Generally the rough consensus of the group was that the way the IAB or IESG made their decisions was not to be defined by this document (though there was significant discussion around the IAB role as a confirming body). Does this rough consensus also apply to the Internet Society Trustees should they decide to send a liaison? We should note that part of the reason Internet society Liaisons were made discretionary is that the IETF was not viewed as having the mandate to dictate actions to the Internet Society Trustees in its BCPs. Question: Should text be added describing how the Internet Society Trustees pick their liaison, should they decide to send one? ----------------- IESG Issue 26 ----------------- > > The organization of this document seems to result in repeating > a lot of information. There are also a lot of forward > references. This makes it difficult to find the part(s) of > the document that apply to a particular part of the process. > > Question: Should the draft be restructured prior to resubmission? From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 04:15:14 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00H04ISSVO@eListX.com> (original mail from harald@alvestrand.no); Wed, 08 Oct 2003 04:12:28 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00H01ISRVM@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 04:12:27 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00H01ISQVL@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 04:12:26 -0400 (EDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF00H2OISPD0@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 04:12:26 -0400 (EDT) Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5A5A961C2A; Wed, 08 Oct 2003 10:12:02 +0200 (CEST) Date: Wed, 08 Oct 2003 09:21:14 +0200 From: Harald Tveit Alvestrand Subject: IESG issue 2 (Re: IESG issues with draft-ietf-nomcom-rfc2727bis-07) In-reply-to: To: Avri Doria , ietf-nomcom@lists.elistx.com Message-id: <181892227.1065604874@localhost> MIME-version: 1.0 X-Mailer: Mulberry/3.1.0b8 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Thanks, Avri! One point of clarification on this point: While creating a vacancy by moving someone from the IESG to the IAB may not seem realistic, we have had events in the past where an IESG member has been moved into another slot on the IESG, and the same nomcom has filled the resulting vacancy, which was not included as a possible vacancy in the original call for nominations. So it's a real practical question. --On 8. oktober 2003 11:53 +0900 Avri Doria wrote: > ----------------- > IESG Issue 2 > ----------------- >> raised by Margaret Wasserman: > >>> From section 3, subsection 8: >>> It is consistent with these rules for the announcements of a >>> resignation, of the existence of a mid-term vacancy, and of the >>> confirmed candidates to all occur at the same time as long as the >>> actual sequence of events that occurred did so in the following >>> order. >>> >>> * The nominating committee completes the advice and consent >>> process for the candidate already sitting on another body. >>> >>> * The newly confirmed candidate resigns from their current >>> position. >>> >>> * The body with the new mid-term vacancy requests that the >>> nominating committee fill the position. >>> >>> * The Executive Director of the IETF informs the nominating >>> committee of the mid-term vacancy. >>> >>> * The nominating committee acts on the request to fill the >>> mid-term vacancy >> >> This section indicates that a position may be vacated and filled >> without the community being notified that a position is open. IMO, no >> position should be filled without public notice that the position is >> open and a public call for nominations. >> >> I understand one shool of thought that says that this is okay for IAB >> positions during the normal selection cycle. Because IAB members >> don't have separate responsibilities, it _might_ be okay to pick 6 IAB >> members from a candidate pool for 5 open positions, for example. >> However, even in this case, the community might want to know if a >> person with a particular specialty/area of expertise was moving, so >> that folks with that type of expertise could be nominated. >> >> This section would also be problematic for IESG positions. This could >> arise in any case where one IESG position is filled by a sitting IESG >> member who is not up for renewal. For example, consider a situation >> where the IESG chair does not volunteer for another term and is >> replaced by a sitting IESG member who is not up for renewal. Even >> though there are two ADs for most areas, the ADs often divide up the >> area into logical sections, requiring different expertise for each >> position. >> >> There are also issues with filling any postition according to this >> section if it is applied to interim vacancies. For example, the >> nomcom should not be empowered to move an IAB member to the IESG to >> fill and interim vacancy and replace the IAB member without making a >> public call for nominations for the open IAB position. > > Background: > > The issue was first brought up > http://lists.elistx.com/archives/ietf-nomcom/200303/msg00020.html > >>>> >>>>> >> Insert in section 3 as paragraph 6 and renumber all subsequent >>>>> paragraphs: >>>>> >>>>> "Nomcom-caused Mid-term Vacancies: >>>>> >>>>> From time to time the Nomcom may propose moving a serving Area >>>>> Director or >>>>> IAB member from one position to another. (E.g. moving a Transport >>>>> AD to >>>>> cover O&M). If the serving member is at the end of their normal >>>>> term there >>>>> is no change in procedures. Otherwise, this is treated as a mid-term >>>>> vacancy and mid-term procedures are used with the following >>>>> exceptions: >>>>> >>>>> a) If the vacancy will occur on the IAB due to a move from the IAB >>>>> to the >>>>> IESG, the Nomcom may, upon confirmation of nominee/IAB member, >>>>> submit for >>>>> confirmation as part of the normal slate of candidates another >>>>> nominee to >>>>> complete the term of the departing IAB member. If the Nomcom >>>>> declines to >>>>> nominate a replacement as part of the annual process, the IAB may, >>>>> at any >>>>> time after the confirmation of the departing member, ask the Nomcom >>>>> to fill >>>>> the slot using mid-term procedures. >>>>> >>>>> b) If the vacancy will occur on the IESG, either as a move to >>>>> another IESG >>>>> slot or as a move to the IAB, the Nomcom must use mid-term >>>>> procedure rules. >>>>> Most importantly, they must advertise the vacancy, and must >>>>> consider all >>>>> new candidates as equitably as any previously considered. The IESG >>>>> chair is >>>>> responsible for notifying the IETF Executive director of the >>>>> vacancy and >>>>> who in turn is responsible for asking the Nomcom select the >>>>> replacement. >>>>> The Nomcom is explicitly barred from proceeding without an explicit >>>>> request >>>>> from the IESG chair. The term of the nominee shall be for the >>>>> remainder of >>>>> the term of the vacated position." > > > The recommended text change was never discussed on the list. > > The issue surrounding the 'poaching' issue was discussed but the > discussion centered on the serialization described in 2727bis-07. > However, none of the discussions were about the result of moving someone > from a non open seat on the IESG to fill an IAB slot and thus having to > fill an unannounced IESG slot. > > Questions: > > Does the document need to be explicit about treating the replacement of > an IESG member in an non open chair differently the the replacement of > an IAB member in a non open seat? > > Do full mid term replacement rules, including public announcement apply > to this case? From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 04:15:16 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00H04ISZWF@eListX.com> (original mail from harald@alvestrand.no); Wed, 08 Oct 2003 04:12:35 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00H01ISYWD@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 04:12:34 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00H01ISYWA@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 04:12:34 -0400 (EDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF00H2VISWD0@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 04:12:33 -0400 (EDT) Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C22AC61C2B; Wed, 08 Oct 2003 10:12:09 +0200 (CEST) Date: Wed, 08 Oct 2003 10:11:29 +0200 From: Harald Tveit Alvestrand Subject: [IESG-6] IESG/IAB overlaps (Re: IESG issues with draft-ietf-nomcom-rfc2727bis-07) In-reply-to: <916B2A98-F8E8-11D7-86F8-00039357A82A@extremenetworks.com> To: RJ Atkinson , ietf-nomcom@lists.elistx.com Message-id: <184907182.1065607889@localhost> MIME-version: 1.0 X-Mailer: Mulberry/3.1.0b8 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <916B2A98-F8E8-11D7-86F8-00039357A82A@extremenetworks.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Ran, I believe the issue Ted brought up was triggered by the presence in both bodies of the IAB chair, and that he thought the description for the IETF chair was adequate. Another possible fix, covering even more people: "Some people serve on both the IESG and IAB as part of their role, such as the IETF Chair, the IAB Chair and the IAB-IESG liaisons. Apart from these, no person should serve both on the IAB and on the IESG." BTW, RFC 2850 says that the IETF Chair is a "full member" of the IAB (section 1.1), but not a "sitting" member (section 1). Well-covered ground. Harald --On 7. oktober 2003 13:06 -0400 RJ Atkinson wrote: >> "No person should serve both on the IAB and as an Area Director, except >> the IETF Chair whose roles as an IAB member and Area Director of the >> General Area is set out elsewhere". > > That proposed fix seems problematic. An alternative phrasing, > which I prefer (yet also suspect is consistent with Ted's intent) > might be: > > "No person should serve both as a sitting member of the IAB > and as a member of the IESG." > > Kindly recall that the IESG Chair (== IETF Chair) is not a > "sitting member of the IAB", neither now nor in the past, > but is instead an "ex-officio member of the IAB". From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 08:05:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00804T880O@eListX.com> (original mail from kre@munnari.OZ.AU); Wed, 08 Oct 2003 07:57:44 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00801T870M@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 07:57:43 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00801T870L@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 07:57:43 -0400 (EDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF004AYT6YPL@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 07:57:43 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h98BuQv08937; Wed, 08 Oct 2003 18:56:26 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h98Bu1P24283; Wed, 08 Oct 2003 18:56:03 +0700 (ICT) Date: Wed, 08 Oct 2003 18:56:01 +0700 From: Robert Elz Subject: Re: IESG issue 2 (Re: IESG issues with draft-ietf-nomcom-rfc2727bis-07) In-reply-to: <181892227.1065604874@localhost> To: Harald Tveit Alvestrand Cc: Avri Doria , ietf-nomcom@lists.elistx.com Message-id: <15775.1065614161@munnari.OZ.AU> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <181892227.1065604874@localhost> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Date: Wed, 08 Oct 2003 09:21:14 +0200 From: Harald Tveit Alvestrand Message-ID: <181892227.1065604874@localhost> | So it's a real practical question. Yes, but it is also a real hard question (as it was suggested in the IESG objection anyway) - as the nomcom can't really announce that it is seeking to fill that postion until after it knows that it will be vacant, which can only be after the candidate has accepted the move, which can't really happen (for certain) until after the confirmation by the confirming body. Aside from not actually being certain that the position will be vacant until after the resignation by the moved incumbent, to reveal that the nomcom was seeking an extra AD for area X, or one more IAB member would (especially in the first case) be revealing information that the nomcom is required to keep confidential. I believe that this issue is based upon a misunderstanding of what >>> * The Executive Director of the IETF informs the nominating >>> committee of the mid-term vacancy. >>> >>> * The nominating committee acts on the request to fill the >>> mid-term vacancy really means. There was no intent here (I believe) to allow ... >> This section indicates that a position may be vacated and filled >> without the community being notified that a position is open. Reading the procedure, it is fairly clear (to me anyway) that the vacancy occurs only after confirmation (and announcement) of the new positions, and is then handled just like any other mid term vacancy (like one occurring in the middle of the normal term for whatever reason). If the wording needs to be tweaked to make that even clearer, I doubt anyone would object. I don't think there's any rational way to have the newly vacant position filled as a part of the initial nomcom process though (though the nomcom may well be aware that a vacancy is likely, and perpare for it, so the mid-term vacancy processing might end up being quite quick by comparison with other events). And this is regardless of whether the new position is an IESG position or an IAB position. To answer Avri's final question: > Do full mid term replacement rules, including public announcement apply > to this case? Yes, of course they do. I find it hard to even imagine how the text can be read so as to imply otherwise. All this happens after confirmation and announcement of the results of the nomcom process that caused it - not during. kre From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 08:45:00 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00A04V7IF3@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 08:40:30 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00A01V7IF1@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 08:40:30 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00A01V7IF0@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 08:40:30 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF0085BV7HW5@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 08:40:30 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98Cdx6U010470 for ; Wed, 08 Oct 2003 08:39:59 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98CdxAw010469 for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 08:39:59 -0400 (EDT) Date: Wed, 08 Oct 2003 08:39:59 -0400 (EDT) From: Scott Bradner Subject: IESG Issue 1: To: ietf-nomcom@lists.elistx.com Message-id: <200310081239.h98CdxAw010469@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > Should it be mandatory that the required qualifications list be made > public? yes Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 08:55:07 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00A04VK6UI@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 08:48:06 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00A01VK6UG@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 08:48:06 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00A01VK6UF@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 08:48:06 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF0086FVK5W5@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 08:48:05 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98Clh6U010522 for ; Wed, 08 Oct 2003 08:47:43 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98Clham010521 for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 08:47:43 -0400 (EDT) Date: Wed, 08 Oct 2003 08:47:43 -0400 (EDT) From: Scott Bradner Subject: IESG Issue 2 To: ietf-nomcom@lists.elistx.com Message-id: <200310081247.h98Clham010521@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: I see little reason to do a new search if the case is someone with time left in their IAB term moving from the IAB to the IESG. I do not see a realistic problem that would be solved by doing so. The community suggested people for the IAB already in the process and the IAB members should be generalists (i.e. no IAB topic-specific seats) but the case of an IESG member with time left in their term being moved to the IAB or another IESG seat should cause a new call for nominees to fill the open IESG seat (while moving in mid term from the IESG to the IAB might not have happened I can easily see the case (its not all that different from someone just quiting being an IESG member which does happen) Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 08:55:09 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00B04VPQ2G@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 08:51:26 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00B01VPP2D@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 08:51:25 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00B01VPP2C@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 08:51:25 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF004JNVPOPL@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 08:51:25 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98Cp06U010533 for ; Wed, 08 Oct 2003 08:51:00 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98Cp0V7010532 for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 08:51:00 -0400 (EDT) Date: Wed, 08 Oct 2003 08:51:00 -0400 (EDT) From: Scott Bradner Subject: IESG Issue 3 To: ietf-nomcom@lists.elistx.com Message-id: <200310081251.h98Cp0V7010532@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > Questions: > > Does content need to be added to the text to allow extension of > confidentiality to the Liaison in the case of reporting issues having > to do with the internal operations of the Nomcom? I do not think this would be a good idea - it blurs the confidentiality requirement > Does content need to be added to explicitly state that liaisons should > consult among themselves and with the past chair before escalating an > issue to their respective I-groups? seems like a good idea to me Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 08:55:11 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00B04VRK5M@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 08:52:32 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00B01VRJ5K@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 08:52:31 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00B01VRJ5J@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 08:52:31 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF004K5VRJPL@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 08:52:31 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98Cq66U010546 for ; Wed, 08 Oct 2003 08:52:06 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98Cq6Q3010545 for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 08:52:06 -0400 (EDT) Date: Wed, 08 Oct 2003 08:52:06 -0400 (EDT) From: Scott Bradner Subject: IESG Issue 4 To: ietf-nomcom@lists.elistx.com Message-id: <200310081252.h98Cq6Q3010545@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > Questions: > > Should text be added to clarify that signatories must be confirmed to > be qualified members of the IETF community according to Nomcom > selection rules? yes > If so, should it be done by the IETF Secretariat as is the case in > verifying Nomcom volunteers. yes Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 08:55:14 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00B04VUF93@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 08:54:15 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00B01VUF91@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 08:54:15 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00B01VUF90@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 08:54:15 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF00881VUEW5@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 08:54:15 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98Cro6U010557 for ; Wed, 08 Oct 2003 08:53:50 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98Cro2w010556 for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 08:53:50 -0400 (EDT) Date: Wed, 08 Oct 2003 08:53:50 -0400 (EDT) From: Scott Bradner Subject: IESG Issue 5 To: ietf-nomcom@lists.elistx.com Message-id: <200310081253.h98Cro2w010556@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > Question: Should WG chairs be added to the list of those who should be > consulted? YES!!!! the idea that the nomcom can reasonabally evaluate a sitting AD without talking to the WG chairs is plain silly Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 09:05:03 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00B04VWZE8@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 08:55:47 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00B01VWZE6@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 08:55:47 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00B01VWYE5@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 08:55:46 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF004KHVWYPL@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 08:55:46 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98CtM6U010568 for ; Wed, 08 Oct 2003 08:55:22 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98CtMT7010567 for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 08:55:22 -0400 (EDT) Date: Wed, 08 Oct 2003 08:55:22 -0400 (EDT) From: Scott Bradner Subject: IESG Issue 6 To: ietf-nomcom@lists.elistx.com Message-id: <200310081255.h98CtMT7010567@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > Question: Should this text, or some other text, replace the current > text in A2 I thought it was clear but if somone is confused it should be changed Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 09:05:06 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00B04VZBFX@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 08:57:11 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00B01VZAFV@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 08:57:11 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00B01VZAFU@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 08:57:10 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF0088DVZ9W5@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 08:57:10 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98Cuj6U010579 for ; Wed, 08 Oct 2003 08:56:45 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98CujI5010578 for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 08:56:45 -0400 (EDT) Date: Wed, 08 Oct 2003 08:56:45 -0400 (EDT) From: Scott Bradner Subject: IESG Issue 7 To: ietf-nomcom@lists.elistx.com Message-id: <200310081256.h98CujI5010578@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > Questions: > > Is a change to the text required to make the two situation consistent? why not just make a blanket statement that the recall & nomcom committiees work the same way? Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 09:05:08 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00B04W1BJT@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 08:58:23 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00B01W1BJR@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 08:58:23 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00B01W1BJQ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 08:58:23 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF0088KW1AW5@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 08:58:22 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98Cvw6U010595 for ; Wed, 08 Oct 2003 08:57:58 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98CvwWx010594 for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 08:57:58 -0400 (EDT) Date: Wed, 08 Oct 2003 08:57:58 -0400 (EDT) From: Scott Bradner Subject: IESG Issue 8 To: ietf-nomcom@lists.elistx.com Message-id: <200310081257.h98CvwWx010594@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > Questions: > > Is the editorial change accepted? > > Is text making it explicit that the maximum assignable term is 3 years > needed? I do not think the change is needed but it would not hurt anything Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 09:05:39 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00B04W7TYP@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 09:02:17 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00B01W7SYN@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:02:16 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00B01W7SYI@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:02:16 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF004LQW7RPL@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:02:16 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98D1p6U010613 for ; Wed, 08 Oct 2003 09:01:51 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98D1p50010612 for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:01:51 -0400 (EDT) Date: Wed, 08 Oct 2003 09:01:51 -0400 (EDT) From: Scott Bradner Subject: IESG Issue 9 To: ietf-nomcom@lists.elistx.com Message-id: <200310081301.h98D1p50010612@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > Questions: > > Should the participation of the non volunteers in voting issues be made > explicit? > Should the non volunteers be excluded from voting on voting rules? these questions do not seem to capture the issue that was raised which is 'does the vote need to be unanimous' in answer to that question - 'voting in this case should follow the same rules as elsewhere in teh nomcom process' Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 09:05:47 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C04WA930@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 09:03:45 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C01WA82Y@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:03:45 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C01WA82X@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:03:44 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF008A9WA8W5@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:03:44 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98D3J6U010624 for ; Wed, 08 Oct 2003 09:03:20 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98D3JFL010623 for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:03:19 -0400 (EDT) Date: Wed, 08 Oct 2003 09:03:19 -0400 (EDT) From: Scott Bradner Subject: IESG Issue 10 To: ietf-nomcom@lists.elistx.com Message-id: <200310081303.h98D3JFL010623@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > Question: should text be added making an explicit rule for the voting > in a Nomcom recall be specified in the document. yes, and it should be at least a majority of the seated memebers of the committee - maybe even 2/3 Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 09:05:49 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C04WC85R@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 09:04:56 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C01WC85H@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:04:56 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C01WC75G@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:04:55 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF004MCWC7PL@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:04:55 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98D4V6U010635 for ; Wed, 08 Oct 2003 09:04:31 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98D4VZj010634 for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:04:31 -0400 (EDT) Date: Wed, 08 Oct 2003 09:04:31 -0400 (EDT) From: Scott Bradner Subject: IESG Issue 11 To: ietf-nomcom@lists.elistx.com Message-id: <200310081304.h98D4VZj010634@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > Question: Should clarifying text indicate that the Confirmed > candidates, chosen by the standard process, as opposed to mid term > appointments, be expected to seve at least 2 years. I do not think the change is needed but would not hurt anything to make it Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 09:15:05 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C04WDXD3@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 09:05:57 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C01WDXD1@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:05:57 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C01WDXCZ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:05:57 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF008AUWDWW5@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:05:56 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98D5W6U010646 for ; Wed, 08 Oct 2003 09:05:32 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98D5WHE010645 for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:05:32 -0400 (EDT) Date: Wed, 08 Oct 2003 09:05:32 -0400 (EDT) From: Scott Bradner Subject: IESG Issue 12 To: ietf-nomcom@lists.elistx.com Message-id: <200310081305.h98D5WHE010645@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > >> First, when there is only one official nominating committee the > > > > add comma after committee > > Question: Is the editorial change accepted? I do not think the WG needed to be asked this type of editorial nit question Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 09:15:07 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C04WEODX@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 09:06:24 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C01WEODV@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:06:24 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C01WEODU@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:06:24 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF008B0WENW5@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:06:24 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98D5x6U010656 for ; Wed, 08 Oct 2003 09:05:59 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98D5xmH010655 for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:05:59 -0400 (EDT) Date: Wed, 08 Oct 2003 09:05:59 -0400 (EDT) From: Scott Bradner Subject: IESG Issue 13 To: ietf-nomcom@lists.elistx.com Message-id: <200310081305.h98D5xmH010655@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > Question: Is the editorial change accepted? I do not think the WG needed to be asked this type of editorial nit question Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 09:15:09 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C04WH3I8@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 09:07:51 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C01WH2I6@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:07:51 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C01WH2I5@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:07:50 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF008BFWH2W5@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:07:50 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98D7P6U010678 for ; Wed, 08 Oct 2003 09:07:26 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98D7PNe010676 for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:07:25 -0400 (EDT) Date: Wed, 08 Oct 2003 09:07:25 -0400 (EDT) From: Scott Bradner Subject: IESG Issue 14 To: ietf-nomcom@lists.elistx.com Message-id: <200310081307.h98D7PNe010676@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > Questions: > > Is the editorial change accepted? yes > Is further explanation necessary indicating that the non volunteers > participate in all votes except those dealing with candidate selection? maybe as an overarching statement Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 09:15:15 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C04WIPKL@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 09:08:49 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C01WIPKJ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:08:49 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C01WIPKI@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:08:49 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF008BOWIOW5@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:08:49 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98D8O6U010699 for ; Wed, 08 Oct 2003 09:08:24 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98D8O3f010698 for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:08:24 -0400 (EDT) Date: Wed, 08 Oct 2003 09:08:24 -0400 (EDT) From: Scott Bradner Subject: IESG Issue 15 To: ietf-nomcom@lists.elistx.com Message-id: <200310081308.h98D8O3f010698@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > > Better to say "... for the Chair position". > > Question: Is the editorial change accepted? I do not think the WG needed to be asked this type of editorial nit question Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 09:15:17 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C04WJ9LV@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 09:09:09 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C01WJ9LT@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:09:09 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C01WJ9LS@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:09:09 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF008BXWJ8W5@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:09:09 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98D8i6U010709 for ; Wed, 08 Oct 2003 09:08:44 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98D8iTh010708 for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:08:44 -0400 (EDT) Date: Wed, 08 Oct 2003 09:08:44 -0400 (EDT) From: Scott Bradner Subject: IESG Issue 16 To: ietf-nomcom@lists.elistx.com Message-id: <200310081308.h98D8iTh010708@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > Question: Is the editorial change accepted? I do not think the WG needed to be asked this type of editorial nit question Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 09:15:19 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C04WM6S0@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 09:10:54 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C01WM5RY@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:10:53 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C01WM5RW@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:10:53 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF008D6WM5W5@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:10:53 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98DAS6U010720 for ; Wed, 08 Oct 2003 09:10:28 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98DASO1010719 for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:10:28 -0400 (EDT) Date: Wed, 08 Oct 2003 09:10:28 -0400 (EDT) From: Scott Bradner Subject: IESG Issue 17 To: ietf-nomcom@lists.elistx.com Message-id: <200310081310.h98DASO1010719@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > Questions; > > Is this an editorial or content change? it is a content change not an editorial change > Is the change accepted? if this is not done then what is the fallback if the committee does not make the deadline? (are all is nominations invalid?) Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 09:15:21 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C04WNMUA@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 09:11:46 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C01WNLU7@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:11:45 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C01WNLU6@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:11:45 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF004NZWNLPL@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:11:45 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98DBK6U010731 for ; Wed, 08 Oct 2003 09:11:20 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98DBKjE010730 for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:11:20 -0400 (EDT) Date: Wed, 08 Oct 2003 09:11:20 -0400 (EDT) From: Scott Bradner Subject: IESG Issue 18 To: ietf-nomcom@lists.elistx.com Message-id: <200310081311.h98DBKjE010730@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > Question: Is the more explicit rewording accepted? I do not think the WG needed to be asked this type of editorial nit question Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 09:15:23 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C04WRBY8@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 09:13:59 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C01WRAY6@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:13:58 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00C01WRAY5@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:13:58 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF00C05WRAX3@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:13:58 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98DDX6U010749 for ; Wed, 08 Oct 2003 09:13:33 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98DDXGt010748 for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:13:33 -0400 (EDT) Date: Wed, 08 Oct 2003 09:13:33 -0400 (EDT) From: Scott Bradner Subject: IESG Issue 19 To: ietf-nomcom@lists.elistx.com Message-id: <200310081313.h98DDXGt010748@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > Question: Should the discussion in Section 3 bullet 3, be expanded to > include a discussion of why 1/2 at a time? we could also just include the text from any number of IESTF descriptive documents - I do not see a need to have this description here - it will not kill anything to add it but I do not think it helps much Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 09:25:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00D04WU86M@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 09:15:45 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00D01WU86K@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:15:44 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00D01WU86H@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:15:44 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF008DTWU7W5@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:15:44 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98DFJ6U010765 for ; Wed, 08 Oct 2003 09:15:19 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98DFJnP010764 for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:15:19 -0400 (EDT) Date: Wed, 08 Oct 2003 09:15:19 -0400 (EDT) From: Scott Bradner Subject: IESG Issue 20 To: ietf-nomcom@lists.elistx.com Message-id: <200310081315.h98DFJnP010764@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > Question: Should the second sentence be removed or reworked? I think this is a silly objection and see no reason that this type of overview desription text needs to get changed Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 09:25:04 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00D04WY1CC@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 09:18:01 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00D01WY1CA@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:18:01 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00D01WY0C9@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:18:00 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF008EPWY0W5@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:18:00 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98DHa6U010789 for ; Wed, 08 Oct 2003 09:17:36 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98DHams010788 for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:17:36 -0400 (EDT) Date: Wed, 08 Oct 2003 09:17:36 -0400 (EDT) From: Scott Bradner Subject: IESG Issue 21 To: ietf-nomcom@lists.elistx.com Message-id: <200310081317.h98DHams010788@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > Question: Should the document be renumbered using a more conventional > numbering scheme? I guess that "a more conventional numbering scheme" means having section heads like 3.1 if that is what is meant, it woudl be better Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 09:25:06 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00D04WY6CO@eListX.com> (original mail from kre@munnari.OZ.AU); Wed, 08 Oct 2003 09:18:06 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00D01WY5CM@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:18:05 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00D01WY5CL@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:18:05 -0400 (EDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF00C0UWXRX3@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:18:05 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h98DHNv12030; Wed, 08 Oct 2003 20:17:25 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h98DH8P22733; Wed, 08 Oct 2003 20:17:09 +0700 (ICT) Date: Wed, 08 Oct 2003 20:17:08 +0700 From: Robert Elz Subject: Re: IESG Issue 1 In-reply-to: To: Margaret.Wasserman@nokia.com Cc: iesg@ietf.org, ietf-nomcom@lists.elistx.com Message-id: <12859.1065619028@munnari.OZ.AU> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Date: Tue, 7 Oct 2003 15:41:18 -0400 From: Message-ID: Note, I have changed the Subject to better reflect the current threading structure... | 1) Providing a set of desirable qualifications is no longer | optional. As far as I know, it hasn't been done in | the past, so this is a new requirement. It hasn't? Really? About 7-9 years ago (I forget when exactly) a problem arose, in exactly this area, where there was a whole bunch of confusion as to just what it was the IESG wanted in one of their open positions. Back then, as the result of the IAB confirmation process which couldn't understand what the nomcom had done or why, and only after a bunch of ferreting around discovered that there had been some ambiguous messages from the IESG to the nomcom about just what the person who filled a particular position should be capable of. The result of all of that was the text that is in 2727 - I'd be astounded to learn that since then no-one had bothered to take any notice, and I actually find it very hard to believe that that is the case. If it is, then I am certainly not in the slightest surprised that the new doc is making it clear that this is expected to be done, and in no way optional. | 2) The new document says who would provide this information | and how it would be sent to the nomcom, which was not | specified in RFC 2727: Is this supposed to matter in some material way, or were you just pointing out a technical difference? | The list of positions is posted publicly along with the call for | nominations. So, would this information (which will come in through | the same channel, probably at the same time) also be posted publicly? I agree with Scott's answer to Avri's question. Yes, of course it is. How could anyone rationally imagine a job ad (which is essentially what a call for nominations is - except no remuneration is being offered...) in which there was no statement of what qualifications and abilities are expected of those who might apply (or be nominated for) the job in question. That information is essential. | Not true. Under the new draft, the IAB and IESG are required to | provide a set of desirable qualifications, and it is unclear whether | that information will be distributed publicly or kept confidential. They were supposed to be required, and I would have assumed just based upon good sense, they would have been, supplying this information all along. It is so inconceivable that anyone would want this information to be considered confidential that I just assume no-one has bothered to say that it should not be. I'll leave the rest of the "posturing" for some other occasion... kre From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 09:25:09 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00D04X0DGO@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 09:19:25 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00D01X0DGM@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:19:25 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00D01X0CGL@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:19:24 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF008EYX0CW5@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:19:24 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98DJ06U010806 for ; Wed, 08 Oct 2003 09:19:00 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98DJ0Jl010805 for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:19:00 -0400 (EDT) Date: Wed, 08 Oct 2003 09:19:00 -0400 (EDT) From: Scott Bradner Subject: IESG Issue 22 To: ietf-nomcom@lists.elistx.com Message-id: <200310081319.h98DJ0Jl010805@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > question: Is the changed accepted. I do not think the WG needed to be asked this type of editorial nit question Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 09:25:12 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00D04X1HHR@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 09:20:05 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00D01X1HHP@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:20:05 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00D01X1HHO@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:20:05 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF00C1IX1GX3@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:20:04 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98DJe6U010817 for ; Wed, 08 Oct 2003 09:19:40 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98DJeJq010816 for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:19:40 -0400 (EDT) Date: Wed, 08 Oct 2003 09:19:40 -0400 (EDT) From: Scott Bradner Subject: IESG Issue 23 To: ietf-nomcom@lists.elistx.com Message-id: <200310081319.h98DJeJq010816@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > Same as issue 11 so why was it asked again? Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 09:25:14 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00D04X4DM6@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 09:21:50 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00D01X4DM2@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:21:49 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00D01X4DM1@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:21:49 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF00C28X4CX3@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:21:48 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98DLO6U010828 for ; Wed, 08 Oct 2003 09:21:24 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98DLOQu010827 for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:21:24 -0400 (EDT) Date: Wed, 08 Oct 2003 09:21:24 -0400 (EDT) From: Scott Bradner Subject: IESG Issue 24 To: ietf-nomcom@lists.elistx.com Message-id: <200310081321.h98DLOQu010827@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > Questions: > > Should the question of starting time for IAB be separated from the > question of IESG? yes > Should it be pointed out that since IAB members do not replace specific > IAB members, it is consistent that new IAB members may overlap with > retiring IAB members? no - just say that the IAB term ends at the end of the week Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 09:25:20 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00D04X7BRN@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 09:23:35 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00D01X7BRJ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:23:35 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00D01X7ARI@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:23:34 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF008F7X7AW5@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:23:34 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98DNA6U010844 for ; Wed, 08 Oct 2003 09:23:10 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98DNA4Z010843 for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:23:10 -0400 (EDT) Date: Wed, 08 Oct 2003 09:23:10 -0400 (EDT) From: Scott Bradner Subject: IESG Issue 25 To: ietf-nomcom@lists.elistx.com Message-id: <200310081323.h98DNA4Z010843@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > - move the content of 4.9 into 4.3 and edit the text in 4.7 to add the > phrase 'if one has been appointed', right after Trustees. > > Question: should this or some other change be made to the text? this change seems fine > Question: Should text be added describing how the Internet Society > Trustees pick their liaison, should they decide to send one? no - that is an ISOC not an IETF issue Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 09:25:23 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00D04X9KVG@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 09:24:56 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00D01X9KVE@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:24:56 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00D01X9JVC@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:24:56 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF00C45X9JX3@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:24:55 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98DOV6U010854 for ; Wed, 08 Oct 2003 09:24:31 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98DOUsN010853 for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:24:30 -0400 (EDT) Date: Wed, 08 Oct 2003 09:24:30 -0400 (EDT) From: Scott Bradner Subject: IESG Issue 26 To: ietf-nomcom@lists.elistx.com Message-id: <200310081324.h98DOUsN010853@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > Question: Should the draft be restructured prior to resubmission? no - I do not think that a major reorginization will do anything other than add a major chance of messingthings up Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 09:35:09 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00E04XL2GB@eListX.com> (original mail from kre@munnari.OZ.AU); Wed, 08 Oct 2003 09:31:50 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00E01XL2G4@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:31:50 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00E01XL1G2@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:31:49 -0400 (EDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF00C65XKVX3@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:31:49 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h98DVEv12662; Wed, 08 Oct 2003 20:31:14 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h98DV5P19528; Wed, 08 Oct 2003 20:31:07 +0700 (ICT) Date: Wed, 08 Oct 2003 20:31:05 +0700 From: Robert Elz Subject: Re: IESG Issue 22 In-reply-to: <200310081319.h98DJ0Jl010805@newdev.harvard.edu> To: Scott Bradner Cc: ietf-nomcom@lists.elistx.com Message-id: <24239.1065619865@munnari.OZ.AU> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <200310081319.h98DJ0Jl010805@newdev.harvard.edu> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Date: Wed, 08 Oct 2003 09:19:00 -0400 (EDT) From: Scott Bradner Message-ID: <200310081319.h98DJ0Jl010805@newdev.harvard.edu> Scott: | I do not think the WG needed to be asked this type of editorial nit | question I agree with you the other times you made this observation, but not for this one in particular. To save everyone going back to Avri's mail, this one is ... >> The intent of this rule to ensure the review of approximately >> one-half of each of the IESG and IAB sitting members each year. > > s/one-half of each of/one-half of/ I don't agree that making the change is a no-op. Assuming that the IESG and IAB are (approximately) the same size, then one half of the IESG and IAB sitting members could be interpreted as all of the IAB, and none of the IESG (which just could happen should the entire IAB, or IESG, decide to resign over some matter of principle). Given that half the sitting members of the combined bodies are being reviewed, one could interpret this as meaning that there is no need to review any of the members of the body which did not resign en mass. Keep the "each of", it is not redundant. On the other hand, the other change requested in the same issue truly is trivial (s/is/are/) but was a consequence of the change above that should not be made, so it should not be made either. kre From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 09:45:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00E04XR8SI@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 09:35:32 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00E01XR7SG@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:35:31 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00E01XR7SF@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:35:31 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF008I5XR6W5@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:35:31 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98DZ66U010926; Wed, 08 Oct 2003 09:35:06 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98DZ6CS010925; Wed, 08 Oct 2003 09:35:06 -0400 (EDT) Date: Wed, 08 Oct 2003 09:35:06 -0400 (EDT) From: Scott Bradner Subject: Re: IESG Issue 22 In-reply-to: <24239.1065619865@munnari.OZ.AU> To: kre@munnari.OZ.AU, sob@harvard.edu Cc: ietf-nomcom@lists.elistx.com Message-id: <200310081335.h98DZ6CS010925@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: OK - I see the way someone (if they tried hard enough) could misunderstand the intent - I guess its a good idea to protect them from that (and us from them) :-) Scott --- Date: Wed, 08 Oct 2003 20:31:05 +0700 From: Robert Elz Subject: Re: IESG Issue 22 To: Scott Bradner Cc: ietf-nomcom@lists.elistx.com Date: Wed, 08 Oct 2003 09:19:00 -0400 (EDT) From: Scott Bradner Message-ID: <200310081319.h98DJ0Jl010805@newdev.harvard.edu> Scott: | I do not think the WG needed to be asked this type of editorial nit | question I agree with you the other times you made this observation, but not for this one in particular. To save everyone going back to Avri's mail, this one is ... >> The intent of this rule to ensure the review of approximately >> one-half of each of the IESG and IAB sitting members each year. > > s/one-half of each of/one-half of/ I don't agree that making the change is a no-op. Assuming that the IESG and IAB are (approximately) the same size, then one half of the IESG and IAB sitting members could be interpreted as all of the IAB, and none of the IESG (which just could happen should the entire IAB, or IESG, decide to resign over some matter of principle). Given that half the sitting members of the combined bodies are being reviewed, one could interpret this as meaning that there is no need to review any of the members of the body which did not resign en mass. Keep the "each of", it is not redundant. On the other hand, the other change requested in the same issue truly is trivial (s/is/are/) but was a consequence of the change above that should not be made, so it should not be made either. kre From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 09:45:04 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00F04Y35CR@eListX.com> (original mail from brc@zurich.ibm.com); Wed, 08 Oct 2003 09:42:42 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00F01Y35CO@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:42:41 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00F01Y34CK@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 09:42:41 -0400 (EDT) Received: from d12lmsgate.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF00C8IY33X3@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 09:42:40 -0400 (EDT) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h98Dg9o0051186 for ; Wed, 08 Oct 2003 15:42:12 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h98Db4uX043716 for ; Wed, 08 Oct 2003 15:37:04 +0200 Received: from zurich.ibm.com (sig-9-145-224-20.de.ibm.com [9.145.224.20]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA63598 for ; Wed, 08 Oct 2003 15:37:03 +0200 Date: Wed, 08 Oct 2003 15:36:39 +0200 From: Brian E Carpenter Subject: Re: IESG Issue 2 To: ietf-nomcom@lists.elistx.com Message-id: <3F8412E7.EC8B4026@zurich.ibm.com> Organization: IBM MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en,fr,de References: <200310081247.h98Clham010521@newdev.harvard.edu> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: I think Scott is correct that there is an asymmetry. An IAB member moving to an IESG position simply increases the number of identical IAB slots to fill. The process should not require a new call for nominees. What is described in the draft is appropriate. An IESG member moving to the IAB creates an unannounced specific vacancy in the IESG. The process should require a new call for nominees. I think the text needs to be revised to include this asymmetry. Brian Scott Bradner wrote: > > I see little reason to do a new search if the case is someone with > time left in their IAB term moving from the IAB to the IESG. I do > not see a realistic problem that would be solved by doing so. The > community suggested people for the IAB already in the process and > the IAB members should be generalists (i.e. no IAB topic-specific > seats) > > but the case of an IESG member with time left in their term > being moved to the IAB or another IESG seat should cause a > new call for nominees to fill the open IESG seat > > (while moving in mid term from the IESG to the IAB might not > have happened I can easily see the case (its not all that different > from someone just quiting being an IESG member which does happen) > > Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 10:15:10 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00H04ZFBLP@eListX.com> (original mail from kre@munnari.OZ.AU); Wed, 08 Oct 2003 10:11:36 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00H01ZFBLN@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 10:11:35 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00H01ZFBLM@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 10:11:35 -0400 (EDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF00CGEZEXX3@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 10:11:35 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h98EAov14318; Wed, 08 Oct 2003 21:10:52 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h98EAhP13143; Wed, 08 Oct 2003 21:10:44 +0700 (ICT) Date: Wed, 08 Oct 2003 21:10:43 +0700 From: Robert Elz Subject: Re: IESG Issue 2 In-reply-to: <3F8412E7.EC8B4026@zurich.ibm.com> To: Brian E Carpenter Cc: ietf-nomcom@lists.elistx.com Message-id: <22210.1065622243@munnari.OZ.AU> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <3F8412E7.EC8B4026@zurich.ibm.com> <200310081247.h98Clham010521@newdev.harvard.edu> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Date: Wed, 08 Oct 2003 15:36:39 +0200 From: Brian E Carpenter Message-ID: <3F8412E7.EC8B4026@zurich.ibm.com> | I think Scott is correct that there is an asymmetry. I think there could be, but I don't see any reason that it needs to be so. | An IAB member moving to an IESG position simply increases the number | of identical IAB slots to fill. The process should not require a new | call for nominees. Perhaps, but filling that last (new) open IAB position is hardly critical to anything - the IAB would manage just fine with one less member for a month or two. I would not create a special case just to avoid that. | What is described in the draft is appropriate. You're assuming that what the draft says is what it was claimed to say. I disagree with that, I believe that if you read it carefully you'll find it says nothing of the kind. | An IESG member moving to the IAB creates an unannounced specific vacancy in | the IESG. The process should require a new call for nominees. yes, absolutely, and that's what I think the draft now assumes. Perhaps it could be made clearer that this is what it is saying, but I believe that is what is already there. Given that, while I have no problem with clarifying text, I certainly would not be adding special text to allow something different just so the IAB can have an extra member a little quicker. kre From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 10:25:09 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00I04ZWSEP@eListX.com> (original mail from joel@stevecrocker.com) ; Wed, 08 Oct 2003 10:22:04 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00I01ZWSEM@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 10:22:04 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMF00I01ZWSEK@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 10:22:04 -0400 (EDT) Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMF00CIVZWRX3@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 10:22:03 -0400 (EDT) Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5568892 for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 10:21:37 -0400 Date: Wed, 08 Oct 2003 10:21:13 -0400 From: "Joel M. Halpern" Subject: Re: IESG Issue 2 In-reply-to: <22210.1065622243@munnari.OZ.AU> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com To: ietf-nomcom@lists.elistx.com Message-id: <5.1.0.14.0.20031008101739.022b1ac0@mail.stevecrocker.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; format=flowed; charset=us-ascii References: <3F8412E7.EC8B4026@zurich.ibm.com> <3F8412E7.EC8B4026@zurich.ibm.com> <200310081247.h98Clham010521@newdev.harvard.edu> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: While one may argue that the document should say that new IESG openings need to be "advertised", that is not what I understand it to currently say. My understanding of the document and of the discussion in the working group is that we decided not to make moving people a major difficulty, and therefore decided to allow quasi-simultaneous filling of created openings. My own reading and estimating of reactions is that if we declare that openings that are created by moving people must be publicly vacated, solicited, and filled then we are essentially telling the nomcom not to move people around. Because no nomcom is going to want to make that much extra work for itself. If we want to make moving people an emergency maneuver, we can. I personally do not want to make such a change to the accepted practice. Yours, Joel M. Halpern At 09:10 PM 10/8/2003 +0700, Robert Elz wrote: > Date: Wed, 08 Oct 2003 15:36:39 +0200 > From: Brian E Carpenter > Message-ID: <3F8412E7.EC8B4026@zurich.ibm.com> > > | I think Scott is correct that there is an asymmetry. > >I think there could be, but I don't see any reason that it needs to be so. > > | An IAB member moving to an IESG position simply increases the number > | of identical IAB slots to fill. The process should not require a new > | call for nominees. > >Perhaps, but filling that last (new) open IAB position is hardly >critical to anything - the IAB would manage just fine with one less >member for a month or two. I would not create a special case just >to avoid that. > > | What is described in the draft is appropriate. > >You're assuming that what the draft says is what it was claimed to >say. I disagree with that, I believe that if you read it carefully >you'll find it says nothing of the kind. > > | An IESG member moving to the IAB creates an unannounced specific > vacancy in > | the IESG. The process should require a new call for nominees. > >yes, absolutely, and that's what I think the draft now assumes. Perhaps >it could be made clearer that this is what it is saying, but I believe that >is what is already there. > >Given that, while I have no problem with clarifying text, I certainly would >not be adding special text to allow something different just so the IAB can >have an extra member a little quicker. > >kre > > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 11:15:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00M042248F@eListX.com> (original mail from rja@extremenetworks.com) ; Wed, 08 Oct 2003 11:08:28 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00M012238D@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 11:08:27 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00M012238C@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 11:08:27 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMG00J7U222MS@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 11:08:27 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.103]) by gnat.inet.org (Postfix) with ESMTP id 82F6367113; Wed, 08 Oct 2003 11:11:32 -0400 (EDT) Date: Wed, 08 Oct 2003 11:08:01 -0400 From: RJ Atkinson Subject: Re: [IESG-6] IESG/IAB overlaps (Re: IESG issues with draft-ietf-nomcom-rfc2727bis-07) In-reply-to: <184907182.1065607889@localhost> To: Harald Tveit Alvestrand Cc: ietf-nomcom@lists.elistx.com Message-id: <35A3BE74-F9A1-11D7-AC68-00039357A82A@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Wednesday, Oct 8, 2003, at 04:11 America/Montreal, Harald Tveit Alvestrand wrote: > I believe the issue Ted brought up was triggered by the presence in > both bodies of the IAB chair, and that he thought the description for > the IETF chair was adequate. > > Another possible fix, covering even more people: > > "Some people serve on both the IESG and IAB as part of their role, > such as the IETF Chair, the IAB Chair and the IAB-IESG liaisons. Apart > from these, no person should serve both on the IAB and on the IESG." That is too confusing, IMHO. Also, I don't know what that version is trying to fix relative to the much simpler text that I had proposed. So I suspect that I am not following some subtlety of meaning that is obvious to you (and others ?). Maybe you could clarify your specific concerns with my proposed text (quoted below) ? > BTW, RFC 2850 says that the IETF Chair is a "full member" of the IAB > (section 1.1), but not a "sitting" member (section 1). Well-covered > ground. Right. Which is why my proposed text specifically used the phrase "sitting member" as the thing that an IESG person could not concurrently be. My reference to "ex officio" was NOT in the proposed new text, but by way of explanation for this mailing list. In at least US & UK English, "ex officio" means that someone has some role/position as a derivative of holding a different office. It does not necessarily mean that any "ex officio" person has lesser status than other persons. If the IETF has tried to alter the standard definition for "ex officio", in RFC-2850 or elsewhere, that is very unfortunate because it means that the IETF is not using standard English (per Websters or the OED; my own dictionary at home is the OED). Just to be crystal clear, my ENTIRE proposed replacement text is: "No person should serve both as a sitting member of the IAB and as a member of the IESG." My text permits liaisons. It also permits IETF Chair to be part of the IAB, but does not permit the IETF Chair to be a sitting member of the IAB. Confusedly yours, Ran > --On 7. oktober 2003 13:06 -0400 RJ Atkinson > wrote: > >>> "No person should serve both on the IAB and as an Area Director, >>> except >>> the IETF Chair whose roles as an IAB member and Area Director of the >>> General Area is set out elsewhere". >> >> That proposed fix seems problematic. An alternative phrasing, >> which I prefer (yet also suspect is consistent with Ted's intent) >> might be: >> >> "No person should serve both as a sitting member of the IAB >> and as a member of the IESG." >> >> Kindly recall that the IESG Chair (== IETF Chair) is not a >> "sitting member of the IAB", neither now nor in the past, >> but is instead an "ex-officio member of the IAB". From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 11:15:07 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00M0426QIH@eListX.com> (original mail from rja@extremenetworks.com) ; Wed, 08 Oct 2003 11:11:14 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00M0126PIF@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 11:11:13 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00M0126PIE@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 11:11:13 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMG00GFO26PHS@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 11:11:13 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.103]) by gnat.inet.org (Postfix) with ESMTP id F1E706710F; Wed, 08 Oct 2003 11:14:18 -0400 (EDT) Date: Wed, 08 Oct 2003 11:10:47 -0400 From: RJ Atkinson Subject: Re: IESG issue 2 (Re: IESG issues with draft-ietf-nomcom-rfc2727bis-07) In-reply-to: <15775.1065614161@munnari.OZ.AU> To: Robert Elz Cc: ietf-nomcom@lists.elistx.com Message-id: <98C99844-F9A1-11D7-AC68-00039357A82A@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: The quoted text below from KRE is entirely consistent with what I thought this WG was saying (and trying to say) with the current text. I agree with KRE that the best approach would be to fix the wording to be more clear, given that some IESG folks find the current text confusing, rather than to try to change the intended meaning. Ran On Wednesday, Oct 8, 2003, at 07:56 America/Montreal, Robert Elz wrote: > Reading the procedure, it is fairly clear (to me anyway) that the > vacancy occurs only after confirmation (and announcement) of the new > positions, and is then handled just like any other mid term vacancy > (like one occurring in the middle of the normal term for whatever > reason). > > If the wording needs to be tweaked to make that even clearer, I doubt > anyone would object. > > I don't think there's any rational way to have the newly vacant > position > filled as a part of the initial nomcom process though (though the > nomcom > may well be aware that a vacancy is likely, and perpare for it, so the > mid-term vacancy processing might end up being quite quick by > comparison > with other events). And this is regardless of whether the new > position is > an IESG position or an IAB position. > > To answer Avri's final question: > >> Do full mid term replacement rules, including public announcement >> apply >> to this case? > > Yes, of course they do. I find it hard to even imagine how the > text can be read so as to imply otherwise. All this happens after > confirmation and announcement of the results of the nomcom process > that caused it - not during. > > kre From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 11:25:05 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG000042HR3S@eListX.com> (original mail from david.putzolu@intel.com) ; Wed, 08 Oct 2003 11:17:51 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG000012HQ3Q@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 11:17:50 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG000012HQ3I@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 11:17:50 -0400 (EDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMG00JB82HPMS@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 11:17:49 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h98FHp7n031930 for ; Wed, 08 Oct 2003 15:17:51 +0000 (GMT) Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h98FBnV10343 for ; Wed, 08 Oct 2003 15:11:49 +0000 (GMT) Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003100808171204759 for ; Wed, 08 Oct 2003 08:17:12 -0700 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 08 Oct 2003 08:17:12 -0700 Date: Wed, 08 Oct 2003 08:17:12 -0700 From: "Putzolu, David" Subject: RE: IESG Issue 5 To: ietf-nomcom@lists.elistx.com Message-id: <52D13A805349A249960B9943E5590BD881F57C@orsmsx409.jf.intel.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: QUOTED-PRINTABLE Thread-Topic: IESG Issue 5 Thread-Index: AcONmz3w+hDRkYOVSVG4Dm7O1CPxkQAEyuiQ Content-Class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: X-OriginalArrivalTime: 08 Oct 2003 15:17:12.0743 (UTC) FILETIME=[3FE76B70:01C38DAF] I agree with this - WG chairs have exposure to IESG members=20 routinely (at least in the area of their wg) and so are=20 likely to have a decently informed opinion. -David > -----Original Message----- > From: Scott Bradner [mailto:sob@harvard.edu]=20 > Sent: Wednesday, October 08, 2003 5:54 AM > To: ietf-nomcom@lists.elistx.com > Subject: IESG Issue 5 >=20 >=20 >=20 > > Question: Should WG chairs be added to the list of those=20 > who should be =20 > > consulted? >=20 > YES!!!! >=20 > the idea that the nomcom can reasonabally evaluate a sitting=20 > AD without > talking to the WG chairs is plain silly >=20 > Scott >=20 > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: >=20 From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 11:25:07 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG000042PNFX@eListX.com> (original mail from rja@extremenetworks.com) ; Wed, 08 Oct 2003 11:22:36 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG000012PNFV@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 11:22:35 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG000012PNFU@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 11:22:35 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMG00JCP2PMMS@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 11:22:35 -0400 (EDT) Received: from extremenetworks.com (unknown [10.18.3.103]) by gnat.inet.org (Postfix) with ESMTP id 94B5D6710F; Wed, 08 Oct 2003 11:25:40 -0400 (EDT) Date: Wed, 08 Oct 2003 11:22:09 -0400 From: RJ Atkinson Subject: Re: IESG Issue 24 In-reply-to: <200310081321.h98DLOQu010827@newdev.harvard.edu> To: Scott Bradner Cc: ietf-nomcom@lists.elistx.com Message-id: <2EF87E35-F9A3-11D7-AC68-00039357A82A@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Wednesday, Oct 8, 2003, at 09:21 America/Montreal, Scott Bradner wrote: >> Questions: >> >> Should the question of starting time for IAB be separated from the >> question of IESG? > > yes > >> Should it be pointed out that since IAB members do not replace >> specific >> IAB members, it is consistent that new IAB members may overlap with >> retiring IAB members? > > no - just say that the IAB term ends at the end of the week In practice, there have been at least 2 occasions in the past 4 years when an outgoing IAB member left the "sitting IAB" at the beginning of the week. One of these was in San Francisco 2003, where following current procedures, I arranged with Itojun that he would replace me as the "sitting IAB member" at the start of the week. I attended several IAB functions during that week, by way of helping with transition, but I was not a "sitting member" while doing so. So I would say it is undesirable to have a fixed handoff at the end of the week. If there is to be a fixed handoff, it would best be start of the week. My preference would be that the current, flexible, "during the week" handoff be retained, however. Ran Atkinson rja@extremenetworks.com From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 11:35:08 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG0010435376@eListX.com> (original mail from Margaret.Wasserman@nokia.com); Wed, 08 Oct 2003 11:31:51 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG0010135374@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 11:31:51 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG0010135373@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 11:31:51 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMG00JER351MS@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 11:31:50 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h98FVPt12444 for ; Wed, 08 Oct 2003 18:31:25 +0300 (EET DST) Received: from daebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 08 Oct 2003 18:31:21 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 08 Oct 2003 10:30:14 -0500 Date: Wed, 08 Oct 2003 11:30:13 -0400 From: Margaret.Wasserman@nokia.com Subject: RE: IESG Issue 2 To: sob@harvard.edu, ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE Thread-Topic: IESG Issue 2 Thread-Index: AcONmnRqk8BfAomCQRC/50Pm+CGi3QAFeCaA content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: X-OriginalArrivalTime: 08 Oct 2003 15:30:14.0993 (UTC) FILETIME=[12294C10:01C38DB1] Hi Scott, > I see little reason to do a new search if the case is someone with > time left in their IAB term moving from the IAB to the IESG. I do > not see a realistic problem that would be solved by doing so. The > community suggested people for the IAB already in the process and > the IAB members should be generalists (i.e. no IAB topic-specific > seats) I agree with you in the general case. In other words, I think it would be fine to fill 6 IAB postions from the nominations that were made for 5 open positions. I don't think that everyone agrees with this, but I do. In an interim replacement, though, this is less clear. If, for example, a sitting IAB member had been chosen to replace Erik Nordmark (instead of me), I don't think that the nomcom should have filled that now-open IAB position without a new call for=20 nominationsm (even though they had a list of previous nominations =66rom the full selection cycle). =20 Margaret From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 11:35:11 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG0010436K99@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 11:32:44 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG0010136J97@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 11:32:44 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG0010136J96@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 11:32:43 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMG00JEX36JMS@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 11:32:43 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98FWJ6U011556; Wed, 08 Oct 2003 11:32:19 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98FWJbo011555; Wed, 08 Oct 2003 11:32:19 -0400 (EDT) Date: Wed, 08 Oct 2003 11:32:19 -0400 (EDT) From: Scott Bradner Subject: RE: IESG Issue 2 In-reply-to: To: ietf-nomcom@lists.elistx.com, Margaret.Wasserman@nokia.com, sob@harvard.edu Message-id: <200310081532.h98FWJbo011555@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: fully agree --- From Margaret.Wasserman@nokia.com Wed Oct 8 11:31:27 2003 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IESG Issue 2 Date: Wed, 8 Oct 2003 11:30:13 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IESG Issue 2 Thread-Index: AcONmnRqk8BfAomCQRC/50Pm+CGi3QAFeCaA From: To: , X-OriginalArrivalTime: 08 Oct 2003 15:30:14.0993 (UTC) FILETIME=[12294C10:01C38DB1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by newdev.harvard.edu id h98FVQ6U011527 Hi Scott, > I see little reason to do a new search if the case is someone with > time left in their IAB term moving from the IAB to the IESG. I do > not see a realistic problem that would be solved by doing so. The > community suggested people for the IAB already in the process and > the IAB members should be generalists (i.e. no IAB topic-specific > seats) I agree with you in the general case. In other words, I think it would be fine to fill 6 IAB postions from the nominations that were made for 5 open positions. I don't think that everyone agrees with this, but I do. In an interim replacement, though, this is less clear. If, for example, a sitting IAB member had been chosen to replace Erik Nordmark (instead of me), I don't think that the nomcom should have filled that now-open IAB position without a new call for nominationsm (even though they had a list of previous nominations from the full selection cycle). Margaret From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 11:45:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG001043CGN9@eListX.com> (original mail from dhc@dcrocker.net); Wed, 08 Oct 2003 11:36:16 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG001013CGN7@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 11:36:16 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG001013CFN6@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 11:36:15 -0400 (EDT) Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMG00JGF3CFMS@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 11:36:15 -0400 (EDT) Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h98FfRf30144 for ; Wed, 08 Oct 2003 08:41:27 -0700 Date: Wed, 08 Oct 2003 08:35:40 -0700 From: Dave Crocker Subject: Re: IESG Issue 5 In-reply-to: <200310081253.h98Cro2w010556@newdev.harvard.edu> To: ietf-nomcom@lists.elistx.com Reply-to: Dave Crocker Message-id: <113132799225.20031008083540@brandenburg.com> Organization: Brandenburg InternetWorking MIME-version: 1.0 X-Mailer: The Bat! (v2.00.22) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) References: <200310081253.h98Cro2w010556@newdev.harvard.edu> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: >> Question: Should WG chairs be added to the list of those who should be >> consulted? SB> YES!!!! SB> the idea that the nomcom can reasonabally evaluate a sitting AD without SB> talking to the WG chairs is plain silly In fact, working group editors often have the content-related interactions with area directors. One of the serious difficulties caused by nominee anonymity is that others with direct knowledge about a candidate cannot know to offer their insight. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 11:45:05 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG001043H3WY@eListX.com> (original mail from Margaret.Wasserman@nokia.com); Wed, 08 Oct 2003 11:39:03 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG001013H3WS@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 11:39:03 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG001013H2WQ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 11:39:02 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMG00GO83H1HS@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 11:39:02 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h98Fcbt19575 for ; Wed, 08 Oct 2003 18:38:37 +0300 (EET DST) Received: from daebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 08 Oct 2003 18:38:36 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 08 Oct 2003 10:38:34 -0500 Date: Wed, 08 Oct 2003 11:38:33 -0400 From: Margaret.Wasserman@nokia.com Subject: RE: IESG Issue 21 To: sob@harvard.edu, ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE Thread-Topic: IESG Issue 21 Thread-Index: AcONnpNR7x8Zp5YeTuulrTKXMA1XyQAEvyLA content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: X-OriginalArrivalTime: 08 Oct 2003 15:38:34.0656 (UTC) FILETIME=[3BFBD200:01C38DB2] > > Question: Should the document be renumbered using a more=20 > > conventional numbering scheme? >=20 > I guess that "a more conventional numbering scheme" means having > section heads like 3.1 >=20 > if that is what is meant, it would be better Yes, this is what I meant. The current document is structured as a set of bulleted lists, instead of a set of sub-sections. This is different from=20 most other RFCs, and it makes it more difficult to refer to=20 a particular section by number -- at least I found it=20 difficult when preparing my comments. The current structure is somewhat like the structure of=20 RFC 2727, but I even found the structure of RFC 2727 clearer, because the different levels of indexing used different formats (1., (1), a.) rather than using the same format. Please note, though, that this was an editorial suggestion. I don't consider this a blocking problem, and it should only be addressed if our other discussions result take long=20 enough that this can be accomplished without delaying the document. From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 11:55:15 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG0030446MAC@eListX.com> (original mail from Margaret.Wasserman@nokia.com); Wed, 08 Oct 2003 11:54:22 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG0030146LAA@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 11:54:21 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG0030146LA9@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 11:54:21 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMG0030K46K11@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 11:54:21 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h98Frt629713 for ; Wed, 08 Oct 2003 18:53:55 +0300 (EET DST) Received: from daebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 08 Oct 2003 18:53:52 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 08 Oct 2003 10:53:42 -0500 Date: Wed, 08 Oct 2003 11:53:41 -0400 From: Margaret.Wasserman@nokia.com Subject: RE: IESG Issue 1 To: kre@munnari.OZ.AU Cc: iesg@ietf.org, ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE Thread-Topic: IESG Issue 1 Thread-Index: AcONnpReIYAj9D1DSeeI950spuQ45QAE8uHg content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: X-OriginalArrivalTime: 08 Oct 2003 15:53:42.0355 (UTC) FILETIME=[5903B230:01C38DB4] >| The list of positions is posted publicly along with the call for >| nominations. So, would this information (which will come in throu= gh >| the same channel, probably at the same time) also be posted public= ly? >=20 > I agree with Scott's answer to Avri's question. Yes, of=20 > course it is. >=20 > How could anyone rationally imagine a job ad (which is=20 > essentially what a call for nominations is - except no=20 > remuneration is being offered...)in which there was no=20 > statement of what qualifications and abilities are > expected of those who might apply (or be nominated for)=20 > the job in question. >=20 > That information is essential. No information of this sort has been included in any of=20 the nomcom announcements that I've ever seen. I have not been on the IESG/IAB during a nomcom cycle, so I can't personally attest to whether it was sent to the nomcom or not, but it wasn't published. I applaud the nomcom WG for adding the requirement that the IESG and IAB submit a list of qualifications. I am=20 also glad that you, at least, think it should be sent=20 publicly, because that is my preference. However, I couldn't find anywhere in the document that actually _says_ that, and I did find at least one place (see below) that seemed (to me) to indicate otherwise. We have now spent approximately 10 times as much effort arguing about whether or not this is clear than it would have taken to write the text to clarify it... If the nomcom WG agrees that it was your intent that this information should be sent publicly, how about making=20 that explicit like this: OLD: 14. The Chair obtains the list of IESG and IAB positions to be reviewed and announces it along with a solicitation for names= of volunteers from the IETF community willing to serve on the nominating committee. NEW: 14. The Chair obtains the list of IESG and IAB positions to be =09 reviewed and a description of the desirable qualifications for= =20 those positions. This information is announced, along with a= =20 solicitation for names of volunteers from the IETF community= =20 willing to serve on the nominating committee. Margaret >=20 From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 12:05:05 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG004044JN2X@eListX.com> (original mail from david.putzolu@intel.com) ; Wed, 08 Oct 2003 12:02:11 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG004014JN2U@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 12:02:11 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG004014JL2T@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 12:02:09 -0400 (EDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMG0032J4JI11@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 12:02:09 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h98G1bhH008442 for ; Wed, 08 Oct 2003 16:01:37 +0000 (GMT) Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h98FtaV16860 for ; Wed, 08 Oct 2003 15:55:36 +0000 (GMT) Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003100809010724450 ; Wed, 08 Oct 2003 09:01:07 -0700 Received: from orsmsx409.amr.corp.intel.com ([192.168.65.58]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 08 Oct 2003 09:01:07 -0700 Date: Wed, 08 Oct 2003 09:01:06 -0700 From: "Putzolu, David" Subject: RE: IESG Issue 1 To: ietf-nomcom@lists.elistx.com Cc: iesg@ietf.org Message-id: <52D13A805349A249960B9943E5590BD881F57E@orsmsx409.jf.intel.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: QUOTED-PRINTABLE Thread-Topic: IESG Issue 1 Thread-Index: AcONnpReIYAj9D1DSeeI950spuQ45QAE8uHgAACZs3A= Content-Class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: X-OriginalArrivalTime: 08 Oct 2003 16:01:07.0612 (UTC) FILETIME=[626885C0:01C38DB5] Announcing the qualifications is a good change, and the text looks good to me. In the interest of being completely=20 precise, add where it is announced: OLD NEW: 14. The Chair obtains the list of IESG and IAB positions to be =09 reviewed and a description of the desirable qualifications for those positions. This information is announced, along with a= =20 solicitation for names of volunteers from the IETF community= =20 willing to serve on the nominating committee. NEW: 14. The Chair obtains the list of IESG and IAB positions to be =09 reviewed and a description of the desirable qualifications for those positions. This information is announced on=20 ietf-announce@ietf.org, along with a solicitation for names= =20 of volunteers from the IETF community willing to serve on= =20 the nominating committee. -David > -----Original Message----- > From: Margaret.Wasserman@nokia.com=20 > [mailto:Margaret.Wasserman@nokia.com]=20 > Sent: Wednesday, October 08, 2003 8:54 AM > To: kre@munnari.OZ.AU > Cc: iesg@ietf.org; ietf-nomcom@lists.elistx.com > Subject: RE: IESG Issue 1 >=20 >=20 > >| The list of positions is posted publicly along with the call for > >| nominations. So, would this information (which will come=20 > in through > >| the same channel, probably at the same time) also be=20 > posted publicly? > >=20 > > I agree with Scott's answer to Avri's question. Yes, of=20 > > course it is. > >=20 > > How could anyone rationally imagine a job ad (which is=20 > > essentially what a call for nominations is - except no=20 > > remuneration is being offered...)in which there was no=20 > > statement of what qualifications and abilities are > > expected of those who might apply (or be nominated for)=20 > > the job in question. > >=20 > > That information is essential. >=20 > No information of this sort has been included in any of=20 > the nomcom announcements that I've ever seen. I have not > been on the IESG/IAB during a nomcom cycle, so I can't > personally attest to whether it was sent to the nomcom or > not, but it wasn't published. >=20 > I applaud the nomcom WG for adding the requirement that > the IESG and IAB submit a list of qualifications. I am=20 > also glad that you, at least, think it should be sent=20 > publicly, because that is my preference. >=20 > However, I couldn't find anywhere in the document that > actually _says_ that, and I did find at least one place > (see below) that seemed (to me) to indicate otherwise. >=20 > We have now spent approximately 10 times as much effort > arguing about whether or not this is clear than it would > have taken to write the text to clarify it... >=20 > If the nomcom WG agrees that it was your intent that this > information should be sent publicly, how about making=20 > that explicit like this: >=20 > OLD: >=20 > 14. The Chair obtains the list of IESG and IAB positions to be > reviewed and announces it along with a solicitation=20 > for names of > volunteers from the IETF community willing to serve on the > nominating committee. >=20 > NEW: >=20 > 14. The Chair obtains the list of IESG and IAB positions to be > =09 reviewed and a description of the desirable=20 > qualifications for=20 > those positions. This information is announced, along with = a=20 > solicitation for names of volunteers from the IETF communit= y=20 > willing to serve on the nominating committee. >=20 > Margaret >=20 > >=20 >=20 > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: >=20 From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 12:15:05 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG004044YNW4@eListX.com> (original mail from harald@alvestrand.no); Wed, 08 Oct 2003 12:11:11 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG004014YMW2@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 12:11:11 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG004014YMW1@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 12:11:10 -0400 (EDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMG0034T4YL10@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 12:11:10 -0400 (EDT) Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6B52B61D30; Wed, 08 Oct 2003 18:10:36 +0200 (CEST) Date: Wed, 08 Oct 2003 17:35:51 +0200 From: Harald Tveit Alvestrand Subject: Re: IESG Issue 1 In-reply-to: <12859.1065619028@munnari.OZ.AU> To: Robert Elz , Margaret.Wasserman@nokia.com Cc: ietf-nomcom@lists.elistx.com Message-id: <14764440.1065634551@localhost> MIME-version: 1.0 X-Mailer: Mulberry/3.1.0b8 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <12859.1065619028@munnari.OZ.AU> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: [taking IESG off the CC] --On 8. oktober 2003 20:17 +0700 Robert Elz wrote: > | The list of positions is posted publicly along with the call for > | nominations. So, would this information (which will come in through > | the same channel, probably at the same time) also be posted publicly? > > I agree with Scott's answer to Avri's question. Yes, of course it is. > > How could anyone rationally imagine a job ad (which is essentially what > a call for nominations is - except no remuneration is being offered...) > in which there was no statement of what qualifications and abilities are > expected of those who might apply (or be nominated for) the job in > question. > > That information is essential. so let the document say that. Discussion over. btw, I agree that this is a sensible thing for the document to say. From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 12:15:07 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG004044YZWM@eListX.com> (original mail from harald@alvestrand.no); Wed, 08 Oct 2003 12:11:23 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG004014YZWK@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 12:11:23 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG004014YZWJ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 12:11:23 -0400 (EDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMG0034W4YY11@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 12:11:22 -0400 (EDT) Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E285061C78; Wed, 08 Oct 2003 18:10:51 +0200 (CEST) Date: Wed, 08 Oct 2003 17:52:30 +0200 From: Harald Tveit Alvestrand Subject: Re: IESG Issue 7 In-reply-to: <200310081256.h98CujI5010578@newdev.harvard.edu> To: Scott Bradner , ietf-nomcom@lists.elistx.com Message-id: <15763797.1065635550@localhost> MIME-version: 1.0 X-Mailer: Mulberry/3.1.0b8 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <200310081256.h98CujI5010578@newdev.harvard.edu> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: --On 8. oktober 2003 08:56 -0400 Scott Bradner wrote: > >> Questions: >> >> Is a change to the text required to make the two situation consistent? > > why not just make a blanket statement that the recall & nomcom committiees > work the same way? this was the difference between a recalled nomcom member and a resigned nomcom member, not between the recall & nomcom comittees. Reproducing Avri's text: > IESG Issue 7 > ----------------- > > >> >> Thomas Narten: >> >> If a voting volunteer member is recalled the committee may >>> choose to proceed with only 9 voting volunteers at its own >>> discretion. In all other cases the Chair must repeat the >>> random >>> selection process including an announcement of the iteration >> >>> prior to the actual selection as stated elsewhere in this >>> document. >> >> The above implies to me that the nomcome is required to find a >> replacement for a resignation, but is not for a recall. Shouldn't the >> nomcom be allowed to also not replace resignations? I.e, I assume that >> the nomcom would have the option of filling or not filling any nomcom >> opening, regardless of how it occurs. > > Questions: > > Is a change to the text required to make the two situation consistent? From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 13:55:08 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00B049J3K6@eListX.com> (original mail from brc@zurich.ibm.com); Wed, 08 Oct 2003 13:49:51 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00B019J2K4@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 13:49:50 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00B019J2K3@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 13:49:50 -0400 (EDT) Received: from d12lmsgate.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMG00B1N9J12U@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 13:49:50 -0400 (EDT) Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h98HnONb097678; Wed, 08 Oct 2003 19:49:25 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h98HnJWZ215840; Wed, 08 Oct 2003 19:49:19 +0200 Received: from zurich.ibm.com (sig-9-145-242-229.de.ibm.com [9.145.242.229]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id TAA59914; Wed, 08 Oct 2003 19:49:17 +0200 Date: Wed, 08 Oct 2003 19:23:22 +0200 From: Brian E Carpenter Subject: Re: IESG Issue 2 To: "Joel M. Halpern" Cc: ietf-nomcom@lists.elistx.com Message-id: <3F84480A.9999AEDA@zurich.ibm.com> Organization: IBM MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en,fr,de References: <3F8412E7.EC8B4026@zurich.ibm.com> <3F8412E7.EC8B4026@zurich.ibm.com> <200310081247.h98Clham010521@newdev.harvard.edu> <5.1.0.14.0.20031008101739.022b1ac0@mail.stevecrocker.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: "Joel M. Halpern" wrote: > > While one may argue that the document should say that new IESG openings > need to be "advertised", that is not what I understand it to currently say. Correct. > My understanding of the document and of the discussion in the working group > is that we decided not to make moving people a major difficulty, and > therefore decided to allow quasi-simultaneous filling of created openings. Correct. But if (and it seems unlikely to me) a sitting IESG member is appointed to the IAB, and no nominees have been solicited for that IESG slot, the current text seems to allow the Nomcom to pick a candidate out of thin air. That seems like a bug. > > My own reading and estimating of reactions is that if we declare that > openings that are created by moving people must be publicly vacated, > solicited, and filled then we are essentially telling the nomcom not to > move people around. Because no nomcom is going to want to make that much > extra work for itself. Yes. But the situation I've mentioned above (an Area Director jumps ship late during the NomCom process to join the IAB) does seem like an extraordinary case and not one that any NomCom is likely to create spontaneously anyway. If we want to give the NomCom discretion to move ADs around (and I think we do) let's just say so. We could replace the whole disputed text, e.g. It is consistent with these rules for the Nominating Committee to nominate a sitting Area Director to a different Area and simultaneously nominate a new Area Director to the position thus vacated, or to nominate a sitting IAB member to an Area Director position and simultaneously nominate a new IAB member to the position thus vacated. Any other moves between positions must be treated as resignations that create bmid-term vacancies. Brian > If we want to make moving people an emergency maneuver, we can. I > personally do not want to make such a change to the accepted practice. In terms of moving people between different AD slots, I agree. It's only the case of creating a completely new vacancy by moving an AD to the IAB that bothers me. > > Yours, > Joel M. Halpern > > At 09:10 PM 10/8/2003 +0700, Robert Elz wrote: > > Date: Wed, 08 Oct 2003 15:36:39 +0200 > > From: Brian E Carpenter > > Message-ID: <3F8412E7.EC8B4026@zurich.ibm.com> > > > > | I think Scott is correct that there is an asymmetry. > > > >I think there could be, but I don't see any reason that it needs to be so. > > > > | An IAB member moving to an IESG position simply increases the number > > | of identical IAB slots to fill. The process should not require a new > > | call for nominees. > > > >Perhaps, but filling that last (new) open IAB position is hardly > >critical to anything - the IAB would manage just fine with one less > >member for a month or two. I would not create a special case just > >to avoid that. > > > > | What is described in the draft is appropriate. > > > >You're assuming that what the draft says is what it was claimed to > >say. I disagree with that, I believe that if you read it carefully > >you'll find it says nothing of the kind. > > > > | An IESG member moving to the IAB creates an unannounced specific > > vacancy in > > | the IESG. The process should require a new call for nominees. > > > >yes, absolutely, and that's what I think the draft now assumes. Perhaps > >it could be made clearer that this is what it is saying, but I believe that > >is what is already there. > > > >Given that, while I have no problem with clarifying text, I certainly would > >not be adding special text to allow something different just so the IAB can > >have an extra member a little quicker. > > > >kre > > > > > >---------------------------------------------------------------- > >To subscribe or unsubscribe from this elist use the subscription > >manager: > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 13:55:10 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00B049JDKU@eListX.com> (original mail from brc@zurich.ibm.com); Wed, 08 Oct 2003 13:50:01 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00B019JDKQ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 13:50:01 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00B019JCKO@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 13:50:00 -0400 (EDT) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMG00B1R9JB2U@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 13:50:00 -0400 (EDT) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h98HnYfw089880; Wed, 08 Oct 2003 19:49:34 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h98HnYuX182862; Wed, 08 Oct 2003 19:49:34 +0200 Received: from zurich.ibm.com (sig-9-145-242-229.de.ibm.com [9.145.242.229]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id TAA59918; Wed, 08 Oct 2003 19:49:22 +0200 Date: Wed, 08 Oct 2003 19:23:22 +0200 From: Brian E Carpenter Subject: Re: IESG Issue 2 To: "Joel M. Halpern" Cc: ietf-nomcom@lists.elistx.com Message-id: <3F84480A.9999AEDA@zurich.ibm.com> Organization: IBM MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en,fr,de References: <3F8412E7.EC8B4026@zurich.ibm.com> <3F8412E7.EC8B4026@zurich.ibm.com> <200310081247.h98Clham010521@newdev.harvard.edu> <5.1.0.14.0.20031008101739.022b1ac0@mail.stevecrocker.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: "Joel M. Halpern" wrote: > > While one may argue that the document should say that new IESG openings > need to be "advertised", that is not what I understand it to currently say. Correct. > My understanding of the document and of the discussion in the working group > is that we decided not to make moving people a major difficulty, and > therefore decided to allow quasi-simultaneous filling of created openings. Correct. But if (and it seems unlikely to me) a sitting IESG member is appointed to the IAB, and no nominees have been solicited for that IESG slot, the current text seems to allow the Nomcom to pick a candidate out of thin air. That seems like a bug. > > My own reading and estimating of reactions is that if we declare that > openings that are created by moving people must be publicly vacated, > solicited, and filled then we are essentially telling the nomcom not to > move people around. Because no nomcom is going to want to make that much > extra work for itself. Yes. But the situation I've mentioned above (an Area Director jumps ship late during the NomCom process to join the IAB) does seem like an extraordinary case and not one that any NomCom is likely to create spontaneously anyway. If we want to give the NomCom discretion to move ADs around (and I think we do) let's just say so. We could replace the whole disputed text, e.g. It is consistent with these rules for the Nominating Committee to nominate a sitting Area Director to a different Area and simultaneously nominate a new Area Director to the position thus vacated, or to nominate a sitting IAB member to an Area Director position and simultaneously nominate a new IAB member to the position thus vacated. Any other moves between positions must be treated as resignations that create bmid-term vacancies. Brian > If we want to make moving people an emergency maneuver, we can. I > personally do not want to make such a change to the accepted practice. In terms of moving people between different AD slots, I agree. It's only the case of creating a completely new vacancy by moving an AD to the IAB that bothers me. > > Yours, > Joel M. Halpern > > At 09:10 PM 10/8/2003 +0700, Robert Elz wrote: > > Date: Wed, 08 Oct 2003 15:36:39 +0200 > > From: Brian E Carpenter > > Message-ID: <3F8412E7.EC8B4026@zurich.ibm.com> > > > > | I think Scott is correct that there is an asymmetry. > > > >I think there could be, but I don't see any reason that it needs to be so. > > > > | An IAB member moving to an IESG position simply increases the number > > | of identical IAB slots to fill. The process should not require a new > > | call for nominees. > > > >Perhaps, but filling that last (new) open IAB position is hardly > >critical to anything - the IAB would manage just fine with one less > >member for a month or two. I would not create a special case just > >to avoid that. > > > > | What is described in the draft is appropriate. > > > >You're assuming that what the draft says is what it was claimed to > >say. I disagree with that, I believe that if you read it carefully > >you'll find it says nothing of the kind. > > > > | An IESG member moving to the IAB creates an unannounced specific > > vacancy in > > | the IESG. The process should require a new call for nominees. > > > >yes, absolutely, and that's what I think the draft now assumes. Perhaps > >it could be made clearer that this is what it is saying, but I believe that > >is what is already there. > > > >Given that, while I have no problem with clarifying text, I certainly would > >not be adding special text to allow something different just so the IAB can > >have an extra member a little quicker. > > > >kre > > > > > >---------------------------------------------------------------- > >To subscribe or unsubscribe from this elist use the subscription > >manager: > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 15:25:00 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00I04DM87G@eListX.com> (original mail from sob@newdev.harvard.edu) ; Wed, 08 Oct 2003 15:18:08 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00I01DM87D@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 15:18:08 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00I01DM77C@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 15:18:08 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMG00H1VDM7Q8@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 15:18:07 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h98JHh6U012577; Wed, 08 Oct 2003 15:17:43 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h98JHdRO012575; Wed, 08 Oct 2003 15:17:39 -0400 (EDT) Date: Wed, 08 Oct 2003 15:17:39 -0400 (EDT) From: Scott Bradner Subject: Re: IESG Issue 2 In-reply-to: <3F84480A.9999AEDA@zurich.ibm.com> To: brc@zurich.ibm.com, joel@stevecrocker.com Cc: ietf-nomcom@lists.elistx.com Message-id: <200310081917.h98JHdRO012575@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > It is consistent with these rules for the Nominating Committee > to nominate a sitting Area Director to a different Area and simultaneously > nominate a new Area Director to the position thus vacated, or to > nominate a sitting IAB member to an Area Director position and > simultaneously nominate a new IAB member to the position thus vacated. > Any other moves between positions must be treated as resignations > that create bmid-term vacancies. I'm fine with the 2nd part of this (IAB->IESG) but not as happy with the first (AD->AD) without advertizing the slot I suspect the change in personel in an area can change who is willing to run (I'd run but I do not want to pair with FOO) often enough to be an issue - and, in many areas each AD has their own expertise - a call for nominees for an area when everyone is assuming that the continuing AD will stay will take into account the expertise of the continuing AD - i.e. the right people may not have been nominated or agreed to run. so I think that the AD->AD case needs to havethe newly vacent seat advertized Scott From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 15:35:09 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00J04EC1EX@eListX.com> (original mail from mstjohns@mindspring.com) ; Wed, 08 Oct 2003 15:33:37 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00J01EC0EV@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 15:33:36 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00J01EC0ET@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 15:33:36 -0400 (EDT) Received: from razorbill.mail.pas.earthlink.net (razorbill.mail.pas.earthlink.net [207.217.121.248]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMG00CNQEBZ48@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 15:33:36 -0400 (EDT) Received: from pcp802150pcs.nrockv01.md.comcast.net ([68.48.85.252] helo=STJOHNS-LAPTOP2.mindspring.com) by razorbill.mail.pas.earthlink.net with asmtp (TLSv1:RC4-SHA:128) (Exim 3.33 #1) id 1A7K3Y-0004q3-00; Wed, 08 Oct 2003 12:33:08 -0700 Date: Wed, 08 Oct 2003 15:33:07 -0400 From: Michael StJohns Subject: Re: IESG issues with draft-ietf-nomcom-rfc2727bis-07 In-reply-to: <123801667.1065546784@[192.168.11.231]> X-Sender: mstjohns@mindspring.com@pop.mindspring.com To: Harald Tveit Alvestrand , ietf-nomcom@lists.elistx.com Message-id: <6.0.0.20.2.20031008152446.03042d58@pop.mindspring.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.20 (Beta) Content-type: text/plain; format=flowed; charset=us-ascii X-ELNK-Trace: 9f6ded143da542dc9c7f779228e2f6aeda0071232e20db4db708ed6bd86a8e09d0f3b9158c628007350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c References: <123801667.1065546784@[192.168.11.231]> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: I'm going to go out on a limb here and suggest the IESG approve this document as is with the understanding that the NomcomWG will continue to work on the issues identified. Here's why - the substantive issues are ALL present in the current (2727) process and approving this document creates no additional problems. Indeed - this document fixes a number of problems that MUST be fixed sooner rather than later. I'm going to go further out on a limb and suggest the IESG immediately refer the document to the RFC editor, and indicate to the Nomcom chair that this is the process to be followed for this cycle and that the ID will be considered authoritative for the process pending the publication of the RFC. I realize this is out of the ordinary, but this process has been going on for a year and I don't think we can wait another year to fix the 2727 brokeness. Mike At 11:13 10/7/2003, Harald Tveit Alvestrand wrote: >The IESG on October 2 evaluated the nomcom document. >It found a number of details that may need to be fixed, and three >substantive issue that it seems to the IESG that it is necessary to fix. > >The first 2 substantive issue was raised by Margaret Wasserman: > >------------------------------------------------------------- >>In section 2: >> The nominating committee will be given the title of the positions >> to be reviewed and a brief description of the desirable set of >> qualifications of the candidate that is nominated to fill each >> position. > >Is this information sent publicly or privately? There are two issues >here: > >1) I think that the "description of the desirable set of qualifications" > should be posted publicly, along with the list of open positions when > the call for nominations is sent. > >2) The IESG and IAB should know, unambiguously, whether or not the > information will be publicly disseminated before providing it. > >------------------------------------------------------------------ > From section 3, subsection 8: >> It is consistent with these rules for the announcements of a >> resignation, of the existence of a mid-term vacancy, and of the >> confirmed candidates to all occur at the same time as long as the >> actual sequence of events that occurred did so in the following >> order. >> >> * The nominating committee completes the advice and consent >> process for the candidate already sitting on another body. >> >> * The newly confirmed candidate resigns from their current >> position. >> >> * The body with the new mid-term vacancy requests that the >> nominating committee fill the position. >> >> * The Executive Director of the IETF informs the nominating >> committee of the mid-term vacancy. >> >> * The nominating committee acts on the request to fill the >> mid-term vacancy > >This section indicates that a position may be vacated and filled >without the community being notified that a position is open. IMO, no >position should be filled without public notice that the position is >open and a public call for nominations. > >I understand one shool of thought that says that this is okay for IAB >positions during the normal selection cycle. Because IAB members >don't have separate responsibilities, it _might_ be okay to pick 6 IAB >members from a candidate pool for 5 open positions, for example. >However, even in this case, the community might want to know if a >person with a particular specialty/area of expertise was moving, so >that folks with that type of expertise could be nominated. > >This section would also be problematic for IESG positions. This could >arise in any case where one IESG position is filled by a sitting IESG >member who is not up for renewal. For example, consider a situation >where the IESG chair does not volunteer for another term and is >replaced by a sitting IESG member who is not up for renewal. Even >though there are two ADs for most areas, the ADs often divide up the >area into logical sections, requiring different expertise for each >position. > >There are also issues with filling any postition according to this >section if it is applied to interim vacancies. For example, the >nomcom should not be empowered to move an IAB member to the IESG to >fill and interim vacancy and replace the IAB member without making a >public call for nominations for the open IAB position. >---------------------------------------------------------------- >The third substantive issue was raised by Thomas Narten: > >> Liaisons from the IESG, IAB, and Internet Society Board of >> Trustees are expected to review the operation and executing >> process of the nominating committee and to report any concerns >> or issues to the Chair of the nominating committee immediately. >> If they can not resolve the issue between themselves liaisons >> must report the issue to their respective bodies. If their >> respective body agrees that there is an issue the liaison must >> report it according to the dispute resolution process stated >> elsewhere in this document. > >I worry that there will be problems with the above in practice. In >particular, the text requires that a liaison report problems back to >their respective group (i.e., IESG or IAB) before invoking the formal >dispute resolution mechanism. But confidentiality rules rather limit >what the liaison can say to their body, and in the case where dispute >resolution may need invoking, it seems like details will be >important. I worry that this will create problems in practice, with it >being unclear what can be said. And if that is the case, it is unclear >what value the discussion within the respective I* would actually >have. This is perhaps more a problem for the IESG, since it has no >confirming role, but it seems like a general issue. > >There are ways of dealing with this, but I'm not sure what is best or >what the WG might think. Some initial thoughts: > >- I note that the current wording doesn't mention the obvious, i.e., > have the liaisons and previous chair get together and discuss > before escalating. One could also have the liaison (independently) > decide whether to formally appeal after such a consultation. This > avoids the confidentiality issue and would seem like a necessary > check as part of escalating issues. > >- add some wording saying that confidentiality rules allow sharing of > info as needed to assess whether to file a formal complaint. >-------------------------------------------------------------------- > >I think these needs to be discussed in the WG, and that they need to >either have new text crafted or a justification for the current choices given. > >The more-or-less minor issues can be found in the ID tracker: > >01&rfc_flag=0> > >and are also given below in raw format. >These are, in the opinion of the IESG, "non-show-stopper" issues - not >things that are critical enough to block/delay publication of the document >on their own, but important enough to be worth mentioning, in case they >can be quickly fixed while the document is "open". It is up to the WG what >to do with these. >-------------------------------------------------------------------------- >Steve Bellovin: >Comment: >The recall section makes no provision or even suggestion that the Recall >Chair verify the putative signers. > >Section 5, Point 12 suggests that the committee consult with the sitting >members of the IAB and IESG. I think that consultation with WG chairs >should be suggested. > >Ted Hardie: >Comment: >I note that the oral tradition section indicates that no person should >serve on both the IESG and IAB, except the IETF Chair who serves on both by >definition. I believe that there is some lack of clarity on whether the IAB >Chair's role ex officio in the IESG means she "serves on", and that this is >probably not the place to resolve that or go into the liaisons from one >body to the other. To capture the same thing, how about: > >"No person should serve both on the IAB and as an Area Director, except >the IETF Chair whose roles as an IAB member and Area Director of the >General Area is set out elsewhere". > >Thomas Narten: > >If a voting volunteer member is recalled the committee may >> choose to proceed with only 9 voting volunteers at its own >> discretion. In all other cases the Chair must repeat the random >> selection process including an announcement of the iteration > >> prior to the actual selection as stated elsewhere in this >> document. > >The above implies to me that the nomcome is required to find a >replacement for a resignation, but is not for a recall. Shouldn't the >nomcom be allowed to also not replace resignations? I.e, I assume that >the nomcom would have the option of filling or not filling any nomcom >opening, regardless of how it occurs. > >> It is consistent with this rule for the nominating committee to >> choose one or more of the currently open positions to which it >> may assign a term greater than 2 years in order to ensure the >> ideal application of this rule in the future. > >s/greater than 2 years/of up to 3 years/ > >(right now, in theory, nomcom could pick the length of time, though I >suspect a lot of folk would be surprised if this ever happend...) > >> committee. The addition must be approved by all members of the >> committee according to its established voting mechanism. >> Advisors participate as individuals. > >"all members" wording implies everyone must agree. What is the intent >here? Is it "must be approved by a quorum of the committee according >to its established voting mechanism"? Note: similar wording appears >elsewhere. > >> conducted. A member may recalled if at least a quorum of all >> committee members agree, including the vote of the member being >> recalled. > >What does this mean? simple majority if there is a quorum? (I ask >because in most cases this document doesn't proscribe rules, leaving >that to the nomcom to decide.) > >> 4. Confirmed candidates are expected to serve at least a 2 year >> term. > >not consistent with interim appointments > >> First, when there is only one official nominating committee the > >add comma after committee > >> As of the publication of this document the current mechanism is > ^ >> an email message to both the "ietf" and the "ietf-announce" >> mailing lists. > >comma above > > >> None of the Chair, liaisons, or advisors vote on the selection >> of candidates. They do vote on all other issues before the >> committee unless otherwise specified. > >s/specified/specified in this document/? (what is the intent?) > >> 6. A Chair, in consultation with the Internet Society President, >> may appoint a temporary substitute. > >Better to say "... for the Chair position". > >> If they can not resolve the issue between themselves liaisons > >comma after themselves. > >> The confirmation process must be completed at least one month >> prior to the First IETF. > >s/must/should/ other parts of the document imply should on this topic. > >> The term of a nominating committee begins when its members are >> officially announced. The term ends at the Third IETF (not >> three meetings) after the next nominating committee's term >> begins. > >ambigous wording. Reword: > > The term ends at the Third IETF (not three meetings), that is, > the IETF after the next nominating committee's term begins. > >Jon Peterson: >Comment: >The Introduction fastidiously notes that the organization of the IESG is >outside the scope of the document. However, in so far as Section 3 bullet >3 explains that half of the IESG positions are reviewed by the NomCom per >year, would it make sense to mention at a high level that IESG members >serve in specific Areas, and that the review process is staggered to >preserve continuity and institutional memory within Areas? This seems like >an important detail of the NomCom process to omit, even if it might change >as the IETF changes. I'd note that Section 3 bullet 3 already has a caveat >about future IESG reorganization, so I'm not sure how it would hurt to >talk about the current IESG structure, in the interests of fully depicting >the existing practice. > >Margaret Wasserman: > >Comment: >EDITORIAL: > >>Abstract >> >> The process by which the members of the IAB and IESG are selected, >> confirmed, and recalled is specified. This document is a >> self-consistent, organized compilation of the process as it was known >> at the time of publication. > >Very weak... I also don't think that the last sentence is true, >as this document changes some things. Suggestions: Add a bit >more information (i.e mention the Nominations Commitee?) and remove >"as it was known at the time of publication". > >The section numbering in this document doesn't match usual >conventions. This makes it harder to refer to sections in this >document unambiguously. > >> 3. One-half of each of the then current IESG and IAB positions is >> selected to be reviewed each year. > >s/One-half of each of/One-half of/ >s/positions is/positions are/ > >> The intent of this rule to ensure the review of approximately >> one-half of each of the IESG and IAB sitting members each year. > >s/one-half of each of/one-half of/ > >> 4. Confirmed candidates are expected to serve at least a 2 year >> term. > >This isn't always true. Replacement candidates may serve >terms of less than two years. > >> A term may begin or end no sooner than the >> first day of the meeting and no later than the last day of the >> meeting as determined by the mutual agreement of the currently >> sitting member and the confirmed candidate. The confirmed >> candidate's term may overlap the sitting member's term during the >> meeting as determined by their mutual agreement. > >How does this apply to IAB terms? In the case where there is >more than one new IAB member, I don't think that it is >defined which IAB member each new member is replacing. >>In section 4, subsection 7: >> Liaisons from the IESG, IAB, and Internet Society Board of >> Trustees are expected to review the operation and executing >> process of the nominating committee and to report any concerns > >There is a mention here of a liaison from the ISOC board. >But, there in section 4.3 there is a list of nomcom members >that indicates how they are selected, and the ISOC liaison >is not listed. > >The organization of this document seems to result in repeating >a lot of information. There are also a lot of forward >references. This makes it difficult to find the part(s) of >the document that apply to a particular part of the process. > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 16:15:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00L04FU6N2@eListX.com> (original mail from Margaret.Wasserman@nokia.com); Wed, 08 Oct 2003 16:06:06 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00L01FU6N0@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 16:06:06 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00L01FU6MZ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 16:06:06 -0400 (EDT) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMG00K39FU452@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 16:06:05 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h98K5e615386 for ; Wed, 08 Oct 2003 23:05:40 +0300 (EET DST) Received: from daebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 08 Oct 2003 23:05:40 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 08 Oct 2003 15:05:34 -0500 Date: Wed, 08 Oct 2003 16:05:33 -0400 From: Margaret.Wasserman@nokia.com Subject: RE: IESG issues with draft-ietf-nomcom-rfc2727bis-07 To: mstjohns@mindspring.com, harald@alvestrand.no, ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE Thread-Topic: IESG issues with draft-ietf-nomcom-rfc2727bis-07 Thread-Index: AcON0woy7omEUnOLRK2t0tzcazWlbgAA3lvw content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: X-OriginalArrivalTime: 08 Oct 2003 20:05:34.0338 (UTC) FILETIME=[88754E20:01C38DD7] Hi Mike, Are you suggesting that we skip the ISOC BoT approval that usually applies to process documents? =20 Or, are you only suggesting that we should bypass the IESG=20 review/approval process?=20 I've been told that the ISOC BoT approval was included for some sort of legal/liability/insurance-related reasons, so it probably wouldn't be wise to bypass it. Margaret > -----Original Message----- > From: ext Michael StJohns [mailto:mstjohns@mindspring.com] > Sent: Wednesday, October 08, 2003 3:33 PM > To: Harald Tveit Alvestrand; ietf-nomcom@lists.elistx.com > Subject: Re: IESG issues with draft-ietf-nomcom-rfc2727bis-07 >=20 >=20 > I'm going to go out on a limb here and suggest the IESG approve thi= s=20 > document as is with the understanding that the NomcomWG will=20 > continue to=20 > work on the issues identified. >=20 > Here's why - the substantive issues are ALL present in the=20 > current (2727)=20 > process and approving this document creates no additional=20 > problems. Indeed=20 > - this document fixes a number of problems that MUST be fixed=20 > sooner rather=20 > than later. >=20 > I'm going to go further out on a limb and suggest the IESG=20 > immediately=20 > refer the document to the RFC editor, and indicate to the=20 > Nomcom chair that=20 > this is the process to be followed for this cycle and that=20 > the ID will be=20 > considered authoritative for the process pending the=20 > publication of the RFC. >=20 > I realize this is out of the ordinary, but this process has=20 > been going on=20 > for a year and I don't think we can wait another year to fix the 27= 27=20 > brokeness. >=20 > Mike >=20 >=20 >=20 >=20 >=20 >=20 > At 11:13 10/7/2003, Harald Tveit Alvestrand wrote: > >The IESG on October 2 evaluated the nomcom document. > >It found a number of details that may need to be fixed, and three= =20 > >substantive issue that it seems to the IESG that it is=20 > necessary to fix. > > > >The first 2 substantive issue was raised by Margaret Wasserman: > > > >------------------------------------------------------------- > >>In section 2: > >> The nominating committee will be given the title of=20 > the positions > >> to be reviewed and a brief description of the desirable set= of > >> qualifications of the candidate that is nominated to fill e= ach > >> position. > > > >Is this information sent publicly or privately? There are two iss= ues > >here: > > > >1) I think that the "description of the desirable set of=20 > qualifications" > > should be posted publicly, along with the list of open=20 > positions when > > the call for nominations is sent. > > > >2) The IESG and IAB should know, unambiguously, whether or not the > > information will be publicly disseminated before providing it. > > > >------------------------------------------------------------------ > > From section 3, subsection 8: > >> It is consistent with these rules for the announcements of = a > >> resignation, of the existence of a mid-term vacancy,=20 > and of the > >> confirmed candidates to all occur at the same time as=20 > long as the > >> actual sequence of events that occurred did so in the=20 > following > >> order. > >> > >> * The nominating committee completes the advice and consen= t > >> process for the candidate already sitting on another body= . > >> > >> * The newly confirmed candidate resigns from their current > >> position. > >> > >> * The body with the new mid-term vacancy requests that the > >> nominating committee fill the position. > >> > >> * The Executive Director of the IETF informs the nominatin= g > >> committee of the mid-term vacancy. > >> > >> * The nominating committee acts on the request to fill the > >> mid-term vacancy > > > >This section indicates that a position may be vacated and filled > >without the community being notified that a position is=20 > open. IMO, no > >position should be filled without public notice that the position = is > >open and a public call for nominations. > > > >I understand one shool of thought that says that this is okay for = IAB > >positions during the normal selection cycle. Because IAB members > >don't have separate responsibilities, it _might_ be okay to=20 > pick 6 IAB > >members from a candidate pool for 5 open positions, for example. > >However, even in this case, the community might want to know if a > >person with a particular specialty/area of expertise was moving, s= o > >that folks with that type of expertise could be nominated. > > > >This section would also be problematic for IESG positions. =20 > This could > >arise in any case where one IESG position is filled by a sitting I= ESG > >member who is not up for renewal. For example, consider a situati= on > >where the IESG chair does not volunteer for another term and is > >replaced by a sitting IESG member who is not up for renewal. Even > >though there are two ADs for most areas, the ADs often divide up t= he > >area into logical sections, requiring different expertise for each > >position. > > > >There are also issues with filling any postition according to this > >section if it is applied to interim vacancies. For example, the > >nomcom should not be empowered to move an IAB member to the IESG t= o > >fill and interim vacancy and replace the IAB member without making= a > >public call for nominations for the open IAB position. > >---------------------------------------------------------------- > >The third substantive issue was raised by Thomas Narten: > > > >> Liaisons from the IESG, IAB, and Internet Society Board o= f > >> Trustees are expected to review the operation and executi= ng > >> process of the nominating committee and to report=20 > any concerns > >> or issues to the Chair of the nominating committee=20 > immediately. > >> If they can not resolve the issue between=20 > themselves liaisons > >> must report the issue to their respective bodies. If the= ir > >> respective body agrees that there is an issue the=20 > liaison must > >> report it according to the dispute resolution process sta= ted > >> elsewhere in this document. > > > >I worry that there will be problems with the above in practice. In > >particular, the text requires that a liaison report problems back = to > >their respective group (i.e., IESG or IAB) before invoking the for= mal > >dispute resolution mechanism. But confidentiality rules rather lim= it > >what the liaison can say to their body, and in the case where disp= ute > >resolution may need invoking, it seems like details will be > >important. I worry that this will create problems in=20 > practice, with it > >being unclear what can be said. And if that is the case, it=20 > is unclear > >what value the discussion within the respective I* would actually > >have. This is perhaps more a problem for the IESG, since it has no > >confirming role, but it seems like a general issue. > > > >There are ways of dealing with this, but I'm not sure what is best= or > >what the WG might think. Some initial thoughts: > > > >- I note that the current wording doesn't mention the obvious, i.e= ., > > have the liaisons and previous chair get together and discuss > > before escalating. One could also have the liaison (independentl= y) > > decide whether to formally appeal after such a consultation. Thi= s > > avoids the confidentiality issue and would seem like a necessary > > check as part of escalating issues. > > > >- add some wording saying that confidentiality rules allow sharing= of > > info as needed to assess whether to file a formal complaint. > >------------------------------------------------------------------= -- > > > >I think these needs to be discussed in the WG, and that they need = to=20 > >either have new text crafted or a justification for the=20 > current choices given. > > > >The more-or-less minor issues can be found in the ID tracker: > > > > iew_id&dTag=3D90 > >01&rfc_flag=3D0> > > > >and are also given below in raw format. > >These are, in the opinion of the IESG, "non-show-stopper"=20 > issues - not=20 > >things that are critical enough to block/delay publication=20 > of the document=20 > >on their own, but important enough to be worth mentioning,=20 > in case they=20 > >can be quickly fixed while the document is "open". It is up=20 > to the WG what=20 > >to do with these. > >------------------------------------------------------------- > ------------- > >Steve Bellovin: > >Comment: > >The recall section makes no provision or even suggestion=20 > that the Recall=20 > >Chair verify the putative signers. > > > >Section 5, Point 12 suggests that the committee consult with=20 > the sitting=20 > >members of the IAB and IESG. I think that consultation with=20 > WG chairs=20 > >should be suggested. > > > >Ted Hardie: > >Comment: > >I note that the oral tradition section indicates that no=20 > person should=20 > >serve on both the IESG and IAB, except the IETF Chair who=20 > serves on both by > >definition. I believe that there is some lack of clarity on=20 > whether the IAB > >Chair's role ex officio in the IESG means she "serves on",=20 > and that this is > >probably not the place to resolve that or go into the=20 > liaisons from one > >body to the other. To capture the same thing, how about: > > > >"No person should serve both on the IAB and as an Area=20 > Director, except > >the IETF Chair whose roles as an IAB member and Area=20 > Director of the=20 > >General Area is set out elsewhere". > > > >Thomas Narten: > > > >If a voting volunteer member is recalled the committee may > >> choose to proceed with only 9 voting volunteers at its ow= n > >> discretion. In all other cases the Chair must=20 > repeat the random > >> selection process including an announcement of the iterat= ion > > > >> prior to the actual selection as stated elsewhere in this > >> document. > > > >The above implies to me that the nomcome is required to find a > >replacement for a resignation, but is not for a recall. Shouldn't = the > >nomcom be allowed to also not replace resignations? I.e, I=20 > assume that > >the nomcom would have the option of filling or not filling=20 > any nomcom > >opening, regardless of how it occurs. > > > >> It is consistent with this rule for the nominating=20 > committee to > >> choose one or more of the currently open positions=20 > to which it > >> may assign a term greater than 2 years in order to=20 > ensure the > >> ideal application of this rule in the future. > > > >s/greater than 2 years/of up to 3 years/ > > > >(right now, in theory, nomcom could pick the length of time, thoug= h I > >suspect a lot of folk would be surprised if this ever happend...) > > > >> committee. The addition must be approved by all=20 > members of the > >> committee according to its established voting mechanism. > >> Advisors participate as individuals. > > > >"all members" wording implies everyone must agree. What is the int= ent > >here? Is it "must be approved by a quorum of the committee accordi= ng > >to its established voting mechanism"? Note: similar wording appear= s > >elsewhere. > > > >> conducted. A member may recalled if at least a=20 > quorum of all > >> committee members agree, including the vote of the=20 > member being > >> recalled. > > > >What does this mean? simple majority if there is a quorum? (I ask > >because in most cases this document doesn't proscribe rules, leavi= ng > >that to the nomcom to decide.) > > > >> 4. Confirmed candidates are expected to serve at least a 2 y= ear > >> term. > > > >not consistent with interim appointments > > > >> First, when there is only one official nominating=20 > committee the > > > >add comma after committee > > > >> As of the publication of this document the current=20 > mechanism is > > ^ > >> an email message to both the "ietf" and the "ietf-announc= e" > >> mailing lists. > > > >comma above > > > > > >> None of the Chair, liaisons, or advisors vote on=20 > the selection > >> of candidates. They do vote on all other issues before t= he > >> committee unless otherwise specified. > > > >s/specified/specified in this document/? (what is the intent?) > > > >> 6. A Chair, in consultation with the Internet Society=20 > President, > >> may appoint a temporary substitute. > > > >Better to say "... for the Chair position". > > > >> If they can not resolve the issue between=20 > themselves liaisons > > > >comma after themselves. > > > >> The confirmation process must be completed at least=20 > one month > >> prior to the First IETF. > > > >s/must/should/ other parts of the document imply should on=20 > this topic. > > > >> The term of a nominating committee begins when its=20 > members are > >> officially announced. The term ends at the Third IETF (n= ot > >> three meetings) after the next nominating committee's ter= m > >> begins. > > > >ambigous wording. Reword: > > > > The term ends at the Third IETF (not three=20 > meetings), that is, > > the IETF after the next nominating committee's term begins= . > > > >Jon Peterson: > >Comment: > >The Introduction fastidiously notes that the organization of=20 > the IESG is=20 > >outside the scope of the document. However, in so far as=20 > Section 3 bullet=20 > >3 explains that half of the IESG positions are reviewed by=20 > the NomCom per=20 > >year, would it make sense to mention at a high level that=20 > IESG members=20 > >serve in specific Areas, and that the review process is staggered = to=20 > >preserve continuity and institutional memory within Areas?=20 > This seems like=20 > >an important detail of the NomCom process to omit, even if=20 > it might change=20 > >as the IETF changes. I'd note that Section 3 bullet 3=20 > already has a caveat=20 > >about future IESG reorganization, so I'm not sure how it=20 > would hurt to=20 > >talk about the current IESG structure, in the interests of=20 > fully depicting=20 > >the existing practice. > > > >Margaret Wasserman: > > > >Comment: > >EDITORIAL: > > > >>Abstract > >> > >> The process by which the members of the IAB and IESG are select= ed, > >> confirmed, and recalled is specified. This document is a > >> self-consistent, organized compilation of the process as=20 > it was known > >> at the time of publication. > > > >Very weak... I also don't think that the last sentence is true, > >as this document changes some things. Suggestions: Add a bit > >more information (i.e mention the Nominations Commitee?) and remov= e > >"as it was known at the time of publication". > > > >The section numbering in this document doesn't match usual > >conventions. This makes it harder to refer to sections in this > >document unambiguously. > > > >> 3. One-half of each of the then current IESG and IAB positions= is > >> selected to be reviewed each year. > > > >s/One-half of each of/One-half of/ > >s/positions is/positions are/ > > > >> The intent of this rule to ensure the review of approximate= ly > >> one-half of each of the IESG and IAB sitting members=20 > each year. > > > >s/one-half of each of/one-half of/ > > > >> 4. Confirmed candidates are expected to serve at least a 2 yea= r > >> term. > > > >This isn't always true. Replacement candidates may serve > >terms of less than two years. > > > >> A term may begin or end no sooner than the > >> first day of the meeting and no later than the last day of = the > >> meeting as determined by the mutual agreement of the curren= tly > >> sitting member and the confirmed candidate. The confirmed > >> candidate's term may overlap the sitting member's=20 > term during the > >> meeting as determined by their mutual agreement. > > > >How does this apply to IAB terms? In the case where there is > >more than one new IAB member, I don't think that it is > >defined which IAB member each new member is replacing. > >>In section 4, subsection 7: > >> Liaisons from the IESG, IAB, and Internet Society Board o= f > >> Trustees are expected to review the operation and executi= ng > >> process of the nominating committee and to report=20 > any concerns > > > >There is a mention here of a liaison from the ISOC board. > >But, there in section 4.3 there is a list of nomcom members > >that indicates how they are selected, and the ISOC liaison > >is not listed. > > > >The organization of this document seems to result in repeating > >a lot of information. There are also a lot of forward > >references. This makes it difficult to find the part(s) of > >the document that apply to a particular part of the process. > > > >---------------------------------------------------------------- > >To subscribe or unsubscribe from this elist use the subscription > >manager: >=20 >=20 >=20 > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: >=20 From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 16:25:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00M04G9CAU@eListX.com> (original mail from delaat@science.uva.nl) ; Wed, 08 Oct 2003 16:15:12 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00M01G9CAS@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 16:15:12 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00M01G9BAR@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 16:15:11 -0400 (EDT) Received: from mail.science.uva.nl (mail.science.uva.nl [146.50.4.51]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMG00K6LG9A51@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 16:15:11 -0400 (EDT) Received: from mac-delaat.science.uva.nl [146.50.22.54] by mail.science.uva.nl with ESMTP (sendmail 8.11.6p2/config 11.34) . id h98KEWE11550; Wed, 08 Oct 2003 22:14:32 +0200 (MEST) X-URL: http://www.science.uva.nl/ Date: Wed, 08 Oct 2003 14:43:41 -0500 From: Cees de Laat Subject: Re: IESG Issue 2 In-reply-to: <200310081917.h98JHdRO012575@newdev.harvard.edu> X-Sender: delaat@127.0.0.1 To: Scott Bradner , brc@zurich.ibm.com, joel@stevecrocker.com Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii References: <200310081917.h98JHdRO012575@newdev.harvard.edu> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: X-Organisation: Faculty of Science, University of Amsterdam, The Netherlands At 15:17 -0400 8/10/03, Scott Bradner wrote: > > It is consistent with these rules for the Nominating Committee >> to nominate a sitting Area Director to a different Area and simultaneously >> nominate a new Area Director to the position thus vacated, or to >> nominate a sitting IAB member to an Area Director position and > > simultaneously nominate a new IAB member to the position thus vacated. Be careful with allowing simultaneous nomination when having moving AD's. We in the GGF (Global Grid Forum) did a nomcom process which now completed successfully but we ran almost in the following problem: If you candidate a sitting AD for for an IAB position and at the same time candidate someone for that vacated spot you run in the problem that if the original candidate is not confirmed for the IAB, he remains in the old position and you basically disclosed the name of a "runner up" to the confirming body of that first position. It may be that the other AD position was also open and gives that confiming body knowledge in terms of "oke, if we reject this one, their next choise is that one". So the only clean way is to keep it a two step process. In our GGF case this situation of "rejected" did not happen, but could have been. Best regards, Cees. -- http://www.science.uva.nl/~delaat/ From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 17:46:14 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00504K5WE4@eListX.com> (original mail from brc@zurich.ibm.com); Wed, 08 Oct 2003 17:39:32 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00501K5WE2@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 17:39:32 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00501K5VE1@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 17:39:31 -0400 (EDT) Received: from d12lmsgate.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMG0042GK5UP0@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 17:39:31 -0400 (EDT) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h98Ld6Nb109154; Wed, 08 Oct 2003 23:39:06 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h98Ld6uX273458; Wed, 08 Oct 2003 23:39:06 +0200 Received: from zurich.ibm.com ([9.145.140.210]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id XAA44422; Wed, 08 Oct 2003 23:36:36 +0200 Date: Wed, 08 Oct 2003 23:36:04 +0200 From: Brian E Carpenter Subject: Re: IESG issues with draft-ietf-nomcom-rfc2727bis-07 To: Margaret.Wasserman@nokia.com Cc: mstjohns@mindspring.com, harald@alvestrand.no, ietf-nomcom@lists.elistx.com Message-id: <3F848344.1E0BE1C0@zurich.ibm.com> Organization: IBM MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en,fr,de References: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Margaret, Yes, we need the ISOC to agree to the final document, to ensure that the liability insurance taken out by ISOC is solid. So this step can't be avoided, but it has always been a formality in the past, once the IESG has approved the document. As far as I can see, Mike is suggesting that the IESG approves the document for BCP and simultaneously recharters the WG to fix the issues raised. This does seem reasonable and pragmatic. Brian Margaret.Wasserman@nokia.com wrote: > > Hi Mike, > > Are you suggesting that we skip the ISOC BoT approval > that usually applies to process documents? > > Or, are you only suggesting that we should bypass the IESG > review/approval process? > > I've been told that the ISOC BoT approval was included for > some sort of legal/liability/insurance-related reasons, so it > probably wouldn't be wise to bypass it. > > Margaret > > > -----Original Message----- > > From: ext Michael StJohns [mailto:mstjohns@mindspring.com] > > Sent: Wednesday, October 08, 2003 3:33 PM > > To: Harald Tveit Alvestrand; ietf-nomcom@lists.elistx.com > > Subject: Re: IESG issues with draft-ietf-nomcom-rfc2727bis-07 > > > > > > I'm going to go out on a limb here and suggest the IESG approve this > > document as is with the understanding that the NomcomWG will > > continue to > > work on the issues identified. > > > > Here's why - the substantive issues are ALL present in the > > current (2727) > > process and approving this document creates no additional > > problems. Indeed > > - this document fixes a number of problems that MUST be fixed > > sooner rather > > than later. > > > > I'm going to go further out on a limb and suggest the IESG > > immediately > > refer the document to the RFC editor, and indicate to the > > Nomcom chair that > > this is the process to be followed for this cycle and that > > the ID will be > > considered authoritative for the process pending the > > publication of the RFC. > > > > I realize this is out of the ordinary, but this process has > > been going on > > for a year and I don't think we can wait another year to fix the 2727 > > brokeness. > > > > Mike > > > > > > > > > > > > > > At 11:13 10/7/2003, Harald Tveit Alvestrand wrote: > > >The IESG on October 2 evaluated the nomcom document. > > >It found a number of details that may need to be fixed, and three > > >substantive issue that it seems to the IESG that it is > > necessary to fix. > > > > > >The first 2 substantive issue was raised by Margaret Wasserman: > > > > > >------------------------------------------------------------- > > >>In section 2: > > >> The nominating committee will be given the title of > > the positions > > >> to be reviewed and a brief description of the desirable set of > > >> qualifications of the candidate that is nominated to fill each > > >> position. > > > > > >Is this information sent publicly or privately? There are two issues > > >here: > > > > > >1) I think that the "description of the desirable set of > > qualifications" > > > should be posted publicly, along with the list of open > > positions when > > > the call for nominations is sent. > > > > > >2) The IESG and IAB should know, unambiguously, whether or not the > > > information will be publicly disseminated before providing it. > > > > > >------------------------------------------------------------------ > > > From section 3, subsection 8: > > >> It is consistent with these rules for the announcements of a > > >> resignation, of the existence of a mid-term vacancy, > > and of the > > >> confirmed candidates to all occur at the same time as > > long as the > > >> actual sequence of events that occurred did so in the > > following > > >> order. > > >> > > >> * The nominating committee completes the advice and consent > > >> process for the candidate already sitting on another body. > > >> > > >> * The newly confirmed candidate resigns from their current > > >> position. > > >> > > >> * The body with the new mid-term vacancy requests that the > > >> nominating committee fill the position. > > >> > > >> * The Executive Director of the IETF informs the nominating > > >> committee of the mid-term vacancy. > > >> > > >> * The nominating committee acts on the request to fill the > > >> mid-term vacancy > > > > > >This section indicates that a position may be vacated and filled > > >without the community being notified that a position is > > open. IMO, no > > >position should be filled without public notice that the position is > > >open and a public call for nominations. > > > > > >I understand one shool of thought that says that this is okay for IAB > > >positions during the normal selection cycle. Because IAB members > > >don't have separate responsibilities, it _might_ be okay to > > pick 6 IAB > > >members from a candidate pool for 5 open positions, for example. > > >However, even in this case, the community might want to know if a > > >person with a particular specialty/area of expertise was moving, so > > >that folks with that type of expertise could be nominated. > > > > > >This section would also be problematic for IESG positions. > > This could > > >arise in any case where one IESG position is filled by a sitting IESG > > >member who is not up for renewal. For example, consider a situation > > >where the IESG chair does not volunteer for another term and is > > >replaced by a sitting IESG member who is not up for renewal. Even > > >though there are two ADs for most areas, the ADs often divide up the > > >area into logical sections, requiring different expertise for each > > >position. > > > > > >There are also issues with filling any postition according to this > > >section if it is applied to interim vacancies. For example, the > > >nomcom should not be empowered to move an IAB member to the IESG to > > >fill and interim vacancy and replace the IAB member without making a > > >public call for nominations for the open IAB position. > > >---------------------------------------------------------------- > > >The third substantive issue was raised by Thomas Narten: > > > > > >> Liaisons from the IESG, IAB, and Internet Society Board of > > >> Trustees are expected to review the operation and executing > > >> process of the nominating committee and to report > > any concerns > > >> or issues to the Chair of the nominating committee > > immediately. > > >> If they can not resolve the issue between > > themselves liaisons > > >> must report the issue to their respective bodies. If their > > >> respective body agrees that there is an issue the > > liaison must > > >> report it according to the dispute resolution process stated > > >> elsewhere in this document. > > > > > >I worry that there will be problems with the above in practice. In > > >particular, the text requires that a liaison report problems back to > > >their respective group (i.e., IESG or IAB) before invoking the formal > > >dispute resolution mechanism. But confidentiality rules rather limit > > >what the liaison can say to their body, and in the case where dispute > > >resolution may need invoking, it seems like details will be > > >important. I worry that this will create problems in > > practice, with it > > >being unclear what can be said. And if that is the case, it > > is unclear > > >what value the discussion within the respective I* would actually > > >have. This is perhaps more a problem for the IESG, since it has no > > >confirming role, but it seems like a general issue. > > > > > >There are ways of dealing with this, but I'm not sure what is best or > > >what the WG might think. Some initial thoughts: > > > > > >- I note that the current wording doesn't mention the obvious, i.e., > > > have the liaisons and previous chair get together and discuss > > > before escalating. One could also have the liaison (independently) > > > decide whether to formally appeal after such a consultation. This > > > avoids the confidentiality issue and would seem like a necessary > > > check as part of escalating issues. > > > > > >- add some wording saying that confidentiality rules allow sharing of > > > info as needed to assess whether to file a formal complaint. > > >-------------------------------------------------------------------- > > > > > >I think these needs to be discussed in the WG, and that they need to > > >either have new text crafted or a justification for the > > current choices given. > > > > > >The more-or-less minor issues can be found in the ID tracker: > > > > > > > iew_id&dTag=90 > > >01&rfc_flag=0> > > > > > >and are also given below in raw format. > > >These are, in the opinion of the IESG, "non-show-stopper" > > issues - not > > >things that are critical enough to block/delay publication > > of the document > > >on their own, but important enough to be worth mentioning, > > in case they > > >can be quickly fixed while the document is "open". It is up > > to the WG what > > >to do with these. > > >------------------------------------------------------------- > > ------------- > > >Steve Bellovin: > > >Comment: > > >The recall section makes no provision or even suggestion > > that the Recall > > >Chair verify the putative signers. > > > > > >Section 5, Point 12 suggests that the committee consult with > > the sitting > > >members of the IAB and IESG. I think that consultation with > > WG chairs > > >should be suggested. > > > > > >Ted Hardie: > > >Comment: > > >I note that the oral tradition section indicates that no > > person should > > >serve on both the IESG and IAB, except the IETF Chair who > > serves on both by > > >definition. I believe that there is some lack of clarity on > > whether the IAB > > >Chair's role ex officio in the IESG means she "serves on", > > and that this is > > >probably not the place to resolve that or go into the > > liaisons from one > > >body to the other. To capture the same thing, how about: > > > > > >"No person should serve both on the IAB and as an Area > > Director, except > > >the IETF Chair whose roles as an IAB member and Area > > Director of the > > >General Area is set out elsewhere". > > > > > >Thomas Narten: > > > > > >If a voting volunteer member is recalled the committee may > > >> choose to proceed with only 9 voting volunteers at its own > > >> discretion. In all other cases the Chair must > > repeat the random > > >> selection process including an announcement of the iteration > > > > > >> prior to the actual selection as stated elsewhere in this > > >> document. > > > > > >The above implies to me that the nomcome is required to find a > > >replacement for a resignation, but is not for a recall. Shouldn't the > > >nomcom be allowed to also not replace resignations? I.e, I > > assume that > > >the nomcom would have the option of filling or not filling > > any nomcom > > >opening, regardless of how it occurs. > > > > > >> It is consistent with this rule for the nominating > > committee to > > >> choose one or more of the currently open positions > > to which it > > >> may assign a term greater than 2 years in order to > > ensure the > > >> ideal application of this rule in the future. > > > > > >s/greater than 2 years/of up to 3 years/ > > > > > >(right now, in theory, nomcom could pick the length of time, though I > > >suspect a lot of folk would be surprised if this ever happend...) > > > > > >> committee. The addition must be approved by all > > members of the > > >> committee according to its established voting mechanism. > > >> Advisors participate as individuals. > > > > > >"all members" wording implies everyone must agree. What is the intent > > >here? Is it "must be approved by a quorum of the committee according > > >to its established voting mechanism"? Note: similar wording appears > > >elsewhere. > > > > > >> conducted. A member may recalled if at least a > > quorum of all > > >> committee members agree, including the vote of the > > member being > > >> recalled. > > > > > >What does this mean? simple majority if there is a quorum? (I ask > > >because in most cases this document doesn't proscribe rules, leaving > > >that to the nomcom to decide.) > > > > > >> 4. Confirmed candidates are expected to serve at least a 2 year > > >> term. > > > > > >not consistent with interim appointments > > > > > >> First, when there is only one official nominating > > committee the > > > > > >add comma after committee > > > > > >> As of the publication of this document the current > > mechanism is > > > ^ > > >> an email message to both the "ietf" and the "ietf-announce" > > >> mailing lists. > > > > > >comma above > > > > > > > > >> None of the Chair, liaisons, or advisors vote on > > the selection > > >> of candidates. They do vote on all other issues before the > > >> committee unless otherwise specified. > > > > > >s/specified/specified in this document/? (what is the intent?) > > > > > >> 6. A Chair, in consultation with the Internet Society > > President, > > >> may appoint a temporary substitute. > > > > > >Better to say "... for the Chair position". > > > > > >> If they can not resolve the issue between > > themselves liaisons > > > > > >comma after themselves. > > > > > >> The confirmation process must be completed at least > > one month > > >> prior to the First IETF. > > > > > >s/must/should/ other parts of the document imply should on > > this topic. > > > > > >> The term of a nominating committee begins when its > > members are > > >> officially announced. The term ends at the Third IETF (not > > >> three meetings) after the next nominating committee's term > > >> begins. > > > > > >ambigous wording. Reword: > > > > > > The term ends at the Third IETF (not three > > meetings), that is, > > > the IETF after the next nominating committee's term begins. > > > > > >Jon Peterson: > > >Comment: > > >The Introduction fastidiously notes that the organization of > > the IESG is > > >outside the scope of the document. However, in so far as > > Section 3 bullet > > >3 explains that half of the IESG positions are reviewed by > > the NomCom per > > >year, would it make sense to mention at a high level that > > IESG members > > >serve in specific Areas, and that the review process is staggered to > > >preserve continuity and institutional memory within Areas? > > This seems like > > >an important detail of the NomCom process to omit, even if > > it might change > > >as the IETF changes. I'd note that Section 3 bullet 3 > > already has a caveat > > >about future IESG reorganization, so I'm not sure how it > > would hurt to > > >talk about the current IESG structure, in the interests of > > fully depicting > > >the existing practice. > > > > > >Margaret Wasserman: > > > > > >Comment: > > >EDITORIAL: > > > > > >>Abstract > > >> > > >> The process by which the members of the IAB and IESG are selected, > > >> confirmed, and recalled is specified. This document is a > > >> self-consistent, organized compilation of the process as > > it was known > > >> at the time of publication. > > > > > >Very weak... I also don't think that the last sentence is true, > > >as this document changes some things. Suggestions: Add a bit > > >more information (i.e mention the Nominations Commitee?) and remove > > >"as it was known at the time of publication". > > > > > >The section numbering in this document doesn't match usual > > >conventions. This makes it harder to refer to sections in this > > >document unambiguously. > > > > > >> 3. One-half of each of the then current IESG and IAB positions is > > >> selected to be reviewed each year. > > > > > >s/One-half of each of/One-half of/ > > >s/positions is/positions are/ > > > > > >> The intent of this rule to ensure the review of approximately > > >> one-half of each of the IESG and IAB sitting members > > each year. > > > > > >s/one-half of each of/one-half of/ > > > > > >> 4. Confirmed candidates are expected to serve at least a 2 year > > >> term. > > > > > >This isn't always true. Replacement candidates may serve > > >terms of less than two years. > > > > > >> A term may begin or end no sooner than the > > >> first day of the meeting and no later than the last day of the > > >> meeting as determined by the mutual agreement of the currently > > >> sitting member and the confirmed candidate. The confirmed > > >> candidate's term may overlap the sitting member's > > term during the > > >> meeting as determined by their mutual agreement. > > > > > >How does this apply to IAB terms? In the case where there is > > >more than one new IAB member, I don't think that it is > > >defined which IAB member each new member is replacing. > > >>In section 4, subsection 7: > > >> Liaisons from the IESG, IAB, and Internet Society Board of > > >> Trustees are expected to review the operation and executing > > >> process of the nominating committee and to report > > any concerns > > > > > >There is a mention here of a liaison from the ISOC board. > > >But, there in section 4.3 there is a list of nomcom members > > >that indicates how they are selected, and the ISOC liaison > > >is not listed. > > > > > >The organization of this document seems to result in repeating > > >a lot of information. There are also a lot of forward > > >references. This makes it difficult to find the part(s) of > > >the document that apply to a particular part of the process. > > > > > >---------------------------------------------------------------- > > >To subscribe or unsubscribe from this elist use the subscription > > >manager: > > > > > > > > ---------------------------------------------------------------- > > To subscribe or unsubscribe from this elist use the subscription > > manager: > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 19:25:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00C04OP8YG@eListX.com> (original mail from mstjohns@mindspring.com) ; Wed, 08 Oct 2003 19:17:32 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00C01OP8YE@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 19:17:32 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00C01OP7YB@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 19:17:31 -0400 (EDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMG00C0UOP7LL@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 19:17:31 -0400 (EDT) Received: from pcp802150pcs.nrockv01.md.comcast.net ([68.48.85.252] helo=STJOHNS-LAPTOP2.mindspring.com) by heron.mail.pas.earthlink.net with asmtp (TLSv1:RC4-SHA:128) (Exim 3.33 #1) id 1A7NYC-00010w-00; Wed, 08 Oct 2003 16:17:00 -0700 Date: Wed, 08 Oct 2003 19:16:57 -0400 From: Michael StJohns Subject: Re: IESG issues with draft-ietf-nomcom-rfc2727bis-07 In-reply-to: <3F848344.1E0BE1C0@zurich.ibm.com> X-Sender: mstjohns@mindspring.com@pop.mindspring.com To: Brian E Carpenter , Margaret.Wasserman@nokia.com Cc: harald@alvestrand.no, ietf-nomcom@lists.elistx.com Message-id: <6.0.0.20.2.20031008190801.03221288@pop.mindspring.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.20 (Beta) Content-type: text/plain; format=flowed; charset=us-ascii X-ELNK-Trace: 9f6ded143da542dc9c7f779228e2f6aeda0071232e20db4d5a23ab9dba851903bcfbbb4385223dd1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c References: <3F848344.1E0BE1C0@zurich.ibm.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Brian - thanks for translating my wild ramblings. Margaret - I'm not suggesting that we bypass the IESG review process - its already happened and as you might guess I consider none of the objections showstoppers to publishing this document. WRT ISOC - I admit I hadn't considered it, but Brian makes a good point that the ISOC process has been relatively benign in the past. The current process has some broken pieces. The new document fixes some of those pieces without breaking others. Speaking as a member of a confirming body I want to follow a process that is more correct than was evident last year. Mike At 17:36 10/8/2003, Brian E Carpenter wrote: >Margaret, > >Yes, we need the ISOC to agree to the final document, to ensure >that the liability insurance taken out by ISOC is solid. > >So this step can't be avoided, but it has always been a >formality in the past, once the IESG has approved the >document. As far as I can see, Mike is suggesting that the >IESG approves the document for BCP and simultaneously >recharters the WG to fix the issues raised. This does seem >reasonable and pragmatic. > > Brian > >Margaret.Wasserman@nokia.com wrote: > > > > Hi Mike, > > > > Are you suggesting that we skip the ISOC BoT approval > > that usually applies to process documents? > > > > Or, are you only suggesting that we should bypass the IESG > > review/approval process? > > > > I've been told that the ISOC BoT approval was included for > > some sort of legal/liability/insurance-related reasons, so it > > probably wouldn't be wise to bypass it. > > > > Margaret > > > > > -----Original Message----- > > > From: ext Michael StJohns [mailto:mstjohns@mindspring.com] > > > Sent: Wednesday, October 08, 2003 3:33 PM > > > To: Harald Tveit Alvestrand; ietf-nomcom@lists.elistx.com > > > Subject: Re: IESG issues with draft-ietf-nomcom-rfc2727bis-07 > > > > > > > > > I'm going to go out on a limb here and suggest the IESG approve this > > > document as is with the understanding that the NomcomWG will > > > continue to > > > work on the issues identified. > > > > > > Here's why - the substantive issues are ALL present in the > > > current (2727) > > > process and approving this document creates no additional > > > problems. Indeed > > > - this document fixes a number of problems that MUST be fixed > > > sooner rather > > > than later. > > > > > > I'm going to go further out on a limb and suggest the IESG > > > immediately > > > refer the document to the RFC editor, and indicate to the > > > Nomcom chair that > > > this is the process to be followed for this cycle and that > > > the ID will be > > > considered authoritative for the process pending the > > > publication of the RFC. > > > > > > I realize this is out of the ordinary, but this process has > > > been going on > > > for a year and I don't think we can wait another year to fix the 2727 > > > brokeness. > > > > > > Mike > > > > > > > > > > > > > > > > > > > > > At 11:13 10/7/2003, Harald Tveit Alvestrand wrote: > > > >The IESG on October 2 evaluated the nomcom document. > > > >It found a number of details that may need to be fixed, and three > > > >substantive issue that it seems to the IESG that it is > > > necessary to fix. > > > > > > > >The first 2 substantive issue was raised by Margaret Wasserman: > > > > > > > >------------------------------------------------------------- > > > >>In section 2: > > > >> The nominating committee will be given the title of > > > the positions > > > >> to be reviewed and a brief description of the desirable set of > > > >> qualifications of the candidate that is nominated to fill each > > > >> position. > > > > > > > >Is this information sent publicly or privately? There are two issues > > > >here: > > > > > > > >1) I think that the "description of the desirable set of > > > qualifications" > > > > should be posted publicly, along with the list of open > > > positions when > > > > the call for nominations is sent. > > > > > > > >2) The IESG and IAB should know, unambiguously, whether or not the > > > > information will be publicly disseminated before providing it. > > > > > > > >------------------------------------------------------------------ > > > > From section 3, subsection 8: > > > >> It is consistent with these rules for the announcements of a > > > >> resignation, of the existence of a mid-term vacancy, > > > and of the > > > >> confirmed candidates to all occur at the same time as > > > long as the > > > >> actual sequence of events that occurred did so in the > > > following > > > >> order. > > > >> > > > >> * The nominating committee completes the advice and consent > > > >> process for the candidate already sitting on another body. > > > >> > > > >> * The newly confirmed candidate resigns from their current > > > >> position. > > > >> > > > >> * The body with the new mid-term vacancy requests that the > > > >> nominating committee fill the position. > > > >> > > > >> * The Executive Director of the IETF informs the nominating > > > >> committee of the mid-term vacancy. > > > >> > > > >> * The nominating committee acts on the request to fill the > > > >> mid-term vacancy > > > > > > > >This section indicates that a position may be vacated and filled > > > >without the community being notified that a position is > > > open. IMO, no > > > >position should be filled without public notice that the position is > > > >open and a public call for nominations. > > > > > > > >I understand one shool of thought that says that this is okay for IAB > > > >positions during the normal selection cycle. Because IAB members > > > >don't have separate responsibilities, it _might_ be okay to > > > pick 6 IAB > > > >members from a candidate pool for 5 open positions, for example. > > > >However, even in this case, the community might want to know if a > > > >person with a particular specialty/area of expertise was moving, so > > > >that folks with that type of expertise could be nominated. > > > > > > > >This section would also be problematic for IESG positions. > > > This could > > > >arise in any case where one IESG position is filled by a sitting IESG > > > >member who is not up for renewal. For example, consider a situation > > > >where the IESG chair does not volunteer for another term and is > > > >replaced by a sitting IESG member who is not up for renewal. Even > > > >though there are two ADs for most areas, the ADs often divide up the > > > >area into logical sections, requiring different expertise for each > > > >position. > > > > > > > >There are also issues with filling any postition according to this > > > >section if it is applied to interim vacancies. For example, the > > > >nomcom should not be empowered to move an IAB member to the IESG to > > > >fill and interim vacancy and replace the IAB member without making a > > > >public call for nominations for the open IAB position. > > > >---------------------------------------------------------------- > > > >The third substantive issue was raised by Thomas Narten: > > > > > > > >> Liaisons from the IESG, IAB, and Internet Society Board of > > > >> Trustees are expected to review the operation and executing > > > >> process of the nominating committee and to report > > > any concerns > > > >> or issues to the Chair of the nominating committee > > > immediately. > > > >> If they can not resolve the issue between > > > themselves liaisons > > > >> must report the issue to their respective bodies. If their > > > >> respective body agrees that there is an issue the > > > liaison must > > > >> report it according to the dispute resolution process stated > > > >> elsewhere in this document. > > > > > > > >I worry that there will be problems with the above in practice. In > > > >particular, the text requires that a liaison report problems back to > > > >their respective group (i.e., IESG or IAB) before invoking the formal > > > >dispute resolution mechanism. But confidentiality rules rather limit > > > >what the liaison can say to their body, and in the case where dispute > > > >resolution may need invoking, it seems like details will be > > > >important. I worry that this will create problems in > > > practice, with it > > > >being unclear what can be said. And if that is the case, it > > > is unclear > > > >what value the discussion within the respective I* would actually > > > >have. This is perhaps more a problem for the IESG, since it has no > > > >confirming role, but it seems like a general issue. > > > > > > > >There are ways of dealing with this, but I'm not sure what is best or > > > >what the WG might think. Some initial thoughts: > > > > > > > >- I note that the current wording doesn't mention the obvious, i.e., > > > > have the liaisons and previous chair get together and discuss > > > > before escalating. One could also have the liaison (independently) > > > > decide whether to formally appeal after such a consultation. This > > > > avoids the confidentiality issue and would seem like a necessary > > > > check as part of escalating issues. > > > > > > > >- add some wording saying that confidentiality rules allow sharing of > > > > info as needed to assess whether to file a formal complaint. > > > >-------------------------------------------------------------------- > > > > > > > >I think these needs to be discussed in the WG, and that they need to > > > >either have new text crafted or a justification for the > > > current choices given. > > > > > > > >The more-or-less minor issues can be found in the ID tracker: > > > > > > > > > > iew_id&dTag=90 > > > >01&rfc_flag=0> > > > > > > > >and are also given below in raw format. > > > >These are, in the opinion of the IESG, "non-show-stopper" > > > issues - not > > > >things that are critical enough to block/delay publication > > > of the document > > > >on their own, but important enough to be worth mentioning, > > > in case they > > > >can be quickly fixed while the document is "open". It is up > > > to the WG what > > > >to do with these. > > > >------------------------------------------------------------- > > > ------------- > > > >Steve Bellovin: > > > >Comment: > > > >The recall section makes no provision or even suggestion > > > that the Recall > > > >Chair verify the putative signers. > > > > > > > >Section 5, Point 12 suggests that the committee consult with > > > the sitting > > > >members of the IAB and IESG. I think that consultation with > > > WG chairs > > > >should be suggested. > > > > > > > >Ted Hardie: > > > >Comment: > > > >I note that the oral tradition section indicates that no > > > person should > > > >serve on both the IESG and IAB, except the IETF Chair who > > > serves on both by > > > >definition. I believe that there is some lack of clarity on > > > whether the IAB > > > >Chair's role ex officio in the IESG means she "serves on", > > > and that this is > > > >probably not the place to resolve that or go into the > > > liaisons from one > > > >body to the other. To capture the same thing, how about: > > > > > > > >"No person should serve both on the IAB and as an Area > > > Director, except > > > >the IETF Chair whose roles as an IAB member and Area > > > Director of the > > > >General Area is set out elsewhere". > > > > > > > >Thomas Narten: > > > > > > > >If a voting volunteer member is recalled the committee may > > > >> choose to proceed with only 9 voting volunteers at its own > > > >> discretion. In all other cases the Chair must > > > repeat the random > > > >> selection process including an announcement of the iteration > > > > > > > >> prior to the actual selection as stated elsewhere in this > > > >> document. > > > > > > > >The above implies to me that the nomcome is required to find a > > > >replacement for a resignation, but is not for a recall. Shouldn't the > > > >nomcom be allowed to also not replace resignations? I.e, I > > > assume that > > > >the nomcom would have the option of filling or not filling > > > any nomcom > > > >opening, regardless of how it occurs. > > > > > > > >> It is consistent with this rule for the nominating > > > committee to > > > >> choose one or more of the currently open positions > > > to which it > > > >> may assign a term greater than 2 years in order to > > > ensure the > > > >> ideal application of this rule in the future. > > > > > > > >s/greater than 2 years/of up to 3 years/ > > > > > > > >(right now, in theory, nomcom could pick the length of time, though I > > > >suspect a lot of folk would be surprised if this ever happend...) > > > > > > > >> committee. The addition must be approved by all > > > members of the > > > >> committee according to its established voting mechanism. > > > >> Advisors participate as individuals. > > > > > > > >"all members" wording implies everyone must agree. What is the intent > > > >here? Is it "must be approved by a quorum of the committee according > > > >to its established voting mechanism"? Note: similar wording appears > > > >elsewhere. > > > > > > > >> conducted. A member may recalled if at least a > > > quorum of all > > > >> committee members agree, including the vote of the > > > member being > > > >> recalled. > > > > > > > >What does this mean? simple majority if there is a quorum? (I ask > > > >because in most cases this document doesn't proscribe rules, leaving > > > >that to the nomcom to decide.) > > > > > > > >> 4. Confirmed candidates are expected to serve at least a 2 year > > > >> term. > > > > > > > >not consistent with interim appointments > > > > > > > >> First, when there is only one official nominating > > > committee the > > > > > > > >add comma after committee > > > > > > > >> As of the publication of this document the current > > > mechanism is > > > > ^ > > > >> an email message to both the "ietf" and the "ietf-announce" > > > >> mailing lists. > > > > > > > >comma above > > > > > > > > > > > >> None of the Chair, liaisons, or advisors vote on > > > the selection > > > >> of candidates. They do vote on all other issues before the > > > >> committee unless otherwise specified. > > > > > > > >s/specified/specified in this document/? (what is the intent?) > > > > > > > >> 6. A Chair, in consultation with the Internet Society > > > President, > > > >> may appoint a temporary substitute. > > > > > > > >Better to say "... for the Chair position". > > > > > > > >> If they can not resolve the issue between > > > themselves liaisons > > > > > > > >comma after themselves. > > > > > > > >> The confirmation process must be completed at least > > > one month > > > >> prior to the First IETF. > > > > > > > >s/must/should/ other parts of the document imply should on > > > this topic. > > > > > > > >> The term of a nominating committee begins when its > > > members are > > > >> officially announced. The term ends at the Third IETF (not > > > >> three meetings) after the next nominating committee's term > > > >> begins. > > > > > > > >ambigous wording. Reword: > > > > > > > > The term ends at the Third IETF (not three > > > meetings), that is, > > > > the IETF after the next nominating committee's term begins. > > > > > > > >Jon Peterson: > > > >Comment: > > > >The Introduction fastidiously notes that the organization of > > > the IESG is > > > >outside the scope of the document. However, in so far as > > > Section 3 bullet > > > >3 explains that half of the IESG positions are reviewed by > > > the NomCom per > > > >year, would it make sense to mention at a high level that > > > IESG members > > > >serve in specific Areas, and that the review process is staggered to > > > >preserve continuity and institutional memory within Areas? > > > This seems like > > > >an important detail of the NomCom process to omit, even if > > > it might change > > > >as the IETF changes. I'd note that Section 3 bullet 3 > > > already has a caveat > > > >about future IESG reorganization, so I'm not sure how it > > > would hurt to > > > >talk about the current IESG structure, in the interests of > > > fully depicting > > > >the existing practice. > > > > > > > >Margaret Wasserman: > > > > > > > >Comment: > > > >EDITORIAL: > > > > > > > >>Abstract > > > >> > > > >> The process by which the members of the IAB and IESG are selected, > > > >> confirmed, and recalled is specified. This document is a > > > >> self-consistent, organized compilation of the process as > > > it was known > > > >> at the time of publication. > > > > > > > >Very weak... I also don't think that the last sentence is true, > > > >as this document changes some things. Suggestions: Add a bit > > > >more information (i.e mention the Nominations Commitee?) and remove > > > >"as it was known at the time of publication". > > > > > > > >The section numbering in this document doesn't match usual > > > >conventions. This makes it harder to refer to sections in this > > > >document unambiguously. > > > > > > > >> 3. One-half of each of the then current IESG and IAB positions is > > > >> selected to be reviewed each year. > > > > > > > >s/One-half of each of/One-half of/ > > > >s/positions is/positions are/ > > > > > > > >> The intent of this rule to ensure the review of approximately > > > >> one-half of each of the IESG and IAB sitting members > > > each year. > > > > > > > >s/one-half of each of/one-half of/ > > > > > > > >> 4. Confirmed candidates are expected to serve at least a 2 year > > > >> term. > > > > > > > >This isn't always true. Replacement candidates may serve > > > >terms of less than two years. > > > > > > > >> A term may begin or end no sooner than the > > > >> first day of the meeting and no later than the last day of the > > > >> meeting as determined by the mutual agreement of the currently > > > >> sitting member and the confirmed candidate. The confirmed > > > >> candidate's term may overlap the sitting member's > > > term during the > > > >> meeting as determined by their mutual agreement. > > > > > > > >How does this apply to IAB terms? In the case where there is > > > >more than one new IAB member, I don't think that it is > > > >defined which IAB member each new member is replacing. > > > >>In section 4, subsection 7: > > > >> Liaisons from the IESG, IAB, and Internet Society Board of > > > >> Trustees are expected to review the operation and executing > > > >> process of the nominating committee and to report > > > any concerns > > > > > > > >There is a mention here of a liaison from the ISOC board. > > > >But, there in section 4.3 there is a list of nomcom members > > > >that indicates how they are selected, and the ISOC liaison > > > >is not listed. > > > > > > > >The organization of this document seems to result in repeating > > > >a lot of information. There are also a lot of forward > > > >references. This makes it difficult to find the part(s) of > > > >the document that apply to a particular part of the process. > > > > > > > >---------------------------------------------------------------- > > > >To subscribe or unsubscribe from this elist use the subscription > > > >manager: > > > > > > > > > > > > ---------------------------------------------------------------- > > > To subscribe or unsubscribe from this elist use the subscription > > > manager: > > > > > > > ---------------------------------------------------------------- > > To subscribe or unsubscribe from this elist use the subscription > > manager: > >-- >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >Brian E Carpenter >Distinguished Engineer, Internet Standards & Technology, IBM > >NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 22:45:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00104Y3W5C@eListX.com> (original mail from jwkckid1@ix.netcom.com) ; Wed, 08 Oct 2003 22:40:44 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00101Y3V5A@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 22:40:43 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00101Y3V59@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 22:40:43 -0400 (EDT) Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMG0010MY3V4O@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 22:40:43 -0400 (EDT) Received: from 1cust59.tnt36.dfw9.da.uu.net ([67.234.81.59] helo=ix.netcom.com) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1A7Qix-0001JV-00; Wed, 08 Oct 2003 22:40:19 -0400 Date: Wed, 08 Oct 2003 21:38:49 -0700 From: Jeff Williams Subject: Re: IESG Issue 5 To: Scott Bradner Cc: ietf-nomcom@lists.elistx.com Message-id: <3F84E658.CBF9B208@ix.netcom.com> Organization: INEGroup Spokesman MIME-version: 1.0 X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <200310081253.h98Cro2w010556@newdev.harvard.edu> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Scott and all, Scott Bradner wrote: > > Question: Should WG chairs be added to the list of those who should be > > consulted? > > YES!!!! Agreed. However such should be given no special or extra consideration. > > > the idea that the nomcom can reasonabally evaluate a sitting AD without > talking to the WG chairs is plain silly Well maybe not silly, but it would be unwise in most instances. > > > Scott > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 131k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard =============================================================== CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 22:45:05 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00104Y8J90@eListX.com> (original mail from jwkckid1@ix.netcom.com) ; Wed, 08 Oct 2003 22:43:32 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00101Y8J8T@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 22:43:31 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMG00101Y8J8R@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 22:43:31 -0400 (EDT) Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMG0011LY8I4O@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 22:43:31 -0400 (EDT) Received: from 1cust59.tnt36.dfw9.da.uu.net ([67.234.81.59] helo=ix.netcom.com) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1A7Qlf-00067E-00; Wed, 08 Oct 2003 22:43:07 -0400 Date: Wed, 08 Oct 2003 21:41:36 -0700 From: Jeff Williams Subject: Re: IESG Issue 10 To: Scott Bradner Cc: ietf-nomcom@lists.elistx.com Message-id: <3F84E700.DB7857AB@ix.netcom.com> Organization: INEGroup Spokesman MIME-version: 1.0 X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <200310081303.h98D3JFL010623@newdev.harvard.edu> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Scott and all, Scott Bradner wrote: > > Question: should text be added making an explicit rule for the voting > > in a Nomcom recall be specified in the document. > > yes, and it should be at least a majority of the seated memebers of the > committee - maybe even 2/3 2/3's is too severe. A simple majority is adequate to meet a reasonable burden. > > > Scott > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 131k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard =============================================================== CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 23:35:08 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMH003040MBUU@eListX.com> (original mail from jwkckid1@ix.netcom.com) ; Wed, 08 Oct 2003 23:34:59 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMH003010MBUS@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 23:34:59 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMH003010MAUR@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 23:34:58 -0400 (EDT) Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMH00KHZ0MAJU@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 23:34:58 -0400 (EDT) Received: from 1cust59.tnt36.dfw9.da.uu.net ([67.234.81.59] helo=ix.netcom.com) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1A7RZO-0003Ct-00; Wed, 08 Oct 2003 23:34:31 -0400 Date: Wed, 08 Oct 2003 22:32:59 -0700 From: Jeff Williams Subject: Re: IESG Issue 5 To: "Putzolu, David" Cc: ietf-nomcom@lists.elistx.com Message-id: <3F84F30B.7B3B2521@ix.netcom.com> Organization: INEGroup Spokesman MIME-version: 1.0 X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <52D13A805349A249960B9943E5590BD881F57C@orsmsx409.jf.intel.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: David and all, I would say MAY have a "decently informed opinion", not necessarily likely to have such. From my experience, some do and some certainly DO NOT have a "decently informed opinion" as has been commented on this forum a number of times in the not so distant past... Putzolu, David wrote: > I agree with this - WG chairs have exposure to IESG members > routinely (at least in the area of their wg) and so are > likely to have a decently informed opinion. > > -David > > > -----Original Message----- > > From: Scott Bradner [mailto:sob@harvard.edu] > > Sent: Wednesday, October 08, 2003 5:54 AM > > To: ietf-nomcom@lists.elistx.com > > Subject: IESG Issue 5 > > > > > > > > > Question: Should WG chairs be added to the list of those > > who should be > > > consulted? > > > > YES!!!! > > > > the idea that the nomcom can reasonabally evaluate a sitting > > AD without > > talking to the WG chairs is plain silly > > > > Scott > > > > ---------------------------------------------------------------- > > To subscribe or unsubscribe from this elist use the subscription > > manager: > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 131k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard =============================================================== CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From ietf-nomcom-errors@lists.elistx.com Wed Oct 8 23:45:05 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMH004040XXBA@eListX.com> (original mail from jwkckid1@ix.netcom.com) ; Wed, 08 Oct 2003 23:41:57 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMH004010XXB8@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 23:41:57 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMH004010XXB7@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Wed, 08 Oct 2003 23:41:57 -0400 (EDT) Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMH00KIT0XWJU@eListX.com> for ietf-nomcom@lists.elistx.com; Wed, 08 Oct 2003 23:41:56 -0400 (EDT) Received: from 1cust59.tnt36.dfw9.da.uu.net ([67.234.81.59] helo=ix.netcom.com) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1A7Rg7-0004nC-00; Wed, 08 Oct 2003 23:41:27 -0400 Date: Wed, 08 Oct 2003 22:39:56 -0700 From: Jeff Williams Subject: Re: IESG Issue 2 To: Brian E Carpenter Cc: "Joel M. Halpern" , ietf-nomcom@lists.elistx.com Message-id: <3F84F4AC.F29C15EA@ix.netcom.com> Organization: INEGroup Spokesman MIME-version: 1.0 X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <3F8412E7.EC8B4026@zurich.ibm.com> <3F8412E7.EC8B4026@zurich.ibm.com> <200310081247.h98Clham010521@newdev.harvard.edu> <5.1.0.14.0.20031008101739.022b1ac0@mail.stevecrocker.com> <3F84480A.9999AEDA@zurich.ibm.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Brian and all, Brian, I know you are going to disagree with me again on this issue, but candidates should be any participating IETF individual. Let them stand on their own merits and answer questions by the IETF participants regarding any elected position. Brian E Carpenter wrote: > "Joel M. Halpern" wrote: > > > > While one may argue that the document should say that new IESG openings > > need to be "advertised", that is not what I understand it to currently say. > > Correct. > > > My understanding of the document and of the discussion in the working group > > is that we decided not to make moving people a major difficulty, and > > therefore decided to allow quasi-simultaneous filling of created openings. > > Correct. But if (and it seems unlikely to me) a sitting IESG member is > appointed to the IAB, and no nominees have been solicited for that IESG > slot, the current text seems to allow the Nomcom to pick a candidate out > of thin air. That seems like a bug. > > > > > My own reading and estimating of reactions is that if we declare that > > openings that are created by moving people must be publicly vacated, > > solicited, and filled then we are essentially telling the nomcom not to > > move people around. Because no nomcom is going to want to make that much > > extra work for itself. > > Yes. But the situation I've mentioned above (an Area Director jumps ship > late during the NomCom process to join the IAB) does seem like an > extraordinary case and not one that any NomCom is likely to create > spontaneously anyway. If we want to give the NomCom discretion to > move ADs around (and I think we do) let's just say so. We could replace > the whole disputed text, e.g. > > It is consistent with these rules for the Nominating Committee > to nominate a sitting Area Director to a different Area and simultaneously > nominate a new Area Director to the position thus vacated, or to > nominate a sitting IAB member to an Area Director position and > simultaneously nominate a new IAB member to the position thus vacated. > Any other moves between positions must be treated as resignations > that create bmid-term vacancies. > > Brian > > > If we want to make moving people an emergency maneuver, we can. I > > personally do not want to make such a change to the accepted practice. > > In terms of moving people between different AD slots, I agree. It's only > the case of creating a completely new vacancy by moving an AD to the > IAB that bothers me. > > > > Yours, > > Joel M. Halpern > > > > At 09:10 PM 10/8/2003 +0700, Robert Elz wrote: > > > Date: Wed, 08 Oct 2003 15:36:39 +0200 > > > From: Brian E Carpenter > > > Message-ID: <3F8412E7.EC8B4026@zurich.ibm.com> > > > > > > | I think Scott is correct that there is an asymmetry. > > > > > >I think there could be, but I don't see any reason that it needs to be so. > > > > > > | An IAB member moving to an IESG position simply increases the number > > > | of identical IAB slots to fill. The process should not require a new > > > | call for nominees. > > > > > >Perhaps, but filling that last (new) open IAB position is hardly > > >critical to anything - the IAB would manage just fine with one less > > >member for a month or two. I would not create a special case just > > >to avoid that. > > > > > > | What is described in the draft is appropriate. > > > > > >You're assuming that what the draft says is what it was claimed to > > >say. I disagree with that, I believe that if you read it carefully > > >you'll find it says nothing of the kind. > > > > > > | An IESG member moving to the IAB creates an unannounced specific > > > vacancy in > > > | the IESG. The process should require a new call for nominees. > > > > > >yes, absolutely, and that's what I think the draft now assumes. Perhaps > > >it could be made clearer that this is what it is saying, but I believe that > > >is what is already there. > > > > > >Given that, while I have no problem with clarifying text, I certainly would > > >not be adding special text to allow something different just so the IAB can > > >have an extra member a little quicker. > > > > > >kre > > > > > > > > >---------------------------------------------------------------- > > >To subscribe or unsubscribe from this elist use the subscription > > >manager: > > > > ---------------------------------------------------------------- > > To subscribe or unsubscribe from this elist use the subscription > > manager: > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > > NEW ADDRESS PLEASE UPDATE ADDRESS BOOK > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 131k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard =============================================================== CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From ietf-nomcom-errors@lists.elistx.com Thu Oct 9 05:16:51 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMH00304G9VBH@eListX.com> (original mail from jwkckid1@ix.netcom.com) ; Thu, 09 Oct 2003 05:13:07 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMH00301G9UBF@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 09 Oct 2003 05:13:06 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMH00301G9UBD@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 09 Oct 2003 05:13:06 -0400 (EDT) Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMH000EGG9T48@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 09 Oct 2003 05:13:05 -0400 (EDT) Received: from 1cust133.tnt36.dfw9.da.uu.net ([67.234.81.133] helo=ix.netcom.com) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1A7Wqa-0002bU-00; Thu, 09 Oct 2003 05:12:37 -0400 Date: Thu, 09 Oct 2003 04:11:05 -0700 From: Jeff Williams Subject: Re: IESG issue 2 (Re: IESG issues with draft-ietf-nomcom-rfc2727bis-07) To: Harald Tveit Alvestrand Cc: Avri Doria , ietf-nomcom@lists.elistx.com Message-id: <3F854248.83E879E9@ix.netcom.com> Organization: INEGroup Spokesman MIME-version: 1.0 X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <181892227.1065604874@localhost> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Harald and all, Hummm? Sounds/reads an awful lot like a "Club" or "Clique" instead of an organization... Harald Tveit Alvestrand wrote: > Thanks, Avri! > > One point of clarification on this point: > While creating a vacancy by moving someone from the IESG to the IAB may not > seem realistic, we have had events in the past where an IESG member has > been moved into another slot on the IESG, and the same nomcom has filled > the resulting vacancy, which was not included as a possible vacancy in the > original call for nominations. > > So it's a real practical question. > > --On 8. oktober 2003 11:53 +0900 Avri Doria wrote: > > > ----------------- > > IESG Issue 2 > > ----------------- > >> raised by Margaret Wasserman: > > > >>> From section 3, subsection 8: > >>> It is consistent with these rules for the announcements of a > >>> resignation, of the existence of a mid-term vacancy, and of the > >>> confirmed candidates to all occur at the same time as long as the > >>> actual sequence of events that occurred did so in the following > >>> order. > >>> > >>> * The nominating committee completes the advice and consent > >>> process for the candidate already sitting on another body. > >>> > >>> * The newly confirmed candidate resigns from their current > >>> position. > >>> > >>> * The body with the new mid-term vacancy requests that the > >>> nominating committee fill the position. > >>> > >>> * The Executive Director of the IETF informs the nominating > >>> committee of the mid-term vacancy. > >>> > >>> * The nominating committee acts on the request to fill the > >>> mid-term vacancy > >> > >> This section indicates that a position may be vacated and filled > >> without the community being notified that a position is open. IMO, no > >> position should be filled without public notice that the position is > >> open and a public call for nominations. > >> > >> I understand one shool of thought that says that this is okay for IAB > >> positions during the normal selection cycle. Because IAB members > >> don't have separate responsibilities, it _might_ be okay to pick 6 IAB > >> members from a candidate pool for 5 open positions, for example. > >> However, even in this case, the community might want to know if a > >> person with a particular specialty/area of expertise was moving, so > >> that folks with that type of expertise could be nominated. > >> > >> This section would also be problematic for IESG positions. This could > >> arise in any case where one IESG position is filled by a sitting IESG > >> member who is not up for renewal. For example, consider a situation > >> where the IESG chair does not volunteer for another term and is > >> replaced by a sitting IESG member who is not up for renewal. Even > >> though there are two ADs for most areas, the ADs often divide up the > >> area into logical sections, requiring different expertise for each > >> position. > >> > >> There are also issues with filling any postition according to this > >> section if it is applied to interim vacancies. For example, the > >> nomcom should not be empowered to move an IAB member to the IESG to > >> fill and interim vacancy and replace the IAB member without making a > >> public call for nominations for the open IAB position. > > > > Background: > > > > The issue was first brought up > > http://lists.elistx.com/archives/ietf-nomcom/200303/msg00020.html > > > >>>> > >>>>> >> Insert in section 3 as paragraph 6 and renumber all subsequent > >>>>> paragraphs: > >>>>> > >>>>> "Nomcom-caused Mid-term Vacancies: > >>>>> > >>>>> From time to time the Nomcom may propose moving a serving Area > >>>>> Director or > >>>>> IAB member from one position to another. (E.g. moving a Transport > >>>>> AD to > >>>>> cover O&M). If the serving member is at the end of their normal > >>>>> term there > >>>>> is no change in procedures. Otherwise, this is treated as a mid-term > >>>>> vacancy and mid-term procedures are used with the following > >>>>> exceptions: > >>>>> > >>>>> a) If the vacancy will occur on the IAB due to a move from the IAB > >>>>> to the > >>>>> IESG, the Nomcom may, upon confirmation of nominee/IAB member, > >>>>> submit for > >>>>> confirmation as part of the normal slate of candidates another > >>>>> nominee to > >>>>> complete the term of the departing IAB member. If the Nomcom > >>>>> declines to > >>>>> nominate a replacement as part of the annual process, the IAB may, > >>>>> at any > >>>>> time after the confirmation of the departing member, ask the Nomcom > >>>>> to fill > >>>>> the slot using mid-term procedures. > >>>>> > >>>>> b) If the vacancy will occur on the IESG, either as a move to > >>>>> another IESG > >>>>> slot or as a move to the IAB, the Nomcom must use mid-term > >>>>> procedure rules. > >>>>> Most importantly, they must advertise the vacancy, and must > >>>>> consider all > >>>>> new candidates as equitably as any previously considered. The IESG > >>>>> chair is > >>>>> responsible for notifying the IETF Executive director of the > >>>>> vacancy and > >>>>> who in turn is responsible for asking the Nomcom select the > >>>>> replacement. > >>>>> The Nomcom is explicitly barred from proceeding without an explicit > >>>>> request > >>>>> from the IESG chair. The term of the nominee shall be for the > >>>>> remainder of > >>>>> the term of the vacated position." > > > > > > The recommended text change was never discussed on the list. > > > > The issue surrounding the 'poaching' issue was discussed but the > > discussion centered on the serialization described in 2727bis-07. > > However, none of the discussions were about the result of moving someone > > from a non open seat on the IESG to fill an IAB slot and thus having to > > fill an unannounced IESG slot. > > > > Questions: > > > > Does the document need to be explicit about treating the replacement of > > an IESG member in an non open chair differently the the replacement of > > an IAB member in a non open seat? > > > > Do full mid term replacement rules, including public announcement apply > > to this case? > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard =============================================================== CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801 From ietf-nomcom-errors@lists.elistx.com Mon Oct 13 04:15:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMO00604S274X@eListX.com> (original mail from harald@alvestrand.no); Mon, 13 Oct 2003 04:10:55 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMO00601S264V@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 13 Oct 2003 04:10:54 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMO00601S254U@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 13 Oct 2003 04:10:53 -0400 (EDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMO00FM9S25DR@eListX.com> for ietf-nomcom@lists.elistx.com; Mon, 13 Oct 2003 04:10:53 -0400 (EDT) Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 09F6E61C00 for ; Mon, 13 Oct 2003 10:10:26 +0200 (CEST) Date: Mon, 13 Oct 2003 10:09:56 +0200 From: Harald Tveit Alvestrand Subject: Issue: Transition rules? To: ietf-nomcom@lists.elistx.com Message-id: <22054032.1066039796@localhost> MIME-version: 1.0 X-Mailer: Mulberry/3.1.0b8 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: because of the timing stuff, this has gone from a non-issue to perhaps an issue...... the current nomcom doc says nothing about when it takes effect, or what that effect is on a currently seated nomcom. I think one sensible procedure would be that it takes effect the moment the ISOC Board accepts a motion to observe that this is current IETF procedure (or some other convoluted wording), and that a sitting nomcom switch to using the rules as far as possible, but does not change decisions taken in the past (for instance, the change in selection rules would not force a current nomcom member to resign, but the sitting nomcom would be expected to use the new rules when communicating with the confirming bodies). 1) Does that make sense? 2) Should the document say so? Of course, an alternate is that the rules take effect when the IESG has approved the document. Thoughts? Harald From ietf-nomcom-errors@lists.elistx.com Mon Oct 13 09:35:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMP00K046PXW2@eListX.com> (original mail from sob@newdev.harvard.edu) ; Mon, 13 Oct 2003 09:27:33 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMP00K016PWVZ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 13 Oct 2003 09:27:32 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMP00K016PWVY@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 13 Oct 2003 09:27:32 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMP00K1U6PVUI@eListX.com> for ietf-nomcom@lists.elistx.com; Mon, 13 Oct 2003 09:27:32 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h9DDR36U028180 for ; Mon, 13 Oct 2003 09:27:03 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h9DDR3Yk028179 for ietf-nomcom@lists.elistx.com; Mon, 13 Oct 2003 09:27:03 -0400 (EDT) Date: Mon, 13 Oct 2003 09:27:03 -0400 (EDT) From: Scott Bradner Subject: Re: Issue: Transition rules? To: ietf-nomcom@lists.elistx.com Message-id: <200310131327.h9DDR3Yk028179@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: I think it takes effect as soon as the IESG approves it as Harald says in his note, the ISOC step is to "observe that this is current IETF procedure" and is needed for insurance purposes. > and that a sitting nomcom switch to > using the rules as far as possible, but does not change decisions taken in > the past (for instance, the change in selection rules would not force a > current nomcom member to resign, but the sitting nomcom would be expected > to use the new rules when communicating with the confirming bodies). yes Scott From ietf-nomcom-errors@lists.elistx.com Mon Oct 13 10:45:04 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMP001049Y5UH@eListX.com> (original mail from mstjohns@mindspring.com) ; Mon, 13 Oct 2003 10:37:18 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMP001019Y5UF@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 13 Oct 2003 10:37:17 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMP001019Y5UE@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 13 Oct 2003 10:37:17 -0400 (EDT) Received: from razorbill.mail.pas.earthlink.net (razorbill.mail.pas.earthlink.net [207.217.121.248]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMP00KAC9Y4UG@eListX.com> for ietf-nomcom@lists.elistx.com; Mon, 13 Oct 2003 10:37:17 -0400 (EDT) Received: from pcp802150pcs.nrockv01.md.comcast.net ([68.48.85.252] helo=STJOHNS-LAPTOP2.mindspring.com) by razorbill.mail.pas.earthlink.net with asmtp (TLSv1:RC4-SHA:128) (Exim 3.33 #1) id 1A93oW-00046G-00; Mon, 13 Oct 2003 07:36:48 -0700 Date: Mon, 13 Oct 2003 10:36:44 -0400 From: Michael StJohns Subject: Re: IESG Issue 2 In-reply-to: <200310081247.h98Clham010521@newdev.harvard.edu> X-Sender: mstjohns@mindspring.com@pop.mindspring.com To: Scott Bradner , ietf-nomcom@lists.elistx.com Message-id: <6.0.0.20.2.20031013101249.0356a430@pop.mindspring.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.20 (Beta) Content-type: text/plain; format=flowed; charset=us-ascii X-ELNK-Trace: 9f6ded143da542dc9c7f779228e2f6aeda0071232e20db4d40cf8b3661e4891c8852c0cceb3e8d87350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c References: <200310081247.h98Clham010521@newdev.harvard.edu> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Sorry for ignoring this for as long as I have but I was hoping it would go away. Since I'm the one who started the trend of moving people from one ADs job to another I figure I should try and make a constructive suggestion. In general, each area has at least one AD position open and advertised each year (2 ADs alternating). There are three cases to this - 1) Moving an expiring AD (e.g. one that's up for reappointment) from one solicited position to another (either AD or IAB), 2) Moving a non-expiring AD from their current non-advertised position to another AD job, and 3) Moving a non-expiring AD to the IAB. 1) No problem, both the old and new slots were advertised and the candidate vacates the old slot when the new appointee takes office. 2) Not much of a problem as long as the position (E.g. internet AD) was advertised - all you're doing is filling 2 copies of the position instead of one - and that's what happened under the Nomcom I chaired. This isn't much different than what happens with the IAB. If there is only one AD for an area (e.g. like Security and User Services used to be) and it wasn't being advertised, then the position needs to be filled as a mid term vacancy - but that should be rare under current organization. 3) This one is problematic and differs from 2 in that there is no absolute prohibition on someone being on both the IESG and the IAB. With 2, the old position becomes vacant upon the AD accepting appointment to the new position and having the IAB approve it. In 3, the old position doesn't become vacant until the AD explictly resigns. Under current rules, this one should also be filled as a mid-term vacancy. One of the reasons why I lobbied so hard for a rule prohibiting dual IAB/IESG membership was to make things like this easier to deal with. Fix: If the type of position (e.g. security AD) was advertised, the Nomcom can take action to fill it from the set of candidates it already has for that type of slot. If the type of position was not advertised (e.g. because it was an off year and there was only one of that type) it must not take action to fill it and it must treat it as a mid-term vacancy. However, once the candidate has accepted appointment to the new position and once the IAB has confirmed them and the announcement has been made, the Nomcom can immediately begin the process of selection for replacement. Other fix: Dual Membership on both the IAB and IESG is prohibited. A nominee who accepts appointment to one body automatically vacates their position on the other body not later than noon on the last of the First IETF meeting. As long as the to-be-vacated position type has been advertised, the Nomcom shall take action to fill it. At 08:47 10/8/2003, Scott Bradner wrote: >I see little reason to do a new search if the case is someone with >time left in their IAB term moving from the IAB to the IESG. I do >not see a realistic problem that would be solved by doing so. The >community suggested people for the IAB already in the process and >the IAB members should be generalists (i.e. no IAB topic-specific >seats) > >but the case of an IESG member with time left in their term >being moved to the IAB or another IESG seat should cause a >new call for nominees to fill the open IESG seat > >(while moving in mid term from the IESG to the IAB might not >have happened I can easily see the case (its not all that different >from someone just quiting being an IESG member which does happen) > >Scott > > > > > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: From ietf-nomcom-errors@lists.elistx.com Mon Oct 13 14:09:32 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMP00H04JDQWA@eListX.com> (original mail from rja@extremenetworks.com) ; Mon, 13 Oct 2003 14:01:03 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMP00H01JDQW8@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 13 Oct 2003 14:01:02 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMP00H01JDPW7@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 13 Oct 2003 14:01:01 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMP00AP6JDPWC@eListX.com> for ietf-nomcom@lists.elistx.com; Mon, 13 Oct 2003 14:01:01 -0400 (EDT) Received: from extremenetworks.com (unknown [10.0.8.71]) by gnat.inet.org (Postfix) with ESMTP id C185B671A3; Mon, 13 Oct 2003 14:04:54 -0400 (EDT) Date: Mon, 13 Oct 2003 14:00:29 -0400 From: RJ Atkinson Subject: Re: Issue: Transition rules? In-reply-to: <200310131327.h9DDR3Yk028179@newdev.harvard.edu> To: Scott Bradner Cc: ietf-nomcom@lists.elistx.com Message-id: <21BE8016-FDA7-11D7-977C-00039357A82A@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Monday, Oct 13, 2003, at 09:27 America/Montreal, Scott Bradner wrote: > I think it takes effect as soon as the IESG approves it > as Harald says in his note, the ISOC step is to "observe that > this is current IETF procedure" and is needed for insurance purposes. I disagree with the notion that IESG approval without ISOC approval is sufficient in this narrow situation. Further, as a purely practical observation, the ISOC BOT has been able to make formal decisions quickly in the past when they were so inclined. So the ISOC BOT step would not represent any significant delay. Hence there is no visible good reason to try to short-circuit that step. Yours, Ran Atkinson rja@extremenetworks.com From ietf-nomcom-errors@lists.elistx.com Mon Oct 13 14:10:35 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMP00I04JJD7O@eListX.com> (original mail from sob@newdev.harvard.edu) ; Mon, 13 Oct 2003 14:04:25 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMP00I01JJD7M@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 13 Oct 2003 14:04:25 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMP00I01JJD7L@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 13 Oct 2003 14:04:25 -0400 (EDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMP00H14JJCWW@eListX.com> for ietf-nomcom@lists.elistx.com; Mon, 13 Oct 2003 14:04:24 -0400 (EDT) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h9DI3t6U029217; Mon, 13 Oct 2003 14:03:55 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h9DI3tdR029216; Mon, 13 Oct 2003 14:03:55 -0400 (EDT) Date: Mon, 13 Oct 2003 14:03:55 -0400 (EDT) From: Scott Bradner Subject: Re: Issue: Transition rules? In-reply-to: <21BE8016-FDA7-11D7-977C-00039357A82A@extremenetworks.com> To: rja@extremenetworks.com, sob@harvard.edu Cc: ietf-nomcom@lists.elistx.com Message-id: <200310131803.h9DI3tdR029216@newdev.harvard.edu> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: > Hence there is no visible good reason > to try to short-circuit that step. just to be very clear - I did not intend to suggest that the ISOC BoT step be "short-circuited". I just point out, as Harald did, that the ISOC board step is to accept the IETF process -- so by simple English the process would have to be already current before the ISOC BoT could accept it as current Scott From ietf-nomcom-errors@lists.elistx.com Mon Oct 13 14:18:12 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMP00I04JSUS1@eListX.com> (original mail from rja@extremenetworks.com) ; Mon, 13 Oct 2003 14:10:06 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMP00I01JSTRZ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 13 Oct 2003 14:10:05 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMP00I01JSTRS@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 13 Oct 2003 14:10:05 -0400 (EDT) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMP00H3SJSSWW@eListX.com> for ietf-nomcom@lists.elistx.com; Mon, 13 Oct 2003 14:10:05 -0400 (EDT) Received: from extremenetworks.com (unknown [10.0.8.71]) by gnat.inet.org (Postfix) with ESMTP id 3CC98671A3; Mon, 13 Oct 2003 14:14:00 -0400 (EDT) Date: Mon, 13 Oct 2003 14:09:35 -0400 From: RJ Atkinson Subject: Re: Issue: Transition rules? In-reply-to: <200310131803.h9DI3tdR029216@newdev.harvard.edu> To: Scott Bradner Cc: ietf-nomcom@lists.elistx.com Message-id: <66C998F8-FDA8-11D7-977C-00039357A82A@extremenetworks.com> MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Monday, Oct 13, 2003, at 14:03 America/Montreal, Scott Bradner wrote: > I just point out, as Harald did, that the ISOC board step is to > accept the IETF process -- so by simple English the process would > have to be already current before the ISOC BoT could accept it as > current Nice twisting of words on your part since it is hardly "by simple English" to go from "IESG and ISOC BOT must approve before changes take effect" to "IESG only must approve before changes take effect". Bottom line is that we disagree. I still believe the new rules cannot take effect until after ISOC BOT has formally approved them, in addition to the IESG. Probably not worth a lot more back and forth on this list, since I think both views have been clearly put forward now. Yours, Ran From ietf-nomcom-errors@lists.elistx.com Tue Oct 14 11:35:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR002046X5O9@eListX.com> (original mail from brc@zurich.ibm.com); Tue, 14 Oct 2003 11:27:05 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR002016X5O7@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 14 Oct 2003 11:27:05 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR002016X4O6@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 14 Oct 2003 11:27:04 -0400 (EDT) Received: from d12lmsgate.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMR00JLJ6X39Y@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 14 Oct 2003 11:27:04 -0400 (EDT) Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h9EFQWXZ091768 for ; Tue, 14 Oct 2003 17:26:33 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9EFQYOh168570 for ; Tue, 14 Oct 2003 17:26:34 +0200 Received: from zurich.ibm.com (sig-9-145-145-162.de.ibm.com [9.145.145.162]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA44082 for ; Tue, 14 Oct 2003 17:26:33 +0200 Date: Tue, 14 Oct 2003 17:26:05 +0200 From: Brian E Carpenter Subject: Re: Issue: Transition rules? To: ietf-nomcom@lists.elistx.com Message-id: <3F8C158D.BD75701D@zurich.ibm.com> Organization: IBM MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en,fr,de References: <66C998F8-FDA8-11D7-977C-00039357A82A@extremenetworks.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Just a reminder: ISOC Board electronic votes normally take two weeks. That's not an unreasonable delay, if people feel Ran is correct. However, in the past the IESG formal decision to approve the BCP has been the signal for implementation. So I think I agree with Scott. Brian RJ Atkinson wrote: > > On Monday, Oct 13, 2003, at 14:03 America/Montreal, Scott Bradner wrote: > > I just point out, as Harald did, that the ISOC board step is to > > accept the IETF process -- so by simple English the process would > > have to be already current before the ISOC BoT could accept it as > > current > > Nice twisting of words on your part since it is hardly "by simple > English" > to go from "IESG and ISOC BOT must approve before changes take > effect" to "IESG only must approve before changes take effect". > > Bottom line is that we disagree. I still believe the new rules > cannot take effect until after ISOC BOT has formally approved them, > in addition to the IESG. > > Probably not worth a lot more back and forth on this list, > since I think both views have been clearly put forward now. > > Yours, > > Ran > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From ietf-nomcom-errors@lists.elistx.com Tue Oct 14 12:05:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR005048GR22@eListX.com> (original mail from mstjohns@mindspring.com) ; Tue, 14 Oct 2003 12:00:27 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR005018GQ20@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 14 Oct 2003 12:00:26 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR005018GQ1Z@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 14 Oct 2003 12:00:26 -0400 (EDT) Received: from razorbill.mail.pas.earthlink.net (razorbill.mail.pas.earthlink.net [207.217.121.248]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMR000F18GPML@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 14 Oct 2003 12:00:25 -0400 (EDT) Received: from pcp802150pcs.nrockv01.md.comcast.net ([68.48.85.252] helo=STJOHNS-LAPTOP2.mindspring.com) by razorbill.mail.pas.earthlink.net with asmtp (TLSv1:RC4-SHA:128) (Exim 3.33 #1) id 1A9RaX-0002VB-00 for ietf-nomcom@lists.elistx.com; Tue, 14 Oct 2003 08:59:58 -0700 Date: Tue, 14 Oct 2003 11:59:51 -0400 From: Michael StJohns Subject: Re: Issue: Transition rules? In-reply-to: <200310131327.h9DDR3Yk028179@newdev.harvard.edu> X-Sender: mstjohns@mindspring.com@pop.mindspring.com To: ietf-nomcom@lists.elistx.com Message-id: <6.0.0.20.2.20031014115518.033d8090@pop.mindspring.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.20 (Beta) Content-type: text/plain; format=flowed; charset=us-ascii X-ELNK-Trace: 9f6ded143da542dc9c7f779228e2f6aeda0071232e20db4d93dff098b5651070fa486ec9c9daa8e4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c References: <200310131327.h9DDR3Yk028179@newdev.harvard.edu> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: This was discussed briefly on IAB/IESG lists... My opinion plus a few others: Pragmatically, it can't actually become active until the next Nomcom. Part of the problem is there are a number of race conditions that could occur depending on when the document was actually approved. If it had been approved before this nomcom had been empaneled then... Later, Mike At 09:27 10/13/2003, Scott Bradner wrote: >I think it takes effect as soon as the IESG approves it >as Harald says in his note, the ISOC step is to "observe that >this is current IETF procedure" and is needed for insurance purposes. > > > and that a sitting nomcom switch to > > using the rules as far as possible, but does not change decisions taken in > > the past (for instance, the change in selection rules would not force a > > current nomcom member to resign, but the sitting nomcom would be expected > > to use the new rules when communicating with the confirming bodies). > >yes > >Scott > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: From ietf-nomcom-errors@lists.elistx.com Tue Oct 14 12:15:06 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR005048SZOM@eListX.com> (original mail from galvin+ietf-nomcom@elistx.com); Tue, 14 Oct 2003 12:07:47 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR005018SYOK@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 14 Oct 2003 12:07:46 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR005018SYOI@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 14 Oct 2003 12:07:46 -0400 (EDT) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMR0037Q8SXOM@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 14 Oct 2003 12:07:46 -0400 (EDT) Date: Tue, 14 Oct 2003 12:07:23 -0400 (EDT) From: James M Galvin Subject: Re: Issue: Transition rules? In-reply-to: <22054032.1066039796@localhost> X-X-Sender: galvin@three.elistx.com To: Harald Tveit Alvestrand Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: In general, all approved documents take effect immediately. I don't believe this document should be any different and I don't believe we need to state that explicitly. However, I presume you are suggesting we document the "edge case" of whether or not an operational NOMCOM is required to employ a revised document if one is published during its tenure? (It's probably worth noting for completeness there is always an operational NOMCOM, and in the current draft revision there is a short period of time when two may be operating concurrently.) With protocols I believe we all expect that when a revision is published it will be adopted immediately and implementations will transition as soon as possible. It's not a perfect expectation but it mostly works. We should have the same situation with this document. Do we need to document that? I would not do it in this document. If we believe that IETF procedures in general should be adopted when approved then let's make that the policy for all procedures. I do not believe this document should be special with respect to this issue. I think we should have just such a policy. Jim On Mon, 13 Oct 2003, Harald Tveit Alvestrand wrote: Date: Mon, 13 Oct 2003 10:09:56 +0200 From: Harald Tveit Alvestrand To: ietf-nomcom@lists.elistx.com Subject: Issue: Transition rules? because of the timing stuff, this has gone from a non-issue to perhaps an issue...... the current nomcom doc says nothing about when it takes effect, or what that effect is on a currently seated nomcom. I think one sensible procedure would be that it takes effect the moment the ISOC Board accepts a motion to observe that this is current IETF procedure (or some other convoluted wording), and that a sitting nomcom switch to using the rules as far as possible, but does not change decisions taken in the past (for instance, the change in selection rules would not force a current nomcom member to resign, but the sitting nomcom would be expected to use the new rules when communicating with the confirming bodies). 1) Does that make sense? 2) Should the document say so? Of course, an alternate is that the rules take effect when the IESG has approved the document. Thoughts? Harald ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: From ietf-nomcom-errors@lists.elistx.com Tue Oct 14 12:25:09 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR006049IEM9@eListX.com> (original mail from kre@munnari.OZ.AU); Tue, 14 Oct 2003 12:23:02 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR006019IEM5@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 14 Oct 2003 12:23:02 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR006019IDM4@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 14 Oct 2003 12:23:01 -0400 (EDT) Received: from fuchsia.home ([192.150.250.67]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMR000JO9IAML@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 14 Oct 2003 12:23:01 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h9EGL6Il012877; Tue, 14 Oct 2003 23:21:06 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h9EGLge17342; Tue, 14 Oct 2003 23:21:43 +0700 (ICT) Date: Tue, 14 Oct 2003 23:21:42 +0700 From: Robert Elz Subject: Re: Issue: Transition rules? In-reply-to: <22054032.1066039796@localhost> To: Harald Tveit Alvestrand Cc: ietf-nomcom@lists.elistx.com Message-id: <9549.1066148502@munnari.OZ.AU> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <22054032.1066039796@localhost> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Date: Mon, 13 Oct 2003 10:09:56 +0200 From: Harald Tveit Alvestrand Message-ID: <22054032.1066039796@localhost> | I think one sensible procedure would be that it takes effect the moment the | ISOC Board accepts a motion to observe that this is current IETF procedure | (or some other convoluted wording), and that a sitting nomcom switch to | using the rules as far as possible, In this particular case, I see no harm from that, but in general, I think this would be an intolerable burden to place upon the nomcom, so, no, this would be wrong. The rules place burdens upon the nomcom itself as well as define how it works to select IAB and IESG members - volunteers sign up to participate on the nomcom upon the basis of the rules that exist. Changing the rules mid-stream is totally unreasonable. The rules for a nomcom need to be fixed at the point the nomcom is formed (when the people selected agree to their selection as part of the nomcom). Changes after that should apply to the next nomcom only. That may make life difficult for the IETF and this particular nomcom, as the new doc wasn't done in time for it, but as a general principle, this is the way things should work. The next (sigh) revision of the nomcom doc should probably make specific rules for this kind of thing, in which case it may be reasonable to divide the various procedures into two groups - one which can be changed at any time and immediately effect the nomcom process from the point it is adopted, and the other for which no changes can affect a sitting nomcom. But it is certainly too late now for anything like that to be done for the nomcom that is just commencing, or ulness the entire doc is to be re-opened for scrutiny, for the current proposed revision of the procedures. kre ps: adopting this attitude also means I don't need to get involved in the petty argument about exactly who's approval stamp is the one that matters... From ietf-nomcom-errors@lists.elistx.com Tue Oct 14 12:35:08 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR007049SV0J@eListX.com> (original mail from mstjohns@mindspring.com) ; Tue, 14 Oct 2003 12:29:19 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR007019SU0B@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 14 Oct 2003 12:29:18 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR007019SU09@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 14 Oct 2003 12:29:18 -0400 (EDT) Received: from razorbill.mail.pas.earthlink.net (razorbill.mail.pas.earthlink.net [207.217.121.248]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMR003AM9STOM@eListX.com>; Tue, 14 Oct 2003 12:29:17 -0400 (EDT) Received: from pcp802150pcs.nrockv01.md.comcast.net ([68.48.85.252] helo=STJOHNS-LAPTOP2.mindspring.com) by razorbill.mail.pas.earthlink.net with asmtp (TLSv1:RC4-SHA:128) (Exim 3.33 #1) id 1A9S2T-0003RD-00; Tue, 14 Oct 2003 09:28:49 -0700 Date: Tue, 14 Oct 2003 12:28:40 -0400 From: Michael StJohns Subject: Re: Issue: Transition rules? In-reply-to: X-Sender: mstjohns@mindspring.com@pop.mindspring.com To: James M Galvin , Harald Tveit Alvestrand Cc: ietf-nomcom@lists.elistx.com Message-id: <6.0.0.20.2.20031014121714.02efc258@pop.mindspring.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.20 (Beta) Content-type: text/plain; format=flowed; charset=us-ascii X-ELNK-Trace: 9f6ded143da542dc9c7f779228e2f6aeda0071232e20db4dc4b4d20c6d3151bef3d98817e0c355b0350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c References: <22054032.1066039796@localhost> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: At 12:07 10/14/2003, James M Galvin wrote: >In general, all approved documents take effect immediately. I don't >believe this document should be any different and I don't believe we >need to state that explicitly. > >However, I presume you are suggesting we document the "edge case" of >whether or not an operational NOMCOM is required to employ a revised >document if one is published during its tenure? (It's probably worth >noting for completeness there is always an operational NOMCOM, and in >the current draft revision there is a short period of time when two may >be operating concurrently.) No. The problem is that there are possible edge conditions between the two documents (2727 vs 2727bis). One example right off the top: 2727bis allows a challenge to the selection process for the Nomcom and sets a 1 week period after the selection has been made for that challenge, 2727 doesn't have such a concept. Say 2727bis is approved during the one week period (which it won't be) - which rule applies? Say its approved one month later - an argument could be made that challenges could occur from the approval date for the one week. An edge case that has no prima facia resolution. (Note - one such challenge would be that the Nomcom chair excluded from the volunteer pool people who were qualified under 2727bis rules of 3 of 5). There may be others where process under 2727 conflicts with, impedes or differs from 2727bis. Regardless, this nomcom should follow 2727 and assuming 2727bis gets approved, the next nomcom can follow 2727bis. Note that none of the above prohibits the sitting nomcom from adopting procedure rules from 2727bis that don't conflict with 2727, but that's their choice, not ours. Later, Mike >With protocols I believe we all expect that when a revision is published >it will be adopted immediately and implementations will transition as >soon as possible. It's not a perfect expectation but it mostly works. >We should have the same situation with this document. > >Do we need to document that? > >I would not do it in this document. If we believe that IETF procedures >in general should be adopted when approved then let's make that the >policy for all procedures. I do not believe this document should be >special with respect to this issue. > >I think we should have just such a policy. > >Jim > > > > >On Mon, 13 Oct 2003, Harald Tveit Alvestrand wrote: > > Date: Mon, 13 Oct 2003 10:09:56 +0200 > From: Harald Tveit Alvestrand > To: ietf-nomcom@lists.elistx.com > Subject: Issue: Transition rules? > > because of the timing stuff, this has gone from a non-issue to perhaps an > issue...... > > the current nomcom doc says nothing about when it takes effect, or what > that effect is on a currently seated nomcom. > > I think one sensible procedure would be that it takes effect the > moment the > ISOC Board accepts a motion to observe that this is current IETF > procedure > (or some other convoluted wording), and that a sitting nomcom switch to > using the rules as far as possible, but does not change decisions > taken in > the past (for instance, the change in selection rules would not force a > current nomcom member to resign, but the sitting nomcom would be expected > to use the new rules when communicating with the confirming bodies). > > 1) Does that make sense? > 2) Should the document say so? > > Of course, an alternate is that the rules take effect when the IESG has > approved the document. Thoughts? > > Harald > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: > > > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: From ietf-nomcom-errors@lists.elistx.com Tue Oct 14 12:35:16 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR007049Z29C@eListX.com> (original mail from galvin+ietf-nomcom@elistx.com); Tue, 14 Oct 2003 12:33:02 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR007019Z296@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 14 Oct 2003 12:33:02 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR007019Z294@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 14 Oct 2003 12:33:02 -0400 (EDT) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMR000LE9Z1ML@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 14 Oct 2003 12:33:01 -0400 (EDT) Date: Tue, 14 Oct 2003 12:32:38 -0400 (EDT) From: James M Galvin Subject: Re: IESG Issue 2 In-reply-to: <5.1.0.14.0.20031008101739.022b1ac0@mail.stevecrocker.com> X-X-Sender: galvin@three.elistx.com To: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: I agree with Joel. As I understood the prior discussion, the goal was to permit the NOMCOM to complete its job as expeditiously as possible. As a practical matter this meant setting out rules so the NOMCOM could be done by the First IETF instead of having to invoke the mid-term vacancy rules and extend its job for another month. So, the document makes it okay for only the NOMCOM to know about the additional vacancy and for it to work to fill it as best it can without announcing the actual vacancy itself -- which doesn't really exist until there's been a formal resignation so what we're really talking about here is making the resignation public. I should point out that currently the IESG has two ADs in all areas except the General Area. What this means is that in all cases except the General Area the community already knows that every area has an open slot. Thus, the NOMCOM is already working with a pool of candidates for every area except the General Area. Personally, I'm not concerned about the General Area since it is already a special case. I'm not in favor of forcing the advertisement of a mid-term vacancy, or more precisely for an AD to resign publically in hopes of being approved for an alternate position. I don't have a problem with the NOMCOM filling two slots, one I didn't know about upfront. I'm also more concerned that the result of trying to "fix" this edge case will be that "poaching" will no longer be practiced, since I can not imagine a NOMCOM already worn out from 4 months of work that is going to agree to another month. The NOMCOM job is hard enough and I am comfortable with this level of discretion. Jim On Wed, 8 Oct 2003, Joel M. Halpern wrote: Date: Wed, 08 Oct 2003 10:21:13 -0400 From: Joel M. Halpern To: ietf-nomcom@lists.elistx.com Subject: Re: IESG Issue 2 While one may argue that the document should say that new IESG openings need to be "advertised", that is not what I understand it to currently say. My understanding of the document and of the discussion in the working group is that we decided not to make moving people a major difficulty, and therefore decided to allow quasi-simultaneous filling of created openings. My own reading and estimating of reactions is that if we declare that openings that are created by moving people must be publicly vacated, solicited, and filled then we are essentially telling the nomcom not to move people around. Because no nomcom is going to want to make that much extra work for itself. If we want to make moving people an emergency maneuver, we can. I personally do not want to make such a change to the accepted practice. Yours, Joel M. Halpern From ietf-nomcom-errors@lists.elistx.com Tue Oct 14 12:55:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR00804AOBBY@eListX.com> (original mail from kre@munnari.OZ.AU); Tue, 14 Oct 2003 12:48:11 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR00801AOBBW@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 14 Oct 2003 12:48:11 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR00801AOABU@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 14 Oct 2003 12:48:10 -0400 (EDT) Received: from fuchsia.home ([192.150.250.67]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMR000ODAO6ML@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 14 Oct 2003 12:48:10 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h9EGkHIl004656; Tue, 14 Oct 2003 23:46:17 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h9EGkTe09655; Tue, 14 Oct 2003 23:46:32 +0700 (ICT) Date: Tue, 14 Oct 2003 23:46:28 +0700 From: Robert Elz Subject: Re: IESG Issue 2 In-reply-to: <6.0.0.20.2.20031013101249.0356a430@pop.mindspring.com> To: Michael StJohns Cc: Scott Bradner , ietf-nomcom@lists.elistx.com Message-id: <19950.1066149988@munnari.OZ.AU> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <6.0.0.20.2.20031013101249.0356a430@pop.mindspring.com> <200310081247.h98Clham010521@newdev.harvard.edu> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Date: Mon, 13 Oct 2003 10:36:44 -0400 From: Michael StJohns Message-ID: <6.0.0.20.2.20031013101249.0356a430@pop.mindspring.com> | 1) No problem, both the old and new slots were advertised and the candidate | vacates the old slot when the new appointee takes office. Yes, that one is a non-issue. | 2) Not much of a problem as long as the position (E.g. internet AD) was | advertised - all you're doing is filling 2 copies of the position instead | of one You're assuming that all areas have 2 ADs. They haven't in the past, and most probably won't again. [Actually, I see that you actually weren't when I read further, you were just treating this as a special case, but allow me to rant anyway, as I typed all this already...] To take a most extreme example, suppose that in a year where the IETF chair position (the general AD if you like) is not intended to be re-nominated, and assume that the nomcom decides that the current incumbent as IETF chair would be better placed as the (or an) AD for the foobar area (or on the IAB). Then the proceed to select someone else as IETF chair, a position that wasn't supposed to be open. This is the case that the rules really need to catch - make sure this is spelled out clearly, and then just apply the same rule to all the other cases and everything will be fine. I see no need for special case rules, or at least not until we have experience with a general rule causing problems. In any case, I am not sure that I agree that "just filling two positions" (without telling anyone - which the confidentiality rules require) is no different than filling one slot. When giving advice about who would be a suitable candidate, one of the criteria needs to be how well they would work with the sitting AD as joint managers of the area. If that sitting AD isn't to remain sitting at all, this could radically alter recommendations for suitable people. The same is true for people being willing to accept nomination "Work with X, you must be joking" or "Yes, X is the other AD, always wanted to work with X, so because of that I'll say yes". | 3) This one is problematic and differs from 2 in that there is no absolute | prohibition on someone being on both the IESG and the IAB. With 2, the old | position becomes vacant upon the AD accepting appointment to the new | position and having the IAB approve it. Really? Why? Where's the prohibition on an AD being an AD for two areas? While there might not be an absolute prohibition on anyone serving on the IAB and IESG at the same time explicitly stated anywhere (under current rules) there hasn't ever been an instance where (perhaps for more than a week or so anyway) it has ever happened. So there's a reasonable amount of "common law" (or precedent) for that. On the other hand, there have been several instances through history where an AD has been AD for multiple areas (sometimes for years). They may look like special cases, but they happened anyway (remember also that the IESG defines its own structure - and is able to shuffle people between areas, even close areas and create others, whenever it wants). The IESG case is actually the harder one of the two, though I can't really see much justification for treating "moving sitting IESG member to IAB" and "moving sitting IESG member to another AD slot" as different in any way at all. | Fix: If the type of position (e.g. security AD) was advertised, the Nomcom | can take action to fill it from the set of candidates it already has for | that type of slot. I don't think that should be done. | If the type of position was not advertised (e.g. | because it was an off year and there was only one of that type) it must not | take action to fill it and it must treat it as a mid-term | vacancy. However, once the candidate has accepted appointment to the new | position and once the IAB has confirmed them and the announcement has been | made, the Nomcom can immediately begin the process of selection for | replacement. All that part seems fine to me, but I'd apply it in all cases, delete the leading "if". I certainly see no reason to delay starting the replacement search until after the positions have been swapped around - the need for any delay at all is just because of the confidentiality requirements (and because until all this has happened, there's no guarantee that the move will in fact happen). kre From ietf-nomcom-errors@lists.elistx.com Tue Oct 14 12:55:05 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR00804AUWLF@eListX.com> (original mail from galvin+ietf-nomcom@elistx.com); Tue, 14 Oct 2003 12:52:08 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR00801AUVLD@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 14 Oct 2003 12:52:07 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR00801AUVLA@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 14 Oct 2003 12:52:07 -0400 (EDT) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMR000P9AUUML@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 14 Oct 2003 12:52:07 -0400 (EDT) Date: Tue, 14 Oct 2003 12:51:44 -0400 (EDT) From: James M Galvin Subject: Re: IESG Issue 17 In-reply-to: <200310081310.h98DASO1010719@newdev.harvard.edu> X-X-Sender: galvin@three.elistx.com To: Scott Bradner Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Speaking as editor: Inserting the complete text from Avri for context: ----------------- IESG Issue 17 ----------------- > >> The confirmation process must be completed at least one month >> prior to the First IETF. > > s/must/should/ other parts of the document imply should on this topic. Questions; Is this an editorial or content change? Is the change accepted? On Wed, 8 Oct 2003, Scott Bradner wrote: Date: Wed, 08 Oct 2003 09:10:28 -0400 (EDT) From: Scott Bradner To: ietf-nomcom@lists.elistx.com Subject: IESG Issue 17 > Questions; > > Is this an editorial or content change? it is a content change not an editorial change I would consider this a content change. The document consistently uses "must" throughout, not "should", and this is intentional. I recall prior discussion from years past about being definite with respect to the schedule and requirements. We'd have to look through POISED archives to find it. > Is the change accepted? if this is not done then what is the fallback if the committee does not make the deadline? (are all is nominations invalid?) In fact, there explicitly is no fallback if the deadline is not met. This was discussed in years past and it was the choice made at that time. Again, we'd have to search the POISED archives to see this. To a first approximation, the existence of the month between when the NOMCOM is done and the staff turnover is effective is the fallback. Essentially, the NOMCOM has a "grace period" of one month before it absolutely, positively has to be done. Jim From ietf-nomcom-errors@lists.elistx.com Tue Oct 14 13:05:18 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR00904BFZFI@eListX.com> (original mail from kre@munnari.OZ.AU); Tue, 14 Oct 2003 13:04:47 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR00901BFZFA@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 14 Oct 2003 13:04:47 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR00901BFYF8@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 14 Oct 2003 13:04:46 -0400 (EDT) Received: from fuchsia.home ([192.150.250.67]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMR003KNBFWOM@eListX.com>; Tue, 14 Oct 2003 13:04:46 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h9EH2uIl003455; Wed, 15 Oct 2003 00:02:56 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h9EH2ue06369; Wed, 15 Oct 2003 00:02:57 +0700 (ICT) Date: Wed, 15 Oct 2003 00:02:56 +0700 From: Robert Elz Subject: Re: Issue: Transition rules? In-reply-to: To: James M Galvin Cc: Harald Tveit Alvestrand , ietf-nomcom@lists.elistx.com Message-id: <2775.1066150976@munnari.OZ.AU> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Date: Tue, 14 Oct 2003 12:07:23 -0400 (EDT) From: James M Galvin Message-ID: | With protocols I believe we all expect that when a revision is published | it will be adopted immediately and implementations will transition as | soon as possible. Huh? You mean that if I have an existing SMTP connection, and a new doc is approved that alters the SMTP dialog, you expect my currently running processes to adapt to the new procedure and enforce the new rules? No-one does that - new rules are only ever used by new connections set up after they have been adopted, and implemented. To get an existing connection to use them, the only way is to kill the connection, and start it all over again under a new implementation. If what you're suggesting is that an existing nomcom should be (metaphorically) killed, and then reconstituted under the new procedures, then fine, that would be a possibility - but I don't think it is one that anyone would consider very seriously. kre ps: in case there is any doubt, I'm in total agreement with Mike. From ietf-nomcom-errors@lists.elistx.com Tue Oct 14 14:35:03 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR00F04F9YL2@eListX.com> (original mail from harald@alvestrand.no); Tue, 14 Oct 2003 14:27:34 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR00F01F9YKT@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 14 Oct 2003 14:27:34 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMR00F01F9XKQ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Tue, 14 Oct 2003 14:27:34 -0400 (EDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMR00AHZF9XML@eListX.com> for ietf-nomcom@lists.elistx.com; Tue, 14 Oct 2003 14:27:33 -0400 (EDT) Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D334C61C11; Tue, 14 Oct 2003 20:27:03 +0200 (CEST) Date: Tue, 14 Oct 2003 19:52:21 +0200 From: Harald Tveit Alvestrand Subject: Re: IESG Issue 2 In-reply-to: To: James M Galvin , ietf-nomcom@lists.elistx.com Message-id: <143399247.1066161141@localhost> MIME-version: 1.0 X-Mailer: Mulberry/3.1.0b8 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: --On 14. oktober 2003 12:32 -0400 James M Galvin wrote: > I should point out that currently the IESG has two ADs in all areas > except the General Area. What this means is that in all cases except > the General Area the community already knows that every area has an open > slot. Thus, the NOMCOM is already working with a pool of candidates for > every area except the General Area. Note that this year's nomcom will not consider the Internet area. From ietf-nomcom-errors@lists.elistx.com Thu Oct 16 12:45:02 2003 Return-Path: Return-path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMU00K04ZQFEA@eListX.com> (original mail from richdr@microsoft.com); Thu, 16 Oct 2003 12:42:15 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMU00K01ZQFE7@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 16 Oct 2003 12:42:15 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMU00K01ZQEE6@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 16 Oct 2003 12:42:14 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMU00EFPZQDLA@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 16 Oct 2003 12:42:14 -0400 (EDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Thu, 16 Oct 2003 09:41:43 -0700 Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 16 Oct 2003 09:41:41 -0700 Received: from RED-MSG-31.redmond.corp.microsoft.com ([157.54.47.231]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0) ; Thu, 16 Oct 2003 09:41:41 -0700 Date: Thu, 16 Oct 2003 09:41:41 -0700 From: Richard Draves Subject: RE: Issue: Transition rules? To: ietf-nomcom@lists.elistx.com Message-id: <5C611EA73500FE4C908733811F670B45017D0AD1@RED-MSG-31.redmond.corp.microsoft.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: QUOTED-PRINTABLE Thread-Topic: Issue: Transition rules? Thread-Index: AcOSdTwfaeSkf3BPTjKrtLmiNaZCFQBjrfUw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: X-OriginalArrivalTime: 16 Oct 2003 16:41:41.0360 (UTC) FILETIME=[6056FF00:01C39404] I would like to hear from someone authoritative what constitutes 2727bis's approval - is it IESG approval or ISOC board approval? Once 2727bis is approved, I would like to adopt as much of it as make= s sense. Rich From ietf-nomcom-errors@lists.elistx.com Thu Oct 16 12:45:08 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMU00K04ZULKD@eListX.com> (original mail from mstjohns@mindspring.com) ; Thu, 16 Oct 2003 12:44:45 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMU00K01ZULK4@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 16 Oct 2003 12:44:45 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMU00K01ZUKJY@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 16 Oct 2003 12:44:44 -0400 (EDT) Received: from razorbill.mail.pas.earthlink.net (razorbill.mail.pas.earthlink.net [207.217.121.248]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMU00EGRZUKLA@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 16 Oct 2003 12:44:44 -0400 (EDT) Received: from pcp802150pcs.nrockv01.md.comcast.net ([68.48.85.252] helo=STJOHNS-LAPTOP2.mindspring.com) by razorbill.mail.pas.earthlink.net with asmtp (TLSv1:RC4-SHA:128) (Exim 3.33 #1) id 1AABER-000390-00; Thu, 16 Oct 2003 09:44:14 -0700 Date: Thu, 16 Oct 2003 12:44:05 -0400 From: Michael StJohns Subject: RE: Issue: Transition rules? X-Sender: mstjohns@mindspring.com@pop.mindspring.com To: Richard Draves , ietf-nomcom@lists.elistx.com Message-id: <6.0.0.20.2.20031016124250.03702eb8@pop.mindspring.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.20 (Beta) Content-type: text/plain; format=flowed; charset=us-ascii X-ELNK-Trace: 9f6ded143da542dc9c7f779228e2f6aeda0071232e20db4ddc63655c97f40f33f94dbf242a78373a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: I'm pretty sure we've come to the consensus that its ISOC board approval due to the issues with liability coverage. With respect to adoption - just make sure what you adopt doesn't conflict with 2727... Later, Mike At 12:41 10/16/2003, Richard Draves wrote: >I would like to hear from someone authoritative what constitutes >2727bis's approval - is it IESG approval or ISOC board approval? > >Once 2727bis is approved, I would like to adopt as much of it as makes >sense. > >Rich > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: From ietf-nomcom-errors@lists.elistx.com Thu Oct 16 13:15:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMV00M04114NU@eListX.com> (original mail from galvin+ietf-nomcom@elistx.com); Thu, 16 Oct 2003 13:10:16 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMV00M01114NS@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 16 Oct 2003 13:10:16 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMV00M01113NQ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 16 Oct 2003 13:10:15 -0400 (EDT) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMV00HEU1121L@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 16 Oct 2003 13:10:15 -0400 (EDT) Date: Thu, 16 Oct 2003 13:09:44 -0400 (EDT) From: James M Galvin Subject: Re: Issue: Transition rules? In-reply-to: <6.0.0.20.2.20031014121714.02efc258@pop.mindspring.com> X-X-Sender: galvin@three.elistx.com To: Michael StJohns Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Tue, 14 Oct 2003, Michael StJohns wrote: >However, I presume you are suggesting we document the "edge case" of >whether or not an operational NOMCOM is required to employ a revised >document if one is published during its tenure? No. The problem is that there are possible edge conditions between the two documents (2727 vs 2727bis). One example right off the top: 2727bis allows a challenge to the selection process for the Nomcom and sets a 1 week period after the selection has been made for that challenge, 2727 doesn't have such a concept. Say 2727bis is approved during the one week period (which it won't be) - which rule applies? Say its approved one month later - an argument could be made that challenges could occur from the approval date for the one week. An edge case that has no prima facia resolution. If we adopt the rule that a new document is "in force" as soon as it is approved, then we also need Harald's earlier suggestion that the new document applies from that moment forward, i.e., you don't revisit earlier decisions. So, while agree there are "significant" differences between rfc2727 and rfc2727bis, I don't see the problem in your example. Specifically, if 2727bis is approved during what would be the one week challenge period the answer is there is no challenge. The event that would have permitted the challenge has passed and was completed under the old rules. Therefore the new rule of a challenge period does not apply. Jim From ietf-nomcom-errors@lists.elistx.com Thu Oct 16 13:25:07 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMV000041F088@eListX.com> (original mail from galvin+ietf-nomcom@elistx.com); Thu, 16 Oct 2003 13:18:36 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMV000011F086@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 16 Oct 2003 13:18:36 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMV000011EZ84@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 16 Oct 2003 13:18:36 -0400 (EDT) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMV00HGM1EZ1L@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 16 Oct 2003 13:18:35 -0400 (EDT) Date: Thu, 16 Oct 2003 13:18:04 -0400 (EDT) From: James M Galvin Subject: Re: Issue: Transition rules? In-reply-to: <2775.1066150976@munnari.OZ.AU> X-X-Sender: galvin@three.elistx.com To: Robert Elz Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Wed, 15 Oct 2003, Robert Elz wrote: | With protocols I believe we all expect that when a revision is | published it will be adopted immediately and implementations | will transition as soon as possible. Huh? You mean that if I have an existing SMTP connection, and a new doc is approved that alters the SMTP dialog, you expect my currently running processes to adapt to the new procedure and enforce the new rules? Of course not. The point is, when a revision is approved it is presumed to be the authority from that point forward. Does that mean we sit in judgement of those who don't *immediately* upgrade? Of course not. When transition is an issue we account for the explicitly in protocols. We either ensure backward compatibility (to the greatest extent possible) in the new protocol or we accept that there will be two valid protocols for a period of time and we deal with it in some other way. The principle is still that the new document is the authority. Why shouldn't that be the case here with the additional caveat that we don't revisit earlier decisions? In essense, not revisiting prior decisions (past events) is the transition plan or backward compatibility. If what you're suggesting is that an existing nomcom should be (metaphorically) killed, and then reconstituted under the new procedures, then fine, that would be a possibility - but I don't think it is one that anyone would consider very seriously. Again, of course not. I'm suggesting the NOMCOM would simply continue as it was but it would adopt the new document rules and procedures from the point that it was approved. Jim From ietf-nomcom-errors@lists.elistx.com Thu Oct 16 14:25:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMV005044283K@eListX.com> (original mail from mstjohns@mindspring.com) ; Thu, 16 Oct 2003 14:15:44 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMV005014273I@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 16 Oct 2003 14:15:44 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMV005014273G@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 16 Oct 2003 14:15:43 -0400 (EDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMV0018Y42604@eListX.com>; Thu, 16 Oct 2003 14:15:43 -0400 (EDT) Received: from pcp802150pcs.nrockv01.md.comcast.net ([68.48.85.252] helo=STJOHNS-LAPTOP2.mindspring.com) by heron.mail.pas.earthlink.net with asmtp (TLSv1:RC4-SHA:128) (Exim 3.33 #1) id 1AACde-0004Tn-00; Thu, 16 Oct 2003 11:14:18 -0700 Date: Thu, 16 Oct 2003 14:12:45 -0400 From: Michael StJohns Subject: Re: Issue: Transition rules? In-reply-to: X-Sender: mstjohns@mindspring.com@pop.mindspring.com To: James M Galvin Cc: ietf-nomcom@lists.elistx.com Message-id: <6.0.0.20.2.20031016140508.036ff558@pop.mindspring.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.20 (Beta) Content-type: text/plain; format=flowed; charset=us-ascii X-ELNK-Trace: 9f6ded143da542dc9c7f779228e2f6aeda0071232e20db4ddff23f5365607ebb3bd798dd389a858f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c References: <6.0.0.20.2.20031014121714.02efc258@pop.mindspring.com> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: At 13:09 10/16/2003, James M Galvin wrote: > Specifically, if >2727bis is approved during what would be the one week challenge period >the answer is there is no challenge. The event that would have >permitted the challenge has passed and was completed under the old >rules. Therefore the new rule of a challenge period does not apply. > >Jim *buzzzz* Wrong answer. For example, under US law, if a change in the law introduces a new cause of action, and that cause of action has a statute of limitations clause, the limitation begins with the effective date of the law, not with the event that was the cause of action - unless explicitly excluded by the law. This is as reasonable an interpretation as the interpretation (you mention) that things this document mentioned that have already happened are not subject to the document. I don't know that we can make this a blanket statement without reviewing in painful details line by line and coming up with a specific implementation guidance that then needs similar approval. Easier by far to just say that this doesn't apply to this nomcom since the panel is now empaneled. Later, Mike From ietf-nomcom-errors@lists.elistx.com Thu Oct 16 14:35:07 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMV006044RBD5@eListX.com> (original mail from galvin+ietf-nomcom@elistx.com); Thu, 16 Oct 2003 14:30:47 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMV006014RBD3@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 16 Oct 2003 14:30:47 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMV006014RBD1@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Thu, 16 Oct 2003 14:30:47 -0400 (EDT) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMV001C44PY04@eListX.com> for ietf-nomcom@lists.elistx.com; Thu, 16 Oct 2003 14:30:46 -0400 (EDT) Date: Thu, 16 Oct 2003 14:29:26 -0400 (EDT) From: James M Galvin Subject: Re: Issue: Transition rules? In-reply-to: <6.0.0.20.2.20031016140508.036ff558@pop.mindspring.com> X-X-Sender: galvin@three.elistx.com To: Michael StJohns Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Thu, 16 Oct 2003, Michael StJohns wrote: At 13:09 10/16/2003, James M Galvin wrote: > Specifically, if >2727bis is approved during what would be the one week challenge period >the answer is there is no challenge. The event that would have >permitted the challenge has passed and was completed under the old >rules. Therefore the new rule of a challenge period does not apply. *buzzzz* Wrong answer. For example, under US law, if a change in the law introduces a new cause of action, and that cause of action has a statute of limitations clause, the limitation begins with the effective date of the law, not with the event that was the cause of action - unless explicitly excluded by the law. *buzzzz* Wrong answer. The cause of action is history. The new rule does not apply. Let's be precise for the sake of discussion. Continuing with your example isn't this the sequence of events: 1. NOMCOM members selected. Under old rules we are now done with this step. Under news rules a one week challenge period would begin but since the new rules are not in effect there is no challenge period. 2. New rules are approved. Since the new rules were approved after the NOMCOM was selected that decision is history. A challenge period does not spring into existence with the approval of the new rules because the challenge period would only exist if the decision that supported the challenge period was made under the new rules. Under the old rules there is no challenge period. 3. One week after NOMCOM selected. Just another day.... I don't see the problem. Jim From ietf-nomcom-errors@lists.elistx.com Fri Oct 17 06:25:03 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMW00M04CLN8E@eListX.com> (original mail from kre@munnari.OZ.AU); Fri, 17 Oct 2003 06:17:47 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMW00M01CLM83@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 17 Oct 2003 06:17:46 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMW00M01CLL81@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 17 Oct 2003 06:17:45 -0400 (EDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMW00M0VCLA0A@eListX.com>; Fri, 17 Oct 2003 06:17:44 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h9HAGtA22542; Fri, 17 Oct 2003 17:16:59 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h9HAGXh09002; Fri, 17 Oct 2003 17:16:37 +0700 (ICT) Date: Fri, 17 Oct 2003 17:16:33 +0700 From: Robert Elz Subject: Re: Issue: Transition rules? In-reply-to: To: James M Galvin Cc: ietf-nomcom@lists.elistx.com Message-id: <28712.1066385793@munnari.OZ.AU> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Date: Thu, 16 Oct 2003 13:18:04 -0400 (EDT) From: James M Galvin Message-ID: | The point is, when a revision is approved it is presumed to be the | authority from that point forward. Yes, but only for new things - we never expect something that is already in progress to suddenly adopt the new procedures. We don't for protocols, and shouldn't for procedures - in both cases, except where there is something that explicitly says what should happen. The best thing to do here is simply for the existing nomcom to agree to follow the new doc as much as it can. kre From ietf-nomcom-errors@lists.elistx.com Fri Oct 17 08:55:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMW00704JT2UI@eListX.com> (original mail from galvin+ietf-nomcom@elistx.com); Fri, 17 Oct 2003 08:53:26 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMW00701JT1UF@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 17 Oct 2003 08:53:26 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMW00701JT1UD@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 17 Oct 2003 08:53:25 -0400 (EDT) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMW0064RJT0JJ@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 17 Oct 2003 08:53:25 -0400 (EDT) Date: Fri, 17 Oct 2003 08:52:49 -0400 (EDT) From: James M Galvin Subject: Re: Issue: Transition rules? In-reply-to: <28712.1066385793@munnari.OZ.AU> X-X-Sender: galvin@three.elistx.com To: Robert Elz Cc: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: On Fri, 17 Oct 2003, Robert Elz wrote: The best thing to do here is simply for the existing nomcom to agree to follow the new doc as much as it can. Agreed. Jim From ietf-nomcom-errors@lists.elistx.com Fri Oct 17 10:35:03 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMW00E04O4XMQ@eListX.com> (original mail from mstjohns@mindspring.com) ; Fri, 17 Oct 2003 10:26:57 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMW00E01O4XMO@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 17 Oct 2003 10:26:57 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMW00E01O4WMN@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 17 Oct 2003 10:26:57 -0400 (EDT) Received: from firecrest.mail.pas.earthlink.net (firecrest.mail.pas.earthlink.net [207.217.121.247]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMW006MUO4WJH@eListX.com>; Fri, 17 Oct 2003 10:26:56 -0400 (EDT) Received: from pcp802150pcs.nrockv01.md.comcast.net ([68.48.85.252] helo=STJOHNS-LAPTOP2.mindspring.com) by firecrest.mail.pas.earthlink.net with asmtp (TLSv1:RC4-SHA:128) (Exim 3.33 #1) id 1AAVYe-00041p-00; Fri, 17 Oct 2003 07:26:24 -0700 Date: Fri, 17 Oct 2003 10:26:17 -0400 From: Michael StJohns Subject: Re: Issue: Transition rules? In-reply-to: X-Sender: mstjohns@mindspring.com@pop.mindspring.com To: James M Galvin , Robert Elz Cc: ietf-nomcom@lists.elistx.com Message-id: <6.0.0.20.2.20031017102402.03b68f78@pop.mindspring.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.20 (Beta) Content-type: text/plain; format=flowed; charset=us-ascii X-ELNK-Trace: 9f6ded143da542dc9c7f779228e2f6aeda0071232e20db4d21c43dc8f9857a07bd8e955ed0fa38f4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c References: <28712.1066385793@munnari.OZ.AU> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Agreed - but its THEIR choice at this point - not the Nomcom WG, IAB, or ISOCs. They could agree to follow the new rules THAT DON'T CONFLICT WITH 2727 even prior to approval by the ISOC. Later, Mike At 08:52 10/17/2003, James M Galvin wrote: >On Fri, 17 Oct 2003, Robert Elz wrote: > > The best thing to do here is simply for the existing nomcom to agree > to follow the new doc as much as it can. > >Agreed. > >Jim > > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: From ietf-nomcom-errors@lists.elistx.com Sat Oct 18 09:35:02 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMY00404FYZF3@eListX.com> (original mail from avri@acm.org); Sat, 18 Oct 2003 09:25:47 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMY00401FYYEV@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Sat, 18 Oct 2003 09:25:46 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HMY00401FYYEU@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Sat, 18 Oct 2003 09:25:46 -0400 (EDT) Received: from psg.com (psg.com [147.28.0.62]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HMY0025YFYX9V@eListX.com> for ietf-nomcom@lists.elistx.com; Sat, 18 Oct 2003 09:25:46 -0400 (EDT) Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AAr4y-000Gdk-VJ for ietf-nomcom@lists.elistx.com; Sat, 18 Oct 2003 13:25:13 +0000 Date: Sat, 18 Oct 2003 22:25:24 +0900 From: Avri Doria Subject: Mid discussion update on IESG Issues To: ietf-nomcom@lists.elistx.com Message-id: <88100C62-016E-11D8-9D11-000393CC2112@acm.org> MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII; delsp=yes Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: We are about half through the discussion period, so I thought I would do a recap of where I think we are. I have inserted he brief recap of my impression of the status follow the "DISCUSSION SO FAR:" under each issue description (sent originally) This is _not_ a consensus call, just a review of current status. Though I do recommend that the editorial nits can be taken care of without further discussion. Should anyone object concerning any of these nits, please speak up. I also suggest that proposed clarifying text for those issues needing clarification be submitted to the list so it can be agreed upon. Issues that seem to still require work are: 1, 2, 10, 17, 24 Though all issues are still open to comment and discussions And please let me know if I got any of the recap wrong. thanks a. ----------------------------- Issue 1-3 are 'showstopper" Issues that must be resolved before the document will be allowed to proceed. ------------------ IESG Issue 1: ------------------ > The first 2 substantive issue was raised by Margaret Wasserman: > ------------------------------------------------------------- >> In section 2: >> The nominating committee will be given the title of the positions >> to be reviewed and a brief description of the desirable set of >> qualifications of the candidate that is nominated to fill each >> position. > > Is this information sent publicly or privately? There are two issues > here: > > 1) I think that the "description of the desirable set of > qualifications" > should be posted publicly, along with the list of open positions when > the call for nominations is sent. > > 2) The IESG and IAB should know, unambiguously, whether or not the > information will be publicly disseminated before providing it. > History: This issue was not discussed Questions: Should it be mandatory that the required qualifications list be made public? If not, should the required qualifications list be confidential? DISCUSSION SO FAR: 5 comments The information should not be confidential. It should be published. Recommended wording change submitted on the list: OLD NEW: 14. The Chair obtains the list of IESG and IAB positions to be reviewed and a description of the desirable qualifications for those positions. This information is announced, along with a solicitation for names of volunteers from the IETF community willing to serve on the nominating committee. NEW: 14. The Chair obtains the list of IESG and IAB positions to be reviewed and a description of the desirable qualifications for those positions. This information is announced on ietf-announce@ietf.org, along with a solicitation for names of volunteers from the IETF community willing to serve on the nominating committee. Is this wording acceptable? > ------------------------------------------------------------------ ----------------- IESG Issue 2 ----------------- > raised by Margaret Wasserman: >> From section 3, subsection 8: >> It is consistent with these rules for the announcements of a >> resignation, of the existence of a mid-term vacancy, and of the >> confirmed candidates to all occur at the same time as long as the >> actual sequence of events that occurred did so in the following >> order. >> >> * The nominating committee completes the advice and consent >> process for the candidate already sitting on another body. >> >> * The newly confirmed candidate resigns from their current >> position. >> >> * The body with the new mid-term vacancy requests that the >> nominating committee fill the position. >> >> * The Executive Director of the IETF informs the nominating >> committee of the mid-term vacancy. >> >> * The nominating committee acts on the request to fill the >> mid-term vacancy > > This section indicates that a position may be vacated and filled > without the community being notified that a position is open. IMO, no > position should be filled without public notice that the position is > open and a public call for nominations. > > I understand one shool of thought that says that this is okay for IAB > positions during the normal selection cycle. Because IAB members > don't have separate responsibilities, it _might_ be okay to pick 6 IAB > members from a candidate pool for 5 open positions, for example. > However, even in this case, the community might want to know if a > person with a particular specialty/area of expertise was moving, so > that folks with that type of expertise could be nominated. > > This section would also be problematic for IESG positions. This could > arise in any case where one IESG position is filled by a sitting IESG > member who is not up for renewal. For example, consider a situation > where the IESG chair does not volunteer for another term and is > replaced by a sitting IESG member who is not up for renewal. Even > though there are two ADs for most areas, the ADs often divide up the > area into logical sections, requiring different expertise for each > position. > > There are also issues with filling any postition according to this > section if it is applied to interim vacancies. For example, the > nomcom should not be empowered to move an IAB member to the IESG to > fill and interim vacancy and replace the IAB member without making a > public call for nominations for the open IAB position. Background: The issue was first brought up http://lists.elistx.com/archives/ietf-nomcom/200303/msg00020.html >>> >>>> >>Insert in section 3 as paragraph 6 and renumber all subsequent >>>> paragraphs: >>>> >>>> "Nomcom-caused Mid-term Vacancies: >>>> >>>> From time to time the Nomcom may propose moving a serving Area >>>> Director or >>>> IAB member from one position to another. (E.g. moving a Transport >>>> AD to >>>> cover O&M). If the serving member is at the end of their normal >>>> term there >>>> is no change in procedures. Otherwise, this is treated as a mid-term >>>> vacancy and mid-term procedures are used with the following >>>> exceptions: >>>> >>>> a) If the vacancy will occur on the IAB due to a move from the IAB >>>> to the >>>> IESG, the Nomcom may, upon confirmation of nominee/IAB member, >>>> submit for >>>> confirmation as part of the normal slate of candidates another >>>> nominee to >>>> complete the term of the departing IAB member. If the Nomcom >>>> declines to >>>> nominate a replacement as part of the annual process, the IAB may, >>>> at any >>>> time after the confirmation of the departing member, ask the Nomcom >>>> to fill >>>> the slot using mid-term procedures. >>>> >>>> b) If the vacancy will occur on the IESG, either as a move to >>>> another IESG >>>> slot or as a move to the IAB, the Nomcom must use mid-term >>>> procedure rules. >>>> Most importantly, they must advertise the vacancy, and must >>>> consider all >>>> new candidates as equitably as any previously considered. The IESG >>>> chair is >>>> responsible for notifying the IETF Executive director of the >>>> vacancy and >>>> who in turn is responsible for asking the Nomcom select the >>>> replacement. >>>> The Nomcom is explicitly barred from proceeding without an explicit >>>> request >>>> from the IESG chair. The term of the nominee shall be for the >>>> remainder of >>>> the term of the vacated position." The recommended text change was never discussed on the list. The issue surrounding the 'poaching' issue was discussed but the discussion centered on the serialization described in 2727bis-07. However, none of the discussions were about the result of moving someone from a non open seat on the IESG to fill an IAB slot and thus having to fill an unannounced IESG slot. Questions: Does the document need to be explicit about treating the replacement of an IESG member in an non open chair differently the the replacement of an IAB member in a non open seat? Do full mid term replacement rules, including public announcement apply to this case? DISCUSSION SO FAR: 8 messages The existing text has been interpreted differently by different commentaries. This is an indication that no matter what the resolution on the substantive issue, the text needs to clarified. Several agree that the vacancy should be treated as a mid-term vacancy with announcement of the vacancy. There is an indication that the case filling an incomplete term IAB seat is different from filling an incomplete term IESG seat. There is an argument that it should not be difficult to move people into different positions and therefore the procedure should allow quasi-simultaneous filling of created openings. Several fixes were suggested: A. It is consistent with these rules for the Nominating Committee to nominate a sitting Area Director to a different Area and simultaneously nominate a new Area Director to the position thus vacated, or to nominate a sitting IAB member to an Area Director position and simultaneously nominate a new IAB member to the position thus vacated. Any other moves between positions must be treated as resignations that create mid-term vacancies. B. Fix: If the type of position (e.g. security AD) was advertised, the Nomcom can take action to fill it from the set of candidates it already has for that type of slot. If the type of position was not advertised (e.g. because it was an off year and there was only one of that type) it must not take action to fill it and it must treat it as a mid-term vacancy. However, once the candidate has accepted appointment to the new position and once the IAB has confirmed them and the announcement has been made, the Nomcom can immediately begin the process of selection for replacement. C. Other fix: Dual Membership on both the IAB and IESG is prohibited. A nominee who accepts appointment to one body automatically vacates their position on the other body not later than noon on the last of the First IETF meeting. As long as the to-be-vacated position type has been advertised, the Nomcom shall take action to fill it. Note: the issue of prohibiting dual membership was discussed previously in the WG and a decision was made to discourage but not prohibit. Status: This issue has not yet been resolved > ---------------------------------------------------------------- ------------------ IESG Issue 3; ------------------ > The third substantive issue was raised by Thomas Narten: > >> Liaisons from the IESG, IAB, and Internet Society Board of >> Trustees are expected to review the operation and executing >> process of the nominating committee and to report any concerns >> or issues to the Chair of the nominating committee immediately. >> If they can not resolve the issue between themselves liaisons >> must report the issue to their respective bodies. If their >> respective body agrees that there is an issue the liaison must >> report it according to the dispute resolution process stated >> elsewhere in this document. > > I worry that there will be problems with the above in practice. In > particular, the text requires that a liaison report problems back to > their respective group (i.e., IESG or IAB) before invoking the formal > dispute resolution mechanism. But confidentiality rules rather limit > what the liaison can say to their body, and in the case where dispute > resolution may need invoking, it seems like details will be > important. I worry that this will create problems in practice, with it > being unclear what can be said. And if that is the case, it is unclear > what value the discussion within the respective I* would actually > have. This is perhaps more a problem for the IESG, since it has no > confirming role, but it seems like a general issue. > > There are ways of dealing with this, but I'm not sure what is best or > what the WG might think. Some initial thoughts: > > - I note that the current wording doesn't mention the obvious, i.e., > have the liaisons and previous chair get together and discuss > before escalating. One could also have the liaison (independently) > decide whether to formally appeal after such a consultation. This > avoids the confidentiality issue and would seem like a necessary > check as part of escalating issues. > > - add some wording saying that confidentiality rules allow sharing of > info as needed to assess whether to file a formal complaint. Background: This particular issue was never discussed, but the issue of confidentiality was frequently discussed in many different contexts. Section 10, Security, discusses the extension of confidentiality to those outside the Nomcom when necessary, though it is not explicit that this extension would also apply to the IAB, IESG or ISOC in the case of Nomcom operational issues. I also note that in the text Thomas quoted, it does state that after reporting the Issues to the chair or committee they only escalate if ' they cannot resolve the issue between themselves'. It is, perhaps, implicit in this that they can and should discuss with the past chair. Questions: Does content need to be added to the text to allow extension of confidentiality to the Liaison in the case of reporting issues having to do with the internal operations of the Nomcom? Does content need to be added to explicitly state that liaisons should consult among themselves and with the past chair before escalating an issue to their respective I-groups? DISCUSSION SO FAR: 1 comment Doing so would blur the lines in confidentiality. Recommendation that the clarification mentioned above be added to the text. > ----------------------------------------------------------------------- > --- Issue 4-26 are not considered 'showstoppers' but should be addressed before sending the document back to the IESG ------------------ IESG Issue 4: ------------------ > Steve Bellovin: > Comment: > The recall section makes no provision or even suggestion that the > Recall Chair verify the putative signers. Note: the Recall Chair would probably not be selected until there was a requirement for a recall committee and would probably be avaialble to verify the signatories. Questions: Should text be added to clarify that signatories must be confirmed to be qualified members of the IETF community according to Nomcom selection rules? If so, should it be done by the IETF Secretariat as is the case in verifying Nomcom volunteers. DISCUSSION SO FAR: 1 comment Yes to both suggestions. ------------------ IESG Issue 5: ------------------ > > Section 5, Point 12 suggests that the committee consult with the > sitting members of the IAB and IESG. I think that consultation with > WG chairs should be suggested. Question: Should WG chairs be added to the list of those who should be consulted? DISCUSSION SO FAR: 5 comments Yes WG chairs should be added. There was one suggestion that editors be added as well. ----------------- IESG Issue 6 ----------------- > > Ted Hardie: > Comment: > I note that the oral tradition section indicates that no person should > serve on both the IESG and IAB, except the IETF Chair who serves on > both by > definition. I believe that there is some lack of clarity on whether > the IAB > Chair's role ex officio in the IESG means she "serves on", and that > this is > probably not the place to resolve that or go into the liaisons from one > body to the other. To capture the same thing, how about: > > "No person should serve both on the IAB and as an Area Director, except > the IETF Chair whose roles as an IAB member and Area Director of the > General Area is set out elsewhere". Question: Should this text, or some other text, replace the current text in A2 DISCUSSION SO FAR: 1 comment The clarification is ok. ----------------- IESG Issue 7 ----------------- > > Thomas Narten: > > If a voting volunteer member is recalled the committee may >> choose to proceed with only 9 voting volunteers at its own >> discretion. In all other cases the Chair must repeat the >> random >> selection process including an announcement of the iteration > >> prior to the actual selection as stated elsewhere in this >> document. > > The above implies to me that the nomcome is required to find a > replacement for a resignation, but is not for a recall. Shouldn't the > nomcom be allowed to also not replace resignations? I.e, I assume that > the nomcom would have the option of filling or not filling any nomcom > opening, regardless of how it occurs. Questions: Is a change to the text required to make the two situation consistent? DISCUSSION SO FAR: 2 comments There was no substantive comment on the issue. ----------------- IESG Issue 8 ----------------- > >> It is consistent with this rule for the nominating committee to >> choose one or more of the currently open positions to which it >> may assign a term greater than 2 years in order to ensure the >> ideal application of this rule in the future. > > s/greater than 2 years/of up to 3 years/ > (right now, in theory, nomcom could pick the length of time, though I > suspect a lot of folk would be surprised if this ever happend...) Questions: Is the editorial change accepted? Is text making it explicit that the maximum assignable term is 3 years needed? DISCUSSION SO FAR: 1 comment No harm in adding clarification ----------------- IESG Issue 9 ----------------- > >> committee. The addition must be approved by all members of the >> committee according to its established voting mechanism. >> Advisors participate as individuals. >> > > "all members" wording implies everyone must agree. What is the intent > here? Is it "must be approved by a quorum of the committee according > to its established voting mechanism"? Note: similar wording appears > elsewhere. Background: Section 4.3 indicates that non volunteers vote on all issues other then candidate selection. Questions: Should the participation of the non volunteers in voting issues be made explicit? Should the non volunteers be excluded from voting on voting rules? DISCUSSION SO FAR: 1 comment A note that I misinterpreted the issue and that the issue concerned the vote needing to be unanimous. The recommendation is that this vote should go by the same rules as expressed elsewhere; i.e there should not be a rule forcing a unanimous vote. Recommendation that the text should be clarified. ----------------- IESG Issue 10 ----------------- > >> conducted. A member may recalled if at least a quorum of all >> committee members agree, including the vote of the member being >> recalled. > > What does this mean? simple majority if there is a quorum? (I ask > because in most cases this document doesn't proscribe rules, leaving > that to the nomcom to decide.) Background: While the document discusses the quorum that must be present for a vote, the actual voting mechanisms are to be be determined by the Nomcom itself. Question: should text be added making an explicit rule for the voting in a Nomcom recall be specified in the document. DISCUSSION SO FAR: 2 comments 2 answers of yes. - suggestion of 2/3 or majority - comment that 2/3 was too stringent. ----------------- IESG Issue 11 ----------------- > >> 4. Confirmed candidates are expected to serve at least a 2 year >> term. > > not consistent with interim appointments Question: Should clarifying text indicate that the Confirmed candidates, chosen by the standard process, as opposed to mid term appointments, be expected to seve at least 2 years. Answers so far: 1 While not necessary clarification would be ok. ----------------- IESG Issue 12 ----------------- > >> First, when there is only one official nominating committee the > > add comma after committee Question: Is the editorial change accepted? DISCUSSION SO FAR: 1 comment Editorial nit ----------------- IESG Issue 13 ----------------- > >> As of the publication of this document the current mechanism is > ^ >> an email message to both the "ietf" and the "ietf-announce" >> mailing lists. > > comma above Question: Is the editorial change accepted? DISCUSSION SO FAR: 1 comment Editorial nit ----------------- IESG Issue 14 ----------------- > > >> None of the Chair, liaisons, or advisors vote on the selection >> of candidates. They do vote on all other issues before the >> committee unless otherwise specified. > > s/specified/specified in this document/? (what is the intent?) Questions: Is the editorial change accepted? Is further explanation necessary indicating that the non volunteers participate in all votes except those dealing with candidate selection? DISCUSSION SO FAR: 1 comment Editorial change should be accepted Further clarification would be ok as 'an overarching statement' (don't think i understand what that means) ----------------- IESG Issue 15 ----------------- > >> 6. A Chair, in consultation with the Internet Society President, >> may appoint a temporary substitute. > > Better to say "... for the Chair position". Question: Is the editorial change accepted? DISCUSSION SO FAR: 1 comment Editorial nit. ----------------- IESG Issue 16 ----------------- > >> If they can not resolve the issue between themselves liaisons > > comma after themselves. Question: Is the editorial change accepted? DISCUSSION SO FAR: 1 comment Editorial nit ----------------- IESG Issue 17 ----------------- > >> The confirmation process must be completed at least one month >> prior to the First IETF. > > s/must/should/ other parts of the document imply should on this topic. Questions; Is this an editorial or content change? Is the change accepted? Answers so far: 2 - both answers: It is content not editorial - 1 answer: without change leaves situation open - 1 answer: intentionally left open Further discussion ? ----------------- IESG Issue 18 ----------------- > >> The term of a nominating committee begins when its members are >> officially announced. The term ends at the Third IETF (not >> three meetings) after the next nominating committee's term >> begins. > > ambigous wording. Reword: > > The term ends at the Third IETF (not three meetings), that is, > the IETF after the next nominating committee's term begins. Question: Is the more explicit rewording accepted? Answers for far: 1 Editorial nit ----------------- IESG Issue 19 ----------------- > > Jon Peterson: > Comment: > The Introduction fastidiously notes that the organization of the IESG > is outside the scope of the document. However, in so far as Section 3 > bullet 3 explains that half of the IESG positions are reviewed by the > NomCom per year, would it make sense to mention at a high level that > IESG members serve in specific Areas, and that the review process is > staggered to preserve continuity and institutional memory within > Areas? This seems like an important detail of the NomCom process to > omit, even if it might change as the IETF changes. I'd note that > Section 3 bullet 3 already has a caveat about future IESG > reorganization, so I'm not sure how it would hurt to talk about the > current IESG structure, in the interests of fully depicting the > existing practice. > Question: Should the discussion in Section 3 bullet 3, be expanded to include a discussion of why 1/2 at a time? Answers so far: 1 Clarification unnecessary but would not be a problem ----------------- IESG Issue 20 ----------------- > Margaret Wasserman: > > Comment: > EDITORIAL: > >> Abstract >> >> The process by which the members of the IAB and IESG are selected, >> confirmed, and recalled is specified. This document is a >> self-consistent, organized compilation of the process as it was known >> at the time of publication. > > Very weak... I also don't think that the last sentence is true, > as this document changes some things. Suggestions: Add a bit > more information (i.e mention the Nominations Commitee?) and remove > "as it was known at the time of publication". Background: this text was never discussed in the working group. Question: Should the second sentence be removed or reworked? DISCUSSION SO FAR: 1 comment No change necessary Though I wonder whether the ongoing discussion under the topic Transition Rules warrants that some clarifying text be inserted here. ----------------- IESG Issue 21 ----------------- > > The section numbering in this document doesn't match usual > conventions. This makes it harder to refer to sections in this > document unambiguously. Question: Should the document be renumbered using a more conventional numbering scheme? DISCUSSION SO FAR: 2 comments Yes, it would be better. ----------------- IESG Issue 22 ----------------- > >> 3. One-half of each of the then current IESG and IAB positions is >> selected to be reviewed each year. > > s/One-half of each of/One-half of/ > s/positions is/positions are/ > >> The intent of this rule to ensure the review of approximately >> one-half of each of the IESG and IAB sitting members each year. > > s/one-half of each of/one-half of/ Discussion: Seems largely editorial. But the added precision does not make the English incorrect. Nor does its removal. question: Is the changed accepted. DISCUSSION SO FAR: 2 comments The change is not necessarily editorial and should not be accepted. ----------------- IESG Issue 23 ----------------- > >> 4. Confirmed candidates are expected to serve at least a 2 year >> term. > > This isn't always true. Replacement candidates may serve > terms of less than two years. Same as issue 11 DISCUSSION SO FAR: 1 comment I should not ask twice. Using comment in 11: clarification is ok. ----------------- IESG Issue 24 ----------------- > >> A term may begin or end no sooner than the >> first day of the meeting and no later than the last day of the >> meeting as determined by the mutual agreement of the currently >> sitting member and the confirmed candidate. The confirmed >> candidate's term may overlap the sitting member's term during the >> meeting as determined by their mutual agreement. > > How does this apply to IAB terms? In the case where there is > more than one new IAB member, I don't think that it is > defined which IAB member each new member is replacing. Questions: Should the question of starting time for IAB be separated from the question of IESG? Should it be pointed out that since IAB members do not replace specific IAB members, it is consistent that new IAB members may overlap with retiring IAB members? DISCUSSION SO FAR: 2 comments - 1 that the IAB should be a separate case and should happen at the end of the week - 1 that the current, flexible, "during the week" handoff be retained ----------------- IESG Issue 25 ----------------- >> In section 4, subsection 7: >> Liaisons from the IESG, IAB, and Internet Society Board of >> Trustees are expected to review the operation and executing >> process of the nominating committee and to report any concerns > > There is a mention here of a liaison from the ISOC board. > But, there in section 4.3 there is a list of nomcom members > that indicates how they are selected, and the ISOC liaison > is not listed. Clarification: The first mention of the possible appointment of a Internet Society liaison is in 4.9 There seem to be two issues here, - an editorial one dealing with a forward reference and the fact that there may not be a ISOC liaison - an issue of whether the Nomcom procedures should specify how the ISOC Trustees choose a liaison if they decide to offer one. Possible remedy to the editorial issue: - move the content of 4.9 into 4.3 and edit the text in 4.7 to add the phrase 'if one has been appointed', right after Trustees. Question: should this or some other change be made to the text? Discussion of the second issue: Generally the rough consensus of the group was that the way the IAB or IESG made their decisions was not to be defined by this document (though there was significant discussion around the IAB role as a confirming body). Does this rough consensus also apply to the Internet Society Trustees should they decide to send a liaison? We should note that part of the reason Internet society Liaisons were made discretionary is that the IETF was not viewed as having the mandate to dictate actions to the Internet Society Trustees in its BCPs. Question: Should text be added describing how the Internet Society Trustees pick their liaison, should they decide to send one? DISCUSSION SO FAR: 1 comment Yes to the editorial change. But the selection process is up to ISOC not the IETF ----------------- IESG Issue 26 ----------------- > > The organization of this document seems to result in repeating > a lot of information. There are also a lot of forward > references. This makes it difficult to find the part(s) of > the document that apply to a particular part of the process. > > Question: Should the draft be restructured prior to resubmission? DISCUSSION SO FAR: 1 comment Recommends against From ietf-nomcom-errors@lists.elistx.com Mon Oct 20 18:35:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HN200504UJUUU@eListX.com> (original mail from harald@alvestrand.no); Mon, 20 Oct 2003 18:31:06 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HN200501UJUUS@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 20 Oct 2003 18:31:06 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HN200501UJTUR@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 20 Oct 2003 18:31:05 -0400 (EDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HN20051AUJTTY@eListX.com> for ietf-nomcom@lists.elistx.com; Mon, 20 Oct 2003 18:31:05 -0400 (EDT) Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9710561C17 for ; Tue, 21 Oct 2003 00:30:31 +0200 (CEST) Date: Mon, 20 Oct 2003 11:16:20 -0700 From: Harald Tveit Alvestrand Subject: IESG issue 10 (Re: Mid discussion update on IESG Issues) In-reply-to: <88100C62-016E-11D8-9D11-000393CC2112@acm.org> To: ietf-nomcom@lists.elistx.com Message-id: <18120756.1066648580@localhost> MIME-version: 1.0 X-Mailer: Mulberry/3.1.0b8 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <88100C62-016E-11D8-9D11-000393CC2112@acm.org> List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Since this issue was listed as needing further discussion, I'll put my two cents in..... --On 18. oktober 2003 22:25 +0900 Avri Doria wrote: > ----------------- > IESG Issue 10 > ----------------- > >> >>> conducted. A member may recalled if at least a quorum of all >>> committee members agree, including the vote of the member being >>> recalled. >> >> What does this mean? simple majority if there is a quorum? (I ask >> because in most cases this document doesn't proscribe rules, leaving >> that to the nomcom to decide.) > > Background: While the document discusses the quorum that must be > present for a vote, the actual voting mechanisms are to be be determined > by the Nomcom itself. > > Question: should text be added making an explicit rule for the voting in > a Nomcom recall be specified in the document. > > DISCUSSION SO FAR: 2 comments > > 2 answers of yes. > - suggestion of 2/3 or majority > - comment that 2/3 was too stringent. This is another piece of code that has never been run. I was reading "at least a quorum has to agree" as "the number of people required to make a quorum has to agree". That number is 75% of the nomcom according to section 5 bullet 6. I'm not averse to saying 2/3, but a simple majority of a minimum quorum (approx 38%) doesn't seem right to me. IMHO, removing a nomcom member SHOULD be a crisis mesaure, not a routine matter. But since my reading wasn't what other people read into it, I agree that the issue needs to be clarified. Suggested change, also fixing the grammar nit: OLD: A member may recalled if at least a quorum of all committee members agree, including the vote of the member being recalled. NEW: A member may be recalled if at least a quorum of all committee members (defined above as 75%) vote for the recall. Harald From ietf-nomcom-errors@lists.elistx.com Fri Oct 24 10:45:01 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HN900504N7AD5@eListX.com> (original mail from avri@acm.org); Fri, 24 Oct 2003 10:35:34 -0400 (EDT) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HN900501N79CV@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 24 Oct 2003 10:35:33 -0400 (EDT) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HN900501N79CO@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Fri, 24 Oct 2003 10:35:33 -0400 (EDT) Received: from psg.com (psg.com [147.28.0.62]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HN9003E5N78W5@eListX.com> for ietf-nomcom@lists.elistx.com; Fri, 24 Oct 2003 10:35:32 -0400 (EDT) Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AD31j-000N4u-2w for ietf-nomcom@lists.elistx.com; Fri, 24 Oct 2003 14:34:55 +0000 Date: Fri, 24 Oct 2003 16:35:03 +0200 From: Avri Doria Subject: Discussion period has ended In-reply-to: <88100C62-016E-11D8-9D11-000393CC2112@acm.org> To: ietf-nomcom@lists.elistx.com Message-id: <40F284E0-062F-11D8-A96B-000393CC2112@acm.org> MIME-version: 1.0 (Apple Message framework v552) X-Mailer: Apple Mail (2.552) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: Well the timed discussion has ended, but we still have not resolved the still open issues, including 2 of those that are gating issues for the IESG. i.e. Issues 1, 2, 10, 17, 24. The current status can be found in: http://lists.elistx.com/archives/ietf-nomcom/200310/msg00090.html At this point I will request a meeting slot at IETF58 so that these issues can be discussed and hopefully proposed solutions can be proposed. Of course it would be best if the discussions continues on line. I also propose that the editor take the other issues and incorporate changes in the draft so that these can also be open to review in Minn. Thanks a. From ietf-nomcom-errors@lists.elistx.com Mon Oct 27 11:26:37 2003 Return-Path: Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HNF00E04BU805@eListX.com> (original mail from galvin+ietf-nomcom@elistx.com); Mon, 27 Oct 2003 11:15:44 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HNF00D01BU6ZZ@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 27 Oct 2003 11:15:42 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0HNF00D01BU5ZY@eListX.com> for ietf-nomcom@elist.lists.elistx.com (ORCPT ietf-nomcom@lists.elistx.com); Mon, 27 Oct 2003 11:15:41 -0500 (EST) Received: from localhost (one.elistx.com [209.116.252.130]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HNF008M9BU3FS@eListX.com> for ietf-nomcom@lists.elistx.com; Mon, 27 Oct 2003 11:15:40 -0500 (EST) Date: Mon, 27 Oct 2003 11:14:25 -0500 (EST) From: James M Galvin Subject: submission of draft-ietf-nomcom-2727bis-08.txt X-X-Sender: galvin@three.elistx.com To: ietf-nomcom@lists.elistx.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII List-Owner: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Help: , List-Id: I have submitted draft-08 to internet-drafts, so it should be distributed sometime this week. Enclosed below is a diff of all the changes, except for page headings and rule renumbering that resulted from moving the ISOC liaison rule inside the rule about the composition of the NOMCOM. All changes are subject to final approval by the working group. If you would prefer something different than what I included it would be a big help if you could propose a specific alternative. No changes were included for the following issues which are still considered unresolved: 1, 2, 3, 10, 17, 24 Avri, I think you meant to include Issue 3 in the unresolved list. If I got that wrong I apologize and I'll include the change in the next revision. No changes were included for the following issues: 19, 20, 21, 22 There was a suggestion to "renumber" the document. I'm not opposed to this but as far as I can tell this is not easy to do with xml2rfc. I don't claim to be an expert with xml2rfc so if someone can tell me how to do this easily (perhaps I'm overlooking a feature) I would appreciate it. What I understand is that to get the rules numbered automatically with the section number included on the rule I would need to use nested sections. But as far as I can tell to do that I need to give each rule a "name," which would be a nightmare in my opinion. Right now the rules are created as a list inside a section. Maintaining numbers manually is doable but I would only be willing to do that as part of the final edit, literally just before submission to the IESG. Thanks, Jim -------- cut here ISSUE 11 (and 23): 312a313,316 > The term of a confirmed candidate selected according to the > mid-term vacancy rules may be less than 2 years, as stated > elsewhere in this document. > ISSUE 8: 315c319 < may assign a term greater than 2 years in order to ensure the --- > may assign a term of not more than 3 years in order to ensure the 321,323c325,327 < and those sitting) to which it may assign a term greater than 2 < years to ensure that all such members will not be reviewed at the < same time. --- > and those sitting) to which it may assign a term of not more than > 3 years to ensure that all such members will not be reviewed at > the same time. ISSUE 12: 349c353 < First, when there is only one official nominating committee the --- > First, when there is only one official nominating committee, the ISSUE 13: 538c542 < As of the publication of this document the current mechanism is --- > As of the publication of this document, the current mechanism is ISSUE 18: 587,588c587,588 < three meetings) after the next nominating committee's term < begins. --- > three meetings), i.e., the IETF meeting after the next > nominating committee's term begins. 621c621 < volunteers, 2 liaisons, and an advisor. --- > volunteers, 3 liaisons, and an advisor. ISSUE 9: 625,627c625,627 < committee. The addition must be approved by all members of the < committee according to its established voting mechanism. < Advisors participate as individuals. --- > committee. The addition must be approved by the committee > according to its established voting mechanism. Advisors > participate as individuals. 632,634c632,634 < approved by all members of the committee according to its < established voting mechanism. Liaisons participate as < representatives of their respective organizations. --- > approved by the committee according to its established voting > mechanism. Liaisons participate as representatives of their > respective organizations. ISSUE: 25: 644a645,647 > The Internet Society Board of Trustees may appoint a liaison to > the nominating committee at its own discretion. > ISSUE 14: 650c653 < committee unless otherwise specified. --- > committee unless otherwise specified in this document. ISSUE 15: 692c695 < may appoint a temporary substitute. --- > may appoint a temporary substitute for the Chair position. ISSUE 25: 722,724d724 < Liaisons from the IESG, IAB, and Internet Society Board of < Trustees are expected to review the operation and executing < process of the nominating committee and to report any concerns ISSUE 16: 733,738c733,741 < or issues to the Chair of the nominating committee immediately. < If they can not resolve the issue between themselves liaisons < must report the issue to their respective bodies. If their < respective body agrees that there is an issue the liaison must < report it according to the dispute resolution process stated < elsewhere in this document. --- > Liaisons from the IESG, IAB, and Internet Society Board of > Trustees (if one was appointed) are expected to review the > operation and executing process of the nominating committee and > to report any concerns or issues to the Chair of the nominating > committee immediately. If they can not resolve the issue > between themselves, liaisons must report the issue to their > respective bodies. If their respective body agrees that there > is an issue the liaison must report it according to the dispute > resolution process stated elsewhere in this document. ISSUE 25: 755,758c758 < 9. The Internet Society Board of Trustees may appoint a liaison to < the nominating committee. < < 10. An advisor is responsible for such duties as specified by the --- > 9. An advisor is responsible for such duties as specified by the ISSUE 16: 769c769 < can not resolve the issue between themselves the prior year's --- > can not resolve the issue between themselves, the prior year's ISSUE 9: 1031,1032c1031,1032 < the committee. The rule must be approved by all members of the < committee according to its established voting mechanism. --- > the committee. The rule must be approved by the committee > according to its established voting mechanism. ISSUE 7: 1129,1134c1129,1134 < If a voting volunteer member is recalled the committee may < choose to proceed with only 9 voting volunteers at its own < discretion. In all other cases the Chair must repeat the random < selection process including an announcement of the iteration < prior to the actual selection as stated elsewhere in this < document. --- > If a voting volunteer member is recalled, regardless of the > circumstances, the committee may choose to proceed with only 9 > voting volunteers at its own discretion. In all other cases the > Chair must repeat the random selection process including an > announcement of the iteration prior to the actual selection as > stated elsewhere in this document. ISSUE 16: 1153c1153 < between themselves the prior year's Chair must report it --- > between themselves, the prior year's Chair must report it ISSUE 5: 1224c1224,1225 < Directors. --- > Directors, and working group chairs, especially those in the > areas with open positions. ISSUE 4: 1477a1478,1482 > The IETF Secretariat is responsible for confirming that each > signatory is qualified to be a voting member of a nominating > committee. A valid petition must be signed by at least 20 > qualified signatories. > EDITORIAL CHANGE NOT LISTED ANYWHERE: 1610,1611c1610,1611 < all times except that the only voting volunteers vote on a < candidate selection. --- > all times except that only voting volunteers vote on a candidate > selection. ISSUE 6: 1923,1924c1923,1925 < 2. No person should serve on both the IESG and the IAB concurrently, < except the IETF Chair who serves on both bodies by definition. --- > 2. No person should serve both on the IAB and as an Area Director, > except the IETF Chair whose roles as an IAB member and Area > Director of the General Area are set out elsewhere.