Internet DRAFT - draft-jaeggli-ietftv-ng

draft-jaeggli-ietftv-ng



IETFTV BOF                                                    J. Jaeggli
Internet-Draft                                      University of Oregon
Expires: December 11, 2005                                  June 9, 2005


       Next Generation Effort for IETF Multicast/Unicast Delivery
                       draft-jaeggli-ietftv-ng-01

IPR Statement

   "By submitting this Internet-Draft, each author represents that
   any applicable patent or other IPR claims of which he or she is
   aware have been or will be disclosed, and any of which he or she
   becomes aware will be disclosed, in accordance with Section 6 of
   BCP 79."

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 11, 2005.

   This document may only be posted in an Internet-Draft.

Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.

Abstract

   This memo describes one proposal for continuing and expanding the
   broadcast and recording effort while reducing the number of
   volunteers required and the expenses associated with providing the
   previous service










Jaeggli                 Expires December 10, 2005               [Page 1]

Internet-Draft                  IETFTV-NG                      June 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Historical Efforts . . . . . . . . . . . . . . . . . . . . . .  4
     2.1   Equipment  . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2   Expenses . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.3   Shortcomings . . . . . . . . . . . . . . . . . . . . . . .  5

   3.  New Effort . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1   Software Platform  . . . . . . . . . . . . . . . . . . . .  6
     3.2   Hardware Platform  . . . . . . . . . . . . . . . . . . . .  6
     3.3   Server Resources . . . . . . . . . . . . . . . . . . . . .  7
     3.4   Meeting Room Requirements  . . . . . . . . . . . . . . . .  8
     3.5   Volunteer Requirements . . . . . . . . . . . . . . . . . .  8
     3.6   Post Production  . . . . . . . . . . . . . . . . . . . . .  9
     3.7   Expenditures . . . . . . . . . . . . . . . . . . . . . . .  9

   4.  IETF 62  . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.1   Budget . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.2   Equipment Procurement  . . . . . . . . . . . . . . . . . . 10
     4.3   Deployment . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.4   Operation  . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.5   Audience . . . . . . . . . . . . . . . . . . . . . . . . . 11

   5.  The Future . . . . . . . . . . . . . . . . . . . . . . . . . . 13

       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13

   A.  Appendix 1 - IETFTV BOF summary  . . . . . . . . . . . . . . . 14

   B.  Appendix 2 - Possible Hardware Configuration . . . . . . . . . 16

       Intellectual Property and Copyright Statements . . . . . . . . 17

















Jaeggli                 Expires December 10, 2005               [Page 2]

Internet-Draft                  IETFTV-NG                      June 2005


1.  Introduction

   With recent changes in the IETF and ways in which interested parties
   participate, there is a push to overhaul the mechanisms that are
   provided for remote participation and working group meeting
   archiving.

   For the past several years, two sessions have been multicast at two
   or more bit rates (low and high).  These sessions have also been
   recorded and made available relatively soon after the meeting.  More
   recently, experiments have been conducted in an attempt to add
   additional rooms with unicast support but only audio.

   At this point, the IETF is at a cross-roads.  Because of perceived
   changes in remote participant needs and funding availability, the
   IETF needs to decide what is needed in terms of service to users.
   Furthermore, an analysis needs to be done on what this service will
   cost and whether there is budget to support it.

   This document proposes one possible approach, intended to expand
   meeting coverage while reducing the volunteers required to support
   this effort, and devels into the effort to deploy this approach at
   IETF 62




























Jaeggli                 Expires December 10, 2005               [Page 3]

Internet-Draft                  IETFTV-NG                      June 2005


2.  Historical Efforts

   Since IETF 49 the University of Oregon Videolab in collaboration with
   the University of California Santa Barba, various corporate partners
   the Secretariat and the IETF chair have scheduled and then multicast,
   the working groups that meet in 2 of the 6 to 8 parallel tracks
   scheduled every day while the IETF meets.

