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>
