doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc4496.txt b/doc/rfc/rfc4496.txt
new file mode 100644
index 0000000..b14b240
--- /dev/null
+++ b/doc/rfc/rfc4496.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                         M. Stecher
+Request for Comments: 4496                              Secure Computing
+Category: Informational                                        A. Barbir
+                                                                  Nortel
+                                                                May 2006
+
+
+           Open Pluggable Edge Services (OPES) SMTP Use Cases
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The Open Pluggable Edge Services (OPES) framework is application
+   agnostic.  Application-specific adaptations extend that framework.
+   This document describes OPES SMTP use cases and deployment scenarios
+   in preparation for SMTP adaptation with OPES.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Terminology .....................................................2
+   3. Brief Overview of SMTP Architecture .............................3
+      3.1. Operation Flow of an OPES SMTP System ......................4
+           3.1.1. OPES SMTP Example ...................................5
+   4. OPES/SMTP Use Cases .............................................6
+      4.1. Security Filters Applied to Email Messages .................6
+      4.2. Spam Filter ................................................7
+      4.3. Logging and Reporting Filters ..............................8
+      4.4. Access Control Filters .....................................8
+      4.5. Secure Email Handling ......................................8
+      4.6. Email Format Normalization .................................8
+      4.7. Mail Rerouting and Address Rewriting .......................9
+      4.8. Block Email during SMTP Dialog .............................9
+      4.9. Convert Attachments to HTTP Links ..........................9
+   5. Security Considerations ........................................10
+   6. References .....................................................10
+      6.1. Normative References ......................................10
+      6.2. Informative References ....................................10
+   Acknowledgements ..................................................11
+
+
+
+Stecher & Barbir             Informational                      [Page 1]
+
+RFC 4496                  OPES SMTP Use Cases                   May 2006
+
+
+1.  Introduction
+
+   The Open Pluggable Edge Services (OPES) architecture [1] enables
+   cooperative application services (OPES services) between a data
+   provider, a data consumer, and zero or more OPES processors.  The
+   application services under consideration analyze and possibly
+   transform application-level messages exchanged between the data
+   provider and the data consumer.  The OPES processor can distribute
+   the responsibility of service execution by communicating and
+   collaborating with one or more remote callout servers.
+
+   The execution of such services is governed by a set of rules
+   installed on the OPES processor.  The rule evaluation can trigger the
+   execution of service applications local to the OPES processor or on a
+   remote callout server.
+
+   Use cases for OPES based on HTTP [8] are described in [2].  This work
+   focuses on OPES for SMTP [7] use cases, whereby additional use cases
+   and enhancements to the types of OPES services defined in [2] are
+   provided.
+
+   In SMTP, the OPES processor may be any agent participating in SMTP
+   exchanges, including a Mail Submission Agent (MSA), a Mail Transfer
+   Agent (MTA), a Mail Delivery Agent (MDA), and a Mail User Agent
+   (MUA).  This document focuses on use cases in which the OPES
+   processor is a MTA.
+
+   SMTP is a store-and-forward protocol.  Current email filtering
+   systems either operate during the SMTP exchange or on messages that
+   have already been received, after the SMTP connection has been closed
+   (for example, in an MTA's message queue).
+
+   This work focuses on SMTP-based services that want to modify command
+   values or want to block SMTP commands.  In order to block a command,
+   the service will provide an error message that the MTA should use in
+   response to the command it received.  An OPES MTA will be involved in
+   SMTP command modification and command satisfaction, analogous to
+   request modification and request satisfaction from HTTP [8].
+
+2.  Terminology
+
+   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 [6].  When used with
+   the normative meanings, these key words will be all uppercase.
+   Occurrences of these words in lowercase comprise normal prose usage,
+   with no normative implications.
+
+
+
+
+Stecher & Barbir             Informational                      [Page 2]
+
+RFC 4496                  OPES SMTP Use Cases                   May 2006
+
+
+3.  Brief Overview of SMTP Architecture
+
+   The SMTP design, taken from RFC 2821 [7], is shown in Figure 1.  When
+   an SMTP client has a message to transmit, it establishes a two-way
+   transmission channel to an SMTP server.  The responsibility of an
+   SMTP client is to transfer mail messages to one or more SMTP servers,
+   or report its failure to do so.
+
+                  +----------+                +----------+
+      +------+    |          |                |          |
+      | User |<-->|          |      SMTP      |          |
+      +------+    |  Client  |Commands/Replies| Server   |
+      +------+    |   SMTP   |<-------------->|  SMTP    |    +------+
+      | File |<-->|          |    and Mail    |          |<-->| File |
+      |System|    |          |                |          |    |System|
+      +------+    +----------+                +----------+    +------+
+                   SMTP client                SMTP server
+
+                           Figure 1: SMTP Design
+
+   In some cases, the domain name(s) transferred to, or determined by,
+   an SMTP client will identify the final destination(s) of the mail
+   message.  In other cases, the domain name determined will identify an
+   intermediate destination through which those mail messages are to be
+   relayed.
+
+   An SMTP server may be either the ultimate destination or an
+   intermediate "relay" or "gateway" (that is, it may transport the
+   message further using some protocol other than SMTP or using again
+   SMTP and then acting as an SMTP client).
+
+   SMTP commands are generated by the SMTP client and sent to the SMTP
+   server.  SMTP responses are sent from the SMTP server to the SMTP
+   client in response to the commands.  SMTP message transfer can occur
+   in a single connection between the original SMTP sender and the final
+   SMTP recipient, or it can occur in a series of hops through
+   intermediary systems.  SMTP clients and servers exchange commands and
+   responses and eventually the mail message body.
+
+   Figure 2 expands on the mail flow in an SMTP system.  Further
+   information about the architecture of email in the Internet may be
+   found in [9].
+
+
+
+
+
+
+
+
+
+Stecher & Barbir             Informational                      [Page 3]
+
+RFC 4496                  OPES SMTP Use Cases                   May 2006
+
+
+   +-------+  +---------+      +---------+      +--------+  +-------+
+   |mail  M|  |M mail  M| SMTP |M mail  M| SMTP |M mail M|  |M mail |
+   |clnt  U|--|S srvr  T|------|T gway  T|------|T srvr D|--|U clnt |
+   |      A|  |A       A|      |A       A|      |A      A|  |A      |
+   +-------+  +---------+      +---------+      +--------+  +-------+
+
+                      Figure 2: Expanded SMTP Flow
+
+   In this work, the OPES processor may be any agent that is
+   participating in SMTP exchanges, including an MSA, MTA, MDA, and MUA.
+   However, this document focuses on use cases in which the OPES
+   processor uses the SMTP protocol or one of the protocols derived from
+   SMTP Message Submission (SUBMIT) [10] and the Local Mail Transfer
+   Protocol (LMTP) [11]).
+
+3.1.  Operation Flow of an OPES SMTP System
+
+   In this work, an MTA is the OPES processor device that sits in the
+   data stream of the SMTP protocol.  The OPES processor gets enhanced
+   by an OCP (OPES callout protocol) [3] client that allows it to vector
+   out data to the callout server.  The filtering functionality is on
+   the callout server.
+
+   A client (a mail user) starts with an email client program (MUA).
+   The user sends email to an outgoing email server.  In the email
+   server, there is an MSA (mail submission agent) that is waiting to
+   receive email from the user.  The MSA uses an MTA within the same
+   server to forward the user email to other domains.  (Communication
+   between the MUA and MSA may be via SMTP, SUBMIT [10], or something
+   else such as MAPI).
+
+   The MTA in the user email server may directly contact the email
+   server of the recipient or may use other intermediate email gateways.
+   The sending email server and all intermediate gateway MTAs usually
+   communicate using SMTP.  Communication with the destination email
+   server usually uses SMTP or its derivative, LMTP [11].
+
+   In the destination email server, a mail delivery agent (MDA) may
+   deliver the email to the recipient's mailbox.  The email client
+   program of the recipient might use a different protocol (such as the
+   Post Office Protocol version 3 (POP3) or IMAP) to access the mailbox
+   and retrieve/read the messages.
+
+
+
+
+
+
+
+
+
+Stecher & Barbir             Informational                      [Page 4]
+
+RFC 4496                  OPES SMTP Use Cases                   May 2006
+
+
+   +-------+  +---------+      +---------+      +--------+  +-------+
+   |mail  M|  |M mail  M| SMTP |M mail  M| SMTP |M mail M|  |M mail |
+   |clnt  U|--|S srvr  T|------|T gway  T|------|T srvr D|--|U clnt |
+   |      A|  |A       A|      |A       A|      |A      A|  |A      |
+   +-------+  +---------+      +---------+      +--------+  +-------+
+                   |                |                |
+                   | OCP            | OCP            | OCP
+                   |                |                |
+              +----------+     +----------+     +----------+
+              |  callout |     |  callout |     |  callout |
+              |  server  |     |  server  |     |  server  |
+              +----------+     +----------+     +----------+
+
+                         Figure 3: OPES SMTP Flow
+
+   From Figure 3, the MTA (the OPES processor) is either receiving or
+   sending an email (or both) within an email server/gateway.  An OPES
+   processor might be the sender's SMTP server, the destination SMTP
+   server, or any intermediate SMTP gateway.  (Which building block
+   belongs to which authoritative domain is an important question but
+   different from deployment to deployment.)  Note that this figure
+   shows multiple OPES deployment options in a typical chain of mail
+   servers and gateways with different roles as MSA, MTA, and MDA; the
+   OPES standard case, however, will only have a single OPES processor
+   and a single callout server in the message flow.
+
+3.1.1.  OPES SMTP Example
+
+   A typical (minimum) SMTP dialog between two OPES SMTP processors
+   (MTA) will consist of the following (C: means client, S: means
+   server):
+
+      S: 220 mail.example.com Sample ESMTP MAIL Service, Version: 1.2
+      ready at Thu, 20 Jan 2005 11:24:40+0100
+      C: HELO [192.0.2.138]
+      S: 250 mail.example.com Hello [192.0.2.138]
+      C: MAIL FROM:<steve@example.org>
+      S: 250 2.1.0 steve@example.org....Sender OK
+      C: RCPT TO:<paul@example.com>
+      S: 250 2.1.5 paul@example.com
+      C: DATA
+      S: 354 Start mail input; end with "CRLF"."CRLF"
+      C: From: steve@example.org
+      C: To: sandra@example.com
+      C: Subject: Test
+      C:
+      C: Hi, this is a test!
+      C: .
+
+
+
+Stecher & Barbir             Informational                      [Page 5]
+
+RFC 4496                  OPES SMTP Use Cases                   May 2006
+
+
+      S: 250 2.6.0 "MAIL0m4b1f@mail.example.com" Queued mail for
+      delivery
+      C: QUIT
+      S: 221 2.0.0 mail.example.com Service closing transmission channel
+
+   The client (C:) is issuing SMTP commands and the server (S:) is
+   generating responses.  All responses start with a status code and
+   then some text.  At minimum, 4 commands are needed to send an email.
+   Together, all commands and responses to send a single email message
+   form "the dialog".  The mail message body is the data sent after the
+   "DATA" command.  An OPES processor could see that as command
+   modification.
+
+   If a callout service wants to adapt the email message body, it is
+   mainly interested in this part of the dialog:
+
+      From: steve@example.org
+      To: sandra@example.com
+      Subject: Test
+
+      Hi, this is a test!
+
+   The callout service may need to examine values of previous commands
+   of the same dialog.  For example, the callout service needs to
+   examine the value of the RCPT command (it is "paul@example.com"),
+   which is different from the "sandra@example.com" that the email
+   client displays in the visible "To" field.  That might be an
+   important fact for some filters such as spam filters (Section 4.2).
+
+4.  OPES/SMTP Use Cases
+
+   In principle, all filtering that is deployed at SMTP gateways today
+   and tomorrow defines use cases for OPES callout filtering.  An
+   OCP/SMTP callout protocol will enable an SMTP gateway to vector out
+   (parts of) an SMTP message or parts of the SMTP dialog to a callout
+   server that is then performing actions on behalf of the gateway.
+   (OCP/SMTP would be a profile defined for OCP analogous to the
+   OCP/HTTP profile [4] that has been defined earlier.)
+
+   Here is a collection of some typical use cases describing different
+   filtering areas and different actions caused by those filters.
+
+4.1.  Security Filters Applied to Email Messages
+
+   These filters concentrate on the email message body and usually
+   filter the email sections one by one.  Email sections (attachments)
+   that violate the security policy (e.g., because they contain a virus
+
+
+
+
+Stecher & Barbir             Informational                      [Page 6]
+
+RFC 4496                  OPES SMTP Use Cases                   May 2006
+
+
+   or contain an unwanted mime type) define an event that can cause a
+   combination of different actions to be performed:
+
+   o  The attachment is replaced by an error message.
+
+   o  The email is marked by inserting a warning into the subject or the
+      email body.
+
+   o  An additional header is added for post-processing steps.
+
+   o  The email storage is advised to put the email into quarantine.
+
+   o  Notifications are sent to sender, recipients, and/or
+      administrators.
+
+   o  The incident is reported to other tools such as intrusion
+      detection applications.
+
+   These kinds of filters usually do not require working with elements
+   of the SMTP dialog other than the email message body.  An exception
+   to this is the need to map email senders and recipients to different
+   security sub-policies that are used for a particular message.  A
+   security filter may therefore require receiving the information of
+   the RCPT TO and MAIL FROM commands as meta data with the email
+   message body it examines.
+
+4.2.  Spam Filter
+
+   Next to security filters, spam filters are probably the most wanted
+   filtering application today.  Spam filters use several methods.  They
+   concentrate most on the email message body (that also includes the
+   email headers), but many of these filters are also interested in the
+   values of the other SMTP commands in order to compare the SMTP
+   sender/recipients with the visible From/To fields.  They may even
+   want to get the source IP of the connected SMTP client as meta
+   information to verify this against lists of open relays, known
+   spammers, etc.
+
+   These are typical actions that could be performed when a message has
+   been classified as spam:
+
+   o  Add a mark to the subject of the email.
+
+   o  Add an additional header for post-processing steps.
+
+   o  The email storage is advised to put the email into a spam queue.
+
+   o  The email is rejected or returned to the sender.
+
+
+
+Stecher & Barbir             Informational                      [Page 7]
+
+RFC 4496                  OPES SMTP Use Cases                   May 2006
+
+
+4.3.  Logging and Reporting Filters
+
+   The nature of these kinds of filters is not to modify the email
+   message.  Depending on what is being logged or reported on, the
+   filter may need access to any part of the SMTP dialog.  Most wanted
+   is the sender and recipient information.  Depending on the ability of
+   the OPES processor to pre-calculate and transfer information about
+   the message body, the callout filter may want to see the email
+   message body itself or just that meta info; an example is the email
+   size.  This information would be typical logging and reporting
+   information that is easy for the SMTP gateway to calculate although
+   not a direct parameter of the SMTP dialog.  Transferring the complete
+   email message body only because the callout server wants to calculate
+   its size would be a waste of network resources.
+
+4.4.  Access Control Filters
+
+   These filters operate on the values of the MAIL FROM and RCPT TO
+   commands of the SMTP dialog.  They run an access control policy to
+   determine whether a sender is currently allowed to send a message to
+   the given recipients.  The values of HELO/EHLO, AUTH, and STARTTLS
+   commands may also be applied.  The result of this filter has a direct
+   influence on the SMTP response that the OPES processor has to send to
+   its peer for the filtered SMTP command.
+
+4.5.  Secure Email Handling
+
+   Filters of this kind can support an email gateway to centrally encode
+   and decode email, and to set and to verify email signatures.  They
+   will therefore modify the email message body to encrypt, decrypt,
+   verify, or sign the message, or use an action as specified in the
+   "Security Filter" (Section 4.1) section if the decryption or
+   signature verification fails.
+
+   Sending the SMTP sender and recipient information as meta data to
+   these filters is mission critical because these filters may not trust
+   the information found in the header section of the email message
+   body.
+
+4.6.  Email Format Normalization
+
+   SMTP messages may be sent with an illegal or uncommon format; this
+   may have happened by a buggy SMTP application or on purpose in order
+   to exploit vulnerabilities of other products.  A normalization filter
+   can correct the email format.  The format correction can be done for
+   the email body and for the value of other SMTP commands.  An example
+   for the email body format correction would be a strange length of
+   UUencoded lines or unusual names of MIME sections.  Command values
+
+
+
+Stecher & Barbir             Informational                      [Page 8]
+
+RFC 4496                  OPES SMTP Use Cases                   May 2006
+
+
+   may be analysed against buffer overflow exploits; a rewrite will not
+   always be possible in this case (cannot simply rewrite an email
+   address that is very long) but will require that the callout server
+   tells the OPES processor to send an error response in reply to such a
+   command.
+
+4.7.  Mail Rerouting and Address Rewriting
+
+   A corporation with multiple locations may want to deploy a central
+   gateway that receives all email messages for all employees and then
+   determines at which location the mail storage of the employee
+   resides.  The callout server will then need the RCPT TO command value
+   and it will look up the location in the corporate directory service.
+   It then tells either the OPES processor where the next SMTP server is
+   (i.e., the next SMTP server to connect to) or it rewrites the
+   recipient address; in the first case, the SMTP servers at the
+   different locations accept emails of the same domain as the central
+   gateway does; in the second case, the other locations will probably
+   use the sublocation of the original domain (joe@example.org ->
+   joe@fr.example.org or joe@de.example.org).
+
+4.8.  Block Email during SMTP Dialog
+
+   In a first step, the callout server will check the sender and
+   recipient information that was transmitted in the SMTP dialog; that
+   information again maps to a policy that will deny all messages either
+   from that sender or to that recipient, or it checks the body of the
+   email and classifies it (maybe just by looking for some words in the
+   subject or by doing in-depth content analysis), which can then also
+   lead to the decision to deny the message.
+
+   Unlike previous examples, this use case wants to deny the email while
+   the SMTP dialog is still active, i.e., before the OPES processor
+   finally accepted the message.  Depending on the exact policy, the
+   error response should then be sent in reply to the MAIL FROM, RCPT
+   TO, or DATA command.
+
+4.9.  Convert Attachments to HTTP Links
+
+   This use case will only modify the email message body without any
+   other influence on the SMTP dialogs, mail routing, etc.  Larger
+   sections (attachments) are removed from the email, and the content is
+   stored on a web server.  A link to that new URL is then added into
+   the text of a first section that is likely to be displayed by an
+   email client.  Storing the attachments onto the web server is not in
+   the scope of the OPES/SMTP scenario and needs to be implemented by
+   the callout server.
+
+
+
+
+Stecher & Barbir             Informational                      [Page 9]
+
+RFC 4496                  OPES SMTP Use Cases                   May 2006
+
+
+5.  Security Considerations
+
+   Application-independent security considerations are documented in
+   application-agnostic OPES specifications [5].  This document contains
+   only use cases and defines no protocol operations.  Security
+   considerations for protocols that appear in these use cases are
+   documented in the corresponding protocol specifications.
+
+   Use case "Secure Email Handling" (Section 4.5) is special in this
+   regard because it requires the extension of the end-to-end encryption
+   model and a secure handling of private cryptographic keys when
+   creating digital signatures or when decrypting messages.  Both are
+   out of scope of OPES protocol specifications.  An implementation of
+   such a service raises security issues (such as availability and
+   storage of cryptographic keys) that must be addressed regardless of
+   whether the implementation happens within an MTA or within an OPES
+   callout server.
+
+6.  References
+
+6.1.  Normative References
+
+   [1]  Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An
+        Architecture for Open Pluggable Edge Services (OPES)", RFC 3835,
+        August 2004.
+
+   [2]  Barbir, A., Burger, E., Chen, R., McHenry, S., Orman, H., and R.
+        Penno, "Open Pluggable Edge Services (OPES) Use Cases and
+        Deployment Scenarios", RFC 3752, April 2004.
+
+   [3]  Rousskov, A., "Open Pluggable Edge Services (OPES) Callout
+        Protocol (OCP) Core", RFC 4037, March 2005.
+
+   [4]  Rousskov, A. and M. Stecher, "HTTP Adaptation with Open
+        Pluggable Edge Services (OPES)", RFC 4236, November 2005.
+
+   [5]  Barbir, A., Batuner, O., Srinivas, B., Hofmann, M., and H.
+        Orman, "Security Threats and Risks for Open Pluggable Edge
+        Services (OPES)", RFC 3837, August 2004.
+
+   [6]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+6.2.  Informative References
+
+   [7]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
+        2001.
+
+
+
+
+Stecher & Barbir             Informational                     [Page 10]
+
+RFC 4496                  OPES SMTP Use Cases                   May 2006
+
+
+   [8]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
+        Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
+        HTTP/1.1", RFC 2616, June 1999.
+
+   [9]  Crocker, D., "Internet Mail Architecture", Work in Progress,
+        March 2005.
+
+   [10] Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
+        December 1998.
+
+   [11] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October
+        1996.
+
+Acknowledgements
+
+   Many thanks to everybody who provided input for the use case
+   examples, namely, jfc and Markus Hofmann.  Thanks also for the
+   discussion and feedback given on the OPES mailing list.
+
+Authors' Addresses
+
+   Martin Stecher
+   Secure Computing Corporation
+   Vattmannstr. 3
+   33100 Paderborn
+   Germany
+
+   EMail: martin.stecher@webwasher.com
+   URI:   http://www.securecomputing.com/
+
+
+   Abbie Barbir
+   Nortel
+   3500 Carling Avenue
+   Ottawa, Ontario
+   CA
+
+   Phone: +1 613 763 5229
+   EMail: abbieb@nortel.com
+
+
+
+
+
+
+
+
+
+
+
+
+Stecher & Barbir             Informational                     [Page 11]
+
+RFC 4496                  OPES SMTP Use Cases                   May 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   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
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Stecher & Barbir             Informational                     [Page 12]
+