2.1  Equipment

   At present the resources required for each track recorded  are as
   follows:

   o  two cameras

   o  a VGA scan converter

   o  video source selector

   o  audio distribution amplifier

   o  3 cable runs of approximately 15-20M

   o  as many PCs to encode as source formats are required

   o  an ethernet switch attached to a multicast capable network

   o  a kvm switch, monitor keyboard and mouse

   o  1 Camera operator per track is required, in practice 2 to 3
      volunteers per track spell each other over the course  of the week

   o  1 person and an additional host computer are required  to monitor
      the encoder hosts and output for both tracks


2.2  Expenses

   Typically the University of Oregon has provided 2 to 3 persons and
   shipped the bulk of the equipment (Cameras reside with the
   secretariat).  Additional volunteers from UCSB and elsewhere have be
   funded through the IETF chair's ISOC funds or through the meeting
   local host, if provided  by them.  Domestically in the United States
   expenses run about $2000 per person for the duration of the meeting,
   internationally $3000 and up depending on the meeting location.
   Shipping equipment has cost anywhere from $5000 domestically to
   $10,000 internationally.




Jaeggli                 Expires December 10, 2005               [Page 4]

Internet-Draft                  IETFTV-NG                      June 2005


2.3  Shortcomings

   The current effort, despite all it successes has several obvious
   shortcomings:

   o  Multicast deployment is required at end sites in order to receive
      multicast sources.  While one of the University of Oregon's
      principle goals was and is multicast network deployment
      evangelism, many people who would like to receive the sources have
      little or no control over their network transport and are
      therefore unable to receive the sources.

   o  Poor scaling properties.  While multicast delivery had decent
      scaling properties if audience size increases, covering one
      additional room under the current model requires a 50% increase in
      manpower and equipment. covering all 8 tracks would require on the
      order of a 4 fold increase in manpower and equipment

   o  Equipment is expensive to ship and aging.  The cameras (purchased
      by the IETF chair) are close to 6 years old.  The kit of equipment
      provided by the University of Oregon is the third generation of
      equipment we have invested in, nevertheless  large parts of it are
      approaching 3 years old.  The kit is increasingly hard for The U
      of O to maintain.  Shipping it, (2 large and 1 small flight cases,
      about 200KG) represents the largest single expense  in supporting
      the IETF multicast

   o  Poor clarity of mission.  There are at least three major
      constituencies who are served by the multicast effort, none
      particularly well, remote participants and observers are placed at
      a disadvantage by the multicast requirements, the lack of complete
      meeting coverage and the subsequent gaps in the archive.  IETF
      attendees have expressed a desire, to be able to monitor the
      activities of one working group while participating in another,
      and likewise are not well served by an incomplete record.
      Consumers of the record only, obviously have the same limitations
      due to coverageas the previous two groups














Jaeggli                 Expires December 10, 2005               [Page 5]

Internet-Draft                  IETFTV-NG                      June 2005


3.  New Effort

   The new effort should meet three simple goals.  It should be
   accessible to people with or without multicast connectivity,
   including availability on  the wireless network for those attending
   the meeting, without adverse performance implications.  It should be
   able to cover as many tracks as are scheduled in parallel.  It should
   be sufficiently inexpensive that it can be funded as part of the
   ongoing operation of the IETF.

   The proposal Hinges on delivering a basic, audio-only  unicast stream
   using a purpose-built but off-the-shelf hardware kit, and remote
   servers, leveraging the reduction in production resources (hardware,
   camera operators, management) to control costs while expanding to
   cover the whole IETF meeting schedule.

3.1  Software Platform

   For IETF 60 and 61 we experimented in a  limited basis (4 rooms at
   60, 2 rooms at 61) with an application, MUSE <http://muse.dyne.org>
   that provided a command line, curses, and X11 interface to stream via
   unicast http an mp3 or ogg audio stream through an Icecast 1 or 2
   style server application or interoperable implementation such as
   Shoutcast or the Apple Darwin streaming server.  Client support for
   this type of unicast delivery appears broad, with most platform's
   native media players (Quicktime, Real, Winamp, Mplayer, Windows Media
   Player, etc) being able to handle the stream, allowing us to leverage
   the current popularity of MP3 streaming used by internet-radio
   applications.  Muse has several desirable properties:

   o  It is open source, and is under active development.

   o  As a command-line application it can be operated and monitored
      remotely relatively easily.

   o  It is capable of simultaneously streaming and recording the mp3
      audio stream.

   o  It can embed a limited amount of meta-data in the recording and
      the stream about the program being received

   It is envisioned that a single operator can simultaneously monitor
   all eight of the streaming boxes from a central location, experience
   gained during ietf60 suggest that this is feasible.

