RE: draft-klensin-nomcom-term-00.txt

2005-07-27 Thread James M. Polk
John Why is this a no-op for the reasons you state? You're rationale is good, yet past experience shows the following to be true: that if a candidate is a sitting AD who wants the position again, why would they have ever be replaced? The opposite of this has happened within the last few

RE: draft-klensin-nomcom-term-00.txt

2005-07-27 Thread John C Klensin
James, Now I'm going to need to be a little cynical... --On Wednesday, 27 July, 2005 18:44 -0500 "James M. Polk" <[EMAIL PROTECTED]> wrote: > How about a NONCOM review situation roughly such as this: > > if there is more than one candidate that can do the AD > position for a particular area, if

RE: draft-klensin-nomcom-term-00.txt

2005-07-27 Thread James M. Polk
At 06:56 PM 7/27/2005 -0400, John C Klensin wrote: Phillip and Joel, --On Wednesday, 27 July, 2005 13:32 -0700 "Hallam-Baker, Phillip" <[EMAIL PROTECTED]> wrote: I'd like to see some other options considered. How about a NONCOM review situation roughly such as this: if there is more than on

RE: draft-klensin-nomcom-term-00.txt

2005-07-27 Thread John C Klensin
Phillip and Joel, --On Wednesday, 27 July, 2005 13:32 -0700 "Hallam-Baker, Phillip" <[EMAIL PROTECTED]> wrote: >> My biggest worry is the one piece of structure that has no >> wiggle room. As >> defined, if the Nomcom in phase 1 decides not to reappoint >> the incumbent, >> there is no way t

Re: draft-klensin-nomcom-term-00.txt

2005-07-27 Thread Spencer Dawkins
Hi, Bill, Thanks for the quick crank through the data - it's pretty interesting, and especially valuable for discussion of this draft. Spencer (p.s. Bill pointed out in a private e-mail that the input dataset he is using seems to undercount General Area ADs pretty seriously - Fred Baker sho

RE: draft-klensin-nomcom-term-00.txt

2005-07-27 Thread Hallam-Baker, Phillip
> My biggest worry is the one piece of structure that has no > wiggle room. As > defined, if the Nomcom in phase 1 decides not to reappoint > the incumbent, > there is no way to recover if that turns out not to work. I > like the idea > of considering incumbents on their own. But I can not

Motivation for draft-klensin-nomcom-term-00.txt and draft-klensin-stds-review-panel-00.txt

2005-07-27 Thread John C Klensin
Hi. As the perpetrator, I want to make several observations about the comments so far. I'm going to divide them into two (or maybe three) parts, with different subject lines. It might be a while before you see the others -- I'm trying to get some other things done this week including a couple of

RE: calendar file for IETF

2005-07-27 Thread John W Noerenberg II
At 1:38 PM -0400 7/25/05, Brian Rosen wrote: So, I just had to try it, even though my company insists on MS Exchange for calendars. Of course it didn't work, and I never expected it to work. However, the error message is at least amusing: This error can appear if you have attempted to save a

Re: calendar file for IETF

2005-07-27 Thread Marshall Eubanks
On Tue, 26 Jul 2005 16:41:43 -0400 Bill Fenner <[EMAIL PROTECTED]> wrote: > > Just for fun, you could try http://rtg.ietf.org/~fenner/ietf/ietf-63.ics ; > this is a completely independent implementation of the same mapping so > may have a completely different failure mode ;-) > This works like

Re: calendar file for IETF

2005-07-27 Thread Cyrus Daboo
Hi Eliot, --On July 27, 2005 8:04:17 AM +0200 Eliot Lear <[EMAIL PROTECTED]> wrote: I couldn't agree with you more regarding multiple overlapping events. They're all designed for the case where one might double-book, and even on occasion triple book, but 8 or 9 events? None of them deal with t

Re: draft-klensin-nomcom-term-00.txt

2005-07-27 Thread Bill Fenner
>P.S. - being curious: A quick analysis of http://www.ietf.org/iesg_mem.html, counting terms by number of IETF meetings since that's how they're represented there, results in the following answers for the IESG. The IAB history page isn't as easy to analyze in the same way but someone certainly c

Re: draft-klensin-nomcom-term-00.txt

