Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics
RFC 8008
| Document | Type |
RFC
- Proposed Standard
(December 2016)
Updated by RFC 9388
|
|
|---|---|---|---|
| Authors | Jan Seedorf , Jon Peterson , Stefano Previdi , Ray van Brandenburg , Kevin J. Ma | ||
| Last updated | 2016-12-13 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Alexey Melnikov | |
| Send notices to | (None) |
RFC 8008
Network Working Group J. Gould
Internet-Draft VeriSign, Inc.
Intended status: Standards Track October 8, 2018
Expires: April 11, 2019
Verification Code Extension for the Extensible Provisioning Protocol
(EPP)
draft-ietf-regext-verificationcode-04
Abstract
This document describes an Extensible Provisioning Protocol (EPP)
extension for including a verification code for marking the data for
a transform command as being verified by a 3rd party, which is
referred to as the Verification Service Provider (VSP). The
verification code is digitally signed by the VSP using XML Signature
and is "base64" encoded. The XML Signature includes the VSP signer
certificate, so the server can verify that the verification code
originated from the VSP.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 11, 2019.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(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
Gould Expires April 11, 2019 [Page 1]
Internet-Draft verificationCode October 2018
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Verification Code . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Signed Code . . . . . . . . . . . . . . . . . . . . . 4
2.1.2. Encoded Signed Code . . . . . . . . . . . . . . . . . 7
2.2. Verification Profile . . . . . . . . . . . . . . . . . . 11
3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 12
3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 12
3.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 12
3.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . 12
3.1.3. EPP <transfer> Command . . . . . . . . . . . . . . . 24
3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 25
3.2.1. EPP <create> Command . . . . . . . . . . . . . . . . 25
3.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . 27
3.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 28
3.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . 28
3.2.5. EPP <update> Command . . . . . . . . . . . . . . . . 28
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1. Verification Code Extension Schema . . . . . . . . . . . 28
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 32
5.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 32
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 33
6.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 33
6.2. Net::DRI . . . . . . . . . . . . . . . . . . . . . . . . 34
7. Security Considerations . . . . . . . . . . . . . . . . . . . 34
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.1. Normative References . . . . . . . . . . . . . . . . . . 35
8.2. Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 36
Appendix B. Change History . . . . . . . . . . . . . . . . . . . 36
B.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 36
B.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 36
B.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 36
B.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 36
B.5. Change from 04 to REGEXT 00 . . . . . . . . . . . . . . . 37
B.6. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 37
B.7. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 37
B.8. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 37
B.9. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 37
Gould Expires April 11, 2019 [Page 2]
Internet-Draft verificationCode October 2018
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction
This document describes an extension mapping for version 1.0 of the
Extensible Provisioning Protocol (EPP) [RFC5730]. This mapping, an
extension to EPP object mappings like the EPP domain name mapping
[RFC5731], EPP host mapping [RFC5732], and EPP contact mapping
[RFC5733], can be used to pass a verification code to one of the EPP
transform commands. The domain name object is used for examples in
the document. The verification code is signed using XML Signature
[W3C.CR-xmldsig-core2-20120124] and is "base64" encoded. The
"base64" encoded text of the verification code MUST conform to
[RFC2045]. The verification code demonstrates that verification was
done by a Verification Service Provider (VSP).
The Verification Service Provider (VSP) is a certified party to
verify that data is in compliance with the policies of a locality. A
locality MAY require the client to have data verified in accordance
with local regulations or laws utilizing data sources not available
to the server. The VSP has access to the local data sources and is
authorized to verify the data. Examples include verifying that the
domain name is not prohibited and verifying that the domain name
registrant is a valid individual, organization, or business in the
locality. The data verified, and the objects and operations that
require the verification code to be passed to the server, is up to
the policies of the locality. The verification code represents a
marker that the verification was completed. The VSP MUST store the
proof of verification and the generated verification code; and MAY
store the verified data. The signer certificate and the digital
signature of the verification code MUST be verified by the server.
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" registry [RFC7736])
Mandatory-to-Specify: Yes.
Property: capability-value
Description: CDNI capability object.
Type: Format/Type is defined by the value of the
capability-type property above
Mandatory-to-Specify: Yes.
Property: footprints
Description: CDNI capability footprint.
Type: List of CDNI Footprint objects (from the "CDNI Metadata
Footprint Types" registry [RFC8006])
Mandatory-to-Specify: No.
5.2. Encoding
CDNI FCI objects MUST be encoded using JSON [RFC7159] and MUST also
follow the recommendations of I-JSON (Internet JSON) [RFC7493]. FCI
objects are composed of a dictionary of (key,value) pairs where the
keys are the property names and the values are the associated
property values.
The keys of the dictionary are the names of the properties associated
with the object and are therefore dependent on the specific object
being encoded (i.e., dependent on the CDNI Payload Type of the
capability or the CDNI Metadata Footprint Type of the footprint).
Likewise, the values associated with each property (dictionary key)
are dependent on the specific object being encoded (i.e., dependent
on the CDNI Payload Type of the capability or the CDNI Metadata
Footprint Type of the footprint).
Seedorf, et al. Standards Track [Page 12]
RFC 8008 CDNI RR Footprint/Capabilities Semantics December 2016
Dictionary keys (properties) in JSON are case sensitive. By
convention, any dictionary key (property) defined by this document
MUST be lowercase.
5.3. Delivery Protocol Capability Object
The Delivery Protocol capability object is used to indicate support
for one or more of the protocols listed in the "CDNI Metadata
Protocol Types" registry (defined in [RFC8006]).
Property: delivery-protocols
Description: List of supported CDNI delivery protocols.
Type: List of protocol types (from the "CDNI Metadata Protocol
Types" registry [RFC8006])
Mandatory-to-Specify: Yes.
5.3.1. Delivery Protocol Capability Object Serialization
The following shows an example of Delivery Protocol capability object
serialization for a CDN that supports only HTTP/1.1 without Transport
Layer Security (TLS) for content delivery.
{
"capabilities": [
{
"capability-type": "FCI.DeliveryProtocol",
"capability-value": {
"delivery-protocols": [
"http/1.1",
]
},
"footprints": [
<Footprint objects>
]
}
]
}
Seedorf, et al. Standards Track [Page 13]
RFC 8008 CDNI RR Footprint/Capabilities Semantics December 2016
5.4. Acquisition Protocol Capability Object
The Acquisition Protocol capability object is used to indicate
support for one or more of the protocols listed in the "CDNI Metadata
Protocol Types" registry (defined in [RFC8006]).
Property: acquisition-protocols
Description: List of supported CDNI acquisition protocols.
Type: List of protocol types (from the "CDNI Metadata Protocol
Types" registry [RFC8006])
Mandatory-to-Specify: Yes.
5.4.1. Acquisition Protocol Capability Object Serialization
The following shows an example of Acquisition Protocol capability
object serialization for a CDN that supports HTTP/1.1 with or without
TLS for content acquisition.
{
"capabilities": [
{
"capability-type": "FCI.AcquisitionProtocol",
"capability-value": {
"acquisition-protocols": [
"http/1.1",
"https/1.1"
]
},
"footprints": [
<Footprint objects>
]
}
]
}
Seedorf, et al. Standards Track [Page 14]
RFC 8008 CDNI RR Footprint/Capabilities Semantics December 2016
5.5. Redirection Mode Capability Object
The Redirection Mode capability object is used to indicate support
for one or more of the modes listed in the "CDNI Capabilities
Redirection Modes" registry (see Section 6.2).
Property: redirection-modes
Description: List of supported CDNI redirection modes.
Type: List of redirection modes (from the "CDNI Capabilities
Redirection Modes" registry, defined in Section 6.2)
Mandatory-to-Specify: Yes.
5.5.1. Redirection Mode Capability Object Serialization
The following shows an example of Redirection Mode capability object
serialization for a CDN that supports only iterative (i.e., not
recursive) redirection with HTTP and DNS.
{
"capabilities": [
{
"capability-type": "FCI.RedirectionMode",
"capability-value": {
"redirection-modes": [
"DNS-I",
"HTTP-I"
]
}
"footprints": [
<Footprint objects>
]
}
]
}
Seedorf, et al. Standards Track [Page 15]
RFC 8008 CDNI RR Footprint/Capabilities Semantics December 2016
5.6. CDNI Logging Capability Object
The CDNI Logging capability object is used to indicate support for
CDNI Logging record-types, as well as CDNI Logging fields that are
marked as optional for the specified record-types [RFC7937].
Property: record-type
Description: Supported CDNI Logging record-type.
Type: String corresponding to an entry from the "CDNI Logging
record-types" registry [RFC7937]
Mandatory-to-Specify: Yes.
Property: fields
Description: List of supported CDNI Logging fields that are
optional for the specified record-type.
Type: List of strings corresponding to entries from the "CDNI
Logging Field Names" registry [RFC7937]
Mandatory-to-Specify: No. Default is that all optional fields
are supported. Omission of this field MUST be interpreted as
"all optional fields are supported". An empty list MUST be
interpreted as "no optional fields are supported". Otherwise,
if a list of fields is provided, the fields in that list MUST
be interpreted as "the only optional fields that are
supported".
Seedorf, et al. Standards Track [Page 16]
RFC 8008 CDNI RR Footprint/Capabilities Semantics December 2016
5.6.1. CDNI Logging Capability Object Serialization
The following shows an example of CDNI Logging capability object
serialization for a CDN that supports the optional Content
Collection ID CDNI Logging field (but not the optional Session ID
CDNI Logging field) for the "cdni_http_request_v1" record-type.
{
"capabilities": [
{
"capability-type": "FCI.Logging",
"capability-value": {
"record-type": "cdni_http_request_v1",
"fields": ["s-ccid"]
},
"footprints": [
<Footprint objects>
]
}
]
}
The next example shows the CDNI Logging capability object
serialization for a CDN that supports all optional fields for the
"cdni_http_request_v1" record-type.
{
"capabilities": [
{
"capability-type": "FCI.Logging",
"capability-value": {
"record-type": "cdni_http_request_v1"
},
"footprints": [
<Footprint objects>
]
}
]
}
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
XML is case sensitive. Unless stated otherwise, XML specifications
and examples provided in this document MUST be interpreted in the
character case presented in order to develop a conforming
implementation.
In examples, "C:" represents lines sent by a protocol client and "S:"
represents lines returned by a protocol server. Indentation and
Gould Expires April 11, 2019 [Page 3]
Internet-Draft verificationCode October 2018
white space in examples are provided only to illustrate element
relationships and are not a REQUIRED feature of this protocol.
"verificationCode-1.0" is used as an abbreviation for
"urn:ietf:params:xml:ns:verificationCode-1.0". The XML namespace
prefix "verificationCode" is used, but implementations MUST NOT
depend on it and instead employ a proper namespace-aware XML parser
and serializer to interpret and output the XML documents.
2. Object Attributes
This extension adds additional elements to EPP object mappings like
the EPP domain name mapping [RFC5731], EPP host mapping [RFC5732],
and EPP contact mapping [RFC5733]. Only those new elements are
described here.
2.1. Verification Code
The Verification Code is a formatted token, referred to as the
Verification Code Token, that is digitally signed by a Verification
Service Provider (VSP) using XML Signature
[W3C.CR-xmldsig-core2-20120124], using the process described in
Section 2.1.1, and is then "base64" encoded, as defined in
Section 2.1.2. The Verification Code Token syntax is specified using
Augmented Backus-Naur Form (ABNF) grammar [RFC5234] as follows:
Verification Code Token ABNF
token = vsp-id "-" verification-id ; Verification Code Token
vsp-id = 1*DIGIT ; VSP Identifier
verification-id = 1*(DIGIT / ALPHA) ; Verification Identifier
For a VSP given VSP Identifier "1" and with a Verification Identifier
of "abc123", the resulting Verification Code Token is "1-abc123".
The Verification Identifier MUST be unique within a VSP and the VSP
Identifier MUST be unique across supporting VSP's, so the
Verification Code Token MUST be unique to an individual verification.
The VSP Identifiers MAY require registration within an IANA registry.
2.1.1. Signed Code
The <verificationCode:signedCode> is the fragment of XML that is
digitally signed using XML Signature [W3C.CR-xmldsig-core2-20120124].
The <verificationCode:signedCode> element includes a required "id"
attribute of type XSD ID for use with an IDREF URI from the Signature
element. The certificate of the issuer MUST be included with the
Signature so it can be chained with the issuer's certificate by the
validating client.
Gould Expires April 11, 2019 [Page 4]
Seedorf, et al. Standards Track [Page 17]quot;, and
RFC 8008 CDNI RR Footprint/Capabilities Semantics December 2016
The final example shows the CDNI Logging capability object
serialization for a CDN that supports none of the optional fields for
the "cdni_http_request_v1" record-type.
{
"capabilities": [
{
"capability-type": "FCI.Logging",
"capability-value": {
"record-type": "cdni_http_request_v1",
"fields": []
},
"footprints": [
<Footprint objects>
]
}
]
}
5.7. CDNI Metadata Capability Object
The CDNI Metadata capability object is used to indicate support for
CDNI GenericMetadata types [RFC8006].
Property: metadata
Description: List of supported CDNI GenericMetadata types.
Type: List of strings corresponding to entries from the "CDNI
Payload Types" registry [RFC7736] that correspond to CDNI
GenericMetadata objects
Mandatory-to-Specify: Yes. An empty list MUST be interpreted
as "no GenericMetadata types are supported", i.e., "only
structural metadata and simple types are supported"; otherwise,
the list must be interpreted as containing "the only
GenericMetadata types that are supported" (in addition to
structural metadata and simple types) [RFC8006].
Seedorf, et al. Standards Track [Page 18]
RFC 8008 CDNI RR Footprint/Capabilities Semantics December 2016
5.7.1. CDNI Metadata Capability Object Serialization
The following shows an example of CDNI Metadata capability object
serialization for a CDN that supports only the SourceMetadata
GenericMetadata type (i.e., it can acquire and deliver content but
cannot enforce any security policies, e.g., time, location, or
protocol Access Control Lists (ACLs)).
{
"capabilities": [
{
"capability-type": "FCI.Metadata",
"capability-value": {
"metadata": ["MI.SourceMetadata"]
},
"footprints": [
<Footprint objects>
]
}
]
}
The next example shows the CDNI Metadata capability object
serialization for a CDN that supports only structural metadata (i.e.,
it can parse metadata as a transit CDN but cannot enforce security
policies or deliver content).
{
"capabilities": [
{
"capability-type": "FCI.Metadata",
"capability-value": {
"metadata": []
},
"footprints": [
<Footprint objects>
]
}
]
}
Seedorf, et al. Standards Track [Page 19]
RFC 8008 CDNI RR Footprint/Capabilities Semantics December 2016
6. IANA Considerations
6.1. CDNI Payload Types
This document registers the following CDNI Payload Types under the
IANA "CDNI Payload Types&Internet-Draft verificationCode October 2018
The <verificationCode:signedCode> element includes a REQUIRED "type"
attribute for use in defining the type of the signed code. It is up
to the VSP and the server to define the valid values for the "type"
attribute. Examples of possible "type" attribute values include
"domain" for verification of the domain name, "registrant" for
verification of the registrant contact, or "domain-registrant" for
verification of both the domain name and the registrant. The typed
signed code is used to indicate the verifications that are done by
the VSP. The "type" attribute values MAY require registration within
an IANA registry.
A <verificationCode:signedCode> element substitutes for the
<verificationCode:abstractSignedCode> abstract element to define a
concrete definition of a signed code. The
<verificationCode:abstractSignedCode> element can be replaced by
other signed code definitions using the XML schema substitution
groups feature.
The child elements of the <verificationCode:signedCode> element
include:
<verificationCode:code> Contains the Verification Code Token as
defined by the ABNF in Section 2.1.
<Signature> XML Signature [W3C.CR-xmldsig-core2-20120124] for the
<verificationCode:signedCode>. Use of a namespace prefix, like
"dsig", is recommended for the XML Signature
[W3C.CR-xmldsig-core2-20120124] elements.
Example of a "domain" typed signed code using the
<verificationCode:signedCode> element and XML Signature
[W3C.CR-xmldsig-core2-20120124]:
<verificationCode:signedCode
xmlns:verificationCode=
"urn:ietf:params:xml:ns:verificationCode-1.0"
id="signedCode">
<verificationCode:code type="domain">1-abc111
</verificationCode:code>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<Reference URI="#signedCode">
<Transforms>
<Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
Gould Expires April 11, 2019 [Page 5]
Internet-Draft verificationCode October 2018
</Transforms>
<DigestMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<DigestValue>wgyW3nZPoEfpptlhRILKnOQnbdtU6ArM7ShrAfHgDFg=
</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>
jMu4PfyQGiJBF0GWSEPFCJjmywCEqR2h4LD+ge6XQ+JnmKFFCuCZS/3SLKAx0L1w
QDFO2e0Y69k2G7/LGE37X3vOflobFM1oGwja8+GMVraoto5xAd4/AF7eHukgAymD
o9toxoa2h0yV4A4PmXzsU6S86XtCcUE+S/WM72nyn47zoUCzzPKHZBRyeWehVFQ+
jYRMIAMzM57HHQA+6eaXefRvtPETgUO4aVIVSugc4OUAZZwbYcZrC6wOaQqqqAZi
30aPOBYbAvHMSmWSS+hFkbshomJfHxb97TD2grlYNrQIzqXk7WbHWy2SYdA+sI/Z
ipJsXNa6osTUw1CzA7jfwA==
</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>
MIIESTCCAzGgAwIBAgIBAjANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEL
MAkGA1UECBMCQ0ExFDASBgNVBAcTC0xvcyBBbmdlbGVzMRMwEQYDVQQKEwpJQ0FO
TiBUTUNIMRswGQYDVQQDExJJQ0FOTiBUTUNIIFRFU1QgQ0EwHhcNMTMwMjA4MDAw
MDAwWhcNMTgwMjA3MjM1OTU5WjBsMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0Ex
FDASBgNVBAcTC0xvcyBBbmdlbGVzMRcwFQYDVQQKEw5WYWxpZGF0b3IgVE1DSDEh
MB8GA1UEAxMYVmFsaWRhdG9yIFRNQ0ggVEVTVCBDRVJUMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAo/cwvXhbVYl0RDWWvoyeZpETVZVVcMCovUVNg/sw
WinuMgEWgVQFrz0xA04pEhXCFVv4evbUpekJ5buqU1gmQyOsCKQlhOHTdPjvkC5u
pDqa51Flk0TMaMkIQjs7aUKCmA4RG4tTTGK/EjR1ix8/D0gHYVRldy1YPrMP+ou7
5bOVnIos+HifrAtrIv4qEqwLL4FTZAUpaCa2BmgXfy2CSRQbxD5Or1gcSa3vurh5
sPMCNxqaXmIXmQipS+DuEBqMM8tldaN7RYojUEKrGVsNk5i9y2/7sjn1zyyUPf7v
L4GgDYqhJYWV61DnXgx/Jd6CWxvsnDF6scscQzUTEl+hywIDAQABo4H/MIH8MAwG
A1UdEwEB/wQCMAAwHQYDVR0OBBYEFPZEcIQcD/Bj2IFz/LERuo2ADJviMIGMBgNV
HSMEgYQwgYGAFO0/7kEh3FuEKS+Q/kYHaD/W6wihoWakZDBiMQswCQYDVQQGEwJV
UzELMAkGA1UECBMCQ0ExFDASBgNVBAcTC0xvcyBBbmdlbGVzMRMwEQYDVQQKEwpJ
Q0FOTiBUTUNIMRswGQYDVQQDExJJQ0FOTiBUTUNIIFRFU1QgQ0GCAQEwDgYDVR0P
AQH/BAQDAgeAMC4GA1UdHwQnMCUwI6AhoB+GHWh0dHA6Ly9jcmwuaWNhbm4ub3Jn
L3RtY2guY3JsMA0GCSqGSIb3DQEBCwUAA4IBAQB2qSy7ui+43cebKUKwWPrzz9y/
IkrMeJGKjo40n+9uekaw3DJ5EqiOf/qZ4pjBD++oR6BJCb6NQuQKwnoAz5lE4Ssu
y5+i93oT3HfyVc4gNMIoHm1PS19l7DBKrbwbzAea/0jKWVzrvmV7TBfjxD3AQo1R
bU5dBr6IjbdLFlnO5x0G0mrG7x5OUPuurihyiURpFDpwH8KAH1wMcCpXGXFRtGKk
wydgyVYAty7otkl/z3bZkCVT34gPvF70sR6+QxUy8u0LzF5A/beYaZpxSYG31amL
AdXitTWFipaIGea9lEGFM0L9+Bg7XzNn4nVLXokyEB3bgS4scG6QznX23FGk
</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
</verificationCode:signedCode>
Gould Expires April 11, 2019 [Page 6]
Internet-Draft verificationCode October 2018
2.1.2. Encoded Signed Code
The <verificationCode:encodedSignedCode> element contains one or more
encoded form of the digitally signed <verificationCode:signedCode>
element, described in Section 2.1.1.
The child elements of the <verificationCode:encodedSignedCode>
element include:
<verificationCode:code> One or more <verificationCode:code> elements
that is an encoded form of the digitally signed
<verificationCode:signedCode> element, described in
Section 2.1.1, with the encoding defined by the "encoding"
attribute with the default "encoding" value of "base64". The
"base64" encoded text of the <verificationCode:code> element MUST
conform to [RFC2045].
Example <verificationCode:encodedSignedCode> element that contains
one "base64" encoded <verificationCode:signedCode> contained in the
<verificationCode:code> element:
<verificationCode:encodedSignedCode
xmlns:verificationCode=
"urn:ietf:params:xml:ns:verificationCode-1.0">
<verificationCode:code>
ICAgICAgPHZlcmlmaWNhdGlvbkNvZGU6c2lnbmVkQ29kZQogICAgICAgIHhtbG5z
OnZlcmlmaWNhdGlvbkNvZGU9CiAgICAgICAgICAidXJuOmlldGY6cGFyYW1zOnht
bDpuczp2ZXJpZmljYXRpb25Db2RlLTEuMCIKICAgICAgICAgIGlkPSJzaWduZWRD
b2RlIj4KICAgCQk8dmVyaWZpY2F0aW9uQ29kZTpjb2RlPjEtYWJjMTIzPC92ZXJp
ZmljYXRpb25Db2RlOmNvZGU+CiAgPFNpZ25hdHVyZSB4bWxucz0iaHR0cDovL3d3
dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyI+CiAgIDxTaWduZWRJbmZvPgogICAg
PENhbm9uaWNhbGl6YXRpb25NZXRob2QKIEFsZ29yaXRobT0iaHR0cDovL3d3dy53
My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8+CiAgICA8U2lnbmF0dXJlTWV0
aG9kCiBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZHNp
Zy1tb3JlI3JzYS1zaGEyNTYiLz4KICAgIDxSZWZlcmVuY2UgVVJJPSIjc2lnbmVk
Q29kZSI+CiAgICAgPFRyYW5zZm9ybXM+CiAgICAgIDxUcmFuc2Zvcm0KIEFsZ29y
aXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3Bl
ZC1zaWduYXR1cmUiLz4KICAgICA8L1RyYW5zZm9ybXM+CiAgICAgPERpZ2VzdE1l
dGhvZAogQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVu
YyNzaGEyNTYiLz4KIDxEaWdlc3RWYWx1ZT53Z3lXM25aUG9FZnBwdGxoUklMS25P
UW5iZHRVNkFyTTdTaHJBZkhnREZnPTwvRGlnZXN0VmFsdWU+CiAgICA8L1JlZmVy
ZW5jZT4KICAgPC9TaWduZWRJbmZvPgogICA8U2lnbmF0dXJlVmFsdWU+CiBqTXU0
UGZ5UUdpSkJGMEdXU0VQRkNKam15d0NFcVIyaDRMRCtnZTZYUStKbm1LRkZDdUNa
Uy8zU0xLQXgwTDF3CiBRREZPMmUwWTY5azJHNy9MR0UzN1gzdk9mbG9iRk0xb0d3
amE4K0dNVnJhb3RvNXhBZDQvQUY3ZUh1a2dBeW1ECiBvOXRveG9hMmgweVY0QTRQ
bVh6c1U2Uzg2WHRDY1VFK1MvV003Mm55bjQ3em9VQ3p6UEtIWkJSeWVXZWhWRlEr
CiBqWVJNSUFNek01N0hIUUErNmVhWGVmUnZ0UEVUZ1VPNGFWSVZTdWdjNE9VQVpa
d2JZY1pyQzZ3T2FRcXFxQVppCiAzMGFQT0JZYkF2SE1TbVdTUytoRmtic2hvbUpm
Gould Expires April 11, 2019 [Page 7]
Internet-Draft verificationCode October 2018
SHhiOTdURDJncmxZTnJRSXpxWGs3V2JIV3kyU1lkQStzSS9aCiBpcEpzWE5hNm9z
VFV3MUN6QTdqZndBPT0KICAgPC9TaWduYXR1cmVWYWx1ZT4KICAgPEtleUluZm8+
CiAgICA8WDUwOURhdGE+CiAgICA8WDUwOUNlcnRpZmljYXRlPgogTUlJRVNUQ0NB
ekdnQXdJQkFnSUJBakFOQmdrcWhraUc5dzBCQVFzRkFEQmlNUXN3Q1FZRFZRUUdF
d0pWVXpFTAogTUFrR0ExVUVDQk1DUTBFeEZEQVNCZ05WQkFjVEMweHZjeUJCYm1k
bGJHVnpNUk13RVFZRFZRUUtFd3BKUTBGTwogVGlCVVRVTklNUnN3R1FZRFZRUURF
eEpKUTBGT1RpQlVUVU5JSUZSRlUxUWdRMEV3SGhjTk1UTXdNakE0TURBdwogTURB
d1doY05NVGd3TWpBM01qTTFPVFU1V2pCc01Rc3dDUVlEVlFRR0V3SlZVekVMTUFr
R0ExVUVDQk1DUTBFeAogRkRBU0JnTlZCQWNUQzB4dmN5QkJibWRsYkdWek1SY3dG
UVlEVlFRS0V3NVdZV3hwWkdGMGIzSWdWRTFEU0RFaAogTUI4R0ExVUVBeE1ZVm1G
c2FXUmhkRzl5SUZSTlEwZ2dWRVZUVkNCRFJWSlVNSUlCSWpBTkJna3Foa2lHOXcw
QgogQVFFRkFBT0NBUThBTUlJQkNnS0NBUUVBby9jd3ZYaGJWWWwwUkRXV3ZveWVa
cEVUVlpWVmNNQ292VVZOZy9zdwogV2ludU1nRVdnVlFGcnoweEEwNHBFaFhDRlZ2
NGV2YlVwZWtKNWJ1cVUxZ21ReU9zQ0tRbGhPSFRkUGp2a0M1dQogcERxYTUxRmxr
MFRNYU1rSVFqczdhVUtDbUE0Ukc0dFRUR0svRWpSMWl4OC9EMGdIWVZSbGR5MVlQ
ck1QK291NwogNWJPVm5Jb3MrSGlmckF0ckl2NHFFcXdMTDRGVFpBVXBhQ2EyQm1n
WGZ5MkNTUlFieEQ1T3IxZ2NTYTN2dXJoNQogc1BNQ054cWFYbUlYbVFpcFMrRHVF
QnFNTTh0bGRhTjdSWW9qVUVLckdWc05rNWk5eTIvN3NqbjF6eXlVUGY3dgogTDRH
Z0RZcWhKWVdWNjFEblhneC9KZDZDV3h2c25ERjZzY3NjUXpVVEVsK2h5d0lEQVFB
Qm80SC9NSUg4TUF3RwogQTFVZEV3RUIvd1FDTUFBd0hRWURWUjBPQkJZRUZQWkVj
SVFjRC9CajJJRnovTEVSdW8yQURKdmlNSUdNQmdOVgogSFNNRWdZUXdnWUdBRk8w
LzdrRWgzRnVFS1MrUS9rWUhhRC9XNndpaG9XYWtaREJpTVFzd0NRWURWUVFHRXdK
VgogVXpFTE1Ba0dBMVVFQ0JNQ1EwRXhGREFTQmdOVkJBY1RDMHh2Y3lCQmJtZGxi
R1Z6TVJNd0VRWURWUVFLRXdwSgogUTBGT1RpQlVUVU5JTVJzd0dRWURWUVFERXhK
SlEwRk9UaUJVVFVOSUlGUkZVMVFnUTBHQ0FRRXdEZ1lEVlIwUAogQVFIL0JBUURB
Z2VBTUM0R0ExVWRId1FuTUNVd0k2QWhvQitHSFdoMGRIQTZMeTlqY213dWFXTmhi
bTR1YjNKbgogTDNSdFkyZ3VZM0pzTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElCQVFC
MnFTeTd1aSs0M2NlYktVS3dXUHJ6ejl5LwogSWtyTWVKR0tqbzQwbis5dWVrYXcz
REo1RXFpT2YvcVo0cGpCRCsrb1I2QkpDYjZOUXVRS3dub0F6NWxFNFNzdQogeTUr
aTkzb1QzSGZ5VmM0Z05NSW9IbTFQUzE5bDdEQktyYndiekFlYS8waktXVnpydm1W
N1RCZmp4RDNBUW8xUgogYlU1ZEJyNklqYmRMRmxuTzV4MEcwbXJHN3g1T1VQdXVy
aWh5aVVScEZEcHdIOEtBSDF3TWNDcFhHWEZSdEdLawogd3lkZ3lWWUF0eTdvdGts
L3ozYlprQ1ZUMzRnUHZGNzBzUjYrUXhVeTh1MEx6RjVBL2JlWWFacHhTWUczMWFt
TAogQWRYaXRUV0ZpcGFJR2VhOWxFR0ZNMEw5K0JnN1h6Tm40blZMWG9reUVCM2Jn
UzRzY0c2UXpuWDIzRkdrCiAgIDwvWDUwOUNlcnRpZmljYXRlPgogICA8L1g1MDlE
YXRhPgogICA8L0tleUluZm8+CiAgPC9TaWduYXR1cmU+CgkJPC92ZXJpZmljYXRp
b25Db2RlOnNpZ25lZENvZGU+Cg==
</verificationCode:code>
</verificationCode:encodedSignedCode>
Example <verificationCode:encodedSignedCode> element that contains
two <verificationCode:code> elements ;.
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<create>
<domain:create
Gould Expires April 11, 2019 [Page 8]
Internet-Draft verificationCode October 2018
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name>domain.example</domain:name>
<domain:registrant>jd1234</domain:registrant>
<domain:contact type="admin">sh8013</domain:contact>
<domain:contact type="tech">sh8013</domain:contact>
<domain:authInfo>
<domain:pw>2fooBAR</domain:pw>
</domain:authInfo>
</domain:create>
</create>
<extension>
<verificationCode:encodedSignedCode
xmlns:verificationCode=
"urn:ietf:params:xml:ns:verificationCode-1.0">
<verificationCode:code>
ICAgICAgPHZlcmlmaWNhdGlvbkNvZGU6c2lnbmVkQ29kZQogICAgICAgIHhtbG5z
OnZlcmlmaWNhdGlvbkNvZGU9CiAgICAgICAgICAidXJuOmlldGY6cGFyYW1zOnht
bDpuczp2ZXJpZmljYXRpb25Db2RlLTEuMCIKICAgICAgICAgIGlkPSJzaWduZWRD
b2RlIj4KICAgCQk8dmVyaWZpY2F0aW9uQ29kZTpjb2RlPjEtYWJjMTIzPC92ZXJp
ZmljYXRpb25Db2RlOmNvZGU+CiAgPFNpZ25hdHVyZSB4bWxucz0iaHR0cDovL3d3
dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyI+CiAgIDxTaWduZWRJbmZvPgogICAg
PENhbm9uaWNhbGl6YXRpb25NZXRob2QKIEFsZ29yaXRobT0iaHR0cDovL3d3dy53
My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8+CiAgICA8U2lnbmF0dXJlTWV0
aG9kCiBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZHNp
Zy1tb3JlI3JzYS1zaGEyNTYiLz4KICAgIDxSZWZlcmVuY2UgVVJJPSIjc2lnbmVk
Q29kZSI+CiAgICAgPFRyYW5zZm9ybXM+CiAgICAgIDxUcmFuc2Zvcm0KIEFsZ29y
aXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3Bl
ZC1zaWduYXR1cmUiLz4KICAgICA8L1RyYW5zZm9ybXM+CiAgICAgPERpZ2VzdE1l
dGhvZAogQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGVu
YyNzaGEyNTYiLz4KIDxEaWdlc3RWYWx1ZT53Z3lXM25aUG9FZnBwdGxoUklMS25P
UW5iZHRVNkFyTTdTaHJBZkhnREZnPTwvRGlnZXN0VmFsdWU+CiAgICA8L1JlZmVy
ZW5jZT4KICAgPC9TaWduZWRJbmZvPgogICA8U2lnbmF0dXJlVmFsdWU+CiBqTXU0
UGZ5UUdpSkJGMEdXU0VQRkNKam15d0NFcVIyaDRMRCtnZTZYUStKbm1LRkZDdUNa
Uy8zU0xLQXgwTDF3CiBRREZPMmUwWTY5azJHNy9MR0UzN1gzdk9mbG9iRk0xb0d3
amE4K0dNVnJhb3RvNXhBZDQvQUY3ZUh1a2dBeW1ECiBvOXRveG9hMmgweVY0QTRQ
bVh6c1U2Uzg2WHRDY1VFK1MvV003Mm55bjQ3em9VQ3p6UEtIWkJSeWVXZWhWRlEr
CiBqWVJNSUFNek01N0hIUUErNmVhWGVmUnZ0UEVUZ1VPNGFWSVZTdWdjNE9VQVpa
d2JZY1pyQzZ3T2FRcXFxQVppCiAzMGFQT0JZYkF2SE1TbVdTUytoRmtic2hvbUpm
SHhiOTdURDJncmxZTnJRSXpxWGs3V2JIV3kyU1lkQStzSS9aCiBpcEpzWE5hNm9z
VFV3MUN6QTdqZndBPT0KICAgPC9TaWduYXR1cmVWYWx1ZT4KICAgPEtleUluZm8+
CiAgICA8WDUwOURhdGE+CiAgICA8WDUwOUNlcnRpZmljYXRlPgogTUlJRVNUQ0NB
ekdnQXdJQkFnSUJBakFOQmdrcWhraUc5dzBCQVFzRkFEQmlNUXN3Q1FZRFZRUUdF
d0pWVXpFTAogTUFrR0ExVUVDQk1DUTBFeEZEQVNCZ05WQkFjVEMweHZjeUJCYm1k
bGJHVnpNUk13RVFZRFZRUUtFd3BKUTBGTwogVGlCVVRVTklNUnN3R1FZRFZRUURF
eEpKUTBGT1RpQlVUVU5JSUZSRlUxUWdRMEV3SGhjTk1UTXdNakE0TURBdwogTURB
d1doY05NVGd3TWpBM01qTTFPVFU1V2pCc01Rc3dDUVlEVlFRR0V3SlZVekVMTUFr
R0ExVUVDQk1DUTBFeAogRkRBU0JnTlZCQWNUQzB4dmN5QkJibWRsYkdWek1SY3dG
UVlEVlFRS0V3NVdZV3hwWkdGMGIzSWdWRTFEU0RFaAogTUI4R0ExVUVBeE1ZVm1G
Gould Expires April 11, 2019 [Page 9]
Internet-Draft verificationCode October 2018
c2FXUmhkRzl5SUZSTlEwZ2dWRVZUVkNCRFJWSlVNSUlCSWpBTkJna3Foa2lHOXcw
QgogQVFFRkFBT0NBUThBTUlJQkNnS0NBUUVBby9jd3ZYaGJWWWwwUkRXV3ZveWVa
cEVUVlpWVmNNQ292VVZOZy9zdwogV2ludU1nRVdnVlFGcnoweEEwNHBFaFhDRlZ2
NGV2YlVwZWtKNWJ1cVUxZ21ReU9zQ0tRbGhPSFRkUGp2a0M1dQogcERxYTUxRmxr
MFRNYU1rSVFqczdhVUtDbUE0Ukc0dFRUR0svRWpSMWl4OC9EMGdIWVZSbGR5MVlQ
ck1QK291NwogNWJPVm5Jb3MrSGlmckF0ckl2NHFFcXdMTDRGVFpBVXBhQ2EyQm1n
WGZ5MkNTUlFieEQ1T3IxZ2NTYTN2dXJoNQogc1BNQ054cWFYbUlYbVFpcFMrRHVF
QnFNTTh0bGRhTjdSWW9qVUVLckdWc05rNWk5eTIvN3NqbjF6eXlVUGY3dgogTDRH
Z0RZcWhKWVdWNjFEblhneC9KZDZDV3h2c25ERjZzY3NjUXpVVEVsK2h5d0lEQVFB
Qm80SC9NSUg4TUF3RwogQTFVZEV3RUIvd1FDTUFBd0hRWURWUjBPQkJZRUZQWkVj
SVFjRC9CajJJRnovTEVSdW8yQURKdmlNSUdNQmdOVgogSFNNRWdZUXdnWUdBRk8w
LzdrRWgzRnVFS1MrUS9rWUhhRC9XNndpaG9XYWtaREJpTVFzd0NRWURWUVFHRXdK
VgogVXpFTE1Ba0dBMVVFQ0JNQ1EwRXhGREFTQmdOVkJBY1RDMHh2Y3lCQmJtZGxi
R1Z6TVJNd0VRWURWUVFLRXdwSgogUTBGT1RpQlVUVU5JTVJzd0dRWURWUVFERXhK
SlEwRk9UaUJVVFVOSUlGUkZVMVFnUTBHQ0FRRXdEZ1lEVlIwUAogQVFIL0JBUURB
Z2VBTUM0R0ExVWRId1FuTUNVd0k2QWhvQitHSFdoMGRIQTZMeTlqY213dWFXTmhi
bTR1YjNKbgogTDNSdFkyZ3VZM0pzTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElCQVFC
MnFTeTd1aSs0M2NlYktVS3dXUHJ6ejl5LwogSWtyTWVKR0tqbzQwbis5dWVrYXcz
REo1RXFpT2YvcVo0cGpCRCsrb1I2QkpDYjZOUXVRS3dub0F6NWxFNFNzdQogeTUr
aTkzb1QzSGZ5VmM0Z05NSW9IbTFQUzE5bDdEQktyYndiekFlYS8waktXVnpydm1W
N1RCZmp4RDNBUW8xUgogYlU1ZEJyNklqYmRMRmxuTzV4MEcwbXJHN3g1T1VQdXVy
aWh5aVVScEZEcHdIOEtBSDF3TWNDcFhHWEZSdEdLawogd3lkZ3lWWUF0eTdvdGts
L3ozYlprQ1ZUMzRnUHZGNzBzUjYrUXhVeTh1MEx6RjVBL2JlWWFacHhTWUczMWFt
TAogQWRYaXRUV0ZpcGFJR2VhOWxFR0ZNMEw5K0JnN1h6Tm40blZMWG9reUVCM2Jn
UzRzY0c2UXpuWDIzRkdrCiAgIDwvWDUwOUNlcnRpZmljYXRlPgogICA8L1g1MDlE
YXRhPgogICA8L0tleUluZm8+CiAgPC9TaWduYXR1cmU+CgkJPC92ZXJpZmljYXRp
b25Db2RlOnNpZ25lZENvZGU+Cg==
</verificationCode:code>
<verificationCode:code>
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48dmVyaWZpY2F0
aW9uQ29kZTpzaWduZWRDb2RlIHhtbG5zOnZlcmlmaWNhdGlvbkNvZGU9InVybjpp
ZXRmOnBhcmFtczp4bWw6bnM6dmVyaWZpY2F0aW9uQ29kZS0xLjAiIGlkPSJzaWdu
ZWRDb2RlIiB0eXBlPSJyZWdpc3RyYW50Ij48dmVyaWZpY2F0aW9uQ29kZTpjb2Rl
PjEtYWJjMjIyPC92ZXJpZmljYXRpb25Db2RlOmNvZGU+PGRzaWc6U2lnbmF0dXJl
IHhtbG5zOmRzaWc9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyMi
Pjxkc2lnOlNpZ25lZEluZm8+PGRzaWc6Q2Fub25pY2FsaXphdGlvbk1ldGhvZCBB
bGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnL1RSLzIwMDEvUkVDLXhtbC1jMTRu
LTIwMDEwMzE1I1dpdGhDb21tZW50cyIvPjxkc2lnOlNpZ25hdHVyZU1ldGhvZCBB
bGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyNyc2Et
c2hhMSIvPjxkc2lnOlJlZmVyZW5jZSBVUkk9IiNzaWduZWRDb2RlIj48ZHNpZzpU
cmFuc2Zvcm1zPjxkc2lnOlRyYW5zZm9ybSBBbGdvcml0aG09Imh0dHA6Ly93d3cu
dzMub3JnLzIwMDAvMDkveG1sZHNpZyNlbnZlbG9wZWQtc2lnbmF0dXJlIi8+PC9k
c2lnOlRyYW5zZm9ybXM+PGRzaWc6RGlnZXN0TWV0aG9kIEFsZ29yaXRobT0iaHR0
cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxlbmMjc2hhMjU2Ii8+PGRzaWc6RGln
ZXN0VmFsdWU+SFg2TU1WUWdnSStzNG9tT3haYjBGTW1VSlBRdk15WmUybDVEdEhh
QlZMND08L2RzaWc6RGlnZXN0VmFsdWU+PC9kc2lnOlJlZmVyZW5jZT48L2RzaWc6
U2lnbmVkSW5mbz48ZHNpZzpTaWduYXR1cmVWYWx1ZT5VOUhPNVlYVWE0ZUsyYXRz
U1RuQk1DU3dXM0dWUzZnUEtkaDBZTlZicERud1d4b1BtYlR2YkVsNDE4NFlKZ3Uw
Gould Expires April 11, 2019 [Page 10]
Internet-Draft verificationCode October 2018
WXB3RkROMmZLY3JVCk1YV0hncE56K0oycTh6MWpTcVJMUEw0UmpnRWw0eGhiOXl5
cExOZC8xQXJXRVlhWWZEdUc1S3FYV05MRG5YVzJoQkEzK0R5Wk82MFQKcTVPd0R5
ZVFSVlNPVWNXVE9FOTJsSlZ4M014Q1V6d1hoL0ZOSTlPbGtXK0ZPNVZNNTZlTmZq
UEhkUlJVdjdzQzRmM0NnWmFaSWFXNQp2RmJnTmJodFJVa0hsSVhnYVNGWDgvcFdV
RXFIY0dLTUxnRU1nbHBnQ3RtOFlIcXVqb0tXUk0yUDNiK2h3ZTRsU0hSWVRjK0pB
eEluClU4RDc1WnliWThnSWFuZUprS2dwVTk2T0tJTGQ5L0l0UVhaeHZnPT08L2Rz
aWc6U2lnbmF0dXJlVmFsdWU+PGRzaWc6S2V5SW5mbz48ZHNpZzpYNTA5RGF0YT48
ZHNpZzpYNTA5Q2VydGlmaWNhdGU+TUlJRGlUQ0NBbkdnQXdJQkFnSUVmcXE2SFRB
TkJna3Foa2lHOXcwQkFRc0ZBREIxTVJBd0RnWURWUVFHRXdkVmJtdHViM2R1TVJB
dwpEZ1lEVlFRSUV3ZFZibXR1YjNkdU1SQXdEZ1lEVlFRSEV3ZFZibXR1YjNkdU1S
QXdEZ1lEVlFRS0V3ZFZibXR1YjNkdU1SQXdEZ1lEClZRUUxFd2RWYm10dWIzZHVN
Umt3RndZRFZRUURFeEIyWlhKcFptbGpZWFJwYjI1RGIyUmxNQjRYRFRFMU1EWXhO
VEl4TURBeU1sb1gKRFRNMU1EWXhNREl4TURBeU1sb3dkVEVRTUE0R0ExVUVCaE1I
Vlc1cmJtOTNiakVRTUE0R0ExVUVDQk1IVlc1cmJtOTNiakVRTUE0RwpBMVVFQnhN
SFZXNXJibTkzYmpFUU1BNEdBMVVFQ2hNSFZXNXJibTkzYmpFUU1BNEdBMVVFQ3hN
SFZXNXJibTkzYmpFWk1CY0dBMVVFCkF4TVFkbVZ5YVdacFkyRjBhVzl1UTI5a1pU
Q0NBU0l3RFFZSktvWklodmNOQVFFQkJRQURnZ0VQQURDQ0FRb0NnZ0VCQUpjY2pY
cmsKUWFJL2lHUEZ3WmVITjFnRFVhcTltVnJmQis2eWR5Qmdoc2FHVFZoaERIOFNO
TmtpamxIMkxCQ3J3TjhjVjhQZ1BPOXRwbG9rR2F5UwpxNktFaHZtTk03b1dsZk5L
SkdSdGNidGMzTnJuYzhiUUJacU1xcFo0UlNRTmh5QWh6Ri85UmErd3RFc0JWeGF3
VDc1L2J0SDZ1YytmClJOdE5FcmhJdVlJUmN0WTZIRmRaR3BlS3cxYnlYK0RsNkJP
L3ZLdnQ4NDllY1R3aEZIcDUwWGh2NFVTL0Z5aWVLaGs3dDdHRnJGRlQKL2NCTGsy
WmxFa1lLcFlEU2dlc2lseFg2QkpTZVdCbXZLQzlTL2pBZDhNWmRHVUg2aHNHRXBl
U1BmZkZQV3FWcXl6V0p5bG91OXF4ZQpnUTZjOFo2SVpXZkUzakxSOUVySDhzOTFD
Mm1pTFZrQ0F3RUFBYU1oTUI4d0hRWURWUjBPQkJZRUZIY0JLdk03dmk3dUZNTUx5
ZE43CmVGVXF2YzVVTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElCQVFBVjB2cmlrSWRB
d2l4THZ0NUx5eXpTNFdTU1d0dVlWL2JQMVg3NzVMRmYKSWh3a2xoMENidk5rYXlK
Tms2Tnp0eDlSc1AwNWZndkxrZER1N0V5cnRzY3I1ZVdETG1WMGtKMWE1N1Z4bnJh
aEdLTnM2Wit1Ui9pSApMaTJXb3liWEpFT2N0NWtJSjFzL05CeUUrdkdGdjFoTmJz
dVVVUEVCYWVtaWpYUFROOWxxZE9uM1FIbktobXhsa1czYS9KbmhtT20vCkRWYTE0
NDJXTVVUSlUyVFlWVldtdUs2NFkwQXFrN2FldzkvVzIzZEcrT2xhOW9VYnBrSXJr
dDRDN3hRa0d5SXN2eUo3bi91OFhBRDIKbno1T1cvek5GWnlrZDAzT2N3M240NkZx
c1IwVDlBbFBEWHQxUjlmMjZMd1lxdjk3dWtVNEcrMVRJNHorV0F2TCtVRk9FVnNu
PC9kc2lnOlg1MDlDZXJ0aWZpY2F0ZT48L2RzaWc6WDUwOURhdGE+PC9kc2lnOktl
eUluZm8+PC9kc2lnOlNpZ25hdHVyZT48L3ZlcmlmaWNhdGlvbkNvZGU6c2lnbmVk
Q29kZT4=
</verificationCode:code>
</verificationCode:encodedSignedCode>
</extension>
<clTRID>ABC-12345</clTRID>
</command>
</epp>
2.2. Verification Profile
A Verification Profile defines the set of verification code types,
the commands that the verification code types are required,
supported, or not supported, and the grace period by which the
Gould Expires April 11, 2019 [Page 11]
Internet-Draft verificationCode October 2018
verification code types MUST be set. A server MAY support many
verification profiles, each with a unique name and a unique
verification policy that is implemented by the server. Each client
MAY have zero or more server assigned verification profiles that will
enforce the required verification policies. Most likely a client
will be assigned zero or one server assigned verification profile,
but overlapping profiles is possible. Overlapping verification
profiles MUST be treated as a logical "and" of the policies by the
server. If no verification profile is assigned to the client, no
additional verification is required by the client.
3. EPP Command Mapping
A detailed description of the EPP syntax and semantics can be found
in the EPP core protocol specification [RFC5730].
3.1. EPP Query Commands
EPP provides three commands to retrieve object information: <check>
to determine if an object is known to the server, <info> to retrieve
detailed information associated with an object, and <transfer> to
retrieve object transfer status information.
3.1.1. EPP <check" registry:
+-------------------------+---------------+
| Payload Type | Specification |
+-------------------------+---------------+
| FCI.DeliveryProtocol | RFC 8008 |
| FCI.AcquisitionProtocol | RFC 8008 |
| FCI.RedirectionMode | RFC 8008 |
| FCI.Logging | RFC 8008 |
| FCI.Metadata | RFC 8008 |
+-------------------------+---------------+
6.1.1. CDNI FCI DeliveryProtocol Payload Type
Purpose: The purpose of this Payload Type is to distinguish FCI
advertisement objects for supported delivery protocols
Interface: FCI
Encoding: see Section 5.3
6.1.2. CDNI FCI AcquisitionProtocol Payload Type
Purpose: The purpose of this Payload Type is to distinguish FCI
advertisement objects for supported acquisition protocols
Interface: FCI
Encoding: see Section 5.4
6.1.3. CDNI FCI RedirectionMode Payload Type
Purpose: The purpose of this Payload Type is to distinguish FCI
advertisement objects for supported redirection modes
Interface: FCI
Encoding: see Section 5.5
Seedorf, et al. Standards Track [Page 20]
RFC 8008 CDNI RR Footprint/Capabilities Semantics December 2016
6.1.4. CDNI FCI Logging Payload Type
Purpose: The purpose of this Payload Type is to distinguish FCI
advertisement objects for supported CDNI Logging record-types and
optional CDNI Logging field names
Interface: FCI
Encoding: see Section 5.6
6.1.5. CDNI FCI Metadata Payload Type
Purpose: The purpose of this Payload Type is to distinguish FCI
advertisement objects for supported CDNI GenericMetadata types
Interface: FCI
Encoding: see Section 5.7
6.2. "CDNI Capabilities Redirection Modes" Registry
IANA has created a new "CDNI Capabilities Redirection Modes" registry
in the "Content Delivery Network Interconnection (CDNI) Parameters"
registry. The "CDNI Capabilities Redirection Modes" namespace
defines the valid redirection modes that can be advertised as
supported by a CDN. Additions to the "CDNI Capabilities Redirection
Modes" namespace conform to the IETF Review policy as defined in
[RFC5226].
The following table defines the initial redirection modes:
+------------------+----------------------------------+----------+
| Redirection Mode | Description | RFC |
+------------------+----------------------------------+----------+
| DNS-I | Iterative DNS-based Redirection | RFC 8008 |
| DNS-R | Recursive DNS-based Redirection | RFC 8008 |
| HTTP-I | Iterative HTTP-based Redirection | RFC 8008 |
| HTTP-R | Recursive HTTP-based Redirection | RFC 8008 |
+------------------+----------------------------------+----------+
Seedorf, et al. Standards Track [Page 21]
RFC 8008 CDNI RR Footprint/Capabilities Semantics December 2016
7. Security Considerations
This specification describes the semantics for capabilities and
footprint advertisement objects across interconnected CDNs. It does
not, however, specify a concrete protocol for transporting those
objects. Specific security mechanisms can only be selected for
concrete protocols that instantiate these semantics. This document
does, however, place some high-level security constraints on such
protocols.
All protocols that implement these capabilities and footprint
advertisement objects are REQUIRED to provide integrity and
authentication services. Without authentication and integrity, an
attacker could trivially deny service by forging a footprint
advertisement from a dCDN that claims the network has no footprint or
capability. This would prevent the uCDN from delegating any requests
to the dCDN. Since a preexisting relationship between all dCDNs and
uCDNs is assumed by CDNI, the exchange of any necessary credentials
could be conducted before the FCI is brought online. The
authorization decision to accept advertisements would also follow
this preexisting relationship and any contractual obligations that it
stipulates.
All protocols that implement these capabilities and footprint
advertisement objects are REQUIRED to provide confidentiality
services. Some dCDNs are willing to share information about their
footprints or capabilities with a uCDN but not with other, competing
dCDNs. For example, if a dCDN incurs an outage that reduces
footprint coverage temporarily, that event could be information the
dCDN would want to share confidentially with the uCDN.
As specified in this document, the security requirements of the FCI
could be met by transport-layer security mechanisms coupled with
domain certificates as credentials (e.g., TLS transport for HTTP as
per [RFC2818] and [RFC7230], with usage guidance from [RFC7525])
between CDNs. There is no apparent need for further object-level
security in this framework, as the trust relationships it defines are
bilateral relationships between uCDNs and dCDNs rather than
transitive relationships.
Seedorf, et al. Standards Track [Page 22]
RFC 8008 CDNI RR Footprint/Capabilities Semantics December 2016
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159,
March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[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>.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
DOI 10.17487/RFC7493, March 2015,
<http://www.rfc-editor.org/info/rfc7493>.
[RFC7937] Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed.,
and R. Peterkofsky, "Content Distribution Network
Interconnection (CDNI) Logging Interface", RFC 7937,
DOI 10.17487/RFC7937, August 2016,
<http://www.rfc-editor.org/info/rfc7937>.
[RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"Content Delivery Network Interconnection (CDNI)
Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016,
<http://www.rfc-editor.org/info/rfc8006>.
Seedorf, et al. Standards Track [Page 23]
RFC 8008 CDNI RR Footprint/Capabilities Semantics December 2016
8.2. Informative References
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
Seedorf, et al. Standards Track [Page 24]
RFC 8008 CDNI RR Footprint/Capabilities Semantics December 2016
Appendix A. Main Use Case to Consider
Focusing on a main use case that contains a simple (yet somewhat
challenging), realistic, and generally imaginable scenario can help
narrow down the requirements for the CDNI FCI. To this end, the
following (simplified) use case can help clarify the semantics of
footprints and capabilities for CDNI. In particular, the intention
of the use case is to clarify what information needs to be exchanged
on the CDNI FCI, what types of information need to be supported in a
mandatory fashion (and which types can be considered optional), and
what types of information need to be updated with respect to a priori
established CDNI contracts.
Use case: A given uCDN has several dCDNs. It selects one dCDN for
delivery protocol A and footprint 1 and another dCDN for delivery
protocol B and footprint 1. The dCDN that serves delivery protocol B
has a further, transitive (level-2) dCDN that serves delivery
protocol B in a subset of footprint 1 where the first-level dCDN
cannot serve delivery protocol B itself. What happens if
capabilities change in the transitive level-2 dCDN that might affect
how the uCDN selects a level-1 dCDN (e.g., in case the level-2 dCDN
cannot serve delivery protocol B anymore)? How will these changes be
conveyed to the uCDN? In particular, what information does the uCDN
need to be able to select a new first-level dCDN, for either all of
footprint 1 or only the subset of footprint 1 that the transitive
level-2 dCDN served on behalf of the first-level dCDN?
Appendix B. Semantics for Footprint Advertisement
Roughly speaking, "footprint" can be defined as a dCDN's "ability and
willingness to serve". However, in addition to simple ability and
willingness to serve, the uCDN could want additional information
before deciding which dCDN to select, e.g., "how well" a given dCDN
can actually serve a given end user request. The dCDN's ability and
willingness to serve SHOULD be distinguished from the subjective
qualitative measurement of how well it can serve a given end user
request. One can imagine that such additional information is
implicitly associated with a given footprint, due to contractual
agreements, Service Level Agreements (SLAs), business relationships,
or past perceptions of dCDN quality. As an alternative, such
additional information could also be explicitly included with the
given footprint.
It is reasonable to assume that a significant part of the actual
footprint advertisement will occur out-of-band, prior to any CDNI FCI
advertisement, with footprints defined in contractual agreements
between participating CDNs. The reason for this assumption is that
any contractual agreement is likely to contain specifics about the
Seedorf, et al. Standards Track [Page 25]
RFC 8008 CDNI RR Footprint/Capabilities Semantics December 2016
gt; Command
This extension does not add any elements to the EPP <check> command
or <check> response described in the [RFC5730].
3.1.2. EPP <info> Command
This extension defines additional elements to extend the EPP <info>
command of an object mapping like the EPP domain name mapping
[RFC5731], EPP host mapping [RFC5732], and EPP contact mapping
[RFC5733].
The EPP <info> command is used to retrieve the verification
information. The verification information is based on the
verification profile, as defined in Section 2.2, set in the server
for the client. The <verificationCode:info> element is an empty
element that indicates that the client requests the verification
information. The OPTIONAL "profile" attribute can be used by the
client to explicitly specify a verification profile, as defined in
Section 2.2, to base the verification information on. It is up to
server policy on the set of verification profiles that the client is
allowed to explicitly specify, and if the client is not allowed, the
server MUST return the 2201 error response.
Gould Expires April 11, 2019 [Page 12]
Internet-Draft verificationCode October 2018
Example <info> domain command with the <verificationCode:info>
extension to retrieve the verification information for the domain
"domain.example", using the profiles associated with the client:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <info>
C: <domain:info
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>domain.example</domain:name>
C: </domain:info>
C: </info>
C: <extension>
C: <verificationCode:info
C: xmlns:verificationCode=
C: "urn:ietf:params:xml:ns:verificationCode-1.0"/>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
Example <info> domain command with the <verificationCode:info>
extension to retrieve the verification information for the domain
"domain.example", using the profiles associated with the client and
with the authorization information to retrieve the verification codes
from the non-sponsoring client:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <info>
C: <domain:info
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>domain.example</domain:name>
C: <domain:authInfo>
C: <domain:pw>2fooBAR</domain:pw>
C: </domain:authInfo>
C: </domain:info>
C: </info>
C: <extension>
C: <verificationCode:info
C: xmlns:verificationCode=
C: "urn:ietf:params:xml:ns:verificationCode-1.0"/>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
Gould Expires April 11, 2019 [Page 13]
Internet-Draft verificationCode October 2018
Example <info> domain command with the <verificationCode:info>
extension to retrieve the verification information for the domain
"domain.example", using the the "sample" profile:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <info>
C: <domain:info
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>domain.example</domain:name>
C: </domain:info>
C: </info>
C: <extension>
C: <verificationCode:info
C: xmlns:verificationCode=
C: "urn:ietf:params:xml:ns:verificationCode-1.0"
C: profile="sample"/>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
If the query was successful, the server replies with a
<verificationCode:infData> element along with the regular EPP
<resData>. The <verificationCode:infData> element contains the
following child elements:
<verificationCode:status> The status of the verification for the
object, using all of the verification profiles assigned to the
client. There are four possible values for the status:
notApplicable The status is not applicable to the client since
there is no assigned verification profile.
nonCompliant The object is non-compliant according to the
verification profiles. If at least one of the profiles is
"nonCompliant", the object is "nonCompliant".
pendingCompliance The object is not in compliance with the
verification profiles, but has a grace period to set the
required set of verification codes, as reflected by the due
date of the verification code type. If at least one of the
profiles is "pendingCompliance" and none of the profiles is
"nonCompliant", the object is "pendingCompliance".
compliant The object is compliant with the verification
profiles. If All of the profiles for the object are
"compliant" or if the object has no assignd profiles, the
object is "compliant".
Gould Expires April 11, 2019 [Page 14]
Internet-Draft verificationCode October 2018
<verificationCode:profile> Zero or more OPTIONAL
<verificationCode:profile> elements that defines the verification
status of the object based on the profile. The required "name"
attribute defines the name of the profile. The
&dCDN coverage (footprint) to which the contractual agreement applies.
In particular, additional information to judge the delivery quality
associated with a given dCDN footprint might be defined in
contractual agreements, outside of the CDNI FCI. Further, one can
assume that dCDN contractual agreements about the delivery quality
associated with a given footprint will probably be based on
high-level aggregated statistics and will not be too detailed.
Given that a large part of the footprint advertisement will be
defined in contractual agreements, the semantics of CDNI footprint
advertisement refer to answering the following question: what exactly
still needs to be advertised by the CDNI FCI? For instance, updates
about temporal failures of part of a footprint can be useful
information to convey via the CDNI Request Routing interface. Such
information would provide updates on information previously agreed
upon in contracts between the participating CDNs. In other words,
the CDNI FCI is a means for a dCDN to provide changes/updates
regarding a footprint it has previously agreed to serve in a contract
with a uCDN.
Generally speaking, one can imagine two categories of footprints to
be advertised by a dCDN:
o A footprint could be defined based on coverage/reachability, where
"coverage/reachability" refers to a set of prefixes, a geographic
region, or similar boundary. The dCDN claims that it can
cover/reach "end user requests coming from this footprint".
o A footprint could be defined based on resources, where "resources"
refers to Surrogates a dCDN claims to have (e.g., the location of
Surrogates/resources). The dCDN claims that "from this footprint"
it can serve incoming end user requests.
For each of these footprint types, there are capabilities associated
with a given footprint:
o capabilities such as delivery protocol, redirection mode, and
metadata, which are supported in the coverage area for a footprint
that is defined by coverage/reachability, or
o capabilities of resources, such as delivery protocol, redirection
mode, and metadata, which apply to a footprint that is defined by
resources.
Resource footprint types are more specific than coverage/reachability
footprint types, where the actual coverage and reachability are
extrapolated from the resource location (e.g., a netmask applied to a
resource IP address to derive an IP prefix). The specific methods
Seedorf, et al. Standards Track [Page 26]
RFC 8008 CDNI RR Footprint/Capabilities Semantics December 2016
for extrapolating coverage/reachability from the resource location
are beyond the scope of this document. In the degenerate case, the
resource address could be specified as a coverage/reachability
footprint type, in which case no extrapolation is necessary.
Resource footprint types could expose the internal structure of a
CDN; this could be undesirable. As such, the resource footprint
types are not considered mandatory to support for CDNI.
Footprints can be viewed as constraints for delegating requests to a
dCDN: a dCDN footprint advertisement tells the uCDN the limitations
for delegating a request to the dCDN. For IP prefixes or ASN(s), the
footprint signals to the uCDN that it should consider the dCDN a
candidate only if the IP address of the Request Routing source falls
within the prefix set (or ASN, respectively). The CDNI
specifications do not define how a given uCDN determines what address
ranges are in a particular ASN. Similarly, for country codes, a uCDN
should only consider the dCDN a candidate if it covers the country of
the Request Routing source. The CDNI specifications do not define
how a given uCDN determines the country of the Request Routing
source. Multiple footprint constraints are additive: the
advertisement of different footprint types narrows the dCDN's
candidacy cumulatively.
Independent of the exact type of a footprint, a footprint might also
include the connectivity of a given dCDN to other CDNs that are able
to serve content to users on behalf of that dCDN, to cover cases with
cascaded CDNs. Further, the dCDN needs to be able to express its
footprint to an interested uCDN in a comprehensive form, e.g., as a
data set containing the complete footprint. However, making
incremental updates to express dynamic changes in state is also
desirable.
Appendix C. Semantics for Capabilities Advertisement
In general, the dCDN needs to be able to express its general
capabilities to the uCDN. These general capabilities could indicate
if the dCDN supports a given service -- for instance, HTTP vs. HTTPS
delivery. Furthermore, the dCDN needs to be able to express
particular capabilities for service delivery in a particular
footprint area. For example, the dCDN might in general offer HTTPS
but not in some specific areas, either for maintenance reasons or
because the Surrogates covering this particular area cannot deliver
this type of service. Hence, in certain cases a footprint and
capabilities are tied together and cannot be interpreted
independently of each other. In such cases, i.e., where capabilities
need to be expressed on a per-footprint basis, it could be beneficial
to combine footprint advertisement and capabilities advertisement.
Seedorf, et al. Standards Track [Page 27]
RFC 8008 CDNI RR Footprint/Capabilities Semantics December 2016
A high-level and very rough semantic for capabilities is thus the
following: capabilities are types of information that allow a uCDN to
determine if a dCDN is able (and willing) to accept (and properly
handle) a delegated content request. In addition, capabilities are
characterized by the fact that this information can change over time
based on the state of the network or Surrogates.
At first glance, several broad categories of capabilities seem useful
to convey via an advertisement interface; however, advertising
capabilities that change highly dynamically (e.g., real-time delivery
performance metrics, CDN resource load, or other highly dynamically
changing QoS information) are beyond the scope of the CDNI FCI.
First, out of the multitude of possible metrics and capabilities, it
is hard to agree on a subset and the precise metrics to be used.
Second, it seems infeasible to specify such highly dynamically
changing capabilities and the corresponding metrics within a
reasonable time frame.
Useful capabilities refer to information that does not change highly
dynamically and that, in many cases, is absolutely necessary for
deciding on a particular dCDN for a given end user request. For
instance, if an end user request concerns the delivery of a video
file with a certain protocol, the uCDN needs to know if a given dCDN
is capable of supporting this delivery protocol.
Similar to footprint advertisement, it is reasonable to assume that a
significant part of the actual (resource) capabilities advertisement
will also occur out-of-band, prior to any CDNI FCI advertisement,
with capabilities defined in contractual agreements between
participating CDNs. The role of capability advertisement is hence
rather to enable the dCDN to update a uCDN on changes since a
contract has been set up (e.g., in case a new delivery protocol is
suddenly being added to the list of supported delivery protocols of a
given dCDN or in case a certain delivery protocol is suddenly not
being supported anymore due to failures). "Capabilities
advertisement" thus refers to conveying information to a uCDN about
changes/updates to certain capabilities with respect to a given
contract.
Given these semantics, it needs to be decided what exact capabilities
are useful and how these can be expressed. Since the details of CDNI
contracts are not known at the time of this writing (and the CDNI
interface is better off being agnostic to these contracts anyway), it
remains to be seen what capabilities will be used to define
agreements between CDNs in practice. One implication for
standardization could be to initially only specify a very limited set
of mandatory capabilities for advertisement and have, on top of that,
Seedorf, et al. Standards Track [Page 28]
RFC 8008 CDNI RR Footprint/Capabilities Semantics December 2016
a flexible data model that allows exchanging additional capabilities
when needed. Still, agreement needs to be reached regarding which
capabilities (if any) will be mandatory among CDNs.
It is not feasible to enumerate all the possible options for the
mandatory capabilities listed above (e.g., all the potential delivery
protocols or metadata options) or anticipate all the future needs for
additional capabilities. FCI object extensibility is necessary to
support future capabilities, as well as a generic protocol for
conveying any capability information (e.g., with common encoding,
error handling, and security mechanisms; further requirements for the
CDNI FCI are listed in [RFC7337]).
Seedorf, et al. Standards Track [Page 29]
RFC 8008 CDNI RR Footprint/Capabilities Semantics December 2016
Acknowledgments
Jan Seedorf is partially supported by the GreenICN project
(GreenICN: Architecture and Applications of Green Information Centric
Networking), a research project supported jointly by the European
Commission under its 7th Framework Program (contract no. 608518) and
the National Institute of Information and Communications Technology
(NICT) in Japan (contract no. 167). The views and conclusions
contained herein are those of the authors and should not be
interpreted as necessarily representing the official policies or
endorsements, either expressed or implied, of the GreenICN project,
the European Commission, or NICT.
Martin Stiemerling provided initial input to this document and
valuable comments to the ongoing discussions among the authors of
this document. Thanks to Francois Le Faucheur and Scott Wainner for
providing valuable comments and suggestions for the text.
Authors' Addresses
Jan Seedorf
HFT Stuttgart - University of Applied Sciences Stuttgart
Schellingstrasse 24
Stuttgart 70174
Germany
Phone: +49-0711-8926-2801
Email: jan.seedorf@hft-stuttgart.de
Jon Peterson
NeuStar
1800 Sutter St. Suite 570
Concord, CA 94520
United States of America
Email: jon.peterson@neustar.biz
Seedorf, et al. Standards Track [Page 30]
RFC 8008 CDNI RR Footprint/Capabilities Semantics December 2016
Stefano Previdi
Cisco Systems
Via Del Serafico 200
Rome 0144
Italy
Email: sprevidi@cisco.com
Ray van Brandenburg
TNO
Anna van Buerenplein 1
The Hague 2595DA
The Netherlands
Phone: +31-88-866-7000
Email: ray.vanbrandenburg@tno.nl
Kevin J. Ma
Ericsson
43 Nagog Park
Acton, MA 01720
United States of America
Phone: +1-978-844-5100
Email: kevin.j.ma@ericsson.com
Seedorf, et al. Standards Track [Page 31]