Internet Engineering Task Force (IETF) F. Le Faucheur, Ed.
Request for Comments: 7937
Category: Standards Track G. Bertrand, Ed.
ISSN: 2070-1721
I. Oprescu, Ed.
Internet Engineering Task Force (IETF) F. Le Faucheur, Ed.
Request for Comments: 7937
Category: Standards Track G. Bertrand, Ed.
ISSN: 2070-1721
I. Oprescu, Ed.
R. Peterkofsky Google Inc. August 2016
R.彼得考夫斯基谷歌公司2016年8月
Content Distribution Network Interconnection (CDNI) Logging Interface
内容分发网络互连（CDNI）记录接口
Abstract
摘要
This memo specifies the Logging interface between a downstream Content Distribution Network (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework. First, it describes a reference model for CDNI logging. Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files.
此备忘录指定了按照CDN互连（CDNI）框架互连的下游内容分发网络（dCDN）和上游CDN（uCDN）之间的日志记录接口。首先，它描述了CDNI测井的参考模型。然后，它指定了CDNI日志文件格式和交换CDNI日志文件的实际协议。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7937.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7937.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. CDNI Logging Reference Model . . . . . . . . . . . . . . . . 5
2.1. CDNI Logging Interactions . . . . . . . . . . . . . . . . 5
2.2. Overall Logging Chain . . . . . . . . . . . . . . . . . . 9
2.2.1. Logging Generation and During-Generation Aggregation 10
2.2.2. Logging Collection . . . . . . . . . . . . . . . . . 11
2.2.3. Logging Filtering . . . . . . . . . . . . . . . . . . 11
2.2.4. Logging Rectification and Post-Generation Aggregation 12
2.2.5. Log-Consuming Applications . . . . . . . . . . . . . 13
2.2.5.1. Maintenance and Debugging . . . . . . . . . . . . 13
2.2.5.2. Accounting . . . . . . . . . . . . . . . . . . . 14
2.2.5.3. Analytics and Reporting . . . . . . . . . . . . . 14
2.2.5.4. Content Protection . . . . . . . . . . . . . . . 14
2.2.5.5. Notions Common to Multiple Log-Consuming
Applications . . . . . . . . . . . . . . . . . . 15
3. CDNI Logging File . . . . . . . . . . . . . . . . . . . . . . 17
3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. CDNI Logging File Structure . . . . . . . . . . . . . . . 18
3.3. CDNI Logging Directives . . . . . . . . . . . . . . . . . 21
3.4. CDNI Logging Records . . . . . . . . . . . . . . . . . . 26
3.4.1. HTTP Request Logging Record . . . . . . . . . . . . . 27
3.5. CDNI Logging File Extension . . . . . . . . . . . . . . . 38
3.6. CDNI Logging File Examples . . . . . . . . . . . . . . . 38
3.7. Cascaded CDNI Logging Files Example . . . . . . . . . . . 42
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. CDNI Logging Reference Model . . . . . . . . . . . . . . . . 5
2.1. CDNI Logging Interactions . . . . . . . . . . . . . . . . 5
2.2. Overall Logging Chain . . . . . . . . . . . . . . . . . . 9
2.2.1. Logging Generation and During-Generation Aggregation 10
2.2.2. Logging Collection . . . . . . . . . . . . . . . . . 11
2.2.3. Logging Filtering . . . . . . . . . . . . . . . . . . 11
2.2.4. Logging Rectification and Post-Generation Aggregation 12
2.2.5. Log-Consuming Applications . . . . . . . . . . . . . 13
2.2.5.1. Maintenance and Debugging . . . . . . . . . . . . 13
2.2.5.2. Accounting . . . . . . . . . . . . . . . . . . . 14
2.2.5.3. Analytics and Reporting . . . . . . . . . . . . . 14
2.2.5.4. Content Protection . . . . . . . . . . . . . . . 14
2.2.5.5. Notions Common to Multiple Log-Consuming
Applications . . . . . . . . . . . . . . . . . . 15
3. CDNI Logging File . . . . . . . . . . . . . . . . . . . . . . 17
3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. CDNI Logging File Structure . . . . . . . . . . . . . . . 18
3.3. CDNI Logging Directives . . . . . . . . . . . . . . . . . 21
3.4. CDNI Logging Records . . . . . . . . . . . . . . . . . . 26
3.4.1. HTTP Request Logging Record . . . . . . . . . . . . . 27
3.5. CDNI Logging File Extension . . . . . . . . . . . . . . . 38
3.6. CDNI Logging File Examples . . . . . . . . . . . . . . . 38
3.7. Cascaded CDNI Logging Files Example . . . . . . . . . . . 42
4. Protocol for Exchange of CDNI Logging File after Full
Collection . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.1. CDNI Logging Feed . . . . . . . . . . . . . . . . . . . . 45
4.1.1. Atom Formatting . . . . . . . . . . . . . . . . . . . 45
4.1.2. Updates to Log Files and the Feed . . . . . . . . . . 46
4.1.3. Redundant Feeds . . . . . . . . . . . . . . . . . . . 47
4.1.4. Example CDNI Logging Feed . . . . . . . . . . . . . . 47
4.2. CDNI Logging File Pull . . . . . . . . . . . . . . . . . 49
5. Protocol for Exchange of CDNI Logging File During Collection 50
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
6.1. CDNI Logging Directive Names Registry . . . . . . . . . . 51
6.2. CDNI Logging File version Registry . . . . . . . . . . . 51
6.3. CDNI Logging record-types Registry . . . . . . . . . . . 52
6.4. CDNI Logging Field Names Registry . . . . . . . . . . . . 53
6.5. CDNI Logging Payload Type . . . . . . . . . . . . . . . . 55
7. Security Considerations . . . . . . . . . . . . . . . . . . . 55
7.1. Authentication, Authorization, Confidentiality, and
Integrity Protection . . . . . . . . . . . . . . . . . . 55
7.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 56
7.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 57
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 58
8.1. Normative References . . . . . . . . . . . . . . . . . . 58
8.2. Informative References . . . . . . . . . . . . . . . . . 61
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63
4. Protocol for Exchange of CDNI Logging File after Full
Collection . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.1. CDNI Logging Feed . . . . . . . . . . . . . . . . . . . . 45
4.1.1. Atom Formatting . . . . . . . . . . . . . . . . . . . 45
4.1.2. Updates to Log Files and the Feed . . . . . . . . . . 46
4.1.3. Redundant Feeds . . . . . . . . . . . . . . . . . . . 47
4.1.4. Example CDNI Logging Feed . . . . . . . . . . . . . . 47
4.2. CDNI Logging File Pull . . . . . . . . . . . . . . . . . 49
5. Protocol for Exchange of CDNI Logging File During Collection 50
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
6.1. CDNI Logging Directive Names Registry . . . . . . . . . . 51
6.2. CDNI Logging File version Registry . . . . . . . . . . . 51
6.3. CDNI Logging record-types Registry . . . . . . . . . . . 52
6.4. CDNI Logging Field Names Registry . . . . . . . . . . . . 53
6.5. CDNI Logging Payload Type . . . . . . . . . . . . . . . . 55
7. Security Considerations . . . . . . . . . . . . . . . . . . . 55
7.1. Authentication, Authorization, Confidentiality, and
Integrity Protection . . . . . . . . . . . . . . . . . . 55
7.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 56
7.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 57
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 58
8.1. Normative References . . . . . . . . . . . . . . . . . . 58
8.2. Informative References . . . . . . . . . . . . . . . . . 61
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63
This memo specifies the CDNI Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN). First, it describes a reference model for CDNI logging. Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files.
此备忘录指定了下游CDN（dCDN）和上游CDN（uCDN）之间的CDNI日志记录接口。首先，它描述了CDNI测井的参考模型。然后，它指定了CDNI日志文件格式和交换CDNI日志文件的实际协议。
The reader should be familiar with the following documents:
读者应熟悉以下文件：
o CDNI problem statement [RFC6707] and framework [RFC7336], which identify a Logging interface,
o CDNI问题声明[RFC6707]和框架[RFC7336]，它们标识了一个日志接口，
o Section 8 of [RFC7337], which specifies a set of requirements for Logging,
o [RFC7337]第8节规定了一系列记录要求，
o [RFC6770] outlines real world use cases for interconnecting CDNs. These use cases require the exchange of Logging information between the dCDN and the uCDN.
o [RFC6770]概述了互连CDN的实际使用案例。这些用例需要在dCDN和uCDN之间交换日志信息。
As stated in [RFC6707], "the CDNI Logging interface enables details of content distribution and delivery activities to be exchanged between interconnected CDNs."
如[RFC6707]中所述，“CDNI日志记录接口允许在互连的CDN之间交换内容分发和交付活动的详细信息。”
The present document describes:
本文件说明：
o The CDNI Logging reference model (Section 2)
o CDNI测井参考模型（第2节）
o The CDNI Logging File format (Section 3)
o CDNI日志文件格式（第3节）
o The CDNI Logging File Exchange protocol (Section 4)
o CDNI日志文件交换协议（第4节）
In this document, the first letter of each CDNI-specific term is capitalized. We adopt the terminology described in [RFC6707] and [RFC7336], and extend it with the additional terms defined below.
在本文件中，每个CDNI特定术语的首字母大写。我们采用[RFC6707]和[RFC7336]中所述的术语，并使用以下定义的附加术语对其进行扩展。
Intra-CDN Logging information: Logging information generated and collected within a CDN. The format of the Intra-CDN Logging information may be different from the format of the CDNI Logging information.
CDN内部日志信息：在CDN内生成和收集的日志信息。CDN内部日志信息的格式可能不同于CDNI日志信息的格式。
CDNI Logging information: Logging information exchanged across CDNs using the CDNI Logging interface.
CDNI日志信息：使用CDNI日志接口在CDN之间交换的日志信息。
Logging information: Logging information generated and collected within a CDN or obtained from another CDN using the CDNI Logging interface.
日志信息：在CDN内生成和收集的日志信息，或使用CDNI日志接口从另一个CDN获取的日志信息。
CDNI Logging Field: An atomic element of information that can be included in a CDNI Logging Record. The time an event/task started, the IP address of an end user to whom content was delivered, and the Uniform Resource Identifier (URI) of the content delivered, are examples of CDNI Logging fields.
CDNI日志字段：可包含在CDNI日志记录中的信息的原子元素。事件/任务开始的时间、内容交付给的最终用户的IP地址以及交付内容的统一资源标识符（URI）都是CDNI日志字段的示例。
CDNI Logging Record: An information record providing information about a specific event. This comprises a collection of CDNI Logging fields.
CDNI日志记录：提供特定事件信息的信息记录。这包括CDNI日志记录字段的集合。
CDNI Logging File: A file containing CDNI Logging Records, as well as additional information facilitating the processing of the CDNI Logging Records.
CDNI日志文件：包含CDNI日志记录的文件，以及便于处理CDNI日志记录的附加信息。
CDN Reporting: The process of providing the relevant information that will be used to create a formatted content delivery report provided to the Content Service Provider (CSP) in deferred time. Such information typically includes aggregated data that can cover a large
CDN报告：提供相关信息的过程，这些信息将用于创建在延迟时间内提供给内容服务提供商（CSP）的格式化内容交付报告。此类信息通常包括可以覆盖大量数据的聚合数据
period of time (e.g., from hours to several months). Uses of reporting include the collection of charging data related to CDN services and the computation of Key Performance Indicators (KPIs).
一段时间（例如，从小时到几个月）。报告的用途包括收集与CDN服务相关的收费数据和计算关键性能指标（KPI）。
CDN Monitoring: The process of providing or displaying content delivery information in a timely fashion with respect to the corresponding deliveries. Monitoring typically includes visibility of the deliveries in progress for service operation purposes. It presents a view of the global health of the services as well as information on usage and performance, for network services supervision and operation management. In particular, monitoring data can be used to generate alarms.
CDN监控：及时提供或显示与相应交付相关的内容交付信息的过程。监控通常包括出于服务运营目的对正在进行的交付的可见性。它展示了服务的全球健康状况以及有关使用和性能的信息，用于网络服务监督和操作管理。特别是，监控数据可用于生成警报。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的说明进行解释。
The CDNI logging reference model between a given uCDN and a given dCDN involves the following interactions:
给定uCDN和给定dCDN之间的CDNI日志记录参考模型涉及以下交互：
o customization by the uCDN of the CDNI Logging information to be provided by the dCDN to the uCDN (e.g., control of which CDNI Logging fields are to be communicated to the uCDN for a given task performed by the dCDN or control of which types of events are to be logged). The dCDN takes into account this CDNI Logging customization information to determine what Logging information to provide to the uCDN, but it may, or may not, take into account this CDNI Logging customization information to influence what CDN Logging information is to be generated and collected within the dCDN (e.g., even if the uCDN requests a restricted subset of the Logging information, the dCDN may elect to generate a broader set of Logging information). The mechanism to support the customization by the uCDN of CDNI Logging information is outside the scope of this document and is left for further study. Until such a mechanism is available, the uCDN and dCDN are expected to agree off-line on what exact set of CDNI Logging information is to be provided by the dCDN to the uCDN, and to rely on management-plane actions to configure the CDNI Logging functions in the dCDN to generate this information set and in the uCDN to expect this information set.
o uCDN自定义由dCDN向uCDN提供的CDNI日志信息（例如，控制哪些CDNI日志字段将被传送到uCDN，用于dCDN执行的给定任务，或者控制哪些类型的事件将被记录）。dCDN会考虑此CDNI日志定制信息，以确定向uCDN提供哪些日志信息，但它可能会也可能不会考虑此CDNI日志定制信息，以影响在dCDN内生成和收集哪些CDN日志信息（例如，即使uCDN请求日志信息的受限子集，dCDN也可以选择生成更广泛的日志信息集）。支持uCDN自定义CDNI日志信息的机制不在本文件范围内，有待进一步研究。在该机制可用之前，uCDN和dCDN应就dCDN向uCDN提供的确切CDNI日志信息集达成离线协议，并依赖管理在dCDN中配置CDNI日志功能以生成此信息集，在uCDN中配置此信息集的操作。
o generation and collection by the dCDN of the intra-CDN Logging information related to the completion of any task performed by the dCDN on behalf of the uCDN (e.g., delivery of the content to an end user) or related to events happening in the dCDN that are relevant to the uCDN (e.g., failures or unavailability in dCDN). This takes place within the dCDN and does not directly involve CDNI interfaces.
o dCDN生成和收集与完成dCDN代表uCDN执行的任何任务（例如，将内容交付给最终用户）或与dCDN中发生的与uCDN相关的事件（例如，dCDN中的故障或不可用）相关的内部CDN日志信息。这发生在dCDN内，不直接涉及CDNI接口。
o communication by the dCDN to the uCDN of the Logging information collected by the dCDN relevant to the uCDN. This is supported by the CDNI Logging interface and is in the scope of the present document. For example, the uCDN may use this Logging information to charge the CSP, to perform analytics and monitoring for operational reasons, to provide analytics and monitoring views on its content delivery to the CSP, or to perform troubleshooting. This document exclusively specifies non-real-time exchange of Logging information. Closer to real-time exchange of Logging information (say sub-minute or sub-second) is outside the scope of the present document and is left for further study. This document exclusively specifies exchange of Logging information related to content delivery. Exchange of Logging information related to operational events (e.g., dCDN request routing function unavailable and content acquisition failure by dCDN) for audit or operational reactive adjustments by uCDN is outside the scope of the present document and is left for further study.
o dCDN与uCDN之间的通信是dCDN收集的与uCDN相关的日志信息。这由CDNI日志接口支持，并且在本文档的范围内。例如，uCDN可使用此日志信息向CSP收费、出于运营原因执行分析和监控、提供其内容交付至CSP的分析和监控视图，或执行故障排除。本文件专门规定了日志信息的非实时交换。更接近实时的日志信息交换（例如分分钟或分秒）超出了本文件的范围，有待进一步研究。本文档专门指定与内容交付相关的日志信息的交换。uCDN为审计或操作响应性调整而交换与操作事件相关的日志信息（例如，dCDN请求路由功能不可用和dCDN的内容获取失败）超出了本文件的范围，留待进一步研究。
o customization by the dCDN of the CDNI Logging information to be provided by the uCDN on behalf of the dCDN. The mechanism to support the customization by the dCDN of CDNI Logging information is outside the scope of this document and is left for further study.
o dCDN自定义uCDN代表dCDN提供的CDNI日志信息。支持dCDN定制CDNI日志信息的机制超出了本文的范围，有待进一步研究。
o generation and collection by the uCDN of Intra-CDN Logging information related to the completion of any task performed by the uCDN on behalf of the dCDN (e.g., serving of content by uCDN to dCDN for acquisition purposes by dCDN) or related to events happening in the uCDN that are relevant to the dCDN. This takes place within the uCDN and does not directly involve CDNI interfaces.
o uCDN生成和收集与uCDN代表dCDN执行的任何任务的完成相关的内部CDN日志信息（例如，uCDN向dCDN提供内容以供dCDN获取），或与uCDN中发生的与dCDN相关的事件相关的内部CDN日志信息。这发生在uCDN内，不直接涉及CDNI接口。
o communication by the uCDN to the dCDN of the Logging information collected by the uCDN relevant to the dCDN. For example, the dCDN might potentially benefit from this information for security auditing or content acquisition troubleshooting. This is outside the scope of this document and is left for further study.
o uCDN与dCDN通信uCDN收集的与dCDN相关的日志信息。例如，dCDN可能会从这些信息中获益，用于安全审核或内容获取故障排除。这超出了本文件的范围，有待进一步研究。
Figure 1 provides an example of CDNI Logging interactions (focusing only on the interactions that are in the scope of this document) in a particular scenario where four CDNs are involved in the delivery of content from a given CSP: the uCDN has a CDNI interconnection with dCDN-1 and dCDN-2. In turn, dCDN-2 has a CDNI interconnection with dCDN-3, where dCDN-2 is acting as an upstream CDN relative to dCDN-3. In this example, uCDN, dCDN-1, dCDN-2, and dCDN-3 all participate in the delivery of content for the CSP. In this example, the CDNI Logging interface enables the uCDN to obtain Logging information from all the dCDNs involved in the delivery. In the example, the uCDN uses the Logging information:
图1提供了一个特定场景中CDNI日志交互的示例（仅关注本文档范围内的交互），其中四个CDN参与了给定CSP的内容交付：uCDN与dCDN-1和dCDN-2之间存在CDNI互连。反过来，dCDN-2具有与dCDN-3的CDNI互连，其中dCDN-2充当相对于dCDN-3的上游CDN。在本例中，uCDN、dCDN-1、dCDN-2和dCDN-3都参与CSP的内容交付。在本例中，CDNI日志接口使uCDN能够从交付中涉及的所有DCDN获取日志信息。在本例中，uCDN使用以下日志信息：
o to analyze the performance of the delivery performed by the dCDNs and to adjust its operations after the fact (e.g., request routing) as appropriate.
o 分析dCDNs执行的交付的性能，并根据情况调整其事后操作（例如，请求路由）。
o to provide (non-real-time) reporting and monitoring information to the CSP.
o 向顾客服务提供商提供（非实时）报告和监控信息。
For instance, the uCDN merges Logging information, extracts relevant KPIs, and presents a formatted report to the CSP, in addition to a bill for the content delivered by uCDN itself or by its dCDNs on the CSP's behalf. The uCDN may also provide Logging information as raw log files to the CSP, so that the CSP can use its own logging analysis tools.
例如，除了uCDN本身或代表CSP的DCDN交付的内容账单外，uCDN还合并日志信息，提取相关KPI，并向CSP提供格式化报告。uCDN还可以将日志信息作为原始日志文件提供给CSP，以便CSP可以使用自己的日志分析工具。
+-----+
| CSP |
+-----+
^ Reporting and monitoring data
* Billing
,--*--.
Logging ,-' `-.
Data =>( uCDN )<= Logging
// `-. _,-' \\ Data
|| `-'-'-' ||
,-----. ,-----.
,-' `-. ,-' `-.
( dCDN-1 ) ( dCDN-2 )<== Logging
`-. ,-' `-. _,-' \\ Data
`--'--' `--'-' ||
,-----.
,' `-.
( dCDN-3 )
`. ,-'
`--'--'
+-----+
| CSP |
+-----+
^ Reporting and monitoring data
* Billing
,--*--.
Logging ,-' `-.
Data =>( uCDN )<= Logging
// `-. _,-' \\ Data
|| `-'-'-' ||
,-----. ,-----.
,-' `-. ,-' `-.
( dCDN-1 ) ( dCDN-2 )<== Logging
`-. ,-' `-. _,-' \\ Data
`--'--' `--'-' ||
,-----.
,' `-.
( dCDN-3 )
`. ,-'
`--'--'
===> CDNI Logging interface
***> outside the scope of CDNI
===> CDNI Logging interface
***> outside the scope of CDNI
Figure 1: Interactions in the CDNI Logging Reference Model
图1:CDNI日志参考模型中的交互
A downstream CDN relative to uCDN (e.g., dCDN-2) integrates the relevant Logging information obtained from its own downstream CDNs (i.e., dCDN-3) in the Logging information that it provides to the uCDN, so that the uCDN ultimately obtains all Logging information relevant to a CSP for which it acts as the authoritative CDN. Such aggregation is further discussed in Section 3.7.
相对于uCDN的下游CDN（例如，dCDN-2）将从其自身的下游CDN（即，dCDN-3）获得的相关日志信息集成到其提供给uCDN的日志信息中，以便uCDN最终获得与其作为权威CDN的CSP相关的所有日志信息。第3.7节将进一步讨论此类汇总。
Note that the format of Logging information that a CDN provides over the CDNI interface might be different from the one that the CDN uses internally. In this case, the CDN needs to reformat the Logging information before it provides this information to the other CDN over the CDNI Logging interface. Similarly, a CDN might reformat the Logging information that it receives over the CDNI Logging interface before injecting it into its log-consuming applications or before providing some of this Logging information to the CSP. Such reformatting operations introduce latency in the logging distribution chain and introduce a processing burden. Therefore, there are benefits in specifying CDNI Logging formats that are suitable for use inside CDNs and also are close to the intra-CDN Logging formats commonly used in CDNs today.
请注意，CDN通过CDNI接口提供的日志信息格式可能与CDN内部使用的格式不同。在这种情况下，CDN需要重新格式化日志信息，然后才能通过CDNI日志接口将此信息提供给其他CDN。类似地，CDN可能会在将其注入日志消耗应用程序或向CSP提供部分日志信息之前，重新格式化通过CDNI日志接口接收的日志信息。这种重新格式化操作在日志分发链中引入延迟，并引入处理负担。因此，指定适合在CDN内使用的CDNI日志记录格式有好处，并且与当前CDN中常用的CDN内日志记录格式非常接近。
This section discusses the overall logging chain within and across CDNs to clarify how CDN Logging information is expected to fit in this overall chain. Figure 2 illustrates the overall logging chain within the dCDN, across CDNs using the CDNI Logging interface, and within the uCDN. Note that the logging chain illustrated in the figure is obviously only an example and varies depending on the specific environments. For example, there may be more or fewer instantiations of each entity (e.g., there may be 4 log-consuming applications in a given CDN). As another example, there may be one instance of a Rectification process per log-consuming application instead of a shared one.
本节讨论了CDN内部和跨CDN的整个日志记录链，以阐明CDN日志记录信息将如何适应整个链。图2展示了dCDN内、使用CDNI日志接口跨CDN以及uCDN内的整个日志记录链。请注意，图中所示的日志记录链显然只是一个示例，根据具体环境而有所不同。例如，每个实体可能有更多或更少的实例化（例如，在给定CDN中可能有4个使用日志的应用程序）。作为另一个示例，每个日志使用应用程序可能有一个校正过程实例，而不是一个共享实例。
Log-Consuming Log-Consuming
App App
^ ^
| |
Rectification----------
^
|
Filtering
^
|
Collection
^ ^
| |
| Generation
|
| uCDN
CDNI Logging ---------------------------------------------------
exchange dCDN
^
| Log-Consuming Log-Consuming
| App App
| ^ ^
| | |
Rectification Rectification---------
^ ^
| |
Filtering
^
|
Collection
^ ^
| |
Generation Generation
Log-Consuming Log-Consuming
App App
^ ^
| |
Rectification----------
^
|
Filtering
^
|
Collection
^ ^
| |
| Generation
|
| uCDN
CDNI Logging ---------------------------------------------------
exchange dCDN
^
| Log-Consuming Log-Consuming
| App App
| ^ ^
| | |
Rectification Rectification---------
^ ^
| |
Filtering
^
|
Collection
^ ^
| |
Generation Generation
Figure 2: CDNI Logging in the Overall Logging Chain
图2：整个日志记录链中的CDNI日志记录
The following subsections describe each of the processes potentially involved in the logging chain of Figure 2.
以下小节描述了图2的日志记录链中可能涉及的每个过程。
CDNs typically generate Logging information for all significant task completions, events, and failures. Logging information is typically generated by many devices in the CDN including the surrogates, the request routing system, and the control system.
CDN通常会生成所有重要任务完成、事件和失败的日志信息。日志信息通常由CDN中的许多设备生成，包括代理、请求路由系统和控制系统。
The amount of Logging information generated can be huge. Therefore, during contract negotiations, interconnected CDNs often agree on a retention duration for Logging information, and/or potentially on a maximum volume of Logging information that the dCDN ought to keep. If this volume is exceeded, the dCDN is expected to alert the uCDN but may not keep more Logging information for the considered time period. In addition, CDNs may aggregate Logging information and transmit only summaries for some categories of operations instead of the full Logging information. Note that such aggregation leads to an information loss, which may be problematic for some usages of the Logging information (e.g., debugging).
生成的日志信息量可能是巨大的。因此，在合同谈判期间，互连的CDN通常就日志信息的保留期限达成一致，和/或可能就dCDN应保留的最大日志信息量达成一致。如果超过此卷，dCDN将向uCDN发出警报，但可能不会在考虑的时间段内保留更多日志信息。此外，CDN可以聚合日志信息，并仅传输某些类别操作的摘要，而不是完整的日志信息。请注意，这种聚合会导致信息丢失，这对于日志信息的某些用法（例如调试）可能会有问题。
[RFC6983] discusses logging for HTTP Adaptive Streaming (HAS). In accordance with the recommendations articulated there, it is expected that a surrogate will generate separate Logging information for delivery of each chunk of HAS content. This ensures that separate Logging information can then be provided to interconnected CDNs over the CDNI Logging interface. Still in line with the recommendations of [RFC6983], the Logging information for per-chunk delivery may include some information (a Content Collection IDentifier and a Session IDentifier) intended to facilitate subsequent post-generation aggregation of per-chunk logs into per-session logs. Note that a CDN may also elect to generate aggregate per-session logs when performing HAS delivery, but this needs to be in addition to, and not instead of, the per-chunk delivery logs. We note that aggregate per-session logs for HAS delivery are for further study and are outside the scope of this document.
[RFC6983]讨论HTTP自适应流（HAS）的日志记录。根据此处阐述的建议，预计代理将为HAS内容的每个区块的交付生成单独的日志信息。这确保了可以通过CDNI日志接口向互连的CDN提供单独的日志信息。仍然符合[RFC6983]的建议，每个区块交付的日志信息可能包括一些信息（内容收集标识符和会话标识符），旨在促进后续生成后将每个区块日志聚合到每个会话日志中。请注意，CDN也可以选择在执行HAS传递时生成聚合的每会话日志，但这需要是对每区块传递日志的补充，而不是替代。我们注意到，HAS交付的每个会话的聚合日志用于进一步研究，不在本文档的范围内。
This is the process that continuously collects Logging information generated by the log-generating entities within a CDN.
这是连续收集CDN中日志生成实体生成的日志信息的过程。
In a CDNI environment, in addition to collecting Logging information from log-generating entities within the local CDN, the Collection process also collects Logging information provided by another CDN, or other CDNs, through the CDNI Logging interface. This is illustrated in Figure 2 where we see that the Collection process of the uCDN collects Logging information from log-generating entities within the uCDN as well as Logging information coming from the dCDNs through the CDNI Logging interface.
在CDNI环境中，除了从本地CDN内的日志生成实体收集日志信息外，收集过程还通过CDNI日志接口收集另一个CDN或其他CDN提供的日志信息。这如图2所示，其中我们看到uCDN的收集过程从uCDN内的日志生成实体收集日志信息，以及通过CDNI日志接口从DCDN收集日志信息。
A CDN may be required to only present different subsets of the whole Logging information collected to various log-consuming applications. This is achieved by the Filtering process.
CDN可能只需要向各种日志使用应用程序提供所收集的整个日志信息的不同子集。这是通过过滤过程实现的。
In particular, the Filtering process can also filter the right subset of Logging information that needs to be provided to a given interconnected CDN. For example, the filtering process in the dCDN can be used to ensure that only the Logging information related to tasks performed on behalf of a given uCDN are made available to that uCDN (thereby filtering out all the Logging information related to deliveries by the dCDN of content for its own CSPs). Similarly, the Filtering process may filter or partially mask some fields, for example, to protect end-users' privacy when communicating CDNI Logging information to another CDN. Filtering of Logging information prior to communication of this information to other CDNs via the CDNI Logging interface requires that the downstream CDN can recognize the subset of Logging information that relates to each interconnected CDN.
具体而言，过滤过程还可以过滤需要提供给给定互连CDN的日志信息的正确子集。例如，dCDN中的过滤过程可用于确保只有与代表给定uCDN执行的任务相关的日志记录信息可供该uCDN使用（从而过滤掉与dCDN为其自己的CSP交付内容相关的所有日志记录信息）。类似地，过滤过程可以过滤或部分屏蔽某些字段，例如，在将CDNI日志信息传送到另一CDN时保护最终用户的隐私。在通过CDNI日志接口将该信息通信到其他CDN之前，日志信息的过滤要求下游CDN能够识别与每个互连CDN相关的日志信息子集。
The CDN will also filter some internal scope information such as information related to its internal alarms (security, failures, load, etc.).
CDN还将过滤一些内部范围信息，如与其内部警报（安全、故障、负载等）相关的信息。
In some use cases described in [RFC6770], the interconnected CDNs do not want to disclose details on their internal topology. The filtering process can then also filter confidential data on the dCDNs' topology (number of servers, location, etc.). In particular, information about the requests served by each Surrogate may be confidential. Therefore, the Logging information needs to be protected so that data such as the Surrogates' hostnames are not disclosed to the uCDN. In the "Inter-Affiliates Interconnection" use case, this information may be disclosed to the uCDN because both the dCDN and the uCDN are operated by entities of the same group.
在[RFC6770]中描述的某些用例中，互连的CDN不想透露其内部拓扑的细节。然后，过滤过程还可以过滤dCDNs拓扑上的机密数据（服务器数量、位置等）。特别是，关于每个代理服务请求的信息可能是保密的。因此，需要保护日志信息，以便不向uCDN披露代理主机名等数据。在“子公司间互连”用例中，该信息可能会披露给uCDN，因为dCDN和uCDN都由同一集团的实体运营。
If Logging information is generated periodically, it is important that the sessions that start in one Logging period and end in another are correctly reported. If they are reported in the starting period, then the Logging information of this period will be available only after the end of the session, which delays the Logging information generation. A simple approach is to provide the complete Logging Record for a session in the Logging Period of the session end.
如果定期生成日志记录信息，则正确报告在一个日志记录期间开始并在另一个日志记录期间结束的会话非常重要。如果在开始期间报告，则此期间的日志记录信息仅在会话结束后可用，这会延迟日志记录信息的生成。一种简单的方法是在会话结束的日志记录期间为会话提供完整的日志记录。
A Logging rectification/update mechanism could be useful to reach a good trade-off between the Logging information generation delay and the Logging information accuracy.
日志校正/更新机制有助于在日志信息生成延迟和日志信息准确性之间达成良好的平衡。
In the presence of HAS, some log-consuming applications can benefit from aggregate per-session logs. For example, for analytics, per-session logs allow display of session-related trends, which are much more meaningful for some types of analysis than chunk-related trends.
在HAS存在的情况下，一些日志消耗应用程序可以从聚合每会话日志中获益。例如，对于分析，每个会话日志允许显示会话相关的趋势，这对于某些类型的分析比区块相关的趋势更有意义。
In the case where aggregate logs have been generated directly by the log-generating entities, those can be used by the applications. In the case where aggregate logs have not been generated, the Rectification process can be extended with a Post-Generation Aggregation process that generates per-session logs from the per-chunk logs, possibly leveraging the information included in the per-chunk logs for that purpose (Content Collection IDentifier and a Session IDentifier). However, in accordance with [RFC6983], this document does not define the exchange of such aggregate logs on the CDNI Logging interface. We note that this is for further study and is outside the scope of this document.
在日志生成实体直接生成聚合日志的情况下，应用程序可以使用这些聚合日志。在未生成聚合日志的情况下，可以使用生成后聚合过程来扩展校正过程，该生成后聚合过程从每区块日志生成每会话日志，可能为此目的利用每区块日志中包含的信息（内容收集标识符和会话标识符）。但是，根据[RFC6983]，本文件未定义CDNI日志接口上此类聚合日志的交换。我们注意到，这是为了进一步研究，不在本文件的范围之内。
Logging information is useful to permit the detection (and limit the risk) of content delivery failures. In particular, Logging information facilitates the detection of configuration issues.
日志信息有助于检测（并限制风险）内容交付失败。特别是，日志信息有助于检测配置问题。
To detect faults, Logging information needs to report the success and failure of CDN-delivery operations. The uCDN can summarize such information into KPIs. For instance, Logging information needs to allow the computation of the number of times, during a given time period, that content delivery related to a specific service succeeds or fails.
要检测故障，日志信息需要报告CDN交付操作的成功与失败。uCDN可以将此类信息汇总为KPI。例如，日志信息需要允许计算给定时间段内与特定服务相关的内容交付成功或失败的次数。
Logging information enables the CDN providers to identify and troubleshoot performance degradations. In particular, Logging information enables tracking of traffic data (e.g., the amount of traffic that has been forwarded by a dCDN on behalf of an uCDN over a given period of time), which is particularly useful for CDN and network planning operations.
日志记录信息使CDN提供商能够识别性能下降并对其进行故障排除。尤其是，日志信息能够跟踪流量数据（例如，在给定时间段内由dCDN代表uCDN转发的流量量），这对于CDN和网络规划操作特别有用。
Some of these maintenance and debugging applications only require aggregate Logging information highly compatible with the use of anonymization of IP addresses (as supported by the present document and specified in the definition of the c-groupid field in Section 3.4.1). However, in some situations, it may be useful, where compatible with privacy protection, to access some CDNI Logging Records containing full non-anonymized IP addresses. This is allowed in the definition of the c-groupid (in Section 3.4.1), with very significant privacy protection limitations that are discussed in the definition of the c-groupid field. For example, this may be useful for detailed fault tracking of a particular end-user content delivery issue. Where there is a hard requirement by uCDN or CSP to associate a given end user to individual CDNI Logging Records (e.g., to allow a posteriori analysis of individual delivery, for example, in
其中一些维护和调试应用程序只需要与IP地址匿名化的使用高度兼容的聚合日志记录信息（如本文件所支持，并在第3.4.1节中的c-groupid字段定义中规定）。但是，在某些情况下，在与隐私保护兼容的情况下，访问一些包含完整非匿名IP地址的CDNI日志记录可能会很有用。这在c-groupid的定义（第3.4.1节）中是允许的，在c-groupid字段的定义中讨论了非常重要的隐私保护限制。例如，这对于特定最终用户内容交付问题的详细故障跟踪可能很有用。当uCDN或CSP要求将给定最终用户与单个CDNI日志记录关联时（例如，允许对单个交付进行事后分析，例如
situations of performance-based penalties), instead of using aggregates containing a single client as discussed in the c-groupid field definition, an alternate approach is to ensure that a client identifier is embedded in the request fields that can be logged in a CDNI Logging Record (for example, by including the client identifier in the URI query string or in an HTTP Header). That latter approach offers two significant benefits: first, the aggregate inside the c-groupid can contain more than one client, thereby ensuring stronger privacy protection; second, it allows a reliable identification of the client while IP address does not in many situations (e.g., behind NAT, where dynamic IP addresses are used and reused, etc.). However, care SHOULD be taken so that the client identifiers exposed in other fields of the CDNI Records cannot themselves be linked back to actual users.
基于性能的惩罚情况），而不是像c-groupid字段定义中讨论的那样使用包含单个客户机的聚合，另一种方法是确保客户机标识符嵌入到可以记录在CDNI日志记录中的请求字段中（例如，通过在URI查询字符串或HTTP头中包含客户端标识符）。后一种方法提供了两个显著的好处：第一，c-groupid中的聚合可以包含多个客户端，从而确保更强的隐私保护；第二，它允许可靠地识别客户端，而IP地址在许多情况下都不允许（例如，在NAT后面，使用和重用动态IP地址等）。但是，应注意使CDNI记录的其他字段中暴露的客户端标识符本身不能链接回实际用户。
Logging information is essential for accounting, to permit inter-CDN billing and CSP billing by uCDNs. For instance, Logging information provided by dCDNs enables the uCDN to compute the total amount of traffic delivered by every dCDN for a particular Content Provider, as well as the associated bandwidth usage (e.g., peak, 95th percentile), and the maximum number of simultaneous sessions over a given period of time.
日志信息对于记帐至关重要，以允许uCDNs进行CDN间计费和CSP计费。例如，dCDNs提供的日志信息使uCDN能够计算特定内容提供商的每个dCDN交付的流量总量，以及相关的带宽使用率（例如，峰值，第95百分位），以及给定时间段内同时会话的最大数量。
The goals of analytics include gathering any relevant information in order to be able to develop statistics on content download, analyze user behavior, and monitor the performance and quality of content delivery. For instance, Logging information enables the CDN providers to report on content consumption (e.g., delivered sessions per content) in a specific geographic area.
分析的目标包括收集任何相关信息，以便能够对内容下载进行统计，分析用户行为，并监控内容交付的性能和质量。例如，日志记录信息使CDN提供商能够报告特定地理区域内的内容使用情况（例如，每个内容交付的会话）。
The goal of reporting is to gather any relevant information to monitor the performance and quality of content delivery, and allow detection of delivery issues. For instance, reporting could track the average delivery throughput experienced by end users in a given region for a specific CSP or content set over a period of time.
报告的目标是收集任何相关信息，以监控内容交付的性能和质量，并允许检测交付问题。例如，报告可以跟踪特定CSP或内容集在一段时间内特定地区的最终用户所经历的平均交付吞吐量。
The goal of content protection is to prevent and monitor unauthorized access, misuse, modification, and denial of access to content. A set of information is logged in a CDN for security purposes. In particular, a record of access to content is usually collected to permit the CSP to detect infringements of content delivery policies and other abnormal end-user behaviors.
内容保护的目标是防止和监视未经授权的访问、误用、修改和拒绝访问内容。出于安全目的，将一组信息记录在CDN中。特别是，通常会收集内容访问记录，以允许CSP检测违反内容交付策略和其他异常最终用户行为的情况。
Within a given log-consuming application, different views may be provided to different users depending on privacy, business, and scalability constraints.
在给定的日志消费应用程序中，根据隐私、业务和可伸缩性约束，可能会向不同的用户提供不同的视图。
For example, an analytics tool run by the uCDN can provide one view to a uCDN operator that exploits all the Logging information available to the uCDN, while the tool may provide a different view to each CSP exploiting only the Logging information related to the content of the given CSP.
例如，uCDN运行的分析工具可以向uCDN运营商提供一个视图，该视图利用uCDN可用的所有日志信息，而该工具可以向每个CSP提供不同的视图，仅利用与给定CSP内容相关的日志信息。
As another example, maintenance and debugging tools may provide different views to different CDN operators, based on their operational role.
另一个例子是，维护和调试工具可以根据不同CDN运营商的运营角色为他们提供不同的视图。
This section presents, for explanatory purposes, a non-exhaustive list of Key Performance Indicators (KPIs) that can be extracted/ produced from logs.
为了便于解释，本节提供了可从日志中提取/生成的关键绩效指标（KPI）的非详尽列表。
Multiple log-consuming applications, such as analytics, monitoring, and maintenance applications, often compute and track such KPIs.
多个日志消耗应用程序（如分析、监控和维护应用程序）通常会计算和跟踪此类KPI。
In a CDNI environment, depending on the situation, these KPIs may be computed by the uCDN or by the dCDN. But it is usually the uCDN that computes KPIs, because the uCDN and dCDN may have different definitions of the KPIs and the computation of some KPIs requires a vision of all the deliveries performed by the uCDN and all its dCDNs.
在CDNI环境中，根据情况，这些KPI可以由uCDN或dCDN计算。但计算KPI的通常是uCDN，因为uCDN和dCDN可能对KPI有不同的定义，并且某些KPI的计算需要对uCDN及其所有dCDN执行的所有交付进行展望。
Here is a list of important examples of KPIs:
以下是KPI的重要示例列表：
o Number of delivery requests received from end users in a given region for each piece of content, during a given period of time (e.g., hour/day/week/month)
o 在给定的时间段（例如，小时/天/周/月）内，从给定区域的最终用户处收到的每段内容的交付请求数
o Percentage of delivery successes/failures among the aforementioned requests
o 上述请求中交付成功/失败的百分比
o Number of failures listed by failure type (e.g., HTTP error code) for requests received from end users in a given region and for each piece of content, during a given period of time (e.g., hour/day/week/month)
o 在给定的时间段（例如，小时/天/周/月）内，针对从给定区域的最终用户接收到的请求以及针对每项内容，按故障类型（例如，HTTP错误代码）列出的故障数
o Number and cause of premature delivery termination for end users in a given region and for each piece of content, during a given period of time (e.g., hour/day/week/month)
o 在给定的时间段内（例如，小时/天/周/月），特定区域内的最终用户和每一内容提前终止交付的次数和原因
o Maximum and mean number of simultaneous sessions established by end users in a given region, for a given Content Provider, and during a given period of time (e.g., hour/day/week/month)
o 终端用户在给定区域、给定内容提供商和给定时间段（例如，小时/天/周/月）内同时建立的最大和平均会话数
o Volume of traffic delivered for sessions established by end users in a given region, for a given Content Provider, and during a given period of time (e.g., hour/day/week/month)
o 在给定的时间段内（例如，小时/天/周/月），终端用户在给定的区域、给定的内容提供商建立的会话的流量
o Maximum, mean, and minimum delivery throughput for sessions established by end users in a given region, for a given Content Provider, and during a given period of time (e.g., hour/day/week/ month)
o 终端用户在给定区域、给定内容提供商和给定时间段（例如，小时/天/周/月）内建立的会话的最大、平均和最小交付吞吐量
o Cache-hit and byte-hit ratios for requests received from end users in a given region for each piece of content, during a given period of time (e.g., hour/day/week/month)
o 在给定时间段（例如，小时/天/周/月）内，在给定区域内接收到的每个内容的最终用户请求的缓存命中率和字节命中率
o Top 10 most popularly requested contents (during a given day/week/ month)
o 十大最受欢迎的请求内容（在给定的日期/周/月内）
o Terminal type (mobile, PC, Set-Top Box (STB), if this information can be acquired from the browser type inferred from the User Agent string, for example)
o 终端类型（移动、PC、机顶盒（STB），如果可以从从用户代理字符串推断的浏览器类型获取此信息，例如）
Additional KPIs can be computed from other sources of information than the Logging information, for instance, data collected by a content portal or by specific client-side application programming interfaces. Such KPIs are out of scope for the present document.
可以从日志信息以外的其他信息源计算其他KPI，例如，由内容门户或特定客户端应用程序编程接口收集的数据。此类KPI超出了本文件的范围。
The KPIs used depend strongly on the considered log-consuming application -- the CDN operator may be interested in different metrics than the CSP. In particular, CDN operators are often interested in delivery and acquisition performance KPIs, information related to Surrogates' performance, caching information to evaluate the cache-hit ratio, information about the delivered file size to compute the volume of content delivered during peak hour, etc.
所使用的KPI在很大程度上取决于所考虑的日志消耗应用程序——CDN运营商可能对CSP以外的不同指标感兴趣。尤其是，CDN运营商通常对交付和获取性能KPI、与代理服务器性能相关的信息、用于评估缓存命中率的缓存信息、用于计算高峰时段交付内容量的有关交付文件大小的信息等感兴趣。
Some of the KPIs, for instance those providing an instantaneous vision of the active sessions for a given CSP's content, are useful essentially if they are provided in a timely manner. By contrast, some other KPIs, such as those averaged over a long period of time, can be provided in non-real-time.
一些KPI，例如那些为给定CSP的内容提供活动会话即时视图的KPI，如果及时提供，基本上是有用的。相比之下，其他一些KPI（如长时间平均的KPI）可以非实时提供。
This specification uses the Augmented Backus-Naur Form (ABNF) notation and core rules of [RFC5234]. In particular, the present document uses the following rules from [RFC5234]:
本规范使用了[RFC5234]的增广巴科斯诺尔形式（ABNF）符号和核心规则。特别是，本文件使用[RFC5234]中的以下规则：
CR = %x0D ; carriage return
CR = %x0D ; carriage return
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
DIGIT = %x30-39 ; 0-9
DQUOTE = %x22 ; " (Double Quote)
DQUOTE = %x22 ; " (Double Quote)
CRLF = CR LF ; Internet standard newline
CRLF=CRLF；互联网标准新线
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
HTAB = %x09 ; horizontal tab
HTAB = %x09 ; horizontal tab
LF = %x0A ; linefeed
LF = %x0A ; linefeed
VCHAR = %x21-7E ; visible (printing) characters
VCHAR = %x21-7E ; visible (printing) characters
OCTET = %x00-FF ; 8 bits of data
OCTET = %x00-FF ; 8 bits of data
The present document also uses the following rules from [RFC3986]:
本文件还使用了[RFC3986]中的以下规则：
host = as specified in Section 3.2.2 of [RFC3986].
主机=按照[RFC3986]第3.2.2节的规定。
IPv4address = as specified in Section 3.2.2 of [RFC3986].
IPv4address=如[RFC3986]第3.2.2节所述。
IPv6address = as specified in Section 3.2.2 of [RFC3986].
IPV6地址=按照[RFC3986]第3.2.2节的规定。
partial-time = as specified in Section 5.6 of [RFC3339].
部分时间=按照[RFC3339]第5.6节的规定。
The present document also defines the following additional rules:
本文件还规定了以下补充规则：
ADDRESS = IPv4address / IPv6address
ADDRESS = IPv4address / IPv6address
ALPHANUM = ALPHA / DIGIT
ALPHANUM = ALPHA / DIGIT
DATE = 4DIGIT "-" 2DIGIT "-" 2DIGIT
日期=4数字“-”2数字“-”2数字
; Dates are encoded as "full-date" specified in [RFC3339].
; 日期编码为[RFC3339]中指定的“完整日期”。
DEC = 1*DIGIT ["." 1*DIGIT]
DEC = 1*DIGIT ["." 1*DIGIT]
NAMEFORMAT = ALPHANUM *(ALPHANUM / "_" / "-")
NAMEFORMAT = ALPHANUM *(ALPHANUM / "_" / "-")
QSTRING = DQUOTE *(NDQUOTE / PCT-ENCODED) DQUOTE
QSTRING = DQUOTE *(NDQUOTE / PCT-ENCODED) DQUOTE
NDQUOTE = %x20-21 / %x23-24 / %x26-7E / UTF8-2 / UTF8-3 / UTF8-4
NDQUOTE = %x20-21 / %x23-24 / %x26-7E / UTF8-2 / UTF8-3 / UTF8-4
; whereby a DQUOTE is conveyed inside a QSTRING unambiguously ; by escaping it with PCT-ENCODED.
; 其中DQUOTE在QSTRING中被明确地传递；通过使用PCT编码对其进行转义。
PCT-ENCODED = "%" HEXDIG HEXDIG
PCT-ENCODED=“%”HEXDIG HEXDIG
; percent encoding is used for escaping octets that might be
; possible in HTTP headers such as bare CR, bare LF, CR LF,
; HTAB, SP, or null. These octets are rendered with percent
; encoding in ABNF as specified by [RFC3986] in order to avoid
; considering them as separators for the Logging Records.
; percent encoding is used for escaping octets that might be
; possible in HTTP headers such as bare CR, bare LF, CR LF,
; HTAB, SP, or null. These octets are rendered with percent
; encoding in ABNF as specified by [RFC3986] in order to avoid
; considering them as separators for the Logging Records.
NHTABSTRING = 1*(SP / VCHAR)
NHTABSTRING = 1*(SP / VCHAR)
TIME = partial-time
TIME = partial-time
USER-COMMENT = *(SP / VCHAR / UTF8-2 / UTF8-3 / UTF8-4)
USER-COMMENT = *(SP / VCHAR / UTF8-2 / UTF8-3 / UTF8-4)
As defined in Section 1.1, a CDNI Logging Field is an atomic Logging information element, a CDNI Logging Record is a collection of CDNI Logging fields containing all logging information corresponding to a single logging event, and a CDNI Logging File contains a collection of CDNI Logging Records. This structure is illustrated in Figure 3. The use of a file structure for transfer of CDNI Logging information is selected since this is the most common practice today for exchange of Logging information within and across CDNs.
如第1.1节所定义，CDNI日志记录字段是一个原子日志记录信息元素，CDNI日志记录是包含与单个日志记录事件对应的所有日志记录信息的CDNI日志记录字段的集合，CDNI日志记录文件包含CDNI日志记录的集合。该结构如图3所示。选择使用文件结构传输CDNI日志信息，因为这是当前在CDN内部和跨CDN交换日志信息的最常见做法。
+----------------------------------------------------------+
|CDNI Logging File |
| |
| #Directive 1 |
| #Directive 2 |
| ... |
| #Directive P |
| |
| +------------------------------------------------------+ |
| |CDNI Logging Record 1 | |
| | +-------------+ +-------------+ +-------------+ | |
| | |CDNI Logging | |CDNI Logging | ... |CDNI Logging | | |
| | | Field 1 | | Field 2 | | Field N | | |
| | +-------------+ +-------------+ +-------------+ | |
| +------------------------------------------------------+ |
| |
| +------------------------------------------------------+ |
| |CDNI Logging Record 2 | |
| | +-------------+ +-------------+ +-------------+ | |
| | |CDNI Logging | |CDNI Logging | ... |CDNI Logging | | |
| | | Field 1 | | Field 2 | | Field N | | |
| | +-------------+ +-------------+ +-------------+ | |
| +------------------------------------------------------+ |
| |
| ... |
| |
| #Directive P+1 |
| |
| ... |
| |
| +------------------------------------------------------+ |
| |CDNI Logging Record M | |
| | +-------------+ +-------------+ +-------------+ | |
| | |CDNI Logging | |CDNI Logging | ... |CDNI Logging | | |
| | | Field 1 | | Field 2 | | Field N | | |
| | +-------------+ +-------------+ +-------------+ | |
| +------------------------------------------------------+ |
| |
| |
| #Directive P+Q |
+----------------------------------------------------------+
+----------------------------------------------------------+
|CDNI Logging File |
| |
| #Directive 1 |
| #Directive 2 |
| ... |
| #Directive P |
| |
| +------------------------------------------------------+ |
| |CDNI Logging Record 1 | |
| | +-------------+ +-------------+ +-------------+ | |
| | |CDNI Logging | |CDNI Logging | ... |CDNI Logging | | |
| | | Field 1 | | Field 2 | | Field N | | |
| | +-------------+ +-------------+ +-------------+ | |
| +------------------------------------------------------+ |
| |
| +------------------------------------------------------+ |
| |CDNI Logging Record 2 | |
| | +-------------+ +-------------+ +-------------+ | |
| | |CDNI Logging | |CDNI Logging | ... |CDNI Logging | | |
| | | Field 1 | | Field 2 | | Field N | | |
| | +-------------+ +-------------+ +-------------+ | |
| +------------------------------------------------------+ |
| |
| ... |
| |
| #Directive P+1 |
| |
| ... |
| |
| +------------------------------------------------------+ |
| |CDNI Logging Record M | |
| | +-------------+ +-------------+ +-------------+ | |
| | |CDNI Logging | |CDNI Logging | ... |CDNI Logging | | |
| | | Field 1 | | Field 2 | | Field N | | |
| | +-------------+ +-------------+ +-------------+ | |
| +------------------------------------------------------+ |
| |
| |
| #Directive P+Q |
+----------------------------------------------------------+
Figure 3: Structure of Logging Files
图3：日志文件的结构
The CDNI Logging File format is inspired from the W3C Extended Log File Format [ELF]. However, it is fully specified by the present document. Where the present document differs from the W3C Extended Log File Format, an implementation of the CDNI Logging interface MUST comply with the present document. The W3C Extended Log File Format was used as a starting point, reused where possible, and expanded when necessary.
CDNI日志文件格式受W3C扩展日志文件格式[ELF]的启发。然而，本文件对此作了充分规定。如果本文档与W3C扩展日志文件格式不同，CDNI日志接口的实现必须符合本文档。W3C扩展日志文件格式被用作起点，在可能的情况下重用，并在必要时进行扩展。
Using a format that resembles the W3C Extended Log File Format is intended to keep the CDNI logging format close to the intra-CDN Logging information format commonly used in CDNs today, thereby minimizing systematic translation at the CDN/CDNI boundary.
使用类似于W3C扩展日志文件格式的格式旨在使CDNI日志格式与当前CDN中常用的CDN内日志信息格式保持一致，从而最大限度地减少CDN/CDNI边界处的系统转换。
A CDNI Logging File MUST contain a sequence of lines containing US-ASCII characters [CHAR_SET] terminated by CRLF. Each line of a CDNI Logging File MUST contain either a directive or a CDNI Logging Record.
CDNI日志文件必须包含包含由CRLF终止的US-ASCII字符[CHAR_SET]的行序列。CDNI日志文件的每一行必须包含指令或CDNI日志记录。
Directives record information about the CDNI Logging process itself. Lines containing directives MUST begin with the "#" character. Directives are specified in Section 3.3.
指令记录有关CDNI日志记录过程本身的信息。包含指令的行必须以“#”字符开头。第3.3节规定了指令。
Logging Records provide actual details of the logged event. Logging Records are specified in Section 3.4.
日志记录提供所记录事件的实际详细信息。第3.4节规定了日志记录。
The CDNI Logging File has a specific structure. It always starts with a directive line, and the first directive it contains MUST be the version.
CDNI日志文件具有特定的结构。它总是以指令行开始，它包含的第一个指令必须是版本。
The directive lines form together a group that contains at least one directive line. Each directives group is followed by a group of Logging Records. The records group contains zero or more actual Logging Record lines about the event being logged. A record line consists of the values corresponding to all or a subset of the possible Logging fields defined within the scope of the record-type directive. These values MUST appear in the order defined by the fields directive.
指令行一起构成一个组，该组至少包含一条指令行。每个指令组后面都有一组日志记录。records（记录）组包含零行或多行关于所记录事件的实际日志记录行。记录行由对应于记录类型指令范围内定义的所有或一个子集的可能日志字段的值组成。这些值必须按照fields指令定义的顺序显示。
Note that future extensions MUST be compliant with the previous description. The following examples depict the structure of a CDNILOGFILE as defined currently by the record-type "cdni_http_request_v1."
请注意，将来的扩展必须符合前面的描述。以下示例描述了当前由记录类型“cdni_http_request_v1”定义的CDNILOGFILE的结构
DIRLINE = "#" directive CRLF
DIRLINE=“#”指令CRLF
DIRGROUP = 1*DIRLINE
DIRGROUP = 1*DIRLINE
RECLINE = <any subset of record values that match what is expected
according to the fields directive within the immediately preceding
DIRGROUP>
RECLINE = <any subset of record values that match what is expected
according to the fields directive within the immediately preceding
DIRGROUP>
RECGROUP = *RECLINE
RECGROUP = *RECLINE
CDNILOGFILE = 1*(DIRGROUP RECGROUP)
CDNILOGFILE = 1*(DIRGROUP RECGROUP)
A CDNI Logging directive line contains the directive name followed by ":" HTAB and the directive value.
CDNI日志记录指令行包含指令名称，后跟“：”HTAB和指令值。
Directive names MUST be of the format NAMEFORMAT. All directive names MUST be registered in the "CDNI Logging Directives Names" registry. Directive names are case-insensitive as per the basic ABNF ([RFC5234]). Unknown directives MUST be ignored. Directive values can have various formats. All possible directive values for the record-type "cdni_http_request_v1" are further detailed in this section.
指令名称的格式必须为NAMEFORMAT。所有指令名称必须在“CDNI日志记录指令名称”注册表中注册。根据基本ABNF（[RFC5234]），指令名称不区分大小写。必须忽略未知指令。指令值可以有多种格式。记录类型“cdni_http_request_v1”的所有可能指令值在本节中有进一步详细说明。
The following example shows the structure of a directive and enumerates strictly the directive values presently defined in the version "cdni/1.0" of the CDNI Logging File.
以下示例显示了指令的结构，并严格列举了当前在cdni日志文件的“cdni/1.0”版本中定义的指令值。
directive = DIRNAME ":" HTAB DIRVAL
指令=DIRNAME:“HTAB DIRVAL
DIRNAME = NAMEFORMAT
DIRNAME = NAMEFORMAT
FIENAME = <any CDNI Logging field name registered in the CDNI
Logging Field Names registry (Section 6.4) that is valid for the
record type specified in the record-type directive.>
FIENAME = <any CDNI Logging field name registered in the CDNI
Logging Field Names registry (Section 6.4) that is valid for the
record type specified in the record-type directive.>
DIRVAL = NHTABSTRING / QSTRING / host / USER-COMMENT / FIENAME
*(HTAB FIENAME) / 64HEXDIG
DIRVAL = NHTABSTRING / QSTRING / host / USER-COMMENT / FIENAME
*(HTAB FIENAME) / 64HEXDIG
An implementation of the CDNI Logging interface MUST support all of the following directives, listed below by their directive name:
CDNI日志记录接口的实现必须支持以下所有指令（按指令名称列出）：
o Version:
o 版本：
* Format: NHTABSTRING
* 格式：NHTABSTRING
* Directive value: Indicates the version of the CDNI Logging File format. The entity transmitting a CDNI Logging File as per the present document MUST set the value to "cdni/1.0". In the future, other versions of the CDNI Logging File might be specified; those would use a value different from "cdni/1.0", which allows the entity receiving the CDNI Logging File to identify the corresponding version. CDNI Logging File versions are case-insensitive as per the basic ABNF ([RFC5234]).
* 指令值：指示CDNI日志文件格式的版本。根据本文件传输CDNI日志文件的实体必须将该值设置为“CDNI/1.0”。将来，可能会指定CDNI日志文件的其他版本；这些将使用不同于“cdni/1.0”的值，该值允许接收cdni日志文件的实体识别相应的版本。根据基本ABNF（[RFC5234]），CDNI日志文件版本不区分大小写。
* Occurrence: There MUST be one and only one instance of this directive per the CDNI Logging File. It MUST be the first line of the CDNI Logging File.
* 事件：每个CDNI日志文件必须有且只有一个此指令的实例。它必须是CDNI日志文件的第一行。
* Example: "version: HTAB cdni/1.0".
* 示例：“版本：HTAB cdni/1.0”。
o UUID:
o UUID：
* Format: NHTABSTRING
* 格式：NHTABSTRING
* Directive value: This a Uniform Resource Name (URN) from the Universally Unique IDentifier (UUID) URN namespace specified in [RFC4122]. The UUID contained in the URN uniquely identifies the CDNI Logging File.
* 指令值：这是来自[RFC4122]中指定的通用唯一标识符（UUID）URN命名空间的统一资源名称（URN）。URN中包含的UUID唯一标识CDNI日志文件。
* Occurrence: There MUST be one and only one instance of this directive per the CDNI Logging File.
* 事件：每个CDNI日志文件必须有且只有一个此指令的实例。
* Example: "UUID: HTAB NHTABSTRING".
* 示例：“UUID:HTAB-NHTABSTRING”。
o Claimed-origin:
o 声称原产地：
* Format: Host
* 格式：主机
* Directive value: This contains the claimed identification of the entity transmitting the CDNI Logging File (e.g., the host in a dCDN supporting the CDNI Logging interface) or the entity responsible for transmitting the CDNI Logging File (e.g., the dCDN).
* 指令值：包含传输CDNI日志文件的实体（例如，支持CDNI日志接口的dCDN中的主机）或负责传输CDNI日志文件的实体（例如，dCDN）的声明标识。
* Occurrence: There MUST be zero or exactly one instance of this directive per the CDNI Logging File. This directive MAY be included by the dCDN. It MUST NOT be included or modified by the uCDN.
* 事件：每个CDNI日志文件必须有零个或正好一个此指令的实例。dCDN可能包括本指令。uCDN不得包含或修改它。
* Example: "claimed-origin: HTAB host".
* 示例：“声明的来源：HTAB主机”。
o Established-origin:
o 既定来源：
* Format: Host
* 格式：主机
* Directive value: This contains the identification, as established by the entity receiving the CDNI Logging File, of the entity transmitting the CDNI Logging File (e.g., the host in a dCDN supporting the CDNI Logging interface) or the entity responsible for transmitting the CDNI Logging File (e.g., the dCDN).
* 指令值：该值包含接收CDNI日志文件的实体确定的发送CDNI日志文件的实体（例如，支持CDNI日志接口的dCDN中的主机）或负责发送CDNI日志文件的实体（例如，dCDN）的标识。
* Occurrence: There MUST be zero or exactly one instance of this directive per the CDNI Logging File. This directive MAY be added by the uCDN (e.g., before storing the CDNI Logging File). It MUST NOT be included by the dCDN. The mechanisms used by the uCDN to establish and validate the entity responsible for the CDNI Logging File is outside the scope of the present document. We observe that, in particular, this may be achieved through authentication mechanisms that are part of the transport layer of the CDNI Logging File pull mechanism (Section 4.2).
* 事件：每个CDNI日志文件必须有零个或正好一个此指令的实例。此指令可由uCDN添加（例如，在存储CDNI日志文件之前）。dCDN中不得包含该文件。uCDN用于建立和验证负责CDNI日志文件的实体的机制不在本文档的范围内。我们特别注意到，这可以通过身份验证机制实现，身份验证机制是CDNI日志文件拉取机制传输层的一部分（第4.2节）。
* ABNF example: "established-origin: HTAB host".
* ABNF示例：“已建立的原点：HTAB主机”。
o Remark:
o 备注:
* Format: USER-COMMENT
* 格式：用户评论
* Directive value: This contains comment information. Data contained in this field is to be ignored by analysis tools.
* 指令值：包含注释信息。分析工具将忽略此字段中包含的数据。
* Occurrence: There MAY be zero, one, or any number of instances of this directive per the CDNI Logging File.
* 发生：每个CDNI日志文件可能有零个、一个或任意数量的此指令实例。
* Example: "remark: HTAB USER-COMMENT".
* 示例：“备注：HTAB用户评论”。
o Record-type:
o 记录类型：
* Format: NAMEFORMAT
* 格式：NAMEFORMAT
* Directive value: Indicates the type of the CDNI Logging Records that follow this directive, until another record-type directive appears in the CDNI Logging File (or the end of the CDNI Logging File). This can be any CDNI Logging Record type registered in the "CDNI Logging record-types" registry (Section 6.3). For example, this may be "cdni_http_request_v1" as specified in Section 3.4.1. CDNI Logging record-types are case-insensitive as per the basic ABNF ([RFC5234]).
* 指令值：指示遵循此指令的CDNI日志记录的类型，直到另一个记录类型指令出现在CDNI日志文件中（或CDNI日志文件的末尾）。这可以是在“CDNI日志记录类型”注册表中注册的任何CDNI日志记录类型（第6.3节）。例如，这可能是第3.4.1节中规定的“cdni_http_请求_v1”。根据基本ABNF（[RFC5234]），CDNI日志记录类型不区分大小写。
* Occurrence: There MUST be at least one instance of this directive per the CDNI Logging File. The first instance of this directive MUST precede a fields directive and MUST precede all CDNI Logging Records.
* 事件：每个CDNI日志文件必须至少有一个此指令的实例。此指令的第一个实例必须位于fields指令之前，并且必须位于所有CDNI日志记录之前。
* Example: "record-type: HTAB cdni_http_request_v1".
* 示例：“记录类型：HTAB cdni_http_request_v1”。
o Fields:
o 领域：
* Format: FIENAME *(HTAB FIENAME) ; where FIENAME can take any CDNI Logging field name registered in the "CDNI Logging Field Names" registry (Section 6.4) that is valid for the record type specified in the record-type directive.
* 格式：FIENAME*（HTAB FIENAME）；其中，FIENAME可以采用在“CDNI日志记录字段名称”注册表（第6.4节）中注册的任何CDNI日志记录字段名称，该名称对记录类型指令中指定的记录类型有效。
* Directive value: This lists the names of all the fields for which a value is to appear in the CDNI Logging Records that follow the instance of this directive (until another instance of this directive appears in the CDNI Logging File). The names of the fields, as well as their occurrences, MUST comply with the corresponding rules specified in the document referenced in the "CDNI Logging record-types" registry (Section 6.3) for the corresponding CDNI Logging record-type.
* 指令值：列出所有字段的名称，该字段的值将出现在该指令实例之后的CDNI日志记录中（直到该指令的另一个实例出现在CDNI日志文件中）。字段名称及其出现次数必须符合“CDNI日志记录类型”注册表（第6.3节）中引用的文档中针对相应CDNI日志记录类型指定的相应规则。
* Occurrence: There MUST be at least one instance of this directive per record-type directive. The first instance of this directive for a given record-type MUST appear before any CDNI Logging Record for this record-type. One situation where more than one instance of the fields directive can appear within a given CDNI Logging File is when there is a change, in the middle of a fairly large logging period, and in the agreement between the uCDN and the dCDN about the set of fields that are to be exchanged. The multiple occurrences allow records with the old set of fields and records with the new set of fields to be carried inside the same Logging File.
* 事件：每个记录类型指令必须至少有一个此指令的实例。给定记录类型的此指令的第一个实例必须出现在此记录类型的任何CDNI日志记录之前。当一个给定的CDNI日志文件中出现一个以上的字段指令实例的情况下，当有变化时，在相当大的日志记录周期的中间，以及在UCDN和DCDN之间关于要交换的字段集合之间的协议。多次出现允许在同一日志文件中携带具有旧字段集的记录和具有新字段集的记录。
* Example: "fields: HTAB FIENAME * (HTAB FIENAME)".
* 示例：“字段：HTAB FIENAME*（HTAB FIENAME）”。
o SHA256-hash:
o SHA256哈希：
* Format: 64HEXDIG
* 格式：64HEXDIG
* Directive value: This directive permits the detection of a corrupted CDNI Logging File. This can be useful, for instance, if a problem occurs on the file system of the dCDN Logging system and leads to a truncation of a Logging File. The valid SHA256-hash value is included in this directive by the entity that transmits the CDNI Logging File. It MUST be computed by applying the SHA-256 ([RFC6234]) cryptographic hash function on the CDNI Logging File, including all the directives and Logging Records, up to the SHA256-hash directive itself, excluding the SHA256-hash directive itself. The SHA256-hash value MUST be represented as a 64-digit hexadecimal number encoded in US-ASCII (representing a 256 bit hash value). The entity receiving the CDNI Logging File also computes, in a similar way, the SHA-256 hash on the received CDNI Logging File and compares this hash to the value of the SHA256-hash directive. If the two values are equal, then the received CDNI Logging File is to be considered non-corrupted. If the two values are different, the received CDNI Logging File is to be considered corrupted. The behavior of the entity that received a corrupted CDNI Logging File is outside the scope of this specification; we note that the entity MAY attempt to pull the same CDNI Logging File from the transmitting entity again. If the entity receiving a non-corrupted CDNI Logging File adds an established-origin directive, it MUST then recompute and update the SHA256-hash directive so that it also protects the added established-origin directive.
* 指令值：此指令允许检测损坏的CDNI日志文件。例如，如果dCDN日志记录系统的文件系统出现问题并导致日志记录文件被截断，这可能非常有用。传输CDNI日志文件的实体在此指令中包含有效的SHA256哈希值。它必须通过在CDNI日志文件上应用SHA-256（[RFC6234]）加密哈希函数来计算，包括所有指令和日志记录，直到SHA256哈希指令本身，不包括SHA256哈希指令本身。SHA256哈希值必须表示为以US-ASCII编码的64位十六进制数（表示256位哈希值）。接收CDNI日志文件的实体还以类似的方式计算接收到的CDNI日志文件上的SHA-256散列，并将该散列与SHA256散列指令的值进行比较。如果两个值相等，则接收到的CDNI日志文件将被视为未损坏。如果两个值不同，则接收到的CDNI日志文件将被视为已损坏。接收损坏的CDNI日志文件的实体的行为超出了本规范的范围；我们注意到，该实体可能会再次尝试从传输实体中提取相同的CDNI日志文件。如果接收未损坏的CDNI日志文件的实体添加了已建立的原始指令，则必须重新计算并更新SHA256哈希指令，以便它也保护已添加的原始指令。
* Occurrence: There MUST be zero or exactly one instance of this directive. There SHOULD be exactly one instance of this directive. One situation where that directive could be omitted is where integrity protection is already provided via another mechanism (for example, if an integrity hash is associated to the CDNI Logging File out of band through the CDNI Logging Feed (Section 4.1) leveraging ATOM extensions such as those proposed in [ATOMPUB]. When present, the SHA256-hash field MUST be the last line of the CDNI Logging File.
* 事件：此指令必须没有或只有一个实例。此指令应该只有一个实例。可以省略该指令的一种情况是，已经通过另一种机制提供了完整性保护（例如，如果完整性散列通过CDNI日志馈送（第4.1节）在带外与CDNI日志文件相关联，利用原子扩展，如[ATOMPUB]中提出的扩展。如果存在，SHA256哈希字段必须是CDNI日志文件的最后一行。
* Example: "SHA256-hash: HTAB 64HEXDIG".
* 示例：“SHA256哈希：HTAB 64HEXDIG”。
A uCDN-side implementation of the CDNI Logging interface MUST ignore a CDNI Logging File that does not comply with the occurrences specified above for each and every directive. For example, a uCDN-
CDNI日志接口的uCDN端实现必须忽略一个CDNI日志文件，该文件不符合上面为每个指令指定的事件。例如，uCDN-
side implementation of the CDNI Logging interface receiving a CDNI Logging File with zero occurrence of the version directive, or with two occurrences of the SHA256-hash, MUST ignore this CDNI Logging File.
CDNI日志记录接口的端实现接收到的CDNI日志记录文件没有出现版本指令，或出现两次SHA256哈希，必须忽略此CDNI日志记录文件。
An entity receiving a CDNI Logging File with a value set to "cdni/1.0" MUST process the CDNI Logging File as per the present document. An entity receiving a CDNI Logging File with a value set to a different value MUST process the CDNI Logging File as per the specification referenced in the "CDNI Logging File version" registry (see Section 6.1) if the implementation supports this specification and MUST ignore the CDNI Logging File otherwise.
接收值设置为“CDNI/1.0”的CDNI日志文件的实体必须按照本文档处理CDNI日志文件。接收CDNI日志文件且其值设置为不同值的实体必须按照“CDNI日志文件版本”注册表中引用的规范（参见第6.1节）处理CDNI日志文件，前提是实施支持此规范，否则必须忽略CDNI日志文件。
A CDNI Logging Record consists of a sequence of CDNI Logging fields relating to that single CDNI Logging Record.
CDNI日志记录由与单个CDNI日志记录相关的一系列CDNI日志字段组成。
CDNI Logging fields MUST be separated by the horizontal tabulation (HTAB) character.
CDNI测井字段必须用水平制表（HTAB）字符分隔。
To facilitate readability, a prefix scheme is used for CDNI Logging field names in a similar way to the one used in W3C Extended Log File Format [ELF]. The semantics of the prefix in the present document are:
为了提高可读性，CDNI日志记录字段名使用了前缀方案，其方式与W3C扩展日志文件格式[ELF]中使用的方式类似。本文件中前缀的语义为：
o "c-" refers to the User Agent that issues the request (corresponds to the "client" of W3C Extended Log Format)
o “c-”指发出请求的用户代理（对应于W3C扩展日志格式的“客户端”）
o "d-" refers to the dCDN (relative to a given CDN acting as an uCDN)
o “d-”指dCDN（相对于作为uCDN的给定CDN）
o "s-" refers to the dCDN Surrogate that serves the request (corresponds to the "server" of the W3C Extended Log Format)
o “s-”指为请求提供服务的dCDN代理（对应于W3C扩展日志格式的“服务器”）
o "u-" refers to the uCDN (relative to a given CDN acting as a dCDN)
o “u-”指uCDN（相对于作为dCDN的给定CDN）
o "cs-" refers to communication from the User Agent towards the dCDN Surrogate
o “cs-”指从用户代理到dCDN代理的通信
o "sc-" refers to communication from the dCDN Surrogate towards the User Agent
o “sc-”指从dCDN代理到用户代理的通信
An implementation of the CDNI Logging interface as per the present specification MUST support the CDNI HTTP Request Logging Record as specified in Section 3.4.1.
根据本规范，CDNI日志接口的实现必须支持第3.4.1节中规定的CDNI HTTP请求日志记录。
A CDNI Logging Record contains the corresponding values for the fields that are enumerated in the last fields directive before the current log line. Note that the order in which the field values appear is dictated by the order of the fields names in the fields directive. There SHOULD be no dependency between the various fields values.
CDNI日志记录包含在当前日志行之前的最后一个字段指令中枚举的字段的相应值。请注意，字段值的显示顺序由fields指令中字段名称的顺序决定。各个字段值之间不应有依赖关系。
This section defines the CDNI Logging Record of record-type "cdni_http_request_v1". It is applicable to content delivery performed by the dCDN using HTTP/1.0 ([RFC1945]), HTTP/1.1 ([RFC7230] [RFC7231] [RFC7232] [RFC7233] [RFC7234] [RFC7235]), or HTTPS ([RFC2818] [RFC7230]). We observe that, in the case of HTTPS delivery, there may be value in logging additional information specific to the operation of HTTP over Transport Layer Security (TLS) and we note that this is outside the scope of the present document and may be addressed in a future document defining another CDNI Logging Record or another version of the HTTP Request Logging Record.
本节定义了记录类型为“CDNI_http_请求_v1”的CDNI日志记录。它适用于dCDN使用HTTP/1.0（[RFC1945]）、HTTP/1.1（[RFC7230][RFC7231][RFC7232][RFC7233][RFC7234][RFC7235]）或HTTPS（[RFC2818][RFC7230]）执行的内容交付。我们注意到，在HTTPS交付的情况下，记录特定于HTTP over Transport Layer Security（TLS）操作的附加信息可能有价值我们注意到，这超出了本文档的范围，可能会在定义另一个CDNI日志记录或HTTP请求日志记录的另一个版本的未来文档中解决。
The "cdni_http_request_v1" record-type is also expected to be applicable to HTTP/2 [RFC7540] since a fundamental design tenet of HTTP/2 is to preserve the HTTP/1.1 semantics. We observe that, in the case of HTTP/2 delivery, there may be value in logging additional information specific to the additional functionality of HTTP/2 (e.g., information related to connection identification, to stream identification, to stream priority, and to flow control). We note that such additional information is outside the scope of the present document and may be addressed in a future document defining another CDNI Logging Record or another version of the HTTP Request Logging Record.
“cdni_http_request_v1”记录类型预计也适用于http/2[RFC7540]，因为http/2的一个基本设计原则是保留http/1.1语义。我们观察到，在HTTP/2交付的情况下，记录特定于HTTP/2附加功能的附加信息（例如，与连接标识、流标识、流优先级和流控制相关的信息）可能有价值。我们注意到，此类附加信息不在本文档的范围内，可能会在定义另一个CDNI日志记录或HTTP请求日志记录的另一个版本的未来文档中解决。
The "cdni_http_request_v1" record-type contains the following CDNI Logging fields, listed by their field name:
“cdni_http_request_v1”记录类型包含以下cdni日志记录字段，按字段名称列出：
o Date:
o 日期：
* Format: DATE
* 格式：日期
* Field value: The date on which the processing of the request completed on the Surrogate.
* 字段值：代理项上完成请求处理的日期。
* Occurrence: There MUST be one and only one instance of this field.
* 事件：此字段必须有且只有一个实例。
o Time:
o 时间：
* Format: TIME
* 格式：时间
* Field value: The time, which MUST be expressed in Coordinated Universal Time (UTC), at which the processing of the request completed on the Surrogate.
* 字段值：必须以协调世界时（UTC）表示的时间，在该时间代理上完成请求处理。
* Occurrence: There MUST be one and only one instance of this field.
* 事件：此字段必须有且只有一个实例。
o Time-taken:
o 所用时间：
* Format: DEC
* 格式：十二月
* Field value: Decimal value of the duration, in seconds, between the start of the processing of the request and the completion of the request processing (e.g., completion of delivery) by the Surrogate.
* 字段值：从开始处理请求到代理完成请求处理（例如，完成交付）之间的持续时间的十进制值，以秒为单位。
* Occurrence: There MUST be one and only one instance of this field.
* 事件：此字段必须有且只有一个实例。
o c-groupid:
o c-groupid:
* Format: NHTABSTRING
* 格式：NHTABSTRING
* Field value: An opaque identifier for an aggregate set of clients, derived from the client IPv4 or IPv6 address in the request received by the Surrogate and/or other network-level identifying information. The c-groupid serves to group clients into aggregates. Example aggregates include civil geolocation information (the country, second-level administrative division, or postal code from which the client is presumed to make the request based on a geolocation database lookup) or network topological information (e.g., the BGP autonomous system (AS) number announcing the prefix containing the address). The c-groupid MAY be structured, e.g., US/TN/MEM/38138. Agreement between the dCDN and the uCDN on a mapping between IPv4 and IPv6 addresses and aggregates is presumed to occur out of band. The aggregation mapping SHOULD be chosen such that each aggregate contains more than one client.
* 字段值：客户端集合的不透明标识符，从代理接收的请求中的客户端IPv4或IPv6地址和/或其他网络级标识信息派生而来。c-groupid用于将客户端分组到聚合中。示例聚合包括民用地理位置信息（国家、二级行政区划或邮政编码，根据地理位置数据库查找，假定客户会从中发出请求）或网络拓扑信息（例如，BGP自治系统（AS）编号，通知包含地址的前缀）。c-groupid可以是结构化的，例如US/TN/MEM/38138。dCDN和uCDN之间就IPv4和IPv6地址和聚合之间的映射达成的协议假定发生在带外。选择聚合映射时，应确保每个聚合包含多个客户端。
+ When the aggregate is chosen so that it contains a single client (e.g., to allow more detailed analytics, or to allow a posteriori analysis of individual delivery, for example, in situations of performance-based penalties), the c-groupid MAY be structured where some elements identify aggregates
+ 当选择聚合以使其包含单个客户机时（例如，允许更详细的分析，或允许对单个交付进行事后分析，例如，在基于性能的处罚情况下），可以在某些元素识别聚合的情况下构造c-groupid
and one element identifies the client, e.g., US/TN/MEM/38138/43a5bdd6-95c4-4d62-be65-7410df0021e2. In the case where the aggregate is chosen so that it contains a single client:
一个元素标识客户，例如US/TN/MEM/38138/43a5bdd6-95c4-4d62-be65-7410df0021e2。在选择聚合以使其包含单个客户端的情况下：
- The element identifying the client SHOULD be algorithmically generated (from the client IPv4 or IPv6 address in the request received by the Surrogate and/or other network-level identifying information) in a way that SHOULD NOT be linkable back to the global addressing context and that SHOULD vary over time (to offer protection against long-term attacks).
- 识别客户机的元素应通过算法生成（从代理接收到的请求中的客户机IPv4或IPv6地址和/或其他网络级识别信息），生成方式不应链接回全局寻址上下文，并且应随时间而变化（针对长期攻击提供保护）。
- It is RECOMMENDED that the mapping varies at least once every 24 hours.
- 建议映射至少每24小时变化一次。
- The algorithmic mapping and variation over time can, in some cases, allow the uCDN (with the knowledge of the algorithm, the time variation, and the associated attributes and keys) to reconstruct the actual client IPv4 or IPv6 address and/or other network-level identifying information when required (e.g., to allow a posteriori analysis of individual delivery, for example, in situations of performance-based penalties). However, these end-user addresses SHOULD only be reconstructed on-demand and the CDNI Logging File SHOULD only be stored with the anonymized c-groupid value.
- 在某些情况下，算法映射和随时间的变化可以允许uCDN（在了解算法、时间变化以及相关属性和密钥的情况下）在需要时重构实际的客户端IPv4或IPv6地址和/或其他网络级标识信息（例如，允许对单个交付进行事后分析，例如，在基于性能的处罚情况下）。但是，这些最终用户地址应仅按需重建，并且CDNI日志文件应仅使用匿名c-groupid值存储。
- Allowing reconstruction of client address information carries with it grave risks to end-user privacy. Since the c-groupid is, in this case, equivalent in identification power to a client IP address, its use may be restricted by regulation or law as personally identifiable information. For this reason, such use is NOT RECOMMENDED.
- 允许重建客户端地址信息会给最终用户的隐私带来严重风险。在这种情况下，由于c-groupid的识别能力等同于客户IP地址，因此其作为个人识别信息的使用可能受到法规或法律的限制。因此，不建议使用这种方法。
- One method for mapping that MAY be supported by implementations relies on a symmetric key that is known only to the uCDN, the dCDN, and the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) key derivation ([RFC5869]), as will be used in TLS 1.3 ([TLS-1.3]). When that method is used:
- 实现可能支持的一种映射方法依赖于仅uCDN、dCDN和基于HMAC的提取和扩展密钥派生函数（HKDF）密钥派生（[RFC5869]）已知的对称密钥，这将在TLS 1.3（[TLS-1.3]）中使用。使用该方法时：
o The uCDN and dCDN need to agree on the "salt" and "input keying material", as described in Section 2.2 of [RFC5869] and the initial "info" parameter (which could be something like the business names of the two organizations in UTF-8, concatenated), as described in
o uCDN和dCDN需要就[RFC5869]第2.2节中所述的“salt”和“输入键控材料”以及初始“info”参数（可能类似于UTF-8中两个组织的企业名称，串联）达成一致，如中所述
Section 2.3 of [RFC5869]. The hash SHOULD be either SHA-2 or SHA-3 [SHA-3], and the encryption algorithm SHOULD be 128-bit AES [AES] in Galois Counter Mode (GCM) [GCM] (AES-GCM) or better. The pseudorandom key (PRK) SHOULD be chosen by both parties contributing alternate random bytes until sufficient length exists. After the initial setup, client-information can be encrypted using the key generated by the "expand" step of Section 2.3 of [RFC5869]. The encrypted value SHOULD be hex encoded or base64 encoded (as specified in Section 4 of [RFC4648]). At the agreed-upon expiration time, a new key SHOULD be generated and used. New keys SHOULD be indicated by prefixing the key with a special character such as an exclamation point. In this way, shorter lifetimes can be used as needed.
[RFC5869]第2.3节。哈希值应为SHA-2或SHA-3[SHA-3]，加密算法应为伽罗瓦计数器模式（GCM）[GCM]（AES-GCM）下的128位AES[AES]或更好。伪随机密钥（PRK）应由提供备用随机字节的双方选择，直到存在足够的长度。初始设置后，可以使用[RFC5869]第2.3节“扩展”步骤生成的密钥对客户机信息进行加密。加密值应为十六进制编码或base64编码（如[RFC4648]第4节所述）。在约定的到期时间，应生成并使用新密钥。应通过在键前加上特殊字符（如感叹号）来指示新键。这样，可以根据需要使用更短的寿命。
* Occurrence: There MUST be one and only one instance of this field.
* 事件：此字段必须有且只有一个实例。
o s-ip:
o s-ip：
* Format: ADDRESS
* 格式：地址
* Field value: The IPv4 or IPv6 address of the Surrogate that served the request (i.e., the "server" address).
* 字段值：为请求提供服务的代理的IPv4或IPv6地址（即“服务器”地址）。
* Occurrence: There MUST be zero or exactly one instance of this field.
* 事件：此字段必须为零或只有一个实例。
o s-hostname:
o s-主机名：
* Format: Host
* 格式：主机
* Field value: The hostname of the Surrogate that served the request (i.e., the "server" hostname).
* 字段值：为请求提供服务的代理的主机名（即“服务器”主机名）。
* Occurrence: There MUST be zero or exactly one instance of this field.
* 事件：此字段必须为零或只有一个实例。
o s-port:
o s端口：
* Format: 1*DIGIT
* 格式：1*位
* Field value: The destination TCP port (i.e., the "server" port) in the request received by the Surrogate.
* 字段值：代理接收的请求中的目标TCP端口（即“服务器”端口）。
* Occurrence: There MUST be zero or exactly one instance of this field.
* 事件：此字段必须为零或只有一个实例。
o cs-method:
o cs方法：
* Format: NHTABSTRING
* 格式：NHTABSTRING
* Field value: This is the method of the request received by the Surrogate. In the case of HTTP delivery, this is the HTTP method in the request.
* 字段值：这是代理接收的请求的方法。在HTTP传递的情况下，这是请求中的HTTP方法。
* Occurrence: There MUST be one and only one instance of this field.
* 事件：此字段必须有且只有一个实例。
o cs-uri:
o cs uri:
* Format: NHTABSTRING
* 格式：NHTABSTRING
* Field value: This is the "effective request URI" of the request received by the Surrogate as specified in [RFC7230]. It complies with the "http" URI scheme or the "https" URI scheme as specified in [RFC7230]. Note that cs-uri can be privacy sensitive. In that case, and where appropriate, u-uri could be used instead of cs-uri.
* 字段值：这是[RFC7230]中指定的代理接收的请求的“有效请求URI”。它符合[RFC7230]中指定的“http”URI方案或“https”URI方案。请注意，cs uri可能对隐私敏感。在这种情况下，在适当的情况下，可以使用u-uri代替cs-uri。
* Occurrence: There MUST be zero or exactly one instance of this field.
* 事件：此字段必须为零或只有一个实例。
o u-uri:
o u-uri：
* Format: NHTABSTRING
* 格式：NHTABSTRING
* Field value: This is a complete URI, derived from the "effective request URI" ([RFC7230]) of the request received by the Surrogate (i.e., the cs-uri) but transformed by the entity generating or transmitting the CDNI Logging Record, in a way that is agreed upon between the two ends of the CDNI Logging interface, so the transformed URI is meaningful to the uCDN. For example, the two ends of the CDNI Logging interface could agree that the u-uri is constructed from the cs-uri by removing the part of the hostname that exposes which individual Surrogate actually performed the delivery. The details of modification performed to generate the u-uri, as well as the mechanism to agree on these modifications between the two sides of the CDNI Logging interface are outside the scope of the present document.
* 字段值：这是一个完整的URI，由代理（即cs URI）接收的请求的“有效请求URI”（[RFC7230]）派生而来，但由生成或传输CDNI日志记录的实体以CDNI日志接口两端商定的方式进行转换，因此，转换后的URI对uCDN是有意义的。例如，CDNI日志接口的两端可以通过删除主机名中暴露哪个代理实际执行传递的部分，同意u-uri是从cs uri构建的。为生成u-uri而执行的修改的细节以及CDNI日志接口双方就这些修改达成一致的机制不在本文档的范围内。
* Occurrence: There MUST be one and only one instance of this field.
* 事件：此字段必须有且只有一个实例。
o Protocol:
o 协议：
* Format: NHTABSTRING
* 格式：NHTABSTRING
* Field value: This is the value of the HTTP-Version field as specified in [RFC7230] of the Request-Line of the request received by the Surrogate (e.g., "HTTP/1.1").
* 字段值：这是代理接收的请求的请求行的[RFC7230]中指定的HTTP版本字段的值（例如，“HTTP/1.1”）。
* Occurrence: There MUST be one and only one instance of this field.
* 事件：此字段必须有且只有一个实例。
o sc-status:
o sc状态：
* Format: 3DIGIT
* 格式：3DIGIT
* Field value: This is the Status-Code in the response from the Surrogate. In the case of HTTP delivery, this is the HTTP Status-Code in the HTTP response.
* 字段值：这是代理响应中的状态代码。在HTTP传递的情况下，这是HTTP响应中的HTTP状态代码。
* Occurrence: There MUST be one and only one instance of this field.
* 事件：此字段必须有且只有一个实例。
o sc-total-bytes:
o sc总字节数：
* Format: 1*DIGIT
* 格式：1*位
* Field value: This is the total number of bytes of the response sent by the Surrogate in response to the request. In the case of HTTP delivery, this includes the bytes of the Status-Line, the bytes of the HTTP headers, and the bytes of the message-body.
* 字段值：这是代理项为响应请求而发送的响应的总字节数。在HTTP传递的情况下，这包括状态行的字节、HTTP头的字节和消息体的字节。
* Occurrence: There MUST be one, and only one, instance of this field.
* 事件：此字段必须有且只有一个实例。
o sc-entity-bytes:
o sc实体字节：
* Format: 1*DIGIT
* 格式：1*位
* Field value: This is the number of bytes of the message-body in the HTTP response sent by the Surrogate in response to the request. This does not include the bytes of the Status-Line or the bytes of the HTTP headers.
* 字段值：这是代理项响应请求而发送的HTTP响应中消息正文的字节数。这不包括状态行的字节或HTTP头的字节。
* Occurrence: There MUST be zero or exactly one instance of this field.
* 事件：此字段必须为零或只有一个实例。
o cs(insert_HTTP_header_name_here):
o cs（在此处插入\u HTTP\u标题\u名称\u）：
* Format: QSTRING
* 格式：QSTRING
* Field value: The value of the HTTP header (identified by the insert_HTTP_header_name_here in the CDNI Logging field name) as it appears in the request processed by the Surrogate, but prepended by a DQUOTE and appended by a DQUOTE. For example, when the CDNI Logging field name (FIENAME) listed in the preceding fields directive is cs(User-Agent), this CDNI Logging field value contains the value of the User-Agent HTTP header as received by the Surrogate in the request it processed, but prepended by a DQUOTE and appended by a DQUOTE. If the HTTP header, as it appeared in the request processed by the Surrogate, contains one or more DQUOTE, each DQUOTE MUST be escaped with percent encoding. For example, if the HTTP header contains My_Header"value", then the field value of the cs(insert_HTTP_header_name_here) is "My_Header%x22value%x22". The entity transmitting the CDNI Logging File MUST ensure that the respective insert_HTTP_header_name_here of the cs(insert_HTTP_header_name_here) listed in the fields directive comply with HTTP specifications. In particular, this field name does not include any HTAB, since this would prevent proper parsing of the fields directive by the entity receiving the CDNI Logging File.
* 字段值：代理项处理的请求中出现的HTTP头的值（由CDNI日志记录字段名中的insert_HTTP_header_name_标识），但前面有一个DQUOTE，后面有一个DQUOTE。例如，当前面的字段指令中列出的CDNI日志记录字段名（FIENAME）为cs（用户代理）时，此CDNI日志记录字段值包含代理在其处理的请求中接收到的用户代理HTTP头的值，但以DQUOTE开头，以DQUOTE追加。如果代理处理的请求中出现的HTTP头包含一个或多个DQUOTE，则每个DQUOTE必须使用百分比编码转义。例如，如果HTTP头包含My_头“value”，则cs的字段值（此处插入_HTTP_头_名称）为“My_头%x22value%x22”。传输CDNI日志文件的实体必须确保fields指令中列出的cs的相应insert_HTTP_header_name_此处（insert_HTTP_header_name_此处）符合HTTP规范。特别是，此字段名不包括任何HTAB，因为这将阻止接收CDNI日志文件的实体正确解析fields指令。
* Occurrence: There MAY be zero, one, or any number of instance of this field.
* 事件：此字段可能有零个、一个或任意数量的实例。
o sc(insert_HTTP_header_name_here):
o sc（在此插入\u HTTP\u标题\u名称）：
* Format: QSTRING
* 格式：QSTRING
* Field value: The value of the HTTP header (identified by the insert_HTTP_header_name_here in the CDNI Logging field name) as it appears in the response issued by the Surrogate to serve the request, but prepended by a DQUOTE and appended by a DQUOTE. If the HTTP header, as it appeared in the request processed by the Surrogate, contains one or more DQUOTEs, each DQUOTE MUST be escaped with percent encoding. For example, if the HTTP header contains My_Header"value", then the field value of the sc(insert_HTTP_header_name_here) is "My_Header%x22value%x22". The entity transmitting the CDNI Logging File MUST ensure that the respective insert_HTTP_header_name_here of the cs(insert_HTTP_header_name_here) listed in the fields directive
* 字段值：HTTP头的值（由CDNI日志记录字段名中此处的insert_HTTP_header_name_标识），它出现在代理发出的响应中，用于服务请求，但前面有一个DQUOTE，后面有一个DQUOTE。如果代理处理的请求中出现的HTTP头包含一个或多个DQUOTE，则必须使用百分比编码对每个DQUOTE进行转义。例如，如果HTTP标头包含My_标头“value”，则sc的字段值（此处插入_HTTP_标头_name_）为“My_标头%x22value%x22”。传输CDNI日志文件的实体必须确保字段指令中列出的cs的相应insert_HTTP_header_name_此处（insert_HTTP_header_name_此处）
comply with HTTP specifications. In particular, this field name does not include any HTAB, since this would prevent proper parsing of the fields directive by the entity receiving the CDNI Logging File.
遵守HTTP规范。特别是，此字段名不包括任何HTAB，因为这将阻止接收CDNI日志文件的实体正确解析fields指令。
* Occurrence: There MAY be zero, one, or any number of instances of this field. For a given insert_HTTP_header_name_here, there MUST be zero or exactly one instance of this field.
* 事件：此字段可能有零个、一个或任意数量的实例。对于此处给定的insert\u HTTP\u header\u name\u，此字段必须为零或只有一个实例。
o s-ccid:
o s-ccid：
* Format: QSTRING
* 格式：QSTRING
* Field value: This contains the value of the Content Collection IDentifier (CCID) associated by the uCDN to the content served by the Surrogate via the CDNI Metadata interface ([CDNI-META]), prepended by a DQUOTE and appended by a DQUOTE. If the CCID conveyed in the CDNI Metadata interface contains one or more DQUOTEs, each DQUOTE MUST be escaped with percent encoding. For example, if the CCID conveyed in the CDNI Metadata interface is My_CCIDD"value", then the field value of the s-ccid is "My_CCID%x22value%X22".
* 字段值：它包含uCDN通过CDNI元数据接口（[CDNI-META]）与代理服务器提供的内容关联的内容集合标识符（CCID）的值，该值前面有一个DQUOTE，后面有一个DQUOTE。如果CDNI元数据接口中传输的CCID包含一个或多个DQUOTE，则必须使用百分比编码对每个DQUOTE进行转义。例如，如果CDNI元数据接口中传递的CCID是My_CCIDD“value”，则s-CCID的字段值是“My_CCID%x22value%X22”。
* Occurrence: There MUST be zero or exactly one instance of this field. For a given insert_HTTP_header_name_here, there MUST be zero or exactly one instance of this field.
* 事件：此字段必须为零或只有一个实例。对于此处给定的insert\u HTTP\u header\u name\u，此字段必须为零或只有一个实例。
o s-sid:
o s-sid：
* Format: QSTRING
* 格式：QSTRING
* Field value: This contains the value of a Session IDentifier (SID) generated by the dCDN for a specific HTTP session, prepended by a DQUOTE and appended by a DQUOTE. In particular, for an HTTP Adaptive Streaming (HAS) session, the SID value is included in the Logging Record for every content chunk delivery of that session in view of facilitating the later correlation of all the per-content chunk log records of a given HAS session. See Section 3.4.2.2. of [RFC6983] for more discussion on the concept of Session IDentifier in the context of HAS. If the SID conveyed contains one or more DQUOTEs, each DQUOTE MUST be escaped with percent-encoding. For example, if the SID is My_SID"value", then the field value of the s-sid is "My_SID%x22value%x22".
* 字段值：该字段包含dCDN为特定HTTP会话生成的会话标识符（SID）的值，该值前面有一个DQUOTE，后面有一个DQUOTE。特别是，对于HTTP自适应流（HAS）会话，SID值包括在该会话的每个内容块交付的日志记录中，以便于以后关联给定HAS会话的所有每个内容块日志记录。见第3.4.2.2节。[RFC6983]中，以获取有关HAS上下文中会话标识符概念的更多讨论。如果SID包含一个或多个DQUOTE，则必须使用百分比编码对每个DQUOTE进行转义。例如，如果SID是My_SID“value”，则s-SID的字段值是“My_SID%x22value%x22”。
* Occurrence: There MUST be zero or exactly one instance of this field.
* 事件：此字段必须为零或只有一个实例。
o s-cached:
o s-cached：
* Format: 1DIGIT
* 格式：1数码
* Field value: This characterizes whether or not the Surrogate served the request using content already stored on its local cache. The allowed values are "0" (for miss) and "1" (for hit). "1" MUST be used when the Surrogate did serve the request exclusively using content already stored on its local cache. "0" MUST be used otherwise (including cases where the Surrogate served the request using some, but not all, content already stored on its local cache). Note that a "0" only means a cache miss in the Surrogate and does not provide any information on whether or not the content was already stored in another device of the dCDN, i.e., whether this was a "dCDN hit" or a "dCDN miss".
* 字段值：这表示代理是否使用已存储在其本地缓存中的内容为请求提供服务。允许的值为“0”（未命中）和“1”（命中）。当代理确实使用已存储在其本地缓存中的内容专门为请求提供服务时，必须使用“1”。“0”必须以其他方式使用（包括代理使用已存储在其本地缓存中的部分（而不是全部）内容来服务请求的情况）。请注意，“0”仅表示代理中的缓存未命中，不提供有关内容是否已存储在dCDN的另一个设备中的任何信息，即，这是“dCDN命中”还是“dCDN未命中”。
* Occurrence: There MUST be zero or exactly one instance of this field.
* 事件：此字段必须为零或只有一个实例。
CDNI Logging field names are case-insensitive as per the basic ABNF ([RFC5234]). The "fields" directive corresponding to an HTTP Request Logging Record MUST contain all the fields names whose occurrence is specified above as "[t]here MUST be one and only one instance of this field." The corresponding fields value MUST be present in every HTTP Request Logging Record.
根据基本ABNF（[RFC5234]），CDNI日志记录字段名称不区分大小写。与HTTP请求日志记录相对应的“fields”指令必须包含所有字段名称，这些字段的出现在上面被指定为“[t]这里必须是并且只有一个此字段的实例”。每个HTTP请求日志记录中必须存在相应的fields值。
The "fields" directive corresponding to an HTTP Request Logging Record MAY list all the fields values whose occurrence is specified above as "[t]here MUST be zero or exactly one instance of this field" or "[t]here MAY be zero, one, or any number of instances of this field." The set of such field names actually listed in the "fields" directive is selected by the CDN generating the CDNI Logging File based on agreements between the interconnected CDNs established through mechanisms outside the scope of this specification (e.g., contractual agreements). When such a field name is not listed in the "fields" directive, the corresponding field value MUST NOT be included in the Logging Record. When such a field name is listed in the "fields" directive, the corresponding field value MUST be included in the Logging Record; if the value for the field is not available, this MUST be conveyed via a dash character ("-").
与HTTP请求日志记录相对应的“fields”指令可以列出所有字段值，这些字段值的出现在上面被指定为“[t]此处必须是此字段的零个或正好是一个实例”或“[t]此处可能是此字段的零个、一个或任意数量的实例”。这组字段名实际列在“fields”中指令由CDN根据通过本规范范围外的机制（例如，合同协议）建立的互连CDN之间的协议生成CDNI日志文件来选择。如果“fields”指令中未列出此类字段名，则日志记录中不得包含相应的字段值。当“fields”指令中列出此类字段名称时，日志记录中必须包含相应的字段值；如果该字段的值不可用，则必须通过短划线字符（“-”）传递。
The fields names listed in the "fields" directive MAY be listed in the order in which they are listed in Section 3.4.1 or MAY be listed in any other order.
“字段”指令中列出的字段名称可以按照第3.4.1节中列出的顺序列出，也可以按照任何其他顺序列出。
Logging some specific fields from HTTP requests and responses can introduce serious security and privacy risks. For example, cookies will often contain (months) long-lived token values that can be used to log into a service as the relevant user. Similar values may be included in other header fields or within URLs or elsewhere in HTTP requests and responses. Centralizing such values in a CDNI Logging File can therefore represent a significant increase in risk both for the user and the web service provider, but also for the CDNs involved. Therefore, implementations ought to attempt to lower the probability of such bad outcomes, e.g., by only allowing a configured set of headers to be added to CDNI Logging Records, or by not supporting wildcard selection of HTTP request/response fields to add. Such mechanisms can reduce the probability that security (or privacy) sensitive values are centralized in CDNI Logging Files. Also, when agreeing on which HTTP request/response fields are to be provided in CDNI Logging Files, the uCDN and dCDN administrators ought to consider these risks. Furthermore, CDNs making use of c-groupid to identify an aggregate of clients rather than individual clients ought to realize that, by logging certain header fields, they may create the possibility to re-identify individual clients. In these cases, heeding the above advice, or not logging header fields at all, is particularly important if the goal is to provide logs that do not identify individual clients.
记录HTTP请求和响应中的某些特定字段可能会带来严重的安全和隐私风险。例如，Cookie通常包含（月）长时间的令牌值，可用于作为相关用户登录到服务。类似的值可以包含在其他头字段中，也可以包含在URL中，或者HTTP请求和响应中的其他位置。因此，将这些值集中在CDNI日志文件中可能会显著增加用户和web服务提供商以及相关CDN的风险。因此，实现应该尝试降低这种不良结果的概率，例如，只允许将一组配置好的头添加到CDNI日志记录中，或者不支持对要添加的HTTP请求/响应字段进行通配符选择。这种机制可以降低安全（或隐私）敏感值集中在CDNI日志文件中的可能性。此外，当同意在CDNI日志文件中提供哪些HTTP请求/响应字段时，UCDN和DCDN管理员应该考虑这些风险。此外，使用c-groupid来标识客户机集合而不是单个客户机的CDN应该意识到，通过记录某些头字段，它们可能会重新标识单个客户机。在这些情况下，如果目标是提供不识别单个客户机的日志，那么注意上述建议，或者根本不记录头字段就显得尤为重要。
A dCDN-side implementation of the CDNI Logging interface MUST implement all the following Logging fields in a CDNI Logging Record of record-type "cdni_http_request_v1" and MUST support the ability to include valid values for each of them:
CDNI日志接口的dCDN端实现必须在记录类型为“CDNI_http_request_v1”的CDNI日志记录中实现以下所有日志字段，并且必须支持为每个字段包含有效值的功能：
o date
o 日期
o time
o 时间
o time-taken
o 耗时
o c-groupid
o c-groupid
o s-ip
o s-ip
o s-hostname
o s主机名
o s-port
o s端口
o cs-method
o cs法
o cs-uri
o cs uri
o u-uri
o u-uri
o protocol
o 协议
o sc-status
o sc状态
o sc-total-bytes
o sc总字节数
o sc-entity-bytes
o sc实体字节
o cs(insert_HTTP_header_name_here)
o cs（在此处插入\u HTTP\u标题\u名称\u）
o sc(insert_HTTP_header_name_here)
o sc（在此处插入\u HTTP\u标题\u名称\u）
o s-cached
o s缓存
A dCDN-side implementation of the CDNI Logging interface MAY support the following Logging fields in a CDNI Logging Record of record-type "cdni_http_request_v1":
CDNI日志接口的dCDN端实现可能支持记录类型为“CDNI_http_request_v1”的CDNI日志记录中的以下日志字段：
o s-ccid
o s-ccid
o s-sid
o s-sid
If a dCDN-side implementation of the CDNI Logging interface supports these fields, it MUST support the ability to include valid values for them.
如果CDNI日志接口的dCDN端实现支持这些字段，那么它必须支持为这些字段包含有效值的功能。
An uCDN-side implementation of the CDNI Logging interface MUST be able to accept CDNI Logging Files with CDNI Logging Records of record-type "cdni_http_request_v1" containing any CDNI Logging Field defined in Section 3.4.1 as long as the CDNI Logging Record and the CDNI Logging File are compliant with the present document.
只要CDNI日志记录和CDNI日志文件符合本文件，CDNI日志记录接口的uCDN端实现必须能够接受记录类型为“CDNI_http_request_v1”的CDNI日志记录文件，其中包含第3.4.1节中定义的任何CDNI日志字段。
In case an uCDN-side implementation of the CDNI Logging interface receives a CDNI Logging File with HTTP Request Logging Records that do not contain field values for exactly the set of field names actually listed in the preceding "fields" directive, the implementation MUST ignore those HTTP Request Logging Records and MUST accept the other HTTP Request Logging Records.
如果CDNI日志接口的uCDN端实现接收到一个CDNI日志文件，该文件包含HTTP请求日志记录，该记录不包含与前面“fields”指令中实际列出的字段名集完全对应的字段值，实现必须忽略这些HTTP请求日志记录，并且必须接受其他HTTP请求日志记录。
To ensure that the Logging File is correct, the text MUST be sanitized before being logged. Null, bare CR, bare LF, and HTAB have to be removed by escaping them through percent encoding to avoid confusion with the Logging Record separators.
为确保日志文件正确，必须在记录之前对文本进行消毒。Null、bare CR、bare LF和HTAB必须通过百分比编码转义来删除，以避免与日志记录分隔符混淆。
The CDNI Logging File contains blocks of directives and blocks of corresponding records. The supported set of directives is defined relative to the CDNI Logging File Format version. The complete set of directives for version "cdni/1.0" are defined in Section 3.3. The directive list is not expected to require much extension, but when it does, the new directive MUST be defined and registered in the "CDNI Logging Directive Names" registry, as described in Figure 9, and a new version MUST be defined and registered in the "CDNI Logging File version" registry, as described in Section 6.2. For example, adding a new CDNI Logging Directive, e.g., "foo", to the set of directives defined for "cdni/1.0" in Section 3.3, would require registering both the new CDNI Logging Directive "foo" and a new CDNI Logging File version, e.g., "CDNI/2.0", which includes all of the existing CDNI Logging Directives of "cdni/1.0" plus "foo".
CDNI日志文件包含指令块和相应记录块。支持的指令集是相对于CDNI日志文件格式版本定义的。第3.3节定义了“cdni/1.0”版的整套指令。指令列表不需要太多扩展，但当它需要扩展时，必须在“CDNI日志记录指令名称”注册表中定义和注册新指令，如图9所示，并且必须在“CDNI日志记录文件版本”注册表中定义和注册新版本，如第6.2节所述。例如，在第3.3节中为“CDNI/1.0”定义的一组指令中添加一个新的CDNI日志指令，例如“foo”，需要同时注册新的CDNI日志指令“foo”和一个新的CDNI日志文件版本，例如“CDNI/2.0”，其中包括所有现有的CDNI日志指令“CDNI/1.0”和“foo”。
It is expected that as new logging requirements arise, the list of fields to log will change and expand. When adding new fields, the new fields MUST be defined and registered in the "CDNI Logging Field Names" registry, as described in Section 6.4, and a new record-type MUST be defined and registered in the "CDNI Logging record-types" registry, as described in Section 6.3. For example, adding a new CDNI Logging Field, e.g., "c-bar", to the set of fields defined for "cdni_http_request_v1" in Section 3.4.1, would require registering both the new CDNI Logging Field "c-bar" and a new CDNI record-type, e.g., "cdni_http_request_v2", which includes all of the existing CDNI Logging Fields of "cdni_http_request_v1" plus "c-bar".
预计随着新的日志记录要求的出现，要记录的字段列表将发生变化并扩展。添加新字段时，必须在“CDNI日志记录字段名称”注册表中定义和注册新字段，如第6.4节所述，并且必须在“CDNI日志记录类型”注册表中定义和注册新记录类型，如第6.3节所述。例如，在第3.4.1节中为“CDNI_http_请求_v1”定义的字段集合中添加一个新的CDNI日志字段，例如“c-bar”，需要注册新的CDNI日志字段“c-bar”和一个新的CDNI记录类型，例如“CDNI_http_请求_v2”，其中包括“CDNI_http_请求_v1”的所有现有CDNI日志字段“c-bar”。
Let us consider the upstream CDN and the downstream CDN-labeled uCDN and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN for uCDN and performs content delivery on behalf of uCDN, dCDN-1 will include the CDNI Logging Records corresponding to the content deliveries performed on behalf of uCDN in the CDNI Logging Files for uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN is shown below in Figure 4.
让我们考虑上游CDN和下游CDN标记的UCDN和DCDN-1，如图1所示。当dCDN-1充当uCDN的下游CDN并代表uCDN执行内容交付时，dCDN-1将在uCDN的CDNI日志文件中包含与代表uCDN执行的内容交付相对应的CDNI日志记录。dCDN-1与uCDN通信的示例CDNI日志文件如图4所示。
#version:<HTAB>cdni/1.0<CRLF>
#version:<HTAB>cdni/1.0<CRLF>
#UUID:<HTAB>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6<CRLF>
#UUID:<HTAB>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6<CRLF>
#claimed-origin:<HTAB>cdni-logging-entity.dcdn-1.example.com<CRLF>
#claimed-origin:<HTAB>cdni-logging-entity.dcdn-1.example.com<CRLF>
#record-type:<HTAB>cdni_http_request_v1<CRLF>
#record-type:<HTAB>cdni_http_request_v1<CRLF>
#fields:<HTAB>date<HTAB>time<HTAB>time-taken<HTAB>c-groupid<HTAB>
cs-method<HTAB>u-uri<HTAB>protocol<HTAB>
sc-status<HTAB>sc-total-bytes<HTAB>cs(User-Agent)<HTAB>
cs(Referer)<HTAB>s-cached<CRLF>
#fields:<HTAB>date<HTAB>time<HTAB>time-taken<HTAB>c-groupid<HTAB>
cs-method<HTAB>u-uri<HTAB>protocol<HTAB>
sc-status<HTAB>sc-total-bytes<HTAB>cs(User-Agent)<HTAB>
cs(Referer)<HTAB>s-cached<CRLF>
2013-05-17<HTAB>00:38:06.825<HTAB>9.058<HTAB>US/TN/MEM/38138<HTAB>
GET<HTAB>
http://cdni-ucdn.dcdn-1.example.com/video/movie100.mp4<HTAB>
HTTP/1.1<HTAB>200<HTAB>6729891<HTAB>"Mozilla/5.0
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari/533.4"<HTAB>
"host1.example.com"<HTAB>1<CRLF>
2013-05-17<HTAB>00:38:06.825<HTAB>9.058<HTAB>US/TN/MEM/38138<HTAB>
GET<HTAB>
http://cdni-ucdn.dcdn-1.example.com/video/movie100.mp4<HTAB>
HTTP/1.1<HTAB>200<HTAB>6729891<HTAB>"Mozilla/5.0
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari/533.4"<HTAB>
"host1.example.com"<HTAB>1<CRLF>
2013-05-17<HTAB>00:39:09.145<HTAB>15.32<HTAB>FR/PACA/NCE/06100<HTAB>
GET<HTAB>
http://cdni-ucdn.dcdn-1.example.com/video/movie118.mp4<HTAB>
HTTP/1.1<HTAB>200<HTAB>15799210<HTAB>"Mozilla/5.0
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari/533.4"<HTAB>
"host1.example.com"<HTAB>1<CRLF>
2013-05-17<HTAB>00:39:09.145<HTAB>15.32<HTAB>FR/PACA/NCE/06100<HTAB>
GET<HTAB>
http://cdni-ucdn.dcdn-1.example.com/video/movie118.mp4<HTAB>
HTTP/1.1<HTAB>200<HTAB>15799210<HTAB>"Mozilla/5.0
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari/533.4"<HTAB>
"host1.example.com"<HTAB>1<CRLF>
2013-05-17<HTAB>00:42:53.437<HTAB>52.879<HTAB>US/TN/MEM/38138<HTAB>
GET<HTAB>
http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4<HTAB>
HTTP/1.0<HTAB>200<HTAB>97234724<HTAB>"Mozilla/5.0
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari/533.4"<HTAB>
"host5.example.com"<HTAB>0<CRLF>
2013-05-17<HTAB>00:42:53.437<HTAB>52.879<HTAB>US/TN/MEM/38138<HTAB>
GET<HTAB>
http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4<HTAB>
HTTP/1.0<HTAB>200<HTAB>97234724<HTAB>"Mozilla/5.0
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari/533.4"<HTAB>
"host5.example.com"<HTAB>0<CRLF>
#SHA256-hash:<HTAB> 64-hexadecimal-digit hash value <CRLF>
#SHA256-hash:<HTAB> 64-hexadecimal-digit hash value <CRLF>
Figure 4: CDNI Logging File Example
图4:CDNI日志文件示例
If uCDN establishes, by some means (e.g., via TLS authentication when pulling the CDNI Logging File), the identity of the entity from which it pulled the CDNI Logging File, uCDN can add an established-origin directive to the CDNI Logging as illustrated below:
如果uCDN通过某种方式（例如，在提取CDNI日志文件时通过TLS身份验证）建立了从中提取CDNI日志文件的实体的标识，则uCDN可以向CDNI日志添加已建立的原始指令，如下所示：
#established-origin:<HTAB>cdni-logging-entity.dcdn-1.example.com<CRLF>
#established-origin:<HTAB>cdni-logging-entity.dcdn-1.example.com<CRLF>
As illustrated in Figure 2, uCDN will then ingest the corresponding CDNI Logging Records into its Collection process, alongside the Logging Records generated locally by the uCDN itself. This allows uCDN to aggregate Logging Records for deliveries performed by itself (through Records generated locally) as well as for deliveries performed by its downstream CDN(s). This aggregate information can then be used (after Filtering and Rectification, as illustrated in Figure 2) by log-consuming applications that take into account deliveries performed by uCDN as well as by all of its downstream CDNs.
如图2所示，uCDN随后将相应的CDNI日志记录与uCDN本身本地生成的日志记录一起摄取到其收集过程中。这允许uCDN为自己执行的交付（通过本地生成的记录）以及下游CDN执行的交付聚合日志记录。然后，日志消费应用程序可以使用这些聚合信息（在过滤和纠正之后，如图2所示），这些应用程序考虑了uCDN及其所有下游CDN执行的交付。
We observe that the time between
我们观察到
1. when a delivery is completed in dCDN and
1. 在dCDN中完成交付时，以及
2. when the corresponding Logging Record is ingested by the Collection process in uCDN
2. 当uCDN中的收集进程接收到相应的日志记录时
depends on a number of parameters such as the Logging Period agreed to by uCDN and dCDN, how much time uCDN waits before pulling the CDNI Logging File once it is advertised in the CDNI Logging Feed, and the time to complete the pull of the CDNI Logging File. Therefore, if we consider the set of Logging Records aggregated by the Collection process in uCDN in a given time interval, there could be a permanent significant timing difference between the CDNI Logging Records received from the dCDN and the Logging Records generated locally. For example, in a given time interval, the Collection process in uCDN may be aggregating Logging Records generated locally by uCDN for deliveries performed in the last hour and CDNI Logging Records generated in the dCDN for deliveries in the hour before last.
取决于多个参数，如uCDN和dCDN约定的日志记录周期、uCDN在CDNI日志记录提要中播发CDNI日志文件后在提取该文件之前等待的时间，以及完成提取CDNI日志文件的时间。因此，如果我们考虑在给定时间间隔中由UCDN收集的集合所记录的日志记录集合，则可以从DCDN接收的CDNI日志记录和本地生成的日志记录之间存在永久的显著时间差。例如，在给定的时间间隔内，uCDN中的收集过程可能会聚合uCDN为上一小时执行的交付在本地生成的日志记录和dCDN中为上一小时的交付生成的CDNI日志记录。
Say that, for some reason (for example, a Surrogate bug), dCDN-1 could not collect the total number of bytes of the responses sent by the Surrogate (in other words, the value for sc-total-bytes is not available). Then the corresponding CDNI Logging Records would contain a dash character ("-") in lieu of the value for the sc-total-bytes field (as specified in Section 3.4.1). In that case, the CDNI Logging File that would be communicated by dCDN-1 to uCDN is shown below in Figure 5.
假设由于某种原因（例如，代理程式错误），dCDN-1无法收集代理程式所传送回应的总字节数（换句话说，sc total bytes的值不可用）。然后，相应的CDNI日志记录将包含一个短划线字符（“-”），以代替sc total bytes字段的值（如第3.4.1节所述）。在这种情况下，将由dCDN-1传送到uCDN的CDNI日志文件如图5所示。
#version:<HTAB>cdni/1.0<CRLF>
#version:<HTAB>cdni/1.0<CRLF>
#UUID:<HTAB>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6<CRLF>
#UUID:<HTAB>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6<CRLF>
#claimed-origin:<HTAB>cdni-logging-entity.dcdn-1.example.com<CRLF>
#claimed-origin:<HTAB>cdni-logging-entity.dcdn-1.example.com<CRLF>
#record-type:<HTAB>cdni_http_request_v1<CRLF>
#record-type:<HTAB>cdni_http_request_v1<CRLF>
#fields:<HTAB>date<HTAB>time<HTAB>time-taken<HTAB>c-groupid<HTAB>
cs-method<HTAB>u-uri<HTAB>protocol<HTAB>
sc-status<HTAB>sc-total-bytes<HTAB>cs(User-Agent)<HTAB>
cs(Referer)<HTAB>s-cached<CRLF>
#fields:<HTAB>date<HTAB>time<HTAB>time-taken<HTAB>c-groupid<HTAB>
cs-method<HTAB>u-uri<HTAB>protocol<HTAB>
sc-status<HTAB>sc-total-bytes<HTAB>cs(User-Agent)<HTAB>
cs(Referer)<HTAB>s-cached<CRLF>
2013-05-17<HTAB>00:38:06.825<HTAB>9.058<HTAB>US/TN/MEM/38138<HTAB>
GET<HTAB>
http://cdni-ucdn.dcdn-1.example.com/video/movie100.mp4<HTAB>
HTTP/1.1<HTAB>200<HTAB>-<HTAB>"Mozilla/5.0
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari/533.4"<HTAB>
"host1.example.com"<HTAB>1<CRLF>
2013-05-17<HTAB>00:38:06.825<HTAB>9.058<HTAB>US/TN/MEM/38138<HTAB>
GET<HTAB>
http://cdni-ucdn.dcdn-1.example.com/video/movie100.mp4<HTAB>
HTTP/1.1<HTAB>200<HTAB>-<HTAB>"Mozilla/5.0
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari/533.4"<HTAB>
"host1.example.com"<HTAB>1<CRLF>
2013-05-17<HTAB>00:39:09.145<HTAB>15.32<HTAB>FR/PACA/NCE/06100<HTAB>
GET<HTAB>
http://cdni-ucdn.dcdn-1.example.com/video/movie118.mp4<HTAB>
HTTP/1.1<HTAB>200<HTAB>-<HTAB>"Mozilla/5.0
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari/533.4"<HTAB>
"host1.example.com"<HTAB>1<CRLF>
2013-05-17<HTAB>00:39:09.145<HTAB>15.32<HTAB>FR/PACA/NCE/06100<HTAB>
GET<HTAB>
http://cdni-ucdn.dcdn-1.example.com/video/movie118.mp4<HTAB>
HTTP/1.1<HTAB>200<HTAB>-<HTAB>"Mozilla/5.0
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari/533.4"<HTAB>
"host1.example.com"<HTAB>1<CRLF>
2013-05-17<HTAB>00:42:53.437<HTAB>52.879<HTAB>US/TN/MEM/38138<HTAB>
GET<HTAB>
http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4<HTAB>
HTTP/1.0<HTAB>200<HTAB>-<HTAB>"Mozilla/5.0
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari/533.4"<HTAB>
"host5.example.com"<HTAB>0<CRLF>
2013-05-17<HTAB>00:42:53.437<HTAB>52.879<HTAB>US/TN/MEM/38138<HTAB>
GET<HTAB>
http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4<HTAB>
HTTP/1.0<HTAB>200<HTAB>-<HTAB>"Mozilla/5.0
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari/533.4"<HTAB>
"host5.example.com"<HTAB>0<CRLF>
#SHA256-hash:<HTAB> 64-hexadecimal-digit hash value <CRLF>
#SHA256-hash:<HTAB> 64-hexadecimal-digit hash value <CRLF>
Figure 5: CDNI Logging File Example with a Missing Field Value
图5：缺少字段值的CDNI日志文件示例
Let us consider the cascaded CDN scenario of uCDN, dCDN-2, and dCDN-3 as depicted in Figure 1. After completion of a delivery by dCDN-3 on behalf of dCDN-2, dCDN-3 will include a corresponding Logging Record in a CDNI Logging File that will be pulled by dCDN-2 and that is illustrated below in Figure 6. In practice, a CDNI Logging File is likely to contain a very high number of CDNI Logging Records. However, for readability, the example in Figure 6 contains a single CDNI Logging Record.
让我们考虑UCDN、DCDN-2和DCDN-3的级联CDN场景，如图1所示。dCDN-3代表dCDN-2完成交付后，dCDN-3将在CDNI日志文件中包含相应的日志记录，该记录将由dCDN-2提取，如下图6所示。实际上，CDNI日志文件可能包含非常多的CDNI日志记录。然而，为了可读性，图6中的示例包含一条CDNI日志记录。
#version:<HTAB>cdni/1.0<CRLF>
#version:<HTAB>cdni/1.0<CRLF>
#UUID:<HTAB>urn:uuid:65718ef-0123-9876-adce4321bcde<CRLF>
#UUID:<HTAB>urn:uuid:65718ef-0123-9876-adce4321bcde<CRLF>
#claimed-origin:<HTAB>cdni-logging-entity.dcdn-3.example.com<CRLF>
#claimed-origin:<HTAB>cdni-logging-entity.dcdn-3.example.com<CRLF>
#record-type:<HTAB>cdni_http_request_v1<CRLF>
#record-type:<HTAB>cdni_http_request_v1<CRLF>
#fields:<HTAB>date<HTAB>time<HTAB>time-taken<HTAB>c-groupid<HTAB>
cs-method<HTAB>u-uri<HTAB>protocol<HTAB>
sc-status<HTAB>sc-total-bytes<HTAB>cs(User-Agent)<HTAB>
cs(Referer)<HTAB>s-cached<CRLF>
#fields:<HTAB>date<HTAB>time<HTAB>time-taken<HTAB>c-groupid<HTAB>
cs-method<HTAB>u-uri<HTAB>protocol<HTAB>
sc-status<HTAB>sc-total-bytes<HTAB>cs(User-Agent)<HTAB>
cs(Referer)<HTAB>s-cached<CRLF>
2013-05-17<HTAB>00:39:09.119<HTAB>14.07<HTAB>US/CA/SFO/94114<HTAB>
GET<HTAB>
http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4<HTAB>
HTTP/1.1<HTAB>200<HTAB>15799210<HTAB>"Mozilla/5.0
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari /533.4"<HTAB>
"host1.example.com"<HTAB>1<CRLF>
2013-05-17<HTAB>00:39:09.119<HTAB>14.07<HTAB>US/CA/SFO/94114<HTAB>
GET<HTAB>
http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4<HTAB>
HTTP/1.1<HTAB>200<HTAB>15799210<HTAB>"Mozilla/5.0
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari /533.4"<HTAB>
"host1.example.com"<HTAB>1<CRLF>
#SHA256-hash:<HTAB> 64-hexadecimal-digit hash value <CRLF>
#SHA256-hash:<HTAB> 64-hexadecimal-digit hash value <CRLF>
Figure 6: Cascaded CDNI Logging File Example (dCDN-3 to dCDN-2)
图6：级联CDNI日志文件示例（dCDN-3到dCDN-2）
If dCDN-2 establishes, by some means (e.g., via TLS authentication when pulling the CDNI Logging File), the identity of the entity from which it pulled the CDNI Logging File, dCDN-2 can add an established-origin directive to the CDNI Logging as illustrated below:
如果dCDN-2通过某种方式（例如，在提取CDNI日志文件时通过TLS身份验证）建立了从中提取CDNI日志文件的实体的标识，则dCDN-2可以向CDNI日志添加已建立的原始指令，如下所示：
#established-origin:<HTAB>cdni-logging-entity.dcdn-3.example.com<CRLF>
#established-origin:<HTAB>cdni-logging-entity.dcdn-3.example.com<CRLF>
dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) will then ingest the CDNI Logging Record for the considered dCDN-3 delivery into its Collection process (as illustrated in Figure 2). This Logging Record may be aggregated with Logging Records generated locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say,
然后，dCDN-2（从dCDN-3的角度来看，其行为类似于上游CDN）将所考虑的dCDN-3交付的CDNI日志记录摄取到其收集过程中（如图2所示）。此日志记录可与dCDN-2本地生成的日志记录聚合，用于dCDN-2自身执行的交付。说
for illustration, that the content delivery performed by dCDN-3 on behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and say that another content delivery has just been redirected by uCDN to dCDN-2 and that dCDN-2 elected to perform the corresponding delivery itself. Then, after Filtering and Rectification (as illustrated in Figure 2), dCDN-2 will include the two Logging Records corresponding respectively to the delivery performed by dCDN-3 and the delivery performed by dCDN-2, in the next CDNI Logging File that will be communicated to uCDN. An example of such a CDNI Logging File is illustrated below in Figure 7.
为了进行说明，dCDN-3代表dCDN-2执行的内容传递实际上已被uCDN重定向到dCDN-2，并表示uCDN刚刚将另一个内容传递重定向到dCDN-2，dCDN-2选择自己执行相应的传递。然后，在过滤和校正（如图2所示）之后，dCDN-2将在下一个CDNI日志文件中包括分别对应于dCDN-3执行的交付和dCDN-2执行的交付的两个日志记录，该文件将被传送到uCDN。下面的图7展示了这样一个CDNI日志文件的示例。
#version:<HTAB>cdni/1.0<CRLF>
#version:<HTAB>cdni/1.0<CRLF>
#UUID:<HTAB>urn:uuid:1234567-8fedc-abab-0987654321ff<CRLF>
#UUID:<HTAB>urn:uuid:1234567-8fedc-abab-0987654321ff<CRLF>
#claimed-origin:<HTAB>cdni-logging-entity.dcdn-2.example.com<CRLF>
#claimed-origin:<HTAB>cdni-logging-entity.dcdn-2.example.com<CRLF>
#record-type:<HTAB>cdni_http_request_v1<CRLF>
#record-type:<HTAB>cdni_http_request_v1<CRLF>
#fields:<HTAB>date<HTAB>time<HTAB>time-taken<HTAB>c-groupid<HTAB>
cs-method<HTAB>u-uri<HTAB>protocol<HTAB>
sc-status<HTAB>sc-total-bytes<HTAB>cs(User-Agent)<HTAB>
cs(Referer)<HTAB>s-cached<CRLF>
#fields:<HTAB>date<HTAB>time<HTAB>time-taken<HTAB>c-groupid<HTAB>
cs-method<HTAB>u-uri<HTAB>protocol<HTAB>
sc-status<HTAB>sc-total-bytes<HTAB>cs(User-Agent)<HTAB>
cs(Referer)<HTAB>s-cached<CRLF>
2013-05-17<HTAB>00:39:09.119<HTAB>14.07<HTAB>US/CA/SFO/94114<HTAB>
GET<HTAB>
http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4<HTAB>
HTTP/1.1<HTAB>200<HTAB>15799210<HTAB>"Mozilla/5.0
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari /533.4"<HTAB>
"host1.example.com"<HTAB>1<CRLF>
2013-05-17<HTAB>00:39:09.119<HTAB>14.07<HTAB>US/CA/SFO/94114<HTAB>
GET<HTAB>
http://cdni-ucdn.dcdn-2.example.com/video/movie118.mp4<HTAB>
HTTP/1.1<HTAB>200<HTAB>15799210<HTAB>"Mozilla/5.0
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari /533.4"<HTAB>
"host1.example.com"<HTAB>1<CRLF>
2013-05-17<HTAB>01:42:53.437<HTAB>52.879<HTAB>FR/IDF/PAR/75001<HTAB>
GET<HTAB>
http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4<HTAB>
HTTP/1.0<HTAB>200<HTAB>97234724<HTAB>"Mozilla/5.0
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari /533.4"<HTAB>
"host5.example.com"<HTAB>0<CRLF>
2013-05-17<HTAB>01:42:53.437<HTAB>52.879<HTAB>FR/IDF/PAR/75001<HTAB>
GET<HTAB>
http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4<HTAB>
HTTP/1.0<HTAB>200<HTAB>97234724<HTAB>"Mozilla/5.0
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari /533.4"<HTAB>
"host5.example.com"<HTAB>0<CRLF>
#SHA256-hash:<HTAB> 64-hexadecimal-digit hash value <CRLF>
#SHA256-hash:<HTAB> 64-hexadecimal-digit hash value <CRLF>
Figure 7: Cascaded CDNI Logging File Example (dCDN-2 to uCDN)
图7：级联CDNI日志文件示例（dCDN-2到uCDN）
If uCDN establishes, by some means (e.g., via TLS authentication when pulling the CDNI Logging File), the identity of the entity from which it pulled the CDNI Logging File, uCDN can add to the CDNI Logging an established-origin directive as illustrated below:
如果uCDN通过某种方式（例如，在提取CDNI日志文件时通过TLS身份验证）建立了从中提取CDNI日志文件的实体的标识，则uCDN可以向CDNI日志添加一个已建立的原始指令，如下所示：
#established-origin:<HTAB>cdni-logging-entity.dcdn-2.example.com<CRLF>
#established-origin:<HTAB>cdni-logging-entity.dcdn-2.example.com<CRLF>
In the example of Figure 7, we observe that:
在图7的示例中，我们观察到：
o The first Logging Record corresponds to the Logging Record communicated earlier to dCDN-2 by dCDN-3, which corresponds to a delivery redirected by uCDN to dCDN-2 and then redirected by dCDN-2 to dCDN-3. The fields values in this Logging Record are copied from the corresponding CDNI Logging Record communicated to dCDN2 by dCDN-3, with the exception of the u-uri that now reflects the URI convention between uCDN and dCDN-2 and that presents the delivery to uCDN as if it was performed by dCDN-2 itself. This reflects the fact that dCDN-2 had taken full responsibility of the corresponding delivery (even if in this case, dCDN-2 elected to redirect the delivery to dCDN-3 so it is actually performed by dCDN-3 on behalf of dCDN-2).
o 第一条日志记录对应于先前由dCDN-3传递给dCDN-2的日志记录，它对应于由uCDN重定向到dCDN-2，然后由dCDN-2重定向到dCDN-3的传递。此日志记录中的字段值是从dCDN-3传递给dCDN2的相应CDNI日志记录复制而来的，但u-uri除外，u-uri现在反映了uCDN和dCDN-2之间的uri约定，并将传递给uCDN的内容表示为好像是由dCDN-2本身执行的。这反映了dCDN-2对相应的交付承担全部责任的事实（即使在这种情况下，dCDN-2选择将交付重定向到dCDN-3，因此实际上由dCDN-3代表dCDN-2执行）。
o The second Logging Record corresponds to a delivery redirected by uCDN to dCDN-2 and performed by dCDN-2 itself. The time of the delivery in this Logging Record may be significantly more recent than the first Logging Record since it was generated locally while the first Logging Record was generated by dCDN-3 and had to be advertised, and then pulled and then ingested into the dCDN-2 Collection process, before being aggregated with the second Logging Record.
o 第二条日志记录对应于uCDN重定向到dCDN-2并由dCDN-2本身执行的传递。此日志记录中的传递时间可能比第一条日志记录要晚得多，因为它是在本地生成的，而第一条日志记录是由dCDN-3生成的，必须进行播发，然后将其拉入dCDN-2收集过程，然后再与第二条日志记录聚合。
This section specifies a protocol for the exchange of CDNI Logging Files as specified in Section 3 after the CDNI Logging File is fully collected by the dCDN.
本节规定了在dCDN完全收集CDNI日志文件后，按照第3节的规定交换CDNI日志文件的协议。
This protocol comprises:
本议定书包括：
o a CDNI Logging feed, allowing the dCDN to notify the uCDN about the CDNI Logging Files that can be retrieved by that uCDN from the dCDN, as well as all the information necessary for retrieving each of these CDNI Logging Files. The CDNI Logging feed is specified in Section 4.1.
o CDNI日志馈送，允许dCDN向uCDN通知该uCDN可从dCDN检索的CDNI日志文件，以及检索每个CDNI日志文件所需的所有信息。第4.1节规定了CDNI测井馈送。
o a CDNI Logging File pull mechanism, allowing the uCDN to obtain from the dCDN a given CDNI Logging File at the uCDN's convenience. The CDNI Logging File pull mechanism is specified in Section 4.2.
o CDNI日志文件拉取机制，允许uCDN方便地从dCDN获取给定的CDNI日志文件。第4.2节规定了CDNI日志文件拉取机制。
An implementation of the CDNI Logging interface on the dCDN side (the entity generating the CDNI Logging File) MUST support the server side of the CDNI Logging feed (as specified in Section 4.1) and the server side of the CDNI Logging pull mechanism (as specified in Section 4.2).
dCDN端（生成CDNI日志文件的实体）的CDNI日志接口实现必须支持CDNI日志提要的服务器端（如第4.1节所述）和CDNI日志拉机制的服务器端（如第4.2节所述）。
An implementation of the CDNI Logging interface on the uCDN side (the entity consuming the CDNI Logging File) MUST support the client side of the CDNI Logging feed (as specified in Section 4.1) and the client side of the CDNI Logging pull mechanism (as specified in Section 4.2).
uCDN端（使用CDNI日志文件的实体）的CDNI日志接口实现必须支持CDNI日志馈送的客户端（如第4.1节所述）和CDNI日志拉机制的客户端（如第4.2节所述）。
The server-side implementation of the CDNI Logging feed MUST produce an Atom feed [RFC4287]. This feed is used to advertise log files that are available for the client-side to retrieve using the CDNI Logging pull mechanism.
CDNI日志提要的服务器端实现必须生成一个Atom提要[RFC4287]。此提要用于公布可供客户端使用CDNI日志拉机制检索的日志文件。
A CDNI Logging feed MUST be structured as an Archived feed, as defined in [RFC5005], and MUST be formatted in Atom [RFC4287]. This means it consists of a subscription document that is regularly updated as new CDNI Logging Files become available, and information about older CDNI Logging Files is moved into archive documents. Once created, archive documents are never modified.
CDNI日志提要必须按照[RFC5005]中的定义构造为存档提要，并且必须在Atom[RFC4287]中格式化。这意味着它包含一个订阅文档，该文档在新的CDNI日志文件可用时定期更新，有关旧的CDNI日志文件的信息被移动到归档文档中。一旦创建，存档文档就不会被修改。
Each CDNI Logging File listed in an Atom feed MUST be described in an atom:entry container element.
Atom提要中列出的每个CDNI日志文件必须在Atom:entry容器元素中描述。
The atom:entry MUST contain an atom:content element whose "src" attribute is a link to the CDNI Logging File and whose "type" attribute is the MIME Media Type indicating that the entry is a CDNI Logging File. This MIME Media Type is defined as "application/cdni" (See [RFC7736]) with the Payload Type (ptype) parameter set to "logging-file".
atom:entry必须包含一个atom:content元素，其“src”属性是指向CDNI日志文件的链接，其“type”属性是MIME媒体类型，指示该条目是CDNI日志文件。此MIME媒体类型定义为“应用程序/cdni”（请参阅[RFC7736]），有效负载类型（ptype）参数设置为“日志文件”。
For compatibility with some Atom feed readers, the atom:entry MAY also contain an atom:link entry whose "href" attribute is a link to the CDNI Logging File and whose "type" attribute is the MIME Media Type indicating that the entry is a CDNI Logging File using the "application/cdni" MIME Media Type with the Payload Type (ptype) parameter set to "logging-file" (see [RFC7736]).
为了与某些Atom提要阅读器兼容，Atom:条目还可能包含一个Atom:link条目，其“href”属性是指向CDNI日志文件的链接，其“type”属性是MIME媒体类型，表示该条目是使用“application/CDNI”MIME媒体类型的CDNI日志文件，有效负载类型（ptype）参数设置为“日志文件”（参见[RFC7736]）。
The URI used in the atom:id of the atom:entry MUST contain the UUID of the CDNI Logging File.
atom:entry的atom:id中使用的URI必须包含CDNI日志文件的UUID。
The atom:updated in the atom:entry MUST indicate the time at which the CDNI Logging File was last updated.
atom:entry中的atom:updated必须指示上次更新CDNI日志文件的时间。
CDNI Logging Files MUST NOT be modified by the dCDN once published in the CDNI Logging feed.
一旦在CDNI日志提要中发布，dCDN就不能修改CDNI日志文件。
The frequency with which the subscription feed is updated, the period of time covered by each CDNI Logging File or each archive document, and timeliness of publishing of CDNI Logging Files are outside the scope of the present document and are expected to be agreed upon by uCDN and dCDN via other means (e.g., human agreement).
订阅订阅源的更新频率、每个CDNI日志文件或每个归档文件所涵盖的时间段以及发布CDNI日志文件的及时性不在本文件的范围内，预计将由uCDN和dCDN通过其他方式商定（例如，人工协议）。
The server-side implementation MUST be able to set, and SHOULD set, HTTP-cache control headers on the subscription feed to indicate the frequency at which the client-side is to poll for updates.
服务器端实现必须能够并且应该在订阅源上设置HTTP缓存控制头，以指示客户端轮询更新的频率。
The client-side MAY use HTTP-cache control headers (set by the server-side) on the subscription feed to determine the frequency at which to poll for updates. The client-side MAY instead, or in addition, use other information to determine when to poll for updates (e.g., a polling frequency that may have been negotiated between the uCDN and dCDN by mechanisms outside the scope of the present document and that is to override the indications provided in the HTTP-cache control headers).
客户端可以在订阅源上使用HTTP缓存控制头（由服务器端设置）来确定轮询更新的频率。客户端可以改为，或者另外，使用其他信息来确定何时轮询更新（例如，可能已经由本文档范围之外的机制在uCDN和dCDN之间协商的轮询频率，该轮询频率用于覆盖HTTP缓存控制头中提供的指示）。
The potential retention limits (e.g., sliding time window) within which the dCDN is to retain and be ready to serve an archive document is outside the scope of the present document and is expected to be agreed upon by uCDN and dCDN via other means (e.g., human agreement). The server-side implementation MUST retain, and be ready to serve, any archive document within the agreed retention limits. Outside these agreed limits, the server-side implementation MAY indicate its inability to serve (e.g., with HTTP status code 404) an archive document or MAY refuse to serve it (e.g., with HTTP status code 403 or 410).
dCDN保留并准备提供归档文件的潜在保留限制（如滑动时间窗口）不在本文件范围内，预计uCDN和dCDN将通过其他方式（如人工协议）达成一致。服务器端实现必须在约定的保留限制内保留并准备好提供任何存档文档。在这些约定的限制之外，服务器端实现可以指示其无法（例如，使用HTTP状态代码404）提供存档文档，或者可以拒绝提供存档文档（例如，使用HTTP状态代码403或410）。
The server-side implementation MAY present more than one CDNI Logging feed for redundancy. Each CDNI Logging File MAY be published in more than one feed.
服务器端实现可能会提供多个CDNI日志提要以实现冗余。每个CDNI日志文件可以在多个提要中发布。
A client-side implementation MAY support such redundant CDNI Logging feeds. If it supports a redundant CDNI Logging feed, the client-side can use the UUID of the CDNI Logging File, presented in the atom:id element of the Atom feed, to avoid unnecessarily pulling and storing a given CDNI Logging File more than once.
客户端实现可以支持这种冗余的CDNI日志馈送。如果支持冗余CDNI日志馈送，客户端可以使用atom馈送的atom:id元素中显示的CDNI日志文件的UUID，以避免不必要地多次拉取和存储给定的CDNI日志文件。
Figure 8 illustrates an example of the subscription document of a CDNI Logging feed.
图8展示了CDNI日志提要的订阅文档示例。
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title type="text">CDNI Logging Feed</title>
<updated>2013-03-23T14:46:11Z</updated>
<id>urn:uuid:663ae677-40fb-e99a-049d-c5642916b8ce</id>
<link href="https://dcdn.example/logfeeds/ucdn1"
rel="self" type="application/atom+xml" />
<link href="https://dcdn.example/logfeeds/ucdn1"
rel="current" type="application/atom+xml" />
<link href="https://dcdn.example/logfeeds/ucdn1/201303231400"
rel="prev-archive" type="application/atom+xml" />
<generator version="example version 1">CDNI Log Feed
Generator</generator>
<author><name>dcdn.example</name></author>
<entry>
<title type="text">CDNI Logging File for uCDN at
2013-03-23 14:15:00</title>
<id>urn:uuid:12345678-1234-abcd-00aa-01234567abcd</id>
<updated>2013-03-23T14:15:00Z</updated>
<content src="https://dcdn.example/logs/ucdn/
http-requests-20130323141500000000"
type="application/cdni"
ptype="logging-file"/>
<summary>CDNI Logging File for uCDN at
2013-03-23 14:15:00</summary>
</entry>
<entry>
<title type="text">CDNI Logging File for uCDN at
2013-03-23 14:30:00</title>
<id>urn:uuid:87654321-4321-dcba-aa00-dcba7654321</id>
<updated>2013-03-23T14:30:00Z</updated>
<content src="https://dcdn.example/logs/ucdn/
http-requests-20130323143000000000"
type="application/cdni"
ptype="logging-file"/>
<summary>CDNI Logging File for uCDN at
2013-03-23 14:30:00</summary>
</entry>
...
<entry>
...
</entry>
</feed>
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title type="text">CDNI Logging Feed</title>
<updated>2013-03-23T14:46:11Z</updated>
<id>urn:uuid:663ae677-40fb-e99a-049d-c5642916b8ce</id>
<link href="https://dcdn.example/logfeeds/ucdn1"
rel="self" type="application/atom+xml" />
<link href="https://dcdn.example/logfeeds/ucdn1"
rel="current" type="application/atom+xml" />
<link href="https://dcdn.example/logfeeds/ucdn1/201303231400"
rel="prev-archive" type="application/atom+xml" />
<generator version="example version 1">CDNI Log Feed
Generator</generator>
<author><name>dcdn.example</name></author>
<entry>
<title type="text">CDNI Logging File for uCDN at
2013-03-23 14:15:00</title>
<id>urn:uuid:12345678-1234-abcd-00aa-01234567abcd</id>
<updated>2013-03-23T14:15:00Z</updated>
<content src="https://dcdn.example/logs/ucdn/
http-requests-20130323141500000000"
type="application/cdni"
ptype="logging-file"/>
<summary>CDNI Logging File for uCDN at
2013-03-23 14:15:00</summary>
</entry>
<entry>
<title type="text">CDNI Logging File for uCDN at
2013-03-23 14:30:00</title>
<id>urn:uuid:87654321-4321-dcba-aa00-dcba7654321</id>
<updated>2013-03-23T14:30:00Z</updated>
<content src="https://dcdn.example/logs/ucdn/
http-requests-20130323143000000000"
type="application/cdni"
ptype="logging-file"/>
<summary>CDNI Logging File for uCDN at
2013-03-23 14:30:00</summary>
</entry>
...
<entry>
...
</entry>
</feed>
Figure 8: Example Subscription Document of a CDNI Logging Feed
图8:CDNI日志提要的示例订阅文档
A client-side implementation of the CDNI Logging interface MAY pull, at its convenience, a CDNI Logging File that is published by the server-side in the CDNI Logging Feed (in the subscription document or an archive document). To do so, the client-side:
CDNI日志接口的客户端实现可以方便地提取服务器端在CDNI日志提要（订阅文档或归档文档）中发布的CDNI日志文件。为此，客户端：
o MUST implement HTTP/1.1 ([RFC7230] [RFC7231] [RFC7232] [RFC7233] [RFC7234] [RFC7235]), MAY also support other HTTP versions (e.g., HTTP/2 [RFC7540]), and MAY negotiate which HTTP version is actually used. This allows operators and implementers to choose to use later versions of HTTP to take advantage of new features, while still ensuring interoperability with systems that only support HTTP/1.1;
o 必须实现HTTP/1.1（[RFC7230][RFC7231][RFC7232][RFC7233][RFC7234][RFC7235]），还可以支持其他HTTP版本（例如HTTP/2[RFC7540]），并可以协商实际使用的HTTP版本。这允许运营商和实现者选择使用更高版本的HTTP来利用新功能，同时确保与仅支持HTTP/1.1的系统的互操作性；
o MUST use the URI that was associated to the CDNI Logging File (within the "src" attribute of the corresponding atom:content element) in the CDNI Logging Feed;
o 必须在CDNI日志提要中使用与CDNI日志文件关联的URI（在相应atom:content元素的“src”属性内）；
o MUST support exchange of CDNI Logging Files with no content encoding applied to the representation;
o 必须支持CDNI日志文件的交换，且表示中未应用内容编码；
o MUST support exchange of CDNI Logging Files with "gzip" content encoding (as defined in [RFC7230]) applied to the representation.
o 必须支持对表示应用“gzip”内容编码（定义见[RFC7230]）的CDNI日志文件交换。
Note that a client-side implementation of the CDNI Logging interface MAY pull a CDNI Logging File that it has already pulled.
请注意，CDNI日志接口的客户端实现可能会提取它已经提取的CDNI日志文件。
The server-side implementation MUST respond to a valid pull request by a client-side implementation for a CDNI Logging File published by the server-side in the CDNI Logging Feed (in the subscription document or an archive document). The server-side implementation:
服务器端实现必须响应客户端实现对服务器端在CDNI日志提要（订阅文档或归档文档）中发布的CDNI日志文件的有效请求。服务器端实现：
o MUST implement HTTP/1.1 to handle the client-side request and MAY also support other HTTP versions (e.g., HTTP/2);
o 必须实现HTTP/1.1来处理客户端请求，还可以支持其他HTTP版本（例如HTTP/2）；
o MUST include the CDNI Logging File identified by the request URI inside the body of the HTTP response;
o 必须在HTTP响应的主体中包含由请求URI标识的CDNI日志文件；
o MUST support exchange of CDNI Logging Files with no content encoding applied to the representation;
o 必须支持CDNI日志文件的交换，且表示中未应用内容编码；
o MUST support exchange of CDNI Logging Files with "gzip" content encoding (as defined in [RFC7231]) applied to the representation.
o 必须支持对表示应用“gzip”内容编码（定义见[RFC7231]）的CDNI日志文件交换。
Content negotiation approaches defined in [RFC7231] (e.g., using Accept-Encoding request-header field or Content-Encoding entity-header field) MAY be used by the client-side and server-side implementations to establish the content coding to be used for a particular exchange of a CDNI Logging File.
[RFC7231]中定义的内容协商方法（例如，使用接受编码请求报头字段或内容编码实体报头字段）可由客户端和服务器端实现用于建立用于CDNI日志文件的特定交换的内容编码。
Applying compression content encoding (such as "gzip") is expected to mitigate the impact of exchanging the large volumes of logging information expected across CDNs. This is expected to be particularly useful in the presence of HTTP Adaptive Streaming (HAS) that, as per the present version of the document, will result in a separate CDNI Log Record for each HAS segment delivery in the CDNI Logging File.
应用压缩内容编码（如“gzip”）有望减轻跨CDN交换大量日志信息的影响。这对于HTTP自适应流（HAS）的存在尤其有用，根据本文档的当前版本，这将在CDNI日志文件中为每个HAS段交付生成单独的CDNI日志记录。
The potential retention limits (e.g., sliding time window and maximum aggregate file storage quotas) within which the dCDN is to retain and be ready to serve a CDNI Logging File previously advertised in the CDNI Logging Feed is outside the scope of the present document and is expected to be agreed upon by uCDN and dCDN via other means (e.g., human agreement). The server-side implementation MUST retain, and be ready to serve, any CDNI Logging File within the agreed retention limits. Outside these agreed limits, the server-side implementation MAY indicate its inability to serve (e.g., with HTTP status code 404) a CDNI Logging File or MAY refuse to serve it (e.g., with HTTP status code 403 or 410).
dCDN保留并准备提供之前在CDNI日志提要中公布的CDNI日志文件的潜在保留限制（例如，滑动时间窗口和最大聚合文件存储配额）不在本文件的范围内，预计将由uCDN和dCDN通过其他方式商定（例如，人工协议）。服务器端实现必须在约定的保留限制内保留任何CDNI日志文件，并随时准备提供服务。在这些约定限制之外，服务器端实现可能表示无法提供（例如，HTTP状态代码404）CDNI日志文件，或者可能拒绝提供该文件（例如，使用HTTP状态代码403或410）。
We note that, in addition to the CDNI Logging File exchange protocol specified in Section 4, implementations of the CDNI Logging interface may also support other mechanisms to exchange CDNI Logging Files. In particular, such mechanisms might allow the exchange of the CDNI Logging File to start before the file is fully collected. This can allow CDNI Logging Records to be communicated by the dCDN to the uCDN as they are gathered by the dCDN without having to wait until all the CDNI Logging Records of the same logging period are collected in the corresponding CDNI Logging File. This approach is commonly referred to as the "tailing" of the file.
我们注意到，除了第4节中指定的CDNI日志文件交换协议外，CDNI日志接口的实现还可能支持交换CDNI日志文件的其他机制。特别是，这种机制可能允许在完全收集文件之前开始交换CDNI日志文件。这可以允许dCDN将CDNI日志记录在dCDN收集时与uCDN通信，而无需等到相同日志记录周期的所有CDNI日志记录都收集到相应的CDNI日志文件中。这种方法通常被称为文件的“拖尾”。
Such an approach could be used, for example, to exchange logging information with a significantly reduced time-lag (e.g., sub-minute or sub-second) between when the event occurred in the dCDN and when the corresponding CDNI Logging Record is made available to the uCDN. This can satisfy log-consuming applications requiring extremely fresh logging information such as near-real-time content delivery monitoring. Such mechanisms are for further study and are outside the scope of this document.
例如，这种方法可用于在事件发生在dCDN中和相应的CDNI日志记录可供uCDN使用之间以显著缩短的时间间隔（例如，亚分钟或亚秒）交换日志信息。这可以满足需要极新日志信息（如近实时内容交付监控）的日志消耗应用程序。此类机制有待进一步研究，不在本文件范围内。
IANA has created a new "CDNI Logging Directive Names" subregistry under the "Content Delivery Networks Interconnection (CDNI) Parameters" registry.
IANA在“内容交付网络互连（CDNI）参数”注册表下创建了一个新的“CDNI日志记录指令名称”子区。
The initial contents of the "CDNI Logging Directives" registry comprise the names of the directives specified in Section 3.3 of the present document and are as follows:
“CDNI日志指令”注册表的初始内容包括本文件第3.3节中规定的指令名称，如下所示：
+------------------------------+-----------+
| Directive Name | Reference |
+------------------------------+-----------+
| version | RFC 7937 |
| UUID | RFC 7937 |
| claimed-origin | RFC 7937 |
| established-origin | RFC 7937 |
| remark | RFC 7937 |
| record-type | RFC 7937 |
| fields | RFC 7937 |
| SHA256-hash | RFC 7937 |
+------------------------------+-----------+
+------------------------------+-----------+
| Directive Name | Reference |
+------------------------------+-----------+
| version | RFC 7937 |
| UUID | RFC 7937 |
| claimed-origin | RFC 7937 |
| established-origin | RFC 7937 |
| remark | RFC 7937 |
| record-type | RFC 7937 |
| fields | RFC 7937 |
| SHA256-hash | RFC 7937 |
+------------------------------+-----------+
Figure 9: CDNI Logging Directive Names Registry
图9:CDNI日志记录指令名称注册表
Within the registry, names are to be allocated by IANA according to the "Specification Required" policy specified in [RFC5226]. Directive names are to be allocated by IANA with a format of NAMEFORMAT (see Section 3.1). All directive names defined in the Logging File are case-insensitive as per the basic ABNF ([RFC5234]).
在注册中心内，IANA将根据[RFC5226]中规定的“所需规范”政策分配名称。指令名称由IANA以NAMEFORMAT格式分配（见第3.1节）。根据基本ABNF（[RFC5234]），日志文件中定义的所有指令名都不区分大小写。
Each specification that defines a new CDNI Logging directive needs to contain a description for the new directive with the same set of information as provided in Section 3.3 (i.e., format, directive value, and occurrence).
定义新CDNI日志记录指令的每个规范都需要包含新指令的描述，以及第3.3节中提供的相同信息集（即格式、指令值和出现次数）。
IANA has created a new "CDNI Logging File version" subregistry under the "Content Delivery Networks Interconnection (CDNI) Parameters" registry.
IANA在“内容交付网络互连（CDNI）参数”注册表下创建了一个新的“CDNI日志文件版本”子区。
The initial contents of the "CDNI Logging File version" registry comprise the value "cdni/1.0" specified in Section 3.3 of the present document and are as follows:
“CDNI日志文件版本”注册表的初始内容包括本文件第3.3节中规定的值“CDNI/1.0”，如下所示：
+-----------------+-----------+----------------------------------+
| version | Reference | Description |
+-----------------+-----------+----------------------------------+
| cdni/1.0 | RFC 7937 | CDNI Logging File version 1.0 |
| | | as specified in RFC 7937 |
+-----------------+-----------+----------------------------------+
+-----------------+-----------+----------------------------------+
| version | Reference | Description |
+-----------------+-----------+----------------------------------+
| cdni/1.0 | RFC 7937 | CDNI Logging File version 1.0 |
| | | as specified in RFC 7937 |
+-----------------+-----------+----------------------------------+
Figure 10: CDNI Logging File version Registry
图10:CDNI日志文件版本注册表
Within the registry, version values are to be allocated by IANA according to the "Specification Required" policy specified in [RFC5226]. Version values are to be allocated by IANA with a format of NAMEFORMAT (see Section 3.1). All version values defined in the Logging File are case-insensitive as per the basic ABNF ([RFC5234]).
在注册表中，IANA将根据[RFC5226]中规定的“所需规范”策略分配版本值。版本值由IANA以NAMEFORMAT格式分配（见第3.1节）。根据基本ABNF（[RFC5234]），日志文件中定义的所有版本值都不区分大小写。
IANA has created a new "CDNI Logging record-types" subregistry under the "Content Delivery Networks Interconnection (CDNI) Parameters" registry.
IANA在“内容交付网络互连（CDNI）参数”注册表下创建了一个新的“CDNI日志记录类型”子区。
The initial contents of the "CDNI Logging record-types" registry comprise the names of the CDNI Logging record-types specified in Section 3.4 of the present document and are as follows:
“CDNI记录类型”登记册的初始内容包括本文件第3.4节中规定的CDNI记录类型的名称，如下所示：
+----------------------+-----------+---------------------------------+
| record-types | Reference | Description |
+----------------------+-----------+---------------------------------+
| cdni_http_request_v1 | RFC 7937 | CDNI Logging Record version 1 |
| | | for content delivery using HTTP |
+----------------------+-----------+---------------------------------+
+----------------------+-----------+---------------------------------+
| record-types | Reference | Description |
+----------------------+-----------+---------------------------------+
| cdni_http_request_v1 | RFC 7937 | CDNI Logging Record version 1 |
| | | for content delivery using HTTP |
+----------------------+-----------+---------------------------------+
Figure 11: CDNI Logging record-types Registry
图11:CDNI日志记录类型注册表
Within the registry, record-types are to be allocated by IANA according to the "Specification Required" policy specified in [RFC5226]. Record-types are to be allocated by IANA with a format of NAMEFORMAT (see Section 3.1). All record-types defined in the Logging File are case-insensitive as per the basic ABNF ([RFC5234]).
在注册表中，IANA将根据[RFC5226]中规定的“要求规范”策略分配记录类型。IANA将以NAMEFORMAT格式分配记录类型（见第3.1节）。根据基本ABNF（[RFC5234]），日志文件中定义的所有记录类型都不区分大小写。
Each specification that defines a new record-type needs to contain a description for the new record-type with the same set of information as provided in Section 3.4.1. This includes:
定义新记录类型的每个规范都需要包含新记录类型的描述，以及第3.4.1节中提供的相同信息集。这包括：
o A list of all the CDNI Logging fields that can appear in a CDNI Logging Record of the new record-type
o 新记录类型的CDNI日志记录中可能出现的所有CDNI日志记录字段的列表
o For all these fields: a specification of the occurrence for each Field in the new record-type
o 对于所有这些字段：新记录类型中每个字段的引用规范
o For every newly defined Field, i.e., for every Field that results in a registration in the "CDNI Logging Field Names" registry (Section 6.4): a specification of the field name, format, and field value.
o 对于每个新定义的字段，即每个导致在“CDNI记录字段名称”注册表中注册的字段（第6.4节）：字段名称、格式和字段值的规范。
IANA has created a new "CDNI Logging Field Names" subregistry under the "Content Delivery Networks Interconnection (CDNI) Parameters" registry.
IANA在“内容交付网络互连（CDNI）参数”注册表下创建了一个新的“CDNI记录字段名称”子区。
This registry is intended to be shared across the currently defined record-type (i.e., cdni_http_request_v1) as well as potentially other CDNI Logging record-types that may be defined in separate specifications. When a field from this registry is used by another CDNI Logging record-type, it is to be used with the exact semantics and format specified in the document that registered this field and that is identified in the Reference column of the registry. If another CDNI Logging record-type requires a field with semantics that are not strictly identical, or a format that is not strictly identical, then this new field is to be registered in the registry with a different field name. When a field from this registry is used by another CDNI Logging record-type, it can be used with different occurrence rules.
此注册表旨在跨当前定义的记录类型（即cdni_http_请求_v1）以及可能在单独规范中定义的其他cdni日志记录类型共享。当来自此注册表的字段被另一个CDNI日志记录类型使用时，它将与注册此字段的文档中指定的、在注册表的引用列中标识的确切语义和格式一起使用。如果另一个CDNI日志记录类型需要语义不完全相同的字段，或者格式不完全相同，则该新字段将使用不同的字段名在注册表中注册。当另一个CDNI日志记录类型使用此注册表中的字段时，它可以与不同的出现规则一起使用。
The initial contents of the "CDNI Logging Fields Names" registry comprise the names of the CDNI Logging fields specified in Section 3.4 of the present document and are as follows:
“CDNI记录字段名称”注册表的初始内容包括本文件第3.4节中规定的CDNI记录字段名称，如下所示：
+------------------------------------------+-----------+
| Field Name | Reference |
+------------------------------------------+-----------+
| date | RFC 7937 |
| time | RFC 7937 |
| time-taken | RFC 7937 |
| c-groupid | RFC 7937 |
| s-ip | RFC 7937 |
| s-hostname | RFC 7937 |
| s-port | RFC 7937 |
| cs-method | RFC 7937 |
| cs-uri | RFC 7937 |
| u-uri | RFC 7937 |
| protocol | RFC 7937 |
| sc-status | RFC 7937 |
| sc-total-bytes | RFC 7937 |
| sc-entity-bytes | RFC 7937 |
| cs(insert_HTTP_header_name_here) | RFC 7937 |
| sc(insert_HTTP_header_name_here) | RFC 7937 |
| s-ccid | RFC 7937 |
| s-sid | RFC 7937 |
| s-cached | RFC 7937 |
+------------------------------------------+-----------+
+------------------------------------------+-----------+
| Field Name | Reference |
+------------------------------------------+-----------+
| date | RFC 7937 |
| time | RFC 7937 |
| time-taken | RFC 7937 |
| c-groupid | RFC 7937 |
| s-ip | RFC 7937 |
| s-hostname | RFC 7937 |
| s-port | RFC 7937 |
| cs-method | RFC 7937 |
| cs-uri | RFC 7937 |
| u-uri | RFC 7937 |
| protocol | RFC 7937 |
| sc-status | RFC 7937 |
| sc-total-bytes | RFC 7937 |
| sc-entity-bytes | RFC 7937 |
| cs(insert_HTTP_header_name_here) | RFC 7937 |
| sc(insert_HTTP_header_name_here) | RFC 7937 |
| s-ccid | RFC 7937 |
| s-sid | RFC 7937 |
| s-cached | RFC 7937 |
+------------------------------------------+-----------+
Figure 12: CDNI Logging Field Names Registry
图12:CDNI日志记录字段名称注册表
Within the registry, names are to be allocated by IANA according to the "Specification Required" policy specified in [RFC5226]. Field names are to be allocated by IANA with a format of NHTABSTRING (see Section 3.1). All field names defined in the Logging File are case-insensitive as per the basic ABNF ([RFC5234]).
在注册中心内，IANA将根据[RFC5226]中规定的“所需规范”政策分配名称。IANA将以NHTABSTRING格式分配字段名（见第3.1节）。根据基本ABNF（[RFC5234]），日志文件中定义的所有字段名都不区分大小写。
IANA has registered the following new Payload Type in the "CDNI Payload Types" registry for use with the application/cdni MIME media type.
IANA已在“CDNI有效负载类型”注册表中注册了以下新的有效负载类型，以便与应用程序/CDNI MIME媒体类型一起使用。
+----------------------+---------------+
| Payload Type | Specification |
+----------------------+---------------+
| logging-file | RFC 7937] |
+----------------------+---------------+
+----------------------+---------------+
| Payload Type | Specification |
+----------------------+---------------+
| logging-file | RFC 7937] |
+----------------------+---------------+
Figure 13: CDNI Logging Payload Type
图13:CDNI日志记录有效负载类型
The purpose of the logging-file payload type is to distinguish between CDNI Logging Files and other CDNI messages.
日志文件有效负载类型的目的是区分CDNI日志文件和其他CDNI消息。
o Interface: LI
o 接口：李
o Encoding: See Section 3.2, Section 3.3, and Section 3.4
o 编码：参见第3.2节、第3.3节和第3.4节
7.1. Authentication, Authorization, Confidentiality, and Integrity Protection
7.1. 身份验证、授权、机密性和完整性保护
An implementation of the CDNI Logging interface MUST support TLS transport of the CDNI Logging feed (Section 4.1) and of the CDNI Logging File pull (Section 4.2) as per [RFC2818] and [RFC7230].
根据[RFC2818]和[RFC7230]，CDNI日志接口的实现必须支持CDNI日志馈送（第4.1节）和CDNI日志文件拉取（第4.2节）的TLS传输。
TLS MUST be used by the server-side and the client-side of the CDNI Logging feed, as well as the server-side and the client-side of the CDNI Logging File pull mechanism, including authentication of the remote end, unless alternate methods are used for ensuring the security of the information exchanged over the LI interface (such as setting up an IPsec tunnel between the two CDNs or using a physically secured internal network between two CDNs that are owned by the same corporate entity).
TLS必须由CDNI日志馈送的服务器端和客户端以及CDNI日志文件拉取机制的服务器端和客户端使用，包括远程端的身份验证，除非使用替代方法确保通过LI接口交换的信息的安全性（例如，在两个CDN之间设置IPsec隧道，或者在同一公司实体拥有的两个CDN之间使用物理安全的内部网络）。
The use of TLS for transport of the CDNI Logging feed and CDNI Logging File pull allows:
使用TLS传输CDNI日志馈送和CDNI日志文件允许：
o the dCDN and uCDN to authenticate each other using TLS client auth and TLS server auth.
o dCDN和uCDN使用TLS客户端身份验证和TLS服务器身份验证相互验证。
And, once they have mutually authenticated each other, it allows:
并且，一旦他们相互认证，它允许：
o the dCDN and uCDN to authorize each other (to ensure they are transmitting/receiving CDNI Logging File to/from an authorized CDN).
o dCDN和uCDN相互授权（以确保它们正在向授权CDN发送/接收CDNI日志文件）。
o the CDNI Logging information to be transmitted with confidentiality.
o CDNI记录信息应保密传输。
o the integrity of the CDNI Logging information to be protected during the exchange.
o 在交换期间要保护的CDNI日志记录信息的完整性。
When TLS is used, the general TLS usage guidance in [RFC7525] MUST be followed.
使用TLS时，必须遵守[RFC7525]中的一般TLS使用指南。
The SHA256-hash directive inside the CDNI Logging File provides additional integrity protection, this time targeting potential corruption of the CDNI Logging information during the CDNI Logging File generation, storage, or exchange. This mechanism does not itself allow restoration of the corrupted CDNI Logging information, but it allows detection of such corruption, and therefore triggering of appropriate corrective actions (e.g., discard of corrupted information, and attempt to re-obtain the CDNI Logging information). Note that the SHA256-hash does not protect against tampering by a third party, since such a third party could have recomputed and updated the SHA256-hash after tampering. Protection against third-party tampering, when the CDNI Logging File is communicated over the CDN Logging interface, can be achieved as discussed above through the use of TLS.
CDNI日志文件中的SHA256哈希指令提供了额外的完整性保护，这一次是针对CDNI日志文件生成、存储或交换期间CDNI日志信息的潜在损坏。该机制本身不允许恢复损坏的CDNI日志信息，但允许检测此类损坏，从而触发适当的纠正措施（例如，丢弃损坏的信息，并尝试重新获取CDNI日志信息）。请注意，SHA256哈希不能防止第三方篡改，因为这样的第三方可能在篡改后重新计算并更新SHA256哈希。当CDNI日志文件通过CDN日志接口进行通信时，可以通过使用TLS实现如上所述的对第三方篡改的保护。
This document does not define a specific mechanism to protect against Denial-of-Service (DoS) attacks on the Logging interface. However, the CDNI Logging feed and CDNI Logging pull endpoints are typically to be accessed only by a very small number of valid remote endpoints, and therefore can be easily protected against DoS attacks through the usual conventional DoS-protection mechanisms such as firewalling or use of Virtual Private Networks (VPNs).
本文档未定义针对日志接口上的拒绝服务（DoS）攻击进行保护的特定机制。然而，CDNI日志馈送和CDNI日志拉取端点通常只能由极少数有效的远程端点访问，因此可以通过防火墙或使用虚拟专用网络（VPN）等常规DoS保护机制轻松防止DoS攻击。
Protection of dCDN Surrogates against spoofed delivery requests is outside the scope of the CDNI Logging interface.
保护dCDN代理不受伪造传递请求的影响不在CDNI日志接口的范围之内。
CDNs have the opportunity to collect detailed information about the downloads performed by end users. A dCDN is expected to collect such information into CDNI Logging Files, which are then communicated to a uCDN.
CDN有机会收集有关最终用户执行的下载的详细信息。dCDN需要将这些信息收集到CDNI日志文件中，然后将这些文件传送到uCDN。
Having detailed CDNI Logging information known by the dCDN in itself does not represent a particular privacy concern since the dCDN is obviously fully aware of all information logged since it generated the information in the first place.
拥有dCDN本身已知的详细CDNI日志信息并不代表特定的隐私问题，因为dCDN显然完全了解所有记录的信息，因为它首先生成了信息。
Transporting detailed CDNI Logging information over the HTTP-based CDNI Logging interface does not represent a particular privacy concern because it is protected by the usual privacy-protection mechanism (e.g., TLS).
通过基于HTTP的CDNI日志接口传输详细的CDNI日志信息并不代表特定的隐私问题，因为它受到通常的隐私保护机制（例如TLS）的保护。
When HTTP redirection is used between the uCDN and the dCDN, making detailed CDNI Logging information known to the uCDN does not represent a particular privacy concern because the uCDN is already exposed at request redirection time to most of the information that shows up as CDNI Logging information (e.g., end-user IP address, URL, and HTTP headers). When DNS redirection is used between the uCDN and the dCDN, there are cases where there is no privacy concern in making detailed CDNI logging information known to the uCDN; this may be the case, for example, where (1) it is considered that because the uCDN has the authority (with respect to the CSP) and control on how the requests are delivered (including whether it is served by the uCDN itself or by a dCDN), the uCDN is entitled to access all detailed information related to the corresponding deliveries, and (2) there is no legal reason to restrict access by the uCDN to all this detailed information. Conversely still, when DNS redirection is used between the uCDN and the dCDN, there are cases where there may be some privacy concern in making detailed CDNI Logging information known to the uCDN; this may be the case, for example, because the uCDN is in a different jurisdiction to the dCDN, resulting is some legal reasons to restrict access by the uCDN to all the detailed information related to the deliveries. In this latter case, the privacy concerns can be taken into account when the uCDN and dCDN agree about which fields are to be conveyed inside the CDNI Logging Files and which privacy protection mechanism is to be used as discussed in the definition of the c-groupid field specified in Section 3.4.1.
当在uCDN和dCDN之间使用HTTP重定向时，让uCDN知道详细的CDNI日志信息并不代表特定的隐私问题，因为uCDN在请求重定向时已经暴露于显示为CDNI日志信息的大多数信息中（例如，最终用户IP地址、URL和HTTP头）。当在uCDN和dCDN之间使用DNS重定向时，在向uCDN提供详细的CDNI日志记录信息时，存在不涉及隐私的情况；例如，可能是这样的情况，（1）由于uCDN具有权限，因此认为：（就CSP而言）以及对如何交付请求的控制（包括是由uCDN本身还是由dCDN提供服务），uCDN有权访问与相应交付相关的所有详细信息，以及（2）没有法律理由限制uCDN对所有这些详细信息的访问。相反，当在uCDN和dCDN之间使用DNS重定向时，在某些情况下，uCDN了解详细的CDNI日志记录信息时可能会存在一些隐私问题；例如，这可能是因为uCDN处于d状态由于dCDN的管辖权不同，因此有一些法律原因限制uCDN访问与交付相关的所有详细信息。在后一种情况下，当uCDN和dCDN就CDNI日志文件中要传输的字段和隐私保护达成一致时，可以考虑隐私问题如第3.4.1节规定的c-groupid字段定义中所述，将使用n机制。
Another privacy concern arises from the fact that large volumes of detailed information about content delivery to users, potentially traceable back to individual users, may be collected in CDNI Logging Files. These CDNI Logging Files represent high-value targets, likely concentrated in a fairly centralized system (although the CDNI
另一个隐私问题是，CDNI日志文件中可能会收集大量关于向用户交付内容的详细信息，这些信息可能可以追溯到单个用户。这些CDNI日志文件代表高价值目标，可能集中在一个相当集中的系统中（尽管CDNI
Logging architecture does not mandate a particular level of centralization/distribution) and at risk of potential data exfiltration. Note that the means of such data exfiltration are beyond the scope of the CDNI Logging interface itself (e.g., corrupted employee, corrupted logging storage system, etc.). This privacy concern calls for some protection.
日志记录体系结构不要求特定级别的集中/分发），并且存在潜在数据外泄的风险。请注意，此类数据过滤的方式超出了CDNI日志记录接口本身的范围（例如，损坏的员工、损坏的日志记录存储系统等）。这种隐私问题需要一些保护。
The collection of large volumes of such information into CDNI Logging Files introduces potential end-users' privacy protection concerns. Mechanisms to address these concerns are discussed in the definition of the c-groupid field specified in Section 3.4.1.
将大量此类信息收集到CDNI日志文件中会带来潜在的最终用户隐私保护问题。第3.4.1节规定的c-groupid字段定义中讨论了解决这些问题的机制。
The use of mutually authenticated TLS to establish a secure session for the transport of the CDNI Logging feed and CDNI Logging pull as discussed in Section 7.1 provides confidentiality while the Logging information is in transit and prevents any party other than the authorized uCDN to gain access to the logging information.
如第7.1节所述，使用相互认证的TLS为CDNI日志馈送和CDNI日志拉取的传输建立安全会话，可在日志信息传输过程中提供机密性，并防止授权uCDN以外的任何一方访问日志信息。
We also note that the query string portion of the URL that may be conveyed inside the cs-uri and u-uri fields of CDNI Logging Files, or the HTTP cookies( [RFC6265]) that may be conveyed as part of the cs(<HTTP-header-name>) field of CDNI Logging Files, may contain personal information or information that can be exploited to derive personal information. Where this is a concern, the CDNI Logging interface specification allows the dCDN to not include the cs-uri and to include a u-uri that removes (or hides) the sensitive part of the query string and allows the dCDN to not include the cs(<HTTP-header-name>) fields corresponding to HTTP headers associated with cookies.
我们还注意到，URL的查询字符串部分可以在CDNI日志文件的cs uri和u-uri字段内传送，或者HTTP cookies（[RFC6265]）可以作为CDNI日志文件的cs（<HTTP header name>）字段的一部分传送，可能包含个人信息或可被利用来获取个人信息的信息。考虑到这一点，CDNI日志接口规范允许dCDN不包括cs uri，并允许dCDN包括删除（或隐藏）查询字符串敏感部分的u-uri，并允许dCDN不包括与Cookie关联的HTTP标头对应的cs（<HTTP header name>）字段。
[AES] NIST, "Advanced Encryption Standard (AES)", National Institute of Standards and Technology FIPS 197, November 2001, <http://csrc.nist.gov/publications/fips/fips197/ fips-197.pdf>.
[AES]NIST，“高级加密标准（AES）”，国家标准与技术研究所FIPS 197，2001年11月<http://csrc.nist.gov/publications/fips/fips197/ fips-197.pdf>。
[GCM] NIST, "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", National Institute of Standards and Technology SP 800-38D, DOI 10.6028/NIST.SP.800-38D, November 2007, <http://csrc.nist.gov/publications/nistpubs/800-38D/ SP-800-38D.pdf>.
[GCM]NIST，“分组密码操作模式建议：Galois/计数器模式（GCM）和GMAC”，国家标准与技术研究所SP 800-38D，DOI 10.6028/NIST.SP.800-38D，2007年11月<http://csrc.nist.gov/publications/nistpubs/800-38D/ SP-800-38D.pdf>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <http://www.rfc-editor.org/info/rfc3339>.
[RFC3339]Klyne，G.和C.Newman，“互联网上的日期和时间：时间戳”，RFC 3339，DOI 10.17487/RFC3339，2002年7月<http://www.rfc-editor.org/info/rfc3339>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <http://www.rfc-editor.org/info/rfc4122>.
[RFC4122]Leach，P.，Mealling，M.和R.Salz，“通用唯一标识符（UUID）URN名称空间”，RFC 4122，DOI 10.17487/RFC4122，2005年7月<http://www.rfc-editor.org/info/rfc4122>.
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication Format", RFC 4287, DOI 10.17487/RFC4287, December 2005, <http://www.rfc-editor.org/info/rfc4287>.
[RFC4287]诺丁汉，M.，Ed.和R.Sayre，Ed.，“原子联合格式”，RFC 4287，DOI 10.17487/RFC4287，2005年12月<http://www.rfc-editor.org/info/rfc4287>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC 4648，DOI 10.17487/RFC4648，2006年10月<http://www.rfc-editor.org/info/rfc4648>.
[RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005, DOI 10.17487/RFC5005, September 2007, <http://www.rfc-editor.org/info/rfc5005>.
[RFC5005]诺丁汉，M.，“提要分页和归档”，RFC 5005，DOI 10.17487/RFC5005，2007年9月<http://www.rfc-editor.org/info/rfc5005>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<http://www.rfc-editor.org/info/rfc7231>.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, <http://www.rfc-editor.org/info/rfc7232>.
[RFC7232]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：有条件请求”，RFC 7232，DOI 10.17487/RFC72322014年6月<http://www.rfc-editor.org/info/rfc7232>.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, DOI 10.17487/RFC7233, June 2014, <http://www.rfc-editor.org/info/rfc7233>.
[RFC7233]Fielding，R.，Ed.，Lafon，Y.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：范围请求”，RFC 7233，DOI 10.17487/RFC7233，2014年6月<http://www.rfc-editor.org/info/rfc7233>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <http://www.rfc-editor.org/info/rfc7234>.
[RFC7234]Fielding，R.，Ed.，Nottingham，M.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：缓存”，RFC 7234，DOI 10.17487/RFC72342014年6月<http://www.rfc-editor.org/info/rfc7234>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.
[RFC7235]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：认证”，RFC 7235，DOI 10.17487/RFC7235，2014年6月<http://www.rfc-editor.org/info/rfc7235>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<http://www.rfc-editor.org/info/rfc7525>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <http://www.rfc-editor.org/info/rfc7540>.
[RFC7540]Belshe，M.，Paon，R.，和M.Thomson，编辑，“超文本传输协议版本2（HTTP/2）”，RFC 7540，DOI 10.17487/RFC7540，2015年5月<http://www.rfc-editor.org/info/rfc7540>.
[SHA-3] NIST, "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", National Institute of Standards and Technology FIPS 202, DOI 10.6028/NIST.FIPS.202, August 2015, <http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf>.
[SHA-3]NIST，“SHA-3标准：基于排列的散列和可扩展输出函数”，国家标准与技术研究所FIPS 202，DOI 10.6028/NIST.FIPS.202，2015年8月<http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf>.
[ATOMPUB] Snell, J., "Atom Link Extensions", Work in Progress, draft-snell-atompub-link-extensions-09, June 2012.
[ATOMPUB]Snell，J.，“Atom链接扩展”，正在进行的工作，草稿-Snell-ATOMPUB-Link-Extensions-092012年6月。
[CDNI-META] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, "CDN Interconnection Metadata", Work in Progress, draft-ietf-cdni-metadata-20, August 2016.
[CDNI-META]Niven Jenkins，B.，Murray，R.，Caulfield，M.，和K.Ma，“CDN互连元数据”，正在进行的工作，草稿-ietf-CDNI-Metadata-202016年8月。
[CHAR_SET] IANA, "Character Sets", <http://www.iana.org/assignments/character-sets>.
[CHAR_SET]IANA，“字符集”<http://www.iana.org/assignments/character-sets>.
[ELF] Phillip M. Hallam-Baker, and Brian Behlendorf, "Extended Log File Format", W3C Working Draft, WD-logfile-960323, <http://www.w3.org/TR/WD-logfile.html>.
[ELF]Phillip M.Hallam Baker和Brian Behlendorf，“扩展日志文件格式”，W3C工作草案，WD-logfile-960323<http://www.w3.org/TR/WD-logfile.html>.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, DOI 10.17487/RFC1945, May 1996, <http://www.rfc-editor.org/info/rfc1945>.
[RFC1945]Berners Lee，T.，Fielding，R.，和H.Frystyk，“超文本传输协议——HTTP/1.0”，RFC 1945，DOI 10.17487/RFC1945，1996年5月<http://www.rfc-editor.org/info/rfc1945>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC 2818，DOI 10.17487/RFC2818，2000年5月<http://www.rfc-editor.org/info/rfc2818>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <http://www.rfc-editor.org/info/rfc5869>.
[RFC5869]Krawczyk，H.和P.Eronen，“基于HMAC的提取和扩展密钥派生函数（HKDF）”，RFC 5869，DOI 10.17487/RFC5869，2010年5月<http://www.rfc-editor.org/info/rfc5869>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <http://www.rfc-editor.org/info/rfc6234>.
[RFC6234]Eastlake 3rd，D.和T.Hansen，“美国安全哈希算法（基于SHA和SHA的HMAC和HKDF）”，RFC 6234，DOI 10.17487/RFC6234，2011年5月<http://www.rfc-editor.org/info/rfc6234>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <http://www.rfc-editor.org/info/rfc6265>.
[RFC6265]Barth，A.，“HTTP状态管理机制”，RFC 6265，DOI 10.17487/RFC6265，2011年4月<http://www.rfc-editor.org/info/rfc6265>.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6707, DOI 10.17487/RFC6707, September 2012, <http://www.rfc-editor.org/info/rfc6707>.
[RFC6707]Niven Jenkins，B.，Le Faucheur，F.，和N.Bitar，“内容分发网络互连（CDNI）问题声明”，RFC 6707，DOI 10.17487/RFC6707，2012年9月<http://www.rfc-editor.org/info/rfc6707>.
[RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, P., Ma, K., and G. Watson, "Use Cases for Content Delivery Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, November 2012, <http://www.rfc-editor.org/info/rfc6770>.
[RFC6770]Bertrand，G.，Ed.，Stephan，E.，Burbridge，T.，Eardley，P.，Ma，K.，和G.Watson，“内容交付网络互连的用例”，RFC 6770，DOI 10.17487/RFC6770，2012年11月<http://www.rfc-editor.org/info/rfc6770>.
[RFC6983] van Brandenburg, R., van Deventer, O., Le Faucheur, F., and K. Leung, "Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI)", RFC 6983, DOI 10.17487/RFC6983, July 2013, <http://www.rfc-editor.org/info/rfc6983>.
[RFC6983]van Brandenburg，R.，van Deventer，O.，Le Faucheur，F.，和K.Leung，“HTTP自适应流感知内容分发网络互连（CDNI）模型”，RFC 6983，DOI 10.17487/RFC6983，2013年7月<http://www.rfc-editor.org/info/rfc6983>.
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., "Framework for Content Distribution Network Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, August 2014, <http://www.rfc-editor.org/info/rfc7336>.
[RFC7336]Peterson，L.，Davie，B.，和R.van Brandenburg，编辑，“内容分发网络互连框架（CDNI）”，RFC 7336，DOI 10.17487/RFC7336，2014年8月<http://www.rfc-editor.org/info/rfc7336>.
[RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution Network Interconnection (CDNI) Requirements", RFC 7337, DOI 10.17487/RFC7337, August 2014, <http://www.rfc-editor.org/info/rfc7337>.
[RFC7337]Leung，K.，Ed.和Y.Lee，Ed.，“内容分发网络互连（CDNI）要求”，RFC 7337，DOI 10.17487/RFC7337，2014年8月<http://www.rfc-editor.org/info/rfc7337>.
[RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, December 2015, <http://www.rfc-editor.org/info/rfc7736>.
[RFC7736]马，K，“内容交付网络互连（CDNI）媒体类型注册”，RFC 7736，DOI 10.17487/RFC7736，2015年12月<http://www.rfc-editor.org/info/rfc7736>.
[TLS-1.3] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Work in Progress, draft-ietf-tls-tls13-15, August 2016.
[TLS-1.3]Rescorla，E.“传输层安全（TLS）协议版本1.3”，正在进行的工作，草案-ietf-TLS-tls13-15，2016年8月。
Acknowledgments
致谢
This document borrows from the W3C Extended Log Format [ELF].
本文档借用了W3C扩展日志格式[ELF]。
Rob Murray significantly contributed into the text of Section 4.1. The authors thank Ben Niven-Jenkins, Kevin Ma, David Mandelberg, and Ray van Brandenburg for their ongoing input.
Rob Murray对第4.1节的内容做出了重大贡献。作者感谢Ben Niven Jenkins、Kevin Ma、David Mandelberg和Ray van Brandenburg的持续投入。
Brian Trammel and Rich Salz made significant contributions into making this interface privacy-friendly.
Brian Trammel和Rich Salz为该界面的隐私友好性做出了重大贡献。
Finally, we also thank Sebastien Cubaud, Pawel Grochocki, Christian Jacquenet, Yannick Le Louedec, Anne Marrec, Emile Stephan, Fabio Costa, Sara Oueslati, Yvan Massot, Renaud Edel, Joel Favier, and the contributors of the EU FP7 OCEAN project for their input in the early draft versions of this document.
最后，我们还要感谢塞巴斯蒂安·库博、帕维尔·格罗乔基、克里斯蒂安·雅克内特、扬尼克·勒卢埃代克、安妮·马雷克、埃米尔·斯蒂芬、法比奥·科斯塔、萨拉·奥斯拉蒂、伊万·马索、勒诺·埃德尔、乔尔·法维尔以及欧盟FP7海洋项目的贡献者，感谢他们在本文件早期草案中的投入。
Authors' Addresses
作者地址
Francois Le Faucheur (editor) France
弗朗索瓦·勒·福彻（编辑）法国
Phone: +33 6 19 98 50 90
Email: flefauch@gmail.com
Phone: +33 6 19 98 50 90
Email: flefauch@gmail.com
Gilles Bertrand (editor)
吉尔斯·伯特兰（编辑）
Phone: +41 76 675 91 44
Email: gilbertrand@gmail.com
Phone: +41 76 675 91 44
Email: gilbertrand@gmail.com
Iuniana Oprescu (editor) France
Iuniana Oprescu（编辑）法国
Email: iuniana.oprescu@gmail.com
Email: iuniana.oprescu@gmail.com
Roy Peterkofsky Google Inc. 345 Spear St, 4th Floor San Francisco CA 94105 United States of America
罗伊彼得科夫斯谷歌公司345矛ST，旧金山CA 94105美利坚合众国第四楼
Email: peterkofsky@google.com
Email: peterkofsky@google.com