2005-07-27 Thread John Leslie
Someone has been kind enough to point out to me in private email that my reading skills are deficient. :^( Specifically, the draft says: " " At the end of this phase, the nomcom submits the list of returning " candidates to the IAB as usual. The IAB makes its decision and the " choices are

Re: draft-klensin-nomcom-term-00.txt

2005-07-27 Thread Jeffrey I. Schiller
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 When I served as an AD, one of the things that would happen around NOMCOM time is people would come to me and ask if I was "re-upping" because they would not put their name in if I was. This probably resulted in some of the best alternative candidates

Re: calendar file for IETF

2005-07-27 Thread Bill Fenner
>Why would you want to have a calender without timezones?? Mostly for clients with bad user interfaces - e.g., old Apple iCal which didn't let you set the display time zone differently from the system time zone, or web-based calendar servers that don't allow the visitor to set the display time zo

Re: draft-klensin-nomcom-term-00.txt

2005-07-27 Thread Jeffrey Altman
There is one thing and one thing only that I believe term limits are good for: weakening the power of a body by reducing its experience level Do we really believe that the IESG and IAB are too powerful? Do we really want to ensure that the average level of experience on the IESG and IAB

Re: draft-klensin-nomcom-term-00.txt

2005-07-27 Thread Ralph Droms
Brian - while I haven't thought through all of the implications of the process in draft-klensin-nomcom-term-00.txt, I don't think the two-stage process will necessarily significantly length then process. The proposed process would require re-shuffling of of specific tasks, but I don't think it fun

Re: draft-klensin-nomcom-term-00.txt

2005-07-27 Thread John Leslie
Brian E Carpenter <[EMAIL PROTECTED]> wrote: > Spencer Dawkins wrote: > >>If there is community consensus that this draft proposes something >>reasonable, would we give the draft to the incoming NOMCOM as part of >>their instructions and perform a BCP 93 process experiment? > > in answer to you

Re: draft-klensin-nomcom-term-00.txt

2005-07-27 Thread John Leslie
Joel M. Halpern <[EMAIL PROTECTED]> wrote: > > My biggest worry is the one piece of structure that has no wiggle room. > As defined, if the Nomcom in phase 1 decides not to reappoint the > incumbent, there is no way to recover if that turns out not to work. I must disagree. This "decisio

Re: draft-klensin-nomcom-term-00.txt

2005-07-27 Thread Eliot Lear
Spencer, I agree that it takes time to learn the job. That is one reason to have staggered terms with two ADs per area. But I have major problems with other portions of the draft. For one, a major reason the NOMCOM sees a dirth of candidates is the major commitment required to do the job (be t

Re: draft-klensin-stds-review-panel-00.txt

2005-07-27 Thread Brian E Carpenter
Spencer Dawkins wrote: I have been waiting for a proposal like this one (available from http://www.ietf.org/internet-drafts/draft-klensin-stds-review-panel-00.txt) since the SIRS experiment in 2003. But, before I start commenting ... Would this draft be in scope for Newtrk, or is it IETF Discu

Re: draft-klensin-nomcom-term-00.txt

2005-07-27 Thread Brian E Carpenter
Spencer, I haven't fully analyzed the proposal yet, so I will refrain from substantive comment. However, in answer to your question, I'm sure the answer is no, because the two-stage process suggested in the draft will add a significant number of weeks to the process, and we would almost certainl

Re: draft-klensin-nomcom-term-00.txt

2005-07-27 Thread Joel M. Halpern
I have to disagree somewhat with this line suggesting stricter limits on serving duration. I agree that a lack of bench strength is a real problem that should be addressed. I suspect that we may have more bench strength than we think. I strongly suspect that with some of the other changes being

Re: draft-klensin-nomcom-term-00.txt

2005-07-27 Thread Spencer Dawkins
I too like this draft and agree that having most IESG members serve for two terms is ideal and making it more the exception that people serve for three or four terms. I also like the flexibility it gives the NOMCOM without creating strict term limits. When someone is "needed" for more than tw

Re: calendar file for IETF

2005-07-27 Thread Elwyn Davies
Absolutely... Be that as it may, I was intrigued as to why Thunderbird did such a different job on the two files. A quick look at the code did not help. Anyway thanks for the effort.. very useful! Regards, Elwyn Eliot Lear wrote: Bill, I couldn't agree with you more regarding multiple ov

Re: calendar file for IETF

2005-07-27 Thread Iljitsch van Beijnum
On 27-jul-2005, at 2:23, Bill Fenner wrote: One important (IMHO) issue is that Bill's ics does not use timezone info for the times. This was a conscious decision. I think the obvious answer is to have two versions, one with timezone and one without. Why would you want to have a calender