idnits 2.17.00 (12 Aug 2021) /tmp/idnits27132/draft-jaeggli-ietftv-ng-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.3 on line 39. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 635. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 642. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 648. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 611), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 43. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? -- The document has an RFC 3978 Section 5.3 Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 121 has weird spacing: '...ecorded are a...' == Line 141 has weird spacing: '... course of th...' == Line 143 has weird spacing: '...equired to mo...' == Line 152 has weird spacing: '...rovided by th...' == Line 179 has weird spacing: '...theless large...' == (10 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 9, 2005) is 6183 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETFTV BOF J. Jaeggli 2 Internet-Draft University of Oregon 3 Expires: December 11, 2005 June 9, 2005 5 Next Generation Effort for IETF Multicast/Unicast Delivery 6 draft-jaeggli-ietftv-ng-01 8 IPR Statement 10 "By submitting this Internet-Draft, each author represents that 11 any applicable patent or other IPR claims of which he or she is 12 aware have been or will be disclosed, and any of which he or she 13 becomes aware will be disclosed, in accordance with Section 6 of 14 BCP 79." 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC 2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on December 11, 2005. 39 This document may only be posted in an Internet-Draft. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). All Rights Reserved. 45 Abstract 47 This memo describes one proposal for continuing and expanding the 48 broadcast and recording effort while reducing the number of 49 volunteers required and the expenses associated with providing the 50 previous service 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Historical Efforts . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1 Equipment . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2 Expenses . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.3 Shortcomings . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. New Effort . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.1 Software Platform . . . . . . . . . . . . . . . . . . . . 6 63 3.2 Hardware Platform . . . . . . . . . . . . . . . . . . . . 6 64 3.3 Server Resources . . . . . . . . . . . . . . . . . . . . . 7 65 3.4 Meeting Room Requirements . . . . . . . . . . . . . . . . 8 66 3.5 Volunteer Requirements . . . . . . . . . . . . . . . . . . 8 67 3.6 Post Production . . . . . . . . . . . . . . . . . . . . . 9 68 3.7 Expenditures . . . . . . . . . . . . . . . . . . . . . . . 9 70 4. IETF 62 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.1 Budget . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4.2 Equipment Procurement . . . . . . . . . . . . . . . . . . 10 73 4.3 Deployment . . . . . . . . . . . . . . . . . . . . . . . . 10 74 4.4 Operation . . . . . . . . . . . . . . . . . . . . . . . . 11 75 4.5 Audience . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 5. The Future . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 81 A. Appendix 1 - IETFTV BOF summary . . . . . . . . . . . . . . . 14 83 B. Appendix 2 - Possible Hardware Configuration . . . . . . . . . 16 85 Intellectual Property and Copyright Statements . . . . . . . . 17 87 1. Introduction 89 With recent changes in the IETF and ways in which interested parties 90 participate, there is a push to overhaul the mechanisms that are 91 provided for remote participation and working group meeting 92 archiving. 94 For the past several years, two sessions have been multicast at two 95 or more bit rates (low and high). These sessions have also been 96 recorded and made available relatively soon after the meeting. More 97 recently, experiments have been conducted in an attempt to add 98 additional rooms with unicast support but only audio. 100 At this point, the IETF is at a cross-roads. Because of perceived 101 changes in remote participant needs and funding availability, the 102 IETF needs to decide what is needed in terms of service to users. 103 Furthermore, an analysis needs to be done on what this service will 104 cost and whether there is budget to support it. 106 This document proposes one possible approach, intended to expand 107 meeting coverage while reducing the volunteers required to support 108 this effort, and devels into the effort to deploy this approach at 109 IETF 62 111 2. Historical Efforts 113 Since IETF 49 the University of Oregon Videolab in collaboration with 114 the University of California Santa Barba, various corporate partners 115 the Secretariat and the IETF chair have scheduled and then multicast, 116 the working groups that meet in 2 of the 6 to 8 parallel tracks 117 scheduled every day while the IETF meets. 119 2.1 Equipment 121 At present the resources required for each track recorded are as 122 follows: 124 o two cameras 126 o a VGA scan converter 128 o video source selector 130 o audio distribution amplifier 132 o 3 cable runs of approximately 15-20M 134 o as many PCs to encode as source formats are required 136 o an ethernet switch attached to a multicast capable network 138 o a kvm switch, monitor keyboard and mouse 140 o 1 Camera operator per track is required, in practice 2 to 3 141 volunteers per track spell each other over the course of the week 143 o 1 person and an additional host computer are required to monitor 144 the encoder hosts and output for both tracks 146 2.2 Expenses 148 Typically the University of Oregon has provided 2 to 3 persons and 149 shipped the bulk of the equipment (Cameras reside with the 150 secretariat). Additional volunteers from UCSB and elsewhere have be 151 funded through the IETF chair's ISOC funds or through the meeting 152 local host, if provided by them. Domestically in the United States 153 expenses run about $2000 per person for the duration of the meeting, 154 internationally $3000 and up depending on the meeting location. 155 Shipping equipment has cost anywhere from $5000 domestically to 156 $10,000 internationally. 158 2.3 Shortcomings 160 The current effort, despite all it successes has several obvious 161 shortcomings: 163 o Multicast deployment is required at end sites in order to receive 164 multicast sources. While one of the University of Oregon's 165 principle goals was and is multicast network deployment 166 evangelism, many people who would like to receive the sources have 167 little or no control over their network transport and are 168 therefore unable to receive the sources. 170 o Poor scaling properties. While multicast delivery had decent 171 scaling properties if audience size increases, covering one 172 additional room under the current model requires a 50% increase in 173 manpower and equipment. covering all 8 tracks would require on the 174 order of a 4 fold increase in manpower and equipment 176 o Equipment is expensive to ship and aging. The cameras (purchased 177 by the IETF chair) are close to 6 years old. The kit of equipment 178 provided by the University of Oregon is the third generation of 179 equipment we have invested in, nevertheless large parts of it are 180 approaching 3 years old. The kit is increasingly hard for The U 181 of O to maintain. Shipping it, (2 large and 1 small flight cases, 182 about 200KG) represents the largest single expense in supporting 183 the IETF multicast 185 o Poor clarity of mission. There are at least three major 186 constituencies who are served by the multicast effort, none 187 particularly well, remote participants and observers are placed at 188 a disadvantage by the multicast requirements, the lack of complete 189 meeting coverage and the subsequent gaps in the archive. IETF 190 attendees have expressed a desire, to be able to monitor the 191 activities of one working group while participating in another, 192 and likewise are not well served by an incomplete record. 193 Consumers of the record only, obviously have the same limitations 194 due to coverageas the previous two groups 196 3. New Effort 198 The new effort should meet three simple goals. It should be 199 accessible to people with or without multicast connectivity, 200 including availability on the wireless network for those attending 201 the meeting, without adverse performance implications. It should be 202 able to cover as many tracks as are scheduled in parallel. It should 203 be sufficiently inexpensive that it can be funded as part of the 204 ongoing operation of the IETF. 206 The proposal Hinges on delivering a basic, audio-only unicast stream 207 using a purpose-built but off-the-shelf hardware kit, and remote 208 servers, leveraging the reduction in production resources (hardware, 209 camera operators, management) to control costs while expanding to 210 cover the whole IETF meeting schedule. 212 3.1 Software Platform 214 For IETF 60 and 61 we experimented in a limited basis (4 rooms at 215 60, 2 rooms at 61) with an application, MUSE <http://muse.dyne.org> 216 that provided a command line, curses, and X11 interface to stream via 217 unicast http an mp3 or ogg audio stream through an Icecast 1 or 2 218 style server application or interoperable implementation such as 219 Shoutcast or the Apple Darwin streaming server. Client support for 220 this type of unicast delivery appears broad, with most platform's 221 native media players (Quicktime, Real, Winamp, Mplayer, Windows Media 222 Player, etc) being able to handle the stream, allowing us to leverage 223 the current popularity of MP3 streaming used by internet-radio 224 applications. Muse has several desirable properties: 226 o It is open source, and is under active development. 228 o As a command-line application it can be operated and monitored 229 remotely relatively easily. 231 o It is capable of simultaneously streaming and recording the mp3 232 audio stream. 234 o It can embed a limited amount of meta-data in the recording and 235 the stream about the program being received 237 It is envisioned that a single operator can simultaneously monitor 238 all eight of the streaming boxes from a central location, experience 239 gained during ietf60 suggest that this is feasible. 241 3.2 Hardware Platform 243 The hardware platform will consist of small headless (no keyboard or 244 monitor) computers running Linux capable of being centrally managed. 245 For audio-only streaming the principle requirements are a supported 246 full-duplex sound chipset with microphone and line-level inputs, 247 ethernet and a local drive for recording. Additionally form-factor 248 should dictate purchasing, it would be highly desirable if 8 of these 249 units were sufficiently small the be packable as lugguage. One 250 possible configuration might be built around mini-itx platform 251 (17x17cm motherboard) would contain a 1ghz via c3 processor 256MB of 252 ram a 40GB drive and be approximately 170x50x250mm and 2kg. Such 253 units could be sourced for $500 or less each. While that is 254 approximately the cost of an inexpensive laptop, mini-itx computers 255 are about 1/2 the volume and weight of a laptop offering. A Dell 256 Inspiron 1150 for example retails for $699 but is 45x329x275mm and 257 about 3.5kg 259 Miscellaneous additional hardware items needed to support recording 260 are some kind of management workstation, (a laptop could be pressed 261 into service there) cables to mate with the room mixer, various 262 length ethernet jumpers and appropriate luggage for hardware to 263 travel in. In total initial equipment outlay ought to cost less than 264 $5000. 266 Equipment that will have have to be purchased immediatly, to be owned 267 by the IETF: 269 o 8 audio streaming hosts at $500ea 271 o Luggage style flight-case suitable to transport 8 hosts plus 272 appropiate cable $500 274 o Misc cables to support various audio interconnects $200 276 Equipment that can provided through volunteer efforts (Joel Jaeggli): 278 o Management workstation 280 o Room Length Ethernet runs 282 o Misc cables to support various audio interconnects 284 3.3 Server Resources 286 Unlike the multicast services which requires no servers to deliver 287 streams to clients, for the unicast streams sufficient server 288 resources and transit bandwidth must be available to serve client 289 demand. As delivered mp3 audio streams will vary between 32 and 290 64Kb/s multiplied by the number of clients joined. During the IETF 291 60 test, peak utilization of ~40 clients never exceeded 2.5Mb/s. 292 While it is possible that servers could be located on the IETF 293 conference network, doing so places an additional, possibly 294 undesirable expectation on the host, According the University of 295 Oregon and ISI's Postel center have offered to host servers. A 296 server is a Linux or UNIX host running the Darwin Streaming Server or 297 shoutcast 2 server, additional servers can be deployed when resources 298 are insufficient on existing servers. At present, the University of 299 Oregon has two such servers available. 301 3.4 Meeting Room Requirements 303 In some key respects, delivering unicast audio will reduce 304 requirements on the secretariat, hosting entity, working group 305 chairs, participants and multicast volunteers, it adds some 306 requirements as well. 308 o Currently the secretariat schedules multicast rooms, this will no 309 longer be required as all rooms will be covered. 311 o Currently the hosting entity is responsible for providing an 312 ethernet drop in each multicast room on a multicast enabled 313 subnet, instead one drop per meeting room will be required, 314 attached to either the terminal room or general conference 315 network. Meeting room connectivity can leverage the network built 316 to support the wireless in most cases. 318 o A sound system will have to provided in all rooms where recording 319 is desired, presently one is provided in most rooms. Costs of 320 providing sound for additional rooms if necessary are best 321 determined by the secretariat. 323 o Working group chairs and participants will need to enforce 324 microphone discipline, stating their name for the record and using 325 the microphone for meeting participation. 327 3.5 Volunteer Requirements 329 The volunteer requirements ought to be as low as two person outside 330 of the additional requirements placed on the secretariat and the 331 host. Two volunteers should all one person to monitor all 8 rooms 332 and remote servers while the other is free for trouble-shooting and 333 post production tasks. Additional host requirements (more network 334 drops) ought to be offset by the reduced complexity of the network 335 and the fact that it leverages network assets that have to be 336 deployed anyway 337 Costs associated with funding volunteers should be similar to current 338 expenses. On a per-person basis, order of $2000 per meeting 339 domestically in the United States (assuming volunteers originate from 340 there). Reimbursable expenses will be submitted through the IETF 341 chair. 343 3.6 Post Production 345 Currently post production of video captured during the IETF is quite 346 an involved process, and due to the size of the files created, and 347 the overhead of delivering transcoded video for the archive can 348 require several weeks of volunteer effort. The only post production 349 the audio recording should require would be removal of any audio 350 recorded prior to the commencement or after the completion of the 351 meeting and the amending of timestamped filenames to a format that 352 allows the identification of each meeting. It is envisioned that 353 principle post production tasks for audio can be performed during the 354 course of an IETF meeting and the finished product should be 355 available to observers and attendees before the minutes are 356 published, much as the raw unedited video files are now. 358 3.7 Expenditures 360 This proposal has about $5000 in immediate expenditures related to 361 hardware purchases. Additionally, recurring costs to provide two 362 volunteers to support the, effort are estimated at around $4000 per 363 meeting. This proposal may place finacial expectations on the 364 secretariat if sound systems have to be provided in additional rooms 365 above and beyond what would otherwise be provisioned. 367 4. IETF 62 369 4.1 Budget 371 Actual expenditures covered by ISOC for hardware aquisition totaled 372 $3,453.49. The travel and lodging expenses for the one reimbursed 373 volunteer, totaled $1,559.03. 375 4.2 Equipment Procurement 377 Apart from the fact that substanital cost savings were realized over 378 and above the downwardly resvised estimates, hardware was 379 straightforward and worked as originally envisioned. Lower costs 380 were principally realized through volume discounts on some of the 381 components, and time constraints limiting the purchase of audio and 382 network cabling that ended up being loaned by volunteers or the 383 University of Oregon. 385 In it's entirety, hardware aquisition occupied the span of one month 386 only, with some assembly tasks being completed the day prior to 387 departure for the IETF meeting. Despite time constraints, almost all 388 of the hardware functioned as expected, one of the servers failed due 389 to a bad power supply (since rectified), and was replaced by a 390 server loaned from the University of Oregon. 392 4.3 Deployment 394 Due to the efforts of the volunteer hosts, ports on a subnet devoted 395 to the streaming were deployed in all of the 8 scheduled meeting 396 rooms. Each host was initially cabled to the ethernet in the room 397 and booted with a laptop acting as serial console attached in order 398 to determine the IP address that the host aquired. 400 IP addresses were subsequently added to the DNS to facilitate remote 401 managment. In the future geting the hosts to update the DNS 402 dynamically or simply recording the mac addresses of the servers 403 would have reduced the number of setup steps considerably. 405 It became apparent in testing of the software proposed for encoding 406 and streaming (muse) in the lab, that some of the desirable 407 functionality of the software was available only from it's gtk gui 408 interface, rather than it's curses text console base interface. The 409 solution adopted was run to run a VNC server on each servers, which 410 functioned as a local xserver, The VNC server could then be attached 411 to a remote management station over ssh to manipulate the 412 applications running locally on each server. In practice, the VNC as 413 local xserver model proved quite successful having survived managment 414 workstation detachments, crashes, and network connectivity 415 interuptions. 417 4.4 Operation 419 There are 5 kinds of host involved In delivering audio to an end 420 user. Clients, directed by a link from the IETF meeting webpage are 421 directed to a webpage. They select either to join a particul room a 422 or download a playlist into their media player which includes all of 423 the available rooms. The client then connects to the darwin/ 424 shoutcast streaming server refered to, in the playlist which is 425 recieving an audio stream from the server located in the 426 corresponding IETF meeting room. Operation of the encoders is 427 directed by a manangment workstation, which controls the encoders 428 through remote vnc sessions and is able to monitors the audio output 429 of the darwin shoutcast server as a client. 431 The principal problems with operation at IETF 62 hinge around the 432 operation of the managment workstation. While software makes it 433 possible to monitor all of the servers and audio streams for 434 availability, it's infeasbile for the workstation user to monitor 435 more than one of the audio streams a time. If only one operator is 436 working at a time, traveling from the noc to a room where an issue is 437 present (loss of network connectivity, no audio, poor audio) results 438 in dividing that person's attention. While the managment workstation 439 resided in the noc and sat on the same network with the streaming 440 servers, switching over to the wireless network for debuging was 441 hampered by the tenuous state of the wireless network early in the 442 meeting, and to the extent that things like audio streams would not 443 stay up while roaming between ap's (ie. running from one end of the 444 building to the other with a laptop) continued to remain elusive 445 throughout the meeting. 447 Given some of the shortcomings only a few screwup's resulted in the 448 the loss of recordings, Fewer even than would ordinarily be expected 449 from the video recording, despite a four-fold increase in the amount 450 of recording. Some of this stability increase can likely been 451 attributed to the elimination of Windows NT and 2000 based servers 452 entirely (no crashes other than the manangment workstation), but a 453 greater part was part was probably played by the simplification in 454 the encoding, and a reduction in the number of operators to 2 rather 455 than 6 or 8 required for the multicast delivery and camera operation. 457 4.5 Audience 459 For the first time, a remote audience received almost complete access 460 to the proceedings of the IETF as they happened. Because delivery of 461 the audio was entirely unicast we have logs that provide a far more 462 accurate picture of the size of the audience. 464 Over the course of the Week at IETF 62, 552 unique hosts made 4409 465 requests that resulted in data being streamed. Of those requestes, 466 702 where made from the conference network. 468 Feedback, from remote users was generally positive, however it points 469 to a few kinks that could stand to be be rectified. Some commentors 470 noted that not all slide decks where available at the time a working 471 group met. Microhpone protocol was not universally observed 472 particulary in small groups although this improved by the end of the 473 week. In the example of the snmp mib working group the 5 particpants 474 in the room included an area director and the working-group chair, 475 another area director followed along remotely... 477 There appears to be substantial interest on the part of local 478 participants at the ietf meeting to monitor sessions in which they 479 are not physicaly participating. If slightly less than a quater of 480 all monitoring occurs from the local network it speaks well to the 481 accessibility of the audio streaming to the group, for which the 482 multicast streaming was not previously accessible. 484 5. The Future 486 When we planned the transition to audio-only unicast streaming for 487 IETF62, the intention was to field a service that was inexpensive 488 enough that it could be replicated at subsequent IETF meetings. I 489 believe that goal has been achieved. Assuming the same sources are 490 willing to provide funding at similar levels into the future there is 491 no reason to believe that we couldn't replicate the exercise at IETF 492 63, and beyond. 494 Author's Address 496 Joel Jaeggli 497 University of Oregon 498 1212 University of Oregon 499 Eugene, Oregon 97405 500 USA 502 Phone: +1-541-346-1716 503 Fax: +1-5413464397 504 Email: joelja@uoregon.edu 506 Appendix A. Appendix 1 - IETFTV BOF summary 508 From falk@isi.edu Tue Dec 7 13:45:26 2004 510 Date: Tue, 7 Dec 2004 13:44:53 -0800 512 From: Aaron Falk falk@isi.edu 514 To: minutes@ietf.org 516 Cc: ietfcast@lists.uoregon.edu 518 Subject: ietfcast: ietf-tv summary for the IETF-61 proceedings 520 Summary of the IETF-TV BoF 522 BoF Chair: Ole Jacobsen 524 Notes taken by: Aaron Falk 526 The purpose of the IETF-TV BoF was to discuss in what way multimedia 527 capture of IETF meetings would best serve the community. Multicast 528 was used by volunteers to provide audio and digital whiteboard tools 529 starting in 1992. Tools and encoding formats evolved over the years 530 until the present day where two rooms at each IETF are covered using 531 MPEG-1 video and H.261/PCM audio four additional rooms with MP3 audio 532 only. The streams are made available using ASM and SSM multicast 533 (some individuals provide unicast reflectors) and the files are post- 534 processed and stored in an online repository for viewing after the 535 meeting. 537 At IETF-60, there were about 20 "viewers" per meeting (ed: IETF or wg 538 meeting?) with a peak of about 70. Feedback from the audio-only 539 sessions was that it was hard to follow the meeting without some 540 visual feedback, preferably the ability to view the slides. There 541 have been 100's to 1000's of downloads of online files. 543 The staffing and travel and equipment expenses have been borne by 544 University of Oregon (UofO) with some assistance from Cisco and the 545 IETF Chair fund. Typical requirements are 6 weeks/year for 546 preparation; staffing and post-processing, 4-6 people (historically 547 students) to operate the equipment during the IETF meeting; $10k for 548 shipping (ed: per meeting? per year?); bandwidth for streaming and 549 download (broadband, real-time bandwidth and server requirements are 550 non-trivial). However, most of the expense is associated with the 551 video capture: camera operators (labor and travel) and specialized 552 equipment are required. The UofO is unwilling to shoulder staffing, 553 and has run out of Cisco-provided funding that allowed their staff to 554 travel and ship their equipment. The UofO never provided any 555 significant financial support outside of staff. Several questions 556 therefore arise: 558 What problem is being solved by this service? Remote participation? 559 Broadcast to a remote (non-participatory) audience? Creating a 560 public record? 562 It is estimated that a professional staff would cost about ~$50k/ 563 meeting (based on similar hotel events). Various strategies of cost 564 recovery were discussed including increasing meeting fees (~$25), 565 charging online viewers ($100), selling CDs (~$100ea) or finding 566 sponsors (~$25k/yr). There was a general conclusion that some form 567 of service is useful and of interest but there were no clear 568 recommendations identifying a primary audience or of cost recovery. 570 No working group will be created from this BoF. 572 ietfcast resources: 573 _________________________________________________ 575 user interface: http://darkwing.uoregon.edu/~llynch/ietfcast.html 577 web archive: 578 http://darkwing.uoregon.edu/~llynch/ietfcast/index.html 580 Appendix B. Appendix 2 - Possible Hardware Configuration 582 One of The lessons to be taken away from previous efforts is that 583 shipping and maintenance of the equipment necessary to provide the 584 former service was one of the most expensive and time-consuming parts 585 of the effort. With that mind, and the goal of simplifying the 586 equipement, a more compact, rugged, and inexpensive computer is 587 needed. The actual cpu requirements for audio encoding are 588 signficantly more lightweight than delivering mpeg-4 video, a great 589 assistance in reducing the scale of the equipment necessary to 590 support this effort. 592 One possible configuration that would be appropriate for our 593 application follows (all costs are approximate): 595 o Casetronic c134 aluminum chassis (dimesions 177 x 50 x 254mm) 60w 596 external powesupply $150 598 o Via epia m1000 mainboard integrated ethernet, sound, video, 599 ieee1394, usb2 1ghz via c3 cpu $160 601 o 256MB unbuffered pc2100 ddr dimm memory module $50 603 o 40GB 2.5" laptop harddrive $80 605 o cable lock $20 607 o Total: $460 609 Full Copyright Statement 611 "Copyright (C) The Internet Society (2005). 613 This document is subject to the rights, licenses and restrictions 614 contained in BCP 78, and except as set forth therein, the authors 615 retain all their rights." 617 "This document and the information contained herein are provided 618 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 619 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 620 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 621 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 622 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 623 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 624 PARTICULAR PURPOSE." 626 Intellectual Property Statement 628 The IETF takes no position regarding the validity or scope of any 629 Intellectual Property Rights or other rights that might be claimed to 630 pertain to the implementation or use of the technology described in 631 this document or the extent to which any license under such rights 632 might or might not be available; nor does it represent that it has 633 made any independent effort to identify any such rights. Information 634 on the procedures with respect to rights in RFC documents can be 635 found in BCP 78 and BCP 79. 637 Copies of IPR disclosures made to the IETF Secretariat and any 638 assurances of licenses to be made available, or the result of an 639 attempt made to obtain a general license or permission for the use of 640 such proprietary rights by implementers or users of this 641 specification can be obtained from the IETF on-line IPR repository at 642 http://www.ietf.org/ipr. 644 The IETF invites any interested party to bring to its attention any 645 copyrights, patents or patent applications, or other proprietary 646 rights that may cover technology that may be required to implement 647 this standard. Please address the information to the IETF at ietf- 648 ipr@ietf.org. 650 Acknowledgment 652 Funding for the RFC Editor function is currently provided by the 653 Internet Society. 655