doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc2872.txt b/doc/rfc/rfc2872.txt
new file mode 100644
index 0000000..d179493
--- /dev/null
+++ b/doc/rfc/rfc2872.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                        Y. Bernet
+Request for Comments: 2872                                  R. Pabbati
+Category: Standards Track                                    Microsoft
+                                                             June 2000
+
+
+      Application and Sub Application Identity Policy Element for
+                             Use with RSVP
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Conventions used in this document
+
+   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].
+
+Abstract
+
+   RSVP [RFC 2205] signaling messages typically include policy data
+   objects, which in turn contain policy elements. Policy elements may
+   describe user and/or application information, which may be used by
+   RSVP aware network elements to apply appropriate policy decisions to
+   a traffic flow. This memo details the usage of policy elements that
+   provide application information.
+
+1. Overview
+
+   RSVP aware network elements may act as policy enforcement points
+   (PEPs). These work together with policy decision points (PDPs) to
+   enforce QoS policy. Briefly, PEPs extract policy information from
+   RSVP signaling requests and compare the information against
+   information stored by a PDP in a (possibly remotely located) policy
+   database or directory. A policy decision is made based on the results
+   of the comparison.
+
+
+
+
+
+
+Bernet & Pabbati            Standards Track                     [Page 1]
+
+RFC 2872            Application Identifiers for RSVP           June 2000
+
+
+   One type of policy information describes the application on behalf of
+   which an RSVP signaling request is generated. When application policy
+   information is available, network administrators are able to manage
+   QoS based on application type. So, for example, a network
+   administrator may establish a policy that prioritizes known mission-
+   critical applications over games.
+
+   This memo describes a structure for a policy element that can be used
+   to identify application traffic flows. The policy element includes a
+   number of attributes, one of which is a policy locator. This policy
+   locator includes the following hierarchically ordered sub-elements
+   (in descending levels of hierarchy):
+
+      1. identifier that uniquely identifies the application vendor
+      2. identifier of the application
+      3. version number of the application
+      4. sub-application identifier
+
+   An arbitrary number of sub-application identifiers may be included in
+   the policy locator. An example of such an identifier is 'print
+   transaction'.
+
+   This memo specifies the structure of the application policy element
+   and proposes keywords for the sub-elements at each level of the
+   hierarchy. It does not enumerate specific values for the sub-
+   elements: such an enumeration is beyond the scope of this memo.
+
+2. Simple Application Identity Policy Element Structure
+
+   General application identity policy elements are defined in
+   [RFC2752]. These are policy elements with a P-type of AUTH_APP.
+   Following the policy element header is a list of authentication
+   attributes.
+
+   The first authentication attribute is of the A-type POLICY_LOCATOR.
+   The sub-type of the POLICY_LOCATOR attribute is of type ASCII_DN
+   [RFC1779] or UNICODE_DN. The actual attribute data is formatted as an
+   X.500 distinguished name (DN), representing a globally unique
+   identifier, the application, version number and sub-application in a
+   hierarchical structure. The POLICY_LOCATOR attribute contains
+   keywords as described in section 2. For further details on the format
+   of the POLICY_LOCATOR attribute, see [RFC2752].
+
+   The second authentication attribute is of the A-type CREDENTIAL. The
+   sub-type of the CREDENTIAL attribute is of type ASCII_ID or
+   UNICODE_ID. The actual attribute data is an ASCII or Unicode string
+   representing the application name. This structure is illustrated in
+   the following diagram:
+
+
+
+Bernet & Pabbati            Standards Track                     [Page 2]
+
+RFC 2872            Application Identifiers for RSVP           June 2000
+
+
+               0              1               2               3
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |    PE Length (8)              |   P-type = AUTH_APP           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |    Attribute Length           |   A-type =    |  Sub-type =   |
+      |                               | POLICY_LOCATOR|   ASCII_DN    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      | Application policy locator attribute data in X.500 DN format  |
+      |                         (see below)                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |    Attribute Length           |   A-type =    |  Sub-type =   |
+      |                               |   CREDENTIAL  |   ASCII_ID    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                 Application name as ASCII string              |
+      |                         (e.g. SAP.EXE)                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The following keywords are recommended although others MAY be used:
+
+   Key  Attribute
+   --------------
+   GUID Globally Unique Identifier (optional)
+   APP  Application Name
+   VER  Application Version Number
+   SAPP Sub Application (optional)
+
+   The following are examples of conformant policy locators:
+
+   "APP=SAP, VER=1.1, SAPP=Print"
+
+   "GUID=http://www.microsoft.com/apps, APP=MyApplication, VER=1.2.3"
+
+   The APP, VER and SAPP attributes SHOULD describe the application to a
+   human reader in as unique and unambiguous a way as possible. The GUID
+   attribute MAY be used when absolute uniqueness of application
+   identification is required and its contents MUST be an identifier
+   from a globally-unique source (e.g. domain names as assigned by the
+   corresponding registration authorities). Note that publication of the
+   chosen identifiers in a suitable format is strongly encouraged.
+
+
+
+
+
+
+
+
+
+
+
+
+Bernet & Pabbati            Standards Track                     [Page 3]
+
+RFC 2872            Application Identifiers for RSVP           June 2000
+
+
+3. Security Considerations
+
+   The proposed simple policy element does not guarantee that element is
+   indeed associated with the application it claims to be associated
+   with. In order to provide such guarantees, it is necessary to sign
+   applications. Signed application policy elements may be proposed at a
+   future date. Note that, typically, the application policy element
+   will be included in an RSVP message with an encrypted and
+   authenticated user policy element. A level of security is provided by
+   trusting the application policy element only if the user policy
+   element is trusted.
+
+   All RSVP integrity considerations apply to the message containing the
+   application policy element.
+
+4. References
+
+   [RFC2205] Braden, R., Zhang, L., Berson, L., Herzog, S. and S. Jamin,
+             "Resource Reservation Protocol (RSVP) - Version 1
+             Functional Specification", RFC 2205, September 1997.
+
+   [RFC1779] Kille, S., "A String Representation of Distinguished
+             Names", RFC 1779, March 1995.
+
+   [RFC2752] Yadav, S., Yavatkar, R., Pabbati, R,. Ford, P., Moore, T.
+             and S. Herzog, "Identity Representation for RSVP", RFC
+             2752, January 2000.
+
+   [ASCII]   Coded Character Set -- 7-Bit American Standard Code for
+             Information Interchange, ANSI X3.4-1986.
+
+   [UNICODE] The Unicode Consortium, "The Unicode Standard, Version
+             2.0", Addison-Wesley, Reading, MA, 1996.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+5.  Acknowledgments
+
+   Thanks to Tim Moore, Shai Mohaban, Andrew Smith, Ulrich Homann and
+   other contributors to the IETF's RAP WG for their input.
+
+
+
+
+
+
+
+
+
+
+Bernet & Pabbati            Standards Track                     [Page 4]
+
+RFC 2872            Application Identifiers for RSVP           June 2000
+
+
+6. Authors' Addresses
+
+   Yoram Bernet
+   Microsoft
+   One Microsoft Way
+   Redmond, WA 98052
+
+   Phone: (425) 936-9568
+   EMail: yoramb@microsoft.com
+
+
+   Ramesh Pabbati
+   One Microsoft Way
+   Redmond, WA 98052
+
+   EMail: rameshpa@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bernet & Pabbati            Standards Track                     [Page 5]
+
+RFC 2872            Application Identifiers for RSVP           June 2000
+
+
+7.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  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 implementation 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
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bernet & Pabbati            Standards Track                     [Page 6]
+