3.2  Hardware Platform

   The hardware platform will consist of small headless (no keyboard or



Jaeggli                 Expires December 10, 2005               [Page 6]

Internet-Draft                  IETFTV-NG                      June 2005


   monitor) computers running Linux capable of being centrally managed.
   For audio-only streaming the principle requirements are a supported
   full-duplex sound chipset with microphone and line-level inputs,
   ethernet and a local drive for recording.  Additionally form-factor
   should dictate purchasing, it would be highly desirable if 8 of these
   units were sufficiently small the be packable as lugguage.  One
   possible configuration might be built around mini-itx platform
   (17x17cm motherboard) would contain a 1ghz via c3 processor 256MB of
   ram a 40GB drive and be approximately 170x50x250mm and 2kg.  Such
   units could be sourced for $500 or less each.  While that is
   approximately the cost of an inexpensive laptop, mini-itx computers
   are about 1/2 the volume and weight of a laptop offering.  A Dell
   Inspiron 1150 for example retails for $699 but is 45x329x275mm and
   about 3.5kg

   Miscellaneous additional hardware items needed to support recording
   are some kind of management workstation, (a laptop could be pressed
   into service there) cables to mate with the room mixer, various
   length ethernet jumpers and appropriate luggage for hardware to
   travel in.  In total initial equipment outlay ought to cost less than
   $5000.

   Equipment that will have have to be purchased immediatly, to be owned
   by the IETF:

   o  8 audio streaming hosts at $500ea

   o  Luggage style flight-case suitable to transport 8 hosts plus
      appropiate cable $500

   o  Misc cables to support various audio interconnects $200

   Equipment that can provided through volunteer efforts (Joel Jaeggli):

   o  Management workstation

   o  Room Length Ethernet runs

   o  Misc cables to support various audio interconnects


3.3  Server Resources

   Unlike the multicast services which requires no servers to deliver
   streams to clients, for the unicast streams sufficient server
   resources and transit bandwidth must be available to serve client
   demand.  As delivered mp3 audio streams will vary between 32 and
   64Kb/s multiplied by the number of clients joined.  During the IETF



Jaeggli                 Expires December 10, 2005               [Page 7]

Internet-Draft                  IETFTV-NG                      June 2005


   60 test, peak utilization of ~40 clients never exceeded 2.5Mb/s.
   While it is possible that servers could be located on the IETF
   conference network, doing so places an additional, possibly
   undesirable expectation on  the host, According the University of
   Oregon and ISI's Postel center have offered to host servers.  A
   server is a Linux or UNIX host running the Darwin Streaming Server or
   shoutcast 2 server, additional servers can be deployed when resources
   are insufficient on existing servers.  At present, the University of
   Oregon has two such servers available.

3.4  Meeting Room Requirements

   In some key respects, delivering unicast audio will reduce
   requirements on the secretariat, hosting entity, working group
   chairs, participants and multicast volunteers, it adds some
   requirements as well.

   o  Currently the secretariat schedules multicast rooms, this will no
      longer be required as all rooms will be covered.

   o  Currently the hosting  entity is responsible for providing an
      ethernet drop in each multicast room on a multicast enabled
      subnet, instead one drop per meeting room will be required,
      attached to either the terminal room or general conference
      network.  Meeting room connectivity can leverage the network built
      to support the wireless in most cases.

   o  A sound system will have to provided in all rooms  where recording
      is desired, presently one is provided in most rooms.  Costs of
      providing sound for additional rooms if necessary are best
      determined by the secretariat.

   o  Working group chairs and participants will need to enforce
      microphone discipline, stating their name for the record and using
      the microphone for meeting participation.


3.5  Volunteer Requirements

   The volunteer requirements ought to be as low as two person outside
   of the additional requirements placed on the secretariat and the
   host.  Two volunteers should all one person to monitor all 8 rooms
   and remote servers while the other is free for trouble-shooting and
   post production tasks.  Additional host requirements (more network
   drops) ought to be offset by the reduced complexity of the network
   and the fact that it leverages network assets that have to be
   deployed anyway




