On 7/26/13, John C Klensin <john-ietf@xxxxxxx> wrote: > Hi. > > For a newcomer or someone expecting to write I-Ds, some of the > most important sessions at the IETF are the various Sunday > afternoon tutorials and introductions. Many of them are (or > should be) of as much interest to remote participants as to f2f > attendees. Until and unless a newcomer's tutorial can be > prepared that is focused on remote participants, even that > session should be of interest. > > For this particular meeting all of the following seem relevant > to at least some remote participants: > > Newcomers' Orientation > Tools for Creating I-Ds and RFCs > IAOC Overview Session > Multipath TCP > Applying IP Flow Information Export (IPFIX) to Network > Measurement and Management > > So... > > (1) The note below strongly implies that none of those sessions > are being audiocast. Why not and can that be fixed? > > (2) There is no hint on the agenda or tools agenda about > availability of presentation and related materials (slides, > etc.) for those sessions. Do those materials not exist? I > know, but a newcomer or remote participant might not, that I can > find some tutorials by going to the IETF main page and going to > "Tutorial" under "Resources", but I have no idea which of those > links actually reflects what will be presented on Sunday. > Assuming the presentation materials do exist for at least > several of the sessions, finding them is much like the situation > with subscribing to the 87all list. It should no involve a > treasure hunt at which only very experienced IETF participants > can be expected to succeed. > > Specific suggestions: > > (i) Let's get these open Sunday sessions audiocast and/or > available over Meetecho or WebEx. If that is impossible for > IETF 87, it should be a priority for IETF 88 and later. +1 > > (ii) If there are presentation materials available, links from > the tools agenda and an announcement to IETF-Announce as to > where to find them would be desirable. > > (iii) If presentation materials are not available, why not? > And, more important, can this be made a requirement for IETF 88 > and beyond? > > thanks, > john > >