doc: Add RFC documents

1 files changed, 324 insertions, 0 deletions

diff --git a/doc/rfc/rfc9274.txt b/doc/rfc/rfc9274.txt
new file mode 100644
index 0000000..0aee2d8
--- /dev/null
+++ b/doc/rfc/rfc9274.txt
@@ -0,0 +1,324 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                      M. Boucadair
+Request for Comments: 9274                                        Orange
+Updates: 7285                                                      Q. Wu
+Category: Standards Track                                         Huawei
+ISSN: 2070-1721                                                July 2022
+
+
+  A Cost Mode Registry for the Application-Layer Traffic Optimization
+                            (ALTO) Protocol
+
+Abstract
+
+   This document creates a new IANA registry for tracking cost modes
+   supported by the Application-Layer Traffic Optimization (ALTO)
+   Protocol.  Also, this document relaxes a constraint that was imposed
+   by the ALTO specification on allowed cost mode values.
+
+   This document updates RFC 7285.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9274.
+
+Copyright Notice
+
+   Copyright (c) 2022 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Terminology
+   3.  Updates to RFC 7285
+     3.1.  Updates to Section 6.1.2 of RFC 7285
+     3.2.  Updates to Section 10.5 of RFC 7285
+   4.  Backward Compatibility Considerations
+   5.  IANA Considerations
+   6.  Security Considerations
+   7.  References
+     7.1.  Normative References
+     7.2.  Informative References
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   The cost mode attribute indicates how costs should be interpreted
+   when communicated as described in "Application-Layer Traffic
+   Optimization (ALTO) Protocol" [RFC7285], which includes a provision
+   for only two modes:
+
+   "numerical":  Indicates that numerical operations can be performed
+      (e.g., normalization) on the returned costs (Section 6.1.2.1 of
+      [RFC7285]).
+
+   "ordinal":  Indicates that the cost values in a cost map represent
+      ranking (relative to all other values in a cost map), not actual
+      costs (Section 6.1.2.2 of [RFC7285]).
+
+   Additional cost modes are required for specific ALTO deployment cases
+   (e.g., [ALTO-PV]).  In order to allow for such use cases, this
+   document relaxes the constraint imposed by the base ALTO
+   specification on allowed cost modes (Section 3) and creates a new
+   ALTO registry to track new cost modes (Section 5).
+
+   The mechanisms defined in [RFC7285] are used to advertise the support
+   of new cost modes for specific cost metrics.  Refer to Section 4 for
+   more details.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   This document makes use of the terms defined in [RFC7285].
+
+3.  Updates to RFC 7285
+
+
+3.1.  Updates to Section 6.1.2 of RFC 7285
+
+   This document updates Section 6.1.2 of [RFC7285] as follows:
+
+   OLD:
+
+      The cost mode attribute indicates how costs should be interpreted.
+      Specifically, the cost mode attribute indicates whether returned
+      costs should be interpreted as numerical values or ordinal
+      rankings.
+
+      It is important to communicate such information to ALTO clients,
+      as certain operations may not be valid on certain costs returned
+      by an ALTO server.  For example, it is possible for an ALTO server
+      to return a set of IP addresses with costs indicating a ranking of
+      the IP addresses.  Arithmetic operations that would make sense for
+      numerical values, do not make sense for ordinal rankings.  ALTO
+      clients may handle such costs differently.
+
+      Cost modes are indicated in protocol messages as strings.
+
+   NEW:
+
+      The cost mode attribute indicates how costs should be interpreted.
+      Two cost modes (numerical values and ordinal rankings) are
+      defined, but additional cost modes can be defined in the future.
+
+      It is important to communicate such information to ALTO clients,
+      as certain operations may not be valid on certain costs returned
+      by an ALTO server.  For example, it is possible for an ALTO server
+      to return a set of IP addresses with costs indicating a ranking of
+      the IP addresses.  Arithmetic operations that would make sense for
+      numerical values, do not make sense for ordinal rankings.  ALTO
+      clients may handle such costs differently.
+
+      Cost modes are indicated in protocol messages as strings.
+
+      For any future documents that defines a new cost mode, indicating
+      whether that new cost mode applies to all or a subset of cost
+      metrics is strongly recommended.  This recommendation is meant to
+      prevent nondeterministic behaviors that may result in presenting a
+      cost mode with a specific metric, while such an association does
+      not make sense or can't be unambiguously interpreted by ALTO
+      implementations.
+
+      If the definition of a cost mode does not indicate whether that
+      cost mode applies to a subset of cost metrics, ALTO
+      implementations MUST be prepared to accept that cost mode for any
+      cost metric.
+
+
+3.2.  Updates to Section 10.5 of RFC 7285
+
+   This document updates Section 10.5 of [RFC7285] as follows:
+
+   OLD:
+
+      A cost mode is encoded as a string.  The string MUST have a value
+      of either "numerical" or "ordinal".
+
+   NEW:
+
+      A cost mode is encoded as a string.  The string MUST be no more
+      than 32 characters, and it MUST NOT contain characters other than
+      US-ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A,
+      and U+0061-U+007A), the hyphen-minus ('-', U+002D), the colon
+      (':', U+003A), or the low line ('_', U+005F).  Cost modes reserved
+      for Private Use are prefixed with "priv:" (Section 5).  Otherwise,
+      the cost mode MUST have a value that is listed in the registry
+      created in Section 5 of [RFC9274].
+
+
+4.  Backward Compatibility Considerations
+
+   ALTO servers that support new cost modes for specific cost metrics
+   will use the mechanism specified in Section 9.2 of [RFC7285] to
+   advertise their capabilities.  ALTO clients (including legacy) will
+   use that information to specify cost constraints in their requests
+   (e.g., indicate a cost metric and a cost mode).  An example of such a
+   behavior is depicted in Section 9.2.3 of [RFC7285].
+
+   If an ALTO client includes a cost mode that is not supported by an
+   ALTO server, the server indicates such an error with the error code
+   E_INVALID_FIELD_VALUE as per Section 8.5.2 of [RFC7285].  In
+   practice, legacy ALTO servers will reply with the error code
+   E_INVALID_FIELD_VALUE to requests that include a cost type other than
+   "numerical" or "ordinal" for the "routingcost" cost metric.
+
+   The encoding constraints in Section 3.2 do not introduce any
+   interoperability issue given that currently implemented cost modes
+   adhere to these constrains (mainly, those in [RFC7285] and
+   [ALTO-PV]).
+
+5.  IANA Considerations
+
+   IANA has created the new "ALTO Cost Modes" subregistry within the
+   "Application-Layer Traffic Optimization (ALTO) Protocol" registry
+   available at [ALTO].
+
+   The assignment policy for this subregistry is "IETF Review"
+   (Section 4.8 of [RFC8126]).
+
+   Requests to register a new ALTO cost mode must include the following
+   information:
+
+   Identifier:  The name of the ALTO cost mode.  Refer to Section 3.2
+      for more details on allowed encoding.
+
+   Description:  A short description of the requested ALTO cost mode.
+
+   Intended Semantics:  A reference to where the semantic of the
+      requested cost mode is defined.
+
+   Reference:  A reference to the document that registers the requested
+      cost mode.
+
+   Cost modes prefixed with "priv:" are reserved for Private Use
+   (Section 4.1 of [RFC8126]).  IANA has added the following note to the
+   new subregistry:
+
+   |  Identifiers prefixed with "priv:" are reserved for Private Use
+   |  (see RFC 9274, Section 5).
+
+   The subregistry is initially populated with the following values:
+
+   +============+=============================+============+===========+
+   | Identifier | Description                 | Intended   | Reference |
+   |            |                             | Semantics  |           |
+   +============+=============================+============+===========+
+   | numerical  | Indicates that numerical    | Section    | RFC 9274  |
+   |            | operations can be performed | 6.1.2.1    |           |
+   |            | on the returned costs       | of         |           |
+   |            |                             | [RFC7285]  |           |
+   +------------+-----------------------------+------------+-----------+
+   | ordinal    | Indicates that the cost     | Section    | RFC 9274  |
+   |            | values in a cost map        | 6.1.2.2    |           |
+   |            | represent ranking           | of         |           |
+   |            |                             | [RFC7285]  |           |
+   +------------+-----------------------------+------------+-----------+
+
+                          Table 1: ALTO Cost Modes
+
+6.  Security Considerations
+
+   This document does not introduce new concerns other than those
+   already discussed in Section 15 of [RFC7285].
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC7285]  Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
+              Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
+              "Application-Layer Traffic Optimization (ALTO) Protocol",
+              RFC 7285, DOI 10.17487/RFC7285, September 2014,
+              <https://www.rfc-editor.org/info/rfc7285>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+7.2.  Informative References
+
+   [ALTO]     IANA, "Application-Layer Traffic Optimization (ALTO)
+              Protocol",
+              <https://www.iana.org/assignments/alto-protocol/>.
+
+   [ALTO-PV]  Gao, K., Lee, Y., Randriamasy, S., Yang, Y. R., and J. J.
+              Zhang, "An ALTO Extension: Path Vector", Work in Progress,
+              Internet-Draft, draft-ietf-alto-path-vector-25, 20 March
+              2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
+              alto-path-vector-25>.
+
+Acknowledgements
+
+   Many thanks to Benjamin Kaduk for spotting the issue during the
+   review of [ALTO-PV].
+
+   Thanks to Adrian Farrel, Dhruv Dhody, Luis Miguel Contreras Murillo,
+   Sabine Randriamasy, and Qiao Xiang for the review and comments.
+
+   Special thanks to Kai Gao for Shepherding the document.
+
+   Thanks to Martin Duke for the AD review.
+
+   Thanks to Roni Even for the gen-art review, Jaime Jimenez for the
+   artart review, and Stephen Farrell for the secdir review.
+
+   Thanks to Robert Wilton, Lars Eggert, Francesca Palombini, Roman
+   Danyliw, Paul Wouters, and Murray Kucherawy for the IESG review.
+
+Authors' Addresses
+
+   Mohamed Boucadair
+   Orange
+   35000 Rennes
+   France
+   Email: mohamed.boucadair@orange.com
+
+
+   Qin Wu
+   Huawei
+   Yuhua District
+   101 Software Avenue
+   Nanjing
+   Jiangsu, 210012
+   China
+   Email: bill.wu@huawei.com