Jaeggli                 Expires December 10, 2005               [Page 8]

Internet-Draft                  IETFTV-NG                      June 2005


   Costs associated with funding volunteers should be similar to current
   expenses.  On a per-person basis, order of $2000 per meeting
   domestically in the United States (assuming volunteers originate from
   there).  Reimbursable expenses will be submitted through the IETF
   chair.

3.6  Post Production

   Currently post production of video captured during the IETF is quite
   an  involved process, and due to the size of the files created, and
   the overhead of delivering transcoded video  for the archive can
   require several weeks of volunteer effort.  The only post production
   the audio recording should require would be removal of any audio
   recorded prior to the commencement or after the completion of the
   meeting and the amending of timestamped filenames to a format that
   allows the identification of each meeting.  It is envisioned that
   principle post production tasks for audio can be performed during the
   course of an IETF meeting and the finished product should be
   available to observers and attendees before the minutes are
   published, much as the raw unedited video files are now.

3.7  Expenditures

   This proposal has about $5000 in immediate expenditures related to
   hardware purchases.  Additionally, recurring costs to provide two
   volunteers to support the, effort are estimated at around $4000 per
   meeting.  This proposal may place finacial expectations on the
   secretariat if sound systems have to be provided in additional rooms
   above and beyond what would otherwise be provisioned.






















Jaeggli                 Expires December 10, 2005               [Page 9]

Internet-Draft                  IETFTV-NG                      June 2005


4.  IETF 62

4.1  Budget

   Actual expenditures covered by ISOC for hardware aquisition totaled
   $3,453.49.  The travel and lodging expenses for the one reimbursed
   volunteer, totaled $1,559.03.

4.2  Equipment Procurement

   Apart from the fact that substanital cost savings were realized over
   and above the downwardly resvised estimates, hardware was
   straightforward and worked as originally envisioned.  Lower costs
   were principally realized through volume discounts on some of the
   components, and time constraints limiting the purchase of audio and
   network cabling that ended up being loaned by volunteers or the
   University of Oregon.

   In it's entirety, hardware aquisition occupied the span of one month
   only, with some assembly tasks being completed the day prior to
   departure for the IETF meeting.  Despite time constraints, almost all
   of the hardware functioned as expected, one of the servers failed due
   to a bad power supply (since rectified),  and was replaced by a
   server loaned from the University	 of Oregon.

4.3  Deployment

   Due to the efforts of the volunteer hosts, ports on a subnet devoted
   to the streaming were deployed in all of the 8 scheduled meeting
   rooms.  Each host was initially cabled to the ethernet in the room
   and booted with a laptop acting as serial console attached in order
   to determine the IP address that the host aquired.

   IP addresses were subsequently added to the DNS to facilitate remote
   managment.  In the future geting the hosts to update the DNS
   dynamically or simply recording  the mac addresses of the servers
   would have reduced the number of setup steps considerably.

   It became apparent in testing of the software proposed for encoding
   and streaming (muse) in the lab, that some of the desirable
   functionality of the software was available only from it's gtk gui
   interface, rather than it's curses text console base interface.  The
   solution adopted was run to run a VNC server on each servers, which
   functioned as a local xserver, The VNC server could then be attached
   to a remote management station over ssh to manipulate the
   applications running locally on each server.  In practice, the VNC as
   local xserver model proved quite successful having survived managment
   workstation detachments, crashes, and network connectivity



Jaeggli                 Expires December 10, 2005              [Page 10]

Internet-Draft                  IETFTV-NG                      June 2005


   interuptions.

