INTERNET DRAFT Richard Hodges
Document: draft-hodges-dtv-chanchange-00.txt Matriplex, inc.
Expires: January, 2002 August, 2001
Digital TV Channel Changing Protocol
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [2].
Abstract
Advances in video compression techniques and new technology for
delivering broadband services are making digital television (DTV)
services practical and marketable. One of the missing elements is a
flexible and open protocol for DTV clients to request desired
video/audio streams, or "channel changing".
This document describes a protocol that a client may use to change
DTV channels, and how servers may authenticate the client, authorize
the requested streams, perform viewership accounting, and form a
reply to inform the client on the status of the request.
1. Terminology
This section defines some terms that are used in the rest of this
document:
Hodges [Page 1]
Internet-Draft Digital TV Channel Changing Protocol July, 2001
Digital Television (DTV) : This is any service that provides video
and audio continuously to a client over some kind of data network.
It is expected that many different streams will be available at any
given time, and the client may select any of them (change channels)
subject only to administrative controls. MPEG2 or MPEG1 will likely
be used for video compression, but others may be used as desired.
DTV-CCP : This is the Digital TV Channel Changing Protocol described
in this document. This includes the packet structure itself and the
methods used by the DTV clients and servers.
AAA : This term refers to the authentication, authorization, and
accounting functions described below.
Authentication : This is the service that determines whether the
client request is genuine. Both client and authentication server
share a common secret, also known as the client key, or password.
The key is not transmitted, but is used by the client to sign the
request with an MD5 hash, and for the server to verify the MD5 hash.
Authorization : This is the service that checks the client request to
verify that the client is eligible to receive the requested DTV
channel. A simple implementation may check only the client and the
requested DTV channel. A more featureful server may also allow or
deny access based on requested bitrate, time of day, encapsulation
options, or any other useful criteria.
Accounting : This is an optional service that tracks the client DTV
requests, and provides statistical information for the DTV service
provider on DTV channel viewership. This would typically be used to
graph DTV viewership to see how many clients were on an given DTV
channel at any one time. The actual implementation may decide the
resolution, which may be viewer-minutes or some fraction thereof.
This information can be invaluable to advertisers and to DTV service
managers that need to know which programs are popular, and which are
not.
Sub-ID : This is a number that uniquely identifies a particular
client where multiple clients exist at one location. This may be the
case where a residence has a set-top box with multiple video
decoders. In this case, the network and/or hardware address may be
identical, and the sub-id number is needed to identify the client
making the request.
2. Current DTV Channel Changing Methods
One simple method that has some success is for each DTV channel to be
transmitted on its own multicast address. The network listens for
Hodges [Page 2]
Internet-Draft Digital TV Channel Changing Protocol July, 2001
IGMP requests from clients, and forwards the appropriate multicast
group traffic to the clients that want to receive those channels
(groups).
Since most network clients are capable of receiving IP multicast
traffic and generating the neccessary IGMP messages, very little
effort is needed to build and evaluate such a DTV service.
3. Problems with IGMP for Channel Changing
IGMP has some advantages, notably simplicity and relatively mature
industry support. There are five noteworthy drawbacks, however.
First, there is no inherent mechanism for authenticating the client.
The client IP address may be taken from the IP header, but it is not
difficult for a malicious or misconfigured host to send an IGMP
packet with any arbitrary source address. While it may be possible
to add IP security functionality to the network switches, this may be
impractical for cost or administrative reasons.
Second, the client has no way to specify optional video or audio
options, such as encoding methods. Nor is there any way for the
client to request a particular encapsulation method (such as RTP) or
transport (eg, ethernet or ATM).
Third, IGMP does not provide for immediate termination of a group's
multicast traffic. When the DTV bandwidth is a major percentage of
the available link capacity, it is imperative that the network
discontinue the old channel to that client before starting to send
the new channel. Otherwise, the link bandwidth will be exceeded and
packets will be dropped, resulting in corrupted video and audio at
the client, and an unacceptable viewing experience.
Fourth, IGMP, as implemented in typical switches, does not have any
inherent authorization mechanism. In other words, if a client makes
a request (via IGMP) for a DTV channel, the switch will simply
provide that stream. Adminstrative control over DTV channels may be
somewhat of a challenge when using IGMP for switching DTV.
Fifth, IGMP is unidirectional. The client does not receive any
acknowlegement, and must wait for the new stream to start arriving in
order to know whether the request was accepted and acted upon. This
makes it difficult for the client to discern whether the IGMP packet
was lost, late, or ignored.
4. DTV-CCP Benefits and Requirements
The packet structure and methods described in this document should
Hodges [Page 3]
Internet-Draft Digital TV Channel Changing Protocol July, 2001
provide the neccessary functionality to implement a DTV channel
changing system. This system can provide for administrative control
over the network assets (DTV channels) and also the flexibility that
facilitates transport over non-ethernet networks (ATM for example).
The authentication, authorization, and accounting functions may be
contained within a single server, or separated into different ones,
allowing for customization and/or scalability.
5. DTV-CCP Packet Structure
The DTV request packet is 100 bytes long, and contains an MD5 hash
that the receiver can use to verify the identity of the sender.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Encapsulation | Option-Audio | 0000 | Auth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Desired Bandwidth Minimum | Desired Bandwidth Maximum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old (leaving) DTV Channel | New (joining) DTV Channel |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client ID Number (or Sub-ID number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client IP4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Client IP6 Address |
| (16 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Client ATM Address |
| (20 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast IP4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast IP4 Port# | AAA Flags | Fail Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Reserved for future use |
| Client sets all 16 bytes to zero |
| |
Hodges [Page 4]
Internet-Draft Digital TV Channel Changing Protocol July, 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MD5 Hash of entire packet |
| Including Following Key |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Secret Hash Key |
| NOT transmitted |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Offset Bytes Field
0 1 version number (set to 1)
1 1 encapsulation method (bitfield flags)
2 1 audio options (language and/or encoding method)
3 1 authentication options, MD5 or other
4 4 request sequence number (client increments)
8 2 bandwidth minimum, times 1000 bits/second
10 2 bandwidth maximum, times 1000 bits/second
12 2 channel old (leaving this channel, zero=no data)
14 2 channel new (joining this channel, zero=no data)
16 4 client ID (client sets to sub-ID, or zero)
20 4 client IP4 address (or server if reply)
24 16 client IP6 address (or server if reply)
40 20 client ATM address (or server if reply)
60 4 multicast IP address (server informs client)
64 2 multicast port (server informs client)
66 1 Server AAA flags, shows AAA progress
67 1 Failure reason code, zero if successful
68 16 reserved (set to zero)
84 16 MD5 hash of packet (including following key)
100 16 Secret key for authenticating packet (NOT transmitted)
The version number should be set to 1.
The encapsulation field may contain one or more of the following
flags:
ENCAPS_ETHER 0x01 Include 14-byte ethernet header
ENCAPS_IPUDP 0x02 Package datagram in an IP UDP packet
ENCAPS_RTP 0x04 Add an RTP (12 byte) header
ENCAPS_AAL5 0x08 Use ATM, send in an AAL5 PDU
ENCAPS_AAL1 0x10 Use ATM, send in AAL1 cells
ENCAPS_LOCAL 0x80 Private or proprietary method
Many encapsulation methods are possible, for instance:
ETHER + IPUDP: Send as IP/UDP packets over ethernet.
ETHER + IPUDP + RTP: Send as IP/UDP RTP packets over ethernet.
Hodges [Page 5]
Internet-Draft Digital TV Channel Changing Protocol July, 2001
ETHER + AAL5 + IPUDP: Send as IP/UDP over ATM, RFC1483/bridged.
AAL5 + IPUDP: Send as IP/UDP over ATM, RFC1483/routed.
AAL5: Send raw in ATM AAL5 PDUs.
The audio options are reserved for further study. Set to zero.
The "other" options are reserved for further study. Set to zero.
The authentication option field should be set to zero for regular MD5
authentication. Values of 1 to 3 may be used for local or
experimental methods, and 4 to 15 are reserved for future methods. A
server that does not understand the packet's authentication option
MAY set the option to zero (MD5) and continue the authentication
process. This may be useful as a primitive backwards compatibility
feature. Otherwise, if the server does not understand the
authentication option, it SHOULD handle the packet as a failed
authentication. Future versions of this protocol may have key
exchange features, and the packet fields may have different meanings
when the authentication option field has different values.
The request sequence number is an incrementing serial number. The
server(s) SHOULD use this number to discard duplicate requests or
ignore old requests that were delayed in transit. Since the client
is verified by the MD5 hash signature, there is no special denial of
service consideration with a third party injecting bogus sequence
numbers.
The bandwidth minimum and maximum fields are optional, and allow the
client to request the desired bandwidth for the new DTV channel. If
multiple presentations of the requested channel exist, the server
SHOULD use these values to choose the best fit, if administrative
controls allow. These values are in units of 1000 bits per second,
and the client may use zero to indicate no preference.
The channel old and channel new fields indicate the current channel
the client is receiving and the next desired DTV channel. The client
SHOULD set the "old" channel field. The client MAY set the "new"
channel to zero in order to discontinue DTV service. The exact
meaning of channel numbers is specific to the administrative goals of
the DTV provider, and the channel numbers MAY have different mappings
for different clients in order to provide customized presentations or
service offerings.
The client ID number is used to uniquely identify a client, and is
typically set by the authentication server for the convenience of the
other servers. The client MAY set this field to its client ID
number, if known. Otherwise, the client SHOULD set this field to its
"sub-ID" number to indicate which video decoder or player it is at
Hodges [Page 6]
Internet-Draft Digital TV Channel Changing Protocol July, 2001
that particular location. This "sub-id" number should start at one,
and has a maximum value of 99.
The client IP4 address field contains the client's IP4 address, or
zero if an IP6 or ATM address is used. If zero, the authentication
server should insert the correct address, if one is known.
The client IP6 address field contains the client's IP6 address, or
zeroes if an IP4 or ATM address is used. If zero, the authentication
server should insert the correct address, if one is known.
The client ATM address field contains the client's ATM address, or
zeroes if an IP4 or IP6 address is used. If zero, the authentication
server should insert the correct address, if one is known.
The multicast IP4 field is used in the reply to the client if the
stream is to be sent on a multicast group. This allows the channel
number to multicast group mapping to be hidden from the client, and
facilitates dynamic mapping, which may be neccessary if a channel is
available in multiple bandwidths or encapsulations. If IP multicast
is not used, this field MUST be set to zero.
The multicast IP port is the destination port number associated with
the multicast IP group described above. Set to zero if IP multicast
is not used for the DTV channel.
The AAA flags field indicates which of the AAA functions have been
successfully performed on the request. The client sets this field to
zero, and the servers set the flags as the request is handled. The
servers SHOULD use the flags in this field to avoid unneccessary
duplication of AAA effort.
AAAFLAG_AUTH1 1 Client has been identified
AAAFLAG_AUTH2 2 Client request has been authenticated (MD5 OK)
AAAFLAG_AUTH3 4 Client request is approved
AAAFLAG_ACCT 8 Client request has been logged
The fail reason code is a field that contains the error code (if any)
for a request, should it fail. Zero indicates no error.
RESULT_NOUSER 1 Client is unknown
RESULT_BADMD5 2 Request MD5 checksum is incorrect
RESULT_NOCHAN 3 Requested channel does not exist
RESULT_DENIED 4 Requested channel not approved
RESULT_BADREQ 5 General problem with request
RESULT_AAAFLAG 6 AAA flag field was not zero
Any fields marked "reserved" are for future use. Set these to zero.
Hodges [Page 7]
Internet-Draft Digital TV Channel Changing Protocol July, 2001
The MD5 hash field contains the 128-bit MD5 hash of the packet and
the secret key to authenticate the sender. This field should be
cleared to zero before actually computing the MD5 hash. The client
MUST compute the hash for every DTV request packet it sends.
The secret key is a 128-bit field immediately following the packet
data, and is included when computing the MD5 hash. It MUST NOT be
transmitted. Since the request packet is 100 bytes long, the MD5
hash will be computed on 116 bytes. The key does not have to have a
length of 128 bits, and may be created from an ASCII password or
other means. In case the keylength is less than 128 bits, the unused
bits MUST be set to zero, and the key MUST be "left justified"
(lowest addresses occupied first). This is to ensure that all hosts
can agree on how to handle short keys.
6. DTV-CCP Client Methods
When a client wants to initiate service, change channels, or stop DTV
service, it sends a DTV request packet to its designated server.
This server may be the actual video encoder, but is more likely to be
a server that will be the first in a chain, eventually passing the
request to the video encoder or network element that handles the
video streams.
The client sets the packet fields as follows:
1. Version is 1.
2. Set the desired encapsulation flags.
3. Set the audio and "other" option flags (or zero).
4. Increment the request sequence number and store it.
5. Set the desired minimum and maximum bandwidth, or zero.
6. Set the old channel number, or zero if starting service.
7. Set the new channel number, or zero if terminating service.
8. Set the client ID number if known, otherwise store the
sub-ID number (unique identifier at that location, 1 <= x <= 99)
9. Set one or more of the client IP4, IP6, and ATM addresses.
10. Clear all other unused or reserved fields.
11. Insert the client key into the secret hash key field.
12. Clear the MD5 hash field.
13. Compute the MD5 hash of the packet data and the key field.
14. Store the resulting MD5 hash in the MD5 hash field.
15. Send the packet to the designated server. If using UDP,
the port number is 2253.
The client MAY close the current DTV channel connection before or
immediately after sending the request packet. This may give better
channel changing performance on certain types of networks. Or the
client MAY wait until receiving the DTV request reply before closing
Hodges [Page 8]
Internet-Draft Digital TV Channel Changing Protocol July, 2001
or otherwise affecting the current DTV channel stream. It may be
advantageous to add another DTV request packet field to allow the
client to state its intentions on this matter, but that is a topic
for future study.
The client SHOULD take steps to ensure that the request sequence
number is always increasing, even if the client restarts. Using the
system (32 bit) time value as an initial value is one way to achieve
this goal.
After sending the DTV request packet, the client SHOULD receive and
inspect the reply to learn the status of the request. If using UDP,
the client SHOULD listen on the DTV request port (2253) so that the
server does not receive an ICMP "unreachable" message.
If the client does not receive a reply in a reasonable amount of
time, it MAY resend the exact same packet with the same sequence
number, and MAY repeat as desired until it receives a reply.
If the client receives a reply indicating that the request failed, it
MAY compose a new request, changing one or more fields that may lead
to approval by the servers. The client SHOULD NOT send a duplicate
request, since the server will certainly refuse that too.
Upon receiving a reply indicating approval, the client should use the
packet information to start receiving the new DTV channel stream. In
particular, the client should inspect the encapsulation, audio
option, and multicast IP fields for guidance on how to prepare to
start receiving the new DTV channel. The client should take the
appropriate steps to close or stop the old DTV channel stream, if it
has not already done so.
7. DTV-CCP Server Methods
The DTV request server is actually one or more servers providing one
or more of the AAA functions: authentication, authorization, and
accounting. In principle, these servers can be deployed in a network
in most any order, but in practise they will probably work best if
organized so that they are in "obvious" order:
1. Authentication: Who are you? Prove it.
2. Authorization: Are you authorized to get this DTV channel?
3. Accounting: How many clients were watching channel x?
For scalability, it is easy to deploy many authentication servers,
each one serving a subset of the total client base. After verifying
the client requests, they forward the requests to the next server
which checks the request against general policy or the specific
rights for that particular client. The "authorized" packet is then
Hodges [Page 9]
Internet-Draft Digital TV Channel Changing Protocol July, 2001
forwarded to a network device (possibly the video encoder) that
manages the network to cause that DTV channel to be available to the
client. The accounting server is optional, and should be used just
after the authorization server.
In a small to medium sized deployment, all three functions may be
located in the same server.
Authentication: When the authentication server receives a DTV
request packet, it should determine the client's identity and then
verify the packet by computing the correct MD5 checksum based on the
secret key known to be correct for that client.
Once the client has been identified, the server MUST fill in the
client ID number, the IP4, IP6, and ATM addresses from its local
information (known to be correct). This prevents a client from
impersonating another client, and possibly disrupting service. This
also means that the sub-ID and address information provided by the
client is not trusted, but is simply used as a "hint" when looking
for the client key to use to validate the packet.
When the client is identified the server sets the "AUTH1" flag in the
AAA field to indicate that a client match was found.
When the request MD5 checksum has been checked, and the request is
known to be genuiune, the server sets the "AUTH2" flag in the AAA
field to indicate that the client did make this request.
If a client sends a request with a non-zero flags field, the server
MAY zero the field and continue normal processing. Otherwise, the
server MUST return the request to the client with fail reason 6,
"AAAFLAG". In both cases, it is RECOMMENDED that the server log this
event appropriately.
After validating the packet and inserting correct ID and address
information, the authentication server signs the packet with its own
key and forwards it to the next server in line. This will most
likely be the authentication server.
The authorization server checks the request's MD5 checksum to verify
the signature from the authentication server. If the MD5 hash does
not match the previous server, the authorization MUST discontinue
processing, and either return it to the client with failure code 6,
"system" (RECOMMENDED), or alternately it MAY forward the request to
the authentication server for validation. If the latter case is
chosen, the servers should take measures to prevent processing loops
or potential denial of service attacks. To protect client privacy,
the authorization server SHOULD NOT provide "what if" information to
Hodges [Page 10]
Internet-Draft Digital TV Channel Changing Protocol July, 2001
a client that has not been authenticated.
After checking local administrative policy and/or permissions for the
client, the authorization server either rejects the request or
approves it, and forwards the request to the next server (probably
the accounting server). In the case of failure, the server sets the
failure code appropriately and forwards the request to the client.
If the request is approved, the server sets the "AUTH3" flag in the
AAA field to indicate that the request is approved.
The accounting server should verify that the MD5 hash signature is
from a trusted server (probably the authorization server), and logs
the request appropriately. This will probably include updating
viewership totals for the DTV channels for storage in a database or
other uses. After logging the request, the accounting server sets
the "ACCT" flag in the AAA field, signs the request with its MD5
signature, and forward the request to the next server, which will
probably be a network device that handles the actual channel stream
switching.
Information from the accounting server can take any form useful to
the implementor, and will probably include channel viewership
statistics by the minute. It is also possible to track daily
summaries of how many minutes a client spent on each channel for a
particular day. If the accounting server has knowlege of special
time slots (eg, advertising), it might track the percentage of
viewers that changed channels during that spot. Knowlege of what the
viewers will (and won't) watch can be a useful tool in providing
programming that better serves the clients.
If one or more of these AAA functions are colocated in the server,
and have trusted communications paths, some of the MD5 signing may be
unneccessary. This may be the case where a single server handles all
three AAA functions. In this case, there is no need to compute and
test the intermediate MD5 hashes.
8. Security Considerations
This protocol provides for client authentication via an MD5 hash. So
long as both client and server protect the shared secret, this
protection is as strong as the key length and the MD5 algorithm
itself. Initial key exchange is an implementation detail not covered
in this document.
No explicit encryption is defined or recommended by this document.
An implementation may encrypt the payload in some manner that is
invisible to this protocol. Such an implementation may also elect to
incorporate an appropriate key exchange as well.
Hodges [Page 11]
Internet-Draft Digital TV Channel Changing Protocol July, 2001
9. References
1 Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April, 1992
2 Schulzrinne, H, et al, "RTP: A Transport Protocol for Real-TIme
Application", RFC 1889, January 1996
3 Hoffman, D, et al, "RTP Payload Format for MPEG1/MPEG2 Video",
RFC 2250, January 1998
4 Fenner, W, "Internet Group Management Protocol, Version 2",
RFC 2236, November 1997
5 Heinanen, J, "Multiprotocol Encapsulation over ATM Adaptation
Layer 5", RFC 1483, July 1993
10. Author's Addresses
Richard hodges
Matriplex, inc.
769 Basque Way
Carson City, NV 89706
Phone: (775) 886-6477
Email: rh@matriplex.com
Please direct all comments to rh@matriplex.com
This Internet-Draft expires January, 2002.
Full Copyright Statement
"Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
Hodges [Page 12]
Internet-Draft Digital TV Channel Changing Protocol July, 2001
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on as
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Hodges [Page 13]