--- 1/draft-ietf-cdni-logging-22.txt 2016-03-18 03:16:19.984705445 -0700 +++ 2/draft-ietf-cdni-logging-23.txt 2016-03-18 03:16:20.096708219 -0700 @@ -1,22 +1,23 @@ Internet Engineering Task Force F. Le Faucheur, Ed. Internet-Draft Cisco Systems Intended status: Standards Track G. Bertrand, Ed. -Expires: September 3, 2016 I. Oprescu, Ed. - Orange +Expires: September 19, 2016 Orange + I. Oprescu, Ed. + R. Peterkofsky - Skytide, Inc. - March 2, 2016 + Google Inc. + March 18, 2016 CDNI Logging Interface - draft-ietf-cdni-logging-22 + draft-ietf-cdni-logging-23 Abstract This memo specifies the Logging interface between a downstream CDN (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. @@ -28,90 +29,90 @@ 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 September 3, 2016. + This Internet-Draft will expire on September 19, 2016. Copyright Notice Copyright (c) 2016 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 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 + 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 . . . . . . . . . . . . . . . . . . 8 2.2.1. Logging Generation and During-Generation Aggregation 9 2.2.2. Logging Collection . . . . . . . . . . . . . . . . . 10 2.2.3. Logging Filtering . . . . . . . . . . . . . . . . . . 10 2.2.4. Logging Rectification and Post-Generation Aggregation 11 2.2.5. Log-Consuming Applications . . . . . . . . . . . . . 12 2.2.5.1. Maintenance/Debugging . . . . . . . . . . . . . . 12 2.2.5.2. Accounting . . . . . . . . . . . . . . . . . . . 13 2.2.5.3. Analytics and Reporting . . . . . . . . . . . . . 13 2.2.5.4. Content Protection . . . . . . . . . . . . . . . 13 2.2.5.5. Notions common to multiple Log Consuming Applications . . . . . . . . . . . . . . . . . . 14 3. CDNI Logging File . . . . . . . . . . . . . . . . . . . . . . 16 3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2. CDNI Logging File Structure . . . . . . . . . . . . . . . 17 3.3. CDNI Logging Directives . . . . . . . . . . . . . . . . . 20 3.4. CDNI Logging Records . . . . . . . . . . . . . . . . . . 24 3.4.1. HTTP Request Logging Record . . . . . . . . . . . . . 25 - 3.5. CDNI Logging File Example . . . . . . . . . . . . . . . . 35 - 3.6. Cascaded CDNI Logging Files Example . . . . . . . . . . . 37 + 3.5. CDNI Logging File Extension . . . . . . . . . . . . . . . 35 + 3.6. CDNI Logging File Example . . . . . . . . . . . . . . . . 36 + 3.7. Cascaded CDNI Logging Files Example . . . . . . . . . . . 38 4. Protocol for Exchange of CDNI Logging File After Full - Collection . . . . . . . . . . . . . . . . . . . . . . . . . 40 - 4.1. CDNI Logging Feed . . . . . . . . . . . . . . . . . . . . 41 - 4.1.1. Atom Formatting . . . . . . . . . . . . . . . . . . . 41 - 4.1.2. Updates to Log Files and the Feed . . . . . . . . . . 41 - 4.1.3. Redundant Feeds . . . . . . . . . . . . . . . . . . . 42 - 4.1.4. Example CDNI Logging Feed . . . . . . . . . . . . . . 42 - 4.2. CDNI Logging File Pull . . . . . . . . . . . . . . . . . 44 - 5. Protocol for Exchange of CDNI Logging File During Collection 45 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 - 6.1. CDNI Logging Directive Names Registry . . . . . . . . . . 46 - 6.2. CDNI Logging File version Registry . . . . . . . . . . . 47 - 6.3. CDNI Logging record-types Registry . . . . . . . . . . . 47 - 6.4. CDNI Logging Field Names Registry . . . . . . . . . . . . 48 - 6.5. CDNI Logging MIME Media Type . . . . . . . . . . . . . . 49 - - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 50 + Collection . . . . . . . . . . . . . . . . . . . . . . . . . 41 + 4.1. CDNI Logging Feed . . . . . . . . . . . . . . . . . . . . 42 + 4.1.1. Atom Formatting . . . . . . . . . . . . . . . . . . . 42 + 4.1.2. Updates to Log Files and the Feed . . . . . . . . . . 42 + 4.1.3. Redundant Feeds . . . . . . . . . . . . . . . . . . . 43 + 4.1.4. Example CDNI Logging Feed . . . . . . . . . . . . . . 43 + 4.2. CDNI Logging File Pull . . . . . . . . . . . . . . . . . 45 + 5. Protocol for Exchange of CDNI Logging File During Collection 46 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 + 6.1. CDNI Logging Directive Names Registry . . . . . . . . . . 47 + 6.2. CDNI Logging File version Registry . . . . . . . . . . . 48 + 6.3. CDNI Logging record-types Registry . . . . . . . . . . . 48 + 6.4. CDNI Logging Field Names Registry . . . . . . . . . . . . 49 + 6.5. CDNI Logging MIME Media Type . . . . . . . . . . . . . . 50 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 51 7.1. Authentication, Authorization, Confidentiality, Integrity - Protection . . . . . . . . . . . . . . . . . . . . . . . 50 - 7.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 51 - 7.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 51 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 53 - 9.2. Informative References . . . . . . . . . . . . . . . . . 54 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 + Protection . . . . . . . . . . . . . . . . . . . . . . . 51 + 7.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 52 + 7.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 52 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 54 + 9.2. Informative References . . . . . . . . . . . . . . . . . 55 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 1. Introduction 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. The reader should be familiar with the following documents: @@ -316,21 +317,21 @@ ===> CDNI Logging Interface ***> outside the scope of CDNI Figure 1: Interactions in CDNI Logging Reference Model 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.6. + aggregation is further discussed in Section 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 @@ -875,21 +876,21 @@ ":" HTAB and the directive value. Directive names MUST be of the format NAMEFORMAT. All directive names MUST be registered in the CDNI Logging Directives Names registry. 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. The following example shows the structure of a directive and enumerates strictly the directive values presently defined in the - record-type "cdni_http_request_v1." + version "CDNI/1.0" of the CDNI Logging File. directive = DIRNAME ":" HTAB DIRVAL DIRNAME = NAMEFORMAT 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: @@ -993,21 +994,22 @@ directive per CDNI Logging File. The first instance of this directive MUST precede a fields directive and MUST precede all CDNI Logging Records. * example: "record-type: HTAB cdni_http_request_v1". o fields: * format: FIENAME *(HTAB FIENAME) ; where FIENAME can take any CDNI Logging field name registered in the CDNI Logging Field - Names registry (Section 6.4). + Names registry (Section 6.4) that is valid for the record type + specified in the record-type directive. * 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). 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. @@ -1197,86 +1199,87 @@ 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 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. 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): + than one client. - + the c-groupid MAY be structured (e.g., US/TN/ - MEM/38138/43a5bdd6-95c4-4d62-be65-7410df0021e2) where some - elements identify aggregates and one element identifies the - client. + + 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 and + one element identifies the client, e.g., US/TN/ + MEM/38138/43a5bdd6-95c4-4d62-be65-7410df0021e2. In that + case: - + the address with a shared secret that is pre-synchronised - and rotated at a predefined time interval. It is - RECOMMENDED that the mapping varies at least once every 24 - hours. The mapping from IP address to the element - identifying the client (effectively an encryption of the - address) SHOULD be done using a symmetric key that is known - only to both the uCDN and dCDN. One method of doing this is - to use an analog of how key derivation is via HKDF - ([RFC5869]), as will be used in TLS 1.3 - ([I-D.ietf-tls-rfc5246-bis]). When the two CDNs set up the - relationship, they agree out-of-band on a mapping between - IPv4 and IPv6 addresses and aggregates and on the - algorithmic mapping from IPv4/IPv6 addresses and the element - identifying the client; they agree on the salt and input key - material, as described in [RFC5869], Section 2.2, the hash - mechanism to use (SHA-2 or SHA-3 SHOULD be used), and the - key lifetime which SHOULD NOT exceed 25 hours. They also - agree on an initial "info" parameter, which can be something - such as the business names of the two organizations in UTF- - 8, concatenated. The encryption algorithm also needs to be - defined, and SHOULD be 128-bit AES-GCM or better. The PRK - should be chosen by both parties contributing alternate - random bytes until sufficient length exists. After this - initial setup, client-information is encrypted using the key - generated by the "expand" step, Section 2.3 of [RFC5869], - and hex-encoded or base64-encoded. At the agreed-upon - lifetime, a new key is used, indicated by prefixing the key - with a special character such as exclamation point. In this - way, shorter lifetimes can be used as needed. + - 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). - + 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); one example way to achieve this is to hash. + - It is RECOMMENDED that the mapping varies at least once + every 24 hours. - + The algorithmic mapping and variation over time MAY allow + - The algorithmic mapping and variation over time MAY allow the uCDN (with the knowledge of the algorithm and time - variation and associated attributes and keys) to reconstruct - the actual enduser IPv4/IPv6 addresses where that is - required (e.g., to allow a-posteriori analysis of individual + variation and 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 enduser IPv4/IPv6 addresses - SHOULD only be reconstructed on-demand and the CDNI Logging - File SHOULD only be stored with the anonymised c-groupid + penalties). However, these enduser addresses SHOULD only + be reconstructed on-demand and the CDNI Logging File + SHOULD only be stored with the anonymised c-groupid value. - + Using the c-groupid field in this way 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. + - 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. + + - One method for mapping that MAY be be supported by + implementations relies on a symmetric key that is known + only to the uCDN and dCDN and HMAC-based Extract-and- + Expand Key Derivation Function (HKDF) key derivation + ([RFC5869]), as will be used in TLS 1.3 + ([I-D.ietf-tls-rfc5246-bis]). When that method is used: + + 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 + Section 2.3 of [RFC5869]. The hash SHOULD be either + SHA-2 or SHA-3 and the encryption algorithm SHOULD be + 128-bit AES-GCM or better. The 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 or + base64 encoded. 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 exclamation point. In this way, + shorter lifetimes can be used as needed. * occurrence: there MUST be one and only one instance of this field. o s-ip: * format: ADDRESS * field value: the IPv4 or IPv6 address of the Surrogate that served the request (i.e., the "server" address). @@ -1613,21 +1618,50 @@ do not contain field values for exactly the set of field names actually listed in the preceding "fields" directive, the implementation MUST reject those HTTP Request Logging Records, and MUST accept the other HTTP Request Logging Records. 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. -3.5. CDNI Logging File Example +3.5. CDNI Logging File Extension + + 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 8, 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". + + 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". + +3.6. CDNI Logging File Example Let us consider the upstream CDN and the downstream CDN labelled 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. #version:cdni/1.0 @@ -1703,21 +1736,21 @@ 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. -3.6. Cascaded CDNI Logging Files Example +3.7. Cascaded CDNI Logging Files Example 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 5. 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 5 contains a single CDNI Logging Record. @@ -2099,22 +2132,22 @@ When IANA allocates new extensions to CDNI Logging Directive Names Registry, CDNI Logging File version Registry, CDNI Logging record- type Registry or CDNI Logging fields Registry, IANA MUST take into account that the directive names are case-insensitive as per the basic ABNF([RFC5234]). 6.1. CDNI Logging Directive Names Registry The IANA is requested to create a new "CDNI Logging Directive Names" - registry under the "Content Delivery Networks Interconnection (CDNI) - Parameters" category. + subregistry under the "Content Delivery Networks Interconnection + (CDNI) Parameters" registry. 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: +------------------------------+-----------+ | Directive Name | Reference | +------------------------------+-----------+ | version | RFC xxxx | | UUID | RFC xxxx | @@ -2139,22 +2172,22 @@ 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). 6.2. CDNI Logging File version Registry The IANA is requested to create a new "CDNI Logging File version" - registry under the "Content Delivery Networks Interconnection (CDNI) - Parameters" category. + subregistry under the "Content Delivery Networks Interconnection + (CDNI) Parameters" registry. The initial contents of the CDNI Logging Logging File version registry comprise the value "CDNI/1.0" specified in Section 3.3 of the present document, and are as follows: +-----------------+-----------+----------------------------------+ | version | Reference | Description | +-----------------+-----------+----------------------------------+ | cdni/1.0 | RFC xxxx | CDNI Logging File version 1.0 | | | | as specified in RFC xxxx | @@ -2166,22 +2199,22 @@ the present document] 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). 6.3. CDNI Logging record-types Registry The IANA is requested to create a new "CDNI Logging record-types" - under the "Content Delivery Networks Interconnection (CDNI) - Parameters" category. + subregistry under the "Content Delivery Networks Interconnection + (CDNI) Parameters" registry. 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: +----------------------+-----------+---------------------------------+ | record-types | Reference | Description | +----------------------+-----------+---------------------------------+ | cdni_http_request_v1 | RFC xxxx | CDNI Logging Record version 1 | | | | for content delivery using HTTP | @@ -2207,22 +2240,22 @@ Field in the new record-type 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. 6.4. CDNI Logging Field Names Registry The IANA is requested to create a new "CDNI Logging Field Names" - under the "Content Delivery Networks Interconnection (CDNI) - Parameters" category. + subregistry under the "Content Delivery Networks Interconnection + (CDNI) Parameters" registry. This registry is intended to be shared across the currently defined record-type (i.e., cdni_http_request_v1) as well as potential 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 @@ -2601,26 +2634,21 @@ Gilles Bertrand (editor) Orange 38-40 rue du General Leclerc Issy les Moulineaux 92130 FR Phone: +33 1 45 29 89 46 Email: gilles.bertrand@orange.com Iuniana Oprescu (editor) - Orange - 38-40 rue du General Leclerc - Issy les Moulineaux 92130 FR - Phone: +33 6 89 06 92 72 - Email: iuniana.oprescu@orange.com + Email: iuniana.oprescu@gmail.com Roy Peterkofsky - Skytide, Inc. - One Kaiser Plaza, Suite 785 - Oakland CA 94612 + Google Inc. + 345 Spear St, 4th Floor + San Francisco CA 94105 USA - Phone: +01 510 250 4284 - Email: roy@skytide.com + Email: peterkofsky@google.com