4.4  Operation

   There are 5 kinds of host involved In delivering audio to an end
   user.  Clients, directed by a link from the IETF meeting webpage are
   directed to a webpage.  They select either to join a particul room a
   or download a playlist into their media player which includes all of
   the available rooms.  The client then connects to the darwin/
   shoutcast streaming server refered to, in the playlist which is
   recieving an audio stream from the server located in the
   corresponding IETF meeting room.  Operation of the encoders is
   directed by a manangment workstation, which controls the encoders
   through remote vnc sessions and is able to monitors the audio output
   of the darwin shoutcast server as a client.

   The principal problems with operation at IETF 62 hinge around the
   operation of the managment workstation.  While software makes it
   possible to monitor all of the servers and audio streams for
   availability, it's infeasbile for the workstation user to monitor
   more than one of the audio streams a time.  If only one operator is
   working at a time, traveling from the noc to a room where an issue is
   present (loss of network connectivity, no audio, poor audio) results
   in dividing that person's attention.  While the managment workstation
   resided in the noc and sat on the same network with the streaming
   servers, switching over to the wireless network for debuging  was
   hampered by the tenuous state of the wireless network early in the
   meeting, and to the extent that things like audio streams would not
   stay up while roaming between ap's (ie. running from one end of the
   building to the other with a laptop) continued to remain elusive
   throughout the meeting.

   Given some of the shortcomings only a few screwup's resulted in the
   the loss of recordings, Fewer even than would ordinarily be expected
   from the video recording, despite a four-fold increase in the amount
   of recording.  Some of this stability increase can likely been
   attributed to the elimination of Windows NT and 2000 based servers
   entirely (no crashes other than the manangment workstation), but a
   greater part was part was probably played by the simplification in
   the encoding, and a reduction in the number of operators to 2 rather
   than 6 or 8 required for the multicast delivery and camera operation.

4.5  Audience

   For the first time, a remote audience received almost complete access
   to the proceedings of the IETF as they happened.  Because delivery of
   the audio was entirely unicast we have logs that provide a far more
   accurate picture of the size of the audience.



Jaeggli                 Expires December 10, 2005              [Page 11]

Internet-Draft                  IETFTV-NG                      June 2005


   Over the course of the Week at IETF 62, 552 unique hosts made 4409
   requests that resulted in data being streamed.  Of those requestes,
   702 where made from the conference network.

   Feedback, from remote users was generally positive, however it points
   to a few kinks that could stand to be be rectified.  Some commentors
   noted that not all slide decks where available at the time a working
   group met.  Microhpone protocol was not universally observed
   particulary in small groups although this improved by the end of the
   week.  In the example of the snmp mib working group the 5 particpants
   in the room included an area director and the working-group chair,
   another area director followed along remotely...

   There appears to be substantial interest on the part of local
   participants at the ietf meeting to monitor sessions in which they
   are not physicaly participating.  If slightly less than a quater of
   all monitoring occurs from the local network it speaks well to the
   accessibility of the audio streaming to the group, for which the
   multicast streaming was not previously accessible.
































Jaeggli                 Expires December 10, 2005              [Page 12]

Internet-Draft                  IETFTV-NG                      June 2005


5.  The Future

   When we planned the transition to audio-only unicast streaming for
   IETF62, the intention was to field a service that was inexpensive
   enough that it could be replicated at subsequent IETF meetings.  I
   believe that goal has been achieved.  Assuming the same sources are
   willing to provide funding at similar levels into the future there is
   no reason to believe that we couldn't replicate the exercise at IETF
   63, and beyond.


Author's Address

   Joel Jaeggli
   University of Oregon
   1212 University of Oregon
   Eugene, Oregon  97405
   USA

   Phone: +1-541-346-1716
   Fax:   +1-5413464397
   Email: joelja@uoregon.edu





























Jaeggli                 Expires December 10, 2005              [Page 13]

Internet-Draft                  IETFTV-NG                      June 2005


