updated calendar file for IETF
Same location: http://www.ofcourseimright.com/~lear/ietf63.ics This one has the following changes: - proper quoting (RFC 2445). - published agendas are now included - URLs to WG Charters are now included - several schedule changes - room numbers are now included Again, use at own risk. This calendar does not merge 1 hour meetings. If you want that, see Bill Fenner's message to the IETF discussion list. Similarly so if your calendar program barfs on timezones. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: calendar file for IETF
Bill, 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 that correctly. I could go on and on about what these Calendar programs don't do, but as I'm not going to fix them... Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-klensin-nomcom-term-00.txt
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 two terms, what does that say about the state of their area? The IETF is based on the commitment of community participation, rather than the brilliance of individual leadership. If we do not have multiple, acceptable choices for an AD slot, then we have a deeper problem with the Area (and/or with the job of being AD, of course.) What would happen if the term limit were firm, with no exceptions? d/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-klensin-nomcom-term-00.txt
Spencer
Let me add my agreement to this ID as a good idea with balance.
At 05:18 PM 7/26/2005 -0500, Spencer Dawkins wrote:
This draft (available at
http://www.ietf.org/internet-drafts/draft-klensin-nomcom-term-00.txt)
does a reasonable job of balancing between current-generation leadership
continuity and next-generation leadership development.
I would like to see this ID become one form of guidance for the next NOMCOM
(as Spencer offers below), acknowledging this effort has not reached
community consensus to date.
If I read RFC 3777 correctly, we will be assembling the next NOMCOM very
soon ("at least two months before the Third IETF"). So, I'm wondering...
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?
Spencer
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
cheers,
James
***
Truth is not to be argued... it is to be presented.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-klensin-nomcom-term-00.txt
Spencer, At 03:18 PM 07/26/2005, Spencer Dawkins wrote: This draft (available at http://www.ietf.org/internet-drafts/draft-klensin-nomcom-term-00.txt ) does a reasonable job of balancing between current-generation leadership continuity and next-generation leadership development. I have previously expressed the opinion that an absolute prohibition on four terms of continuous service would be preferable, but the flexibility granted to NOMCOM in this proposal is acceptable (and I could be wrong). 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. I think the IETF community is well served by having more people cycle in and out of the IESG. It serves the IESG by having ADs who have more recent experience in working groups and it serves the working groups by having some of our best technical people back in the working groups. Bob ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: calendar file for IETF
>It reads in to Thunderbird OK, but the result is less pretty than >Eliot's effort. Eliot's version appears to lay out the multiple events >in a partcular timeslot evenly across the available space, whereas >Bill's results in different sized blocks and in some cases some of the >events appear to be hiding others. This may be because mine treats two sequential 1-hour meetings as a 2-hour meeting, and Eliot's treats them as 2 1-hour meetings. See l3vpn on Monday and mip6 on Tuesday evening. I originally wrote the agenda parser that's the basis of this .ics output when we switched to 1-hour meetings on Tuesdays because I could never tell whether a given meeting was one or 2 hours long. I have yet to find a client that has a good variable-length overlapping event rendering algorithm, especially with 8-9 events in the overlap. Apple's iCal usually does really well when there are 3 or 4. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: calendar file for IETF
>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. >Couple of other points: > >- Some lines were longer than 72 characters Erk, I forgot about that aspect. >- Some SUMMARY's contained raw HTMl mark-up This was an oversight when converting the HTML output to iCalendar output. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: calendar file for IETF
Hi Elwyn, --On July 27, 2005 12:06:58 AM +0100 Elwyn Davies <[EMAIL PROTECTED]> wrote: It reads in to Thunderbird OK, but the result is less pretty than Eliot's effort. Eliot's version appears to lay out the multiple events in a partcular timeslot evenly across the available space, whereas Bill's results in different sized blocks and in some cases some of the events appear to be hiding others. Looking at the .ics sources it is not obvious why this should be. Clearly Bill's has additional useul info... need a merge of the two! One important (IMHO) issue is that Bill's ics does not use timezone info for the times. Since I'm not going to be in Paris, but do want to listen in to some sessions, having proper timezone info in the ics would allow me to see the times adjusted to my own local timezone without having to do any math in my head! Couple of other points: - Some lines were longer than 72 characters - Some SUMMARY's contained raw HTMl mark-up However, it imported fine into my client. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IAOC office hours in Paris
IETF 63 Attendees: The members of the IAOC will be holding regular office hours at the IETF meeting in Paris. Members will be available between 3:45PM and 4:45PM on Tuesday, Wednesday, and Thursday (August 2-4) in room 325M on the third floor mezzanine above Hall Bordeaux. For a plan of the third floor see: http://www.palaisdescongres-paris.com/organiser/espace/pdf/FICHE9.pdf. Minutes of recent IAOC calls as well as monthly reports can be viewed at our web site: http://koi.uoregon.edu/~iaoc/. Please drop by and share any comments or questions you may have about our work. See you in Paris! Lucy E. Lynch Academic User Services Computing CenterUniversity of Oregon llynch @darkwing.uoregon.edu (541) 346-1774 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: calendar file for IETF
It reads in to Thunderbird OK, but the result is less pretty than Eliot's effort. Eliot's version appears to lay out the multiple events in a partcular timeslot evenly across the available space, whereas Bill's results in different sized blocks and in some cases some of the events appear to be hiding others. Looking at the .ics sources it is not obvious why this should be. Clearly Bill's has additional useul info... need a merge of the two! Regards, Elwyn Bill Fenner 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 ;-) Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
draft-klensin-stds-review-panel-00.txt
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 Discussion material? Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
draft-klensin-nomcom-term-00.txt
This draft (available at
http://www.ietf.org/internet-drafts/draft-klensin-nomcom-term-00.txt)
does a reasonable job of balancing between current-generation
leadership continuity and next-generation leadership development.
I have previously expressed the opinion that an absolute prohibition
on four terms of continuous service would be preferable, but the
flexibility granted to NOMCOM in this proposal is acceptable (and I
could be wrong).
The current IETF is a better place because of several I* members who
have returned to the community - they are providing strong technical
leadership, without dots on badges. Honorable retirement after
honorable service on IESG or IAB is not a bad thing.
If I read RFC 3777 correctly, we will be assembling the next NOMCOM
very soon ("at least two months before the Third IETF"). So, I'm
wondering...
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?
Spencer
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
RE: calendar file for IETF
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 ;-) Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
