FEC Framework A. Begen
Internet-Draft Cisco Systems
Intended status: Standards Track November 11, 2007
Expires: May 14, 2008
SDP Elements for FEC Framework
draft-begen-fecframe-sdp-elements-00
Status of this Memo
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.
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 May 14, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document specifies the use of Session Description Protocol (SDP)
to describe the parameters required to signal the Forward Error
Correction (FEC) Framework Configuration Information between the
sender(s) and receiver(s). This document also provides the semantics
for grouping multiple source and repair flows together for the
applications that simultaneously use multiple instances of the FEC
Framework.
Begen Expires May 14, 2008 [Page 1]
Internet-Draft SDP Elements for FEC Framework November 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Forward Error Correction (FEC) and FEC Framework . . . . . . . 3
3.1. Forward Error Correction (FEC) . . . . . . . . . . . . . . 3
3.2. FEC Framework . . . . . . . . . . . . . . . . . . . . . . 4
3.3. FEC Framework Configuration Information . . . . . . . . . 4
4. FEC Framework Descriptors . . . . . . . . . . . . . . . . . . 6
4.1. Transport Protocol Identifiers . . . . . . . . . . . . . . 6
4.2. Media Stream Grouping . . . . . . . . . . . . . . . . . . 6
4.3. Source IP Addresses . . . . . . . . . . . . . . . . . . . 7
4.4. Source Flows . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Repair Flows . . . . . . . . . . . . . . . . . . . . . . . 8
4.6. Minimum Buffer Size . . . . . . . . . . . . . . . . . . . 9
4.7. Bandwidth Specification . . . . . . . . . . . . . . . . . 10
5. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Session Announcement Considerations . . . . . . . . . . . 11
5.2. Offer/Answer Considerations . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. Transport Protocols . . . . . . . . . . . . . . . . . . . 11
7.2. Attribute Names . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Begen Expires May 14, 2008 [Page 2]
Internet-Draft SDP Elements for FEC Framework November 2007
1. Introduction
The Forward Error Correction (FEC) Framework, described in
[I-D.ietf-fecframe-framework], outlines a general framework for using
FEC-based error recovery in packet flows carrying media content.
While a continuous signaling between the sender(s) and receiver(s) is
not required for a Content Delivery Protocol (CDP) that uses the FEC
Framework, a set of parameters pertaining to the FEC Framework MUST
be initially communicated between the sender(s) and receiver(s).
One way to communicate this information is to use the Session
Description Protocol (SDP)[RFC4566]. SDP provides a simple text-
based format for announcements and invitations to describe multimedia
sessions. These SDP announcements and invitations include sufficient
information for the sender(s) and receiver(s) to participate in the
multimedia sessions. SDP also provides a framework for capability
negotiation, which MAY be used to negotiate all or a subset of the
parameters pertaining to the individual sessions.
The purpose of this document is to introduce the SDP elements that
MUST be used by the CDPs using the FEC Framework that choose SDP
[RFC4566] as their session description protocol.
2. Requirements Notation
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 [RFC2119].
3. Forward Error Correction (FEC) and FEC Framework
This section gives a brief overview of FEC and the FEC Framework.
3.1. Forward Error Correction (FEC)
Any application that needs a reliable transmission over an unreliable
packet network has to cope with the packet losses. FEC is an
effective approach that provides reliable transmission particularly
in multicast and broadcast applications where the feedback from the
receiver(s) may be potentially limited. In a nutshell, FEC groups
source packets into blocks and applies protection to generate a
desired number of repair packets.
Repair packets MAY be sent on demand or independently of any receiver
feedback. The choice depends on the FEC code used by the
application, the error characteristics of the underlying network, the
Begen Expires May 14, 2008 [Page 3]
Internet-Draft SDP Elements for FEC Framework November 2007
transport scheme (e.g., unicast, multicast, and broadcast), and the
application. At the receiver side, lost packets can be recovered by
erasure decoding provided that a sufficient number of source and
repair packets are received. See [I-D.ietf-fecframe-framework] for
further details.
3.2. FEC Framework
The FEC Framework [I-D.ietf-fecframe-framework] outlines a general
framework for using FEC codes in multimedia applications that stream
audio, video or other types of multimedia content. It defines the
common components and aspects of Content Delivery Protocols (CDP).
The FEC Framework also defines the requirements for the FEC schemes
that need to be used within a CDP. However, the details of the FEC
schemes are not specified within the FEC Framework. For example, the
FEC Framework defines what configuration information has to be known
at the sender and receiver(s) at minimum, but the FEC Framework
neither specifies how the FEC repair packets are generated and used
to recover missing source packets, nor dictates how the configuration
information is negotiated or signaled between the sender and
receiver(s). These are rather specified by the individual FEC
schemes or CDPs.
For a proper operation, the information required by the FEC Framework
and the details of an FEC scheme have to be communicated between the
sender and receiver(s). One way to provide this information is to
use the Session Description Protocol (SDP)[RFC4566]. SDP provides a
commonly used text-based format for announcements and invitations
that describe multimedia sessions. These SDP announcements and
invitations include sufficient information for clients to participate
in multimedia sessions. By using the SDP capability negotiation
framework, all or a subset of the parameters pertaining to the FEC
Framework MAY also be negotiated between the sender and receiver(s).
The purpose of this document is to introduce the SDP elements that
MUST be used by the CDPs using the FEC Framework that choose SDP as
their session description protocol.
3.3. FEC Framework Configuration Information
The FEC Framework defines a minimum set of information that MUST be
communicated between the sender and receiver(s) for a proper
operation of an FEC scheme. This information is called the FEC
Framework Configuration Information. This information specifies how
the sender applies protection to the source flow(s) and how the
repair flow(s) can be used to recover lost data. In other words,
this information specifies the relationship(s) between the source and
repair flows.
Begen Expires May 14, 2008 [Page 4]
Internet-Draft SDP Elements for FEC Framework November 2007
The FEC Framework Configuration Information includes identifiers for
unique identification of the source and repair flows that carry the
source and repair packets, respectively. For example, a packet flow
that is transmitted over UDP is uniquely identified by a tuple
{Source IP Address, Destination IP Address, Source UDP port,
Destination UDP port}. However, an integer identifier MAY be used
internally within the FEC scheme as a shorthand to identify this
flow.
Multiple instances of the FEC Framework MAY simultaneously exist at
the sender and the receiver(s) for different source flows, for the
same source flow, or for various combinations of source flows. Each
instance of the FEC Framework MUST provide the following FEC
Framework Configuration Information:
1. Identification of the repair flows.
2. For each source packet flow protected by the FEC repair flow(s):
a. Definition of the source flow.
b. An integer identifier for this flow definition (i.e., tuple).
This identifier MUST be unique amongst all source flows that are
protected by the same FEC repair flow. The identifiers SHOULD be
allocated starting from zero and increasing by one for each flow.
A source flow identifier need not be carried in source packets
since source packets are directly associated with a flow by virtue
of their packet headers. Note that an application MAY wildcard
some of the fields if only a subset of the fields of the tuple
(e.g., {Destination IP Address, Destination UDP port} ) is
sufficient.
3. The FEC Scheme ID that identifies the FEC scheme.
4. The length of the Source FEC Payload ID (in bytes).
This value MAY be zero indicating that no Explicit Source FEC
Payload ID is used by the FEC scheme. However, in the case that
the Explicit Source FEC Payload ID is used, then only one FEC
scheme MUST be used for this source flow, unless the generic tag
is used by all of the FEC schemes protecting this source flow.
5. An opaque container for the FEC-Scheme-Specific Information
(FSSI).
FSSI includes the information that is specific to the FEC scheme used
by the CDP. FSSI is used to communicate the information that cannot
Begen Expires May 14, 2008 [Page 5]
Internet-Draft SDP Elements for FEC Framework November 2007
be adequately represented otherwise and is essential for the proper
FEC decoding operation. FSSI is transmitted in a variable-length
opaque container that carries an octet string. The FEC schemes
define the structure of this octet string, which MAY contain multiple
distinct elements. If the FEC scheme does not require any specific
information, the FSSI MAY be null.
For the fully-specified FEC schemes, a full description of the
encoded information MUST be provided. See
[I-D.ietf-fecframe-framework] for details.
4. FEC Framework Descriptors
This section defines the SDP elements that MUST be used to describe
the FEC Framework Configuration Information in multimedia sessions by
the CDPs that choose SDP [RFC4566] as their session description
protocol. Example SDP configurations can be found in Section 5.
4.1. Transport Protocol Identifiers
This specification defines a class of new transport protocol
identifiers for SDP media descriptions. For all existing identifiers
<proto>, this specification defines the identifier 'fec/<proto>'.
This identifier MAY be used as the transport protocol identifier in
the media descriptions for the source data to indicate that the FEC
Source Packet format defined in Section 6.3 of
[I-D.ietf-fecframe-framework] is used, where the original transport
payload field is formatted according to <proto>. However, if the FEC
scheme does not use the Explicit Source FEC Payload ID described in
Section 6.3 of [I-D.ietf-fecframe-framework], then the original
transport protocol identifier MUST be used to support backward
compatibility with the receivers that do not support FEC at all.
This specification also defines another transport protocol
identifier, 'udp/fec', to indicate the FEC Repair Packet format
defined in Section 6.4 of [I-D.ietf-fecframe-framework].
4.2. Media Stream Grouping
The FEC Framework [I-D.ietf-fecframe-framework] states that multiple
instances of the FEC Framework MAY exist at the sender and the
receiver(s), and a source flow MAY be protected by multiple FEC
Framework instances. Furthermore, within a single FEC Framework
instance, multiple source flows MAY be protected by multiple repair
flows. However, each repair flow MUST provide protection for a
single FEC Framework instance. An example relationship between the
source and repair flows is shown in Figure 1. Here, source flows 1
Begen Expires May 14, 2008 [Page 6]
Internet-Draft SDP Elements for FEC Framework November 2007
and 2 are grouped together and protected by the repair flows 4 and 5;
source flow 1 is protected by the repair flow 6; source flows 2 and 3
are grouped together and protected by the repair flows 7, 8 and 9.
_____| FEC FRAMEWORK
/ | 4: Repair Flow
/ | 5: Repair Flow
/
SOURCE FLOWS / __| FEC FRAMEWORK
1: Source Flow |___/ |---' | 6: Repair Flow
2: Source Flow | |____
3: Source Flow | \ | FEC FRAMEWORK
\ | 7: Repair Flow
\_| 8: Repair Flow
| 9: Repair Flow
Figure 1: Relationship between the source and repair flows
The 'group' attribute and the FEC grouping semantics defined in
[RFC4756] are used to associate source and repair flows together with
the following additional requirement:
In the case that the Explicit Source FEC Payload ID is used, then
only one FEC Scheme MUST be used for this source flow, unless the
generic tag is used by all of the FEC Schemes for the Source FEC
Payload ID field, as defined in [I-D.ietf-fecframe-framework].
The 'group' attribute MAY be used to associate multiple repair flows
with one or more source flows. This means that the repair flows MAY
be used together in an additive manner.
To let the receivers know the order which they MUST use the repair
flows MAY be communicated by using the parameter 'priority' of the
attribute 'fec-repair-flow'. See Section 4.5 for details.
4.3. Source IP Addresses
The 'source-filter' attribute of SDP ("a=source-filter") as defined
in [RFC4570] is used to express the source addresses or fully
qualified domain names in the FEC Framework.
Editor's note: Additional requirements or exceptions regarding
source filters are TBD.
Begen Expires May 14, 2008 [Page 7]
Internet-Draft SDP Elements for FEC Framework November 2007
4.4. Source Flows
The FEC Framework allows that multiple source flows MAY be grouped
and protected together by a single or multiple FEC Framework
instances. For this reason, as described in Section 3.3, individual
source flows MUST be identified with unique identifiers. For this
purpose, we introduce the attribute 'fec-source-flow'.
The syntax for the new attribute in ABNF [RFC4234] is as follows:
fec-source-flow-line = "a=fec-source-flow:" source-id
[";" SP tag-length] CRLF
source-id = "id=" src-id
src-id = 1*DIGIT
tag-length = "tag-len=" tlen
tlen = *DIGIT
The MANDATORY parameter 'id' is used to identify the source flow.
The OPTIONAL 'tag-len' parameter is used to specify the length of the
Source FEC Payload ID (in bytes) and MUST be used according to the
requirements listed in Section 4.2. If no value is specified for the
'tag-len' parameter, it indicates a value of zero.
4.5. Repair Flows
A repair flow MUST contain only repair packets formatted as described
in [I-D.ietf-fecframe-framework] for a single FEC Framework instance.
In other words, packets belonging to source flows or other repair
flows from a different FEC Framework instance MUST NOT be sent within
this flow. We introduce the attribute 'fec-repair-flow' to describe
the repair flows.
The syntax for the new attribute in ABNF is as follows:
Begen Expires May 14, 2008 [Page 8]
Internet-Draft SDP Elements for FEC Framework November 2007
fec-repair-flow-line = "a=fec-repair-flow:" fec-scheme-id
[";" SP flow-priority] [";" SP fec-scheme-specific] CRLF
fec-scheme-id = "scheme-id=" sch-id
sch-id = 1*DIGIT ; FEC scheme ID
flow-priority = "priority=" priority-of-the-flow
priority-of-the-flow = *DIGIT
fec-scheme-specific = "scheme-specific=" scheme-specific-info
scheme-specific-info = *CHAR
The MANDATORY parameter 'scheme-id' is used to identify the FEC
scheme used to generate this repair flow. These identifiers MUST be
registered with IANA by the FEC schemes that use the FEC Framework.
The OPTIONAL parameter 'priority' is used to indicate the priorities
of the repair flows when multiple repair flows are grouped together
to be used in an additive manner within a single FEC Framework
instance. The exact usage of the parameter 'priority' and the
pertaining rules SHOULD be defined by the FEC scheme or the CDP. If
no value is specified for the parameter 'priority', it means that the
receiver(s) MAY use the repair flows in any order.
The OPTIONAL parameter 'scheme-specific' is an opaque container to
convey the FEC-Scheme-Specific Information (FSSI) that includes the
information that is specific to the FEC scheme used by the CDP. FSSI
is transmitted in a variable-length opaque container that carries an
octet string. The FEC schemes define the structure of this octet
string, which MAY contain multiple distinct elements. If the FEC
scheme does not require any specific information, the FSSI MAY be
null.
4.6. Minimum Buffer Size
An FEC receiver usually needs to buffer source packets before it
receives the repair packets and can perform FEC decoding. The amount
of this buffer can be determined by the CDP or can be implementation
specific. This document specifies a new attribute to describe the
amount of buffer size in milliseconds.
The syntax for the attribute in ABNF is as follows:
Begen Expires May 14, 2008 [Page 9]
Internet-Draft SDP Elements for FEC Framework November 2007
min-buffer-size-line = "a=min-buffer-size:" buf-size-in-ms CRLF
buf-size-in-ms = 1*DIGIT ; in milliseconds
The "a=min-buffer-size" attribute is a media-level attribute since
each repair flow MAY have a different buffer requirement.
4.7. Bandwidth Specification
The bandwidth specification as defined in [RFC4566] denotes the
proposed bandwidth to be used by the session or media. The
specification of bandwidth is OPTIONAL.
In the context of the FEC Framework, the bandwidth specification can
be used to express the bandwidth of the repair flows or the bandwidth
of the session. If included in the SDP, it SHALL adhere to the
following rules:
The session-level bandwidth for an FEC Framework instance MAY be
specified. In this case, it is RECOMMENDED to use the Transport
Independent Application Specific (TIAS) bandwidth modifier [RFC3890]
and the 'a=maxprate' attribute for the session.
The media-level bandwidth for the individual repair flows MAY also be
specified. In this case, it is RECOMMENDED to use the TIAS bandwidth
modifier [RFC3890].
The Application Specific (AS) bandwidth modifier [RFC4566] MAY be
used instead of TIAS, however, this is NOT RECOMMENDED since TIAS
allows the calculation of the bitrate according to the IP version and
transport protocol, whereas AS does not. Thus, in TIAS-based bitrate
calculations, the packet size SHALL include all headers and payload,
excluding the IP and UDP headers. In AS-based bitrate calculations,
the packet size SHALL include all headers and payload, plus the IP
and UDP headers.
For the ABNF syntax information of the TIAS and AS, refer to
[RFC3890] and [RFC4566], respectively.
5. SDP Examples
This section provides SDP examples that can be used by the FEC
Framework.
Editor's note: We need to fill in SDP examples showing single and
multiple FEC Framework instances each using single or multiple repair
flows.
Begen Expires May 14, 2008 [Page 10]
Internet-Draft SDP Elements for FEC Framework November 2007
5.1. Session Announcement Considerations
In multicast-based applications, the FEC Framework Configuration
Information pertaining to all FEC protection options available at the
sender MAY be advertised to the receivers as a part of a session
announcement. This way, the sender can let the receivers know all
available options for FEC protection. Based on their needs, the
receivers MAY choose one or more protections and subscribe to the
respective multicast group(s) to receive the repair flow(s). Unless
explicitly required by the CDP, the receivers SHOULD NOT send an
answer back to the sender specifying their choices.
5.2. Offer/Answer Considerations
In unicast-based applications, a sender and receiver MAY adopt the
Offer/Answer Model [RFC3264] to set the FEC Framework Configuration
Information. In this case, the sender offers all available options
to the receiver and the receiver answers back to the sender with its
choice(s). Note that some FEC protection options MAY be offered to
only a particular set of (i.e., premium) receivers.
Eligible receivers MAY also use the SDP capability negotiation
framework [I-D.ietf-mmusic-sdp-capability-negotiation] to negotiate
all or a subset of the FEC Framework parameters.
6. Security Considerations
For the general security considerations related to SDP, refer to
[RFC4566]. For the security considerations related to source/FEC
media stream grouping in SDP and use of source address filters in
SDP, refer to [RFC4756] and [RFC4570], respectively.
7. IANA Considerations
7.1. Transport Protocols
The 'proto' sub-field of the media description field ("m=") describes
the transport protocol used. This document registers the following
two values:
UDP/FEC
DCCP/FEC
Begen Expires May 14, 2008 [Page 11]
Internet-Draft SDP Elements for FEC Framework November 2007
7.2. Attribute Names
As recommended by [RFC4566], the following attribute names should be
registered with IANA.
The contact information for the registrations is:
Ali Begen
abegen@cisco.com
SDP Attribute ("att-field"):
Attribute name: fec-source-flow
Long form: Pointer to FEC Source Flow
Type of name: att-field
Type of attribute: Media level
Subject to charset: No
Purpose: See this document
Reference: This document
Values: See this document
SDP Attribute ("att-field"):
Attribute name: fec-repair-flow
Long form: Pointer to FEC Repair Flow
Type of name: att-field
Type of attribute: Media level
Subject to charset: No
Purpose: See this document
Reference: This document
Values: See this document
SDP Attribute ("att-field"):
Attribute name: min-buffer-size
Long form: Minimum Buffer Size in Milliseconds
Type of name: att-field
Type of attribute: Media level
Subject to charset: No
Purpose: See this document
Reference: This document
Values: See this document
8. Acknowledgments
The author would like to thank the FEC Framework Design Team for
their inputs, suggestions and contributions.
9. References
Begen Expires May 14, 2008 [Page 12]
Internet-Draft SDP Elements for FEC Framework November 2007
9.1. Normative References
[I-D.ietf-fecframe-framework]
Watson, M., "Forward Error Correction (FEC) Framework",
draft-ietf-fecframe-framework-00 (work in progress),
February 2007.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4570] Quinn, B. and R. Finlayson, "Session Description Protocol
(SDP) Source Filters", RFC 4570, July 2006.
[RFC4756] Li, A., "Forward Error Correction Grouping Semantics in
Session Description Protocol", RFC 4756, November 2006.
[RFC3890] Westerlund, M., "A Transport Independent Bandwidth
Modifier for the Session Description Protocol (SDP)",
RFC 3890, September 2004.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[I-D.ietf-mmusic-sdp-capability-negotiation]
Andreasen, F., "SDP Capability Negotiation",
draft-ietf-mmusic-sdp-capability-negotiation-07 (work in
progress), October 2007.
9.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Author's Address
Ali Begen
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
USA
Email: abegen@cisco.com
Begen Expires May 14, 2008 [Page 13]
Internet-Draft SDP Elements for FEC Framework November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Begen Expires May 14, 2008 [Page 14]