Appendix A.  Appendix 1 - IETFTV BOF summary

      From falk@isi.edu Tue Dec  7 13:45:26 2004

      Date: Tue, 7 Dec 2004 13:44:53 -0800

      From: Aaron Falk falk@isi.edu

      To: minutes@ietf.org

      Cc: ietfcast@lists.uoregon.edu

      Subject: ietfcast: ietf-tv summary for the IETF-61 proceedings

   Summary of the IETF-TV BoF

      BoF Chair: Ole Jacobsen

      Notes taken by: Aaron Falk

   The purpose of the IETF-TV BoF was to discuss in what way multimedia
   capture of IETF meetings would best serve the community.  Multicast
   was used by volunteers to provide audio and digital whiteboard tools
   starting in 1992.  Tools and encoding formats evolved over the years
   until the present day where two rooms at each IETF are covered using
   MPEG-1 video and H.261/PCM audio four additional rooms with MP3 audio
   only.  The streams are made available using ASM and SSM multicast
   (some individuals provide unicast reflectors) and the files are post-
   processed and stored in an online repository for viewing after the
   meeting.

   At IETF-60, there were about 20 "viewers" per meeting (ed: IETF or wg
   meeting?) with a peak of about 70.  Feedback from the audio-only
   sessions was that it was hard to follow the meeting without some
   visual feedback, preferably the ability to view the slides.  There
   have been 100's to 1000's of downloads of online files.

   The staffing and travel and equipment expenses have been borne by
   University of Oregon (UofO) with some assistance from Cisco and the
   IETF Chair fund.  Typical requirements are 6 weeks/year for
   preparation; staffing and post-processing, 4-6 people (historically
   students) to operate the equipment during the IETF meeting; $10k for
   shipping (ed: per meeting? per year?); bandwidth for streaming and
   download (broadband, real-time bandwidth and server requirements are
   non-trivial).  However, most of the expense is associated with the
   video capture: camera operators (labor and travel) and specialized
   equipment are required.  The UofO is unwilling to shoulder staffing,
   and has run out of Cisco-provided funding that allowed their staff to



Jaeggli                 Expires December 10, 2005              [Page 14]

Internet-Draft                  IETFTV-NG                      June 2005


   travel and ship their equipment.  The UofO never provided any
   significant financial support outside of staff.  Several questions
   therefore arise:

   What problem is being solved by this service?  Remote participation?
   Broadcast to a remote (non-participatory) audience?  Creating a
   public record?

   It is estimated that a professional staff would cost about ~$50k/
   meeting (based on similar hotel events).  Various strategies of cost
   recovery were discussed including increasing meeting fees (~$25),
   charging online viewers ($100), selling CDs (~$100ea) or finding
   sponsors (~$25k/yr).  There was a general conclusion that some form
   of service is useful and of interest but there were no clear
   recommendations identifying a primary audience or of cost recovery.

   No working group will be created from this BoF.

      ietfcast resources:
      _________________________________________________

      user interface: http://darkwing.uoregon.edu/~llynch/ietfcast.html

      web archive:
      http://darkwing.uoregon.edu/~llynch/ietfcast/index.html


























Jaeggli                 Expires December 10, 2005              [Page 15]

Internet-Draft                  IETFTV-NG                      June 2005


Appendix B.  Appendix 2 - Possible Hardware Configuration

   One of The lessons to be taken away from previous efforts is that
   shipping and maintenance of the equipment necessary to provide the
   former service was one of the most expensive and time-consuming parts
   of the effort.  With that mind, and the goal of simplifying the
   equipement, a more compact, rugged, and inexpensive computer is
   needed.  The actual cpu requirements for audio encoding are
   signficantly more lightweight than delivering mpeg-4 video, a great
   assistance in reducing the scale of the equipment necessary to
   support this effort.

   One possible configuration that would be appropriate for our
   application follows (all costs are approximate):

   o  Casetronic c134 aluminum chassis (dimesions 177 x 50 x 254mm) 60w
      external powesupply        $150

   o  Via epia m1000 mainboard integrated ethernet, sound, video,
      ieee1394, usb2 1ghz via c3 cpu $160

   o  256MB unbuffered pc2100 ddr dimm memory module $50

   o  40GB 2.5" laptop harddrive $80

   o  cable lock $20

   o  Total: $460























Jaeggli                 Expires December 10, 2005              [Page 16]

Internet-Draft                  IETFTV-NG                      June 2005

Full Copyright Statement

   "Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights."

   "This document and the information contained herein are provided
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
   EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
   THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
   ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
   PARTICULAR PURPOSE."

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.


Jaeggli                 Expires December 10, 2005              [Page 17]

Internet-Draft                  IETFTV-NG                      June 2005


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Jaeggli                 Expires December 10, 2005              [Page 18]


</pre></body></html>