From ben@niven-jenkins.co.uk Fri Nov 2 07:28:01 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894F621F8AB7 for ; Fri, 2 Nov 2012 07:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-FU+z2x302z for ; Fri, 2 Nov 2012 07:28:01 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 07AE521F8AB2 for ; Fri, 2 Nov 2012 07:28:01 -0700 (PDT) Received: from [81.134.152.4] (helo=xxx.corp.velocix.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1TUIE3-0005C6-TK for cdni@ietf.org; Fri, 02 Nov 2012 14:28:00 +0000 From: Ben Niven-Jenkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Nov 2012 14:27:59 +0000 Message-Id: <91A268D8-34D3-4732-ACC2-37FF91E925ED@niven-jenkins.co.uk> To: cdni@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Subject: [CDNi] Comments on draft-leung-cdni-uri-signing-01 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 14:28:01 -0000 Kent, Francois, Matt, =46rom reading draft-leung-cdni-uri-signing-01 it appears to be trying = to outline what is required for CDN "URI Signing"/"Token authorisation" = as well as describing a particular "URI Signing" mechanism (that has a = number of significant drawbacks). I'd suggest splitting these more explicitly into a more general = discussion on what the authorisation attributes that could/should be = supported are, what is needed on the other CDNI interfaces to support = uri signing/token authorisation and what the use cases are for different = type of signing/authorisation are e.g. is appending query parameters = sufficient? The draft could also describe a particular algorithm/mechanism but I = think that should be in a later section or an appendix (or separate = document) rather than being placed in the middle of the document as it = is currently. Ben From kevin.ma@azukisystems.com Sun Nov 4 12:07:28 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55CE21F8830 for ; Sun, 4 Nov 2012 12:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiJ00kIdAHsR for ; Sun, 4 Nov 2012 12:07:27 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id CA41021F860D for ; Sun, 4 Nov 2012 12:07:26 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id E2ADD8BEC65; Sun, 4 Nov 2012 15:07:24 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB024.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id E9F4D8BEC3B; Sun, 4 Nov 2012 15:07:23 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB024.mail.lan ([10.110.17.24]) with mapi; Sun, 4 Nov 2012 15:07:06 -0500 From: Kevin J Ma To: "Francois Le Faucheur (flefauch)" , "draft-ietf-cdni-metadata@tools.ietf.org" Date: Sun, 4 Nov 2012 15:07:23 -0500 Thread-Topic: First batch of comments from review of draft-ietf-cdni-metadata-00.txt Thread-Index: AQHNsUm63sRF/Xg/pkCylJisS6aMZpfaJNEA Message-ID: <291CC3F9E50E7641901A54E85D0977C6535F4FBC28@MAILR002.mail.lan> References: <20121002173431.31982.57229.idtracker@ietfa.amsl.com> <166EBB70C264A9479E459B01B1BA6C920F3D5FC5@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] First batch of comments from review of draft-ietf-cdni-metadata-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 20:07:28 -0000 Hi Francois, All great comments. Some quick answers to a couple of the questions: > why does "\" have to be escaped if it does not have ay special meaning = (like "*" and "?") ? The backslash has the special meaning as the escape character; it needs to be escapeable to allow the literal backslash character to appear directly adjacent to wildcards, e.g., "\\*". > can you discuss your assumptions here for how content would be acquired= in that case? The thinking was that if content was all pre-positioned, there may be no need to acquire it. > when there are multiple sources listed: is it in descending order of pr= eference from viewpoint of dCDN? is it left to the dCDN? The thought is that lists are ordered from highest to lowest precedence. The use of explicit priorities for list entries was discussed, but not added. There is still question imo as to who is allowed to alter the order (or explicit priorities). Certain security properties set by the content provider should probably not be reordered by dCDNs, but perhaps a dCDN should be allowed to add or modify the priority of acqusition sources. From your second batch of comments, about section 4.3.2: > * section 4.3.2 Protocol: I think this section probably just needs some general cleanup. Looks like it may have come directly from draft-jenkins-cdni-metadata and probably lost some of its original context. wrt your final comment on framework section 4.6: > I'd picture the "Check-with-uCDN" as something that can be used "in add= ition" to access control rules that may be distributed to dCDN and not "ins= tead of". My interpretation of the framework text was that Metadata revalidation was required. The existing metadata properties already contain the ability to specify deny rules? While the check-with-me flag is easy to add, what would be the protocol used in the check? Does a protocol need to be defined here, or at least a protocolID specified so that the dCDN knows how to check? There are also a number of security issues that come to mind with the check api, which are probably beyond the scope of the metadata interface. thanx. -- Kevin J. Ma > -----Original Message----- > From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] > Sent: Tuesday, October 23, 2012 2:11 PM > To: draft-ietf-cdni-metadata@tools.ietf.org > Cc: cdni@ietf.org > Subject: First batch of comments from review of draft-ietf-cdni-metadata- > 00.txt > > Hello, > > I started doing a review of draft-ietf-cdni-metadata-00.txt (as an > Individual). > > This document is shaping up very well. > > My specific comments/questions/suggestions are listed below (I stopped > just before section 4.3). > > I hope this is useful. > > Francois > > > Comments/Suggestions > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > OLD: > " > Cacheability improves the latency of acquiring metadata > " > NEW: > " > Cacheability improves the latency of acquiring metadata while maintaining > its freshness > " > > > OLD: > " > Deterministic mappings from content requests to metadata properties > eliminates ambiguity and ensures that the same policies are applied > consistently by all downstream CDNs. > " > NEW: > " > Deterministic mappings from content to metadata properties > eliminates ambiguity and ensures that policies are applied > consistently by all downstream CDNs. > " > (the policies may not be exactly the same for all dCDNs, but they need to > be deterministic so uCDN can achieve consistent operation) > > > OLD: > " > describes a data structure for mapping > content requests to metadata properties > " > NEW: > " > describes a data structure for mapping > redirection requests and content requests to metadata properties > " > (Note: this occurs many times throughout the documents) > > > OLD: > " > A HostIndex object contains a list of Hostnames (and/or IP addresses) > that may be delegated to the downstream CDN. > " > NEW: > " > A HostIndex object contains a list of Hostnames (and/or IP addresses) > for which content requests may be delegated to the downstream CDN. > " > > > OLD: > " > When looking up CDNI Metadata, the downstream CDN looks > up the requested Hostname (or IP address) in the HostIndex, from > there it can find HostMetadata which describes delivery rules for a > host and PathMetadata which may override those rules for given URI > paths within the host. > " > NEW: > " > When looking up CDNI Metadata, the downstream CDN looks > up the requested Hostname (or IP address) in the HostIndex, from > there it can find HostMetadata which describes properties for a > host and PathMetadata which may override those properties for given UR= I > paths within the host. > " > (rationale: there is more to metadata than just delivery rules, e.g. > acquisition info). > > > OLD: > " > | HostIndex | A HostIndex object lists the Hostnames (and/or | > | | IP addresses) that an upstream CDN can provide | > | | CDNI Metadata for and the URIs to use for | > | | retrieving that CDNI Metadata. For example, if | > | | "example.com" is a content provider, the | > | | HostIndex object may include an entry for | > | | "example.com" with the URI of the associated | > | | HostMetadata object. These hostnames are | > | | contained inside a list of HostMatch objects. | > | HostMatch | A HostMatch object defines a hostname to match | > | | against a requested host, and contains or | > | | references a HostMetadata object which contains | > | | CDNI Metadata objects to be applied when a | > | | content request matches against the hostname. | > " > NEW: > " > | HostIndex | A HostIndex object lists HostMatch objects| > | HostMatch | A HostMatch object defines a hostname (and/or IP > addresses) to match | > | | against a requested host, and contains or | > | | references a HostMetadata object which contains | > | | CDNI Metadata objects to be applied when a | > | | request matches against the hostname. | > | | For example, if | > | | "example.com" is a content provider, a | > | | HostMatch object may include an entry for | > | | "example.com" with the URI of the associated | > | | HostMetadata object. > " > (Rationale: as currently written, I had a hard time follow the structure. > Because it first says that the HostIndex lists the hostnames and then > explains that those are actually contained inside HostMatch) > > > > > OLD: > " > | PathMatch | A PathMatch object defines a pattern to match | > | | against the requested path, and contains or | > " > NEW: > " > | PathMatch | A PathMatch object defines a pattern to match | > | | against the requested URI path, and contains or > | > " > > > > In Figure 1, I think it would help a bit if you indicated next to each > reference, the valid number of such references. > For example, from HostIndex to HostMatch it would say: " ---(0-N)--->" > From HostMatch to HostMetadata it would say :"---(1)-->" > > > OLD: > " > | GenericMetadata | A GenericMetadata object contains individual | > | | CDNI Metadata property objects which define the | > " > NEW: > " > | GenericMetadata | A GenericMetadata object contains individual | > | | CDNI Metadata objects which define the | > " > > > section 3.2, 1st and 2nd paragraph: > "serialization rules, etc.)": this is the first time "serialization" is > mentioned (and "deserialization" is then mentioned in 2nd paragraph). I > think this terms need some description. > > > section 3.2, 2nd & 3rd paragraph: > 2nd paragraph specifies behavior when property is not supported and > mandatory. > I think the third paragraph implies that when it is not mandatory then > whether or not it can be re-distributed in a cascaded CDNs scenario > depends on the specific "redistribution friendliness" of the object. If I > am correct then: > * you shoudl first indicate that when object is not understood and > not mandatory, the request can be served. > * and then explain that with respect to redistribution in case of > cascaded CDNs, here is the rule. > Have you considered using the term "Transitive" instead of "Redistributio= n > safety" (i.e. as used in BGP) (this would also impact text in section > 4.1.7)? > > > section 3.3. > You define precisely the scenarios where override happens. While implied, > it may be worth explicitly saying when inheritance happens. Something > like: > " > Objects of a given type previously defined by a parent object in > the tree are inherited when no object of the same type is defined by > the child object. > > " > And I'd suggest using your existing example to illustrate that also. So, > OLD: > " > GenericMetadata objects of a given type override all GenericMetadata > objects of the same type previously defined by any parent object in > the tree. For example, if HostMetadata for the host "example.com" > contains GenericMetadata objects of type LocationACL and > TimeWindowACL, while a PathMetadata object which applies to > "example.com/movies/*" defines an alternate GenericMetadata object of > type TimeWindowACL, The PathMetadata defined TimeWindowACL would > override the TimeWindowACL defined in the HostMetadata for all User > Agent requests for movies. > " > NEW: > " > GenericMetadata objects of a given type override all GenericMetadata > objects of the same type previously defined by any parent object in > the tree. Objects of a given type previously defined by a parent > object in > the tree are inherited when no object of the same type is defined by > the child object. > For example, if HostMetadata for the host "example.com" > contains GenericMetadata objects of type LocationACL and > TimeWindowACL, while a PathMetadata object which applies to > "example.com/movies/*" defines an alternate GenericMetadata object of > type TimeWindowACL, then: > * the TimeWindowACL defined in the PathMetadata would > override the TimeWindowACL defined in the HostMetadata > * the LocationACL defined in the HostMetadata would be inherited > for all User Agent requests for content under "example.com/movies". > " > > > OLD: > " > 3.3. Metadata Inheritance > " > NEW: > " > 3.3. Metadata Inheritance and Override > " > > > section 3.4. > While it is useful to provide an example of naming for vendor extensions, > it is a little confusing to only provide such an example. > I suggest you first include an example of Metadata Name actually specifie= d > by this document (e.g. "HostMetadata"?) and only then go into further > details for vendor extensions. > > > section 4.1.1: > OLD: > " > The HostIndex object is the entry point into the CDNI Metadata > hierarchy. An incoming content request is matched against the list > of hosts to find the HostMatch object which applies to the request. > " > NEW: > " > The HostIndex object is the entry point into the CDNI Metadata > hierarchy. It contains a list of HostMatch objects. An incoming reques= t > is matched against the hostname inside each of the listed HostMatch > objects to find the HostMatch object which applies to the request. > " > > section 4.1.2: > OLD: > " > The HostMatch object contains a hostname or IP address to match > against content requests. The HostMatch object references Metadata > objects to apply if a match is found. > " > NEW: > " > The HostMatch object contains a hostname or IP address to match > against content requests. The HostMatch object also contains a > reference to Metadata > objects to apply if a match is found. > " > > > section 4.1.2: > I think you need to specify behavior in case there are separate HostMatch > objects for a domain and one of its subdomain. e.g. "video.example.com" > and "premium.video.example.com". "first match applies" or "more specific > match"? > > > section 4.1.6: > "The three literals \ , * and ? should be escaped as \\, \* and \?" > why does "\" have to be escaped if it does not have ay special meaning > (like "*" and "?") ? > > > section 4.2.1: > " > Property: sources > ... > Mandatory-to-Specify: No. > " > So how would content be acquired in the absence of a "sources" property? > via some out-of-scope configuration? in any case, can you discuss your > assumptions here for how content would be acquired in that case? > > > section 4.2.1: > You need to indicate expected behavior when there are multiple sources > listed: is it in descending order of preference from viewpoint of dCDN? i= s > it left to the dCDN? something else? I would assume the 1st option. > > > section 4.2.1.1: > Since the sources property contains a list of sources, do we also need to > allow multiple endpoints within each source? > Is the targeted benefit to avoid replication when you have multiple > endpoints that can be used with the exact same auth and protocol > properties? > > > section 4.2.2: > " > LocationACL Metadata defines location-based restrictions. > Property: locations > " > Should the Property not be called "Property: locationACL"? > If not, does this not conflict with the "Property: locations" of section > 4.2.2.1? > > > section 4.2.2: > OLD: > " > A LocationRule contains or references a list of Location objects. > LocationRule objects are used to construct a LocationACL to apply > restrictions to content delivery. > " > NEW: > " > A LocationRule contains or references a list of Location objects and > the corresponding action. > " > (Note: the 2nd sentence is redundant with the description text in section > 4.2.2) > > > section 4.2.2.1: > " > Property: action > Description: Defines whether the rule specifies locations to > allow or deny. > Type: Enumeration [allow|deny] > Mandatory-to-Specify: Yes. > " > Why not specify a Default action and make this a "Mandatory-to-Specify: > No"? > > > section 4.2.2.2: > OLD: > " > A Location object describes a Location which may be applied by an > ACLRule, e.g. a Location may be an IPv4 address range or a geographic > location. > " > NEW: > " > A Location object describes a location which may be used as part of a > LocationRule, > e.g. a Location may be an IPv4 address range or a geographic > location. > " > > > section 4.2.3: > " > TimeWindowACL Metadata defines time-based restrictions. > Property: times > " > shoudl the Property not be named something like "Property: > TimeWindowACL"? > If not, does this not conflict with the "Property: times" of section > 4.2.3.1? > > > section 4.2.3.1: > OLD: > " > A TimeWindowRule contains or references a list of TimeWindow objects. > TimeWindowRule objects are used to construct a TimeWindowACL to apply > restrictions to content delivery. > " > NEW: > " > A TimeWindowRule contains or references a list of TimeWindow objects > and the corresponding action > " > > section 4.2.3.1: > " > Property: action > Description: Defines whether the rule specifies time windows to > allow or deny. > Type: Enumeration [allow|deny] > Mandatory-to-Specify: Yes. > " > Why not specify a Default action and make this a "Mandatory-to-Specify: > No"? > > > Table 3: > "Table 3: MIME Media Types for CDNI Metadata resources" > You have been using the terms of objects and properties before. Is > "resource" really the right term here? > > > > > > > Editorials: > =3D=3D=3D=3D=3D=3D=3D > > OLD: > " > [I-D.ietf-cdni-problem-statement] > " > NEW: > " > RFC 6707 > " > > > OLD: > " > are specified in [I-D.ietf-cdni-requirements] > " > NEW: > " > are specified in [I-D.ietf-cdni-requirements]. > " > > > OLD: > " > The proposed CDNI Metadata Interface aims to achieve the following design > principles: > " > NEW: > " > The CDNI Metadata Interface was designed to achieve the following > objectives: > " > > > OLD: > " > Deterministic mapping from content requests to CDNI metadata properties > " > NEW: > " > Deterministic mapping from content to CDNI metadata properties > " > OR > " > Deterministic mapping from redirection requests and content requests to > CDNI metadata properties > " > > > > OLD: > " > Different Hostnames and URI paths will contain different sets of CDNI > Metadata properties > " > NEW: > " > Different Hostnames and URI paths will be associated with different sets > of CDNI > Metadata properties > " > > > > OLD: > " > Property: pattern > Description: >A pattern for string matching. > " > NEW: > " > Property: pattern > Description: A pattern for string matching. > " > > > section 4.1.7: > OLD: > " > the the property > " > NEW: > " > the property > " > > > section 4.2.1 > OLD: > " > how to contact an uCDN Surrogate or an Origin Server. > " > NEW: > " > how to contact an uCDN Surrogate or an Origin Server in order to obtain > the content to be served. > " > > > section 4.2.1/4.2.1.1/4.2.2/4.2.2.1 > "Type: List of Source"/ "List of EndPoint"/"List of LocationRule"/"Type: > List of Location" > The singular after |list" reads off to me. I can see that those are objec= t > names, but still I would consider using plural (e.g. List of Sources") or > possibly something like "List of Source properties" > > > > > On 2 Oct 2012, at 19:40, Matt Caulfield (mcaulfie) wrote: > > > Hi everyone, > > > > We have posted the first revision of the Metadata Interface Draft which > was accepted as a WG doc in Vancouver: draft-ietf-cdni-metadata. > > > > Your comments and feedback are appreciated. > > > > Regards, > > Matt Caulfield > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Tuesday, October 02, 2012 1:35 PM > > To: Matt Caulfield (mcaulfie) > > Cc: ben@velocix.com; Kent Leung (kleung); kevin.ma@azukisystems.com; > rmurray@velocix.com; gwatson@velocix.com > > Subject: New Version Notification for draft-ietf-cdni-metadata-00.txt > > > > > > A new version of I-D, draft-ietf-cdni-metadata-00.txt has been > successfully submitted by Matt Caulfield and posted to the IETF > repository. > > > > Filename: draft-ietf-cdni-metadata > > Revision: 00 > > Title: CDN Interconnect Metadata > > Creation date: 2012-10-02 > > WG ID: cdni > > Number of pages: 35 > > URL: http://www.ietf.org/internet-drafts/draft-ietf-cdni- > metadata-00.txt > > Status: http://datatracker.ietf.org/doc/draft-ietf-cdni- > metadata > > Htmlized: http://tools.ietf.org/html/draft-ietf-cdni-metadata-00 > > > > > > Abstract: > > The CDNI Metadata Interface enables interconnected CDNs to exchange > > content distribution metadata in order to enable content acquisition > > and delivery. The CDNI metadata associated with a piece of content > > provides a downstream CDN with sufficient information for the > > downstream CDN to service content requests on behalf of an upstream > > CDN. This document describes both the core set of CDNI metadata and > > the protocol for exchanging that metadata. > > > > > > > > > > > > The IETF Secretariat > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni From gilles.bertrand@orange.com Mon Nov 5 07:22:11 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B8521F874B for ; Mon, 5 Nov 2012 07:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxMX1CzaMOMC for ; Mon, 5 Nov 2012 07:22:10 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 52D6521F8783 for ; Mon, 5 Nov 2012 07:22:10 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 38E78264257; Mon, 5 Nov 2012 16:22:07 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id C7B2A23806B; Mon, 5 Nov 2012 16:22:06 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Mon, 5 Nov 2012 16:22:06 +0100 From: To: ietfdbh , "cdni@ietf.org" Thread-Topic: [CDNi] I-D Action: draft-bertrand-cdni-logging-02.txt Thread-Index: AQHNsIdeEM+iFlLH4UChV+E4F+uWaZfFsqSAgBW60iA= Date: Mon, 5 Nov 2012 15:22:05 +0000 Message-ID: <6412_1352128926_5097D99E_6412_343_1_2AC63C9F27AF8446B0C064C50FC0A89306DC3608@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <20121022185902.22651.23401.idtracker@ietfa.amsl.com> <021501cdb09a$9da68300$d8f38900$@comcast.net> In-Reply-To: <021501cdb09a$9da68300$d8f38900$@comcast.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Subject: Re: [CDNi] I-D Action: draft-bertrand-cdni-logging-02.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:22:12 -0000 David, Thanks for your review of our draft.=20 1) We want the WG to discuss the choice of a Logging transport protocol for= non real-time information. Personally, I do not yet have a clear preferenc= e for a given transport protocol. We definitely need to identify the pro / = cons of the candidate protocols and I would like to invite the WG contribut= ors to share their technical arguments on the mailing list.=20 2) Please see 1) :-)=20 =20=20 3) Thanks for sharing these arguments.=20 To clarify the scope of the open technical questions: - I think there is consensus on the fact that the logging informati= on required by CDNs in the scope of CDNI in quite specific. So, we need to = define a Logging format. - There is no consensus for the moment on the choice of a Logging transp= ort protocol for non real-time information.=20 - The candidate protocols are: SNMPv3, Syslog, SSH File Transport, HTT= PS. Did I forget any relevant protocol? - Your point is that SNMPv3 and syslog (and any other candidate p= rotocol) must not be excluded without documenting technical reasons. I defi= nitely agree. Note that we want to have a clear separation between the logging applicatio= n layer (the format of the information) and the logging transport layer. So= , the WG may decide to support more than on logging transport protocol. Best regards, Gilles -----Message d'origine----- De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de i= etfdbh Envoy=E9=A0: lundi 22 octobre 2012 23:17 =C0=A0: cdni@ietf.org Cc=A0: David Harrington Objet=A0: Re: [CDNi] I-D Action: draft-bertrand-cdni-logging-02.txt Hi, I took a quick look at this document. I have a few comments. 1) While appendix C is yet to be written, the placeholders seem to already = poo-poo the candidates that are existing IETF standards, without documentin= g why they are not viable choices. 2) Appendix C2 references RFC6707, which states some conclusions that have = no documentation as to how the conclusions were reached. What are the scalability requirements for the CDNI logging interface?=20 RFC6707 states that there are "scalability concerns", but doesn't specify t= he requirements or the specific concerns.=20 There may be valid scalability concerns, but this deserves better documenta= tion than mere handwaving. Which scalability requirements are not possible to meet with SNMPv3? 3) RFC6707 states SNMP does not support guaranteed delivery of traps.=20 I am not sure how this conclusion was reached. SNMPv3 has Informs (acknowledged traps), which support application-level ac= knowledgement of receipt.=20 An SNMPv3 agent could continue to periodically send the Inform until it rec= eives acknowledgement of receipt. This would seem to mitigate the concern that use of SNMP "could result in l= og records being lost".=20 Note that SNMPv1 has been declared Historic, so shouldn't even be considere= d a candidate protocol for new usage.=20 Only version 3 of SNMP is recommended. That said, I would think that syslog [RFC5424] might be a better choice for= CDNI logging. It uses secure, reliable transport over TLS (RFC5425). Signed syslog messages [RFC5848] can be used by receivers to verify they ha= ve received all the messages sent to them. If messages are out-of-order or missing, the receiver can determine which r= ecords are missing and request they be resent. In addition, the signing can be applied to stored logs to verify they have = not been modified from the original message stream. If you are considering the RECOMMENDED versions of these candidate protocol= s, they might better meet the requirements. But the main point is that the consideration process should be documented m= ore clearly than this document (or RFC6707) does. David Harrington ietfdbh@comcast.net +1-603-828-1401 -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Monday, October 22, 2012 2:59 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-bertrand-cdni-logging-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : CDNI Logging Interface Author(s) : Gilles Bertrand Stephan Emile Roy Peterkofsky Francois Le Faucheur Pawel Grochocki Filename : draft-bertrand-cdni-logging-02.txt Pages : 43 Date : 2012-10-22 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 actual protocol for CDNI logging information exchange covering the information elements as well as the transport of those. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bertrand-cdni-logging There's also a htmlized version available at: http://tools.ietf.org/html/draft-bertrand-cdni-logging-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-bertrand-cdni-logging-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From kevin.ma@azukisystems.com Mon Nov 5 07:28:49 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A25D21F893F for ; Mon, 5 Nov 2012 07:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrYCrl+dbcpF for ; Mon, 5 Nov 2012 07:28:48 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id E6FD221F8833 for ; Mon, 5 Nov 2012 07:28:47 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id E244C5534ED; Mon, 5 Nov 2012 10:28:44 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 6FFD95533B0; Mon, 5 Nov 2012 10:28:44 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Mon, 5 Nov 2012 10:28:26 -0500 From: Kevin J Ma To: Ben Niven-Jenkins , "cdni@ietf.org" Date: Mon, 5 Nov 2012 10:28:44 -0500 Thread-Topic: [CDNi] Comments on draft-leung-cdni-uri-signing-01 Thread-Index: Ac25BkqoqqpxCfZqQy6zVTYE6uk28wCXhSJQ Message-ID: <291CC3F9E50E7641901A54E85D0977C6535F4FBD29@MAILR002.mail.lan> References: <91A268D8-34D3-4732-ACC2-37FF91E925ED@niven-jenkins.co.uk> In-Reply-To: <91A268D8-34D3-4732-ACC2-37FF91E925ED@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] Comments on draft-leung-cdni-uri-signing-01 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:28:49 -0000 Hi All, I agree with Ben's comments below. I think it would be helpful if the document focused more on a generic method to describe URI signing algorit= hms and better described the information that needs to be exchanged by CDNI. wrt CDNI Metadata, we could go simple, and just have a single integer val= ue that identifies an algorithms. The components of any given algorithm cou= ld be kept outside the scope of CDNI. If we want to describe the actual sch= eme, there are a few things that need to be distributed: 1) the query string argument names, e.g., VER/ET/CIP/KO/KN/HF/ALG/US 2) the allowed values for query string arguments for each field: VER/KO/K= N/ALG/HF - for CIP, is the dCDN expected to validate that a MAC is actually a M= AC or that and MEID is actually an MEID, etc? 3) key retrieval information 4) anything else? wrt CDN Capabilities, the capabilities would need to be much more than ju= st "I support signing" or "I support these fields", but would also need to b= e able to describe "I support these values for these fields"? Is it intended that a uCDN would be allowed to created a "cryptographical= ly equivalent" signing scheme for use when redirecting to the dCDN, if the d= CDN does not support the exact algorithm specified by the CP? If so, how? The security considerations mention some fundamental issues associated wi= th URL signing (i.e., spoofing, nats, long timeouts). Are we addressing tho= se issues here, or just looking at security issues related to exchanging CDN= I information required for doing signing, regardless of whether its a bad s= cheme? thanx. -- Kevin J. Ma > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Ben Niven-Jenkins > Sent: Friday, November 02, 2012 10:28 AM > To: cdni@ietf.org > Subject: [CDNi] Comments on draft-leung-cdni-uri-signing-01 >=20 > Kent, Francois, Matt, >=20 > From reading draft-leung-cdni-uri-signing-01 it appears to be trying to > outline what is required for CDN "URI Signing"/"Token authorisation" as > well as describing a particular "URI Signing" mechanism (that has a numbe= r > of significant drawbacks). >=20 > I'd suggest splitting these more explicitly into a more general discussio= n > on what the authorisation attributes that could/should be supported are, > what is needed on the other CDNI interfaces to support uri signing/token > authorisation and what the use cases are for different type of > signing/authorisation are e.g. is appending query parameters sufficient? >=20 > The draft could also describe a particular algorithm/mechanism but I thin= k > that should be in a later section or an appendix (or separate document) > rather than being placed in the middle of the document as it is currently= . >=20 > Ben >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From ggolovinsky@qualys.com Mon Nov 5 07:35:45 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D7821F9072 for ; Mon, 5 Nov 2012 07:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+YE+E8GBiry for ; Mon, 5 Nov 2012 07:35:44 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE4E21F87E7 for ; Mon, 5 Nov 2012 07:34:20 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id t11so311796qaa.10 for ; Mon, 05 Nov 2012 07:34:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:references:in-reply-to:mime-version:x-mailer:thread-index:date :message-id:subject:to:content-type:content-transfer-encoding :x-gm-message-state; bh=rzuYn4l/giRtFZYZD39PK0H2/nixuNUSbHOWypR6Gaw=; b=ThLtlXshewDbdLE32cZe+J5pPTfYC8kcM0kEKmyPz95ZJeaJhlKiCoqF+zrtYy+NAh uHATKA3BIc9Ta6Ix20vlOXIlzUEwQTJQFBXizFFM4z3s1er9cK6oOfV6p5CxU+gcaA5u 0pAIUGeFQHNfXqgVwYvYI83oR1+ApsCR6gWeHyHWYeLMV7EFXY1/F5UegJlCmgFbiRGS f8C73y7TzN6PzBh/sQ1ji/AqAdFOFa7NR4UKI+Fc0/T9M8YiBzilkIw/vu4Aa4IdIrkB NPgYRsmDUgrkvb9+b/lgL7Ox7MgLnBdlvgU3CnFwZTZO3QXEMyBYa1s257TCCUxomOVo 4OUw== Received: by 10.224.33.135 with SMTP id h7mr15183243qad.26.1352129660056; Mon, 05 Nov 2012 07:34:20 -0800 (PST) From: Gene Golovinsky References: <20121022185902.22651.23401.idtracker@ietfa.amsl.com> <021501cdb09a$9da68300$d8f38900$@comcast.net> <6412_1352128926_5097D99E_6412_343_1_2AC63C9F27AF8446B0C064C50FC0A89306DC3608@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <6412_1352128926_5097D99E_6412_343_1_2AC63C9F27AF8446B0C064C50FC0A89306DC3608@PEXCVZYM13.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKVJ5ZQVWRGZstnq+mhCPHo4nvoqgGnKhbSAow9U/SWKul78A== Date: Mon, 5 Nov 2012 07:34:18 -0800 Message-ID: To: gilles.bertrand@orange.com, ietfdbh , cdni@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkOC1nCnGNjgfG3XZgEOUitiVHCv2ImGRqWkYqldeUDyrZMFcGGQDTKLXKPaif++xwmj7Mk Subject: Re: [CDNi] I-D Action: draft-bertrand-cdni-logging-02.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:35:46 -0000 Hi. Some questions re usage of Syslog RFC 5424 were asked at the previous meeting. Then, were also raised on the list. I did not see a technical conversation about it. (May be I missed it). The same applies to SNMP Informs. I would too suggest that Syslog may be a better choice since it allows for easier extension and longer massages. The only argument I have heard against these two so far is that CDNi logs may be too long. Cheers. --Gene -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of gilles.bertrand@orange.com Sent: Monday, November 05, 2012 07:22 AM To: ietfdbh; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-bertrand-cdni-logging-02.txt David, Thanks for your review of our draft. 1) We want the WG to discuss the choice of a Logging transport protocol for non real-time information. Personally, I do not yet have a clear preference for a given transport protocol. We definitely need to identify the pro / cons of the candidate protocols and I would like to invite the WG contributors to share their technical arguments on the mailing list. 2) Please see 1) :-) 3) Thanks for sharing these arguments. To clarify the scope of the open technical questions: - I think there is consensus on the fact that the logging information required by CDNs in the scope of CDNI in quite specific. So, we need to define a Logging format. - There is no consensus for the moment on the choice of a Logging transport protocol for non real-time information. - The candidate protocols are: SNMPv3, Syslog, SSH File Transport, HTTPS. Did I forget any relevant protocol? - Your point is that SNMPv3 and syslog (and any other candidate protocol) must not be excluded without documenting technical reasons. I definitely agree. Note that we want to have a clear separation between the logging application layer (the format of the information) and the logging transport layer. So, the WG may decide to support more than on logging transport protocol. Best regards, Gilles -----Message d'origine----- De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de ietfdbh Envoy=E9=A0: lundi 22 octobre 2012 23:17 =C0=A0: cdni@ietf.org Cc= =A0: David Harrington Objet=A0: Re: [CDNi] I-D Action: draft-bertrand-cdni-logging-02.txt Hi, I took a quick look at this document. I have a few comments. 1) While appendix C is yet to be written, the placeholders seem to already poo-poo the candidates that are existing IETF standards, without documenting why they are not viable choices. 2) Appendix C2 references RFC6707, which states some conclusions that have no documentation as to how the conclusions were reached. What are the scalability requirements for the CDNI logging interface? RFC6707 states that there are "scalability concerns", but doesn't specify the requirements or the specific concerns. There may be valid scalability concerns, but this deserves better documentation than mere handwaving. Which scalability requirements are not possible to meet with SNMPv3? 3) RFC6707 states SNMP does not support guaranteed delivery of traps. I am not sure how this conclusion was reached. SNMPv3 has Informs (acknowledged traps), which support application-level acknowledgement of receipt. An SNMPv3 agent could continue to periodically send the Inform until it receives acknowledgement of receipt. This would seem to mitigate the concern that use of SNMP "could result in log records being lost". Note that SNMPv1 has been declared Historic, so shouldn't even be considered a candidate protocol for new usage. Only version 3 of SNMP is recommended. That said, I would think that syslog [RFC5424] might be a better choice for CDNI logging. It uses secure, reliable transport over TLS (RFC5425). Signed syslog messages [RFC5848] can be used by receivers to verify they have received all the messages sent to them. If messages are out-of-order or missing, the receiver can determine which records are missing and request they be resent. In addition, the signing can be applied to stored logs to verify they have not been modified from the original message stream. If you are considering the RECOMMENDED versions of these candidate protocols, they might better meet the requirements. But the main point is that the consideration process should be documented more clearly than this document (or RFC6707) does. David Harrington ietfdbh@comcast.net +1-603-828-1401 -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Monday, October 22, 2012 2:59 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-bertrand-cdni-logging-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CDNI Logging Interface Author(s) : Gilles Bertrand Stephan Emile Roy Peterkofsky Francois Le Faucheur Pawel Grochocki Filename : draft-bertrand-cdni-logging-02.txt Pages : 43 Date : 2012-10-22 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 actual protocol for CDNI logging information exchange covering the information elements as well as the transport of those. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bertrand-cdni-logging There's also a htmlized version available at: http://tools.ietf.org/html/draft-bertrand-cdni-logging-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-bertrand-cdni-logging-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni __________________________________________________________________________ _______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From ben@niven-jenkins.co.uk Mon Nov 5 07:49:24 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81AD21F87BB for ; Mon, 5 Nov 2012 07:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEYPh1AgDZib for ; Mon, 5 Nov 2012 07:49:23 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAC521F87A0 for ; Mon, 5 Nov 2012 07:49:22 -0800 (PST) Received: from dhcp-1123.meeting.ietf.org ([130.129.17.35]) by mail4.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1TVOvP-0007HH-UU; Mon, 05 Nov 2012 15:49:21 +0000 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Mon, 5 Nov 2012 15:49:15 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <166EBB70C264A9479E459B01B1BA6C920F404118@xmb-aln-x03.cisco.com> To: "Francois Le Faucheur (flefauch)" X-Mailer: Apple Mail (2.1085) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "draft-ietf-cdni-metadata@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] And one more comment from review of draft-ietf-cdni-metadata-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:49:24 -0000 Francois, On 31 Oct 2012, at 18:05, Francois Le Faucheur (flefauch) wrote: > As I just reviewed cdni-framework, I noticed the text in there (in = section "4.6. Metadata Interface") reflecting the earlier WG agreement = to allow the uCDN to enforce access control checks itself. And in = particular the following text: > " > As a consequence, the Metadata interface must provide a > means for the uCDN to express its desire to retain enforcement > for itself. For example, this might be done by including a "check > with me" flag in the metadata associated with certain content. > " > I believe this needs to be added to the set of metadata properties = currently specified. We have two possible scenarios here: 1) UCDN wants the DCDN to validate the content with the UCDN before = delivering - i.e. the equivalent of setting must-revalidate in HTTP = Cache-Control headers. 2) UCDN wants the DCDN to validate "the request" with the UCDN before = delivering, e.g. because the CP/UCDN is using a uri signing/token = authorisation mechanism the DCDN does not support (or where the DCDN may = not be trusted to enforce the token auth?). I think (2) is this case you & the framework are talking about. While = behaviour analogous to must-revalidate may address this requirement, I = think we should explore the requirements a bit more before we assume = that must-revalidate is a sufficient solution. =20 > When you specify its detailed semantics. I'd suggest that you indicate = that when the flag is set, the dCDN should perform the "check-with-uCDN" = after validation of access controls that are present inside metadata. Assuming we are talking about case (2) I think there are two things we = need to consider: A) Does 'check-with-uCDN' override any other metadata check or does = 'check-with-UCDN' add to existing metadata checks (i.e. content is only = delivered if the metadata access controls 'pass' *and* if the = 'check-with-uCDN' check 'passes'). B) The actual timing, e.g. is a DCDN required to perform metadata access = control checks first before performing any check-with-uCDN or whether = such checks can be performed in parallel (this might be crossing the = line into implementation detail). Ben =20 > In other words, I'd picture the "Check-with-uCDN" as something that = can be used "in addition" to access control rules that may be = distributed to dCDN and not "instead of". This way: > * if the uCDN wants to have full control, it does not advertise = any access control in CDNI metadata > * if the uCDN wants to delegate some simple validations (e.g. = time-window specific to a content range) and enforce on top of that some = finer-grain access control (e.g. per user), it can do so by advertising = simple access control in CDNI Metadata + "Check-with-me" flag. This = allows filtering of invalid requests (and possibly DOS attacks) in dCDN = and scales better. >=20 >=20 >=20 > On 26 Oct 2012, at 20:45, Matt Caulfield (mcaulfie) wrote: >=20 >> Thank you for the detailed comments, Francois.=20 >>=20 >> Hoping we can address both your first batch and second batch of = questions relatively soon. >>=20 >> Matt >>=20 >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Francois Le Faucheur (flefauch) >> Sent: Friday, October 26, 2012 12:59 PM >> To: draft-ietf-cdni-metadata@tools.ietf.org >> Cc: cdni@ietf.org >> Subject: [CDNi] Second batch of comments from review of = draft-ietf-cdni-metadata-00.txt >>=20 >> Hello, >>=20 >> Below are my second batch of comments (as an Individual). >> I hope this is useful. >>=20 >> Francois >>=20 >>=20 >>=20 >> General comments: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> * When used, MUST/SHOULD/MAY are used appropriately. But I recommend = you do a pass to verify that there is enough MUST to capture everything = that is mandatory for an implementation. For example, I am not sure = there is an explicit statement stating that all the objects/properties = listed in section 3 and 4 MUST be supported. >>=20 >> * You provide examples of both JSON and XML encoding, which is very = nice. I suggest you start driving a discussion on the list as to which = should be picked. Perhaps you could try list key pros&cons of each on = the list? >> When you have decided , you could then replace "example encodings" by = a specification of the encoding. >>=20 >>=20 >> Specific Comments/Suggestions >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> * Section 4.3.1 Link >> " >> A link object may be used in place of any of the objects described = above. >> " >> I think this should be replaced by: >> " >> A link object may be used in place of any of the objects or = properties described above. >> "=20 >> because for example in the Source object (Property: auth + Property: = endpoints + Property: protocol) each property (e.g. Protocol) can be = specified individually using a link. Is this right? >>=20 >>=20 >>=20 >> * section 4.3.2 Protocol: >> " >> This type only appears in Links.=20 >> " >> This is confusing because the Protocol type already appears in = multiple objects , for example in " >> 4.2.1.1. Source >> Property: auth >> Description: Authentication method to use when requesting >> content from this source. >> Type: Auth >> Mandatory-to-Specify: No. Default is no authentication is >> required. >> Property: endpoints >> Description: Origins from which the dCDN can acquire content. >> Type: List of EndPoint >> Mandatory-to-Specify: Yes. >> Property: protocol >> Description: Protocol to use for content acquisition. >> Type: Protocol >> Mandatory-to-Specify: Yes. >> " >> Assuming I understand what you want to do correctly, perhaps you = could call the type define din 4.3.2 with a different name e.g. = "ProtocolID" and this special type would only appear inside a Link. = Would that work? Or am I entirely missing what you want to do here? >>=20 >>=20 >> * section 4.3.2 Protocol: >> " >> The following examples are illustrative: >> o http://url.cdni.ietf.example/protocol/delivery/http/rfcABCD >> o http://url.cdni.ietf.example/protocol/delivery/rtmp/rfcEFGH >> o http://url.vendorY.ietf.example/protocol/delivery/rtmp/releaseP.Q >> " >> I think it would be useful to use a URI if that saved you from = managing an IANA register (e.g. because there exist a URI that = unambiguously points to the spec you want to reference e.g. = http://datatracker.ietf.org/doc/rfc2616/) but that will probably not = work with /rtmp/releaseP.Q. So what is the benefit of using a URI here = over defining an IANA register for these protocol IDs? >>=20 >>=20 >> * section 5: >> OLD: >> " >> The interface can be used by a Downstream CDN to retrieve CDNI >> Metadata objects either dynamically as required by the Downstream = CDN >> to process received requests (for example in response to receiving a >> CDNI Request Routing request from an Upstream CDN or in response to >> receiving a request for content from a User Agent) or in advance of >> being required. >> " >> NEW: >> " >> The interface can be used by a Downstream CDN to retrieve CDNI >> Metadata objects either dynamically as required by the Downstream = CDN >> to process received requests (for example in response to receiving a >> CDNI Request Routing request from an Upstream CDN or in response to >> receiving a request for content from a User Agent) or in advance of >> being required (for example in case of Pre-positioned CDNI Metadata = acquisition). >> " >>=20 >>=20 >> * section 5.2: >> OLD: >> " >> the HostIndex which >> provides the CDNI Metadata client with a list of Hostnames that the >> upstream CDN may delegate to the downstream CDN. >> " >> NEW: >> " >> the HostIndex which >> provides the CDNI Metadata client with a list of Hostnames for which = the >> upstream CDN may delegate content delivery to the downstream CDN. >> " >>=20 >>=20 >> * section 5.2: >> " >> The CDNI >> metadata client then makes a GET request for the URI specified in = the >> href key of that Host's entry in the HostIndex. >> " >> I have a couple of issue with that sentence: >> 1) the HostMetadata are found in the HostMatch entry for which = there was a match on the Host, so the text news tweaking. >> 2) while the HostMetadata may contain a href to the Metadata, I = think it could also actually contain the Metadata itself. If correct = then, you need to tweak text to discuss both options. If incorrect then, = you may need to tweak the text in section 4 that describes HostMatch. >> The same comment applies also to the following paragraph re = PathMetadata. >>=20 >>=20 >> *section 5.2: >> OLD: >> " >> When application level redirection (e.g. HTTP 302 redirects) is >> being used between CDNs, it is expected that the downstream CDN will >> be able to determine the upstream CDN that redirected a particular >> request from information contained in the received request (e.g. via >> the URI in case of HTTP redirection across CDNs). >> " >> NEW: >> " >> When application level redirection (e.g. HTTP 302 redirects) is >> being used between CDNs, it is expected that the downstream CDN will >> be able to determine the upstream CDN that redirected a particular >> request from information contained in the received request (e.g. via >> the URI). >> " >>=20 >> *section 5.2: >> OLD: >> " >> In the case of DNS redirection there is not sufficient information >> carried in the DNS request from User Agents to determine the = upstream >> CDN that redirected a particular request and therefore downstream >> CDNs may have to apply local policy when deciding which upstream >> CDN's metadata to apply. >> " >> NEW: >> " >> In the case of DNS redirection there is not always sufficient = information >> carried in the DNS request from User Agents to determine the = upstream >> CDN that redirected a particular request (e.g. when content from a = given host is redirected to a given downstream CDN by more than one = upstream CDN) and therefore downstream >> CDNs may have to apply local policy when deciding which upstream >> CDN metadata to apply. >> " >>=20 >>=20 >> *section5.3 Bootstrapping: >> OLD: >> " >> If the URI for the HostIndex object is not manually configured in = the >> downstream CDN then the HostIndex URI could be discovered via the >> CDNI Control interface. An upstream CDN would provide the URI of = the >> HostIndex object to the downstream CDN via the CDNI Control >> Interface. >> " >> NEW: >> " >> Mechanism allowing the downstream CDN to discover the URI of the = HostIndex are outside the scope of this document. >> " >> (Depending on the base protocol leveraged to support CDNI discovery = in the future, it may or may not be obvious that this would be = considered part of the Control Interface, so I recommend we don't try = second-guess future work and leave it open) >>=20 >>=20 >> OLD: >> " >> Table 3: MIME Media Types for CDNI Metadata resources >> " >> NEW: >> " >> Table 3: Example MIME Media Types for CDNI Metadata resources >> " >> (this is to make it clear that the table only contains a subset) >>=20 >>=20 >> section 5.4.2: >> " >> Dictionary keys in JSON are case sensitive and therefore any >> dictionary key defined by this document (for example the names of >> CDNI Metadata object properties) MUST always be represented in >> lowercase. >> " >> Are you saying that there was no choice and they had to be = represented in lower case (as suggested by "therefore") or are you = saying that we need to be case sensitive so to make it simpler you have = decided to make them all lower case and therefore they MUST be encoded = that way? If it is the former, please explain why. If it is the latter, = then adjust text. >>=20 >>=20 >> * section 5.5: >> " >> it is suggested that proprietary and/or custom property Metadata be >> identified by the "ext." >> " >> Why not make this a stronger statement i.e. that "ext" MUST be used = for any proprietary/custom extensions? >> Also, could we specify a rule to define the how to signal "the = organization defining the property Metadata" e.g. FQDN in reverse order = like ".com.companyA"? >>=20 >>=20 >>=20 >> * section 5.5.1: >> OLD: >> " >> Note: Ideally, uCDNs would not delegate content requests to a dCDN >> which does not support the Metadata=20 >> " >> NEW: >> " >> Note: Ideally, uCDNs would never delegate content requests to a dCDN >> which does not support the "mandatory-to-enforce" Metadata=20 >> " >>=20 >>=20 >> * section 5.5.1: >> OLD: >> " >> The dCDN >> MUST evaluate all Metadata >> " >> NEW: >> " >> This is why the dCDN >> MUST evaluate all Metadata >> " >>=20 >>=20 >> * section 5.5.2: >> " >> Note: Because Metadata is inherently ordered in GenericMetadata >> lists, as well as in the PathMetadata hierarchy and PathMatch lists, >> multiple conflicting Metadata types MAY be used, however, Metadata >> hierarchies MUST ensure that independent PathMatch root objects are >> used to prevent ambiguous or conflicting Metadata definitions. >> " >> I don't think the term PathMatch root object is well defined. I think = what you want to say is that it is OK to use conflicting metadata types = as long as they actually never apply to the same content. Right? It may = be simpler to express it that way. >>=20 >>=20 >> *Appendix A: >> OLD: >> " >> Requirements related to pre-positioning of metadata are not met >> directly by this document. Triggering metadata pre-positioning is >> beyond the scope of the CDNI Metadata interface. However, the >> interface as described by this document supports pulling metadata = on- >> demand for the purpose of pre-positioning. >> " >> NEW: >> " >> Requirements related to pre-positioning of metadata are met >> by this document on the assumption that other CDNI Interfaces are to = be used by the upstream CDN to trigger the pre-positioning of metadata = by the downstream CDN via the CDNI Metadata Interface.=20 >> " >>=20 >>=20 >> *Appendix A: >> I think it would be useful to discuss how requirement META-7 is met: >> " >> META-7 [HIGH] The CDNI Metadata Distribution interface shall allow >> the Upstream CDN to request addition and modification of >> CDNI Metadata into the Downstream CDN. >> " >>=20 >>=20 >> *Appendix A: >> OLD: >> " >> Requirement META-13 relating to feedback from the downstream CDN to >> the upstream CDN with respect to metadata >> " >> NEW: >> " >> Requirement META-13 relating to feedback from the downstream CDN to >> the upstream CDN with respect to rejected metadata >> " >>=20 >>=20 >> *Appendix A: >> OLD: >> " >> As an >> alternative, the downstream CDN may use the CDNI Logging interface = to >> convey error conditions related to metadata. >> " >> NEW: >> " >> As an >> alternative, the CDNI Logging interface could be extended to convey = error conditions related to metadata. >> " >>=20 >>=20 >> *Appendix A: >> " >> Requirement META-18 relating to surrogate cache behavior parameters >> is supported via extensibility. However, the example parameters in >> META-18 are not described in this document. >> " >> I know that META-18 is listed as [LOW] but I actually think that = supporting the "control of whether the query string of HTTP URI is to be = ignored by surrogate cache" is actually both useful and extremely simple = to add. Would you be willing to add a simple binary property indicating = whether query string is to be ignored or not? >> Interestingly, the Metadata was expected to include 3 types of info: = info related to acquisition, info related to authorizing, info related = to how to deliver: >> " >> Metadata properties >> describe how to acquire, authorize, and deliver content from a >> downstream CDN. >> " >> The Query String ignore property would be a good example of metadata = related to how to deliver. >>=20 >>=20 >>=20 >> Editorials: >> =3D=3D=3D=3D=3D=3D=3D >>=20 >> OLD: >> " >> are not intended impose >> " >> NEW: >> " >> are not intended to impose >> " >>=20 >>=20 >>=20 >> OLD: >> " >> document.Table 3 >> " >> NEW: >> " >> document. Table 3 >> " >>=20 >>=20 >> section 6: IANA >> OLD: >> " >> This document requests the registration of the "application/cdni" >> MIME type. >> " >> NEW: >> " >> This document requests the registration of the "application/cdni" >> MIME Media Type under the IANA MIME Media Type registry = (http://www.iana.org/assignments/media-types/index.html). >>=20 >>=20 >>=20 >> *section 5.5.2: >> OLD: >> " >> Metadata assigned to a given content asset >> " >> NEW: >> " >> Metadata assigned to a given content >> " >> (asset is not part of the CDNI terminology) >>=20 >>=20 >> Appendix A: >> OLD: >> " >> All metadata requirements are met either directly or indirectly by >> the CDNI Metadata Interface described in this document. The >> following paragraphs describe notable exceptions. >> " >> NEW: >> " >> All metadata requirements are met either directly or indirectly by >> the CDNI Metadata Interface described in this document, with the = clarifications or exceptions=20 >> described in the following paragraphs. >> " >>=20 >> OLD: >> " >> " >> NEW: >> " >> " >>=20 >>=20 >> OLD: >> " >> " >> NEW: >> " >> " >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From mcaulfie@cisco.com Mon Nov 5 07:54:52 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF1D21F885B for ; Mon, 5 Nov 2012 07:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EXn9xA3JQxz for ; Mon, 5 Nov 2012 07:54:51 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3B821F884F for ; Mon, 5 Nov 2012 07:54:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6867; q=dns/txt; s=iport; t=1352130888; x=1353340488; h=from:to:subject:date:message-id:mime-version; bh=m0hDvkD3G1QbwjXI1AKlEiM4SPiDT/+ZIbGYWwWIrPs=; b=gxCh+jLGVFEO1E7iTQLLgYuRxk5XcIGpX36g/aBYvjOOCMMY1pv/4D3j pTuJi2+TzPd75WJYBy77BjZk/oN0GxuFos9dwVWD3RdWjrz7pDUzeegwQ 0iANW1/wWR3IxjHhH53ChmzpX7zsKvLo9FOKrTZzj3d/l9/d7s1hZSony E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABPhl1CtJV2d/2dsb2JhbABEgknAcoEIgiABBBIBGl4BKlYmAQQbGodomWeBK59ukVxhA6RUgWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,715,1344211200"; d="scan'208,217";a="138924372" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 05 Nov 2012 15:54:33 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qA5FsXYc000901 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 5 Nov 2012 15:54:33 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 09:54:32 -0600 From: "Matt Caulfield (mcaulfie)" To: "cdni@ietf.org" Thread-Topic: CDNI Metadata Open Items Thread-Index: Ac27bdTYbY9vmmvwQs63Xn8iLcNm8Q== Date: Mon, 5 Nov 2012 15:54:31 +0000 Message-ID: <166EBB70C264A9479E459B01B1BA6C920F40DC83@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.76.207] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19340.004 x-tm-as-result: No--32.172400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_166EBB70C264A9479E459B01B1BA6C920F40DC83xmbalnx03ciscoc_" MIME-Version: 1.0 Subject: [CDNi] CDNI Metadata Open Items X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:54:52 -0000 --_000_166EBB70C264A9479E459B01B1BA6C920F40DC83xmbalnx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi everyone, On Wednesday I'll be presenting on the status of the CDNI Metadata Interfac= e. There are two main items I'd like to discuss following the presentation: 1) Base set of metadata - which metadata properties should be standardi= zed in draft-ietf-cdni-metadata? (vs. some other draft). 2) XML vs JSON - how should metadata be encoded? Any feedback on these questions, either in person on Wednesday or on the li= st, is appreciated. Thanks, Matt --_000_166EBB70C264A9479E459B01B1BA6C920F40DC83xmbalnx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi everyone,

 

On Wednesday I’ll be presenting on = the status of the CDNI Metadata Interface. There are two main items I’= ;d like to discuss following the presentation:

 

1)<= span style=3D"font:7.0pt "Times New Roman"">   &nb= sp; Base set of metadata – whic= h metadata properties should be standardized in draft-ietf-cdni-metadata? (= vs. some other draft).

2)<= span style=3D"font:7.0pt "Times New Roman"">   &nb= sp; XML vs JSON – how should me= tadata be encoded?

 

Any feedback on these questions, either i= n person on Wednesday or on the list, is appreciated.

 

Thanks,

Matt

--_000_166EBB70C264A9479E459B01B1BA6C920F40DC83xmbalnx03ciscoc_-- From kevin.ma@azukisystems.com Mon Nov 5 09:14:52 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C8A21F87D0 for ; Mon, 5 Nov 2012 09:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PD6ywLpkf00F for ; Mon, 5 Nov 2012 09:14:52 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id DDA0D21F8789 for ; Mon, 5 Nov 2012 09:14:45 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id D5D028BF3E4; Mon, 5 Nov 2012 12:14:43 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB028.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 488D78BF337; Mon, 5 Nov 2012 12:14:43 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB028.mail.lan ([10.110.17.28]) with mapi; Mon, 5 Nov 2012 12:14:35 -0500 From: Kevin J Ma To: "gilles.bertrand@orange.com" , "cdni@ietf.org" Date: Mon, 5 Nov 2012 12:14:41 -0500 Thread-Topic: New version of the CDNI Logging draft posted Thread-Index: AQHNsIhQpQ5EQkTRwk2UvYifo9SmxZfbjMTQ Message-ID: <291CC3F9E50E7641901A54E85D0977C6535F4FBDCC@MAILR002.mail.lan> References: <20121022185902.22651.23401.idtracker@ietfa.amsl.com> <11995_1350932778_5085992A_11995_9963_1_2AC63C9F27AF8446B0C064C50FC0A89306DA472F@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <11995_1350932778_5085992A_11995_9963_1_2AC63C9F27AF8446B0C064C50FC0A89306DA472F@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] New version of the CDNI Logging draft posted X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 17:14:53 -0000 Hi All, I had a couple questions about the logging config and the use of the cont= rol interface rather than the metadata interface for distributing the config. - Though the config is static, it may differ for different pieces of cont= ent? The metadata interface already includes provisions for apply properties= to specific sets of content based on URI path; logging could be a property= . - Though the filtering could occur higher up than the surrogates, is that going to be efficient? The surrogates would have to log all fields for the upstream filtering function to work. The extra metadata seems smal= l in comparison to the extra (unnecessary) logging data sent to the filte= r? Furthermore, if a CP wants an additional field (e.g., X-vendor-blah hea= der) that would need to be conveyed to the surrogates to be logged? thanx. -- Kevin J. Ma > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > gilles.bertrand@orange.com > Sent: Monday, October 22, 2012 3:06 PM > To: cdni@ietf.org > Subject: [CDNi] New version of the CDNI Logging draft posted >=20 > Folks, >=20 > We have submitted a new version of the CDNI logging draft: > URL: http://www.ietf.org/internet-drafts/draft-bertrand-cdni- > logging-02.txt > Status: http://datatracker.ietf.org/doc/draft-bertrand-cdni- > logging > Htmlized: http://tools.ietf.org/html/draft-bertrand-cdni-logging-0= 2 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-bertrand-cdni- > logging-02 >=20 > Best regards, >=20 > Gilles >=20 > -----Message d'origine----- > De=A0: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.or= g] > De la part de internet-drafts@ietf.org > Envoy=E9=A0: lundi 22 octobre 2012 20:59 > =C0=A0: i-d-announce@ietf.org > Objet=A0: I-D Action: draft-bertrand-cdni-logging-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : CDNI Logging Interface > Author(s) : Gilles Bertrand > Stephan Emile > Roy Peterkofsky > Francois Le Faucheur > Pawel Grochocki > Filename : draft-bertrand-cdni-logging-02.txt > Pages : 43 > Date : 2012-10-22 >=20 > 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 actual > protocol for CDNI logging information exchange covering the > information elements as well as the transport of those. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-bertrand-cdni-logging >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-bertrand-cdni-logging-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-bertrand-cdni-logging-02 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _________________________________________________________________________= _ > _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for > messages that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From kevin.ma@azukisystems.com Mon Nov 5 11:35:26 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F7A21F8673 for ; Mon, 5 Nov 2012 11:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LF+Oi692hc9 for ; Mon, 5 Nov 2012 11:35:26 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 085D121F862E for ; Mon, 5 Nov 2012 11:35:26 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 7472C416B79; Mon, 5 Nov 2012 14:36:36 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB028.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id CF9D0416B27; Mon, 5 Nov 2012 14:36:35 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB028.mail.lan ([10.110.17.28]) with mapi; Mon, 5 Nov 2012 14:35:15 -0500 From: Kevin J Ma To: Rob Murray , "cdni@ietf.org" Date: Mon, 5 Nov 2012 14:35:22 -0500 Thread-Topic: CDNI Triggers draft updated Thread-Index: AQHNht3+yZkQCIYO10Wuoi/OlOs1OJfcBrrg Message-ID: <291CC3F9E50E7641901A54E85D0977C6535F5DA9A3@MAILR002.mail.lan> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] CDNI Triggers draft updated X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 19:35:27 -0000 Hi Rob/Ben, A couple questions about the updated draft: - Is section 2.1 wrt purge/invalidate, are we saying that purge/invalidate takes precedence over pre-position when both are in the same request, i.e., pre-position always gets processed first, and a transit CDN must complete its own preposition and purge/invalidate before sending the preposition and purge/invalidate request to any cascaded dCDN? If, however, separate requests for pre-position and purge/invalidate=20 are used and the pre-position is only partially complete when the purge/invalidate comes in, the CDN may purge/invalidate a portion of the newly pre-positioned content, but the uCDN may not know which portion was purged after pre-positioning? Same goes for cascaded dCDNs= ? If so, then are we saying that if the uCDN wants to maintain the order of operations, it must wait for the trigger result from the pre-position before issuing the purge/invalidate? And that applies recursively to all cascaded dCDNs? - In section 4, when it talks about loops, wrt the much discussed diamond deployment, how would the proposed de-duplication schemes affect the no-loops requirement? The dCDN must ensure that activity triggered by uCDN only affects=09 metadata or content originating from that uCDN. Since only one CDN=09 can be authoritative for a given item of metadata or content, this=09 requirement means there cannot be any "loops" in trigger requests=09 between CDNs. thanx. -- Kevin J. Ma > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Rob Murray > Sent: Thursday, August 30, 2012 2:34 PM > To: cdni@ietf.org > Subject: [CDNi] CDNI Triggers draft updated >=20 > Hi all, >=20 > We've submitted an update to the CDNI Triggers draft dealing with comment= s > against the first version, we've not addressed open issues yet... >=20 > http://tools.ietf.org/html/draft-murray-cdni-triggers-01 >=20 >=20 > The main change in this version is to allow multiple trigger actions in a > single request, so that an invalidate/delete can be packaged with > prepopulate in order to replace content. >=20 > Open issues include: > - how to refer to content and metadata, including pattern matching for > invalidate/purge (depends on metadata draft) > - how to report failure (need to come up with error codes, and deal wit= h > partial failure) > - encoding may change to align with metadata and other interfaces >=20 > We'll continue to work on those things. >=20 > Best regards, > Rob. >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From Jan.Seedorf@neclab.eu Mon Nov 5 11:59:31 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E1221F87BF; Mon, 5 Nov 2012 11:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eQNMaTl2Fg5; Mon, 5 Nov 2012 11:59:30 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 58D1121F85AD; Mon, 5 Nov 2012 11:59:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id BD55310242B; Mon, 5 Nov 2012 20:59:29 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7x8GbGd0j7U; Mon, 5 Nov 2012 20:59:29 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id A61CD10242D; Mon, 5 Nov 2012 20:59:14 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.239]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 5 Nov 2012 20:59:14 +0100 From: Jan Seedorf To: "cdni-footprint@ietf.org" , "cdni@ietf.org" Thread-Topic: Room Info for CDNI Footprint / Capabilities Side Meeting @IETF-85 Thread-Index: Ac27j01D4KK4Z1mzTGmw7HGFCHvluA== Date: Mon, 5 Nov 2012 19:58:42 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE55384E65@DAPHNIS.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.197] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Ben Niven-Jenkins \(ben@velocix.com\)" Subject: [CDNi] Room Info for CDNI Footprint / Capabilities Side Meeting @IETF-85 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 19:59:31 -0000 Dear all, Reminder: there will be a side meeting regarding CDNI Footprint / Capabilit= ies here at IETF-85. The meeting will be: ** Tuesday, Nov 6th, 15:00-17:00 ** Room will be (thanks to Martin for organizing):=20 ** IESG Breakout Room, Location: IESG Office 202 ** I hope that all people interested in this can make it. I propose to first c= ontinue our latest discussion regarding capabilities, and then to spend som= e time on agreeing on the status quo, i.e. to establish a common view on wh= at we have found agreement on and what still the open issues are. This we c= an then present to the WG in the Thursday session. - Jan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jan Seedorf Senior Researcher NEC Europe Ltd., NEC Laboratories Europe, Network Division=A0=A0=A0=A0=A0 Kurfuerstenanlage 36, D-69115 Heidelberg Tel.=A0=A0=A0=A0 +49 (0)6221 4342-221 Fax:=A0=A0=A0=A0 +49 (0)6221 4342-155 e-mail:=A0 jan.seedorf@neclab.eu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014=20 From ietfdbh@comcast.net Mon Nov 5 10:36:34 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510DE21F893B for ; Mon, 5 Nov 2012 10:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kF8hP1sAvLZn for ; Mon, 5 Nov 2012 10:36:33 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3C821F8BEE for ; Mon, 5 Nov 2012 10:36:32 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta13.westchester.pa.mail.comcast.net with comcast id KseQ1k0091HzFnQ5Ducdh9; Mon, 05 Nov 2012 18:36:37 +0000 Received: from JV6RVH1 ([71.233.85.150]) by omta14.westchester.pa.mail.comcast.net with comcast id Kucb1k00q3Ecudz3aucc0A; Mon, 05 Nov 2012 18:36:36 +0000 From: "ietfdbh" To: References: <20121022185902.22651.23401.idtracker@ietfa.amsl.com> <021501cdb09a$9da68300$d8f38900$@comcast.net> <6412_1352128926_5097D99E_6412_343_1_2AC63C9F27AF8446B0C064C50FC0A89306DC3608@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Mon, 5 Nov 2012 13:36:31 -0500 Message-ID: <00ca01cdbb84$7a347db0$6e9d7910$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKVJ5ZQVWRGZstnq+mhCPHo4nvoqgGnKhbSAow9U/QBgSvQ8JYfAfpw Content-Language: en-us X-Mailman-Approved-At: Mon, 05 Nov 2012 13:08:00 -0800 Subject: Re: [CDNi] I-D Action: draft-bertrand-cdni-logging-02.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 18:36:34 -0000 Hi, How long are CDNI log messages expected to be? What are the requirements to be met in terms of confidentiality, = integrity checking, etc.? RFC5424 syslog deliberately does not hard-code the length. For interoperability, senders MUST support at least 2048, receivers = SHOULD support at least 8192 bytes. For usages that need larger message sizes, such as HIPPA audit logs, you = can use larger message sizes. However, each syslog sender/receiver/relay/application in the path to deliver that data would need to support these larger sizes to avoid truncation. SNMP is designed to support traps as alerts, and to support = trap-directed polling. Traps/Informs are typically small messages to alert the NMS on a timely basis to some condition; small alerts typically better meet operational alerting requirements. You typically do not send lots of data in a trap/inform. If there is a lot of information to be passed, a trap can be used to = tell the NMS something is available, and the NMS can then poll for the actual data (or use a different protocol to get the data). So, depending on what you plan to log, and the importance of timely reporting, traps/informs may or may not meet operational requirements. David Harrington ietfdbh@comcast.net +1-603-828-1401 -----Original Message----- From: Gene Golovinsky [mailto:ggolovinsky@qualys.com]=20 Sent: Monday, November 05, 2012 10:34 AM To: gilles.bertrand@orange.com; ietfdbh; cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-bertrand-cdni-logging-02.txt Hi. Some questions re usage of Syslog RFC 5424 were asked at the previous meeting. Then, were also raised on the list. I did not see a technical conversation about it. (May be I missed it). The same applies to SNMP Informs. I would too suggest that Syslog may be a better choice since it allows = for easier extension and longer massages. The only argument I have heard against these two so far is that CDNi = logs may be too long. Cheers. --Gene -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of gilles.bertrand@orange.com Sent: Monday, November 05, 2012 07:22 AM To: ietfdbh; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-bertrand-cdni-logging-02.txt David, Thanks for your review of our draft. 1) We want the WG to discuss the choice of a Logging transport protocol = for non real-time information. Personally, I do not yet have a clear = preference for a given transport protocol. We definitely need to identify the pro / cons of the candidate protocols and I would like to invite the WG contributors to share their technical arguments on the mailing list. 2) Please see 1) :-) 3) Thanks for sharing these arguments. To clarify the scope of the open technical questions: - I think there is consensus on the fact that the logging information required by CDNs in the scope of CDNI in quite specific. So, we need to define a Logging format. - There is no consensus for the moment on the choice of a Logging transport protocol for non real-time information. - The candidate protocols are: SNMPv3, Syslog, SSH File Transport, HTTPS. Did I forget any relevant protocol? - Your point is that SNMPv3 and syslog (and any other = candidate protocol) must not be excluded without documenting technical reasons. I definitely agree. Note that we want to have a clear separation between the logging = application layer (the format of the information) and the logging transport layer. = So, the WG may decide to support more than on logging transport protocol. Best regards, Gilles -----Message d'origine----- De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part = de ietfdbh Envoy=E9=A0: lundi 22 octobre 2012 23:17 =C0=A0: cdni@ietf.org = Cc=A0: David Harrington Objet=A0: Re: [CDNi] I-D Action: draft-bertrand-cdni-logging-02.txt Hi, I took a quick look at this document. I have a few comments. 1) While appendix C is yet to be written, the placeholders seem to = already poo-poo the candidates that are existing IETF standards, without = documenting why they are not viable choices. 2) Appendix C2 references RFC6707, which states some conclusions that = have no documentation as to how the conclusions were reached. What are the scalability requirements for the CDNI logging interface? RFC6707 states that there are "scalability concerns", but doesn't = specify the requirements or the specific concerns. There may be valid scalability concerns, but this deserves better documentation than mere handwaving. Which scalability requirements are not possible to meet with SNMPv3? 3) RFC6707 states SNMP does not support guaranteed delivery of traps. I am not sure how this conclusion was reached. SNMPv3 has Informs (acknowledged traps), which support application-level acknowledgement of receipt. An SNMPv3 agent could continue to periodically send the Inform until it receives acknowledgement of receipt. This would seem to mitigate the concern that use of SNMP "could result = in log records being lost". Note that SNMPv1 has been declared Historic, so shouldn't even be = considered a candidate protocol for new usage. Only version 3 of SNMP is recommended. That said, I would think that syslog [RFC5424] might be a better choice = for CDNI logging. It uses secure, reliable transport over TLS (RFC5425). Signed syslog messages [RFC5848] can be used by receivers to verify they have received all the messages sent to them. If messages are out-of-order or missing, the receiver can determine = which records are missing and request they be resent. In addition, the signing can be applied to stored logs to verify they = have not been modified from the original message stream. If you are considering the RECOMMENDED versions of these candidate protocols, they might better meet the requirements. But the main point is that the consideration process should be = documented more clearly than this document (or RFC6707) does. David Harrington ietfdbh@comcast.net +1-603-828-1401 -----Original Message----- From: i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Monday, October 22, 2012 2:59 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-bertrand-cdni-logging-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CDNI Logging Interface Author(s) : Gilles Bertrand Stephan Emile Roy Peterkofsky Francois Le Faucheur Pawel Grochocki Filename : draft-bertrand-cdni-logging-02.txt Pages : 43 Date : 2012-10-22 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 actual protocol for CDNI logging information exchange covering the information elements as well as the transport of those. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bertrand-cdni-logging There's also a htmlized version available at: http://tools.ietf.org/html/draft-bertrand-cdni-logging-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-bertrand-cdni-logging-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _________________________________________________________________________= _ _______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles = d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Mon Nov 5 15:34:03 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4F021F8748 for ; Mon, 5 Nov 2012 15:34:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ddJciIBqj8R for ; Mon, 5 Nov 2012 15:34:02 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5444021F8747 for ; Mon, 5 Nov 2012 15:33:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4927; q=dns/txt; s=iport; t=1352158436; x=1353368036; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oWS3flXD5UfrBDPK9RxaNU77ppxAO/Xuw3FOsADzTg8=; b=ja+GTd+yucfJcVQ/KIQerF012sS6DPpT5VC5i4rgreZaYCOaCCUNr+Mq bhv/UHzjHLaqcGI5+3fFe8BFTV8T/s+/TwR0NkWxcCzIiOvFNK8A1SEYZ T4lOUMkvdumx54DEa4nF1kkY6C2h/obN9Gr65ISZvoUve8RJNISoIr/QC E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKVLmFCtJXG9/2dsb2JhbABEwzSBCIIeAQEBAwEBAQEPARRHCxACASokJwslAgQOBQgBGYdiBgubAKAWi3yDe4F5YQOXF4oagyOBa4JiDYIZ X-IronPort-AV: E=Sophos;i="4.80,718,1344211200"; d="scan'208";a="139063137" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 05 Nov 2012 23:33:56 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA5NXthm028906 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 23:33:55 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 17:33:55 -0600 From: "Francois Le Faucheur (flefauch)" To: Wangdanhua Thread-Topic: Comments on draft-he-cdni-routing-request-redirection-03.txt Thread-Index: AQHNu64FXa+DAGW+oEeENGnPtIGCtQ== Date: Mon, 5 Nov 2012 23:33:55 +0000 Message-ID: References: <20121022030240.24155.12810.idtracker@ietfa.amsl.com> In-Reply-To: <20121022030240.24155.12810.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.65.46] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19340.004 x-tm-as-result: No--45.682400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <4FAC4DA33C97BF44AC848D26D34292DE@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] Comments on draft-he-cdni-routing-request-redirection-03.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 23:34:03 -0000 Hello, (As an Individual). In general, I feel this new version is going in the right direction. Some high level comments: * I think the spec should be less prescriptive as to how a dCDN builds its= redirection response. For example in section 6.1.1, the text says: "If the dCDN decides to use DNS Redirection, where the Downstream CDN is redirecting directly to a surrogate in the Downstream CDN: the Downstream CDN selects one or more surrogates and returns a CDNI RRRI response containing the IP addresses of the selected surrogate(s), ... If the dCDN decides to use DNS Redirection, where the Downstream CDN is redirecting to a Request Router in the dCDN: : the Downstream CDN returns a CDNI RRRI response containing a CNAME of the Downstream CDN's Request Router(s), =85 " In this example, I think the dCDN should be free to return an IP address or= a CNAME of the "redirection target" as it sees fit. The redirection target= may be a Surrogate, a Request Router, a set of Surrogates, a 3rd party CDN= Req Router, a 3rd party CDN Surrogate in case of cascaded CDNs,... whateve= r the dCDN sees fit. You could possibly mention one of the behavior above as an example of what = might happen, but it should just be an example and I recommend the spec be = open as to the logic to populate the Redirection response. * the document keeps talking about "encapsulating the enduser request" insi= de the Redirection Request. I find this misleading, because this is not abo= ut encapsulating the enduser request per-say, but rather to convey the key = attributes of the enduser request. * for HTTP, the Redirection Request should allow passing other attributes i= n addition to client IP address and URI. * the document requires that a pointer to Metadata be included in the Redir= ection request: "For DNS redirection, the uCDN also needs to provide in the CDNI RRRI request the a link to the associated CDNI Metadata for the host/ domain being requested." Considering that the latest Metadata interface allows the dCDN to walk down= the metadata tree for any content without seeding any initial info/pointer= s, I am not sure there is a benefit in passing a link to metadata inside th= e Redirection request. If would potentially save the dCDN Request Router to= do the lookup on Content-->Metadata , but would require the uCDN Request R= outer to do the same on its behalf. Besides the dCDN has to do that looup a= nyways to get the Metadata for serving the content. * the redirection interface will need to discuss handling of URI Signing=20 * we need to agree on a set of acronyms to refer to the "CDNI Request Routi= ng/Redirection Interface". I will bring that up during the meeting this wee= k. HTH Francois On 21 Oct 2012, at 23:02, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : Routing Request Redirection for CDN Interconnection > Author(s) : Wang Danhua (editor) > He Xiaoyan > Spencer Dawkins > Ge Chen > Ni Wei > Zhang Yunfei > Ben Niven-Jenkins > Filename : draft-he-cdni-routing-request-redirection-03.txt > Pages : 19 > Date : 2012-10-21 >=20 > Abstract: > The Request Routing Interface comprises of (1) the asynchronous > advertisement of footprint and capabilities by a downstream CDN that > allows a upstream CDN to decide whether to redirect particular user > requests to that downstream CDN; and (2) the synchronous operation of > an upstream CDN requesting whether a downstream CDN is prepared to > accept a user request and of a downstream CDN responding with how to > actually redirect the user request. This document describes an > interface for the latter part, i.e. the CDNI Request Routing > Redirection interface. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-he-cdni-routing-request-redirectio= n >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-he-cdni-routing-request-redirection-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-he-cdni-routing-request-redirect= ion-03 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From flefauch@cisco.com Mon Nov 5 15:34:12 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAD021F8748 for ; Mon, 5 Nov 2012 15:34:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.572 X-Spam-Level: X-Spam-Status: No, score=-9.572 tagged_above=-999 required=5 tests=[AWL=-1.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gisdSI9GNwqy for ; Mon, 5 Nov 2012 15:34:11 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 68DFE21F8747 for ; Mon, 5 Nov 2012 15:34:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9519; q=dns/txt; s=iport; t=1352158451; x=1353368051; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kBjhGzKa2MZ3YTjhm2j/NizHAK78uYE5xQTcGjn2IkQ=; b=UH2+BLQGLRly0XrJfGavgrZmfVfajX6LKaD1qI0NQUCC827FLuiVuRs7 fczlPYfUJmM8Hkaw+WViEuq8VhwWausuPCb8SUwKFRIRWejza/EF9K2+Y L3wOJBhf1D87M60sZGK4+dZ3Z4V7nTOcYTL08yeTbJDEwb4oxIyMnX25U 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUFAIFMmFCtJXHA/2dsb2JhbABEgkmDTqsqiQEBh3N9gQiCHwEBBBIBWQgFEAIBKiICAjAlAgQBDQ0TB4doC5p+jSIIkmyLfCCDW4FDNmEDkkgFhEqNPYFrgmINgVwfHg X-IronPort-AV: E=Sophos;i="4.80,718,1344211200"; d="scan'208,217";a="139082540" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 05 Nov 2012 23:33:57 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA5NXuRT019360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 23:33:56 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 17:33:56 -0600 From: "Francois Le Faucheur (flefauch)" To: ramki Krishnan , =?gb2312?B?s8K46g==?= , "Bhumip.Khasnabish@zte.com.cn" , "li.mian@zte.com.cn" Thread-Topic: Comments on Long Tail personalized content delivery over CDN Interconnections Thread-Index: AQHNu64FLac022V2MkGBV8RkMFDU+g== Date: Mon, 5 Nov 2012 23:33:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.65.46] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19340.004 x-tm-as-result: No--46.984100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D202253xmbrcdx10ciscocom_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] Comments on Long Tail personalized content delivery over CDN Interconnections X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 23:34:12 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D202253xmbrcdx10ciscocom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCihBcyBhbiBpbmRpdmlkdWFsKToNCg0KSSB3YXMgc3RpbGwgdmVyeSB1bmNsZWFy IG9uIHdoZXRoZXIgdGhlcmUgaXMgYSByZWFsIGlzc3VlIHRvIHNvbHZlIGhlcmU6DQoqIHRoaXMg c2VlbXMgdG8gc3VnZ2VzdCBhIGxvbmcgY2hhaW4gb2YgZXZlbnQgd2hvc2UgbmV0IHJlc3VsdCBp cyB0byBlbnN1cmUgdUNETiBkb2VzIG5vdCByZWRpcmVjdCBsb25nIHRhaWwgY29udGVudCB0byBk Q0ROIChpLmUuIGRDRE4gcGVyZm9ybXMgc29tZSBkaXN0cmlidXRlZCBjb250ZW50IHRyYWNraW5n LCBhcHBsaWVzIG9uZSBhbmFseXNpcywgdGhlbiBzaWduYWxzIHRvIHVDRE4gdG8gbm90IHJlZGly ZWN0KSB3aGlsZSB0aGUgdUNETiBpcyBhY3R1YWxseSBpbiBhIGZhaXJseSBnb29kIHBvc2l0aW9u IGluIHRoZSBmaXJzdCBwbGFjZSB0byBkZWNpZGUgdG8gbm90IHJlZGlyZWN0IGNvbnRlbnQgdW50 aWwgaXQgaXMgZGVlbWVkIHBvcHVsYXINCiogdGhpcyBzZWVtcyB0byBlcXVhdGUgdGhlIGZhY3Qg dGhhdCBhIHJlcXVlc3QgaXMgcmVkaXJlY3QgdG8gdGhlIGRDRE4gd2l0aCB0aGUgZmFjdCB0aGF0 IHRoZSBjb250ZW50IGlzIG5lY2Vzc2FyaWx5IGNvbnN1bWluZyB2YWx1YWJsZSBzdG9yaW5nIHJl c291cmNlcyBpbiB0aGUgZENETi4gVGhlcmUgYXJlIGEgbG90IG9mIHNtYXJ0IHRoaW5ncyB0aGUg ZENETiBjYW4gZG8gdG8gbWFuYWdlIHN0b3JhZ2Ugc3BhY2UgZWZmaWNpZW50bHkgKGUuZy4gc3Rv cmUgYnV0IGRpc2NhcmQgaWYgY29udGVudCBpbiBub3QgcG9wdWxhciBhbmQgc3RvcmFnZSBpcyBu ZWVkZWQgLWFrYSBsb3cgcG9wdWxhcml0eSBldmljdGlvbiwgbm90IHN0b3JlIG9uIGZpcnN0IG9j Y3VycmVuY2UsIHJlZGlyZWN0IGxvbmcgdGFpbCBjb250ZW50IHRvIGEgc21hbGxlciBzZXQgb2Yg Y2FjaGVzIC4uKS4NClNvIEkgYW0gbm90IGNvbnZpbmNlZCB0aGVyZSBpcyBtdWNoIGJlbmVmaXRz IHRvIGJlIGdhaW5lZCBhdCBhbGwgb3ZlciBhIHNvbHV0aW9uIGNvbWJpbmluZyBzbWFydCByZXJv dXRpbmcgbG9naWMgaW4gdUNETiBhbmQgc21hcnQgY2FjaGluZyBpbiBkQ0ROLg0KDQpJIGFtIG5v dCBzdXJlIHRoZSBwcm9wb3NlZCB0ZWNobmlxdWUgYWRkcmVzc2VzIGFsbCBzaXR1YXRpb25zLiBG b3IgZXhhbXBsZSwgbGV0J3Mgc2F5IHRoYXQgdGhlIGRDRE4gZGV0ZXJtaW5lcyBhdCBzb21lIHN0 YWdlIHRoYXQgYSBnaXZlbiBjb250ZW50IGlzIG5vdCBwb3B1bGFyIGFuZCBjb21tdW5pY2F0ZXMg dGhpcyB0byB1Q0ROIHdobyBzdG9wcyByZWRpcmVjdGluZyB0byBkQ0ROLiBCdXQgdGhlbiB0aGUg Y29udGVudCBiZWNvbWVzIHBvcHVsYXIgYWdhaW4uIFNpbmNlIHRoZSBkQ0ROIG5ldmVyIHJlY2Vp dmVzIGNvcnJlc3BvbmRpbmcgcmVxdWVzdCwgaXQgY2Fubm90IGRldGVybWluZSB0aGF0IHRoZSBj b250ZW50IGlzIG5vdyBwb3B1bGFyIGFuZCBjYW5ub3Qgc2lnbmFsIHRvIHRoZSB1Q0ROIHRvIHJl c3RhcnQgcmVkaXJlY3RpbmcgcmVxdWVzdCB0byBkQ0ROLiBJZiB5b3UgYXNzdW1lIHRoYXQgdGhl IHVDRE4gaXMgbWFydCBlbm91Z2ggdG8ga2VlcCB0cmFjayBvZiB3aGF0IGlzIHBvcHVsYXIgb3Ig bm90LCB0aGVuIGl0IG1heSBhcyB3ZWxsIHNpbXBseSB1c2UgdGhhdCBpbiB0aGUgZmlyc3QgcGxh Y2UgdG8gZGVjaWRlIHdoZW4gdG8gcmVkaXJlY3QgKG9yIG5vdCkgdG8gdGhlIGRDRE4gYW5kIHdl IGRvIG5vdCBuZWVkIGFueSBleHRyYSBtZWNoYW5pc20uDQoNCkkgYW0gdmVyeSB1bmNsZWFyIG9u IHdoZXRoZXIgdGhlIHByb3Bvc2VkIHNvbHV0aW9uIGFjdHVhbGx5IGZpdHMgdGhlIENETkkgZnJh bWV3b3JrLjoNClRoZSBkb2N1bWVudCBzZWVtcyB0byBhc3N1bWUgYSBkaWZmZXJlbnQgbW9kZWwg dG8gaG93IHRoZSBDRE5JIFdvcmtpbmcgR3JvdXAgc3BlY3MgYXJlIHNoYXBpbmcgdXAuDQpGb3Ig ZXhhbXBsZSwgaXQgc2F5czoNCiJNZXRhZGF0YSBpbnRlcmZhY2UgcmVxdWlyZW1lbnQNCiAgICAg VGhlIENETkkgTWV0YWRhdGEgRGlzdHJpYnV0aW9uIGludGVyZmFjZSBzaGFsbCBwcm92aWRlIGlu ZGljYXRpb24NCiAgICAgYnkgdGhlIGRDRE4gdG8gdGhlIHVDRE4gd2hldGhlciB0aGUgY29udGVu dCBzaG91bGQgYmUgY2FjaGVkIG9yDQogICAgIG5vdCBjYWNoZWQgaW4gdGhlIGRDRE4uIFRoaXMg aW5mb3JtYXRpb24gc2hvdWxkIGJlIG9uIGEgcGVyIFVSTA0KICAgICBiYXNpcy4gVGhlIGRlZmF1 bHQgYmVoYXZpb3Igd291bGQgYmUgdG8gY2FjaGUgdGhlIGNvbnRlbnQgaW4gdGhlDQogICAgIGRD RE4iDQp3aGlsZSB0aGUgQ0ROSSBNZXRhZGF0YSBpbnRlcmZhY2UgYWxsb3dzIHRvIGRpc3RyaWJ1 dGUgbWV0YWRhdGEgaW4gdGhlIG9wcG9zaXRlIGRpcmVjdGlvbiAoaS5lLiB1Q0ROIHByb3ZpZGVz IGluZm8gdG8gZENETikuDQpJIHJlY29tbWVuZCB5b3UgcmV2aWV3IG1vcmUgY2FyZWZ1bGx5IHRo ZSBGcmFtZXdvcmsgYW5kIE1ldGFkYXRhIGRvY3VtZW50cy4NCg0KQ2hlZXJzDQoNCkZyYW5jb2lz DQoNCk9uIDggU2VwIDIwMTIsIGF0IDEwOjM1LCByYW1raSBLcmlzaG5hbiB3cm90ZToNCg0KQWxs LA0KDQpUaGFua3MgZm9yIHRoZSBjb21tZW50cyBzbyBmYXIuIEEgbGF0ZXN0IHZlcnNpb24gb2Yg dGhlIGRyYWZ0IGlzIHBvc3RlZCBhdGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQta3Jpc2huYW4tY2RuaS1sb25nLXRhaWwvLiBLaW5kbHkgcmV2aWV3IGFuZCBjb21tZW50Lg0K DQp0aGFua3MsIHJhbWtpDQoNCg== --_000_FC236DA6F2DA77449EF2D02DF4471A8D202253xmbrcdx10ciscocom_ Content-Type: text/html; charset="gb2312" Content-ID: Content-Transfer-Encoding: quoted-printable Hello,

(As an individual):

I was still very unclear on whether there is a real issue to solve her= e:
* this= seems to suggest a long chain of event whose net result is to ensure uCDN = does not redirect long tail content to dCDN (i.e. dCDN performs some distri= buted content tracking, applies one analysis, then signals to uCDN to not redirect) while the uCDN is actually= in a fairly good position in the first place to decide to not redirect con= tent until it is deemed popular
* this= seems to equate the fact that a request is redirect to the dCDN with the f= act that the content is necessarily consuming valuable storing resources in= the dCDN. There are a lot of smart things the dCDN can do to manage storage space efficiently (e.g. stor= e but discard if content in not popular and storage is needed -aka low popu= larity eviction, not store on first occurrence, redirect long tail con= tent to a smaller set of caches ..). 
So I am not convinced there is much benefits to be gained at all over = a solution combining smart rerouting logic in uCDN and smart caching in dCD= N.

I am not sure the proposed technique addresses all situations. For exa= mple, let's say that the dCDN determines at some stage that a given content= is not popular and communicates this to uCDN who stops redirecting to dCDN= . But then the content becomes popular again. Since the dCDN never receives corresponding request, it cannot dete= rmine that the content is now popular and cannot signal to the uCDN to rest= art redirecting request to dCDN. If you assume that the uCDN is mart enough= to keep track of what is popular or not, then it may as well simply use that in the first place to decide w= hen to redirect (or not) to the dCDN and we do not need any extra mechanism= .

I am very unclear on whether the proposed solution actually fits the C= DNI framework.:
The document seems to assume a different model to how the CDNI Working= Group specs are shaping up. 
For example, it says:
"Metadata interface requirement
     The CDNI Metadata Distribution interface shall pro= vide indication
     by the dCDN to the uCDN whether the content should= be cached or
     not cached in the dCDN. This information should be= on a per URL
     basis. The default behavior would be to cache the = content in the
     dCDN"
while the CDNI Metadata interface allows to distribute metadata in the= opposite direction (i.e. uCDN provides info to dCDN).
I recommend you review more carefully the Framework and Metadata docum= ents.

Cheers

Francois

On 8 Sep 2012, at 10:35, ramki Krishnan wrote:

All,
 =
Thanks for the comments = so far. A latest version of the draft is posted athttp://datat= racker.ietf.org/doc/draft-krishnan-cdni-long-tail/. Kindly review and comment.
 =
thanks, ramki=

--_000_FC236DA6F2DA77449EF2D02DF4471A8D202253xmbrcdx10ciscocom_-- From ben@niven-jenkins.co.uk Tue Nov 6 07:25:31 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C57421F8914 for ; Tue, 6 Nov 2012 07:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGD+WLDgRwYl for ; Tue, 6 Nov 2012 07:25:30 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id DA06121F893B for ; Tue, 6 Nov 2012 07:25:29 -0800 (PST) Received: from dhcp-1123.meeting.ietf.org ([130.129.17.35]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1TVl1r-00016I-R4; Tue, 06 Nov 2012 15:25:28 +0000 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Ben Niven-Jenkins In-Reply-To: Date: Tue, 6 Nov 2012 15:25:14 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3F5BB382-1292-4EE4-8621-52C7C5097ACC@niven-jenkins.co.uk> References: <20121022030240.24155.12810.idtracker@ietfa.amsl.com> To: Francois Le Faucheur (flefauch) X-Mailer: Apple Mail (2.1085) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Comments on draft-he-cdni-routing-request-redirection-03.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 15:25:31 -0000 Francois, Please see below for my views. On 5 Nov 2012, at 23:33, Francois Le Faucheur (flefauch) wrote: > Hello, >=20 > (As an Individual). >=20 > In general, I feel this new version is going in the right direction. >=20 > Some high level comments: >=20 > * I think the spec should be less prescriptive as to how a dCDN = builds its redirection response. For example in section 6.1.1, the text = says: > "If the dCDN decides to use DNS Redirection, where the Downstream CDN > is redirecting directly to a surrogate in the Downstream CDN: the > Downstream CDN selects one or more surrogates and returns a CDNI = RRRI > response containing the IP addresses of the selected surrogate(s), = ... > If the dCDN decides to use DNS Redirection, where the Downstream CDN > is redirecting to a Request Router in the dCDN: : the Downstream CDN > returns a CDNI RRRI response containing a CNAME of the Downstream > CDN's Request Router(s), =85 > " > In this example, I think the dCDN should be free to return an IP = address or a CNAME of the "redirection target" as it sees fit. The = redirection target may be a Surrogate, a Request Router, a set of = Surrogates, a 3rd party CDN Req Router, a 3rd party CDN Surrogate in = case of cascaded CDNs,... whatever the dCDN sees fit. > You could possibly mention one of the behavior above as an example of = what might happen, but it should just be an example and I recommend the = spec be open as to the logic to populate the Redirection response. Fair comment. Describing the different redirection possibilities & their = applicability while at the same time talking about CDNI Redirection in a = more generic way (so we don't keep repeating all the different nuances) = was something we struggled a little with and is certainly an area of the = draft (IMO) that needs more work to make the text clearer etc. I like your idea of a 'redirection target' and maybe the right approach = is to have a section defining/discussing the possibilities for = redirection (A/AAAA/CNAME/Application level 302/etc) to a 'redirection = target' in a dCDN and in the rest of the document just talk generically = about redirection targets? =20 > * the document keeps talking about "encapsulating the enduser request" = inside the Redirection Request. I find this misleading, because this is = not about encapsulating the enduser request per-say, but rather to = convey the key attributes of the enduser request. Fair comment. We used 'encapsulating end user request' to distinguish = between previous versions of the draft where the end user request was = proxied to a dCDN via the same protocol that the end user request was = made over. Going forward that history doesn't matter and we should use better = language to describe what we are actually doing. =20 > * for HTTP, the Redirection Request should allow passing other = attributes in addition to client IP address and URI. The draft currently just tries to define the minimum necessary = information for a dCDN to be able to perform a redirection. There are = probably other attributes that the dCDN would find useful and although = it is not explicitly described in the current draft I think the CDNI = Redirection 'protocol framework' in draft-he easily allows passing = additional optional attributes. Describing how to extend the 'base = protocol' with additional attributes is certainly something we should = add in a future revision of the draft. Personally, I am reluctant to define lots of theoretical attributes = (that no one ends up using) to be included in a CDN Redirection request = but I would like to hear views from implementors on the attributes they = actually use (or plan to use as part of CDNI) to influence surrogate = selection/redirection across a CDN interconnect. > * the document requires that a pointer to Metadata be included in the = Redirection request: > "For DNS redirection, the uCDN also needs to provide in the CDNI RRRI > request the a link to the associated CDNI Metadata for the host/ > domain being requested." > Considering that the latest Metadata interface allows the dCDN to walk = down the metadata tree for any content without seeding any initial = info/pointers, I am not sure there is a benefit in passing a link to = metadata inside the Redirection request. If would potentially save the = dCDN Request Router to do the lookup on Content-->Metadata , but would = require the uCDN Request Router to do the same on its behalf. Besides = the dCDN has to do that looup anyways to get the Metadata for serving = the content. This is in my slides for Thursday. When I was thinking about CDN = Redirection a while ago I convinced myself a link to CDNI Metadata was = useful so when I started working on draft-he I included it, but since = then I've been struggling to remind myself why I originally thought it = was required so I'm certainly open to removing it. > * the redirection interface will need to discuss handling of URI = Signing=20 Sure. Personally I'd like the uri signing/token authorisation work in = the WG to mature a bit more first just to avoid having to keep draft-he = aligned with a still moving target. At a minimum we should include in the next revision a comment that we = still need to factor token authorisation into the document. > * we need to agree on a set of acronyms to refer to the "CDNI Request = Routing/Redirection Interface". I will bring that up during the meeting = this week. OK Ben >=20 > HTH >=20 > Francois >=20 >=20 > On 21 Oct 2012, at 23:02, > wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >>=20 >> Title : Routing Request Redirection for CDN = Interconnection >> Author(s) : Wang Danhua (editor) >> He Xiaoyan >> Spencer Dawkins >> Ge Chen >> Ni Wei >> Zhang Yunfei >> Ben Niven-Jenkins >> Filename : = draft-he-cdni-routing-request-redirection-03.txt >> Pages : 19 >> Date : 2012-10-21 >>=20 >> Abstract: >> The Request Routing Interface comprises of (1) the asynchronous >> advertisement of footprint and capabilities by a downstream CDN that >> allows a upstream CDN to decide whether to redirect particular user >> requests to that downstream CDN; and (2) the synchronous operation = of >> an upstream CDN requesting whether a downstream CDN is prepared to >> accept a user request and of a downstream CDN responding with how to >> actually redirect the user request. This document describes an >> interface for the latter part, i.e. the CDNI Request Routing >> Redirection interface. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-he-cdni-routing-request-redirection= >>=20 >> There's also a htmlized version available at: >> = http://tools.ietf.org/html/draft-he-cdni-routing-request-redirection-03 >>=20 >> A diff from the previous version is available at: >> = http://www.ietf.org/rfcdiff?url2=3Ddraft-he-cdni-routing-request-redirecti= on-03 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From kleung@cisco.com Tue Nov 6 09:31:30 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E5821F8951 for ; Tue, 6 Nov 2012 09:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZfe5Ku-UHqH for ; Tue, 6 Nov 2012 09:31:29 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C7BC321F8996 for ; Tue, 6 Nov 2012 09:31:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2522; q=dns/txt; s=iport; t=1352223090; x=1353432690; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=zWwLuPL5Nm5L1/LlYgf05oJdYnhGSzRrPIqZhmt3Ujc=; b=famfPiHDyqaUAavjxyExy0wXkIyhFHP6N+I3x23NRFXvjX5bFIf4Y/5u jePzJCz2CbZTow7YgL9UBctr9KBK1qaO0Cpo2nYCHsP3kIeJOEyiNjlEK JQsXq1cbQqfkK57iFfvzqxaAMpJ0hz+XtJAtHbFyZul0tIxSvpOJWOmNw g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIZImVCtJXHB/2dsb2JhbABEwy+BCIIeAQEBBAEBAQ8BJzQXBAIBCBEEAQELFAkHJwsUCQgCBAESCBqFboF6C5wNj2SQSQSMAwqFamEDpFSBa4JvgV0HFwYY X-IronPort-AV: E=Sophos;i="4.80,722,1344211200"; d="scan'208";a="139384592" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 06 Nov 2012 17:31:29 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qA6HVTuL016572 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Nov 2012 17:31:29 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Tue, 6 Nov 2012 11:31:29 -0600 From: "Kent Leung (kleung)" To: Ben Niven-Jenkins , "cdni@ietf.org" Thread-Topic: [CDNi] Comments on draft-leung-cdni-uri-signing-01 Thread-Index: AQHNuQZH4emGLIFqKkGB8eC+X8aPW5fdBTyA Date: Tue, 6 Nov 2012 17:31:28 +0000 Message-ID: References: <91A268D8-34D3-4732-ACC2-37FF91E925ED@niven-jenkins.co.uk> In-Reply-To: <91A268D8-34D3-4732-ACC2-37FF91E925ED@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.78.196] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19344.002 x-tm-as-result: No--41.858800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] Comments on draft-leung-cdni-uri-signing-01 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 17:31:30 -0000 Hi Ben. Thanks for the feedback. I agree that the draft attempts to document both the general purpose and th= e specifics of a scheme. The original intent was specifying the details for= interoperability. But it's better that we start with a general discussion. Here's what I think should be in the generic set of information that need t= o be passed between CDNs: o Version - Identifier of the version of URI signing method with its se= t of capabilities. o Expiry Time - Time duration when signed URI remains valid o Client IP - IP address of the client that has access to the content o Key Index - Index to the key used to validate the URI signature o Hash Function - Identifier of the hash algorithm (e.g. "MD5", "SHA1= ") used by HMAC o Algorithm - Identifier of the algorithm used to compute the URI sign= ature o Client ID - Identifier of the client provided by the CSP o Access to content is subject to URI validation or not indication o Logging should provide indication of URI validation enforcement=20 The information can be conveyed via URI query component or CDNI interfaces.= The attributes that are appended to the query string may be a subset of th= e list.=20 Kent -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben= Niven-Jenkins Sent: Friday, November 02, 2012 7:28 AM To: cdni@ietf.org Subject: [CDNi] Comments on draft-leung-cdni-uri-signing-01 Kent, Francois, Matt, >From reading draft-leung-cdni-uri-signing-01 it appears to be trying to out= line what is required for CDN "URI Signing"/"Token authorisation" as well a= s describing a particular "URI Signing" mechanism (that has a number of sig= nificant drawbacks). I'd suggest splitting these more explicitly into a more general discussion = on what the authorisation attributes that could/should be supported are, wh= at is needed on the other CDNI interfaces to support uri signing/token auth= orisation and what the use cases are for different type of signing/authoris= ation are e.g. is appending query parameters sufficient? The draft could also describe a particular algorithm/mechanism but I think = that should be in a later section or an appendix (or separate document) rat= her than being placed in the middle of the document as it is currently. Ben _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From kleung@cisco.com Tue Nov 6 09:45:32 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9973721F8A0B for ; Tue, 6 Nov 2012 09:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YA2sBxfuHi5w for ; Tue, 6 Nov 2012 09:45:29 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 763FA21F87F2 for ; Tue, 6 Nov 2012 09:45:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4884; q=dns/txt; s=iport; t=1352223927; x=1353433527; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=WbZ6Cm+yjFC5gWUV1lvvdGqu3jOuuWN7b/OzMmyjk6s=; b=j2Hed0rGW5X4uLU3uwTnSVzLI//h+beXLr1IozNOFNXum6kHq1JE1gWv zdH748PxQrDDlCRmYYYnwgJz8uW7xzuLH4tvQOp25YUhYd4tXWFCasFWB dc5ZYGNZNeFjHqLK/nhestgRGeDukMfXXjAZwzo97lSTvlpBZp14TM299 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHtLmVCtJXG8/2dsb2JhbAA6CsMvgQiCHgEBAQQBAQEPASc0FwQCAQgRBAEBCxQJBycLFAkIAQEEARIIGodoC5wOj2SQRgSMAwoGhWRhA6RUgWuCb4FdHgYY X-IronPort-AV: E=Sophos;i="4.80,722,1344211200"; d="scan'208";a="139388615" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 06 Nov 2012 17:45:27 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA6HjQFY025843 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Nov 2012 17:45:26 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.001; Tue, 6 Nov 2012 11:45:26 -0600 From: "Kent Leung (kleung)" To: Kevin J Ma , Ben Niven-Jenkins , "cdni@ietf.org" Thread-Topic: [CDNi] Comments on draft-leung-cdni-uri-signing-01 Thread-Index: Ac25Bkqo4emGLIFqKkGB8eC+X8aPWwCXhSJQADgPqqA= Date: Tue, 6 Nov 2012 17:45:25 +0000 Message-ID: References: <91A268D8-34D3-4732-ACC2-37FF91E925ED@niven-jenkins.co.uk> <291CC3F9E50E7641901A54E85D0977C6535F4FBD29@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6535F4FBD29@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.78.196] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19344.002 x-tm-as-result: No--42.487300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] Comments on draft-leung-cdni-uri-signing-01 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 17:45:33 -0000 Hi Kevin. Agree with your assessment. The only thing that I prefer to have = is some specifics for the base function of the standard URI Signing method.= That means first, identify the information needed to be exchanged between = CDNs generically. Then, come up with the specifics that allows interoperabi= lity of the base function. More details need to be flushed out to see if th= at's feasible. Comments below. -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Kev= in J Ma Sent: Monday, November 05, 2012 7:29 AM To: Ben Niven-Jenkins; cdni@ietf.org Subject: Re: [CDNi] Comments on draft-leung-cdni-uri-signing-01 Hi All, I agree with Ben's comments below. I think it would be helpful if the document focused more on a generic method to describe URI signing algorit= hms and better described the information that needs to be exchanged by CDNI. KL> Agree. wrt CDNI Metadata, we could go simple, and just have a single integer val= ue that identifies an algorithms. The components of any given algorithm cou= ld be kept outside the scope of CDNI. =20 KL> Prefer to specify a base function. Algorithms can be extended with a fl= exible scheme such as a simple integer identifier of the new algorithms. If we want to describe the actual scheme, there are a few things that need to be distributed: 1) the query string argument names, e.g., VER/ET/CIP/KO/KN/HF/ALG/US 2) the allowed values for query string arguments for each field: VER/KO/K= N/ALG/HF - for CIP, is the dCDN expected to validate that a MAC is actually a M= AC or that and MEID is actually an MEID, etc? 3) key retrieval information 4) anything else? KL> We need to discuss the purpose of CID more to see if we should have thi= s in the base function of URI Signing. For example, CID may be split into s= pecific identifiers such as IMSI, MEID, MAC, etc. For the other attributes,= is there a need to define the allowed values?=20 wrt CDN Capabilities, the capabilities would need to be much more than ju= st "I support signing" or "I support these fields", but would also need to b= e able to describe "I support these values for these fields"? KL> See above. Depends if there is value to know the allowable values. :) Is it intended that a uCDN would be allowed to created a "cryptographical= ly equivalent" signing scheme for use when redirecting to the dCDN, if the d= CDN does not support the exact algorithm specified by the CP? If so, how? KL> This should be part of the capabilities advertisement. For HTTP-based r= equest routing, uCDN needs to know that the dCDN supports the algorithm use= d by uCDN to sign the URI. The security considerations mention some fundamental issues associated wi= th URL signing (i.e., spoofing, nats, long timeouts). Are we addressing tho= se issues here, or just looking at security issues related to exchanging CDN= I information required for doing signing, regardless of whether its a bad s= cheme? KL> These are the issues associated with URI Signing. We can consider if th= ere are ways to mitigate them. Not clear what's meant by "regardless of whe= ther it's a bad scheme"? URI Signing is a bad scheme in general? Compare to= another alternative? Kent thanx. -- Kevin J. Ma > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf=20 > Of Ben Niven-Jenkins > Sent: Friday, November 02, 2012 10:28 AM > To: cdni@ietf.org > Subject: [CDNi] Comments on draft-leung-cdni-uri-signing-01 >=20 > Kent, Francois, Matt, >=20 > From reading draft-leung-cdni-uri-signing-01 it appears to be trying=20 > to outline what is required for CDN "URI Signing"/"Token=20 > authorisation" as well as describing a particular "URI Signing"=20 > mechanism (that has a number of significant drawbacks). >=20 > I'd suggest splitting these more explicitly into a more general=20 > discussion on what the authorisation attributes that could/should be=20 > supported are, what is needed on the other CDNI interfaces to support=20 > uri signing/token authorisation and what the use cases are for=20 > different type of signing/authorisation are e.g. is appending query param= eters sufficient? >=20 > The draft could also describe a particular algorithm/mechanism but I=20 > think that should be in a later section or an appendix (or separate=20 > document) rather than being placed in the middle of the document as it is= currently. >=20 > Ben >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From RMurray@velocix.com Tue Nov 6 09:56:59 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F5A21F88DB for ; Tue, 6 Nov 2012 09:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUB+wnw3J3mw for ; Tue, 6 Nov 2012 09:56:58 -0800 (PST) Received: from owa.velocix.com (mail-out1.velocix.com [81.134.152.10]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1B721F88B0 for ; Tue, 6 Nov 2012 09:56:58 -0800 (PST) Received: from EXC01-MLT.corp.velocix.com (172.18.4.41) by EXC00CAM.corp.velocix.com (172.18.4.40) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 6 Nov 2012 17:56:56 +0000 Received: from EXB01-MLT.corp.velocix.com ([169.254.2.46]) by exc01-mlt.corp.velocix.com ([172.18.4.41]) with mapi id 14.02.0318.001; Tue, 6 Nov 2012 17:56:56 +0000 From: Rob Murray To: Kevin J Ma , "cdni@ietf.org" Thread-Topic: CDNI Triggers draft updated Thread-Index: AQHNht3+yZkQCIYO10Wuoi/OlOs1OJfcBrrggAEn5wA= Date: Tue, 6 Nov 2012 17:56:55 +0000 Message-ID: <49C77373835C5A479BC2A84B2A1D66BD5C3D015B@EXB01-MLT.corp.velocix.com> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6535F5DA9A3@MAILR002.mail.lan> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [130.129.22.18] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] CDNI Triggers draft updated X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 17:56:59 -0000 Hi Kevin - responses inline ... On 05/11/2012 14:35, "Kevin J Ma" wrote: >Hi Rob/Ben, > > A couple questions about the updated draft: > > - Is section 2.1 wrt purge/invalidate, are we saying that > purge/invalidate takes precedence over pre-position when both are > in the same request, i.e., pre-position always gets processed > first, and a transit CDN must complete its own preposition and > purge/invalidate before sending the preposition and purge/invalidate > request to any cascaded dCDN? The transit CDN has to pass-on the combined request, so its dCDN also has to obey the rules about not deleting the content it just prepositioned as part of the same request. > If, however, separate requests for pre-position and purge/invalidate > are used and the pre-position is only partially complete when the > purge/invalidate comes in, the CDN may purge/invalidate a portion of > the newly pre-positioned content, but the uCDN may not know which > portion was purged after pre-positioning? Same goes for cascaded >dCDNs? I think purge/invalidate are to get rid of broken content, it only really makes sense to use them when the origin is fixed or disabled, otherwise the broken content can just be reacquired. In that case, if the preposition continues to run after the purge/invalidate arrives, it will either be acquiring mended content or the acquisition will fail. But ... we've been thinking only about making sure that content pre-positioned after an invalidate/purge isn't immediately disposed of. The converse is perhaps a more serious problem, and I don't think we've dealt with it ... if uCDN hasn't finished its purge/invalidate and it still serves that content, it could be picked up by the dCDN's pre-position and therefore not picked up by the associated invalidate/purge in dCDN. One way to deal with that would be to say that caches have to check requests it's serving against the invalidate/purge requests they've not completed (and re-validate/re-acquire at that point if necessary). That'd mean from an external viewpoint the invalidate/purge takes affect as soon as the cache learns about the request, the search of cached URLs doesn't have to complete - the CDN could hold on to the trigger until it's distributed it to all of its affected caches. Not sure whether all CDN implementations would be able to do that. > If so, then are we saying that if the uCDN wants to maintain the > order of operations, it must wait for the trigger result from the > pre-position before issuing the purge/invalidate? And that applies > recursively to all cascaded dCDNs? Holding on to triggers until they're complete in each uCDN doesn't seem like a good idea, in a cascade it could be a very long time before the trigger affects content being served to end users. Perhaps we are best to leave it to the originator of the triggers to sequence triggers - they can send in invalidate/purge requests and expect them to cascade quickly, but they should wait for the response before triggering pre-position. If deleted content is requested before it's all re-pre-positioned it'll be acquired in the normal way... there's always a fallback for pre-position but not for invalidate/purge. So I think we have to make sure invalidate/purge are acted upon quickly, and perhaps shouldn't get hung up in the delete then immediately pre-position use case. > - In section 4, when it talks about loops, wrt the much discussed > diamond deployment, how would the proposed de-duplication schemes > affect the no-loops requirement? > > The dCDN must ensure that activity triggered by uCDN only affects=09 > metadata or content originating from that uCDN. Since only one CDN=09 > can be authoritative for a given item of metadata or content, this=09 > requirement means there cannot be any "loops" in trigger requests=09 > between CDNs. We've not considered the content de-duplication mechanisms in this yet since they're not settled. (We should remember the impact of de-duplication on other aspects of CDNI when considering them though.) >thanx. > >-- Kevin J. Ma > >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of >> Rob Murray >> Sent: Thursday, August 30, 2012 2:34 PM >> To: cdni@ietf.org >> Subject: [CDNi] CDNI Triggers draft updated >>=20 >> Hi all, >>=20 >> We've submitted an update to the CDNI Triggers draft dealing with >>comments >> against the first version, we've not addressed open issues yet... >>=20 >> http://tools.ietf.org/html/draft-murray-cdni-triggers-01 >>=20 >>=20 >> The main change in this version is to allow multiple trigger actions in >>a >> single request, so that an invalidate/delete can be packaged with >> prepopulate in order to replace content. >>=20 >> Open issues include: >> - how to refer to content and metadata, including pattern matching for >> invalidate/purge (depends on metadata draft) >> - how to report failure (need to come up with error codes, and deal >>with >> partial failure) >> - encoding may change to align with metadata and other interfaces >>=20 >> We'll continue to work on those things. >>=20 >> Best regards, >> Rob. >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni From kevin.ma@azukisystems.com Tue Nov 6 10:59:55 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B398D21F8A18 for ; Tue, 6 Nov 2012 10:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-MZ-j8YVGNA for ; Tue, 6 Nov 2012 10:59:54 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 58CAC21F8A96 for ; Tue, 6 Nov 2012 10:59:54 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id BBBA94169B1; Tue, 6 Nov 2012 14:01:09 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB025.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 7374A416D8C; Tue, 6 Nov 2012 14:01:06 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Tue, 6 Nov 2012 13:59:51 -0500 From: Kevin J Ma To: "Kent Leung (kleung)" , Ben Niven-Jenkins , "cdni@ietf.org" Date: Tue, 6 Nov 2012 13:59:50 -0500 Thread-Topic: [CDNi] Comments on draft-leung-cdni-uri-signing-01 Thread-Index: Ac25Bkqo4emGLIFqKkGB8eC+X8aPWwCXhSJQADgPqqAAAmi3UA== Message-ID: <291CC3F9E50E7641901A54E85D0977C6535F5DAD4D@MAILR002.mail.lan> References: <91A268D8-34D3-4732-ACC2-37FF91E925ED@niven-jenkins.co.uk> <291CC3F9E50E7641901A54E85D0977C6535F4FBD29@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] Comments on draft-leung-cdni-uri-signing-01 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 18:59:55 -0000 Hi Kent, > KL> We need to discuss the purpose of CID more to see if we should have > this in the base function of URI Signing. For example, CID may be split > into specific identifiers such as IMSI, MEID, MAC, etc. For the other > attributes, is there a need to define the allowed values? The allowed values only apply if we are going to allow substituting "equivalent" URI signing schemes. If not, then its not clear to me why we would necessarily need to include KO/KN/HF/ALG in the query string. They could just be configuration thats never exposed to the clients. Having them in the query string allows clients to generate their own algorithms, and opens up different attacks with fake KO/KN/HF injection? But, that kind of segues into my next comment... ;) > The security considerations mention some fundamental issues associated = with > URL signing (i.e., spoofing, nats, long timeouts). Are we addressing t= hose > issues here, or just looking at security issues related to exchanging C= DNI > information required for doing signing, regardless of whether its a bad= scheme? >=20 > KL> These are the issues associated with URI Signing. We can consider if > there are ways to mitigate them. Not clear what's meant by "regardless of > whether it's a bad scheme"? URI Signing is a bad scheme in general? > Compare to another alternative? What I meant was, the WG should not be addressing the goodness or badness o= f a URI signing scheme. (I tend to find them more bad than good.) If someone chooses an infinite expiration time, or chooses not to use a good client id= , or picks a bad key, etc., its a bad scheme, but that is probably inconseque= ntial to the CDNI interfaces? Do we agree that the security concerns should be confined to only those con= cerns related to CDNI metadata and capabilities exchange, and should not include = general concerns about the goodness or badness of the supported URI signing scheme? thanx. -- Kevin J. Ma > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > Sent: Tuesday, November 06, 2012 12:45 PM > To: Kevin J Ma; Ben Niven-Jenkins; cdni@ietf.org > Subject: RE: [CDNi] Comments on draft-leung-cdni-uri-signing-01 >=20 > Hi Kevin. Agree with your assessment. The only thing that I prefer to hav= e > is some specifics for the base function of the standard URI Signing > method. That means first, identify the information needed to be exchanged > between CDNs generically. Then, come up with the specifics that allows > interoperability of the base function. More details need to be flushed ou= t > to see if that's feasible. Comments below. >=20 > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Kevin J Ma > Sent: Monday, November 05, 2012 7:29 AM > To: Ben Niven-Jenkins; cdni@ietf.org > Subject: Re: [CDNi] Comments on draft-leung-cdni-uri-signing-01 >=20 > Hi All, >=20 > I agree with Ben's comments below. I think it would be helpful if the > document focused more on a generic method to describe URI signing > algorithms > and better described the information that needs to be exchanged by CDNI= . >=20 > KL> Agree. >=20 > wrt CDNI Metadata, we could go simple, and just have a single integer > value > that identifies an algorithms. The components of any given algorithm > could > be kept outside the scope of CDNI. >=20 > KL> Prefer to specify a base function. Algorithms can be extended with a > flexible scheme such as a simple integer identifier of the new algorithms= . >=20 > If we want to describe the actual scheme, > there are a few things that need to be distributed: >=20 > 1) the query string argument names, e.g., VER/ET/CIP/KO/KN/HF/ALG/US > 2) the allowed values for query string arguments for each field: > VER/KO/KN/ALG/HF > - for CIP, is the dCDN expected to validate that a MAC is actually a > MAC > or that and MEID is actually an MEID, etc? > 3) key retrieval information > 4) anything else? >=20 > KL> We need to discuss the purpose of CID more to see if we should have > this in the base function of URI Signing. For example, CID may be split > into specific identifiers such as IMSI, MEID, MAC, etc. For the other > attributes, is there a need to define the allowed values? >=20 > wrt CDN Capabilities, the capabilities would need to be much more than > just > "I support signing" or "I support these fields", but would also need to > be > able to describe "I support these values for these fields"? >=20 > KL> See above. Depends if there is value to know the allowable values. :) >=20 > Is it intended that a uCDN would be allowed to created a > "cryptographically > equivalent" signing scheme for use when redirecting to the dCDN, if the > dCDN > does not support the exact algorithm specified by the CP? If so, how? >=20 > KL> This should be part of the capabilities advertisement. For HTTP-based > request routing, uCDN needs to know that the dCDN supports the algorithm > used by uCDN to sign the URI. >=20 > The security considerations mention some fundamental issues associated > with > URL signing (i.e., spoofing, nats, long timeouts). Are we addressing > those > issues here, or just looking at security issues related to exchanging > CDNI > information required for doing signing, regardless of whether its a bad > scheme? >=20 > KL> These are the issues associated with URI Signing. We can consider if > there are ways to mitigate them. Not clear what's meant by "regardless of > whether it's a bad scheme"? URI Signing is a bad scheme in general? > Compare to another alternative? >=20 > Kent >=20 > thanx. >=20 > -- Kevin J. Ma >=20 > > -----Original Message----- > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > > Of Ben Niven-Jenkins > > Sent: Friday, November 02, 2012 10:28 AM > > To: cdni@ietf.org > > Subject: [CDNi] Comments on draft-leung-cdni-uri-signing-01 > > > > Kent, Francois, Matt, > > > > From reading draft-leung-cdni-uri-signing-01 it appears to be trying > > to outline what is required for CDN "URI Signing"/"Token > > authorisation" as well as describing a particular "URI Signing" > > mechanism (that has a number of significant drawbacks). > > > > I'd suggest splitting these more explicitly into a more general > > discussion on what the authorisation attributes that could/should be > > supported are, what is needed on the other CDNI interfaces to support > > uri signing/token authorisation and what the use cases are for > > different type of signing/authorisation are e.g. is appending query > parameters sufficient? > > > > The draft could also describe a particular algorithm/mechanism but I > > think that should be in a later section or an appendix (or separate > > document) rather than being placed in the middle of the document as it > is currently. > > > > Ben > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From dan-ietf@danyork.org Tue Nov 6 11:46:47 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD17421F8AA1 for ; Tue, 6 Nov 2012 11:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAN7rj9Uuo6T for ; Tue, 6 Nov 2012 11:46:47 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id EF8C321F8A8D for ; Tue, 6 Nov 2012 11:46:46 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so1368067iec.31 for ; Tue, 06 Nov 2012 11:46:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=cJEOzfl2rnZSITUNWVmDfUQc8n9uVIyPeO4rHYfyEyg=; b=HoDdCMQ7TzGaYBZjtH0360YzdIuFKN+ae2d+QaV956RcgpHT3/1Gdg+/XSO4MX8a8v KzRyiVDlRXYV90rSF8WBM2T//ayi00W4LlF8vh+M/sqdsUV/LzPYs5N1udfZYZ/mfO/i NAj/jQKmwHokjBlkKas7O/gJzCpQmQAMtxWt02rLkfRlb6QEZWs3nzK0EczUTlcqzqdq 2hTSnI+piEMpuAvDo/OE74NS6xoY+kLUOjSss9k7SpDdGcqIQ5U5zyCPJ3Ctyckrv8OH ZkYZBfHP4VRxH/n8uUUW42m62ivchRRHYZjexaz/rrkO41fK/QlklWJq/dD0XqbtWeCB OVRA== Received: by 10.50.77.136 with SMTP id s8mr2263766igw.74.1352231206569; Tue, 06 Nov 2012 11:46:46 -0800 (PST) Received: from [172.20.12.152] (cpe-74-75-92-114.maine.res.rr.com. [74.75.92.114]) by mx.google.com with ESMTPS id pq3sm103547igc.8.2012.11.06.11.46.45 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Nov 2012 11:46:46 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_C889259C-3934-4173-8C8B-19F72688DBF5" From: Dan York In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6535F5DAD4D@MAILR002.mail.lan> Date: Tue, 6 Nov 2012 14:46:44 -0500 Message-Id: <7E3A2DDD-6E53-4918-9E35-56061B71329C@danyork.org> References: <91A268D8-34D3-4732-ACC2-37FF91E925ED@niven-jenkins.co.uk> <291CC3F9E50E7641901A54E85D0977C6535F4FBD29@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6535F5DAD4D@MAILR002.mail.lan> To: Kevin J Ma X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkDetivrdxH85HbusW9iy8adFirHEYhr4K1LumLsBUsI8BBeeVDtjpKCzw/GgWpYLg6TxWT Cc: "cdni@ietf.org" Subject: Re: [CDNi] Comments on draft-leung-cdni-uri-signing-01 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 19:46:47 -0000 --Apple-Mail=_C889259C-3934-4173-8C8B-19F72688DBF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 6, 2012, at 1:59 PM, Kevin J Ma wrote: >> The security considerations mention some fundamental issues = associated with >> URL signing (i.e., spoofing, nats, long timeouts). Are we = addressing those >> issues here, or just looking at security issues related to = exchanging CDNI >> information required for doing signing, regardless of whether its a = bad scheme? >>=20 >> KL> These are the issues associated with URI Signing. We can consider = if >> there are ways to mitigate them. Not clear what's meant by = "regardless of >> whether it's a bad scheme"? URI Signing is a bad scheme in general? >> Compare to another alternative? >=20 > What I meant was, the WG should not be addressing the goodness or = badness of a > URI signing scheme. (I tend to find them more bad than good.) If = someone > chooses an infinite expiration time, or chooses not to use a good = client id, > or picks a bad key, etc., its a bad scheme, but that is probably = inconsequential > to the CDNI interfaces? >=20 > Do we agree that the security concerns should be confined to only = those concerns > related to CDNI metadata and capabilities exchange, and should not = include general > concerns about the goodness or badness of the supported URI signing = scheme? On a similar note related to scope, it would be helpful if the Security = Considerations section had some commentary about the attack surface of = the exchange of information between the CDNs (or pointed to a document = where this is described). By that I mean, is the exchange of CDNI = information happening over the public Internet? over private networks? = over VPNs? or potentially all of the above? How accessible the = exchange is to attackers can help guide the level of necessary = robustness needed in the protection of the information. Dan --=20 Dan York dyork@lodestar2.com http://www.danyork.me/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork --Apple-Mail=_C889259C-3934-4173-8C8B-19F72688DBF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
 The security = considerations mention some fundamental issues associated = with
 URL signing (i.e., = spoofing, nats, long timeouts).  Are we addressing = those
 issues here, or = just looking at security issues related to exchanging = CDNI
 information = required for doing signing, regardless of whether its a bad = scheme?

KL> These = are the issues associated with URI Signing. We can consider = if
there are ways to mitigate = them. Not clear what's meant by "regardless = of
whether it's a bad scheme"? = URI Signing is a bad scheme in general?
Compare to another alternative?

What I = meant was, the WG should not be addressing the goodness or badness of = a
URI signing scheme.  (I tend to find them more bad than good.) =  If someone
chooses an infinite expiration time, or chooses not = to use a good client id,
or picks a bad key, etc., its a bad scheme, = but that is probably inconsequential
to the CDNI = interfaces?

Do we agree that the security concerns should be = confined to only those concerns
related to CDNI metadata and = capabilities exchange, and should not include general
concerns about = the goodness or badness of the supported URI signing = scheme?

On a similar note = related to scope, it would be helpful if the Security Considerations = section had some commentary about the attack surface of the exchange of = information between the CDNs (or pointed to a document where this is = described).  By that I mean, is the exchange of CDNI information = happening over the public Internet? over private networks? over VPNs? or = potentially all of the above?   How accessible the exchange is to = attackers can help guide the level of necessary robustness needed in the = protection of the = information.

Dan

-- 
Dan York  dyork@lodestar2.com
http://www.danyork.me/  &nb= sp;skype:danyork
Phone: = +1-802-735-1624
Twitter - http://twitter.com/danyork

= --Apple-Mail=_C889259C-3934-4173-8C8B-19F72688DBF5-- From dan-ietf@danyork.org Tue Nov 6 12:13:37 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3DD21F843D for ; Tue, 6 Nov 2012 12:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUV3VPJ-rUoD for ; Tue, 6 Nov 2012 12:13:37 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 185DD21F8421 for ; Tue, 6 Nov 2012 12:13:30 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id x24so650475iak.31 for ; Tue, 06 Nov 2012 12:13:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=0oQ/UCCzbeE7P323AYoUYwLKa5J5rAIVEx4OUuqa2go=; b=WG/i53IQnetCC1ivd38QuH1Thkxsm8lrYKqjKe5Dn4eZ1j7ituOvsGVpKMsJvvcAMs eJr6/3VKqYa82mNtBPfiRU/6A9srOB4DMaFTU4ePJmg8PoWJ3zx/v7u7pVWuN+VZ1QRY GIkKcgHnIMrhmGTCnV6tNbw1QBPtJ1IO2eSa4BH9RFQ7ZXNCQDk18Mj6jUFk5Cc72UUS kIROdGlVkQl+dkN4iZg5Ng/D1S3DQhdZ+avZqZqy5/DjwTDaM9jscsvfXD9hwYBIm5U4 mjqZ9aD1N2ZV2gSAYgeLmhip2FdviqcLNTRf1LEA+qYzj7jGevhBhhDm0YUtMgpaXfl+ Tp8w== Received: by 10.50.5.205 with SMTP id u13mr2410170igu.37.1352232810566; Tue, 06 Nov 2012 12:13:30 -0800 (PST) Received: from [172.20.12.152] (cpe-74-75-92-114.maine.res.rr.com. [74.75.92.114]) by mx.google.com with ESMTPS id dq9sm174059igc.5.2012.11.06.12.13.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Nov 2012 12:13:30 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_FE93FBDA-4FDC-4F57-9CC9-F79553C36C8B" From: Dan York In-Reply-To: <91A268D8-34D3-4732-ACC2-37FF91E925ED@niven-jenkins.co.uk> Date: Tue, 6 Nov 2012 15:13:26 -0500 Message-Id: <598EAF9C-9A5B-4AD5-85CC-5358A985B2B8@danyork.org> References: <91A268D8-34D3-4732-ACC2-37FF91E925ED@niven-jenkins.co.uk> To: Ben Niven-Jenkins X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQmCdwpxxz+QP/9fdGIvxRvVf//ocodzW0A6mp+D7sPtIKXzo7WTK0UU08tQoxDhvU/jg029 Cc: cdni@ietf.org Subject: [CDNi] Assymetric key distribution - Re: Comments on draft-leung-cdni-uri-signing-01 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 20:13:38 -0000 --Apple-Mail=_FE93FBDA-4FDC-4F57-9CC9-F79553C36C8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Kent, Francois, Matt, Several times in the document there is a mention that for assymetric = keys "public keys can typically be distributed openly", but unless I = missed it (and I could have) I didn't get an understanding in the draft = of *how* a CDN could get the public key for another CDN. =20 How would a dCDN actually get the CSP's public key? Would it retrieve it from a specific URL? from DNS? from some other PKI? = from some other transfer method? all of the above? I think the document should make some mention of how this distribution = of the public key could occur. Also, I don't know that I fully agree with this statement: > Key distribution for asymmetric keys does not require > confidentiality since public keys can typically be distributed = openly > (because they cannot be used for URI signing) and private keys are > kept by the URI signing function. While that is true, how does the dCDN know that it has the *correct* = public key for the CPS? What if the attacker can somehow provide the = dCDN with a public key from the attacker's site? He or she could then = send updates to the dCDN that are signed with a public key and would = appear legit - it would just be the wrong public key. One potential solution would be to look at the work happening over in = the DANE working group[1] where a certificate could be published as a = DNS record and then signed with DNSSEC[2]. This would provide a way for = the dCDN to easily get the public key for the CSP - and would also have = strong integrity protection via DNSSEC so that the dCDN would know that = it has the *correct* public key. My 2 cents, Dan [1] or look at http://www.internetsociety.org/deploy360/resources/dane/ = for some intro material. [2] And yes, I realize that for this to work DNSSEC would need to be = more widely deployed but: a) that's being worked on; and b) we're = talking here about a defined set of users (CSPs) who would need to = publish their public keys in DNS and sign their zone files. Not = necessarily a huge number of users to work with to get their zones = signed and records published. On Nov 2, 2012, at 10:27 AM, Ben Niven-Jenkins wrote: > Kent, Francois, Matt, >=20 > =46rom reading draft-leung-cdni-uri-signing-01 it appears to be trying = to outline what is required for CDN "URI Signing"/"Token authorisation" = as well as describing a particular "URI Signing" mechanism (that has a = number of significant drawbacks). >=20 > I'd suggest splitting these more explicitly into a more general = discussion on what the authorisation attributes that could/should be = supported are, what is needed on the other CDNI interfaces to support = uri signing/token authorisation and what the use cases are for different = type of signing/authorisation are e.g. is appending query parameters = sufficient? >=20 > The draft could also describe a particular algorithm/mechanism but I = think that should be in a later section or an appendix (or separate = document) rather than being placed in the middle of the document as it = is currently. >=20 > Ben >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --=20 Dan York dyork@lodestar2.com http://www.danyork.me/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork --Apple-Mail=_FE93FBDA-4FDC-4F57-9CC9-F79553C36C8B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Kent, = Francois, Matt,

Several times in the document there = is a mention that for assymetric keys "public keys can typically be = distributed openly", but unless I missed it (and I could have) I didn't = get an understanding in the draft of *how* a CDN could get the public = key for another CDN.  

How would a dCDN = actually get the CSP's public key?

Would it = retrieve it from a specific URL? from DNS? from some other PKI? from = some other transfer method? all of the above?

I = think the document should make some mention of how this distribution of = the public key could occur.

Also, I don't know = that I fully agree with this = statement:

   Key distribution for asymmetric keys = does not require
   confidentiality since public = keys can typically be distributed openly
   (because = they cannot be used for URI signing) and private keys = are
   kept by the URI signing = function.

While that is true, how = does the dCDN know that it has the *correct* public key for the CPS? =  What if the attacker can somehow provide the dCDN with a public = key from the attacker's site?  He or she could then send updates to = the dCDN that are signed with a public key and would appear legit - it = would just be the wrong public key.

One = potential solution would be to look at the work happening over in the = DANE working group[1] where a certificate could be published as a DNS = record and then signed with DNSSEC[2].  This would provide a way = for the dCDN to easily get the public key for the CSP - and would also = have strong integrity protection via DNSSEC so that the dCDN would know = that it has the *correct* public key.

My 2 = cents,
Dan

[1] or look at http://w= ww.internetsociety.org/deploy360/resources/dane/ for some intro = material.

[2] And yes, I realize that for this = to work DNSSEC would need to be more widely deployed but: a) that's = being worked on; and b) we're talking here about a defined set of users = (CSPs) who would need to publish their public keys in DNS and sign their = zone files.  Not necessarily a huge number of users to work with to = get their zones signed and records = published.


On Nov 2, 2012, = at 10:27 AM, Ben Niven-Jenkins wrote:

Kent, = Francois, Matt,

=46rom reading draft-leung-cdni-uri-signing-01 it = appears to be trying to outline what is required for CDN "URI = Signing"/"Token authorisation" as well as describing a particular "URI = Signing" mechanism (that has a number of significant = drawbacks).

I'd suggest splitting these more explicitly into a = more general discussion on what the authorisation attributes that = could/should be supported are, what is needed on the other CDNI = interfaces to support uri signing/token authorisation and what the use = cases are for different type of signing/authorisation are e.g. is = appending query parameters sufficient?

The draft could also = describe a particular algorithm/mechanism but I think that should be in = a later section or an appendix (or separate document) rather than being = placed in the middle of the document as it is = currently.

Ben

_____________________________________________= __
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/ma= ilman/listinfo/cdni

dyork@lodestar2.com
http://www.danyork.me/  &nb= sp;skype:danyork
Phone: = +1-802-735-1624
Twitter - http://twitter.com/danyork



= --Apple-Mail=_FE93FBDA-4FDC-4F57-9CC9-F79553C36C8B-- From Jan.Seedorf@neclab.eu Tue Nov 6 14:51:16 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938F521F8B8C; Tue, 6 Nov 2012 14:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWN6tkIvczN2; Tue, 6 Nov 2012 14:51:15 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 65BCC21F8B9B; Tue, 6 Nov 2012 14:51:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 5A137102456; Tue, 6 Nov 2012 23:51:03 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FcCrIDJPi9i; Tue, 6 Nov 2012 23:51:03 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 40A2310245C; Tue, 6 Nov 2012 23:50:53 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.239]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 6 Nov 2012 23:50:53 +0100 From: Jan Seedorf To: "cdni-footprint@ietf.org" Thread-Topic: My notes from today's CDNI Side Meeting Footprint/Capabilities at IETF85 Thread-Index: Ac28cIkzkX5s+1xhQPWKsObFSX3Law== Date: Tue, 6 Nov 2012 22:50:28 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE553854DB@DAPHNIS.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.205] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] My notes from today's CDNI Side Meeting Footprint/Capabilities at IETF85 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 22:51:17 -0000 CDNI Side Meeting Footprint/Capabilities at IETF85 - 20121106 ************************************************************* -- what capabilities are mandatory and how could we call those with respect= to terminology? -- agreement that "delivery protocol" is mandatory; Francois: how fine grai= ned?; Emil: smooth streaming etc. should be sub-field under general field "= http" etc.; Rob: how to avoid enumeration of all types of http delivery; -- agreement that we do not want to enumerate detailed delivery protocols; = agreement to have a registry for "delivery protocol" where the registry and= how to fill the registry would be defined by CDNI documents -- single-level registry is probably what we want to have (i.e. on a genera= l protocol level such as "http", without going into flavors of http) -- Kevin: there are use cases were acquisition protocol is needed to know; = live streaming is interesting use case regarding supported acquisition prot= ocol -- acquisition protocol may be dependent on delivery protocol, but let's di= scuss dependencies among capabilities later -- probably the same registry can be used for delivery protocol and acquisi= tion protocol -- redirection mode needs to be supported, possibly a stricter registry is = needed for this -- capabilities needed for logging will be needed, but not yet clear -- capabilities needed with respect to metadata; for some metadata actual s= upported values need to be advertised as capabilities -- need to align the work between metadata / logging / request routing inte= rfaces with respect to capabilities advertisement -- capability interface needs to be extensible (e.g. to allow for metadata = that might be added later) -- cascading / matrix of different capabilities in combination is still to = be discussed (e.g. certain acquisition protocols are only supported for cer= tain delivery protocols) -- URI signing still to be discussed regarding capabilities advertisement o= f detailed features / methods -- Francois: what about versioning (e.g. metadata v.1 vs. metadata v.2)? Do= we need to advertise that? - Jan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jan Seedorf Senior Researcher NEC Europe Ltd., NEC Laboratories Europe, Network Division=A0=A0=A0=A0=A0 Kurfuerstenanlage 36, D-69115 Heidelberg Tel.=A0=A0=A0=A0 +49 (0)6221 4342-221 Fax:=A0=A0=A0=A0 +49 (0)6221 4342-155 e-mail:=A0 jan.seedorf@neclab.eu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014=20 From kevin.ma@azukisystems.com Tue Nov 6 15:39:46 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6B321F8BB9 for ; Tue, 6 Nov 2012 15:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRlerUYgnER5 for ; Tue, 6 Nov 2012 15:39:46 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id D492E21F8BB4 for ; Tue, 6 Nov 2012 15:39:45 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 7F2A17DF36A; Tue, 6 Nov 2012 18:13:56 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): References: ...F@PEXCVZYM13.corporate.adroot.infra.ftgroup>\n Received: from HUB016.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id C2C577DF2BE; Tue, 6 Nov 2012 18:13:55 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Tue, 6 Nov 2012 18:39:12 -0500 From: Kevin J Ma To: "gilles.bertrand@orange.com" , "cdni@ietf.org" Date: Tue, 6 Nov 2012 18:38:08 -0500 Thread-Topic: New version of the CDNI Logging draft posted Thread-Index: AQHNsIhQpQ5EQkTRwk2UvYifo9SmxZfbjMTQgAH+oBA= Message-ID: <291CC3F9E50E7641901A54E85D0977C6535F5DAEF0@MAILR002.mail.lan> References: <20121022185902.22651.23401.idtracker@ietfa.amsl.com> <11995_1350932778_5085992A_11995_9963_1_2AC63C9F27AF8446B0C064C50FC0A89306DA472F@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] New version of the CDNI Logging draft posted X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 23:39:46 -0000 Hi All, A couple of additional thoughts on metadata vs control for logging config= : - While I can see an argument for using control to convey uCDN to dCDN logging information, because it is not content specific, it is not clear to me why we would need to do that logging at all. Both the uCDN and the dCDN know what was transfered; the sharing of logs does not seem that meaningful. Unlike when the dCDN talks to the client, and needs to tell the uCDN about it. - If we consider the control interface to be triggers, it is not clear that the semantics of triggers lends itself to pushing persistent information. Whereas, with metadata, the logging information for a given piece of content would be automatically accessed on demand whenever the content is accessed by an end user, rather than having to be proactively pushed by the uCDN and maintained by the dCDN. - Finally, even if we consider that the optimal logging config for a given surrogate is the aggregate of the different logging configs for the different content it may server, combined with the internal CDN logging needs, this optimization can still be performed by the local CDN. Just as with content acquisition, I would not expect all the surrogates use the uCDN metadata directly; I would expect some type of hierarchical organization of servers through which the surrogates acquire the content. The metadata interface conveys inter-CDN data; intra-CDN per-surrogate optimization can still be performed by the local CDN, outside the scope of CDNI. thanx. -- Kevin J. Ma > -----Original Message----- > From: Kevin J Ma > Sent: Monday, November 05, 2012 12:15 PM > To: 'gilles.bertrand@orange.com'; cdni@ietf.org > Subject: RE: New version of the CDNI Logging draft posted >=20 > Hi All, >=20 > I had a couple questions about the logging config and the use of the > control > interface rather than the metadata interface for distributing the > config. >=20 > - Though the config is static, it may differ for different pieces of > content? > The metadata interface already includes provisions for apply > properties to > specific sets of content based on URI path; logging could be a > property. >=20 > - Though the filtering could occur higher up than the surrogates, is > that > going to be efficient? The surrogates would have to log all fields > for > the upstream filtering function to work. The extra metadata seems > small > in comparison to the extra (unnecessary) logging data sent to the > filter? >=20 > Furthermore, if a CP wants an additional field (e.g., X-vendor-blah > header) > that would need to be conveyed to the surrogates to be logged? >=20 > thanx. >=20 > -- Kevin J. Ma >=20 > > -----Original Message----- > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > > gilles.bertrand@orange.com > > Sent: Monday, October 22, 2012 3:06 PM > > To: cdni@ietf.org > > Subject: [CDNi] New version of the CDNI Logging draft posted > > > > Folks, > > > > We have submitted a new version of the CDNI logging draft: > > URL: http://www.ietf.org/internet-drafts/draft-bertrand- > cdni- > > logging-02.txt > > Status: http://datatracker.ietf.org/doc/draft-bertrand-cdni- > > logging > > Htmlized: http://tools.ietf.org/html/draft-bertrand-cdni-logging= - > 02 > > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-bertrand-cdni= - > > logging-02 > > > > Best regards, > > > > Gilles > > > > -----Message d'origine----- > > De=A0: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] > > De la part de internet-drafts@ietf.org > > Envoy=E9=A0: lundi 22 octobre 2012 20:59 > > =C0=A0: i-d-announce@ietf.org > > Objet=A0: I-D Action: draft-bertrand-cdni-logging-02.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : CDNI Logging Interface > > Author(s) : Gilles Bertrand > > Stephan Emile > > Roy Peterkofsky > > Francois Le Faucheur > > Pawel Grochocki > > Filename : draft-bertrand-cdni-logging-02.txt > > Pages : 43 > > Date : 2012-10-22 > > > > 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 actual > > protocol for CDNI logging information exchange covering the > > information elements as well as the transport of those. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-bertrand-cdni-logging > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-bertrand-cdni-logging-02 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-bertrand-cdni-logging-02 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > _________________________________________________________________________= _ > > _______________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > > recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s > > electroniques etant susceptibles d'alteration, > > France Telecom - Orange decline toute responsabilite si ce message a et= e > > altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > > information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > > delete this message and its attachments. > > As emails may be altered, France Telecom - Orange is not liable for > > messages that have been modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni From roy@skytide.com Tue Nov 6 17:48:32 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AEC21F867C for ; Tue, 6 Nov 2012 17:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rO7xHAEGfmpj for ; Tue, 6 Nov 2012 17:48:30 -0800 (PST) Received: from mail-pop3-1.server101.com (ns1.giga-sj-001.net [216.218.210.201]) by ietfa.amsl.com (Postfix) with ESMTP id 5154821F8654 for ; Tue, 6 Nov 2012 17:48:30 -0800 (PST) Received: from [192.168.1.102] (70-36-140-147.dsl.dynamic.sonic.net [70.36.140.147]) (authenticated as roy@skytide.com with PLAIN (0 bits)) by mail-pop3-1.server101.com (8.13.7/8.12.8) with ESMTP id qA71mL5R024034; Wed, 7 Nov 2012 11:48:21 +1000 Message-ID: <5099BDE3.6050703@skytide.com> Date: Tue, 06 Nov 2012 17:48:19 -0800 From: Roy Peterkofsky User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Kevin J Ma References: <20121022185902.22651.23401.idtracker@ietfa.amsl.com> <11995_1350932778_5085992A_11995_9963_1_2AC63C9F27AF8446B0C064C50FC0A89306DA472F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <291CC3F9E50E7641901A54E85D0977C6535F5DAEF0@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6535F5DAEF0@MAILR002.mail.lan> Content-Type: multipart/alternative; boundary="------------040009050506040308040700" Cc: "cdni@ietf.org" Subject: Re: [CDNi] New version of the CDNI Logging draft posted X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 01:48:32 -0000 This is a multi-part message in MIME format. --------------040009050506040308040700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Kevin, The rational for using the control interface was that we deemed it unlikely that, in practice, uCDNs and dCDNs would engage in the practice of specifying the elements to be logged and transmitted independently for each request or piece of content. What seems much more likely is that uCDNs and dCDNs will agree in advance about which elements will be transmitted and then adopt that standard for all traffic transacted between the two parties. To control the logged elements on a per-content or per-request basis would: 1) Add a much higher level of complexity to the task of capturing and transmitting log data on the part of the logging CDN. Most edge server streaming software, for example, does not have logic to capture different data elements for different pieces of content. 2) Imply that the CDNs that provide reports to CSPs or to internal departments are going to provide different reports to those constituencies about different content, which would also add a great deal of complexity and would be a use this that we have not seen. CDNs typically offer the same portfolio of reports to all of their CSP customers, for example. 3) Add unnecessary volume to the metadata traffic for each content element. While we can see some cases where logging and reporting may differ for different types of content (e.g., HAS vs. HTTP small object delivery), this is not likely to vary by specific content element within a type of content. For these reasons, we did not think that is was most appropriate to put these transactions in the content-specific metadata interface. It is certainly conceivable that, someday, some CDNs might want the capability to specify logging elements differently for each content element. But we do not know of any CDN platform providers that are even considering this capability on their near-term or strategic roadmaps. Roy On 11/6/2012 3:38 PM, Kevin J Ma wrote: > Hi All, > > A couple of additional thoughts on metadata vs control for logging config: > > - While I can see an argument for using control to convey uCDN to dCDN > logging information, because it is not content specific, it is not > clear to me why we would need to do that logging at all. Both the > uCDN and the dCDN know what was transfered; the sharing of logs does > not seem that meaningful. Unlike when the dCDN talks to the client, > and needs to tell the uCDN about it. > > - If we consider the control interface to be triggers, it is not clear > that the semantics of triggers lends itself to pushing persistent > information. Whereas, with metadata, the logging information for a > given piece of content would be automatically accessed on demand > whenever the content is accessed by an end user, rather than having > to be proactively pushed by the uCDN and maintained by the dCDN. > > - Finally, even if we consider that the optimal logging config for a > given surrogate is the aggregate of the different logging configs > for the different content it may server, combined with the internal > CDN logging needs, this optimization can still be performed by the > local CDN. Just as with content acquisition, I would not expect all > the surrogates use the uCDN metadata directly; I would expect some type > of hierarchical organization of servers through which the surrogates > acquire the content. The metadata interface conveys inter-CDN data; > intra-CDN per-surrogate optimization can still be performed by the > local CDN, outside the scope of CDNI. > > thanx. > > -- Kevin J. Ma > >> -----Original Message----- >> From: Kevin J Ma >> Sent: Monday, November 05, 2012 12:15 PM >> To: 'gilles.bertrand@orange.com'; cdni@ietf.org >> Subject: RE: New version of the CDNI Logging draft posted >> >> Hi All, >> >> I had a couple questions about the logging config and the use of the >> control >> interface rather than the metadata interface for distributing the >> config. >> >> - Though the config is static, it may differ for different pieces of >> content? >> The metadata interface already includes provisions for apply >> properties to >> specific sets of content based on URI path; logging could be a >> property. >> >> - Though the filtering could occur higher up than the surrogates, is >> that >> going to be efficient? The surrogates would have to log all fields >> for >> the upstream filtering function to work. The extra metadata seems >> small >> in comparison to the extra (unnecessary) logging data sent to the >> filter? >> >> Furthermore, if a CP wants an additional field (e.g., X-vendor-blah >> header) >> that would need to be conveyed to the surrogates to be logged? >> >> thanx. >> >> -- Kevin J. Ma >> >>> -----Original Message----- >>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of >>> gilles.bertrand@orange.com >>> Sent: Monday, October 22, 2012 3:06 PM >>> To: cdni@ietf.org >>> Subject: [CDNi] New version of the CDNI Logging draft posted >>> >>> Folks, >>> >>> We have submitted a new version of the CDNI logging draft: >>> URL: http://www.ietf.org/internet-drafts/draft-bertrand- >> cdni- >>> logging-02.txt >>> Status: http://datatracker.ietf.org/doc/draft-bertrand-cdni- >>> logging >>> Htmlized: http://tools.ietf.org/html/draft-bertrand-cdni-logging- >> 02 >>> Diff: http://www.ietf.org/rfcdiff?url2=draft-bertrand-cdni- >>> logging-02 >>> >>> Best regards, >>> >>> Gilles >>> >>> -----Message d'origine----- >>> De : i-d-announce-bounces@ietf.org [mailto:i-d-announce- >> bounces@ietf.org] >>> De la part de internet-drafts@ietf.org >>> Envoyé : lundi 22 octobre 2012 20:59 >>> À : i-d-announce@ietf.org >>> Objet : I-D Action: draft-bertrand-cdni-logging-02.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : CDNI Logging Interface >>> Author(s) : Gilles Bertrand >>> Stephan Emile >>> Roy Peterkofsky >>> Francois Le Faucheur >>> Pawel Grochocki >>> Filename : draft-bertrand-cdni-logging-02.txt >>> Pages : 43 >>> Date : 2012-10-22 >>> >>> 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 actual >>> protocol for CDNI logging information exchange covering the >>> information elements as well as the transport of those. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-bertrand-cdni-logging >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-bertrand-cdni-logging-02 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-bertrand-cdni-logging-02 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> >> __________________________________________________________________________ >>> _______________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >>> recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >>> electroniques etant susceptibles d'alteration, >>> France Telecom - Orange decline toute responsabilite si ce message a ete >>> altere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or privileged >>> information that may be protected by law; >>> they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and >>> delete this message and its attachments. >>> As emails may be altered, France Telecom - Orange is not liable for >>> messages that have been modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2013.0.2742 / Virus Database: 2617/5877 - Release Date: 11/06/12 > > -- Roy Peterkofsky Vice President, Product Management Skytide -- the leader in Digital Media Performance Management www.skytide.com (510) 250-4284 Read our new white paper: The 4 Keys to Telco CDN Success --------------040009050506040308040700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Kevin,

The rational for using the control interface was that we deemed it unlikely that, in practice, uCDNs and dCDNs would engage in the practice of specifying the elements to be logged and transmitted independently for each request or piece of content.  What seems much more likely is that uCDNs and dCDNs will agree in advance about which elements will be transmitted and then adopt that standard for all traffic transacted between the two parties.  To control the logged elements on a per-content or per-request basis would:

1) Add a much higher level of complexity to the task of capturing and transmitting log data on the part of the logging CDN.  Most edge server streaming software, for example, does not have logic to capture different data elements for different pieces of content.
2) Imply that the CDNs that provide reports to CSPs or to internal departments are going to provide different reports to those constituencies about different content, which would also add a great deal of complexity and would be a use this that we have not seen.  CDNs typically offer the same portfolio of reports to all of their CSP customers, for example.
3) Add unnecessary volume to the metadata traffic for each content element.

While we can see some cases where logging and reporting may differ for different types of content (e.g., HAS vs. HTTP small object delivery), this is not likely to vary by specific content element within a type of content.

For these reasons, we did not think that is was most appropriate to put these transactions in the content-specific metadata interface.

It is certainly conceivable that, someday, some CDNs might want the capability to specify logging elements differently for each content element.  But we do not know of any CDN platform providers that are even considering this capability on their near-term or strategic roadmaps.

Roy

On 11/6/2012 3:38 PM, Kevin J Ma wrote:
Hi All,

  A couple of additional thoughts on metadata vs control for logging config:

  - While I can see an argument for using control to convey uCDN to dCDN
    logging information, because it is not content specific, it is not
    clear to me why we would need to do that logging at all.  Both the
    uCDN and the dCDN know what was transfered; the sharing of logs does
    not seem that meaningful.  Unlike when the dCDN talks to the client,
    and needs to tell the uCDN about it.

  - If we consider the control interface to be triggers, it is not clear
    that the semantics of triggers lends itself to pushing persistent
    information.  Whereas, with metadata, the logging information for a
    given piece of content would be automatically accessed on demand
    whenever the content is accessed by an end user, rather than having
    to be proactively pushed by the uCDN and maintained by the dCDN.

  - Finally, even if we consider that the optimal logging config for a
    given surrogate is the aggregate of the different logging configs
    for the different content it may server, combined with the internal
    CDN logging needs, this optimization can still be performed by the
    local CDN.  Just as with content acquisition, I would not expect all
    the surrogates use the uCDN metadata directly; I would expect some type
    of hierarchical organization of servers through which the surrogates
    acquire the content.  The metadata interface conveys inter-CDN data;
    intra-CDN per-surrogate optimization can still be performed by the
    local CDN, outside the scope of CDNI.

thanx.

--  Kevin J. Ma


-----Original Message-----
From: Kevin J Ma
Sent: Monday, November 05, 2012 12:15 PM
To: 'gilles.bertrand@orange.com'; cdni@ietf.org
Subject: RE: New version of the CDNI Logging draft posted

Hi All,

  I had a couple questions about the logging config and the use of the
control
  interface rather than the metadata interface for distributing the
config.

  - Though the config is static, it may differ for different pieces of
content?
    The metadata interface already includes provisions for apply
properties to
    specific sets of content based on URI path; logging could be a
property.

  - Though the filtering could occur higher up than the surrogates, is
that
    going to be efficient?  The surrogates would have to log all fields
for
    the upstream filtering function to work.  The extra metadata seems
small
    in comparison to the extra (unnecessary) logging data sent to the
filter?

    Furthermore, if a CP wants an additional field (e.g., X-vendor-blah
header)
    that would need to be conveyed to the surrogates to be logged?

thanx.

-- Kevin J. Ma


-----Original Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of
gilles.bertrand@orange.com
Sent: Monday, October 22, 2012 3:06 PM
To: cdni@ietf.org
Subject: [CDNi] New version of the CDNI Logging draft posted

Folks,

We have submitted a new version of the CDNI logging draft:
URL:             http://www.ietf.org/internet-drafts/draft-bertrand-

cdni-

logging-02.txt
Status:          http://datatracker.ietf.org/doc/draft-bertrand-cdni-
logging
Htmlized:        http://tools.ietf.org/html/draft-bertrand-cdni-logging-

02

Diff:            http://www.ietf.org/rfcdiff?url2=draft-bertrand-cdni-
logging-02

Best regards,

Gilles

-----Message d'origine-----
De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-

bounces@ietf.org]

De la part de internet-drafts@ietf.org
Envoyé : lundi 22 octobre 2012 20:59
À : i-d-announce@ietf.org
Objet : I-D Action: draft-bertrand-cdni-logging-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title           : CDNI Logging Interface
	Author(s)       : Gilles Bertrand
                          Stephan Emile
                          Roy Peterkofsky
                          Francois Le Faucheur
                          Pawel Grochocki
	Filename        : draft-bertrand-cdni-logging-02.txt
	Pages           : 43
	Date            : 2012-10-22

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 actual
   protocol for CDNI logging information exchange covering the
   information elements as well as the transport of those.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bertrand-cdni-logging

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bertrand-cdni-logging-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-bertrand-cdni-logging-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt



__________________________________________________________________________

_______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete
altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for
messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2742 / Virus Database: 2617/5877 - Release Date: 11/06/12


--
Roy Peterkofsky
Vice President, Product Management
Skytide -- the leader in Digital Media Performance Management
www.skytide.com
(510) 250-4284

Read our new white paper: The 4 Keys to Telco CDN Success
--------------040009050506040308040700-- From kleung@cisco.com Tue Nov 6 20:15:47 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D55F21F8BD9 for ; Tue, 6 Nov 2012 20:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJ7ZYndJGSWG for ; Tue, 6 Nov 2012 20:15:46 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2008C21F8BD5 for ; Tue, 6 Nov 2012 20:15:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2717; q=dns/txt; s=iport; t=1352261746; x=1353471346; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=6/ZdLqerwnLcc/Mnf79Zi6DPKygJzWIqdU0WB78qoII=; b=mowrD3nu+EOlBYF5bxcMOUN1PUZmQAUcgV1BBpsrYb8ciyW7WChmcaiY dt5RA8OxUKf6JKLw30ERKUVTIvKzcrIU6LsjHPm7H50irX9y5EGRWn+nT akqnPtlAJzSv3rvq6suN1YRB8VE83l/fOYfuxI5OP1FCUKK2GJQfNLvrU s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACTgmVCtJV2c/2dsb2JhbAA6CsNlgQiCHgEBAQMBEgEnRAcEAgEIEQQBAQsUCQcyFAkIAQEEARIIGodiBpsqoB6MAxCFVmEDpFSBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,725,1344211200"; d="scan'208";a="139619848" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 07 Nov 2012 04:15:45 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA74FjCq021843 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Nov 2012 04:15:45 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Tue, 6 Nov 2012 22:15:44 -0600 From: "Kent Leung (kleung)" To: Kevin J Ma , Ben Niven-Jenkins , "cdni@ietf.org" Thread-Topic: [CDNi] Comments on draft-leung-cdni-uri-signing-01 Thread-Index: Ac25Bkqo4emGLIFqKkGB8eC+X8aPWwCXhSJQADgPqqAAAmi3UAASvV7Q Date: Wed, 7 Nov 2012 04:15:44 +0000 Message-ID: References: <91A268D8-34D3-4732-ACC2-37FF91E925ED@niven-jenkins.co.uk> <291CC3F9E50E7641901A54E85D0977C6535F4FBD29@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6535F5DAD4D@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6535F5DAD4D@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.117.36] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19344.002 x-tm-as-result: No--32.560300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] Comments on draft-leung-cdni-uri-signing-01 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 04:15:47 -0000 Hi Kevin. Comments below. -----Original Message----- From: Kevin J Ma [mailto:kevin.ma@azukisystems.com]=20 Sent: Tuesday, November 06, 2012 11:00 AM To: Kent Leung (kleung); Ben Niven-Jenkins; cdni@ietf.org Subject: RE: [CDNi] Comments on draft-leung-cdni-uri-signing-01 Hi Kent, > KL> We need to discuss the purpose of CID more to see if we should=20 > KL> have > this in the base function of URI Signing. For example, CID may be=20 > split into specific identifiers such as IMSI, MEID, MAC, etc. For the=20 > other attributes, is there a need to define the allowed values? The allowed values only apply if we are going to allow substituting "equiva= lent" URI signing schemes. If not, then its not clear to me why we would n= ecessarily need to include KO/KN/HF/ALG in the query string. They could just be configuration thats never exposed to the clients. Having them in the query string allows clients to generate their own algori= thms, and opens up different attacks with fake KO/KN/HF injection? But, that kind of segues into my next comment... ;) KL>> Right, some of the attributes may not be needed in the query string if= obtained via CDNI Metadata interface. We have to figure out the tradeoffs = of how each attribute is obtained by dCDN. > The security considerations mention some fundamental issues associated = with > URL signing (i.e., spoofing, nats, long timeouts). Are we addressing t= hose > issues here, or just looking at security issues related to exchanging C= DNI > information required for doing signing, regardless of whether its a bad= scheme? >=20 > KL> These are the issues associated with URI Signing. We can consider=20 > KL> if > there are ways to mitigate them. Not clear what's meant by "regardless=20 > of whether it's a bad scheme"? URI Signing is a bad scheme in general? > Compare to another alternative? What I meant was, the WG should not be addressing the goodness or badness o= f a URI signing scheme. (I tend to find them more bad than good.) If some= one chooses an infinite expiration time, or chooses not to use a good clien= t id, or picks a bad key, etc., its a bad scheme, but that is probably inco= nsequential to the CDNI interfaces? Do we agree that the security concerns should be confined to only those con= cerns related to CDNI metadata and capabilities exchange, and should not in= clude general concerns about the goodness or badness of the supported URI s= igning scheme? KL>> I think we should identify the issues with URI Signing scheme. People = can figure out the level of concern depending on how URI Signing is used. B= ut I'm still open on this matter. Kent From kleung@cisco.com Tue Nov 6 20:15:47 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B893021F8BD9 for ; Tue, 6 Nov 2012 20:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ipmvmR2ahml for ; Tue, 6 Nov 2012 20:15:46 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9E51921F8BD7 for ; Tue, 6 Nov 2012 20:15:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8519; q=dns/txt; s=iport; t=1352261746; x=1353471346; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/T07uOEdhHIklokM8w5SllomFiRZ6zWQIDmovGSf4hk=; b=V1lpl+Pf9ITeoE9I1tEjJ1B/X6GbEahKyFC0eT6nfbcNlwO4yGtHwxPz kf/SRaiphKEEpOvOwAy6CXaU23sGrTqREdmNP99cTOhuYIZcESUlhnk0L r2fAo4nrMDnPWeRyr1+FZd1azHqFsAGZNHhze4SoqE0gwvxy0cusOz53s o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgFAJfemVCtJXG8/2dsb2JhbABBA4JJhi64MII+gQiCHwEBBBIBGkwOAgIBCAcbHQcbFxQRAQEEAQ0FCBqHaJs1oB8EjxyCSWEDlxeKGoMjgWuBLoFBghk X-IronPort-AV: E=Sophos;i="4.80,725,1344211200"; d="scan'208,217";a="139573735" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 07 Nov 2012 04:15:46 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA74FkwV018151 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Nov 2012 04:15:46 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Tue, 6 Nov 2012 22:15:45 -0600 From: "Kent Leung (kleung)" To: Dan York , Kevin J Ma Thread-Topic: [CDNi] Comments on draft-leung-cdni-uri-signing-01 Thread-Index: Ac25Bkqo4emGLIFqKkGB8eC+X8aPWwCXhSJQADgPqqAABLXcOAAQ6juQ Date: Wed, 7 Nov 2012 04:15:44 +0000 Message-ID: References: <91A268D8-34D3-4732-ACC2-37FF91E925ED@niven-jenkins.co.uk> <291CC3F9E50E7641901A54E85D0977C6535F4FBD29@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6535F5DAD4D@MAILR002.mail.lan> <7E3A2DDD-6E53-4918-9E35-56061B71329C@danyork.org> In-Reply-To: <7E3A2DDD-6E53-4918-9E35-56061B71329C@danyork.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.117.36] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19344.002 x-tm-as-result: No--24.627700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_CD85F32117029D4F9AEF48BDEF5536AB0F3C47DCxmbalnx03ciscoc_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Comments on draft-leung-cdni-uri-signing-01 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 04:15:47 -0000 --_000_CD85F32117029D4F9AEF48BDEF5536AB0F3C47DCxmbalnx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dan. I think your question was about the CDNI interface security and mo= re general than URI Signing. The CDNI Framework document states: Security of CDNI Interfaces It is noted in [I-D.ietf-cdni-requirements] that all CDNI interfaces must be able to operate securely over insecure IP networks. Since it is expected that the CDNI interfaces will be implemented using existing application protocols such as HTTP or XMPP, we also expect that the security mechanisms available to those protocols may be used by the CDNI interfaces. Details of how these interfaces are secured will be specified in the relevant interface documents. Kent On a similar note related to scope, it would be helpful if the Security Con= siderations section had some commentary about the attack surface of the exc= hange of information between the CDNs (or pointed to a document where this = is described). By that I mean, is the exchange of CDNI information happeni= ng over the public Internet? over private networks? over VPNs? or potential= ly all of the above? How accessible the exchange is to attackers can help= guide the level of necessary robustness needed in the protection of the in= formation. Dan -- Dan York dyork@lodestar2.com http://www.danyork.me/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork --_000_CD85F32117029D4F9AEF48BDEF5536AB0F3C47DCxmbalnx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dan.  I think you= r question was about the CDNI interface security and more general than URI = Signing. The CDNI Framework document states:

 <= /p>

Security of CDNI Interfac= es

 <= /p>

   It is noted = in [I-D.ietf-cdni-requirements] that all CDNI interfaces<= /p>

   must be able= to operate securely over insecure IP networks.  Since it

   is expected = that the CDNI interfaces will be implemented using

   existing app= lication protocols such as HTTP or XMPP, we also expect

   that the sec= urity mechanisms available to those protocols may be used=

   by the CDNI = interfaces.  Details of how these interfaces are secured

   will be spec= ified in the relevant interface documents.

 <= /p>

Kent

 <= /p>

<snip>=

 

On a similar note related to scope, it would be help= ful if the Security Considerations section had some commentary about the at= tack surface of the exchange of information between the CDNs (or pointed to= a document where this is described).  By that I mean, is the exchange of CDNI information happening over t= he public Internet? over private networks? over VPNs? or potentially all of= the above?   How accessible the exchange is to attackers can help gui= de the level of necessary robustness needed in the protection of the information.

 

Dan

 

-- 
Dan York  dyork@lodestar2.com
http://www.danyork.me/  &= nbsp;skype:danyork
Phone: +1-802-735-1624
Twitter - http://twitter.com/da= nyork

 <= /p>

 

 

--_000_CD85F32117029D4F9AEF48BDEF5536AB0F3C47DCxmbalnx03ciscoc_-- From kleung@cisco.com Tue Nov 6 20:15:50 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BEE21F8BDB for ; Tue, 6 Nov 2012 20:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlMfIWMvyf5J for ; Tue, 6 Nov 2012 20:15:47 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 08B1D21F8BD8 for ; Tue, 6 Nov 2012 20:15:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13751; q=dns/txt; s=iport; t=1352261747; x=1353471347; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=w6PwZqjYsRrYLIx+DVX6vzdCQUdliExAsjPIMuDMf3o=; b=kQMcnF92H4O9+2mTrpnT9vOKTFYsxAnJ+mnI2fza296gclQWRNVpiNLW Se01W9KO8C+DsVQWZpSoz5C2FHIF35jvIfDyGeIlNonN2S2iOFeOFQ7i1 smehwUZjZ1N3NCnSToZvNBdq8KbiKVsvSoeJ1y/itv1iJ8p+kGi1gbFg2 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkFACTgmVCtJXHA/2dsb2JhbABBA4JJhi64MII+gQiCHgEBAQQBAQEPARpBCw4CAgEIBwoEAQELHQcbDAsUCQgCBAEJBAUIARIHh2gLmx+gHgSLfwqDE4JJYQOXF4oagyOBa4EugUGBXR4GGA X-IronPort-AV: E=Sophos;i="4.80,725,1344211200"; d="scan'208,217";a="139359211" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 07 Nov 2012 04:15:46 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA74Fkru013970 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Nov 2012 04:15:46 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Tue, 6 Nov 2012 22:15:45 -0600 From: "Kent Leung (kleung)" To: Dan York , Ben Niven-Jenkins Thread-Topic: [CDNi] Assymetric key distribution - Re: Comments on draft-leung-cdni-uri-signing-01 Thread-Index: AQHNvFs6sRqy9WtrVkKM09QwJ+7cgZfdvocQ Date: Wed, 7 Nov 2012 04:15:45 +0000 Message-ID: References: <91A268D8-34D3-4732-ACC2-37FF91E925ED@niven-jenkins.co.uk> <598EAF9C-9A5B-4AD5-85CC-5358A985B2B8@danyork.org> In-Reply-To: <598EAF9C-9A5B-4AD5-85CC-5358A985B2B8@danyork.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.117.36] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19344.002 x-tm-as-result: No--47.152100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_CD85F32117029D4F9AEF48BDEF5536AB0F3C47E7xmbalnx03ciscoc_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Assymetric key distribution - Re: Comments on draft-leung-cdni-uri-signing-01 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 04:15:50 -0000 --_000_CD85F32117029D4F9AEF48BDEF5536AB0F3C47E7xmbalnx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dan. That's right. The dCDN needs to know that it has the correct public= key to validate the signed URI. I don't think that has been published, but= one consideration is obtaining the public key via the CDNI Metadata interf= ace. Kent From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Dan= York Sent: Tuesday, November 06, 2012 12:13 PM To: Ben Niven-Jenkins Cc: cdni@ietf.org Subject: [CDNi] Assymetric key distribution - Re: Comments on draft-leung-c= dni-uri-signing-01 Kent, Francois, Matt, Several times in the document there is a mention that for assymetric keys "= public keys can typically be distributed openly", but unless I missed it (a= nd I could have) I didn't get an understanding in the draft of *how* a CDN = could get the public key for another CDN. How would a dCDN actually get the CSP's public key? Would it retrieve it from a specific URL? from DNS? from some other PKI? fr= om some other transfer method? all of the above? I think the document should make some mention of how this distribution of t= he public key could occur. Also, I don't know that I fully agree with this statement: Key distribution for asymmetric keys does not require confidentiality since public keys can typically be distributed openly (because they cannot be used for URI signing) and private keys are kept by the URI signing function. While that is true, how does the dCDN know that it has the *correct* public= key for the CPS? What if the attacker can somehow provide the dCDN with a= public key from the attacker's site? He or she could then send updates to= the dCDN that are signed with a public key and would appear legit - it wou= ld just be the wrong public key. One potential solution would be to look at the work happening over in the D= ANE working group[1] where a certificate could be published as a DNS record= and then signed with DNSSEC[2]. This would provide a way for the dCDN to = easily get the public key for the CSP - and would also have strong integrit= y protection via DNSSEC so that the dCDN would know that it has the *correc= t* public key. My 2 cents, Dan [1] or look at http://www.internetsociety.org/deploy360/resources/dane/ for= some intro material. [2] And yes, I realize that for this to work DNSSEC would need to be more w= idely deployed but: a) that's being worked on; and b) we're talking here ab= out a defined set of users (CSPs) who would need to publish their public ke= ys in DNS and sign their zone files. Not necessarily a huge number of user= s to work with to get their zones signed and records published. On Nov 2, 2012, at 10:27 AM, Ben Niven-Jenkins wrote: Kent, Francois, Matt, >From reading draft-leung-cdni-uri-signing-01 it appears to be trying to out= line what is required for CDN "URI Signing"/"Token authorisation" as well a= s describing a particular "URI Signing" mechanism (that has a number of sig= nificant drawbacks). I'd suggest splitting these more explicitly into a more general discussion = on what the authorisation attributes that could/should be supported are, wh= at is needed on the other CDNI interfaces to support uri signing/token auth= orisation and what the use cases are for different type of signing/authoris= ation are e.g. is appending query parameters sufficient? The draft could also describe a particular algorithm/mechanism but I think = that should be in a later section or an appendix (or separate document) rat= her than being placed in the middle of the document as it is currently. Ben _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni -- Dan York dyork@lodestar2.com http://www.danyork.me/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork --_000_CD85F32117029D4F9AEF48BDEF5536AB0F3C47E7xmbalnx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dan. That’s righ= t. The dCDN needs to know that it has the correct public key to validate th= e signed URI. I don’t think that has been published, but one consider= ation is obtaining the public key via the CDNI Metadata interface.

 <= /p>

Kent

 <= /p>

From: cdni-bou= nces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Dan York
Sent: Tuesday, November 06, 2012 12:13 PM
To: Ben Niven-Jenkins
Cc: cdni@ietf.org
Subject: [CDNi] Assymetric key distribution - Re: Comments on draft-= leung-cdni-uri-signing-01

 

Kent, Francois, Matt,

 

Several times in the document there is a mention tha= t for assymetric keys "public keys can typically be distributed openly= ", but unless I missed it (and I could have) I didn't get an understan= ding in the draft of *how* a CDN could get the public key for another CDN.  

 

How would a dCDN actually get the CSP's public key?<= o:p>

 

Would it retrieve it from a specific URL? from DNS? = from some other PKI? from some other transfer method? all of the above?

 

I think the document should make some mention of how= this distribution of the public key could occur.

 

Also, I don't know that I fully agree with this stat= ement:

 

   Key distribution for asymmetric keys do= es not require

   confidentiality since public keys can t= ypically be distributed openly

   (because they cannot be used for URI si= gning) and private keys are

   kept by the URI signing function.<= /o:p>

 

While that is true, how does the dCDN know that it h= as the *correct* public key for the CPS?  What if the attacker can som= ehow provide the dCDN with a public key from the attacker's site?  He = or she could then send updates to the dCDN that are signed with a public key and would appear legit - it would just be the= wrong public key.

 

One potential solution would be to look at the work = happening over in the DANE working group[1] where a certificate could be pu= blished as a DNS record and then signed with DNSSEC[2].  This would pr= ovide a way for the dCDN to easily get the public key for the CSP - and would also have strong integrity protecti= on via DNSSEC so that the dCDN would know that it has the *correct* public = key.

 

My 2 cents,

Dan

 

[1] or look at http://www.internetsociety.org/deploy3= 60/resources/dane/ for some intro material.

 

[2] And yes, I realize that for this to work DNSSEC = would need to be more widely deployed but: a) that's being worked on; and b= ) we're talking here about a defined set of users (CSPs) who would need to = publish their public keys in DNS and sign their zone files.  Not necessarily a huge number of users to wor= k with to get their zones signed and records published.

 

 

On Nov 2, 2012, at 10:27 AM, Ben Niven-Jenkins wrote= :



Kent, Francois, Matt,

>From reading draft-leung-cdni-uri-signing-01 it appears to be trying to out= line what is required for CDN "URI Signing"/"Token authorisa= tion" as well as describing a particular "URI Signing" mecha= nism (that has a number of significant drawbacks).

I'd suggest splitting these more explicitly into a more general discussion = on what the authorisation attributes that could/should be supported are, wh= at is needed on the other CDNI interfaces to support uri signing/token auth= orisation and what the use cases are for different type of signing/authorisation are e.g. is appending quer= y parameters sufficient?

The draft could also describe a particular algorithm/mechanism but I think = that should be in a later section or an appendix (or separate document) rat= her than being placed in the middle of the document as it is currently.

Ben

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org= /mailman/listinfo/cdni

 

-- 
Dan York  dyork@lodestar2.com
http://www.danyork.me/  &= nbsp;skype:danyork
Phone: +1-802-735-1624
Twitter - http://twitter.com/da= nyork

 

 

 

--_000_CD85F32117029D4F9AEF48BDEF5536AB0F3C47E7xmbalnx03ciscoc_-- From kevin.ma@azukisystems.com Tue Nov 6 21:46:24 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E515E21F8511 for ; Tue, 6 Nov 2012 21:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2pMVpHr7jyT for ; Tue, 6 Nov 2012 21:46:22 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 03C5E21F85B6 for ; Tue, 6 Nov 2012 21:46:21 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id C890C7DF285; Wed, 7 Nov 2012 00:21:04 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 8BE547DF056; Wed, 7 Nov 2012 00:21:03 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Wed, 7 Nov 2012 00:45:55 -0500 From: Kevin J Ma To: Roy Peterkofsky Date: Wed, 7 Nov 2012 00:46:16 -0500 Thread-Topic: [CDNi] New version of the CDNI Logging draft posted Thread-Index: Ac28ifzlqVB1CzyJTdyuorHaUywsBgAHLW5A Message-ID: <291CC3F9E50E7641901A54E85D0977C6535F5DAF2E@MAILR002.mail.lan> References: <20121022185902.22651.23401.idtracker@ietfa.amsl.com> <11995_1350932778_5085992A_11995_9963_1_2AC63C9F27AF8446B0C064C50FC0A89306DA472F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <291CC3F9E50E7641901A54E85D0977C6535F5DAEF0@MAILR002.mail.lan> <5099BDE3.6050703@skytide.com> In-Reply-To: <5099BDE3.6050703@skytide.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_291CC3F9E50E7641901A54E85D0977C6535F5DAF2EMAILR002maill_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] New version of the CDNI Logging draft posted X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 05:46:25 -0000 --_000_291CC3F9E50E7641901A54E85D0977C6535F5DAF2EMAILR002maill_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Roy, > The rational for using the control interface was that we deemed it unlike= ly that, in practice, uCDNs and dCDNs would engage in the practice of speci= fying the elements to be logged and transmitted independently for each requ= est or piece of content. I'm not sure what you mean by "specifying the elements to be logged and transmitted independently for each request"? I don't see why anyone would want to change the logging config on each request. The metadata interface is not really for that purpose in any case. As for specifying logging conf= ig for "each piece of content", I would agree that doesnt make sense, but that does not mean all content should have the same logs. The metadata interfac= e is hierarchical and supports either global config or config for some subset based on URI wildcard match. It should be flexible and scalable. > 1) Add a much higher level of complexity One might argue that it allows for a much more efficient method of logging where surrogates would not need to log unnecessary data? > 2) Imply that the CDNs that provide reports to CSPs or to internal depart= ments are going to provide different reports to those constituencies about = different content We may or may not. I'm not sure why we would just rule it out? Isn't the purpose of filtering, in the draft, to generate different reports= ? > 3) Add unnecessary volume to the metadata traffic for each content elemen= t. I do not see it being that much metadata traffic. I do not see the logging config being different for every piece of content, but I would also not wan= t to constrain all logging to be the same for every piece of content. Metada= ta is specified by URI path match (with wildcards). I would expect every mpeg= ts segment for a given CP to have the same config, not a config per segment? That should only be one piece of metadata for all those mpegts segments? Having segment specific metadata would not really scale in general. thanx. -- Kevin J. Ma From: Roy Peterkofsky [mailto:roy@skytide.com] Sent: Tuesday, November 06, 2012 8:48 PM To: Kevin J Ma Cc: gilles.bertrand@orange.com; cdni@ietf.org Subject: Re: [CDNi] New version of the CDNI Logging draft posted Kevin, The rational for using the control interface was that we deemed it unlikely= that, in practice, uCDNs and dCDNs would engage in the practice of specify= ing the elements to be logged and transmitted independently for each reques= t or piece of content. What seems much more likely is that uCDNs and dCDNs= will agree in advance about which elements will be transmitted and then ad= opt that standard for all traffic transacted between the two parties. To c= ontrol the logged elements on a per-content or per-request basis would: 1) Add a much higher level of complexity to the task of capturing and trans= mitting log data on the part of the logging CDN. Most edge server streamin= g software, for example, does not have logic to capture different data elem= ents for different pieces of content. 2) Imply that the CDNs that provide reports to CSPs or to internal departme= nts are going to provide different reports to those constituencies about di= fferent content, which would also add a great deal of complexity and would = be a use this that we have not seen. CDNs typically offer the same portfol= io of reports to all of their CSP customers, for example. 3) Add unnecessary volume to the metadata traffic for each content element. While we can see some cases where logging and reporting may differ for diff= erent types of content (e.g., HAS vs. HTTP small object delivery), this is = not likely to vary by specific content element within a type of content. For these reasons, we did not think that is was most appropriate to put the= se transactions in the content-specific metadata interface. It is certainly conceivable that, someday, some CDNs might want the capabil= ity to specify logging elements differently for each content element. But = we do not know of any CDN platform providers that are even considering this= capability on their near-term or strategic roadmaps. Roy On 11/6/2012 3:38 PM, Kevin J Ma wrote: Hi All, A couple of additional thoughts on metadata vs control for logging config= : - While I can see an argument for using control to convey uCDN to dCDN logging information, because it is not content specific, it is not clear to me why we would need to do that logging at all. Both the uCDN and the dCDN know what was transfered; the sharing of logs does not seem that meaningful. Unlike when the dCDN talks to the client, and needs to tell the uCDN about it. - If we consider the control interface to be triggers, it is not clear that the semantics of triggers lends itself to pushing persistent information. Whereas, with metadata, the logging information for a given piece of content would be automatically accessed on demand whenever the content is accessed by an end user, rather than having to be proactively pushed by the uCDN and maintained by the dCDN. - Finally, even if we consider that the optimal logging config for a given surrogate is the aggregate of the different logging configs for the different content it may server, combined with the internal CDN logging needs, this optimization can still be performed by the local CDN. Just as with content acquisition, I would not expect all the surrogates use the uCDN metadata directly; I would expect some type of hierarchical organization of servers through which the surrogates acquire the content. The metadata interface conveys inter-CDN data; intra-CDN per-surrogate optimization can still be performed by the local CDN, outside the scope of CDNI. thanx. -- Kevin J. Ma -----Original Message----- From: Kevin J Ma Sent: Monday, November 05, 2012 12:15 PM To: 'gilles.bertrand@orange.com'; cdni@i= etf.org Subject: RE: New version of the CDNI Logging draft posted Hi All, I had a couple questions about the logging config and the use of the control interface rather than the metadata interface for distributing the config. - Though the config is static, it may differ for different pieces of content? The metadata interface already includes provisions for apply properties to specific sets of content based on URI path; logging could be a property. - Though the filtering could occur higher up than the surrogates, is that going to be efficient? The surrogates would have to log all fields for the upstream filtering function to work. The extra metadata seems small in comparison to the extra (unnecessary) logging data sent to the filter? Furthermore, if a CP wants an additional field (e.g., X-vendor-blah header) that would need to be conveyed to the surrogates to be logged? thanx. -- Kevin J. Ma -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of gilles.bertrand@orange.com Sent: Monday, October 22, 2012 3:06 PM To: cdni@ietf.org Subject: [CDNi] New version of the CDNI Logging draft posted Folks, We have submitted a new version of the CDNI logging draft: URL: http://www.ietf.org/internet-drafts/draft-bertrand- cdni- logging-02.txt Status: http://datatracker.ietf.org/doc/draft-bertrand-cdni- logging Htmlized: http://tools.ietf.org/html/draft-bertrand-cdni-logging- 02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-bertrand-cdni- logging-02 Best regards, Gilles -----Message d'origine----- De : i-d-announce-bounces@ietf.org [m= ailto:i-d-announce- bounces@ietf.org] De la part de internet-drafts@ietf.org Envoy=E9 : lundi 22 octobre 2012 20:59 =C0 : i-d-announce@ietf.org Objet : I-D Action: draft-bertrand-cdni-logging-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CDNI Logging Interface Author(s) : Gilles Bertrand Stephan Emile Roy Peterkofsky Francois Le Faucheur Pawel Grochocki Filename : draft-bertrand-cdni-logging-02.txt Pages : 43 Date : 2012-10-22 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 actual protocol for CDNI logging information exchange covering the information elements as well as the transport of those. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bertrand-cdni-logging There's also a htmlized version available at: http://tools.ietf.org/html/draft-bertrand-cdni-logging-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-bertrand-cdni-logging-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt __________________________________________________________________________ _______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2742 / Virus Database: 2617/5877 - Release Date: 11/06/12 -- Roy Peterkofsky Vice President, Product Management Skytide -- the leader in Digital Media Performance Management www.skytide.com (510) 250-4284 Read our new white paper: The 4 Keys to Telco CDN Success --_000_291CC3F9E50E7641901A54E85D0977C6535F5DAF2EMAILR002maill_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

= Hi Roy,

 

> The rational for using the control interfac= e was that we deemed it unlikely that, in practice, uCDNs and dCDNs would e= ngage in the practice of specifying the elements to be logged and transmitt= ed independently for each request or piece of content.=A0

 

transmitted independently fo= r each request"?=A0 I don't see why anyone would

=

want to change the logging config on each request.=A0= The metadata interface

is not r= eally for that purpose in any case.=A0 As for specifying logging config

for "each piece of content&quo= t;, I would agree that doesnt make sense, but that

does not mean all content should have the same logs.=A0 = The metadata interface

is hierar= chical and supports either global config or config for some subset

based on URI wildcard match.=A0 It shoul= d be flexible and scalable.

 

> 1) Add a much higher lev= el of complexity

 

One might argue that it allows for a muc= h more efficient method of logging

where surrogates would not need to log unnecessary data?

 

> 2) Imply that the CDNs that provide reports to CSPs or to internal = departments are going to provide different reports to those constituencies = about different content

&nb= sp;

We may or may not.=A0 I'm not sur= e why we would just rule it out?

= Isn't the purpose of filtering, in the draft, to generate different report= s?

 

<= p class=3DMsoNormal>> 3) Add unnecessary volume to the metadata traffic= for each content element.

=  

I do not see it being that muc= h metadata traffic.=A0 I do not see the logging

config being different for every piece of content, but I wo= uld also not want

to constrain a= ll logging to be the same for every piece of content.=A0 Metadata

is specified by URI path match (with wild= cards).=A0 I would expect every mpegts

segment for a given CP to have the same config, not a config per seg= ment?

That should only be one pi= ece of metadata for all those mpegts segments?

Having segment specific metadata would not really scale in g= eneral.

 =

thanx.

=  

--=A0 Kevin J. Ma

 

From: Roy P= eterkofsky [mailto:roy@skytide.com]
Sent: Tuesday, November 06, = 2012 8:48 PM
To: Kevin J Ma
Cc: gilles.bertrand@orange.= com; cdni@ietf.org
Subject: Re: [CDNi] New version of the CDNI Lo= gging draft posted

 

Kevin,

The rational for= using the control interface was that we deemed it unlikely that, in practi= ce, uCDNs and dCDNs would engage in the practice of specifying the elements= to be logged and transmitted independently for each request or piece of co= ntent.  What seems much more likely is that uCDNs and dCDNs will agree= in advance about which elements will be transmitted and then adopt that st= andard for all traffic transacted between the two parties.  To control= the logged elements on a per-content or per-request basis would:

1)= Add a much higher level of complexity to the task of capturing and transmi= tting log data on the part of the logging CDN.  Most edge server strea= ming software, for example, does not have logic to capture different data e= lements for different pieces of content.
2) Imply that the CDNs that pro= vide reports to CSPs or to internal departments are going to provide differ= ent reports to those constituencies about different content, which would al= so add a great deal of complexity and would be a use this that we have not = seen.  CDNs typically offer the same portfolio of reports to all of th= eir CSP customers, for example.
3) Add unnecessary volume to the metadat= a traffic for each content element.

While we can see some cases wher= e logging and reporting may differ for different types of content (e.g., HA= S vs. HTTP small object delivery), this is not likely to vary by specific c= ontent element within a type of content.

For these reasons, we did n= ot think that is was most appropriate to put these transactions in the cont= ent-specific metadata interface.

It is certainly conceivable that, s= omeday, some CDNs might want the capability to specify logging elements dif= ferently for each content element.  But we do not know of any CDN plat= form providers that are even considering this capability on their near-term= or strategic roadmaps.

Roy

On 11/6/2012 3:38 PM, Kevin J Ma = wrote:

Hi All,
 
=
=A0 A couple of additional thoughts on metadata vs control for logging conf=
ig:
 
=A0 - While I can see =
an argument for using control to convey uCDN to dCDN
=
=A0=A0=A0 logging information, because it is not content specific, it is no=
t
=A0=A0=A0 clear to me why we would need to do that l=
ogging at all.=A0 Both the
=A0=A0=A0 uCDN and the dCDN=
 know what was transfered; the sharing of logs does
=
=A0=A0=A0 not seem that meaningful.=A0 Unlike when the dCDN talks to the cl=
ient,
=A0=A0=A0 and needs to tell the uCDN about it.
 
=A0 - If we consider the co=
ntrol interface to be triggers, it is not clear
=A0=A0=
=A0 that the semantics of triggers lends itself to pushing persistent<=
/o:p>
=A0=A0=A0 information.=A0 Whereas, with metadata, the loggi=
ng information for a
=A0=A0=A0 given piece of content =
would be automatically accessed on demand
=A0=A0=A0 wh=
enever the content is accessed by an end user, rather than having
=A0=A0=A0 to be proactively pushed by the uCDN and maintained b=
y the dCDN.
 
=A0 - Finally,=
 even if we consider that the optimal logging config for a
= 
=A0=A0=A0 given surrogate is the aggregate of the different logging co=
nfigs
=A0=A0=A0 for the different content it may serve=
r, combined with the internal
=A0=A0=A0 CDN logging ne=
eds, this optimization can still be performed by the
=
=A0=A0=A0 local CDN.=A0 Just as with content acquisition, I would not expec=
t all
=A0=A0=A0 the surrogates use the uCDN metadata d=
irectly; I would expect some type
=A0=A0=A0 of hierarc=
hical organization of servers through which the surrogates
= 
=A0=A0=A0 acquire the content.=A0 The metadata interface conveys inter=
-CDN data;
=A0=A0=A0 intra-CDN per-surrogate optimizat=
ion can still be performed by the
=A0=A0=A0 local CDN,=
 outside the scope of CDNI.
 
thanx.
 
--=A0 Kevin J. Ma=

 
-----Original Message-----
From: Kevin J Ma
Sent: Monday, November 05, 201=
2 12:15 PM
To: 'gilles.bertrand@orange.com'; c=
dni@ietf.org
Subject: RE: New version of the CDNI =
Logging draft posted
 
Hi Al=
l,
 
=A0 I had a couple ques=
tions about the logging config and the use of the
cont=
rol
=A0 interface rather than the metadata interface f=
or distributing the
config.
=
 
=A0 - Though the config is static, it may differ for=
 different pieces of
content?
=A0=
=A0=A0 The metadata interface already includes provisions for apply
properties to
=A0=A0=A0 specific sets of=
 content based on URI path; logging could be a
propert=
y.
 
=A0 - Though the filter=
ing could occur higher up than the surrogates, is
that=

=A0=A0=A0 going to be efficient?=A0 The surrogates wo=
uld have to log all fields
for
=
=A0=A0=A0 the upstream filtering function to work.=A0 The extra metadata se=
ems
small
=A0=A0=A0 in comparison=
 to the extra (unnecessary) logging data sent to the
f=
ilter?
 
=A0=A0=A0 Furthermo=
re, if a CP wants an additional field (e.g., X-vendor-blah
=

header)
=A0=A0=A0 that would need to be conveyed =
to the surrogates to be logged?
 
thanx.
 
-- Kevin J. M=
a
 
-----Original Message-----
From: cdni-bounces@ietf.or=
g [mailto:cdni-bounces@ietf.or=
g] On Behalf Of
gilles.bertrand@orange.com
Sent: Monda=
y, October 22, 2012 3:06 PM
To: cdni@ietf.org
Subject: [CDNi] New versi=
on of the CDNI Logging draft posted
 <=
/pre>
Folks,
 
We have s=
ubmitted a new version of the CDNI logging draft:
URL:=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 http://www.ietf.org/internet-drafts/draft-bertrand=
-
cdni-
logging-02.txt
Status:=A0=A0=A0=A0=A0=A0=A0=A0=A0 http://datatracker.ietf.org/doc/draft-b=
ertrand-cdni-
logging
Htmlize=
d:=A0=A0=A0=A0=A0=A0=A0 http://tools.ietf.org/html/draft-bertrand-cdni-logging-=

02
Diff:=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 h=
ttp://www.ietf.org/rfcdiff?url2=3Ddraft-bertrand-cdni-
=

logging-02
 
Best regar=
ds,
 
Gilles
 
-----Message d'origine-----
De : i-d-anno=
unce-bounces@ietf.org [mailto:i-d-annou=
nce-
bounces@ietf.org]
De la part de internet-drafts@ietf.org
Envoy=E9&nb=
sp;: lundi 22 octobre 2012 20:59
=C0 : i-d-announce@ietf.org
Objet : I-D Action: draft-bertrand-cdni-logging-02.txt
 
 
A New Inte=
rnet-Draft is available from the on-line Internet-Drafts
directories.
 
 =
;
=A0=A0=A0 Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : CDNI Logg=
ing Interface
=A0=A0=A0 Author(s)=A0=A0=A0=A0=A0=A0 : =
Gilles Bertrand
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0Stephan Emile
=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
 Roy Peterkofsky
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Francois Le Faucheur
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 Pawel Grochocki
=A0=A0=A0 Filename=A0=A0=A0=
=A0=A0=A0=A0 : draft-bertrand-cdni-logging-02.txt
=A0=
=A0=A0 Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 43
=A0=A0=
=A0 Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2012-10-22
 
Abstract:
=A0=A0 This mem=
o specifies the Logging interface between a downstream CDN
=

=A0=A0 (dCDN) and an upstream CDN (uCDN) that are interconnected as pe=
r the
=A0=A0 CDN Interconnection (CDNI) framework.=A0 =
First, it describes a
=A0=A0 reference model for CDNI =
logging.=A0 Then, it specifies the actual
=A0=A0 proto=
col for CDNI logging information exchange covering the
=A0=A0 information elements as well as the transport of those.<=
/pre>
 
 
The IETF =
datatracker status page for this draft is:
https://datat=
racker.ietf.org/doc/draft-bertrand-cdni-logging
 
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bertrand-cdni-logging-02<=
o:p>
 
A diff from the previous v=
ersion is available at:
http://www.ietf.org/rfcdiff=
?url2=3Ddraft-bertrand-cdni-logging-02
 =

 
Internet-Drafts are also avail=
able by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
 
_________________________________________=
______
I-D-Announce mailing list
=
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: h=
ttp://www.ietf.org/shadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites=
.txt
 
 =

___________________________________________________=
_______________________
______________________________________________=
_
 
Ce message et ses pieces=
 jointes peuvent contenir des informations
confidentie=
lles ou privilegiees et ne doivent donc
pas etre diffu=
ses, exploites ou copies sans autorisation. Si vous avez
recu ce message par erreur, veuillez le signaler
a =
l'expediteur et le detruire ainsi que les pieces jointes. Les messages=

electroniques etant susceptibles d'alteration,<=
/pre>
France Telecom - Orange decline toute responsabilite si ce messag=
e a ete
altere, deforme ou falsifie. Merci.=

 
This message and its attachments may=
 contain confidential or privileged
information that m=
ay be protected by law;
they should not be distributed=
, used or copied without authorisation.
If you have re=
ceived this email in error, please notify the sender and
delete this message and its attachments.
As emails =
may be altered, France Telecom - Orange is not liable for
<= pre>messages that have been modified, changed or falsified.
Thank you.
 
_________=
______________________________________
CDNi mailing li=
st
CDNi@ietf.org<=
o:p>
https://www.ietf.org/mailman/listinfo/cdni
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni
 
 
<= pre>-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2742 / Virus Database: 2617/5877 - Relea=
se Date: 11/06/12
 
&nb=
sp;

 

--
Roy Peterkofsky<= br>Vice President, Product Management
Skytide -- the leader in Digital M= edia Performance Management
www.skyti= de.com
(510) 250-4284

Read our new white paper: The 4 Keys= to Telco CDN Success

= --_000_291CC3F9E50E7641901A54E85D0977C6535F5DAF2EMAILR002maill_-- From ben@niven-jenkins.co.uk Tue Nov 6 21:49:15 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412EF21F8681 for ; Tue, 6 Nov 2012 21:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Me34nN2W8S6 for ; Tue, 6 Nov 2012 21:49:14 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 84E5921F8686 for ; Tue, 6 Nov 2012 21:49:13 -0800 (PST) Received: from dhcp-4599.meeting.ietf.org ([130.129.69.153]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1TVyVi-0007AM-CP; Wed, 07 Nov 2012 05:49:11 +0000 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Ben Niven-Jenkins In-Reply-To: <5099BDE3.6050703@skytide.com> Date: Wed, 7 Nov 2012 05:49:07 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3577C72C-F298-4550-AB42-D59D072CC51E@niven-jenkins.co.uk> References: <20121022185902.22651.23401.idtracker@ietfa.amsl.com> <11995_1350932778_5085992A_11995_9963_1_2AC63C9F27AF8446B0C064C50FC0A89306DA472F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <291CC3F9E50E7641901A54E85D0977C6535F5DAEF0@MAILR002.mail.lan> <5099BDE3.6050703@skytide.com> To: Roy Peterkofsky X-Mailer: Apple Mail (2.1085) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] New version of the CDNI Logging draft posted X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 05:49:15 -0000 On 7 Nov 2012, at 01:48, Roy Peterkofsky wrote: > Kevin, >=20 > The rational for using the control interface was that we deemed it = unlikely that, in practice, uCDNs and dCDNs would engage in the practice = of specifying the elements to be logged and transmitted independently = for each request or piece of content. I can't see uCDNs and dCDNs engaging in the practice of specifying = elements to log for each request or piece of content but I can see folks = wanting to log different sets of fields for different hostnames. I think there is also an architectural element to this as well. IMO CDNI = Metadata should be used to convey all the 'configuration' related to = content delivery. Which fields to log is part of that configuration IMO. > What seems much more likely is that uCDNs and dCDNs will agree in = advance about which elements will be transmitted and then adopt that = standard for all traffic transacted between the two parties. To control = the logged elements on a per-content or per-request basis would: >=20 > 1) Add a much higher level of complexity to the task of capturing and = transmitting log data on the part of the logging CDN. Most edge server = streaming software, for example, does not have logic to capture = different data elements for different pieces of content. > 2) Imply that the CDNs that provide reports to CSPs or to internal = departments are going to provide different reports to those = constituencies about different content, which would also add a great = deal of complexity and would be a use this that we have not seen. CDNs = typically offer the same portfolio of reports to all of their CSP = customers, for example. Except logs aren't just about reporting. There is likely to be a 'core' = set of log fields a uCDN requires for generating its reports but there = are other fields that get logged purely for debugging for example. Some = of those fields are generic across hostnames some are specific to a = particular service running on a subset of hostnames. > 3) Add unnecessary volume to the metadata traffic for each content = element. I'm not convinced the additional volume is really all that great, = especially if you consider logging per hostname as opposed to logging = per content element. One approach is certainly for the dCDN to log for each hostname the = superset of all log fields required for all hostnames delegated by that = uCDN, i.e. what you are proposing. If different hostnames only require a subset of the superset of log = fields the dCDN is logging then you've just traded a small amount of = volume on the CDNI Metadata interface (a list of log fields per = hostname) for a potentially huge amount of log data (all the log fields = a particular CSP doesn't care about but gets anyway because a different = CSP using the same uCDN does care about them). It could be that that is a tradeoff we're happy to make, but I think it = needs more discussion first. Ben >=20 > While we can see some cases where logging and reporting may differ for = different types of content (e.g., HAS vs. HTTP small object delivery), = this is not likely to vary by specific content element within a type of = content. >=20 > For these reasons, we did not think that is was most appropriate to = put these transactions in the content-specific metadata interface. >=20 > It is certainly conceivable that, someday, some CDNs might want the = capability to specify logging elements differently for each content = element. But we do not know of any CDN platform providers that are even = considering this capability on their near-term or strategic roadmaps. >=20 > Roy >=20 > On 11/6/2012 3:38 PM, Kevin J Ma wrote: >> Hi All, >>=20 >> A couple of additional thoughts on metadata vs control for logging = config: >>=20 >> - While I can see an argument for using control to convey uCDN to = dCDN >> logging information, because it is not content specific, it is = not >> clear to me why we would need to do that logging at all. Both = the >> uCDN and the dCDN know what was transfered; the sharing of logs = does >> not seem that meaningful. Unlike when the dCDN talks to the = client, >> and needs to tell the uCDN about it. >>=20 >> - If we consider the control interface to be triggers, it is not = clear >> that the semantics of triggers lends itself to pushing persistent >> information. Whereas, with metadata, the logging information for = a >> given piece of content would be automatically accessed on demand >> whenever the content is accessed by an end user, rather than = having >> to be proactively pushed by the uCDN and maintained by the dCDN. >>=20 >> - Finally, even if we consider that the optimal logging config for = a >> given surrogate is the aggregate of the different logging configs >> for the different content it may server, combined with the = internal >> CDN logging needs, this optimization can still be performed by = the >> local CDN. Just as with content acquisition, I would not expect = all >> the surrogates use the uCDN metadata directly; I would expect = some type >> of hierarchical organization of servers through which the = surrogates >> acquire the content. The metadata interface conveys inter-CDN = data; >> intra-CDN per-surrogate optimization can still be performed by = the >> local CDN, outside the scope of CDNI. >>=20 >> thanx. >>=20 >> -- Kevin J. Ma >>=20 >>=20 >>> -----Original Message----- >>> From: Kevin J Ma >>> Sent: Monday, November 05, 2012 12:15 PM >>> To: ' >>> gilles.bertrand@orange.com'; cdni@ietf.org >>>=20 >>> Subject: RE: New version of the CDNI Logging draft posted >>>=20 >>> Hi All, >>>=20 >>> I had a couple questions about the logging config and the use of = the >>> control >>> interface rather than the metadata interface for distributing the >>> config. >>>=20 >>> - Though the config is static, it may differ for different pieces = of >>> content? >>> The metadata interface already includes provisions for apply >>> properties to >>> specific sets of content based on URI path; logging could be a >>> property. >>>=20 >>> - Though the filtering could occur higher up than the surrogates, = is >>> that >>> going to be efficient? The surrogates would have to log all = fields >>> for >>> the upstream filtering function to work. The extra metadata = seems >>> small >>> in comparison to the extra (unnecessary) logging data sent to = the >>> filter? >>>=20 >>> Furthermore, if a CP wants an additional field (e.g., = X-vendor-blah >>> header) >>> that would need to be conveyed to the surrogates to be logged? >>>=20 >>> thanx. >>>=20 >>> -- Kevin J. Ma >>>=20 >>>=20 >>>> -----Original Message----- >>>> From:=20 >>>> cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org >>>> ] On Behalf Of >>>>=20 >>>> gilles.bertrand@orange.com >>>>=20 >>>> Sent: Monday, October 22, 2012 3:06 PM >>>> To:=20 >>>> cdni@ietf.org >>>>=20 >>>> Subject: [CDNi] New version of the CDNI Logging draft posted >>>>=20 >>>> Folks, >>>>=20 >>>> We have submitted a new version of the CDNI logging draft: >>>> URL: =20 >>>> http://www.ietf.org/internet-drafts/draft-bertrand >>>> - >>>>=20 >>> cdni- >>>=20 >>>> logging-02.txt >>>> Status: =20 >>>> http://datatracker.ietf.org/doc/draft-bertrand-cdni >>>> - >>>> logging >>>> Htmlized: =20 >>>> http://tools.ietf.org/html/draft-bertrand-cdni-logging >>>> - >>>>=20 >>> 02 >>>=20 >>>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-bertrand-cdni >>>> - >>>> logging-02 >>>>=20 >>>> Best regards, >>>>=20 >>>> Gilles >>>>=20 >>>> -----Message d'origine----- >>>> De :=20 >>>> i-d-announce-bounces@ietf.org [mailto:i-d-announce >>>> - >>>>=20 >>> bounces@ietf.org >>> ] >>>=20 >>>> De la part de internet-drafts@ietf.org >>>>=20 >>>> Envoy=E9 : lundi 22 octobre 2012 20:59 >>>> =C0 :=20 >>>> i-d-announce@ietf.org >>>>=20 >>>> Objet : I-D Action: draft-bertrand-cdni-logging-02.txt >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>>=20 >>>>=20 >>>> Title : CDNI Logging Interface >>>> Author(s) : Gilles Bertrand >>>> Stephan Emile >>>> Roy Peterkofsky >>>> Francois Le Faucheur >>>> Pawel Grochocki >>>> Filename : draft-bertrand-cdni-logging-02.txt >>>> Pages : 43 >>>> Date : 2012-10-22 >>>>=20 >>>> 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 actual >>>> protocol for CDNI logging information exchange covering the >>>> information elements as well as the transport of those. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>>=20 >>>> https://datatracker.ietf.org/doc/draft-bertrand-cdni-logging >>>>=20 >>>>=20 >>>> There's also a htmlized version available at: >>>>=20 >>>> http://tools.ietf.org/html/draft-bertrand-cdni-logging-02 >>>>=20 >>>>=20 >>>> A diff from the previous version is available at: >>>>=20 >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-bertrand-cdni-logging-02 >>>>=20 >>>>=20 >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>>=20 >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>>=20 >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>=20 >>>> Internet-Draft directories:=20 >>>> http://www.ietf.org/shadow.html >>>> or >>>>=20 >>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>> = __________________________________________________________________________= >>>=20 >>>> _______________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez >>>> recu ce message par erreur, veuillez le signaler >>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages >>>> electroniques etant susceptibles d'alteration, >>>> France Telecom - Orange decline toute responsabilite si ce message = a ete >>>> altere, deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or = privileged >>>> information that may be protected by law; >>>> they should not be distributed, used or copied without = authorisation. >>>> If you have received this email in error, please notify the sender = and >>>> delete this message and its attachments. >>>> As emails may be altered, France Telecom - Orange is not liable for >>>> messages that have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>> _______________________________________________ >>>> CDNi mailing list >>>>=20 >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni >> _______________________________________________ >> CDNi mailing list >>=20 >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >>=20 >>=20 >>=20 >> ----- >> No virus found in this message. >> Checked by AVG -=20 >> www.avg.com >>=20 >> Version: 2013.0.2742 / Virus Database: 2617/5877 - Release Date: = 11/06/12 >>=20 >>=20 >>=20 >=20 >=20 > --=20 > Roy Peterkofsky > Vice President, Product Management > Skytide -- the leader in Digital Media Performance Management > www.skytide.com > (510) 250-4284 >=20 > Read our new white paper: The 4 Keys to Telco CDN Success > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Wed Nov 7 04:37:32 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54F721F8B12 for ; Wed, 7 Nov 2012 04:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5OMR0h8Fg81 for ; Wed, 7 Nov 2012 04:37:30 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 438AE21F8B0D for ; Wed, 7 Nov 2012 04:37:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3754; q=dns/txt; s=iport; t=1352291850; x=1353501450; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nmSp8OPOnyhCo+YQ8iP8nlvBlrelC7TOEfN8OFLx5iw=; b=N3k9xARVekyfJLcpcXTHgRQU84bpNo4G1O0qJSEzORCKYTybxTIGYSM1 sNVnZND57Wocmo5XzVffGSGAq7i62sTIoxHU7Rn8VRYbYCYhe1cY3S83d 3WfGO+mJ3LhuX/TfbibzUvwWkT3ENtbnWT/Aler7Jv2CzxoZMBX13UJcl o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACBVmlCtJV2b/2dsb2JhbAA6CsNfgQiCHwEBBAEBAQ8BWwsQAgEIBB4dBycLFBECBA4FCBqHaAubTqAnBIwDEIVWYQOkVIFrgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,730,1344211200"; d="scan'208,217";a="139752773" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 07 Nov 2012 12:37:29 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA7CbTeW024242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Nov 2012 12:37:29 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 06:37:28 -0600 From: "Francois Le Faucheur (flefauch)" To: "Kent Leung (kleung)" Thread-Topic: [CDNi] Comments on draft-leung-cdni-uri-signing-01 Thread-Index: AQHNuQZHXbtdFyKs7UaagzSsreOhKpfbxwQAgAG4hYCAABTKAIAAm1IAgACMLgA= Date: Wed, 7 Nov 2012 12:37:28 +0000 Message-ID: References: <91A268D8-34D3-4732-ACC2-37FF91E925ED@niven-jenkins.co.uk> <291CC3F9E50E7641901A54E85D0977C6535F4FBD29@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6535F5DAD4D@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.88.111] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19346.005 x-tm-as-result: No--39.558200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D205EBDxmbrcdx10ciscocom_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Comments on draft-leung-cdni-uri-signing-01 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 12:37:33 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D205EBDxmbrcdx10ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 6 Nov 2012, at 23:15, Kent Leung (kleung) wrote: What I meant was, the WG should not be addressing the goodness or badness o= f a URI signing scheme. (I tend to find them more bad than good.) If some= one chooses an infinite expiration time, or chooses not to use a good clien= t id, or picks a bad key, etc., its a bad scheme, but that is probably inco= nsequential to the CDNI interfaces? Do we agree that the security concerns should be confined to only those con= cerns related to CDNI metadata and capabilities exchange, and should not in= clude general concerns about the goodness or badness of the supported URI s= igning scheme? KL>> I think we should identify the issues with URI Signing scheme. People = can figure out the level of concern depending on how URI Signing is used. B= ut I'm still open on this matter. I would also think the URI Signing document needs to identify the general s= ecurity issues/limits/concerns associated with its use (or use of its parti= cular variations e.g. if IP address (or CID) is not included then it does n= ot protect against use of the URI by another enduser) and how to mitigate t= hose when possible. Francois Kent _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC236DA6F2DA77449EF2D02DF4471A8D205EBDxmbrcdx10ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <2DEBE3A8BFA5544CA2B6A785F3EAAB13@cisco.com> Content-Transfer-Encoding: quoted-printable
On 6 Nov 2012, at 23:15, Kent Leung (kleung) wrote:

What I meant was, the WG should not be addressing the goodness or ba= dness of a URI signing scheme.  (I tend to find them more bad than goo= d.)  If someone chooses an infinite expiration time, or chooses not to= use a good client id, or picks a bad key, etc., its a bad scheme, but that is probably inconsequential to the CDNI i= nterfaces?

Do we agree that the security concerns should be confined to only those con= cerns related to CDNI metadata and capabilities exchange, and should not in= clude general concerns about the goodness or badness of the supported URI s= igning scheme?

KL>> I think we should identify the issues with URI Signing scheme. P= eople can figure out the level of concern depending on how URI Signing is u= sed. But I'm still open on this matter.

I would also think the URI Signing document needs to identify the gene= ral security issues/limits/concerns associated with its use (or use of its = particular variations e.g. if IP address (or CID) is not included then it d= oes not protect against use of the URI by another enduser) and how to mitigate those when possible. 
Francois


Kent
<snip>
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

--_000_FC236DA6F2DA77449EF2D02DF4471A8D205EBDxmbrcdx10ciscocom_-- From dan-ietf@danyork.org Wed Nov 7 06:31:14 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D06021F8B14 for ; Wed, 7 Nov 2012 06:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvsPf2l3qpUg for ; Wed, 7 Nov 2012 06:31:13 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2F06921F8861 for ; Wed, 7 Nov 2012 06:31:13 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id x24so1289540iak.31 for ; Wed, 07 Nov 2012 06:31:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=4uPH/LmC3/W5MWxiCBUa1FPmmaD6ayFDifPyjwc5VTw=; b=BDDUdfazbZ1X/IGVKGgc0N16VJT/Kgc2T/L0JbnS+ja0eiMW2sb87mLj/D9hMyz1BF 4sbHbPnqqGi6FbW2mySnU8zOPVIUTUIUvTT/MDBeY/UvIwEFjOQaHCLqeJhFxbX/3bqr cB9IcOnvRtj60EqP6ffiOrpnlaw4yGJSZhrsQrf2XQvfwzD6rC+Z1SSweg85Khc3Skqb JT/Ayz+PYNc6n9vQCZAH5vsfO9Zc5NLwJdZeq0zyb2AX97FdDGX2dNkp+tOLD3Ju+nYo utHv79RP7Fb5NXTSNahBZ2wh4itUhM2hlHVgLXU6xUdEvR1ZX+IvZHvA+lqhuwTkBjfj hcnQ== Received: by 10.50.152.137 with SMTP id uy9mr4652706igb.62.1352298672679; Wed, 07 Nov 2012 06:31:12 -0800 (PST) Received: from [172.20.12.152] (cpe-74-75-92-114.maine.res.rr.com. [74.75.92.114]) by mx.google.com with ESMTPS id i10sm2009645igb.12.2012.11.07.06.31.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 06:31:12 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_1E4CEACA-9AA8-4CAC-A3DD-959F16DA459E" From: Dan York In-Reply-To: Date: Wed, 7 Nov 2012 09:31:09 -0500 Message-Id: <18FB51B8-7E93-4E81-917C-CB0A43EE5287@danyork.org> References: <91A268D8-34D3-4732-ACC2-37FF91E925ED@niven-jenkins.co.uk> <291CC3F9E50E7641901A54E85D0977C6535F4FBD29@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6535F5DAD4D@MAILR002.mail.lan> <7E3A2DDD-6E53-4918-9E35-56061B71329C@danyork.org> To: "Kent Leung (kleung)" X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkUXSKpmqtOLFXtS/aQgAURaCfWHrgf5R8x2IDuTfyexd/8jJ78jbTeu6Uv3xZlGCN8HZWG Cc: "cdni@ietf.org" Subject: Re: [CDNi] Comments on draft-leung-cdni-uri-signing-01 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 14:31:14 -0000 --Apple-Mail=_1E4CEACA-9AA8-4CAC-A3DD-959F16DA459E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ken, On Nov 6, 2012, at 11:15 PM, Kent Leung (kleung) wrote: > Hi Dan. I think your question was about the CDNI interface security = and more general than URI Signing. The CDNI Framework document states: Thank you for pointing me to this reference in the CDNI Framework = document. I would suggest for people who might someday look at this URI = Signing document to figure out how to implement it that there be a = sentence in the "Security Considerations" section along the lines of: ---- As noted in the CDNI Framework document [I-D.ietf-cdni-framework], all = CDNI interfaces must be able to operate securely over insecure IP = networks. Care should be taken to ensure that the signed URIs are = passed between CDNs using a secure transport. ---- Or something like that. My 2 cents, Dan > =20 > Security of CDNI Interfaces > =20 > It is noted in [I-D.ietf-cdni-requirements] that all CDNI = interfaces > must be able to operate securely over insecure IP networks. Since = it > is expected that the CDNI interfaces will be implemented using > existing application protocols such as HTTP or XMPP, we also expect > that the security mechanisms available to those protocols may be = used > by the CDNI interfaces. Details of how these interfaces are = secured > will be specified in the relevant interface documents. > =20 > Kent > =20 > > =20 > On a similar note related to scope, it would be helpful if the = Security Considerations section had some commentary about the attack = surface of the exchange of information between the CDNs (or pointed to a = document where this is described). By that I mean, is the exchange of = CDNI information happening over the public Internet? over private = networks? over VPNs? or potentially all of the above? How accessible = the exchange is to attackers can help guide the level of necessary = robustness needed in the protection of the information. > =20 > Dan > =20 > --=20 > Dan York dyork@lodestar2.com > http://www.danyork.me/ skype:danyork > Phone: +1-802-735-1624 > Twitter - http://twitter.com/danyork > =20 > =20 --=20 Dan York dyork@lodestar2.com http://www.danyork.me/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork --Apple-Mail=_1E4CEACA-9AA8-4CAC-A3DD-959F16DA459E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Ken,

On Nov 6, 2012, at 11:15 PM, = Kent Leung (kleung) wrote:

Hi = Dan.  I think your question was about the CDNI interface security = and more general than URI Signing. The CDNI Framework document = states:

Thank = you for pointing me to this reference in the CDNI Framework document. =  I would suggest for people who might someday look at this URI = Signing document to figure out how to implement it that there be a = sentence in the "Security Considerations" section along the lines = of:

----
As noted in the CDNI = Framework document [I-D.ietf-cdni-framework], all CDNI interfaces = must be able to operate securely over insecure IP networks.  Care = should be taken to ensure that the signed URIs are passed between CDNs = using a secure transport.
----

Or = something like that.

My 2 = cents,
Dan

   is expected that the CDNI interfaces = will be implemented using
   existing application protocols such as = HTTP or XMPP, we also expect
   that the security = mechanisms available to those protocols may be = used
   will be specified in the relevant = interface documents.
 
Kent
 
On a similar = note related to scope, it would be helpful if the Security = Considerations section had some commentary about the attack surface of = the exchange of information between the CDNs (or pointed to a document = where this is described).  By that I mean, is the exchange of CDNI = information happening over the public Internet? over private networks? = over VPNs? or potentially all of the above?   How accessible the = exchange is to attackers can help guide the level of necessary = robustness needed in the protection of the = information.


= --Apple-Mail=_1E4CEACA-9AA8-4CAC-A3DD-959F16DA459E-- From flefauch@cisco.com Wed Nov 7 06:32:05 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658DE21F8B2B for ; Wed, 7 Nov 2012 06:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-dGL33s3PGu for ; Wed, 7 Nov 2012 06:32:04 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4007E21F8B14 for ; Wed, 7 Nov 2012 06:32:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8467; q=dns/txt; s=iport; t=1352298724; x=1353508324; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BGiMn1Qk9LFedpZTsyXodo4oyPL9Og8i4huSyh6ICco=; b=NtXLIPDDFeV5cEBHjjczAhXJHEA0A86s06zpRae7+kbNMWG3CkxSep2C wZApODJgXrTSjxcXvDfsmikNY7J/7DfrRjWDHWUtZfHxHtKEzwwdD63CM Xs+fV9/amj7u57u+qM+XcyRP3LDNsMfxJuFlHhsk+D0yDiPte/kwjlrXL I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGJvmlCtJV2Z/2dsb2JhbABEw2qBCIIeAQEBAwEBAQEPARRHCwULAgEIGAokJwslAgQOBQgBGYdiBgubeaArjA2FZmEDlxeKGoMjgWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,730,1344211200"; d="scan'208";a="136742586" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 07 Nov 2012 14:32:03 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA7EW3Mt017037 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Nov 2012 14:32:03 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 08:32:02 -0600 From: "Francois Le Faucheur (flefauch)" To: Ben Niven-Jenkins Thread-Topic: [CDNi] Comments on draft-he-cdni-routing-request-redirection-03.txt Thread-Index: AQHNu64FXa+DAGW+oEeENGnPtIGCtZfdUw8AgAGDeIA= Date: Wed, 7 Nov 2012 14:32:02 +0000 Message-ID: References: <20121022030240.24155.12810.idtracker@ietfa.amsl.com> <3F5BB382-1292-4EE4-8621-52C7C5097ACC@niven-jenkins.co.uk> In-Reply-To: <3F5BB382-1292-4EE4-8621-52C7C5097ACC@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.90.49] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19346.005 x-tm-as-result: No--51.487000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <7D5876C0FDBD794BA8F62146CEE05B51@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Comments on draft-he-cdni-routing-request-redirection-03.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 14:32:05 -0000 Thanks for your responses. Looks like we're synch. Please keep track of tho= se points so they get addressed in the next rev. You may want to bring up some of those today (e.g. need for link to metadat= a in Redirection request) , specifically during the "discussion slot" for R= edirection, so we get input from others. On 6 Nov 2012, at 10:25, Ben Niven-Jenkins wrote: > Francois, >=20 > Please see below for my views. >=20 > On 5 Nov 2012, at 23:33, Francois Le Faucheur (flefauch) wrote: >=20 >> Hello, >>=20 >> (As an Individual). >>=20 >> In general, I feel this new version is going in the right direction. >>=20 >> Some high level comments: >>=20 >> * I think the spec should be less prescriptive as to how a dCDN builds = its redirection response. For example in section 6.1.1, the text says: >> "If the dCDN decides to use DNS Redirection, where the Downstream CDN >> is redirecting directly to a surrogate in the Downstream CDN: the >> Downstream CDN selects one or more surrogates and returns a CDNI RRRI >> response containing the IP addresses of the selected surrogate(s), ... >> If the dCDN decides to use DNS Redirection, where the Downstream CDN >> is redirecting to a Request Router in the dCDN: : the Downstream CDN >> returns a CDNI RRRI response containing a CNAME of the Downstream >> CDN's Request Router(s), =85 >> " >> In this example, I think the dCDN should be free to return an IP address= or a CNAME of the "redirection target" as it sees fit. The redirection tar= get may be a Surrogate, a Request Router, a set of Surrogates, a 3rd party = CDN Req Router, a 3rd party CDN Surrogate in case of cascaded CDNs,... what= ever the dCDN sees fit. >> You could possibly mention one of the behavior above as an example of wh= at might happen, but it should just be an example and I recommend the spec = be open as to the logic to populate the Redirection response. >=20 > Fair comment. Describing the different redirection possibilities & their = applicability while at the same time talking about CDNI Redirection in a mo= re generic way (so we don't keep repeating all the different nuances) was s= omething we struggled a little with and is certainly an area of the draft (= IMO) that needs more work to make the text clearer etc. >=20 > I like your idea of a 'redirection target' and maybe the right approach i= s to have a section defining/discussing the possibilities for redirection (= A/AAAA/CNAME/Application level 302/etc) to a 'redirection target' in a dCDN= and in the rest of the document just talk generically about redirection ta= rgets? >=20 >> * the document keeps talking about "encapsulating the enduser request" i= nside the Redirection Request. I find this misleading, because this is not = about encapsulating the enduser request per-say, but rather to convey the k= ey attributes of the enduser request. >=20 > Fair comment. We used 'encapsulating end user request' to distinguish bet= ween previous versions of the draft where the end user request was proxied = to a dCDN via the same protocol that the end user request was made over. >=20 > Going forward that history doesn't matter and we should use better langua= ge to describe what we are actually doing. >=20 >> * for HTTP, the Redirection Request should allow passing other attribute= s in addition to client IP address and URI. >=20 > The draft currently just tries to define the minimum necessary informatio= n for a dCDN to be able to perform a redirection. There are probably other = attributes that the dCDN would find useful and although it is not explicitl= y described in the current draft I think the CDNI Redirection 'protocol fra= mework' in draft-he easily allows passing additional optional attributes. D= escribing how to extend the 'base protocol' with additional attributes is c= ertainly something we should add in a future revision of the draft. >=20 > Personally, I am reluctant to define lots of theoretical attributes (that= no one ends up using) to be included in a CDN Redirection request but I wo= uld like to hear views from implementors on the attributes they actually us= e (or plan to use as part of CDNI) to influence surrogate selection/redirec= tion across a CDN interconnect. >=20 >> * the document requires that a pointer to Metadata be included in the Re= direction request: >> "For DNS redirection, the uCDN also needs to provide in the CDNI RRRI >> request the a link to the associated CDNI Metadata for the host/ >> domain being requested." >> Considering that the latest Metadata interface allows the dCDN to walk d= own the metadata tree for any content without seeding any initial info/poin= ters, I am not sure there is a benefit in passing a link to metadata inside= the Redirection request. If would potentially save the dCDN Request Router= to do the lookup on Content-->Metadata , but would require the uCDN Reques= t Router to do the same on its behalf. Besides the dCDN has to do that loou= p anyways to get the Metadata for serving the content. >=20 > This is in my slides for Thursday. When I was thinking about CDN Redirect= ion a while ago I convinced myself a link to CDNI Metadata was useful so wh= en I started working on draft-he I included it, but since then I've been st= ruggling to remind myself why I originally thought it was required so I'm c= ertainly open to removing it. >=20 >> * the redirection interface will need to discuss handling of URI Signing= =20 >=20 > Sure. Personally I'd like the uri signing/token authorisation work in the= WG to mature a bit more first just to avoid having to keep draft-he aligne= d with a still moving target. >=20 > At a minimum we should include in the next revision a comment that we sti= ll need to factor token authorisation into the document. >=20 >> * we need to agree on a set of acronyms to refer to the "CDNI Request Ro= uting/Redirection Interface". I will bring that up during the meeting this = week. >=20 > OK >=20 > Ben >=20 >>=20 >> HTH >>=20 >> Francois >>=20 >>=20 >> On 21 Oct 2012, at 23:02, >> wrote: >>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. >>>=20 >>>=20 >>> Title : Routing Request Redirection for CDN Interconnection >>> Author(s) : Wang Danhua (editor) >>> He Xiaoyan >>> Spencer Dawkins >>> Ge Chen >>> Ni Wei >>> Zhang Yunfei >>> Ben Niven-Jenkins >>> Filename : draft-he-cdni-routing-request-redirection-03.txt >>> Pages : 19 >>> Date : 2012-10-21 >>>=20 >>> Abstract: >>> The Request Routing Interface comprises of (1) the asynchronous >>> advertisement of footprint and capabilities by a downstream CDN that >>> allows a upstream CDN to decide whether to redirect particular user >>> requests to that downstream CDN; and (2) the synchronous operation of >>> an upstream CDN requesting whether a downstream CDN is prepared to >>> accept a user request and of a downstream CDN responding with how to >>> actually redirect the user request. This document describes an >>> interface for the latter part, i.e. the CDNI Request Routing >>> Redirection interface. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-he-cdni-routing-request-redirect= ion >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-he-cdni-routing-request-redirection-03 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-he-cdni-routing-request-redire= ction-03 >>>=20 >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 From flefauch@cisco.com Wed Nov 7 08:04:04 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8548C21F8903 for ; Wed, 7 Nov 2012 08:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.957 X-Spam-Level: X-Spam-Status: No, score=-9.957 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zfa+eEZFw8VB for ; Wed, 7 Nov 2012 08:04:02 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 49DA721F88B2 for ; Wed, 7 Nov 2012 08:04:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18914; q=dns/txt; s=iport; t=1352304242; x=1353513842; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0txzWQMqQ/x94IrjqDxzMbhg/AWnk0aHQStK2IQHM6Q=; b=CL34I107YRRQaEQ3YZwn3QoG1mxlnLQ55f9p19nenYKgUDW7EZTIVKGs qXCbkuYi+8pjPL1VlYCgduJ901v+MrDtdzGJMqXoemHCEYme5WU3ERo37 4k0NSrmqIMyvbACSOjKZ7xb5I3MoxJCs07L+dQCxxHZrddMpitDurgdoV Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAmGmlCtJXG//2dsb2JhbABEw2CBCIIeAQEBAwEBAQEPASctBwsFBwQCAQgRBAEBAQoPAgMJBycLFAkIAgQOBQgBEQEHh2IGC5wyoCWMDYMzAoIxYQOSSYROjT2Ba4JvgT4fHgEFGA X-IronPort-AV: E=Sophos;i="4.80,730,1344211200"; d="scan'208";a="139757628" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 07 Nov 2012 16:03:56 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA7G3uVD016673 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Nov 2012 16:03:56 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.252]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 10:03:56 -0600 From: "Francois Le Faucheur (flefauch)" To: Ben Niven-Jenkins Thread-Topic: [CDNi] And one more comment from review of draft-ietf-cdni-metadata-00.txt Thread-Index: AQHNt5I/3JVIIrCTM0i8+CWIoQwZ5Zfbz6eAgAMoWwA= Date: Wed, 7 Nov 2012 16:03:55 +0000 Message-ID: References: <166EBB70C264A9479E459B01B1BA6C920F404118@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.120.209] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19346.005 x-tm-as-result: No--43.203200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-cdni-metadata@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] And one more comment from review of draft-ietf-cdni-metadata-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:04:04 -0000 On 5 Nov 2012, at 10:49, Ben Niven-Jenkins wrote: > Francois, >=20 > On 31 Oct 2012, at 18:05, Francois Le Faucheur (flefauch) wrote: >=20 >> As I just reviewed cdni-framework, I noticed the text in there (in secti= on "4.6. Metadata Interface") reflecting the earlier WG agreement to allow= the uCDN to enforce access control checks itself. And in particular the fo= llowing text: >> " >> As a consequence, the Metadata interface must provide a >> means for the uCDN to express its desire to retain enforcement >> for itself. For example, this might be done by including a "check >> with me" flag in the metadata associated with certain content. >> " >> I believe this needs to be added to the set of metadata properties curre= ntly specified. >=20 > We have two possible scenarios here: > 1) UCDN wants the DCDN to validate the content with the UCDN before deliv= ering - i.e. the equivalent of setting must-revalidate in HTTP Cache-Contro= l headers. >=20 > 2) UCDN wants the DCDN to validate "the request" with the UCDN before del= ivering, e.g. because the CP/UCDN is using a uri signing/token authorisatio= n mechanism the DCDN does not support (or where the DCDN may not be trusted= to enforce the token auth?). >=20 > I think (2) is this case you & the framework are talking about. Yes. > While behaviour analogous to must-revalidate may address this requirement= , I think we should explore the requirements a bit more before we assume th= at must-revalidate is a sufficient solution. >=20 >> When you specify its detailed semantics. I'd suggest that you indicate t= hat when the flag is set, the dCDN should perform the "check-with-uCDN" aft= er validation of access controls that are present inside metadata. >=20 > Assuming we are talking about case (2) I think there are two things we ne= ed to consider: >=20 > A) Does 'check-with-uCDN' override any other metadata check or does 'chec= k-with-UCDN' add to existing metadata checks (i.e. content is only delivere= d if the metadata access controls 'pass' *and* if the 'check-with-uCDN' che= ck 'passes'). Yes. And my proposal is "add-to". >=20 > B) The actual timing, e.g. is a DCDN required to perform metadata access = control checks first before performing any check-with-uCDN or whether such = checks can be performed in parallel (this might be crossing the line into i= mplementation detail). If the rule discussed in A) above (i.e. "add-to" or "replace") is specified= unambiguously, then I am not sure we need to discuss "timing". It should n= ot matter functionally as long as the logical result is achieved and it wou= ld not affect interoperability, so I would not discuss this (or at least no= t constrain it). Francois >=20 > Ben >=20 >> In other words, I'd picture the "Check-with-uCDN" as something that can = be used "in addition" to access control rules that may be distributed to dC= DN and not "instead of". This way: >> * if the uCDN wants to have full control, it does not advertise any acc= ess control in CDNI metadata >> * if the uCDN wants to delegate some simple validations (e.g. time-wind= ow specific to a content range) and enforce on top of that some finer-grain= access control (e.g. per user), it can do so by advertising simple access = control in CDNI Metadata + "Check-with-me" flag. This allows filtering of i= nvalid requests (and possibly DOS attacks) in dCDN and scales better. >>=20 >>=20 >>=20 >> On 26 Oct 2012, at 20:45, Matt Caulfield (mcaulfie) wrote: >>=20 >>> Thank you for the detailed comments, Francois.=20 >>>=20 >>> Hoping we can address both your first batch and second batch of questio= ns relatively soon. >>>=20 >>> Matt >>>=20 >>> -----Original Message----- >>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of= Francois Le Faucheur (flefauch) >>> Sent: Friday, October 26, 2012 12:59 PM >>> To: draft-ietf-cdni-metadata@tools.ietf.org >>> Cc: cdni@ietf.org >>> Subject: [CDNi] Second batch of comments from review of draft-ietf-cdni= -metadata-00.txt >>>=20 >>> Hello, >>>=20 >>> Below are my second batch of comments (as an Individual). >>> I hope this is useful. >>>=20 >>> Francois >>>=20 >>>=20 >>>=20 >>> General comments: >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> * When used, MUST/SHOULD/MAY are used appropriately. But I recommend yo= u do a pass to verify that there is enough MUST to capture everything that = is mandatory for an implementation. For example, I am not sure there is an = explicit statement stating that all the objects/properties listed in sectio= n 3 and 4 MUST be supported. >>>=20 >>> * You provide examples of both JSON and XML encoding, which is very nic= e. I suggest you start driving a discussion on the list as to which should = be picked. Perhaps you could try list key pros&cons of each on the list? >>> When you have decided , you could then replace "example encodings" by a= specification of the encoding. >>>=20 >>>=20 >>> Specific Comments/Suggestions >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> * Section 4.3.1 Link >>> " >>> A link object may be used in place of any of the objects described abov= e. >>> " >>> I think this should be replaced by: >>> " >>> A link object may be used in place of any of the objects or properties = described above. >>> "=20 >>> because for example in the Source object (Property: auth + Property: en= dpoints + Property: protocol) each property (e.g. Protocol) can be specifie= d individually using a link. Is this right? >>>=20 >>>=20 >>>=20 >>> * section 4.3.2 Protocol: >>> " >>> This type only appears in Links.=20 >>> " >>> This is confusing because the Protocol type already appears in multiple= objects , for example in " >>> 4.2.1.1. Source >>> Property: auth >>> Description: Authentication method to use when requesting >>> content from this source. >>> Type: Auth >>> Mandatory-to-Specify: No. Default is no authentication is >>> required. >>> Property: endpoints >>> Description: Origins from which the dCDN can acquire content. >>> Type: List of EndPoint >>> Mandatory-to-Specify: Yes. >>> Property: protocol >>> Description: Protocol to use for content acquisition. >>> Type: Protocol >>> Mandatory-to-Specify: Yes. >>> " >>> Assuming I understand what you want to do correctly, perhaps you could = call the type define din 4.3.2 with a different name e.g. "ProtocolID" and = this special type would only appear inside a Link. Would that work? Or am I= entirely missing what you want to do here? >>>=20 >>>=20 >>> * section 4.3.2 Protocol: >>> " >>> The following examples are illustrative: >>> o http://url.cdni.ietf.example/protocol/delivery/http/rfcABCD >>> o http://url.cdni.ietf.example/protocol/delivery/rtmp/rfcEFGH >>> o http://url.vendorY.ietf.example/protocol/delivery/rtmp/releaseP.Q >>> " >>> I think it would be useful to use a URI if that saved you from managing= an IANA register (e.g. because there exist a URI that unambiguously points= to the spec you want to reference e.g. http://datatracker.ietf.org/doc/rfc= 2616/) but that will probably not work with /rtmp/releaseP.Q. So what is th= e benefit of using a URI here over defining an IANA register for these prot= ocol IDs? >>>=20 >>>=20 >>> * section 5: >>> OLD: >>> " >>> The interface can be used by a Downstream CDN to retrieve CDNI >>> Metadata objects either dynamically as required by the Downstream CDN >>> to process received requests (for example in response to receiving a >>> CDNI Request Routing request from an Upstream CDN or in response to >>> receiving a request for content from a User Agent) or in advance of >>> being required. >>> " >>> NEW: >>> " >>> The interface can be used by a Downstream CDN to retrieve CDNI >>> Metadata objects either dynamically as required by the Downstream CDN >>> to process received requests (for example in response to receiving a >>> CDNI Request Routing request from an Upstream CDN or in response to >>> receiving a request for content from a User Agent) or in advance of >>> being required (for example in case of Pre-positioned CDNI Metadata acq= uisition). >>> " >>>=20 >>>=20 >>> * section 5.2: >>> OLD: >>> " >>> the HostIndex which >>> provides the CDNI Metadata client with a list of Hostnames that the >>> upstream CDN may delegate to the downstream CDN. >>> " >>> NEW: >>> " >>> the HostIndex which >>> provides the CDNI Metadata client with a list of Hostnames for which th= e >>> upstream CDN may delegate content delivery to the downstream CDN. >>> " >>>=20 >>>=20 >>> * section 5.2: >>> " >>> The CDNI >>> metadata client then makes a GET request for the URI specified in the >>> href key of that Host's entry in the HostIndex. >>> " >>> I have a couple of issue with that sentence: >>> 1) the HostMetadata are found in the HostMatch entry for which there w= as a match on the Host, so the text news tweaking. >>> 2) while the HostMetadata may contain a href to the Metadata, I think = it could also actually contain the Metadata itself. If correct then, you ne= ed to tweak text to discuss both options. If incorrect then, you may need t= o tweak the text in section 4 that describes HostMatch. >>> The same comment applies also to the following paragraph re PathMetadat= a. >>>=20 >>>=20 >>> *section 5.2: >>> OLD: >>> " >>> When application level redirection (e.g. HTTP 302 redirects) is >>> being used between CDNs, it is expected that the downstream CDN will >>> be able to determine the upstream CDN that redirected a particular >>> request from information contained in the received request (e.g. via >>> the URI in case of HTTP redirection across CDNs). >>> " >>> NEW: >>> " >>> When application level redirection (e.g. HTTP 302 redirects) is >>> being used between CDNs, it is expected that the downstream CDN will >>> be able to determine the upstream CDN that redirected a particular >>> request from information contained in the received request (e.g. via >>> the URI). >>> " >>>=20 >>> *section 5.2: >>> OLD: >>> " >>> In the case of DNS redirection there is not sufficient information >>> carried in the DNS request from User Agents to determine the upstream >>> CDN that redirected a particular request and therefore downstream >>> CDNs may have to apply local policy when deciding which upstream >>> CDN's metadata to apply. >>> " >>> NEW: >>> " >>> In the case of DNS redirection there is not always sufficient informati= on >>> carried in the DNS request from User Agents to determine the upstream >>> CDN that redirected a particular request (e.g. when content from a give= n host is redirected to a given downstream CDN by more than one upstream CD= N) and therefore downstream >>> CDNs may have to apply local policy when deciding which upstream >>> CDN metadata to apply. >>> " >>>=20 >>>=20 >>> *section5.3 Bootstrapping: >>> OLD: >>> " >>> If the URI for the HostIndex object is not manually configured in the >>> downstream CDN then the HostIndex URI could be discovered via the >>> CDNI Control interface. An upstream CDN would provide the URI of the >>> HostIndex object to the downstream CDN via the CDNI Control >>> Interface. >>> " >>> NEW: >>> " >>> Mechanism allowing the downstream CDN to discover the URI of the HostIn= dex are outside the scope of this document. >>> " >>> (Depending on the base protocol leveraged to support CDNI discovery in = the future, it may or may not be obvious that this would be considered part= of the Control Interface, so I recommend we don't try second-guess future = work and leave it open) >>>=20 >>>=20 >>> OLD: >>> " >>> Table 3: MIME Media Types for CDNI Metadata resources >>> " >>> NEW: >>> " >>> Table 3: Example MIME Media Types for CDNI Metadata resources >>> " >>> (this is to make it clear that the table only contains a subset) >>>=20 >>>=20 >>> section 5.4.2: >>> " >>> Dictionary keys in JSON are case sensitive and therefore any >>> dictionary key defined by this document (for example the names of >>> CDNI Metadata object properties) MUST always be represented in >>> lowercase. >>> " >>> Are you saying that there was no choice and they had to be represented = in lower case (as suggested by "therefore") or are you saying that we need = to be case sensitive so to make it simpler you have decided to make them al= l lower case and therefore they MUST be encoded that way? If it is the form= er, please explain why. If it is the latter, then adjust text. >>>=20 >>>=20 >>> * section 5.5: >>> " >>> it is suggested that proprietary and/or custom property Metadata be >>> identified by the "ext." >>> " >>> Why not make this a stronger statement i.e. that "ext" MUST be used for= any proprietary/custom extensions? >>> Also, could we specify a rule to define the how to signal "the organiza= tion defining the property Metadata" e.g. FQDN in reverse order like ".com.= companyA"? >>>=20 >>>=20 >>>=20 >>> * section 5.5.1: >>> OLD: >>> " >>> Note: Ideally, uCDNs would not delegate content requests to a dCDN >>> which does not support the Metadata=20 >>> " >>> NEW: >>> " >>> Note: Ideally, uCDNs would never delegate content requests to a dCDN >>> which does not support the "mandatory-to-enforce" Metadata=20 >>> " >>>=20 >>>=20 >>> * section 5.5.1: >>> OLD: >>> " >>> The dCDN >>> MUST evaluate all Metadata >>> " >>> NEW: >>> " >>> This is why the dCDN >>> MUST evaluate all Metadata >>> " >>>=20 >>>=20 >>> * section 5.5.2: >>> " >>> Note: Because Metadata is inherently ordered in GenericMetadata >>> lists, as well as in the PathMetadata hierarchy and PathMatch lists, >>> multiple conflicting Metadata types MAY be used, however, Metadata >>> hierarchies MUST ensure that independent PathMatch root objects are >>> used to prevent ambiguous or conflicting Metadata definitions. >>> " >>> I don't think the term PathMatch root object is well defined. I think w= hat you want to say is that it is OK to use conflicting metadata types as l= ong as they actually never apply to the same content. Right? It may be simp= ler to express it that way. >>>=20 >>>=20 >>> *Appendix A: >>> OLD: >>> " >>> Requirements related to pre-positioning of metadata are not met >>> directly by this document. Triggering metadata pre-positioning is >>> beyond the scope of the CDNI Metadata interface. However, the >>> interface as described by this document supports pulling metadata on- >>> demand for the purpose of pre-positioning. >>> " >>> NEW: >>> " >>> Requirements related to pre-positioning of metadata are met >>> by this document on the assumption that other CDNI Interfaces are to be= used by the upstream CDN to trigger the pre-positioning of metadata by the= downstream CDN via the CDNI Metadata Interface.=20 >>> " >>>=20 >>>=20 >>> *Appendix A: >>> I think it would be useful to discuss how requirement META-7 is met: >>> " >>> META-7 [HIGH] The CDNI Metadata Distribution interface shall allow >>> the Upstream CDN to request addition and modification of >>> CDNI Metadata into the Downstream CDN. >>> " >>>=20 >>>=20 >>> *Appendix A: >>> OLD: >>> " >>> Requirement META-13 relating to feedback from the downstream CDN to >>> the upstream CDN with respect to metadata >>> " >>> NEW: >>> " >>> Requirement META-13 relating to feedback from the downstream CDN to >>> the upstream CDN with respect to rejected metadata >>> " >>>=20 >>>=20 >>> *Appendix A: >>> OLD: >>> " >>> As an >>> alternative, the downstream CDN may use the CDNI Logging interface to >>> convey error conditions related to metadata. >>> " >>> NEW: >>> " >>> As an >>> alternative, the CDNI Logging interface could be extended to convey err= or conditions related to metadata. >>> " >>>=20 >>>=20 >>> *Appendix A: >>> " >>> Requirement META-18 relating to surrogate cache behavior parameters >>> is supported via extensibility. However, the example parameters in >>> META-18 are not described in this document. >>> " >>> I know that META-18 is listed as [LOW] but I actually think that suppor= ting the "control of whether the query string of HTTP URI is to be ignored = by surrogate cache" is actually both useful and extremely simple to add. Wo= uld you be willing to add a simple binary property indicating whether query= string is to be ignored or not? >>> Interestingly, the Metadata was expected to include 3 types of info: in= fo related to acquisition, info related to authorizing, info related to how= to deliver: >>> " >>> Metadata properties >>> describe how to acquire, authorize, and deliver content from a >>> downstream CDN. >>> " >>> The Query String ignore property would be a good example of metadata re= lated to how to deliver. >>>=20 >>>=20 >>>=20 >>> Editorials: >>> =3D=3D=3D=3D=3D=3D=3D >>>=20 >>> OLD: >>> " >>> are not intended impose >>> " >>> NEW: >>> " >>> are not intended to impose >>> " >>>=20 >>>=20 >>>=20 >>> OLD: >>> " >>> document.Table 3 >>> " >>> NEW: >>> " >>> document. Table 3 >>> " >>>=20 >>>=20 >>> section 6: IANA >>> OLD: >>> " >>> This document requests the registration of the "application/cdni" >>> MIME type. >>> " >>> NEW: >>> " >>> This document requests the registration of the "application/cdni" >>> MIME Media Type under the IANA MIME Media Type registry (http://www.ian= a.org/assignments/media-types/index.html). >>>=20 >>>=20 >>>=20 >>> *section 5.5.2: >>> OLD: >>> " >>> Metadata assigned to a given content asset >>> " >>> NEW: >>> " >>> Metadata assigned to a given content >>> " >>> (asset is not part of the CDNI terminology) >>>=20 >>>=20 >>> Appendix A: >>> OLD: >>> " >>> All metadata requirements are met either directly or indirectly by >>> the CDNI Metadata Interface described in this document. The >>> following paragraphs describe notable exceptions. >>> " >>> NEW: >>> " >>> All metadata requirements are met either directly or indirectly by >>> the CDNI Metadata Interface described in this document, with the clarif= ications or exceptions=20 >>> described in the following paragraphs. >>> " >>>=20 >>> OLD: >>> " >>> " >>> NEW: >>> " >>> " >>>=20 >>>=20 >>> OLD: >>> " >>> " >>> NEW: >>> " >>> " >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 From flefauch@cisco.com Wed Nov 7 08:21:15 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C9B21F8C42 for ; Wed, 7 Nov 2012 08:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKsdRHfkKrGL for ; Wed, 7 Nov 2012 08:21:14 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 6076B21F8B75 for ; Wed, 7 Nov 2012 08:21:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=762; q=dns/txt; s=iport; t=1352305274; x=1353514874; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=s4hhWvTmrS51AXVLg1bGQDnsSIp76DgQBD59GegJZBg=; b=Nf3s5ZnRU1xDcjY/G1AkZJfAiUxaKlkJWQxtyDLbmb+opMW7JbEmsWq1 uUzw+nSh5fBbaNVH/68X0Fk5jN8OpW9S5djjajeLZwFHgTK5HgH4gFHaI I59TkrQne9LLAK6yJ18e04pf6E6eI2HUy1D3rxu4GeaLphHT2pf3tKTHF o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANSJmlCtJV2b/2dsb2JhbABEw2CBCIIfAQEEEgEnPxACAQgiFBAyJQIEDg0ah2icPKAmkXNhA6RUgWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,730,1344211200"; d="scan'208";a="139785199" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 07 Nov 2012 16:21:14 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA7GLDQg025108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Nov 2012 16:21:13 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.252]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 10:21:13 -0600 From: "Francois Le Faucheur (flefauch)" To: Ben Niven-Jenkins Thread-Topic: [CDNi] I-D Action: draft-bertrand-cdni-logging-02.txt Thread-Index: AQHNvQPn6KX8AbB/akGBgMXQIlxedQ== Date: Wed, 7 Nov 2012 16:21:13 +0000 Message-ID: References: <20121022185902.22651.23401.idtracker@ietfa.amsl.com> <021501cdb09a$9da68300$d8f38900$@comcast.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.120.209] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19346.005 x-tm-as-result: No--28.721100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <22F8E44016F7CE49AC974A00219D03AE@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , ietfdbh Subject: Re: [CDNi] I-D Action: draft-bertrand-cdni-logging-02.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:21:15 -0000 Good discussion. The next rev of the logging draft will start documenting the requirements f= or long exchange, specifically in terms of scalability and reliability. Quick question on an assumption below: >=20 > But as an example, let's assume a cache is delivering Live MS Smoothstrea= ming and the clients are requesting the manifest every 10 seconds then a CD= N will be generating 1100 log lines a second for each Gbps of traffic it is= delivering. So there are some assumption here on some average number of simultaneous vi= ewers of that Live stream, right? Just to understand this figure, can you expand a bit on how this has been d= erived, like is this based on observation in some production CDN over a num= ber of Live channels?=20 From enrico.marocco@telecomitalia.it Thu Nov 8 11:47:43 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38CF21F8B16 for ; Thu, 8 Nov 2012 11:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.069 X-Spam-Level: X-Spam-Status: No, score=-101.069 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vQ2vdVUBiY2 for ; Thu, 8 Nov 2012 11:47:43 -0800 (PST) Received: from GRFEDG702RM001.telecomitalia.it (grfedg702rm001.telecomitalia.it [217.169.121.21]) by ietfa.amsl.com (Postfix) with ESMTP id 4428B21F853D for ; Thu, 8 Nov 2012 11:47:42 -0800 (PST) Received: from grfhub703rm001.griffon.local (10.19.3.10) by GRFEDG702RM001.telecomitalia.it (10.173.88.21) with Microsoft SMTP Server (TLS) id 8.3.279.5; Thu, 8 Nov 2012 20:47:38 +0100 Received: from dhcp-11c9.meeting.ietf.org (163.162.180.246) by smtp.telecomitalia.it (10.19.9.236) with Microsoft SMTP Server (TLS) id 8.3.279.5; Thu, 8 Nov 2012 20:47:37 +0100 Message-ID: <509C0C56.2050006@telecomitalia.it> Date: Thu, 8 Nov 2012 14:47:34 -0500 From: Enrico Marocco User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "cdni@ietf.org" References: <507577DF.3020602@telecomitalia.it> In-Reply-To: <507577DF.3020602@telecomitalia.it> X-Forwarded-Message-Id: <507577DF.3020602@telecomitalia.it> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050708060605090006060303" X-TI-Disclaimer: Disclaimer1 Subject: [CDNi] Fwd: Re: [cdni-footprint] Rough Agenda for today's "CDNI Footprint/Capabilties Design Team Call" X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 19:47:44 -0000 --------------ms050708060605090006060303 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, as the chairs suggested, here's an email sent some time ago on the footprint design team list a while ago. It has both a proposal for a solution to the issue just discussed in the room, and a description of the issue itself -- in the wrong order they should appear, I agree. Enrico -------- Original Message -------- Subject: Re: [cdni-footprint] [CDNi] Rough Agenda for today's "CDNI Footprint/Capabilties Design Team Call" Date: Wed, 10 Oct 2012 15:27:59 +0200 From: Enrico Marocco To: Scott Wainner CC: Jan Seedorf , "cdni-footprint@ietf.org" At the risk of biting off more than we can chew... after giving some thought at the use cases, here's how the footprint information may look like (JSON-encoded with , and operators in brackets, to show possible alternatives): "footprint" : [ { "zone" : { "from" : { "as" : "123" , "ipv4" : "1.2.3.0/24" , "geo" : "France" , } , "include" : { "as" : [ "123" , "456" ] , "ipv4" : [ "1.2.3.0/24" ] , "geo" : "France" } , "exclude" : { "as" : [ "789" ] , "ipv4" : [ "1.2.3.128/25" ] , "geo" : "Provence" } , } , "capabilities" : { ... } } , ... ] The "capabilities" are the topic of the next call, but I guess they will include properties such as RTT, RTSP/HLS support, etc, possibly bound to the business contract. In "include" goes what we have so far called the "willing to serve" area. Little doubt that for many people that's essential. Despite being optional, the "from" attribute is necessary in at least two cases: 1. as additional information for the uCDN to make a decision (e.g. when the contractual agreement does not constitute a solid basis for using the advertized "capabilities" alone); 2. when the dCDN cannot specify an explicit coverage area. An example of point 2 is when the traffic generated by a dCDN may have an impact on the peering (or possibly transit) agreements between the dCDN itself (or the transit provider associated with it) and the networks advertized in its "willing to serve" list. The fact that such agreements are quite often resolved in court constitutes a strong disincentive for the dCDN -- that may in fact be very willing to serve -- to advertize that explicitly. Finally the "exclude" attribute is the complementary of "include", for completeness and for cases when defining what's out is easier than defining what's in. Forget the encoding if you don't like it, if people agree something along this line could be used as a starting point -- and if people actually started pointing out what they believe is missing and what's to remove -- that I guess would be good progress. Enrico On 10/10/12 5:41 AM, Scott Wainner wrote: >=20 > Jan, >=20 > I propose two use cases that may be foundational building blocks=20 > for more sophisticated use cases: >=20 > Definition: > regional coverage: The CDN has cache nodes that service a well-defined = > geographic or topologically bounded network > global coverage: The CDN has cache nodes that service any geographic=20 > region and is topologically unbounded >=20 > 1) uCDN with regional coverage delegates to one or more dCDN for global= =20 > coverage >=20 > Motivations for uCDN to delegate to dCDN might include the following: > - DECISION: uCDN client is outside the region > IMPACT: uCDN client is better served by global dCDN > CRITERIA: uCDN ascertains if the client is outside a=20 > well-defined region or IP topology > CRITERIA: uCDN ascertains if the requested content can be=20 > delivered by dCDN(s) (short list created) > CRITERIA: uCDN determines which dCDN is appropriate (chosen b= y=20 > priority) > In this use case, I think its quite simple for the uCDN to know the BGP= =20 > AS or geography covered because the uCDN is under the same=20 > administrative authority as the IP network to which it is attached. Th= e=20 > well-defined region is much more easily bounded. The global dCDN become= s=20 > a CDN of last-resort. >=20 > 2) uCDN with global coverage delegates to one or more dCDN for regional= =20 > coverage >=20 > Motivations for uCDN to delegate to dCDN might include the following: > - DECISION: uCDN client is inside a dCDN's well-defined region = > or IP topology > IMPACT: uCDN client is better served by regional dCDN > CRITERIA: uCDN ascertains if the client is inside a=20 > well-defined region or IP topology > CRITERIA: uCDN ascertains which dCDN's associated with the=20 > region can deliver the requested content (short list) > CRITERIA: uCDN determines which dCDN is appropriate (chosen b= y=20 > priority) > In this case, the uCDN needs to know the candidate regions and have the= =20 > ability to associate a client to the candidate region. That means each = > dCDN needs to advertise its candidate region to the global uCDN. The=20 > regional dCDN become CDN of preference provided the dCDN is available=20 > and capable of delivering the content. >=20 > I see three fundamental requirements: >=20 > region of coverage: either AS or geography or both > capability of delivery: services the content delivery method > availability: active and operational for servicing delivery requests >=20 > On 10/9/12 9:48 AM, Jan Seedorf wrote: >> Hi all, >> >> As rough thread for today's call, I suggest the following: >> -- short recap of the Vancouver discussions (Jan) >> -- continue discussions on capabilities >> -- discuss suggestion from Francois on focusing on some key use cases >> >> - Jan >> >> >>> -----Original Message----- >>> From: Jan Seedorf >>> Sent: Tuesday, October 02, 2012 10:49 AM >>> To: Jan Seedorf; cdni-footprint@ietf.org >>> Cc: cdni@ietf.org >>> Subject: RE: [cdni-footprint] Doodle for "CDNI Footprint/Capabilties = Design >>> Team Call" >>> >>> Based on the doodle, I suggest having design team phone calls on the >>> following dates (let's schedule two calls for now and then see where = to go >>> from there...): >>> >>> ** Tuesday, Oct. 9th, 16:00-18:00 CET ** >>> ** Tuesday, Oct. 16th, 16:00-18:00 CET ** >>> >>> On these dates most people seem to be able to join. Can someone pleas= e >>> set up a WebEx meeting for those dates and times? >>> >>> - Jan >>> >>> >>> >>>> -----Original Message----- >>>> From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- >>>> bounces@ietf.org] On Behalf Of Jan Seedorf >>>> Sent: Friday, September 28, 2012 2:42 PM >>>> To: cdni-footprint@ietf.org >>>> Cc: cdni@ietf.org >>>> Subject: [cdni-footprint] Doodle for "CDNI Footprint/Capabilties Des= ign >>> Team >>>> Call" >>>> >>>> Hi all, >>>> >>>> I created a doodle for a CDNI Footprint/Capabilties Design Team Call= : >>>> >>>> http://www.doodle.com/3u7pkrfctqa6u33g >>>> >>>> I would be good if we could make two calls in October to make progre= ss >>>> before the Atlanta meeting, so please fill in the doodle if you are = interested >>>> in joining the discussion. >>>> >>>> - Jan >>>> _______________________________________________ >>>> cdni-footprint mailing list >>>> cdni-footprint@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni-footprint >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >> . >> >=20 > _______________________________________________ > cdni-footprint mailing list > cdni-footprint@ietf.org > https://www.ietf.org/mailman/listinfo/cdni-footprint >=20 --------------ms050708060605090006060303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdzCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHOzCCBiOgAwIBAgIDBKfoMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTIwODA3MDkxNTQz WhcNMTMwODA4MDczMzM3WjB1MRkwFwYDVQQNExBvWkNPVnNYc09NME9mcExwMSgwJgYDVQQD DB9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MS4wLAYJKoZIhvcNAQkBFh9lbnJp Y28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAshI2shfUZ7P5RVcP04fJ4OfYmK/RUyokJpuJE4KaSOLArtpNtlYo6MtXfmZzA8y/ 5HChSAmPvqUwhMMYh1LurWbOdX4uKXO1gsFrPOtxTa6qin6lXaJ3bo2pKnkN9mQkjvm0E23r rrT3MC6h6UfyFAcvs01+yq9wVuxxRdC4LZTGAbXGkE34GQAnBy9eqvJ+m351hPaaVw9u8CWN uyv9YKLXpicS/q8j2EOpFBCkZVp0E8fViSXViGtuhfbW6R+TjTXJZN06DEqb/vpRSWkvBDf0 UqDFrgmlmSnXJ/xpaygAJcHyE5qjRXkIV7adTkg9Z/Z2lJXvtDUdHbNBiYcVOwIDAQABo4ID ujCCA7YwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBT1YgWCbkVCN8iNgS49Fh9R2ZC8wTAfBgNVHSMEGDAWgBRTcu2S nODaywFcfH6WNU7y1LhRgjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRh bGlhLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUH AgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHq MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRp ZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcg cGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxp bWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6 Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2 aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0 MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOC AQEAIn8FoRaqvQzo8aGNi4EbPhIMX8aPIMhX3L/N+8sMyFe3cpSyjij47DW1K330zDJnoyZs kuI10EzfK0wwY+D2qMQPGAmPDkix5t2dYQj6DKh1yBlBwAf7c65Ty1kpgtdymSptDJKVZcK6 R2CJ91oRBCZIObcWrG/0FZIr55+InAYyLDrlk34MwBmINhBZ4oRJdrzG6OC7cK4vG1ZWrAFE GHVwx1uG2NXRUXQTH9DGYcwwfPo4uinFCwHZAJ2Il/J0Mqui5x+N/7p+WUlGRyb67qxg7ect f2095+YDnbqIKIz7fGzw8XTwpjYbvWZplkG93qRXr8MRD9ukgxpxpHG2dTGCA90wggPZAgEB MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwSn6DAJBgUrDgMCGgUA oIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjExMDgx OTQ3MzRaMCMGCSqGSIb3DQEJBDEWBBTYoqDp+Z05d+/K65cQA7B8D+lFSzBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEE AYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBKfoMIGn BgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2 BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgMEp+gwDQYJKoZIhvcNAQEBBQAEggEAmwt29aT+3JMC3SFjN53ahnw3fK3kJG7F+t8dTkdN t//CMb953857+b9fjWra0FrZmqYCJdaNunlJqe+Y1fZSsV+lTNTYA8mG9q5r2evqV5lFRyh3 ChKTBzNarb0GMuQnlmt+rhl4Z3N7xXtpok9jtigZd1XENGTF/ATwuse6saTESWoxaDNKXWMx DF6DdLv8tWhcSgJweiDW8L0jIC8tjFgDsLxsQLWsOQs1dhLJdEiwyp6JzRtPpkIaU5evmocv OLs8qvDhmu99TniPpw4tSyRT2Ba8hCLsD+MgkHgpBe85Xru9e8LTCYtq7Vyc0xFSl9U9yZUr ZwEDb2ydLAkWngAAAAAAAA== --------------ms050708060605090006060303-- From flefauch@cisco.com Thu Nov 8 13:51:26 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCE621F889E for ; Thu, 8 Nov 2012 13:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Og4yHyaYssUj for ; Thu, 8 Nov 2012 13:51:25 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6C72621F85B2 for ; Thu, 8 Nov 2012 13:51:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=863; q=dns/txt; s=iport; t=1352411485; x=1353621085; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=77WBdQEq1TFspJF3CFV5sMHXFmaU5pQznAomEhWiwF8=; b=HzcndYL7kwS4tVCBaAAI5KMXA46+BFDD5wfP66i0uU5P4DFaPzfaFPHT kmb8BjzY90PDQaS/hvejK3uo060L4X/aujU9F9dqLG9A4ztdjM6W5F5si mUGMM2++RJxV+mbxQQv+DJEsjXPtywJPEa01eKMDBHGBXaA6H9J3rC8Ya U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8HAOgonFCtJV2c/2dsb2JhbABEw0KBAQeCIAEEEgEnUQEqFEInBBsah2iacYErl2mIPZF4YQOkU4Frgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,740,1344211200"; d="scan'208";a="140320374" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 08 Nov 2012 21:51:25 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA8LpORe015790 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 8 Nov 2012 21:51:24 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 15:51:24 -0600 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Acronyms for the CDNI interfaces Thread-Index: AQHNvfsyv+R0Tv5ROk6hOdIj1ufyOg== Date: Thu, 8 Nov 2012 21:51:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.91.210] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19348.005 x-tm-as-result: No--24.647600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Acronyms for the CDNI interfaces X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 21:51:26 -0000 Folks, As discussed during the Atlanta meeting, we need to agree on a set of acron= yms to designate the CDNI interfaces consistently across documents (particu= larly in figures where the full name cannot be used). A base proposal is: * "CCI" for the CDNI Control Interface * "CMI" for the CDNI Metadata distribution Interface * "CLI" for the CDNI Logging Interface * "CRI" for the CDNI request routing/Redirection Interface * "CFI" for the CDNI request routing/Footprint & capabilities advertisemen= t Interface. Let us know if you see issues with that, or if you want to offer a better p= roposal. Cheers Francois PS: some of the acronyms above probably conflict with some acronyms you've = already encountered somewhere else before, but those don't seem to be major= conflict, and it'd be nice to stick to short acronyms. = From vumip1@gmail.com Thu Nov 8 19:03:59 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0B421F85E2 for ; Thu, 8 Nov 2012 19:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPfacW2pBZ4D for ; Thu, 8 Nov 2012 19:03:58 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 21E5621F85DA for ; Thu, 8 Nov 2012 19:03:57 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id b11so2878031lam.31 for ; Thu, 08 Nov 2012 19:03:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GOrzlngF3781gErXIrtpknGXNpMV+ZiWHrN4GhWR7q4=; b=z0sf3u7U8Z02hpaU+PuFtKzqXPB7lTu2ha+hdGEHSjl/Vyji91jMMZCE6LYYUc5TNW 6BAx4jPzCDFvrzihvL7TWvKc6cUVTlxrbse50o+N1LTl+ObF+ZsB8zCdH16r7BKh13Z+ KOsV9dBS+2uHlxH/m0y8XUBvsA6J0qbT/zGa1vjW5lYvz804y6YpxfP8WkICtFVtFdAX 0hWH/CgjqjxMmtTn/1Oxrks8QhuZMlKYxd9o+bUiIXHBfis2i08j6pwa/XpKV/B2MCZS x3rp9enTKdcZDM1bCqp/S4833LhiLR1/3sSF7wTEIT54dft44CYVTlSz50vNYKay23OI h8bQ== MIME-Version: 1.0 Received: by 10.152.106.110 with SMTP id gt14mr9390151lab.1.1352430226527; Thu, 08 Nov 2012 19:03:46 -0800 (PST) Received: by 10.114.3.66 with HTTP; Thu, 8 Nov 2012 19:03:46 -0800 (PST) In-Reply-To: References: Date: Thu, 8 Nov 2012 22:03:46 -0500 Message-ID: From: "B.Khasnabish@ieee.org" To: "Francois Le Faucheur (flefauch)" Content-Type: multipart/alternative; boundary=f46d040711673c55a504ce073331 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Acronyms for the CDNI interfaces X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 03:03:59 -0000 --f46d040711673c55a504ce073331 Content-Type: text/plain; charset=ISO-8859-1 Hi Francois, Thanks. This is a good start. As you know, "CLI" is widely used for "Command Line Interface," (http://en.wikipedia.org/wiki/Command-line_interface) so let us consider something different for "CDNI Logging Interface"... Best. Bhumip On Thu, Nov 8, 2012 at 4:51 PM, Francois Le Faucheur (flefauch) < flefauch@cisco.com> wrote: > Folks, > > As discussed during the Atlanta meeting, we need to agree on a set of > acronyms to designate the CDNI interfaces consistently across documents > (particularly in figures where the full name cannot be used). > > A base proposal is: > * "CCI" for the CDNI Control Interface > * "CMI" for the CDNI Metadata distribution Interface > * "CLI" for the CDNI Logging Interface > * "CRI" for the CDNI request routing/Redirection Interface > * "CFI" for the CDNI request routing/Footprint & capabilities > advertisement Interface. > > Let us know if you see issues with that, or if you want to offer a better > proposal. > > Cheers > > Francois > > PS: some of the acronyms above probably conflict with some acronyms you've > already encountered somewhere else before, but those don't seem to be major > conflict, and it'd be nice to stick to short acronyms. > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > --f46d040711673c55a504ce073331 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Francois,
=A0
Thanks. This is a good start.
=A0
As you know, "CLI" is widely used for "Command Line Int= erface,"
so let us consider something different for "CDNI Logging Interfac= e"...
=A0
Best.
=A0
Bhumip


=A0
On Thu, Nov 8, 2012 at 4:51 PM, Francois Le Fauc= heur (flefauch) <flefauch@cisco.com> wrote:
Folks,

As discussed during the= Atlanta meeting, we need to agree on a set of acronyms to designate the CD= NI interfaces consistently across documents (particularly in figures where = the full name cannot be used).

A base proposal is:
=A0 =A0 =A0 =A0 * "CCI" for the CDNI C= ontrol Interface
=A0 =A0 =A0 =A0 * "CMI" for the CDNI Metadata= distribution Interface
=A0 =A0 =A0 =A0 * "CLI" for the CDNI L= ogging Interface
=A0 =A0 =A0 =A0 * "CRI" for the CDNI request routing/Redirection = Interface
=A0 =A0 =A0 =A0 * "CFI" for the CDNI request routing= /Footprint & capabilities advertisement Interface.

Let us know i= f you see issues with that, or if you want to offer a better proposal.

Cheers

Francois

PS: some of the acronyms above probably c= onflict with some acronyms you've already encountered somewhere else be= fore, but those don't seem to be major conflict, and it'd be nice t= o stick to short acronyms.
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailm= an/listinfo/cdni



=A0 --f46d040711673c55a504ce073331-- From flefauch@cisco.com Fri Nov 9 05:36:59 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD0D21F8680 for ; Fri, 9 Nov 2012 05:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.548 X-Spam-Level: X-Spam-Status: No, score=-10.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nz8dG2f1sY5 for ; Fri, 9 Nov 2012 05:36:58 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D703721F85C0 for ; Fri, 9 Nov 2012 05:36:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4905; q=dns/txt; s=iport; t=1352468218; x=1353677818; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wzqcPLywYQUE1IX8B808Z6vsfKcmVAxMQBzde/9Iyjs=; b=d3COeBQd836Mf3qf1bUoWDjXMqBnLYpwFYSWE6OQfvrFsHg1LbSJg+4g BKA+0mw/76RP/02sONlP2gPzV/4HS/8CNfuFVEbTp1Uv3ZydUCVx1UM3c OSaFwuii2PhXuBFQXodDVGXzwQnbwPd4t0W9e5sjOFxhW6SjnmD5v52sh U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALMGnVCtJV2a/2dsb2JhbABEulWIdYEIgh8BAQQBAQEPAVsLEAIBCAQeHQcnCxQRAgQOBQgah2gLnReXV4g9jBKFZ2EDpFOBa4Jvghk X-IronPort-AV: E=McAfee;i="5400,1158,6890"; a="140558646" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 09 Nov 2012 13:36:57 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA9DavBi031545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Nov 2012 13:36:57 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Fri, 9 Nov 2012 07:36:56 -0600 From: "Francois Le Faucheur (flefauch)" To: "B.Khasnabish@ieee.org" Thread-Topic: [CDNi] Acronyms for the CDNI interfaces Thread-Index: AQHNvfsyv+R0Tv5ROk6hOdIj1ufyOpfhNkkAgACw7AA= Date: Fri, 9 Nov 2012 13:36:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.194] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19350.005 x-tm-as-result: No--41.371000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D21D36Axmbrcdx10ciscocom_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Acronyms for the CDNI interfaces X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 13:36:59 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D21D36Axmbrcdx10ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 9 Nov 2012, at 04:03, B.Khasnabish@ieee.org wrote: Hi Francois, Thanks. This is a good start. As you know, "CLI" is widely used for "Command Line Interface," (http://en.wikipedia.org/wiki/Command-line_interface) so let us consider something different for "CDNI Logging Interface"=85 "CLoI" ? Best. Bhumip On Thu, Nov 8, 2012 at 4:51 PM, Francois Le Faucheur (flefauch) > wrote: Folks, As discussed during the Atlanta meeting, we need to agree on a set of acron= yms to designate the CDNI interfaces consistently across documents (particu= larly in figures where the full name cannot be used). A base proposal is: * "CCI" for the CDNI Control Interface * "CMI" for the CDNI Metadata distribution Interface * "CLI" for the CDNI Logging Interface * "CRI" for the CDNI request routing/Redirection Interface * "CFI" for the CDNI request routing/Footprint & capabilities adver= tisement Interface. Let us know if you see issues with that, or if you want to offer a better p= roposal. Cheers Francois PS: some of the acronyms above probably conflict with some acronyms you've = already encountered somewhere else before, but those don't seem to be major= conflict, and it'd be nice to stick to short acronyms. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC236DA6F2DA77449EF2D02DF4471A8D21D36Axmbrcdx10ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On 9 Nov 2012, at 04:03, B.Kh= asnabish@ieee.org wrote:

Hi Francois,
 
Thanks. This is a good start.
 
As you know, "CLI" is widely used for "Command Line Int= erface,"
so let us consider something different for "CDNI Logging Interfac= e"=85

"CLoI" ?

 
Best.
 
Bhumip


 
On Thu, Nov 8, 2012 at 4:51 PM, Francois Le Fauc= heur (flefauch) <flefauch@cisco.com> wrote:
Folks,

As discussed during the Atlanta meeting, we need to agree on a set of acron= yms to designate the CDNI interfaces consistently across documents (particu= larly in figures where the full name cannot be used).

A base proposal is:
        * "CCI" for the CDNI Control Interfac= e
        * "CMI" for the CDNI Metadata distrib= ution Interface
        * "CLI" for the CDNI Logging Interfac= e
        * "CRI" for the CDNI request routing/= Redirection Interface
        * "CFI" for the CDNI request routing/= Footprint & capabilities advertisement Interface.

Let us know if you see issues with that, or if you want to offer a better p= roposal.

Cheers

Francois

PS: some of the acronyms above probably conflict with some acronyms you've = already encountered somewhere else before, but those don't seem to be major= conflict, and it'd be nice to stick to short acronyms.
_______________________________________________
CDNi mailing list
CDNi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cdni



 

--_000_FC236DA6F2DA77449EF2D02DF4471A8D21D36Axmbrcdx10ciscocom_-- From kevin.ma@azukisystems.com Fri Nov 9 05:58:36 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDC221F853A for ; Fri, 9 Nov 2012 05:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKyUVLwQk3cK for ; Fri, 9 Nov 2012 05:58:34 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 939D121F8533 for ; Fri, 9 Nov 2012 05:58:34 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 7F91D416ACB; Fri, 9 Nov 2012 02:53:39 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 5519C416BB4; Fri, 9 Nov 2012 02:53:38 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Fri, 9 Nov 2012 08:58:09 -0500 From: Kevin J Ma To: "Francois Le Faucheur (flefauch)" , "B.Khasnabish@ieee.org" Date: Fri, 9 Nov 2012 08:58:30 -0500 Thread-Topic: [CDNi] Acronyms for the CDNI interfaces Thread-Index: AQHNvfsyv+R0Tv5ROk6hOdIj1ufyOpfhNkkAgACw7AD//59c0A== Message-ID: <291CC3F9E50E7641901A54E85D0977C6535F5DB898@MAILR002.mail.lan> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_291CC3F9E50E7641901A54E85D0977C6535F5DB898MAILR002maill_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Acronyms for the CDNI interfaces X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 13:58:36 -0000 --_000_291CC3F9E50E7641901A54E85D0977C6535F5DB898MAILR002maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The "C" is somewhat superfluous? We could drop all the "C"s. CI, MI, LI, RI, and FI? And, at the risk of opening a rat hole, "FI" seems to imply that footprint is more important than capabilities... :) "FCI"? From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Fra= ncois Le Faucheur (flefauch) Sent: Friday, November 09, 2012 8:37 AM To: B.Khasnabish@ieee.org Cc: cdni@ietf.org Subject: Re: [CDNi] Acronyms for the CDNI interfaces On 9 Nov 2012, at 04:03, B.Khasnabish@ieee.org wrote: Hi Francois, Thanks. This is a good start. As you know, "CLI" is widely used for "Command Line Interface," (http://en.wikipedia.org/wiki/Command-line_interface) so let us consider something different for "CDNI Logging Interface"... "CLoI" ? Best. Bhumip On Thu, Nov 8, 2012 at 4:51 PM, Francois Le Faucheur (flefauch) > wrote: Folks, As discussed during the Atlanta meeting, we need to agree on a set of acron= yms to designate the CDNI interfaces consistently across documents (particu= larly in figures where the full name cannot be used). A base proposal is: * "CCI" for the CDNI Control Interface * "CMI" for the CDNI Metadata distribution Interface * "CLI" for the CDNI Logging Interface * "CRI" for the CDNI request routing/Redirection Interface * "CFI" for the CDNI request routing/Footprint & capabilities adver= tisement Interface. Let us know if you see issues with that, or if you want to offer a better p= roposal. Cheers Francois PS: some of the acronyms above probably conflict with some acronyms you've = already encountered somewhere else before, but those don't seem to be major= conflict, and it'd be nice to stick to short acronyms. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_291CC3F9E50E7641901A54E85D0977C6535F5DB898MAILR002maill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The "C" is somewhat su= perfluous?  We could drop all the "C"s.

CI, MI, LI, RI, and FI?

 

And, at the risk of opening a rat hole, "FI" seems = to imply

that footprint is more important than ca= pabilities...  :)

"FCI"?

 

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On= Behalf Of Francois Le Faucheur (flefauch)
Sent: Friday, Nove= mber 09, 2012 8:37 AM
To: B.Khasnabish@ieee.org
Cc: cdn= i@ietf.org
Subject: Re: [CDNi] Acronyms for the CDNI interfaces

 

<= p class=3DMsoNormal> 

On = 9 Nov 2012, at 04:03, B.Khasnabish= @ieee.org wrote:



=

Hi Francois,

<= p class=3DMsoNormal> 

Th= anks. This is a good start.

&= nbsp;

As you know, "CLI&= quot; is widely used for "Command Line Interface,"


<= br>

Best.

Bhumip

On Thu, Nov 8, 2012 at 4:51 PM, Francois Le Faucheur (flefa= uch) <flefauch@c= isco.com> wrote:

Folks,

As= discussed during the Atlanta meeting, we need to agree on a set of acronym= s to designate the CDNI interfaces consistently across documents (particula= rly in figures where the full name cannot be used).

A base proposal = is:
        * "CCI" for the CDNI Control I= nterface
        * "CMI" for the CDNI Meta= data distribution Interface
        * "CLI"= ; for the CDNI Logging Interface
        * "CRI= " for the CDNI request routing/Redirection Interface
    =     * "CFI" for the CDNI request routing/Footprint &= ; capabilities advertisement Interface.

Let us know if you see issue= s with that, or if you want to offer a better proposal.

Cheers
Francois

PS: some of the acronyms above probably conflict with som= e acronyms you've already encountered somewhere else before, but those don'= t seem to be major conflict, and it'd be nice to stick to short acronyms._______________________________________________
CDNi mailing list
<= a href=3D"mailto:CDNi@ietf.org">CDNi@ietf.org
https://www.ietf.org/mai= lman/listinfo/cdni




 

 

= --_000_291CC3F9E50E7641901A54E85D0977C6535F5DB898MAILR002maill_-- From flefauch@cisco.com Fri Nov 9 06:07:53 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BD821F86AA for ; Fri, 9 Nov 2012 06:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.555 X-Spam-Level: X-Spam-Status: No, score=-10.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFPyzE2xfVAE for ; Fri, 9 Nov 2012 06:07:52 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0F13121F8695 for ; Fri, 9 Nov 2012 06:07:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15046; q=dns/txt; s=iport; t=1352470072; x=1353679672; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=z6ofDInSOGr4A9NLNF1p0P4l7TLLfDNIDJ4UU8+6sIA=; b=ARHG0881qkHmpNhxzOiLorgbwrn1PTfGqpkmDNytv8dQ3ycvy8IwG+my 0D8FUED4i2r8waCkabuauxYqRisE86BqQO+cIjx3W3LxCxM9Byp6Irp0z UJWIsOBJ8SA1+PgSDUIWL9oR7QDo05+ruBZy96TAYQg4stGRrcUNkZFsa M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANgNnVCtJV2a/2dsb2JhbABEgkm4DIh1gQiCHgEBAQQBAQEPAVsLEAIBCBEEAQELHQcnCxQJCAIEDgUIGodoC50al1WIPYwShWdhA6RTgWuCb4IZ X-IronPort-AV: E=McAfee;i="5400,1158,6890"; a="140547895" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 09 Nov 2012 14:07:28 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA9E7Swo016271 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Nov 2012 14:07:28 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Fri, 9 Nov 2012 08:07:27 -0600 From: "Francois Le Faucheur (flefauch)" To: Kevin J Ma Thread-Topic: [CDNi] Acronyms for the CDNI interfaces Thread-Index: AQHNvfsyv+R0Tv5ROk6hOdIj1ufyOpfhNkkAgACw7AD//59c0IAAaSwA Date: Fri, 9 Nov 2012 14:07:27 +0000 Message-ID: References: <291CC3F9E50E7641901A54E85D0977C6535F5DB898@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6535F5DB898@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.194] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19350.005 x-tm-as-result: No--46.382900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D21D6A6xmbrcdx10ciscocom_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Acronyms for the CDNI interfaces X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 14:07:53 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D21D6A6xmbrcdx10ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Works for me. So latest proposal on the table is: * CI, MI, LI, RI, FCI PS: and no, the "I" is not superfluous 8^) On 9 Nov 2012, at 14:58, Kevin J Ma wrote: The "C" is somewhat superfluous? We could drop all the "C"s. CI, MI, LI, RI, and FI? And, at the risk of opening a rat hole, "FI" seems to imply that footprint is more important than capabilities... :) "FCI"? From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Francois Le Faucheur (flefauch) Sent: Friday, November 09, 2012 8:37 AM To: B.Khasnabish@ieee.org Cc: cdni@ietf.org Subject: Re: [CDNi] Acronyms for the CDNI interfaces On 9 Nov 2012, at 04:03, B.Khasnabish@ieee.org wrote: Hi Francois, Thanks. This is a good start. As you know, "CLI" is widely used for "Command Line Interface," (http://en.wikipedia.org/wiki/Command-line_interface) so let us consider something different for "CDNI Logging Interface"=85 "CLoI" ? Best. Bhumip On Thu, Nov 8, 2012 at 4:51 PM, Francois Le Faucheur (flefauch) > wrote: Folks, As discussed during the Atlanta meeting, we need to agree on a set of acron= yms to designate the CDNI interfaces consistently across documents (particu= larly in figures where the full name cannot be used). A base proposal is: * "CCI" for the CDNI Control Interface * "CMI" for the CDNI Metadata distribution Interface * "CLI" for the CDNI Logging Interface * "CRI" for the CDNI request routing/Redirection Interface * "CFI" for the CDNI request routing/Footprint & capabilities adver= tisement Interface. Let us know if you see issues with that, or if you want to offer a better p= roposal. Cheers Francois PS: some of the acronyms above probably conflict with some acronyms you've = already encountered somewhere else before, but those don't seem to be major= conflict, and it'd be nice to stick to short acronyms. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC236DA6F2DA77449EF2D02DF4471A8D21D6A6xmbrcdx10ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <13BF5EDD4808A94584F7D667A88450A9@cisco.com> Content-Transfer-Encoding: quoted-printable
Works for me. So latest proposal on the table is:

* CI, = MI, LI, RI, FCI


PS: and no, the "I" is not superfluous 8^)

On 9 Nov 2012, at 14:58, Kevin J Ma wrote:

The "C&q= uot; is somewhat superfluous?  We could drop all the "C"s.
CI, MI, LI, R= I, and FI?
 
And, at the r= isk of opening a rat hole, "FI" seems to imply<= /div>
that footprin= t is more important than capabilities...  :)
"FCI&quo= t;?
 
From:=  cdn= i-bounces@ietf.org [m= ailto:cdni-bounces@ietf.org] On Behalf Of Francois L= e Faucheur (flefauch)
Sent: Friday, Nove= mber 09, 2012 8:37 AM
To: B.Khasnabish@ieee.org
Cc: cdni= @ietf.org
Subject: Re: [CDNi= ] Acronyms for the CDNI interfaces
 
 
On 9 Nov 2012, at 04:03, = B.Khasnabish@ieee.org wrote:


Hi Francois,
 
Thanks. This is a good start.
 
As you know, "CLI" is widely used for "Command Line Interfac= e,"
so let us consider something different for "CDNI Logging Interface&quo= t;=85
 
"CLoI" ?


 
Best.
 
Bhumip


 
On Thu, Nov 8, 2012 at 4:51 PM, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote:
Folks,

As discussed during the Atlanta meeting, we need to agree on a set of acron= yms to designate the CDNI interfaces consistently across documents (particu= larly in figures where the full name cannot be used).

A base proposal is:
        * "CCI" for the CDNI Control Interfac= e
        * "CMI" for the CDNI Metadata distrib= ution Interface
        * "CLI" for the CDNI Logging Interfac= e
        * "CRI" for the CDNI request routing/= Redirection Interface
        * "CFI" for the CDNI request routing/= Footprint & capabilities advertisement Interface.

Let us know if you see issues with that, or if you want to offer a better p= roposal.

Cheers

Francois

PS: some of the acronyms above probably conflict with some acronyms you've = already encountered somewhere else before, but those don't seem to be major= conflict, and it'd be nice to stick to short acronyms.
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mail= man/listinfo/cdni



 
 

--_000_FC236DA6F2DA77449EF2D02DF4471A8D21D6A6xmbrcdx10ciscocom_-- From flefauch@cisco.com Fri Nov 9 07:04:49 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8E821F86F9 for ; Fri, 9 Nov 2012 07:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pooGbprcsLrB for ; Fri, 9 Nov 2012 07:04:48 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8D91321F86D8 for ; Fri, 9 Nov 2012 07:04:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=550; q=dns/txt; s=iport; t=1352473488; x=1353683088; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=NfXQhEtIfCZtPq5iiXCJXAcww02b5Hw4mAE4lzjf1iQ=; b=WxE3mss+bfhd+Gpsit5tFbeXpcleFWFr1+aWXYfJMbQpYYzW2mniDqwt dwGqxFJ8gqYBeHYqWhAQs7LXEwa1pJV2dVehcz9wL9nwCVpjiVX40aGkk XqDXs7f94rT6P6ZzJyDwgHhLPvQbs5XKQjNG6M2npXVqJJqjCI5T+ebk5 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcYADcbnVCtJV2Z/2dsb2JhbABEhASBTr1vgQEHgiABBBIBJ1EBKhRCJwQbARmHaAucCoEroBORfWEDpFOBa4Jvghk X-IronPort-AV: E=McAfee;i="5400,1158,6890"; a="140372733" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 09 Nov 2012 15:04:45 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA9F4jiS007939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 9 Nov 2012 15:04:45 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Fri, 9 Nov 2012 09:04:44 -0600 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Draft IETF-85 minutes posted Thread-Index: AQHNvouMpeQod5tGtUKHlbf8oHgh3A== Date: Fri, 9 Nov 2012 15:04:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.194] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19350.005 x-tm-as-result: No--29.094800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <9B9FAAB33ECCFC4A9C6CB0B4223AC75F@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Draft IETF-85 minutes posted X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 15:04:49 -0000 Folks, Draft minutes for our two CDNI sessions of IETF-85 have been posted. You ca= n access them from the IETF-85 Meeting Material page or directly from: http://www.ietf.org/proceedings/85/minutes/minutes-85-cdni. Thanks to Marcin for providing raw notes.=20 We could not quite capture all statements of the discussion in some occurre= nces, and the audio recording won't be available for a little while, but th= e draft minutes aim at capturing the essential of the discussion. Corrections/comments welcome. Cheers Francois= From ray.vanbrandenburg@tno.nl Fri Nov 9 07:13:47 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0AF521F8D6B for ; Fri, 9 Nov 2012 07:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20JD0UY4H0fj for ; Fri, 9 Nov 2012 07:13:46 -0800 (PST) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id B702E21F8CD0 for ; Fri, 9 Nov 2012 07:13:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,746,1344204000"; d="scan'208";a="16703153" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 09 Nov 2012 16:13:42 +0100 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.243]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.02.0298.004; Fri, 9 Nov 2012 16:13:42 +0100 From: "Brandenburg, R. (Ray) van" To: "Francois Le Faucheur (flefauch)" Thread-Topic: [CDNi] Draft IETF-85 minutes posted Thread-Index: AQHNvozNMuHks/gv9UW5xtE3wq0mbQ== Date: Fri, 9 Nov 2012 15:13:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "cdni@ietf.org" Subject: Re: [CDNi] Draft IETF-85 minutes posted X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 15:13:47 -0000 Hi Francois, One comment: the minutes note that the last presentation on Thursday was me= presenting the HAS experiments draft, while it was actually Bhumip present= ing the Intra-CDN providers draft (we diverged from the agenda). Ray On 9 nov. 2012, at 10:04, "Francois Le Faucheur (flefauch)" wrote: > Folks, > = > Draft minutes for our two CDNI sessions of IETF-85 have been posted. You = can access them from the IETF-85 Meeting Material page or directly from: > http://www.ietf.org/proceedings/85/minutes/minutes-85-cdni. > = > Thanks to Marcin for providing raw notes. = > = > We could not quite capture all statements of the discussion in some occur= rences, and the audio recording won't be available for a little while, but = the draft minutes aim at capturing the essential of the discussion. > = > Corrections/comments welcome. > = > Cheers > = > Francois > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From kevin.ma@azukisystems.com Fri Nov 9 14:57:17 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9AEF21F862A for ; Fri, 9 Nov 2012 14:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPgjB+RpeYtu for ; Fri, 9 Nov 2012 14:57:16 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD5B21F861C for ; Fri, 9 Nov 2012 14:57:16 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 1697C8BF21F; Fri, 9 Nov 2012 17:57:16 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 97FA88BF20F; Fri, 9 Nov 2012 17:57:15 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Fri, 9 Nov 2012 17:56:52 -0500 From: Kevin J Ma To: Jeroen Famaey , "cdni@ietf.org" Date: Fri, 9 Nov 2012 17:57:15 -0500 Thread-Topic: [CDNi] New draft submitted draft-famaey-cdni-has-experiments-00 Thread-Index: Ac2clXYyrzFw/IwKTxiVsOT+5F0G8AiEvNlQ Message-ID: <291CC3F9E50E7641901A54E85D0977C6535F6910DD@MAILR002.mail.lan> References: <83440700-EEF7-4738-BA59-083AB4B2ED4E@intec.ugent.be> In-Reply-To: <83440700-EEF7-4738-BA59-083AB4B2ED4E@intec.ugent.be> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_291CC3F9E50E7641901A54E85D0977C6535F6910DDMAILR002maill_" MIME-Version: 1.0 Subject: Re: [CDNi] New draft submitted draft-famaey-cdni-has-experiments-00 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 22:57:17 -0000 --_000_291CC3F9E50E7641901A54E85D0977C6535F6910DDMAILR002maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jeroen, I read through the draft. It seems that it essentially shows the upper bound on the encoded bitrate somewhere along the lines of: B * (SD - 4 * D + C) / SD where SD is the segment duration, in this case 2 seconds, 4 * D is the two WAN RTTs required for the redirect, and C is the overhead of the access network latency plus the processing delay for the redirect messages? Certainly with HTTP adaptive protocols, it is the case that as the RTT approaches SD, the viable encoded bitrate goes to zero, even without redirects. It is a primary reason for using SD =3D 10 with HLS and presumably why the native SS client seems to just automatically use the redirect target for its subsequent requests. Pressumably the experiment is for a VoD scenario, i.e., all the segments are immediately available for download? (Live delivery poses other issues...) If the content provider selects a suitably large SD to try to protect against the worst case scenario, the impact to average encoded bitrate is probably less dramatic? While I agree that there is higher probability of the inter-CDN link having higher latency than the access network, there are plenty of bad access networks out there. I was wondering if the selected values for "per-client bandwidth B" were designed to reflect any specific access network deployment scenarios? Selecting the "best" CDN to deliver the content (in this case lowest latency request router, though, it works for other cases, e.g., cheapest CDN) and sticking with it certainly has its advantages. Is the intent of the draft just to support the concept of manifest rewrite, or are there specific redirctions or rewrite mechanisms that it would like to propose? thanx. -- Kevin J. Ma From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Jer= oen Famaey Sent: Thursday, September 27, 2012 5:49 AM To: cdni@ietf.org Subject: [CDNi] New draft submitted draft-famaey-cdni-has-experiments-00 Dear all, We have submitted a new draft on the delivery of HTTP Adaptive Streaming (H= AS) content over interconnected CDNs. The document presents experimental r= esults on the influence of multiple alternative CDN-I request routing appro= aches on the quality of delivered HAS content streams. The approaches are = based on the HAS chunk addressing methods proposed in draft-brandenburg-cdn= i-has-03. We look forward to your comments and feedback. http://tools.ietf.org/id/draft-famaey-cdni-has-experiments-00.txt Kind regards, Jeroen Famaey -- Dr. Jeroen Famaey Department of Information Technology Internet Based Communication Networks and Services (IBCN) Ghent University - IBBT Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium T: +32 9 33 14938; T Secr: +32 (0)9 33 14900 F: +32 9 33 14899 E: jeroen.famaey@intec.UGent.be W: http://users.ugent.be/~jfamaey W: http://www.ibcn.intec.UGent.be --_000_291CC3F9E50E7641901A54E85D0977C6535F6910DDMAILR002maill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jeroen,

=

 

  I read through the draft. = ; It seems that it essentially shows the

  u= pper bound on the encoded bitrate somewhere along the lines of: =

 

    B * (SD= - 4 * D + C) / SD

 

  4 * D is the two WAN RTTs required for the redire= ct, and

  C is the overhead of the access ne= twork latency plus the

  processing delay fo= r the redirect messages?

 =

  Certainly with HTTP adaptive protocols, it is the case that= as

  the RTT approaches SD, the viable enco= ded bitrate goes to zero,

  even without red= irects.  It is a primary reason for using SD =3D 10<= /p>

  with HLS and presumably why the native SS client seems to ju= st

  automatically use the redirect target f= or its subsequent requests.

 

  Pressumably the experiment is for a VoD scenario, i.e., = all the

  segments are immediately available= for download?  (Live delivery

  poses = other issues...)  If the content provider selects a suitably

  large SD to try to protect against the worst case s= cenario, the

  impact to average encoded bit= rate is probably less dramatic?

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'> =

  While I agree that there is higher probability of th= e inter-CDN

  link having higher latency tha= n the access network, there are

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'>  plenty of = bad access networks out there.  I was wondering if

  the selected values for "per-client bandwidth B" we= re designed

  to reflect any specific access= network deployment scenarios?

 <= /span>

  Selecting the "best" CDN to deliver the con= tent (in this case

  lowest latency request = router, though, it works for other cases,

  = e.g., cheapest CDN) and sticking with it certainly has its

  advantages.  Is the intent of the draft just to suppo= rt the

  concept of manifest rewrite, or are= there specific redirctions

  or rewrite mec= hanisms that it would like to propose?

 = ;

thanx.

 

--  Kevin J. Ma

 

From: cdni-bounces@ie= tf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Jeroen Famaey
= Sent: Thursday, September 27, 2012 5:49 AM
To: cdni@ietf.o= rg
Subject: [CDNi] New draft submitted draft-famaey-cdni-has-expe= riments-00

 = ;

Dear all,

 

We have submitt= ed a new draft on the delivery of HTTP Adaptive Streaming (HAS) content ove= r interconnected CDNs.  The document presents experimental results on = the influence of multiple alternative CDN-I request routing approaches on t= he quality of delivered HAS content streams.  The approaches are based= on the HAS chunk addressing methods proposed in draft-brandenburg-cdni-has= -03.  We look forward to your comments and feedback.

 

 

Kind regards,

Jeroen Famaey


--

Dr. Jero= en Famaey
Department of Information Technology
Internet Based Communi= cation Networks and Services (IBCN)
Ghent University - IBBT
Gaston Cr= ommenlaan 8 (Bus 201), B-9050 Gent, Belgium
T: +32 9 33 14938; T Secr: += 32 (0)9 33 14900
F: +32 9 33 14899
E: jeroen.famaey@intec.UGent.be
W: http://users.ugent.be/~jfamaey
W= : http://www.ibcn.intec.UGe= nt.be 

 

= --_000_291CC3F9E50E7641901A54E85D0977C6535F6910DDMAILR002maill_-- From kevin.ma@azukisystems.com Fri Nov 9 15:03:09 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B7A21F869B for ; Fri, 9 Nov 2012 15:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phyfKPOJSOAF for ; Fri, 9 Nov 2012 15:03:08 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 836CC21F8680 for ; Fri, 9 Nov 2012 15:03:08 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id E80597DE782; Fri, 9 Nov 2012 17:37:51 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB012.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 4ADAC7DE5F3; Fri, 9 Nov 2012 17:37:51 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Fri, 9 Nov 2012 18:02:58 -0500 From: Kevin J Ma To: Jeroen Famaey , "cdni@ietf.org" Date: Fri, 9 Nov 2012 18:03:05 -0500 Thread-Topic: [CDNi] New draft submitted draft-famaey-cdni-has-experiments-00 Thread-Index: Ac2clXYyrzFw/IwKTxiVsOT+5F0G8AiEvNlQAAl503A= Message-ID: <291CC3F9E50E7641901A54E85D0977C6535F6910E3@MAILR002.mail.lan> References: <83440700-EEF7-4738-BA59-083AB4B2ED4E@intec.ugent.be> <291CC3F9E50E7641901A54E85D0977C6535F6910DD@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6535F6910DD@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_291CC3F9E50E7641901A54E85D0977C6535F6910E3MAILR002maill_" MIME-Version: 1.0 Subject: Re: [CDNi] New draft submitted draft-famaey-cdni-has-experiments-00 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 23:03:09 -0000 --_000_291CC3F9E50E7641901A54E85D0977C6535F6910E3MAILR002maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable there was a missing set of parens: B * (SD - (4 * D + C)) / SD From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Kev= in J Ma Sent: Friday, November 09, 2012 5:57 PM To: Jeroen Famaey; cdni@ietf.org Subject: Re: [CDNi] New draft submitted draft-famaey-cdni-has-experiments-0= 0 Hi Jeroen, I read through the draft. It seems that it essentially shows the upper bound on the encoded bitrate somewhere along the lines of: B * (SD - 4 * D + C) / SD where SD is the segment duration, in this case 2 seconds, 4 * D is the two WAN RTTs required for the redirect, and C is the overhead of the access network latency plus the processing delay for the redirect messages? Certainly with HTTP adaptive protocols, it is the case that as the RTT approaches SD, the viable encoded bitrate goes to zero, even without redirects. It is a primary reason for using SD =3D 10 with HLS and presumably why the native SS client seems to just automatically use the redirect target for its subsequent requests. Pressumably the experiment is for a VoD scenario, i.e., all the segments are immediately available for download? (Live delivery poses other issues...) If the content provider selects a suitably large SD to try to protect against the worst case scenario, the impact to average encoded bitrate is probably less dramatic? While I agree that there is higher probability of the inter-CDN link having higher latency than the access network, there are plenty of bad access networks out there. I was wondering if the selected values for "per-client bandwidth B" were designed to reflect any specific access network deployment scenarios? Selecting the "best" CDN to deliver the content (in this case lowest latency request router, though, it works for other cases, e.g., cheapest CDN) and sticking with it certainly has its advantages. Is the intent of the draft just to support the concept of manifest rewrite, or are there specific redirctions or rewrite mechanisms that it would like to propose? thanx. -- Kevin J. Ma From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Jer= oen Famaey Sent: Thursday, September 27, 2012 5:49 AM To: cdni@ietf.org Subject: [CDNi] New draft submitted draft-famaey-cdni-has-experiments-00 Dear all, We have submitted a new draft on the delivery of HTTP Adaptive Streaming (H= AS) content over interconnected CDNs. The document presents experimental r= esults on the influence of multiple alternative CDN-I request routing appro= aches on the quality of delivered HAS content streams. The approaches are = based on the HAS chunk addressing methods proposed in draft-brandenburg-cdn= i-has-03. We look forward to your comments and feedback. http://tools.ietf.org/id/draft-famaey-cdni-has-experiments-00.txt Kind regards, Jeroen Famaey -- Dr. Jeroen Famaey Department of Information Technology Internet Based Communication Networks and Services (IBCN) Ghent University - IBBT Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium T: +32 9 33 14938; T Secr: +32 (0)9 33 14900 F: +32 9 33 14899 E: jeroen.famaey@intec.UGent.be W: http://users.ugent.be/~jfamaey W: http://www.ibcn.intec.UGent.be --_000_291CC3F9E50E7641901A54E85D0977C6535F6910E3MAILR002maill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

there was a missing set of paren= s: B * (SD - (4 * D + C)) / SD

 <= /span>

From: cdni-bounces@ietf.= org [mailto:cdni-bounces@ietf.org] On Behalf Of Kevin J Ma
Sen= t: Friday, November 09, 2012 5:57 PM
To: Jeroen Famaey; cdni@= ietf.org
Subject: Re: [CDNi] New draft submitted draft-famaey-cdn= i-has-experiments-00

=  

Hi Jeroen,

 <= /o:p>

  I read through the draft.  It seems that i= t essentially shows the

  upper bound on the= encoded bitrate somewhere along the lines of:

<= o:p> 

    B * (SD - 4 * D + C) / S= D

 

  where S= D is the segment duration, in this case 2 seconds,

  C is the overhead of the access network latency plu= s the

  processing delay for the redirect me= ssages?

 

  C= ertainly with HTTP adaptive protocols, it is the case that as

  the RTT approaches SD, the viable encoded bitrate goes = to zero,

  even without redirects.  It = is a primary reason for using SD =3D 10

  wi= th HLS and presumably why the native SS client seems to just

  automatically use the redirect target for its subsequent= requests.

 

&nb= sp; Pressumably the experiment is for a VoD scenario, i.e., all the

  segments are immediately available for download?&= nbsp; (Live delivery

  poses other issues..= .)  If the content provider selects a suitably

  impact to average encoded bitrate is probab= ly less dramatic?

 

  link having higher latency than the access n= etwork, there are

  plenty of bad access net= works out there.  I was wondering if

  = the selected values for "per-client bandwidth B" were designed

  to reflect any specific access network deplo= yment scenarios?

 

  Selecting the "best" CDN to deliver the content (in this = case

  lowest latency request router, though= , it works for other cases,

  e.g., cheapest= CDN) and sticking with it certainly has its

&nb= sp; advantages.  Is the intent of the draft just to support the

  concept of manifest rewrite, or are there specif= ic redirctions

  or rewrite mechanisms that = it would like to propose?

 

thanx.

 

--  Kevin J. Ma

 

From: cdni-bounces@ietf.org [mailt= o:cdni-bounces@ietf.org] On Behalf Of Jeroen Famaey
Sent: = Thursday, September 27, 2012 5:49 AM
To: cdni@ietf.org
Subj= ect: [CDNi] New draft submitted draft-famaey-cdni-has-experiments-00

 

Dear all,

&= nbsp;

We have submitted a new draf= t on the delivery of HTTP Adaptive Streaming (HAS) content over interconnec= ted CDNs.  The document presents experimental results on the influence= of multiple alternative CDN-I request routing approaches on the quality of= delivered HAS content streams.  The approaches are based on the HAS c= hunk addressing methods proposed in draft-brandenburg-cdni-has-03.  We= look forward to your comments and feedback.

 

 

=

Kind regards,

<= div>

Jeroen Famaey


--

Dr. Jeroen Famaey
= Department of Information Technology
Internet Based Communication Networ= ks and Services (IBCN)
Ghent University - IBBT
Gaston Crommenlaan 8 (= Bus 201), B-9050 Gent, Belgium
T: +32 9 33 14938; T Secr: +32 (0)9 33 14= 900
F: +32 9 33 14899
E: jeroen.famaey@intec.UGent.be
W: http://users.ugent.be/~jfamaey
W: http://www.ibcn.intec.UGent.be = ;

 

= --_000_291CC3F9E50E7641901A54E85D0977C6535F6910E3MAILR002maill_-- From flefauch@cisco.com Mon Nov 12 01:16:07 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E24221F846A for ; Mon, 12 Nov 2012 01:16:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8dkbw3Rx0RN for ; Mon, 12 Nov 2012 01:16:06 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4635821F846F for ; Mon, 12 Nov 2012 01:16:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1586; q=dns/txt; s=iport; t=1352711766; x=1353921366; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Tu2XHozGqQO08/j2QJTCvW/xwhk6W0uDKhdbfjIbYh0=; b=DBWJm4iVbcGEc8wt9zdFwNTB7G3i5jtvD6lj5QhHUWpo0rqZ1Bo9QoSb 2ijvrPSUFMYJ9jbckOPt/wQ4ZkadL2E+tNndMRKTz8tXZcoGMWSL8+JJv mRpifTt8NhHc/1xgvPKhBB4Zao8dFZGxEolFz/A7kSdb9ya6omakiSo7s c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIJAAy+oFCtJXG+/2dsb2JhbABEw1aBAQeCHgEBAQMBAQEBDwEnNAsFCwIBCBgKFBAnCyUCBA4FCAEZh2IGC5sFnzGMFRqFT2EDpFSBa4JvgWQXHg X-IronPort-AV: E=McAfee;i="5400,1158,6893"; a="141209650" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 12 Nov 2012 09:16:05 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAC9G5He019915 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Nov 2012 09:16:05 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 03:16:05 -0600 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: [CDNi] Draft IETF-85 minutes posted Thread-Index: AQHNvouMpeQod5tGtUKHlbf8oHgh3JfiARiAgARTIAA= Date: Mon, 12 Nov 2012 09:16:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.198] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19356.005 x-tm-as-result: No--41.124000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <75FFC0FA11D43C47A02584EB9B19E6BB@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Bhumip.Khasnabish@zte.com.cn" Subject: Re: [CDNi] Draft IETF-85 minutes posted X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 09:16:07 -0000 Hi everyone, The draft minutes have been updated with: * the correction discussed below by Ray * a correction on the Show-of-hand results for the long-tail I-D (that wer= e swapped in earlier version) - thanks to Dave Melton for pointing that out= . Any more comments/corrections? Francois On 9 Nov 2012, at 16:13, Brandenburg, R. (Ray) van wrote: > Hi Francois, >=20 > One comment: the minutes note that the last presentation on Thursday was = me presenting the HAS experiments draft, while it was actually Bhumip prese= nting the Intra-CDN providers draft (we diverged from the agenda). >=20 > Ray >=20 > On 9 nov. 2012, at 10:04, "Francois Le Faucheur (flefauch)" wrote: >=20 >> Folks, >>=20 >> Draft minutes for our two CDNI sessions of IETF-85 have been posted. You= can access them from the IETF-85 Meeting Material page or directly from: >> http://www.ietf.org/proceedings/85/minutes/minutes-85-cdni. >>=20 >> Thanks to Marcin for providing raw notes.=20 >>=20 >> We could not quite capture all statements of the discussion in some occu= rrences, and the audio recording won't be available for a little while, but= the draft minutes aim at capturing the essential of the discussion. >>=20 >> Corrections/comments welcome. >>=20 >> Cheers >>=20 >> Francois >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni > This e-mail and its contents are subject to the DISCLAIMER at http://www.= tno.nl/emaildisclaimer >=20 From lpeterson@verivue.com Mon Nov 12 09:53:26 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A27621F860C for ; Mon, 12 Nov 2012 09:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUJ5TUUNVRQK for ; Mon, 12 Nov 2012 09:53:25 -0800 (PST) Received: from exprod8og120.obsmtp.com (exprod8og120.obsmtp.com [64.18.3.40]) by ietfa.amsl.com (Postfix) with SMTP id 9EC7C21F85A4 for ; Mon, 12 Nov 2012 09:53:25 -0800 (PST) Received: from vvexch.verivue.com ([38.83.192.68]) by exprod8ob120.postini.com ([64.18.7.12]) with SMTP ID DSNKUKE3lC5xo5Ribx9Vf1+BivzkfBX3mDaW@postini.com; Mon, 12 Nov 2012 09:53:25 PST Received: from vvexch.verivue.com ([10.160.6.20]) by vvexch.verivue.com ([10.160.6.20]) with mapi; Mon, 12 Nov 2012 12:53:23 -0500 From: "Peterson, Larry" To: "Francois Le Faucheur (flefauch)" Date: Mon, 12 Nov 2012 12:53:22 -0500 Thread-Topic: [CDNi] Acronyms for the CDNI interfaces Thread-Index: Ac3A/puc0Rn2RFWETS6wSJBD662shQ== Message-ID: References: <291CC3F9E50E7641901A54E85D0977C6535F5DB898@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Acronyms for the CDNI interfaces X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 17:53:26 -0000 I'm good with these, but in working through the framework=20 document, I note that we also make significant reference to=20 the generic Request Routing Interface. While we could add RRI to the set, and then fully qualify the two sub-interfaces (i.e., RR/RI and RR/FCI), I propose instead to stick with RI=20 and FCI, and just not use an acronym for the generic Request Routing Interface. (For me, the main value of the acronyms is in the figures, and we never need RRI.) Larry On Nov 9, 2012, at 9:07 AM, Francois Le Faucheur (flefauch) wrote: > Works for me. So latest proposal on the table is: >=20 > * CI, MI, LI, RI, FCI >=20 >=20 > PS: and no, the "I" is not superfluous 8^) >=20 > On 9 Nov 2012, at 14:58, Kevin J Ma wrote: >=20 >> The "C" is somewhat superfluous? We could drop all the "C"s. >> CI, MI, LI, RI, and FI? >> =20 >> And, at the risk of opening a rat hole, "FI" seems to imply >> that footprint is more important than capabilities... :) >> "FCI"? >> =20 >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Francois Le Faucheur (flefauch) >> Sent: Friday, November 09, 2012 8:37 AM >> To: B.Khasnabish@ieee.org >> Cc: cdni@ietf.org >> Subject: Re: [CDNi] Acronyms for the CDNI interfaces >> =20 >> =20 >> On 9 Nov 2012, at 04:03, B.Khasnabish@ieee.org wrote: >>=20 >>=20 >> Hi Francois, >> =20 >> Thanks. This is a good start. >> =20 >> As you know, "CLI" is widely used for "Command Line Interface," >> (http://en.wikipedia.org/wiki/Command-line_interface) >> so let us consider something different for "CDNI Logging Interface"=85 >> =20 >> "CLoI" ? >>=20 >>=20 >> =20 >> Best. >> =20 >> Bhumip >>=20 >>=20 >> =20 >> On Thu, Nov 8, 2012 at 4:51 PM, Francois Le Faucheur (flefauch) wrote: >> Folks, >>=20 >> As discussed during the Atlanta meeting, we need to agree on a set of ac= ronyms to designate the CDNI interfaces consistently across documents (part= icularly in figures where the full name cannot be used). >>=20 >> A base proposal is: >> * "CCI" for the CDNI Control Interface >> * "CMI" for the CDNI Metadata distribution Interface >> * "CLI" for the CDNI Logging Interface >> * "CRI" for the CDNI request routing/Redirection Interface >> * "CFI" for the CDNI request routing/Footprint & capabilities ad= vertisement Interface. >>=20 >> Let us know if you see issues with that, or if you want to offer a bette= r proposal. >>=20 >> Cheers >>=20 >> Francois >>=20 >> PS: some of the acronyms above probably conflict with some acronyms you'= ve already encountered somewhere else before, but those don't seem to be ma= jor conflict, and it'd be nice to stick to short acronyms. >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >>=20 >>=20 >>=20 >> =20 >> =20 >=20 > From kevin.ma@azukisystems.com Mon Nov 12 09:55:06 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D6321F862E for ; Mon, 12 Nov 2012 09:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mv4DDhs96DSd for ; Mon, 12 Nov 2012 09:55:05 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id D75DE21F860C for ; Mon, 12 Nov 2012 09:55:04 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 79A4F416B58; Mon, 12 Nov 2012 06:50:26 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB023.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id BFBA1416B2A; Mon, 12 Nov 2012 06:50:24 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Mon, 12 Nov 2012 12:54:35 -0500 From: Kevin J Ma To: "Peterson, Larry" , "Francois Le Faucheur (flefauch)" Date: Mon, 12 Nov 2012 12:55:00 -0500 Thread-Topic: [CDNi] Acronyms for the CDNI interfaces Thread-Index: Ac3A/puc0Rn2RFWETS6wSJBD662shQAACa+Q Message-ID: <291CC3F9E50E7641901A54E85D0977C6535F691250@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C6535F5DB898@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Acronyms for the CDNI interfaces X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 17:55:06 -0000 I agree with always specifically referencing RI or FCI directly. > -----Original Message----- > From: Peterson, Larry [mailto:lpeterson@verivue.com] > Sent: Monday, November 12, 2012 12:53 PM > To: Francois Le Faucheur (flefauch) > Cc: Kevin J Ma; cdni@ietf.org > Subject: Re: [CDNi] Acronyms for the CDNI interfaces >=20 > I'm good with these, but in working through the framework > document, I note that we also make significant reference to > the generic Request Routing Interface. While we could add > RRI to the set, and then fully qualify the two sub-interfaces > (i.e., RR/RI and RR/FCI), I propose instead to stick with RI > and FCI, and just not use an acronym for the generic Request > Routing Interface. (For me, the main value of the acronyms > is in the figures, and we never need RRI.) >=20 > Larry >=20 >=20 > On Nov 9, 2012, at 9:07 AM, Francois Le Faucheur (flefauch) wrote: >=20 > > Works for me. So latest proposal on the table is: > > > > * CI, MI, LI, RI, FCI > > > > > > PS: and no, the "I" is not superfluous 8^) > > > > On 9 Nov 2012, at 14:58, Kevin J Ma wrote: > > > >> The "C" is somewhat superfluous? We could drop all the "C"s. > >> CI, MI, LI, RI, and FI? > >> > >> And, at the risk of opening a rat hole, "FI" seems to imply > >> that footprint is more important than capabilities... :) > >> "FCI"? > >> > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf O= f > Francois Le Faucheur (flefauch) > >> Sent: Friday, November 09, 2012 8:37 AM > >> To: B.Khasnabish@ieee.org > >> Cc: cdni@ietf.org > >> Subject: Re: [CDNi] Acronyms for the CDNI interfaces > >> > >> > >> On 9 Nov 2012, at 04:03, B.Khasnabish@ieee.org wrote: > >> > >> > >> Hi Francois, > >> > >> Thanks. This is a good start. > >> > >> As you know, "CLI" is widely used for "Command Line Interface," > >> (http://en.wikipedia.org/wiki/Command-line_interface) > >> so let us consider something different for "CDNI Logging Interface"... > >> > >> "CLoI" ? > >> > >> > >> > >> Best. > >> > >> Bhumip > >> > >> > >> > >> On Thu, Nov 8, 2012 at 4:51 PM, Francois Le Faucheur (flefauch) > wrote: > >> Folks, > >> > >> As discussed during the Atlanta meeting, we need to agree on a set of > acronyms to designate the CDNI interfaces consistently across documents > (particularly in figures where the full name cannot be used). > >> > >> A base proposal is: > >> * "CCI" for the CDNI Control Interface > >> * "CMI" for the CDNI Metadata distribution Interface > >> * "CLI" for the CDNI Logging Interface > >> * "CRI" for the CDNI request routing/Redirection Interface > >> * "CFI" for the CDNI request routing/Footprint & capabilities > advertisement Interface. > >> > >> Let us know if you see issues with that, or if you want to offer a > better proposal. > >> > >> Cheers > >> > >> Francois > >> > >> PS: some of the acronyms above probably conflict with some acronyms > you've already encountered somewhere else before, but those don't seem to > be major conflict, and it'd be nice to stick to short acronyms. > >> _______________________________________________ > >> CDNi mailing list > >> CDNi@ietf.org > >> https://www.ietf.org/mailman/listinfo/cdni > >> > >> > >> > >> > >> > > > > From flefauch@cisco.com Mon Nov 12 10:24:22 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A175F21F86E5 for ; Mon, 12 Nov 2012 10:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.569 X-Spam-Level: X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+nxONhChytW for ; Mon, 12 Nov 2012 10:24:20 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5496B21F86D3 for ; Mon, 12 Nov 2012 10:24:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4387; q=dns/txt; s=iport; t=1352744660; x=1353954260; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=y63/LP5wmKC6N6sJspA66rwKkk6lILUrxSUXQp+Z9Tg=; b=Yc9y9WL7IYVrc74W6oVlkO9ZewnpDV2PVeniOLacnUW40TCDd7gYDoBq i9mminHh8k00Y8YxGrliacQtW7bTSCS6Gr8lgP46rVq+kDfyHiJVKyiqc UPwFX0h4XunuZhhOmR8jelldMYQFK7q9xivBcz+nIcTSFH8RvmzYi6wnn Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAL89oVCtJXG8/2dsb2JhbABEw1qBCIIeAQEBAwEBAQEPAVsLBQsCAQgRBAEBAQodBycLFAkIAgQOBQgah2IGC5lllz+IPYwVhWlhA6RUgWuCb4IZ X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="141380672" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 12 Nov 2012 18:24:05 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qACIO5r4008712 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Nov 2012 18:24:05 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 12:24:04 -0600 From: "Francois Le Faucheur (flefauch)" To: "Peterson, Larry" Thread-Topic: [CDNi] Acronyms for the CDNI interfaces Thread-Index: AQHNvfsyv+R0Tv5ROk6hOdIj1ufyOpfhNkkAgACw7AD//59c0IAAaSwAgAT2GACAAAiMAA== Date: Mon, 12 Nov 2012 18:24:05 +0000 Message-ID: References: <291CC3F9E50E7641901A54E85D0977C6535F5DB898@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.198] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19356.005 x-tm-as-result: No--51.995700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <78C45A0D98A9034AA40DECA171DDA9DE@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Acronyms for the CDNI interfaces X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 18:24:22 -0000 On 12 Nov 2012, at 18:53, Peterson, Larry wrote: > I'm good with these, but in working through the framework=20 > document, I note that we also make significant reference to=20 > the generic Request Routing Interface. While we could add > RRI to the set, and then fully qualify the two sub-interfaces > (i.e., RR/RI and RR/FCI), I propose instead to stick with RI=20 > and FCI, and just not use an acronym for the generic Request > Routing Interface. (For me, the main value of the acronyms > is in the figures, and we never need RRI.) First, I agree with not having an acronym for the Request Routing Interface= . Secondly, as the "CDNI request routing/Redirection Interface" and "CDNI req= uest routing/Footprint & Capabilities advertisement Interface" are firming = up, there is probably less and less rationale for even referring to the Req= uest Routing Interface per say. At the beginning we were not sure whether t= he two components would be realized with one or two interfaces so we bundle= d the two functions under the term Request Routing Interface, but now that = we are quite clear that they will be realized separately, we can probably a= lways refer to RI and FCI specifically. So, with respect to the Framework, I'd suggest: * explaining early in the document that the Request Routing Interface is a= logical grouping of RI and FCI, because the two relate to enabling request= routing * then, whenever possible, only use the terms "CDNI request routing/Redire= ction Interface" and "CDNI request routing/Footprint & Capabilities adverti= sement Interface". And when you want to refer to both, then just list them = both (instead of using "Request Routing Interface") either using the full n= ame or the acronym. Makes sense? Francois >=20 > Larry >=20 >=20 > On Nov 9, 2012, at 9:07 AM, Francois Le Faucheur (flefauch) wrote: >=20 >> Works for me. So latest proposal on the table is: >>=20 >> * CI, MI, LI, RI, FCI >>=20 >>=20 >> PS: and no, the "I" is not superfluous 8^) >>=20 >> On 9 Nov 2012, at 14:58, Kevin J Ma wrote: >>=20 >>> The "C" is somewhat superfluous? We could drop all the "C"s. >>> CI, MI, LI, RI, and FI? >>>=20 >>> And, at the risk of opening a rat hole, "FI" seems to imply >>> that footprint is more important than capabilities... :) >>> "FCI"? >>>=20 >>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of= Francois Le Faucheur (flefauch) >>> Sent: Friday, November 09, 2012 8:37 AM >>> To: B.Khasnabish@ieee.org >>> Cc: cdni@ietf.org >>> Subject: Re: [CDNi] Acronyms for the CDNI interfaces >>>=20 >>>=20 >>> On 9 Nov 2012, at 04:03, B.Khasnabish@ieee.org wrote: >>>=20 >>>=20 >>> Hi Francois, >>>=20 >>> Thanks. This is a good start. >>>=20 >>> As you know, "CLI" is widely used for "Command Line Interface," >>> (http://en.wikipedia.org/wiki/Command-line_interface) >>> so let us consider something different for "CDNI Logging Interface"=85 >>>=20 >>> "CLoI" ? >>>=20 >>>=20 >>>=20 >>> Best. >>>=20 >>> Bhumip >>>=20 >>>=20 >>>=20 >>> On Thu, Nov 8, 2012 at 4:51 PM, Francois Le Faucheur (flefauch) wrote: >>> Folks, >>>=20 >>> As discussed during the Atlanta meeting, we need to agree on a set of a= cronyms to designate the CDNI interfaces consistently across documents (par= ticularly in figures where the full name cannot be used). >>>=20 >>> A base proposal is: >>> * "CCI" for the CDNI Control Interface >>> * "CMI" for the CDNI Metadata distribution Interface >>> * "CLI" for the CDNI Logging Interface >>> * "CRI" for the CDNI request routing/Redirection Interface >>> * "CFI" for the CDNI request routing/Footprint & capabilities ad= vertisement Interface. >>>=20 >>> Let us know if you see issues with that, or if you want to offer a bett= er proposal. >>>=20 >>> Cheers >>>=20 >>> Francois >>>=20 >>> PS: some of the acronyms above probably conflict with some acronyms you= 've already encountered somewhere else before, but those don't seem to be m= ajor conflict, and it'd be nice to stick to short acronyms. >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> >=20 From vumip1@gmail.com Mon Nov 12 10:53:59 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDD721F8686 for ; Mon, 12 Nov 2012 10:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HChjr72eErk3 for ; Mon, 12 Nov 2012 10:53:58 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 73B1221F8793 for ; Mon, 12 Nov 2012 10:53:57 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so1285962lah.31 for ; Mon, 12 Nov 2012 10:53:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=CXIooRKG4+brUPyOl23bcLCPU37bHK9r2prWt8Wscx8=; b=ROubWWMTUffqXqHQkGmcKXcdCpr07CkvDKZcUNB3loeCwyY4dGXNYIdtv1yGgTZTMP NXOZoKacmkhD2toyy8Q0gcmfQf2NZpuvelquVPaBjTAqDhy3iedz42RI4PdyRY9O7rMG YO9nW9EKanJAAQSSlywql/icc5tlXIy3qgaTOOxiiBABgb8ZfIlS0BUNL9gVHIi6zV6A IFEKXLEI79C8C1ArbKl09brRREJ9iJefrhEyImifnz99R9Vg0n8FOLBu3rms/97puALC cv+lPktrVkajBGaRoSa4VIkEjgSMpN/XTeH6Rkfb2VkldnfvKWyl4xBonDALBmEO9tiU t8bA== MIME-Version: 1.0 Received: by 10.152.132.3 with SMTP id oq3mr18876972lab.18.1352746436346; Mon, 12 Nov 2012 10:53:56 -0800 (PST) Received: by 10.114.5.161 with HTTP; Mon, 12 Nov 2012 10:53:56 -0800 (PST) Date: Mon, 12 Nov 2012 13:53:56 -0500 Message-ID: From: "B.Khasnabish@ieee.org" To: "Francois Le Faucheur (flefauch)" Content-Type: multipart/alternative; boundary=f46d04308554cf43d304ce50d2d8 Cc: cdni@ietf.org, Ram Krishnan Subject: [CDNi] Requesting Marcin Pilarski to share de-dup expt setup and results, ..Re: Draft IETF-85 minutes posted X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 18:53:59 -0000 --f46d04308554cf43d304ce50d2d8 Content-Type: text/plain; charset=ISO-8859-1 Hi Francois , During the presentation of the following draft Marcin Pilarski suggested that in his CDNI expt. the problem of content duplication does not match at all what he is see in his environment Content De-duplication for CDNi Optimization, draft-jin-cdni-content-deduplication-optimization-03: Bhumip Khasnabish Do you have access to Marcin's experiment. setup, traffic/network/content profile, and results? If yes, can you share those with us. If not can you ask Marcin to share the setup info and results with us ASAP. Many thanks in advance. Best. Bhumip ========================================================== >> Draft minutes for our two CDNI sessions of IETF-85 have been posted. You can access them from the IETF-85 Meeting Material page or directly from: >> http://www.ietf.org/proceedings/85/minutes/minutes-85-cdni. - problem of de-duplication explained with 3 scenarios. - survey up to 60% data stored is duplicated. *Marcin Pilarski: what are the assumptions behind these numbers because that does not match at all what I see in my environment *Bhumip: will be explained in this draft or in separate draft :::::: - Option 2 - decide it is a nice-to-have, but is not crucial for initial versions of CDNI interfaces. We *continue the work on it inside the WG*, but do not aim to support it in first version of the CDNI interfaces. :::::::: - Option 2: ~20 people ========================================================== On Mon, Nov 12, 2012 at 4:16 AM, Francois Le Faucheur (flefauch) < flefauch@cisco.com> wrote: > Hi everyone, > > The draft minutes have been updated with: > * the correction discussed below by Ray > * a correction on the Show-of-hand results for the long-tail I-D > (that were swapped in earlier version) - thanks to Dave Melton for pointing > that out. > > Any more comments/corrections? > > Francois > > > On 9 Nov 2012, at 16:13, Brandenburg, R. (Ray) van wrote: > > > Hi Francois, > > > > One comment: the minutes note that the last presentation on Thursday was > me presenting the HAS experiments draft, while it was actually Bhumip > presenting the Intra-CDN providers draft (we diverged from the agenda). > > > > Ray > > > > On 9 nov. 2012, at 10:04, "Francois Le Faucheur (flefauch)" < > flefauch@cisco.com> wrote: > > > >> Folks, > >> > >> Draft minutes for our two CDNI sessions of IETF-85 have been posted. > You can access them from the IETF-85 Meeting Material page or directly from: > >> http://www.ietf.org/proceedings/85/minutes/minutes-85-cdni. > >> > >> Thanks to Marcin for providing raw notes. > >> > >> We could not quite capture all statements of the discussion in some > occurrences, and the audio recording won't be available for a little while, > but the draft minutes aim at capturing the essential of the discussion. > >> > >> Corrections/comments welcome. > >> > >> Cheers > >> > >> Francois > >> _______________________________________________ > >> CDNi mailing list > >> CDNi@ietf.org > >> https://www.ietf.org/mailman/listinfo/cdni > > This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/emaildisclaimer > > > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > --f46d04308554cf43d304ce50d2d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Francois ,
=A0
During the presentation of the following draft Marcin Pilarski suggest= ed that in his CDNI expt.
the problem of content duplication does not match at all what he is se= e in his
environment
Content De-duplication for CDNi Optimization,
draft-jin-cdni-content-deduplication-optimization-03: Bhumip Khasnabis= h
=A0
Do you have access to Marcin's experiment. setup, traffic/network/= content=A0profile,
and results? If yes, can you share those with us.
If not can you ask Marcin to share the setup info and results with us = ASAP.
=A0
Many=A0 thanks in advance.
=A0
Best.
=A0
Bhumip
=A0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> Draft minutes for our two CDNI sessions of IETF-85 have been = posted. You can access them from the IETF-85 Meeting Material page or direc= tly from:
>> http://www.ietf.org/proceedings/85/minu= tes/minutes-85-cdni.

- problem of de-duplication explained with 3 scenarios.
- survey up= to 60% data stored is duplicated.
*Marcin Pilarski: what are the assum= ptions behind these numbers because that does not match at all what I see i= n my environment
*Bhumip: will be explained in this draft or in separate draft
::::::
- Option 2 - decide it is a nice-to-have, but is not crucial for initi= al versions of CDNI interfaces. We continue the work on it insid= e the WG,=A0 but do not aim to support it in first version of = the CDNI interfaces.
::::::::
- Option 2: ~20 people

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=A0
On Mon, Nov 12, 2012 at 4:16 AM, Francois Le Faucheur (flefauch) <fl= efauch@cisco.com> wrote:
Hi everyone,

The draft minutes= have been updated with:
=A0 =A0 =A0 =A0 * the correction discussed belo= w by Ray
=A0 =A0 =A0 =A0 * a correction on the Show-of-hand results for the long-tai= l I-D (that were swapped in earlier version) - thanks to Dave Melton for po= inting that out.

Any more comments/corrections?

Francois


On 9 Nov 2012, at 16:13, Brandenburg, R. (Ray) va= n wrote:

> Hi Francois,
>
> One comment: the minutes = note that the last presentation on Thursday was me presenting the HAS exper= iments draft, while it was actually Bhumip presenting the Intra-CDN provide= rs draft (we diverged from the agenda).
>
> Ray
>
> On 9 nov. 2012, at 10:04, "Francois L= e Faucheur (flefauch)" <flefa= uch@cisco.com> wrote:
>
>> Folks,
>>
>= > Draft minutes for our two CDNI sessions of IETF-85 have been posted. Y= ou can access them from the IETF-85 Meeting Material page or directly from:=
>> http://www.ietf.org/proceedings/85/minutes/minutes-8= 5-cdni.
>>
>> Thanks to Marcin for providing raw note= s.
>>
>> We could not quite capture all statements of the discu= ssion in some occurrences, and the audio recording won't be available f= or a little while, but the draft minutes aim at capturing the essential of = the discussion.
>>
>> Corrections/comments welcome.
>>
>> = Cheers
>>
>> Francois
>> _______________________= ________________________
>> CDNi mailing list
>> CDNi@ietf.org
>> https://www.ietf.org/mailman/listinfo/cdni
> This e-mail a= nd its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer=
>

_______________________________________________
CDNi mailing= list
CDNi@ietf.org
https://www.ie= tf.org/mailman/listinfo/cdni


=A0 --f46d04308554cf43d304ce50d2d8-- From flefauch@cisco.com Mon Nov 12 23:57:53 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1FD21F88E5 for ; Mon, 12 Nov 2012 23:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.571 X-Spam-Level: X-Spam-Status: No, score=-10.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVhm7Kk15K2C for ; Mon, 12 Nov 2012 23:57:52 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 785B321F88E4 for ; Mon, 12 Nov 2012 23:57:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10202; q=dns/txt; s=iport; t=1352793472; x=1354003072; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CtKzwKomtl4abrj9vyFeAOnBJtv2L6hWc29b4KeF44w=; b=DhyAjDVItQ4ZzlH9F6SVOIpi2hVrntK7qju4hGrNnnyxoOhX9vmA2rSH fXdUivq9HPp/SDLb7GMSLogjznijkEX0xCIZ4CTDGudZsxvFe1Wivx3BI QaXEnw6D5goZOQthOKcalSjg6AT+Jv9Dc+dJPHli74EQ46ghydK9TTqUU k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADT8oVCtJV2c/2dsb2JhbABEw3qBCIIeAQEBAwEBAQEPAQVWCwULAgEIGAoZBAcnCxQRAgQOBQgBGYVugXQGC5oPj2WQOYwhGoVZYQOIJZwvgWuCb4FkFx4 X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="141812098" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 13 Nov 2012 07:57:52 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qAD7vpm4017380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Nov 2012 07:57:51 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Tue, 13 Nov 2012 01:57:51 -0600 From: "Francois Le Faucheur (flefauch)" To: "B.Khasnabish@ieee.org" Thread-Topic: Requesting Marcin Pilarski to share de-dup expt setup and results, ..Re: [CDNi] Draft IETF-85 minutes posted Thread-Index: AQHNwQcaCEZfwvhVJk2HEVEOJyxl7Zfny6yA Date: Tue, 13 Nov 2012 07:57:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.198] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19360.002 x-tm-as-result: No--45.232600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D223064xmbrcdx10ciscocom_" MIME-Version: 1.0 Cc: "cdni@ietf.org" , Ram Krishnan Subject: Re: [CDNi] Requesting Marcin Pilarski to share de-dup expt setup and results, ..Re: Draft IETF-85 minutes posted X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 07:57:53 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D223064xmbrcdx10ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Bhumip, I suggest you communicate directly with Marcin. Cheers Francois On 12 Nov 2012, at 19:53, B.Khasnabish@ieee.org wrote: Hi Francois , During the presentation of the following draft Marcin Pilarski suggested th= at in his CDNI expt. the problem of content duplication does not match at all what he is see in = his environment Content De-duplication for CDNi Optimization, draft-jin-cdni-content-deduplication-optimization-03: Bhumip Khasnabish Do you have access to Marcin's experiment. setup, traffic/network/content p= rofile, and results? If yes, can you share those with us. If not can you ask Marcin to share the setup info and results with us ASAP. Many thanks in advance. Best. Bhumip =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >> Draft minutes for our two CDNI sessions of IETF-85 have been posted. You= can access them from the IETF-85 Meeting Material page or directly from: >> http://www.ietf.org/proceedings/85/minutes/minutes-85-cdni. - problem of de-duplication explained with 3 scenarios. - survey up to 60% data stored is duplicated. *Marcin Pilarski: what are the assumptions behind these numbers because tha= t does not match at all what I see in my environment *Bhumip: will be explained in this draft or in separate draft :::::: - Option 2 - decide it is a nice-to-have, but is not crucial for initial ve= rsions of CDNI interfaces. We continue the work on it inside the WG, but d= o not aim to support it in first version of the CDNI interfaces. :::::::: - Option 2: ~20 people =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D On Mon, Nov 12, 2012 at 4:16 AM, Francois Le Faucheur (flefauch) > wrote: Hi everyone, The draft minutes have been updated with: * the correction discussed below by Ray * a correction on the Show-of-hand results for the long-tail I-D (t= hat were swapped in earlier version) - thanks to Dave Melton for pointing t= hat out. Any more comments/corrections? Francois On 9 Nov 2012, at 16:13, Brandenburg, R. (Ray) van wrote: > Hi Francois, > > One comment: the minutes note that the last presentation on Thursday was = me presenting the HAS experiments draft, while it was actually Bhumip prese= nting the Intra-CDN providers draft (we diverged from the agenda). > > Ray > > On 9 nov. 2012, at 10:04, "Francois Le Faucheur (flefauch)" > wrote: > >> Folks, >> >> Draft minutes for our two CDNI sessions of IETF-85 have been posted. You= can access them from the IETF-85 Meeting Material page or directly from: >> http://www.ietf.org/proceedings/85/minutes/minutes-85-cdni. >> >> Thanks to Marcin for providing raw notes. >> >> We could not quite capture all statements of the discussion in some occu= rrences, and the audio recording won't be available for a little while, but= the draft minutes aim at capturing the essential of the discussion. >> >> Corrections/comments welcome. >> >> Cheers >> >> Francois >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni > This e-mail and its contents are subject to the DISCLAIMER at http://www.= tno.nl/emaildisclaimer > _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC236DA6F2DA77449EF2D02DF4471A8D223064xmbrcdx10ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable Hello Bhumip,
I suggest you communicate directly with Marcin.
Cheers
Francois

On 12 Nov 2012, at 19:53, B.K= hasnabish@ieee.org wrote:

Hi Francois ,
 
During the presentation of the following draft Marcin Pilarski suggest= ed that in his CDNI expt.
the problem of content duplication does not match at all what he is se= e in his
environment
Content De-duplication for CDNi Optimization,
draft-jin-cdni-content-deduplication-optimization-03: Bhumip Khasnabis= h
 
Do you have access to Marcin's experiment. setup, traffic/network/cont= ent profile,
and results? If yes, can you share those with us.
If not can you ask Marcin to share the setup info and results with us = ASAP.
 
Many  thanks in advance.
 
Best.
 
Bhumip
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> Draft minutes for our two CDNI sessions of IETF-85 have been = posted. You can access them from the IETF-85 Meeting Material page or direc= tly from:
>> http://www.ietf.org/proceedings/85/minutes/minutes-85-cdni.

- problem of de-duplication explained with 3 scenarios.
- survey up to 60% data stored is duplicated.
*Marcin Pilarski: what are the assumptions behind these numbers because tha= t does not match at all what I see in my environment
*Bhumip: will be explained in this draft or in separate draft
::::::
- Option 2 - decide it is a nice-to-have, but is not crucial for initi= al versions of CDNI interfaces. We continue the work on it inside the WG,  but do= not aim to support it in first version of the CDNI interfaces.
::::::::
- Option 2: ~20 people

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
On Mon, Nov 12, 2012 at 4:16 AM, Francois Le Faucheur (flefauch) <flefauch@cisco.= com> wrote:
Hi everyone,

The draft minutes have been updated with:
        * the correction discussed below by Ray
        * a correction on the Show-of-hand results for = the long-tail I-D (that were swapped in earlier version) - thanks to Dave M= elton for pointing that out.

Any more comments/corrections?

Francois


On 9 Nov 2012, at 16:13, Brandenburg, R. (Ray) van wrote:

> Hi Francois,
>
> One comment: the minutes note that the last presentation on Thursday w= as me presenting the HAS experiments draft, while it was actually Bhumip pr= esenting the Intra-CDN providers draft (we diverged from the agenda).
>
> Ray
>
> On 9 nov. 2012, at 10:04, "Francois Le Faucheur (flefauch)" = <flefauch@cisco.com> wrote:=
>
>> Folks,
>>
>> Draft minutes for our two CDNI sessions of IETF-85 have been poste= d. You can access them from the IETF-85 Meeting Material page or directly f= rom:
>> http://www.ietf.org/proceedings/85/minutes/minutes-85-cdni.
>>
>> Thanks to Marcin for providing raw notes.
>>
>> We could not quite capture all statements of the discussion in som= e occurrences, and the audio recording won't be available for a little whil= e, but the draft minutes aim at capturing the essential of the discussion.<= br> >>
>> Corrections/comments welcome.
>>
>> Cheers
>>
>> Francois
>> _______________________________________________
>> CDNi mailing list
>> CDNi@ietf.org
>> https://www.ietf.org/mailman/listinfo/cdni
> This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer
>

_______________________________________________
CDNi mailing list
CDNi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cdni


 

--_000_FC236DA6F2DA77449EF2D02DF4471A8D223064xmbrcdx10ciscocom_-- From vumip1@gmail.com Tue Nov 13 07:01:54 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECBEF21F8574 for ; Tue, 13 Nov 2012 07:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkCA-vBWNnf9 for ; Tue, 13 Nov 2012 07:01:51 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5E51F21F86A8 for ; Tue, 13 Nov 2012 07:01:49 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2463854lbk.31 for ; Tue, 13 Nov 2012 07:01:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/ScBjOLnPC8tUXFsVRvM2mw+xpdVva2n9DyXtEpehQE=; b=re0mZy4awm3U5d2FiQPZwWxvENdy1wkIUJnsjs8zYJQPGtCe/GspwmaOY6rVi8pbcn WVD/tnF7YP9o0Z4ZGuvCh52wgzy66gQqDA2qptRsxFraFbWmfB6AcKJXnb1FpevT8TPc QqZOkoo9segCOgp7ROnjjuFygCYqQkl2KZWd1t/PVAqEotTHaSvjrkxkAnl2C5/0VY7L GfPc8SLzcfKzeiW/Mhth3Ten1W6AihdhLwaiXvrTcjNSGj1QOU724yHQA7SydYy7pYqa BONW4KgYmM9odWw4Qnvl8gIBGPwayQshtCQrO+LEQRm+BKYCnU+BgJC0jeRNX9jPxTfw B0ww== MIME-Version: 1.0 Received: by 10.112.24.6 with SMTP id q6mr9625288lbf.24.1352818906683; Tue, 13 Nov 2012 07:01:46 -0800 (PST) Received: by 10.114.5.161 with HTTP; Tue, 13 Nov 2012 07:01:46 -0800 (PST) In-Reply-To: References: Date: Tue, 13 Nov 2012 10:01:46 -0500 Message-ID: From: "B.Khasnabish@ieee.org" To: "Francois Le Faucheur (flefauch)" Content-Type: multipart/alternative; boundary=e0cb4efe2a0a60d8ca04ce61b2cc Cc: "cdni@ietf.org" , Ram Krishnan Subject: Re: [CDNi] Requesting Marcin Pilarski to share de-dup expt setup and results, ..Re: Draft IETF-85 minutes posted X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 15:01:55 -0000 --e0cb4efe2a0a60d8ca04ce61b2cc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello Francois, PLS send us Marcin's email address, if you have it. Not sure whether Marcin monitors the discussion in the CDNI WG. If anyone knows Marcin's email address, pls forward this email ASAP. Thanks Best. Bhumip On Tue, Nov 13, 2012 at 2:57 AM, Francois Le Faucheur (flefauch) < flefauch@cisco.com> wrote: > Hello Bhumip, > I suggest you communicate directly with Marcin. > Cheers > Francois > > On 12 Nov 2012, at 19:53, B.Khasnabish@ieee.org wrote: > > Hi Francois , > > During the presentation of the following draft Marcin Pilarski suggested > that in his CDNI expt. > the problem of content duplication does not match at all what he is see i= n > his > environment > Content De-duplication for CDNi Optimization, > draft-jin-cdni-content-deduplication-optimization-03: Bhumip Khasnabish > > Do you have access to Marcin's experiment. setup, > traffic/network/content profile, > and results? If yes, can you share those with us. > If not can you ask Marcin to share the setup info and results with us ASA= P. > > Many thanks in advance. > > Best. > > Bhumip > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > >> Draft minutes for our two CDNI sessions of IETF-85 have been posted. > You can access them from the IETF-85 Meeting Material page or directly fr= om: > >> http://www.ietf.org/proceedings/85/minutes/minutes-85-cdni. > > - problem of de-duplication explained with 3 scenarios. > - survey up to 60% data stored is duplicated. > *Marcin Pilarski: what are the assumptions behind these numbers because > that does not match at all what I see in my environment > *Bhumip: will be explained in this draft or in separate draft > :::::: > - Option 2 - decide it is a nice-to-have, but is not crucial for initial > versions of CDNI interfaces. We *continue the work on it inside the WG*, > but do not aim to support it in first version of the CDNI interfaces. > :::::::: > - Option 2: ~20 people > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > On Mon, Nov 12, 2012 at 4:16 AM, Francois Le Faucheur (flefauch) < > flefauch@cisco.com> wrote: > >> Hi everyone, >> >> The draft minutes have been updated with: >> * the correction discussed below by Ray >> * a correction on the Show-of-hand results for the long-tail I-D >> (that were swapped in earlier version) - thanks to Dave Melton for point= ing >> that out. >> >> Any more comments/corrections? >> >> Francois >> >> >> On 9 Nov 2012, at 16:13, Brandenburg, R. (Ray) van wrote: >> >> > Hi Francois, >> > >> > One comment: the minutes note that the last presentation on Thursday >> was me presenting the HAS experiments draft, while it was actually Bhumi= p >> presenting the Intra-CDN providers draft (we diverged from the agenda). >> > >> > Ray >> > >> > On 9 nov. 2012, at 10:04, "Francois Le Faucheur (flefauch)" < >> flefauch@cisco.com> wrote: >> > >> >> Folks, >> >> >> >> Draft minutes for our two CDNI sessions of IETF-85 have been posted. >> You can access them from the IETF-85 Meeting Material page or directly f= rom: >> >> http://www.ietf.org/proceedings/85/minutes/minutes-85-cdni. >> >> >> >> Thanks to Marcin for providing raw notes. >> >> >> >> We could not quite capture all statements of the discussion in some >> occurrences, and the audio recording won't be available for a little whi= le, >> but the draft minutes aim at capturing the essential of the discussion. >> >> >> >> Corrections/comments welcome. >> >> >> >> Cheers >> >> >> >> Francois >> >> _______________________________________________ >> >> CDNi mailing list >> >> CDNi@ietf.org >> >> https://www.ietf.org/mailman/listinfo/cdni >> > This e-mail and its contents are subject to the DISCLAIMER at >> http://www.tno.nl/emaildisclaimer >> > >> >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >> > > > > > > --=20 Best. Bhumip Khasnabish vumip1@gmail.com b.khasnabish@ieee.org bhumip.khasnabish@zteusa.com +1-781-752-8003 (mobile) http://tinyurl.com/bhumip __o _ `\ <, _ .......... ( =95 ) / ( =95 ) ...................... --e0cb4efe2a0a60d8ca04ce61b2cc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hello Francois,
=A0
PLS send us Marcin's email= address, if you have it.
=A0
Not sure whether Marcin monito= rs the discussion in the CDNI WG.
=A0
If anyone knows Marcin's e= mail address, pls forward this email ASAP.
=A0
Thanks
=A0
Best.
=A0
Bhumip
=A0


=A0
On Tue, Nov 13, 2012 at 2:57 AM, Francois Le Fau= cheur (flefauch) <flefauch@cisco.com> wrote:
Hello Bhumip,=20
I suggest you communicate directly with Marcin.
Cheers
Francois

On 12 Nov 2012, at 19:53, B.Khasnabish@ieee.org wrote:

Hi Francois ,
=A0
During the presentation of the following draft Marcin Pilarski suggest= ed that in his CDNI expt.
the problem of content duplication does not match at all what he is se= e in his
environment
Content De-duplication for CDNi Optimization,
draft-jin-cdni-content-deduplication-optimization-03: Bhumip Khasnabis= h
=A0
Do you have access to Marcin's experiment. setup, traffic/network/= content=A0profile,
and results? If yes, can you share those with us.
If not can you ask Marcin to share the setup info and results with us = ASAP.
=A0
Many=A0 thanks in advance.
=A0
Best.
=A0
Bhumip
=A0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> Draft minutes for our two CDNI sessions of IETF-85 have been = posted. You can access them from the IETF-85 Meeting Material page or direc= tly from:
>> http://www.ietf.org/proceedings/85/minu= tes/minutes-85-cdni.

- problem of de-duplication explained with 3 scenarios.
- survey up= to 60% data stored is duplicated.
*Marcin Pilarski: what are the assum= ptions behind these numbers because that does not match at all what I see i= n my environment
*Bhumip: will be explained in this draft or in separate draft
::::::
- Option 2 - decide it is a nice-to-have, but is not crucial for initi= al versions of CDNI interfaces. We continue the work on it insid= e the WG,=A0 but do not aim to support it in first version of = the CDNI interfaces.
::::::::
- Option 2: ~20 people

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=A0
On Mon, Nov 12, 2012 at 4:16 AM, Francois Le Faucheur (flefauch) <fl= efauch@cisco.com> wrote:
Hi everyone,

The draft minutes= have been updated with:
=A0 =A0 =A0 =A0 * the correction discussed belo= w by Ray
=A0 =A0 =A0 =A0 * a correction on the Show-of-hand results for the long-tai= l I-D (that were swapped in earlier version) - thanks to Dave Melton for po= inting that out.

Any more comments/corrections?

Francois


On 9 Nov 2012, at 16:13, Brandenburg, R. (Ray) van wrote:
<= br>> Hi Francois,
>
> One comment: the minutes note that the= last presentation on Thursday was me presenting the HAS experiments draft,= while it was actually Bhumip presenting the Intra-CDN providers draft (we = diverged from the agenda).
>
> Ray
>
> On 9 nov. 2012, at 10:04, "Francois L= e Faucheur (flefauch)" <flefauch@cisco.com> wrote:
>
>> Folks, >>
>> Draft minutes for our two CDNI sessions of IETF-85 hav= e been posted. You can access them from the IETF-85 Meeting Material page o= r directly from:
>> http://www.ietf.org/proceedings/= 85/minutes/minutes-85-cdni.
>>
>> Thanks to Marcin for providing raw notes.
>><= br>>> We could not quite capture all statements of the discussion in = some occurrences, and the audio recording won't be available for a litt= le while, but the draft minutes aim at capturing the essential of the discu= ssion.
>>
>> Corrections/comments welcome.
>>
>> = Cheers
>>
>> Francois
>> _______________________= ________________________
>> CDNi mailing list
>> CDNi@ietf.org
>> https://www.ietf.org/mailman/listinfo/cdni
> This e-mail a= nd its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer=
>

_______________________________________________
CDNi mailing= list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni


=A0




-= -
Best.

Bhumip Khasnabish
+1-781-752-8003 (mobile)
http://tinyurl.com/bhumip

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 __o
=A0= =A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0 _ `\ <, _
.......... ( =95 ) / ( =95 = ) ......................

--e0cb4efe2a0a60d8ca04ce61b2cc-- From vumip1@gmail.com Tue Nov 13 07:20:37 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDDCE21F85B8 for ; Tue, 13 Nov 2012 07:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XE4meF4ywMhf for ; Tue, 13 Nov 2012 07:20:35 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 41E3421F842E for ; Tue, 13 Nov 2012 07:20:32 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2481882lbk.31 for ; Tue, 13 Nov 2012 07:20:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MjLEvMDBQP5+60hc4KcRiuK73JYQ7u6rXGTySL0Lq5M=; b=r9t9582NIkkTWQCnYcrQP7OrN5nula4iJKWP2svhG0w2uayTJP1tlJqtpUvQLhEHrn I0FUylEx+w5RmN9R+LvKTCUOsDwQVe3US3cXj7krR4i9Z2enENtH7JACP+FsHJGhrb1t sYgegcalz22W4luZMYjhltlk9FrhgV3JnoBLC4/C9QEC1pnJXAtKsIaGpu02+Fahgb43 L/rJUysDB7GIiyNGpFtLChNp8JmFjEgDNGcrkkv3mIJw+MrM6exZpymSE4vO/rPFEANN Fellge7CQPz07P7H4djpRozUdGkIhl4aBlESj28mKw92iqYUCNk/8xmZZu56fYXsdz8n xM5A== MIME-Version: 1.0 Received: by 10.112.26.233 with SMTP id o9mr9644589lbg.101.1352820030765; Tue, 13 Nov 2012 07:20:30 -0800 (PST) Received: by 10.114.5.161 with HTTP; Tue, 13 Nov 2012 07:20:30 -0800 (PST) In-Reply-To: References: Date: Tue, 13 Nov 2012 10:20:30 -0500 Message-ID: From: "B.Khasnabish@ieee.org" To: Pilarski Marcin - Korpo TP Content-Type: multipart/alternative; boundary=bcaec554dbca60f9f604ce61f5dd Cc: "cdni@ietf.org" , "ramkri123@gmail.com" Subject: Re: [CDNi] Odp.: Re: Requesting Marcin Pilarski to share de-dup expt setup and results, ..Re: Draft IETF-85 minutes posted X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 15:20:37 -0000 --bcaec554dbca60f9f604ce61f5dd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Marcin, During the presentation of the following draft you suggested that in your CDNI experiment the problem of content duplication does not match at all what yo= u see in your environment. > Content De-duplication for CDNi Optimization, > draft-jin-cdni-content-deduplication-optimization-03: Bhumip Khasnabish Can you share details of your experiment. setup, traffic/network/content profile, and results? We plan to update our drafts soon, and would appreciate quick feedback. Many thanks in advance. Best. Bhumip =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >> Draft minutes for our two CDNI sessions of IETF-85 have been posted. You can access them from the IETF-85 Meeting Material page or directly from: >> http://www.ietf.org/proceedings/85/minutes/minutes-85-cdni. - problem of de-duplication explained with 3 scenarios. - survey up to 60% data stored is duplicated. *Marcin Pilarski: what are the assumptions behind these numbers because that does not match at all what I see in my environment *Bhumip: will be explained in this draft or in separate draft :::::: - Option 2 - decide it is a nice-to-have, but is not crucial for initial versions of CDNI interfaces. We continue the work on it inside the WG, but do not aim to support it in first version of the CDNI interfaces. :::::::: - Option 2: ~20 people On Tue, Nov 13, 2012 at 10:06 AM, Pilarski Marcin - Korpo TP < Marcin.Pilarski@orange.com> wrote: > Dear Bhumip, > > here is one of them, > > Best regards, > Marcin Pilarski > > ---Sent from mobile device > > *Od*: B.Khasnabish@ieee.org [mailto:vumip1@gmail.com] > *Wys=C5=82ano*: Tuesday, November 13, 2012 04:01 PM > *Do*: Francois Le Faucheur (flefauch) > *DW*: cdni@ietf.org ; Ram Krishnan > *Temat*: Re: [CDNi] Requesting Marcin Pilarski to share de-dup expt setup > and results, ..Re: Draft IETF-85 minutes posted > > Hello Francois, > > PLS send us Marcin's email address, if you have it. > > Not sure whether Marcin monitors the discussion in the CDNI WG. > > If anyone knows Marcin's email address, pls forward this email ASAP. > > Thanks > > Best. > > Bhumip > > > > > On Tue, Nov 13, 2012 at 2:57 AM, Francois Le Faucheur (flefauch) < > flefauch@cisco.com> wrote: > >> Hello Bhumip, >> I suggest you communicate directly with Marcin. >> Cheers >> Francois >> >> On 12 Nov 2012, at 19:53, B.Khasnabish@ieee.org wrote: >> >> Hi Francois , >> >> During the presentation of the following draft Marcin Pilarski suggested >> that in his CDNI expt. >> the problem of content duplication does not match at all what he is see >> in his >> environment >> Content De-duplication for CDNi Optimization, >> draft-jin-cdni-content-deduplication-optimization-03: Bhumip Khasnabish >> >> Do you have access to Marcin's experiment. setup, >> traffic/network/content profile, >> and results? If yes, can you share those with us. >> If not can you ask Marcin to share the setup info and results with us >> ASAP. >> >> Many thanks in advance. >> >> Best. >> >> Bhumip >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Draft minutes for our two CDNI sessions of IETF-85 have been posted. >> You can access them from the IETF-85 Meeting Material page or directly f= rom: >> >> http://www.ietf.org/proceedings/85/minutes/minutes-85-cdni. >> >> - problem of de-duplication explained with 3 scenarios. >> - survey up to 60% data stored is duplicated. >> *Marcin Pilarski: what are the assumptions behind these numbers because >> that does not match at all what I see in my environment >> *Bhumip: will be explained in this draft or in separate draft >> :::::: >> - Option 2 - decide it is a nice-to-have, but is not crucial for initial >> versions of CDNI interfaces. We *continue the work on it inside the WG*, >> but do not aim to support it in first version of the CDNI interfaces. >> :::::::: >> - Option 2: ~20 people >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> On Mon, Nov 12, 2012 at 4:16 AM, Francois Le Faucheur (flefauch) < >> flefauch@cisco.com> wrote: >> >>> Hi everyone, >>> >>> The draft minutes have been updated with: >>> * the correction discussed below by Ray >>> * a correction on the Show-of-hand results for the long-tail I-= D >>> (that were swapped in earlier version) - thanks to Dave Melton for poin= ting >>> that out. >>> >>> Any more comments/corrections? >>> >>> Francois >>> >>> >>> On 9 Nov 2012, at 16:13, Brandenburg, R. (Ray) van wrote: >>> >>> > Hi Francois, >>> > >>> > One comment: the minutes note that the last presentation on Thursday >>> was me presenting the HAS experiments draft, while it was actually Bhum= ip >>> presenting the Intra-CDN providers draft (we diverged from the agenda). >>> > >>> > Ray >>> > >>> > On 9 nov. 2012, at 10:04, "Francois Le Faucheur (flefauch)" < >>> flefauch@cisco.com> wrote: >>> > >>> >> Folks, >>> >> >>> >> Draft minutes for our two CDNI sessions of IETF-85 have been posted. >>> You can access them from the IETF-85 Meeting Material page or directly = from: >>> >> http://www.ietf.org/proceedings/85/minutes/minutes-85-cdni. >>> >> >>> >> Thanks to Marcin for providing raw notes. >>> >> >>> >> We could not quite capture all statements of the discussion in some >>> occurrences, and the audio recording won't be available for a little wh= ile, >>> but the draft minutes aim at capturing the essential of the discussion. >>> >> >>> >> Corrections/comments welcome. >>> >> >>> >> Cheers >>> >> >>> >> Francois >>> >> _______________________________________________ >>> >> CDNi mailing list >>> >> CDNi@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/cdni >>> > This e-mail and its contents are subject to the DISCLAIMER at >>> http://www.tno.nl/emaildisclaimer >>> > >>> >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>> >> >> >> >> >> >> > > > > --bcaec554dbca60f9f604ce61f5dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Marcin,
=C2=A0
During the presentation of the following draft you suggested that in y= our CDNI
experiment the problem of content duplication does not match at all wh= at you
see in your environment.
=C2=A0
> Content De-duplication for CDNi Optimization,
> draft-jin-= cdni-content-deduplication-optimization-03: Bhumip Khasnabish
=C2=A0
= Can you share details of your=C2=A0experiment. setup, traffic/network/conte= nt profile,
and results?=C2=A0
=C2=A0
We plan to update our drafts soon, and would appreciate quick feedback= .
=C2=A0
Many=C2=A0 thanks in advance.
=C2=A0
Best.
=C2=A0
Bhumip=C2=A0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> Draft minutes for our two = CDNI sessions of IETF-85 have been posted. You can access them from the IET= F-85 Meeting Material page or directly from:
>> http://www.ietf.org/proceedings/85/minutes/minutes-85-cdni.

- problem of de-duplication explained with 3 scenarios.
- survey up = to 60% data stored is duplicated.
*Marcin Pilarski: what are the assump= tions behind these numbers because that does not match at all what I see in= my environment
*Bhumip: will be explained in this draft or in separate draft
::::::
= - Option 2 - decide it is a nice-to-have, but is not crucial for initial ve= rsions of CDNI interfaces. We continue the work on it inside the WG,=C2=A0 = but do not aim to support it in first version of the CDNI interfaces.

::::::::
- Option 2: ~20 people

On Tue, Nov 13, 2012 at 10:06 AM, Pilarski Marci= n - Korpo TP <Marcin.Pilarski@orange.com> wrote:
Dear Bhumip,

here is one of them,

B= est regards,
Marcin Pilarski

---Sent from mobile device =C2=A0
Od: B.Khasnabish@ieee.org [mailto:<= a href=3D"mailto:vumip1@gmail.com" target=3D"_blank">vumip1@gmail.com] =
Wys=C5=82ano: Tuesday, November 13, 2012 04:01 PM
Do: Fran= cois Le Faucheur (flefauch) <flefauch@cisco.com>
DW: cdni@ietf.org <cdni@ietf.org>; Ram Krishnan <ramkri123@gmail.com&= gt;
Temat: Re: [CDNi] Requesting Marcin Pilarski to share de-dup expt se= tup and results, ..Re: Draft IETF-85 minutes posted
=C2=A0
Hello Francois,
=C2=A0
PLS send us Marcin's email= address, if you have it.
=C2=A0
Not sure whether Marcin monito= rs the discussion in the CDNI WG.
=C2=A0
If anyone knows Marcin's e= mail address, pls forward this email ASAP.
=C2=A0
Thanks
=C2=A0
Best.
=C2=A0
Bhumip
=C2=A0


=C2=A0
On Tue, Nov 13, 2012 at 2:57 AM, Francois Le Fau= cheur (flefauch) <flefauch@cisco.com> wrote:
Hello Bhumip,=20
I suggest you communicate directly with Marcin.
Cheers
Francois

On 12 Nov 2012, at 19:53, B.Khasnabish@ieee.org wrote:

Hi Francois ,
=C2=A0
During the presentation of the following draft Marcin Pilarski suggest= ed that in his CDNI expt.
the problem of content duplication does not match at all what he is se= e in his
environment
Content De-duplication for CDNi Optimization,
draft-jin-cdni-content-deduplication-optimization-03: Bhumip Khasnabis= h
=C2=A0
Do you have access to Marcin's experiment. setup, traffic/network/= content=C2=A0profile,
and results? If yes, can you share those with us.
If not can you ask Marcin to share the setup info and results with us = ASAP.
=C2=A0
Many=C2=A0 thanks in advance.
=C2=A0
Best.
=C2=A0
Bhumip
=C2=A0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> Draft minutes for our two CDNI sessions of IETF-85 have been = posted. You can access them from the IETF-85 Meeting Material page or direc= tly from:
>> http://www.ietf.org/proceedings/85/minu= tes/minutes-85-cdni.

- problem of de-duplication explained with 3 scenarios.
- survey up= to 60% data stored is duplicated.
*Marcin Pilarski: what are the assum= ptions behind these numbers because that does not match at all what I see i= n my environment
*Bhumip: will be explained in this draft or in separate draft
::::::
- Option 2 - decide it is a nice-to-have, but is not crucial for initi= al versions of CDNI interfaces. We continue the work on it insid= e the WG,=C2=A0 but do not aim to support it in first version = of the CDNI interfaces.
::::::::
- Option 2: ~20 people

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0
On Mon, Nov 12, 2012 at 4:16 AM, Francois Le Faucheur (flefauch) <fl= efauch@cisco.com> wrote:
Hi everyone,

The draft minutes= have been updated with:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * the correction di= scussed below by Ray
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * a correction on the Show-of-hand results for = the long-tail I-D (that were swapped in earlier version) - thanks to Dave M= elton for pointing that out.

Any more comments/corrections?

Francois


On 9 Nov 2012, at 16:13, Brandenburg, R. (Ray) van wrote:
<= br>> Hi Francois,
>
> One comment: the minutes note that the= last presentation on Thursday was me presenting the HAS experiments draft,= while it was actually Bhumip presenting the Intra-CDN providers draft (we = diverged from the agenda).
>
> Ray
>
> On 9 nov. 2012, at 10:04, "Francois L= e Faucheur (flefauch)" <flefauch@cisco.com> wrote:
>
>> Folks, >>
>> Draft minutes for our two CDNI sessions of IETF-85 hav= e been posted. You can access them from the IETF-85 Meeting Material page o= r directly from:
>> http://www.ietf.org/proceedings/= 85/minutes/minutes-85-cdni.
>>
>> Thanks to Marcin for providing raw notes.
>><= br>>> We could not quite capture all statements of the discussion in = some occurrences, and the audio recording won't be available for a litt= le while, but the draft minutes aim at capturing the essential of the discu= ssion.
>>
>> Corrections/comments welcome.
>>
>> = Cheers
>>
>> Francois
>> _______________________= ________________________
>> CDNi mailing list
>> CDNi@ietf.org
>> https://www.ietf.org/mailman/listinfo/cdni
> This e-mail a= nd its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer=
>

_______________________________________________
CDNi mailing= list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni


=C2=A0



=C2=A0
--bcaec554dbca60f9f604ce61f5dd-- From Marcin.Pilarski@orange.com Tue Nov 13 07:24:54 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9B921F85C9 for ; Tue, 13 Nov 2012 07:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.487 X-Spam-Level: X-Spam-Status: No, score=0.487 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePX0eXvTWYUk for ; Tue, 13 Nov 2012 07:24:52 -0800 (PST) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) by ietfa.amsl.com (Postfix) with ESMTP id 02CC921F85C2 for ; Tue, 13 Nov 2012 07:24:49 -0800 (PST) Received: from 10.236.62.137 (EHLO OPE10HT03.tp.gk.corp.tepenet) ([10.236.62.137]) by mailin.tpsa.pl (MOS 3.10.10a-GA FastPath queued) with ESMTP id CVX34061; Tue, 13 Nov 2012 16:24:43 +0100 (CET) From: Pilarski Marcin - Korpo TP To: "'vumip1@gmail.com'" Thread-Topic: Odp.: Re: Odp.: Re: [CDNi] Requesting Marcin Pilarski to share de-dup expt setup and results, ..Re: Draft IETF-85 minutes posted Thread-Index: AQHNwbJr7kWbKYslFkaIxi+BOF+YY5fn4p2J Date: Tue, 13 Nov 2012 15:24:42 +0000 Message-ID: In-Reply-To: Accept-Language: pl-PL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_A60E005FD8778E41AE40379D75874B2D1DA7D434OPE10MB02tpgkco_" MIME-Version: 1.0 Cc: "'cdni@ietf.org'" , "'ramkri123@gmail.com'" Subject: [CDNi] Odp.: Re: Odp.: Re: Requesting Marcin Pilarski to share de-dup expt setup and results, ..Re: Draft IETF-85 minutes posted X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 15:24:54 -0000 --_000_A60E005FD8778E41AE40379D75874B2D1DA7D434OPE10MB02tpgkco_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBCaHVtaXAsDQoNCk15IGNvbW1lbnQgYW5kIGNyaXRpY2lzbSB3YXMgcmVsYXRlZCB0byB0 aGUgeW91cnMgc2V0dXAgdGhhdCBjb21wbGV0ZWx5IG5lZ2xlY3RlZCBEUk0gdGVjaG5vbG9neSBl eGlzdGVuY2UgdGhhdCBpcyBjb21tb24gaXMgYWxtb3N0IGFsbCBPcmFuZ2UncyBzZXR1cHMuIE1v cmUgb3ZlciBkdWUgdG8gdGhpcyBmYWN0IHRoZSBjb250ZW50IGlzIGVuY3J5cHRlZCBhbmQgcGFj a2FnZWQgZm9yIGVhY2ggQ1Agd2l0aCB0aGVpciBpbmRpdmlkdWFsIGtleSBzbyBkZS1kdXBsaWNh dGlvbiBpcyBub3QgYW4gaXNzdWUgYXQgYWxsIC0gYmVjYXVzZSBjYW5ub3QgYmUgd2hlbiBkaWZm ZXJlbnQgQ1AgaGFzIGRpZmZlcmVudCBlbmNyeXB0aW9ucyBrZXlzLg0KDQpTbyB3aGF0IEkgd291 bGQgbGlrZSB0byBzZWUgaXMgcGFyYWdyYXBoIGFib3V0IGNvLWV4aXN0ZW5jZSBvZiBleGlzdGlu ZyBEUk0gdGVjaG5vbG9neSBhbmQgeW91cnMgcHJvcG9zYWwgYmVmb3JlIHdlIGRvIGdvIGFueSBm dXJ0aGVyLg0KDQpJIGhvcGUgdGhpcyB3aWxsIGhlbHAsDQpNYXJjaW4NCg0KLS0tU2VudCBmcm9t IG1vYmlsZSBkZXZpY2UNCg0KT2Q6IEIuS2hhc25hYmlzaEBpZWVlLm9yZyBbbWFpbHRvOnZ1bWlw MUBnbWFpbC5jb21dDQpXeXPFgmFubzogVHVlc2RheSwgTm92ZW1iZXIgMTMsIDIwMTIgMDQ6MjAg UE0NCkRvOiBQaWxhcnNraSBNYXJjaW4gLSBLb3JwbyBUUA0KRFc6IGZsZWZhdWNoQGNpc2NvLmNv bSA8ZmxlZmF1Y2hAY2lzY28uY29tPjsgY2RuaUBpZXRmLm9yZyA8Y2RuaUBpZXRmLm9yZz47IHJh bWtyaTEyM0BnbWFpbC5jb20gPHJhbWtyaTEyM0BnbWFpbC5jb20+OyBsaS5taWFuQHp0ZS5jb20u Y24gPGxpLm1pYW5AenRlLmNvbS5jbj4NClRlbWF0OiBSZTogT2RwLjogUmU6IFtDRE5pXSBSZXF1 ZXN0aW5nIE1hcmNpbiBQaWxhcnNraSB0byBzaGFyZSBkZS1kdXAgZXhwdCBzZXR1cCBhbmQgcmVz dWx0cywgLi5SZTogRHJhZnQgSUVURi04NSBtaW51dGVzIHBvc3RlZA0KDQpIZWxsbyBNYXJjaW4s DQoNCkR1cmluZyB0aGUgcHJlc2VudGF0aW9uIG9mIHRoZSBmb2xsb3dpbmcgZHJhZnQgeW91IHN1 Z2dlc3RlZCB0aGF0IGluIHlvdXIgQ0ROSQ0KZXhwZXJpbWVudCB0aGUgcHJvYmxlbSBvZiBjb250 ZW50IGR1cGxpY2F0aW9uIGRvZXMgbm90IG1hdGNoIGF0IGFsbCB3aGF0IHlvdQ0Kc2VlIGluIHlv dXIgZW52aXJvbm1lbnQuDQoNCj4gQ29udGVudCBEZS1kdXBsaWNhdGlvbiBmb3IgQ0ROaSBPcHRp bWl6YXRpb24sDQo+IGRyYWZ0LWppbi1jZG5pLWNvbnRlbnQtZGVkdXBsaWNhdGlvbi1vcHRpbWl6 YXRpb24tMDM6IEJodW1pcCBLaGFzbmFiaXNoDQoNCkNhbiB5b3Ugc2hhcmUgZGV0YWlscyBvZiB5 b3VyIGV4cGVyaW1lbnQuIHNldHVwLCB0cmFmZmljL25ldHdvcmsvY29udGVudCBwcm9maWxlLA0K YW5kIHJlc3VsdHM/DQoNCldlIHBsYW4gdG8gdXBkYXRlIG91ciBkcmFmdHMgc29vbiwgYW5kIHdv dWxkIGFwcHJlY2lhdGUgcXVpY2sgZmVlZGJhY2suDQoNCk1hbnkgIHRoYW5rcyBpbiBhZHZhbmNl Lg0KDQpCZXN0Lg0KDQpCaHVtaXANCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPj4gRHJhZnQgbWludXRlcyBmb3Igb3VyIHR3byBD RE5JIHNlc3Npb25zIG9mIElFVEYtODUgaGF2ZSBiZWVuIHBvc3RlZC4gWW91IGNhbiBhY2Nlc3Mg dGhlbSBmcm9tIHRoZSBJRVRGLTg1IE1lZXRpbmcgTWF0ZXJpYWwgcGFnZSBvciBkaXJlY3RseSBm cm9tOg0KPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84NS9taW51dGVzL21pbnV0 ZXMtODUtY2RuaS4NCg0KLSBwcm9ibGVtIG9mIGRlLWR1cGxpY2F0aW9uIGV4cGxhaW5lZCB3aXRo IDMgc2NlbmFyaW9zLg0KLSBzdXJ2ZXkgdXAgdG8gNjAlIGRhdGEgc3RvcmVkIGlzIGR1cGxpY2F0 ZWQuDQoqTWFyY2luIFBpbGFyc2tpOiB3aGF0IGFyZSB0aGUgYXNzdW1wdGlvbnMgYmVoaW5kIHRo ZXNlIG51bWJlcnMgYmVjYXVzZSB0aGF0IGRvZXMgbm90IG1hdGNoIGF0IGFsbCB3aGF0IEkgc2Vl IGluIG15IGVudmlyb25tZW50DQoqQmh1bWlwOiB3aWxsIGJlIGV4cGxhaW5lZCBpbiB0aGlzIGRy YWZ0IG9yIGluIHNlcGFyYXRlIGRyYWZ0DQo6Ojo6OjoNCi0gT3B0aW9uIDIgLSBkZWNpZGUgaXQg aXMgYSBuaWNlLXRvLWhhdmUsIGJ1dCBpcyBub3QgY3J1Y2lhbCBmb3IgaW5pdGlhbCB2ZXJzaW9u cyBvZiBDRE5JIGludGVyZmFjZXMuIFdlIGNvbnRpbnVlIHRoZSB3b3JrIG9uIGl0IGluc2lkZSB0 aGUgV0csICBidXQgZG8gbm90IGFpbSB0byBzdXBwb3J0IGl0IGluIGZpcnN0IHZlcnNpb24gb2Yg dGhlIENETkkgaW50ZXJmYWNlcy4NCg0KOjo6Ojo6OjoNCi0gT3B0aW9uIDI6IH4yMCBwZW9wbGUN Cg0KDQpPbiBUdWUsIE5vdiAxMywgMjAxMiBhdCAxMDowNiBBTSwgUGlsYXJza2kgTWFyY2luIC0g S29ycG8gVFAgPE1hcmNpbi5QaWxhcnNraUBvcmFuZ2UuY29tPG1haWx0bzpNYXJjaW4uUGlsYXJz a2lAb3JhbmdlLmNvbT4+IHdyb3RlOg0KRGVhciBCaHVtaXAsDQoNCmhlcmUgaXMgb25lIG9mIHRo ZW0sDQoNCkJlc3QgcmVnYXJkcywNCk1hcmNpbiBQaWxhcnNraQ0KDQotLS1TZW50IGZyb20gbW9i aWxlIGRldmljZQ0KDQpPZDogQi5LaGFzbmFiaXNoQGllZWUub3JnPG1haWx0bzpCLktoYXNuYWJp c2hAaWVlZS5vcmc+IFttYWlsdG86dnVtaXAxQGdtYWlsLmNvbTxtYWlsdG86dnVtaXAxQGdtYWls LmNvbT5dDQpXeXPFgmFubzogVHVlc2RheSwgTm92ZW1iZXIgMTMsIDIwMTIgMDQ6MDEgUE0NCkRv OiBGcmFuY29pcyBMZSBGYXVjaGV1ciAoZmxlZmF1Y2gpIDxmbGVmYXVjaEBjaXNjby5jb208bWFp bHRvOmZsZWZhdWNoQGNpc2NvLmNvbT4+DQpEVzogY2RuaUBpZXRmLm9yZzxtYWlsdG86Y2RuaUBp ZXRmLm9yZz4gPGNkbmlAaWV0Zi5vcmc8bWFpbHRvOmNkbmlAaWV0Zi5vcmc+PjsgUmFtIEtyaXNo bmFuIDxyYW1rcmkxMjNAZ21haWwuY29tPG1haWx0bzpyYW1rcmkxMjNAZ21haWwuY29tPj4NClRl bWF0OiBSZTogW0NETmldIFJlcXVlc3RpbmcgTWFyY2luIFBpbGFyc2tpIHRvIHNoYXJlIGRlLWR1 cCBleHB0IHNldHVwIGFuZCByZXN1bHRzLCAuLlJlOiBEcmFmdCBJRVRGLTg1IG1pbnV0ZXMgcG9z dGVkDQoNCkhlbGxvIEZyYW5jb2lzLA0KDQpQTFMgc2VuZCB1cyBNYXJjaW4ncyBlbWFpbCBhZGRy ZXNzLCBpZiB5b3UgaGF2ZSBpdC4NCg0KTm90IHN1cmUgd2hldGhlciBNYXJjaW4gbW9uaXRvcnMg dGhlIGRpc2N1c3Npb24gaW4gdGhlIENETkkgV0cuDQoNCklmIGFueW9uZSBrbm93cyBNYXJjaW4n cyBlbWFpbCBhZGRyZXNzLCBwbHMgZm9yd2FyZCB0aGlzIGVtYWlsIEFTQVAuDQoNClRoYW5rcw0K DQpCZXN0Lg0KDQpCaHVtaXANCg0KDQoNCg0KT24gVHVlLCBOb3YgMTMsIDIwMTIgYXQgMjo1NyBB TSwgRnJhbmNvaXMgTGUgRmF1Y2hldXIgKGZsZWZhdWNoKSA8ZmxlZmF1Y2hAY2lzY28uY29tPG1h aWx0bzpmbGVmYXVjaEBjaXNjby5jb20+PiB3cm90ZToNCkhlbGxvIEJodW1pcCwNCkkgc3VnZ2Vz dCB5b3UgY29tbXVuaWNhdGUgZGlyZWN0bHkgd2l0aCBNYXJjaW4uDQpDaGVlcnMNCkZyYW5jb2lz DQoNCk9uIDEyIE5vdiAyMDEyLCBhdCAxOTo1MywgQi5LaGFzbmFiaXNoQGllZWUub3JnPG1haWx0 bzpCLktoYXNuYWJpc2hAaWVlZS5vcmc+IHdyb3RlOg0KDQpIaSBGcmFuY29pcyAsDQoNCkR1cmlu ZyB0aGUgcHJlc2VudGF0aW9uIG9mIHRoZSBmb2xsb3dpbmcgZHJhZnQgTWFyY2luIFBpbGFyc2tp IHN1Z2dlc3RlZCB0aGF0IGluIGhpcyBDRE5JIGV4cHQuDQp0aGUgcHJvYmxlbSBvZiBjb250ZW50 IGR1cGxpY2F0aW9uIGRvZXMgbm90IG1hdGNoIGF0IGFsbCB3aGF0IGhlIGlzIHNlZSBpbiBoaXMN CmVudmlyb25tZW50DQpDb250ZW50IERlLWR1cGxpY2F0aW9uIGZvciBDRE5pIE9wdGltaXphdGlv biwNCmRyYWZ0LWppbi1jZG5pLWNvbnRlbnQtZGVkdXBsaWNhdGlvbi1vcHRpbWl6YXRpb24tMDM6 IEJodW1pcCBLaGFzbmFiaXNoDQoNCkRvIHlvdSBoYXZlIGFjY2VzcyB0byBNYXJjaW4ncyBleHBl cmltZW50LiBzZXR1cCwgdHJhZmZpYy9uZXR3b3JrL2NvbnRlbnQgcHJvZmlsZSwNCmFuZCByZXN1 bHRzPyBJZiB5ZXMsIGNhbiB5b3Ugc2hhcmUgdGhvc2Ugd2l0aCB1cy4NCklmIG5vdCBjYW4geW91 IGFzayBNYXJjaW4gdG8gc2hhcmUgdGhlIHNldHVwIGluZm8gYW5kIHJlc3VsdHMgd2l0aCB1cyBB U0FQLg0KDQpNYW55ICB0aGFua3MgaW4gYWR2YW5jZS4NCg0KQmVzdC4NCg0KQmh1bWlwDQoNCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N Cj4+IERyYWZ0IG1pbnV0ZXMgZm9yIG91ciB0d28gQ0ROSSBzZXNzaW9ucyBvZiBJRVRGLTg1IGhh dmUgYmVlbiBwb3N0ZWQuIFlvdSBjYW4gYWNjZXNzIHRoZW0gZnJvbSB0aGUgSUVURi04NSBNZWV0 aW5nIE1hdGVyaWFsIHBhZ2Ugb3IgZGlyZWN0bHkgZnJvbToNCj4+IGh0dHA6Ly93d3cuaWV0Zi5v cmcvcHJvY2VlZGluZ3MvODUvbWludXRlcy9taW51dGVzLTg1LWNkbmkuDQoNCi0gcHJvYmxlbSBv ZiBkZS1kdXBsaWNhdGlvbiBleHBsYWluZWQgd2l0aCAzIHNjZW5hcmlvcy4NCi0gc3VydmV5IHVw IHRvIDYwJSBkYXRhIHN0b3JlZCBpcyBkdXBsaWNhdGVkLg0KKk1hcmNpbiBQaWxhcnNraTogd2hh dCBhcmUgdGhlIGFzc3VtcHRpb25zIGJlaGluZCB0aGVzZSBudW1iZXJzIGJlY2F1c2UgdGhhdCBk b2VzIG5vdCBtYXRjaCBhdCBhbGwgd2hhdCBJIHNlZSBpbiBteSBlbnZpcm9ubWVudA0KKkJodW1p cDogd2lsbCBiZSBleHBsYWluZWQgaW4gdGhpcyBkcmFmdCBvciBpbiBzZXBhcmF0ZSBkcmFmdA0K Ojo6Ojo6DQotIE9wdGlvbiAyIC0gZGVjaWRlIGl0IGlzIGEgbmljZS10by1oYXZlLCBidXQgaXMg bm90IGNydWNpYWwgZm9yIGluaXRpYWwgdmVyc2lvbnMgb2YgQ0ROSSBpbnRlcmZhY2VzLiBXZSBj b250aW51ZSB0aGUgd29yayBvbiBpdCBpbnNpZGUgdGhlIFdHLCAgYnV0IGRvIG5vdCBhaW0gdG8g c3VwcG9ydCBpdCBpbiBmaXJzdCB2ZXJzaW9uIG9mIHRoZSBDRE5JIGludGVyZmFjZXMuDQo6Ojo6 Ojo6Og0KLSBPcHRpb24gMjogfjIwIHBlb3BsZQ0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCk9uIE1vbiwgTm92IDEyLCAyMDEy IGF0IDQ6MTYgQU0sIEZyYW5jb2lzIExlIEZhdWNoZXVyIChmbGVmYXVjaCkgPGZsZWZhdWNoQGNp c2NvLmNvbTxtYWlsdG86ZmxlZmF1Y2hAY2lzY28uY29tPj4gd3JvdGU6DQpIaSBldmVyeW9uZSwN Cg0KVGhlIGRyYWZ0IG1pbnV0ZXMgaGF2ZSBiZWVuIHVwZGF0ZWQgd2l0aDoNCiAgICAgICAgKiB0 aGUgY29ycmVjdGlvbiBkaXNjdXNzZWQgYmVsb3cgYnkgUmF5DQogICAgICAgICogYSBjb3JyZWN0 aW9uIG9uIHRoZSBTaG93LW9mLWhhbmQgcmVzdWx0cyBmb3IgdGhlIGxvbmctdGFpbCBJLUQgKHRo YXQgd2VyZSBzd2FwcGVkIGluIGVhcmxpZXIgdmVyc2lvbikgLSB0aGFua3MgdG8gRGF2ZSBNZWx0 b24gZm9yIHBvaW50aW5nIHRoYXQgb3V0Lg0KDQpBbnkgbW9yZSBjb21tZW50cy9jb3JyZWN0aW9u cz8NCg0KRnJhbmNvaXMNCg0KDQpPbiA5IE5vdiAyMDEyLCBhdCAxNjoxMywgQnJhbmRlbmJ1cmcs IFIuIChSYXkpIHZhbiB3cm90ZToNCg0KPiBIaSBGcmFuY29pcywNCj4NCj4gT25lIGNvbW1lbnQ6 IHRoZSBtaW51dGVzIG5vdGUgdGhhdCB0aGUgbGFzdCBwcmVzZW50YXRpb24gb24gVGh1cnNkYXkg d2FzIG1lIHByZXNlbnRpbmcgdGhlIEhBUyBleHBlcmltZW50cyBkcmFmdCwgd2hpbGUgaXQgd2Fz IGFjdHVhbGx5IEJodW1pcCBwcmVzZW50aW5nIHRoZSBJbnRyYS1DRE4gcHJvdmlkZXJzIGRyYWZ0 ICh3ZSBkaXZlcmdlZCBmcm9tIHRoZSBhZ2VuZGEpLg0KPg0KPiBSYXkNCj4NCj4gT24gOSBub3Yu IDIwMTIsIGF0IDEwOjA0LCAiRnJhbmNvaXMgTGUgRmF1Y2hldXIgKGZsZWZhdWNoKSIgPGZsZWZh dWNoQGNpc2NvLmNvbTxtYWlsdG86ZmxlZmF1Y2hAY2lzY28uY29tPj4gd3JvdGU6DQo+DQo+PiBG b2xrcywNCj4+DQo+PiBEcmFmdCBtaW51dGVzIGZvciBvdXIgdHdvIENETkkgc2Vzc2lvbnMgb2Yg SUVURi04NSBoYXZlIGJlZW4gcG9zdGVkLiBZb3UgY2FuIGFjY2VzcyB0aGVtIGZyb20gdGhlIElF VEYtODUgTWVldGluZyBNYXRlcmlhbCBwYWdlIG9yIGRpcmVjdGx5IGZyb206DQo+PiBodHRwOi8v d3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzg1L21pbnV0ZXMvbWludXRlcy04NS1jZG5pLg0KPj4N Cj4+IFRoYW5rcyB0byBNYXJjaW4gZm9yIHByb3ZpZGluZyByYXcgbm90ZXMuDQo+Pg0KPj4gV2Ug Y291bGQgbm90IHF1aXRlIGNhcHR1cmUgYWxsIHN0YXRlbWVudHMgb2YgdGhlIGRpc2N1c3Npb24g aW4gc29tZSBvY2N1cnJlbmNlcywgYW5kIHRoZSBhdWRpbyByZWNvcmRpbmcgd29uJ3QgYmUgYXZh aWxhYmxlIGZvciBhIGxpdHRsZSB3aGlsZSwgYnV0IHRoZSBkcmFmdCBtaW51dGVzIGFpbSBhdCBj YXB0dXJpbmcgdGhlIGVzc2VudGlhbCBvZiB0aGUgZGlzY3Vzc2lvbi4NCj4+DQo+PiBDb3JyZWN0 aW9ucy9jb21tZW50cyB3ZWxjb21lLg0KPj4NCj4+IENoZWVycw0KPj4NCj4+IEZyYW5jb2lzDQo+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gQ0RO aSBtYWlsaW5nIGxpc3QNCj4+IENETmlAaWV0Zi5vcmc8bWFpbHRvOkNETmlAaWV0Zi5vcmc+DQo+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkNCj4gVGhpcyBlLW1h aWwgYW5kIGl0cyBjb250ZW50cyBhcmUgc3ViamVjdCB0byB0aGUgRElTQ0xBSU1FUiBhdCBodHRw Oi8vd3d3LnRuby5ubC9lbWFpbGRpc2NsYWltZXINCj4NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCkNETmkgbWFpbGluZyBsaXN0DQpDRE5pQGlldGYu b3JnPG1haWx0bzpDRE5pQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jZG5pDQoNCg0KDQoNCg0KDQoNCg0K --_000_A60E005FD8778E41AE40379D75874B2D1DA7D434OPE10MB02tpgkco_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGZvbnQgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRlYXIgQmh1bWlwLDxicj4NCjxicj4NCk15 IGNvbW1lbnQgYW5kIGNyaXRpY2lzbSB3YXMgcmVsYXRlZCB0byB0aGUgeW91cnMgc2V0dXAgdGhh dCBjb21wbGV0ZWx5IG5lZ2xlY3RlZCBEUk0gdGVjaG5vbG9neSBleGlzdGVuY2UgdGhhdCBpcyBj b21tb24gaXMgYWxtb3N0IGFsbCBPcmFuZ2UncyBzZXR1cHMuIE1vcmUgb3ZlciBkdWUgdG8gdGhp cyBmYWN0IHRoZSBjb250ZW50IGlzIGVuY3J5cHRlZCBhbmQgcGFja2FnZWQgZm9yIGVhY2ggQ1Ag d2l0aCB0aGVpciBpbmRpdmlkdWFsIGtleSBzbw0KIGRlLWR1cGxpY2F0aW9uIGlzIG5vdCBhbiBp c3N1ZSBhdCBhbGwgLSBiZWNhdXNlIGNhbm5vdCBiZSB3aGVuIGRpZmZlcmVudCBDUCBoYXMgZGlm ZmVyZW50IGVuY3J5cHRpb25zIGtleXMuPGJyPg0KPGJyPg0KU28gd2hhdCBJIHdvdWxkIGxpa2Ug dG8gc2VlIGlzIHBhcmFncmFwaCBhYm91dCBjby1leGlzdGVuY2Ugb2YgZXhpc3RpbmcgRFJNIHRl Y2hub2xvZ3kgYW5kIHlvdXJzIHByb3Bvc2FsIGJlZm9yZSB3ZSBkbyBnbyBhbnkgZnVydGhlci48 YnI+DQo8YnI+DQpJIGhvcGUgdGhpcyB3aWxsIGhlbHAsPGJyPg0KTWFyY2luPGJyPg0KPGJyPg0K LS0tU2VudCBmcm9tIG1vYmlsZSBkZXZpY2U8L2ZvbnQ+PGJyPg0KJm5ic3A7PGJyPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPGZvbnQgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxiPk9kPC9i PjogQi5LaGFzbmFiaXNoQGllZWUub3JnIFttYWlsdG86dnVtaXAxQGdtYWlsLmNvbV0NCjxicj4N CjxiPld5c8WCYW5vPC9iPjogVHVlc2RheSwgTm92ZW1iZXIgMTMsIDIwMTIgMDQ6MjAgUE08YnI+ DQo8Yj5EbzwvYj46IFBpbGFyc2tpIE1hcmNpbiAtIEtvcnBvIFRQIDxicj4NCjxiPkRXPC9iPjog ZmxlZmF1Y2hAY2lzY28uY29tICZsdDtmbGVmYXVjaEBjaXNjby5jb20mZ3Q7OyBjZG5pQGlldGYu b3JnICZsdDtjZG5pQGlldGYub3JnJmd0OzsgcmFta3JpMTIzQGdtYWlsLmNvbSAmbHQ7cmFta3Jp MTIzQGdtYWlsLmNvbSZndDs7IGxpLm1pYW5AenRlLmNvbS5jbiAmbHQ7bGkubWlhbkB6dGUuY29t LmNuJmd0Ow0KPGJyPg0KPGI+VGVtYXQ8L2I+OiBSZTogT2RwLjogUmU6IFtDRE5pXSBSZXF1ZXN0 aW5nIE1hcmNpbiBQaWxhcnNraSB0byBzaGFyZSBkZS1kdXAgZXhwdCBzZXR1cCBhbmQgcmVzdWx0 cywgLi5SZTogRHJhZnQgSUVURi04NSBtaW51dGVzIHBvc3RlZA0KPGJyPg0KPC9mb250PiZuYnNw Ozxicj4NCjwvZGl2Pg0KPGRpdj5IZWxsbyBNYXJjaW4sIDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rp dj4NCjxkaXY+RHVyaW5nIHRoZSBwcmVzZW50YXRpb24gb2YgdGhlIGZvbGxvd2luZyBkcmFmdCB5 b3Ugc3VnZ2VzdGVkIHRoYXQgaW4geW91ciBDRE5JDQo8L2Rpdj4NCjxkaXY+ZXhwZXJpbWVudCB0 aGUgcHJvYmxlbSBvZiBjb250ZW50IGR1cGxpY2F0aW9uIGRvZXMgbm90IG1hdGNoIGF0IGFsbCB3 aGF0IHlvdTwvZGl2Pg0KPGRpdj5zZWUgaW4geW91ciBlbnZpcm9ubWVudC48L2Rpdj4NCjxkaXY+ Jm5ic3A7PC9kaXY+DQo8ZGl2PiZndDsgQ29udGVudCBEZS1kdXBsaWNhdGlvbiBmb3IgQ0ROaSBP cHRpbWl6YXRpb24sIDxicj4NCiZndDsgZHJhZnQtamluLWNkbmktY29udGVudC1kZWR1cGxpY2F0 aW9uLW9wdGltaXphdGlvbi0wMzogQmh1bWlwIEtoYXNuYWJpc2g8YnI+DQombmJzcDs8YnI+DQpD YW4geW91IHNoYXJlIGRldGFpbHMgb2YgeW91ciZuYnNwO2V4cGVyaW1lbnQuIHNldHVwLCB0cmFm ZmljL25ldHdvcmsvY29udGVudCBwcm9maWxlLA0KPGJyPg0KYW5kIHJlc3VsdHM/Jm5ic3A7IDwv ZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+V2UgcGxhbiB0byB1cGRhdGUgb3VyIGRyYWZ0 cyBzb29uLCBhbmQgd291bGQgYXBwcmVjaWF0ZSBxdWljayBmZWVkYmFjay48L2Rpdj4NCjxkaXY+ Jm5ic3A7PC9kaXY+DQo8ZGl2Pk1hbnkmbmJzcDsgdGhhbmtzIGluIGFkdmFuY2UuPGJyPg0KJm5i c3A7PGJyPg0KQmVzdC48YnI+DQombmJzcDs8YnI+DQpCaHVtaXA8YnI+DQombmJzcDs8YnI+DQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PGJyPg0KJmd0OyZndDsgRHJhZnQgbWludXRlcyBmb3Igb3VyIHR3byBDRE5JIHNlc3Npb25zIG9m IElFVEYtODUgaGF2ZSBiZWVuIHBvc3RlZC4gWW91IGNhbiBhY2Nlc3MgdGhlbSBmcm9tIHRoZSBJ RVRGLTg1IE1lZXRpbmcgTWF0ZXJpYWwgcGFnZSBvciBkaXJlY3RseSBmcm9tOjxicj4NCiZndDsm Z3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODUvbWludXRlcy9t aW51dGVzLTg1LWNkbmkiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODUvbWludXRl cy9taW51dGVzLTg1LWNkbmk8L2E+LjwvZGl2Pg0KPHA+LSBwcm9ibGVtIG9mIGRlLWR1cGxpY2F0 aW9uIGV4cGxhaW5lZCB3aXRoIDMgc2NlbmFyaW9zLiA8YnI+DQotIHN1cnZleSB1cCB0byA2MCUg ZGF0YSBzdG9yZWQgaXMgZHVwbGljYXRlZC4gPGJyPg0KKk1hcmNpbiBQaWxhcnNraTogd2hhdCBh cmUgdGhlIGFzc3VtcHRpb25zIGJlaGluZCB0aGVzZSBudW1iZXJzIGJlY2F1c2UgdGhhdCBkb2Vz IG5vdCBtYXRjaCBhdCBhbGwgd2hhdCBJIHNlZSBpbiBteSBlbnZpcm9ubWVudA0KPGJyPg0KKkJo dW1pcDogd2lsbCBiZSBleHBsYWluZWQgaW4gdGhpcyBkcmFmdCBvciBpbiBzZXBhcmF0ZSBkcmFm dDxicj4NCjo6Ojo6Ojxicj4NCi0gT3B0aW9uIDIgLSBkZWNpZGUgaXQgaXMgYSBuaWNlLXRvLWhh dmUsIGJ1dCBpcyBub3QgY3J1Y2lhbCBmb3IgaW5pdGlhbCB2ZXJzaW9ucyBvZiBDRE5JIGludGVy ZmFjZXMuIFdlIGNvbnRpbnVlIHRoZSB3b3JrIG9uIGl0IGluc2lkZSB0aGUgV0csJm5ic3A7IGJ1 dCBkbyBub3QgYWltIHRvIHN1cHBvcnQgaXQgaW4gZmlyc3QgdmVyc2lvbiBvZiB0aGUgQ0ROSSBp bnRlcmZhY2VzLjwvcD4NCjxwPjo6Ojo6Ojo6PGJyPg0KLSBPcHRpb24gMjogfjIwIHBlb3BsZTxi cj4NCjxicj4NCjwvcD4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBUdWUsIE5vdiAxMywg MjAxMiBhdCAxMDowNiBBTSwgUGlsYXJza2kgTWFyY2luIC0gS29ycG8gVFANCjxzcGFuIGRpcj0i bHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOk1hcmNpbi5QaWxhcnNraUBvcmFuZ2UuY29tIiB0YXJn ZXQ9Il9ibGFuayI+TWFyY2luLlBpbGFyc2tpQG9yYW5nZS5jb208L2E+Jmd0Ozwvc3Bhbj4gd3Jv dGU6PGJyPg0KPGJsb2NrcXVvdGUgc3R5bGU9IkJPUkRFUi1MRUZUOiNjY2MgMXB4IHNvbGlkO01B UkdJTjowcHggMHB4IDBweCAwLjhleDtQQURESU5HLUxFRlQ6MWV4IiBjbGFzcz0iZ21haWxfcXVv dGUiPg0KPGRpdj48Zm9udCBzdHlsZT0iRk9OVC1GQU1JTFk6J0NhbGlicmknLCdzYW5zLXNlcmlm JztDT0xPUjojMWY0OTdkO0ZPTlQtU0laRToxMXB0Ij5EZWFyIEJodW1pcCw8YnI+DQo8YnI+DQpo ZXJlIGlzIG9uZSBvZiB0aGVtLDxicj4NCjxicj4NCkJlc3QgcmVnYXJkcyw8YnI+DQpNYXJjaW4g UGlsYXJza2k8YnI+DQo8YnI+DQotLS1TZW50IGZyb20gbW9iaWxlIGRldmljZTwvZm9udD48YnI+ DQombmJzcDs8YnI+DQo8ZGl2IHN0eWxlPSJCT1JERVItQk9UVE9NOm1lZGl1bSBub25lO0JPUkRF Ui1MRUZUOm1lZGl1bSBub25lO1BBRERJTkctQk9UVE9NOjBpbjtQQURESU5HLUxFRlQ6MGluO1BB RERJTkctUklHSFQ6MGluO0JPUkRFUi1UT1A6I2I1YzRkZiAxcHQgc29saWQ7Qk9SREVSLVJJR0hU Om1lZGl1bSBub25lO1BBRERJTkctVE9QOjNwdCI+DQo8Zm9udCBzdHlsZT0iRk9OVC1GQU1JTFk6 J1RhaG9tYScsJ3NhbnMtc2VyaWYnO0ZPTlQtU0laRToxMHB0Ij48Yj5PZDwvYj46IDxhIGhyZWY9 Im1haWx0bzpCLktoYXNuYWJpc2hAaWVlZS5vcmciIHRhcmdldD0iX2JsYW5rIj4NCkIuS2hhc25h YmlzaEBpZWVlLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86dnVtaXAxQGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnZ1bWlwMUBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+V3lzxYJh bm88L2I+OiBUdWVzZGF5LCBOb3ZlbWJlciAxMywgMjAxMiAwNDowMSBQTTxicj4NCjxiPkRvPC9i PjogRnJhbmNvaXMgTGUgRmF1Y2hldXIgKGZsZWZhdWNoKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZs ZWZhdWNoQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZsZWZhdWNoQGNpc2NvLmNvbTwvYT4m Z3Q7DQo8YnI+DQo8Yj5EVzwvYj46IDxhIGhyZWY9Im1haWx0bzpjZG5pQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+Y2RuaUBpZXRmLm9yZzwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzpjZG5pQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y2RuaUBpZXRmLm9yZzwvYT4mZ3Q7OyBSYW0gS3Jpc2hu YW4gJmx0OzxhIGhyZWY9Im1haWx0bzpyYW1rcmkxMjNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+cmFta3JpMTIzQGdtYWlsLmNvbTwvYT4mZ3Q7DQo8YnI+DQo8Yj5UZW1hdDwvYj46IFJlOiBb Q0ROaV0gUmVxdWVzdGluZyBNYXJjaW4gUGlsYXJza2kgdG8gc2hhcmUgZGUtZHVwIGV4cHQgc2V0 dXAgYW5kIHJlc3VsdHMsIC4uUmU6IERyYWZ0IElFVEYtODUgbWludXRlcyBwb3N0ZWQNCjxicj4N CjwvZm9udD4mbmJzcDs8YnI+DQo8L2Rpdj4NCjxkaXY+PGZvbnQgc2l6ZT0iNCIgZmFjZT0iZ2Vv cmdpYSxzZXJpZiI+SGVsbG8gRnJhbmNvaXMsIDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgc2l6 ZT0iNCIgZmFjZT0iZ2VvcmdpYSxzZXJpZiI+PC9mb250PiZuYnNwOzwvZGl2Pg0KPGRpdj48Zm9u dCBzaXplPSI0IiBmYWNlPSJnZW9yZ2lhLHNlcmlmIj5QTFMgc2VuZCB1cyBNYXJjaW4ncyBlbWFp bCBhZGRyZXNzLCBpZiB5b3UgaGF2ZSBpdC48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IHNpemU9 IjQiIGZhY2U9Imdlb3JnaWEsc2VyaWYiPjwvZm9udD4mbmJzcDs8L2Rpdj4NCjxkaXY+PGZvbnQg c2l6ZT0iNCIgZmFjZT0iZ2VvcmdpYSxzZXJpZiI+Tm90IHN1cmUgd2hldGhlciBNYXJjaW4gbW9u aXRvcnMgdGhlIGRpc2N1c3Npb24gaW4gdGhlIENETkkgV0cuPC9mb250PjwvZGl2Pg0KPGRpdj48 Zm9udCBzaXplPSI0IiBmYWNlPSJnZW9yZ2lhLHNlcmlmIj48L2ZvbnQ+Jm5ic3A7PC9kaXY+DQo8 ZGl2Pjxmb250IHNpemU9IjQiIGZhY2U9Imdlb3JnaWEsc2VyaWYiPklmIGFueW9uZSBrbm93cyBN YXJjaW4ncyBlbWFpbCBhZGRyZXNzLCBwbHMgZm9yd2FyZCB0aGlzIGVtYWlsIEFTQVAuDQo8L2Zv bnQ+PC9kaXY+DQo8ZGl2Pjxmb250IHNpemU9IjQiIGZhY2U9Imdlb3JnaWEsc2VyaWYiPjwvZm9u dD4mbmJzcDs8L2Rpdj4NCjxkaXY+PGZvbnQgc2l6ZT0iNCIgZmFjZT0iZ2VvcmdpYSxzZXJpZiI+ VGhhbmtzIDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgc2l6ZT0iNCIgZmFjZT0iZ2VvcmdpYSxz ZXJpZiI+PC9mb250PiZuYnNwOzwvZGl2Pg0KPGRpdj48Zm9udCBzaXplPSI0IiBmYWNlPSJnZW9y Z2lhLHNlcmlmIj5CZXN0LjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgc2l6ZT0iNCIgZmFjZT0i Z2VvcmdpYSxzZXJpZiI+PC9mb250PiZuYnNwOzwvZGl2Pg0KPGRpdj48Zm9udCBzaXplPSI0IiBm YWNlPSJnZW9yZ2lhLHNlcmlmIj5CaHVtaXA8L2ZvbnQ+PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2 Pg0KPGRpdj48YnI+DQo8YnI+DQombmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3Rl Ij5PbiBUdWUsIE5vdiAxMywgMjAxMiBhdCAyOjU3IEFNLCBGcmFuY29pcyBMZSBGYXVjaGV1ciAo ZmxlZmF1Y2gpDQo8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpmbGVmYXVjaEBj aXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5mbGVmYXVjaEBjaXNjby5jb208L2E+Jmd0Ozwvc3Bh bj4gd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgc3R5bGU9IkJPUkRFUi1MRUZUOiNjY2MgMXB4IHNv bGlkO01BUkdJTjowcHggMHB4IDBweCAwLjhleDtQQURESU5HLUxFRlQ6MWV4IiBjbGFzcz0iZ21h aWxfcXVvdGUiPg0KPGRpdiBzdHlsZT0iV09SRC1XUkFQOmJyZWFrLXdvcmQiPkhlbGxvIEJodW1p cCwNCjxkaXY+SSBzdWdnZXN0IHlvdSBjb21tdW5pY2F0ZSBkaXJlY3RseSB3aXRoIE1hcmNpbi48 L2Rpdj4NCjxkaXY+Q2hlZXJzPC9kaXY+DQo8c3Bhbj48Zm9udCBjb2xvcj0iIzg4ODg4OCI+DQo8 ZGl2PkZyYW5jb2lzPC9kaXY+DQo8L2ZvbnQ+PC9zcGFuPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pjxi cj4NCjxkaXY+DQo8ZGl2Pk9uIDEyIE5vdiAyMDEyLCBhdCAxOTo1MywgPGEgaHJlZj0ibWFpbHRv OkIuS2hhc25hYmlzaEBpZWVlLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KQi5LaGFzbmFiaXNoQGll ZWUub3JnPC9hPiB3cm90ZTo8L2Rpdj4NCjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0K PGRpdj5IaSBGcmFuY29pcyAsPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5EdXJpbmcg dGhlIHByZXNlbnRhdGlvbiBvZiB0aGUgZm9sbG93aW5nIGRyYWZ0IE1hcmNpbiBQaWxhcnNraSBz dWdnZXN0ZWQgdGhhdCBpbiBoaXMgQ0ROSSBleHB0Lg0KPC9kaXY+DQo8ZGl2PnRoZSBwcm9ibGVt IG9mIGNvbnRlbnQgZHVwbGljYXRpb24gZG9lcyBub3QgbWF0Y2ggYXQgYWxsIHdoYXQgaGUgaXMg c2VlIGluIGhpczwvZGl2Pg0KPGRpdj5lbnZpcm9ubWVudCA8YnI+DQo8L2Rpdj4NCjxkaXY+Q29u dGVudCBEZS1kdXBsaWNhdGlvbiBmb3IgQ0ROaSBPcHRpbWl6YXRpb24sIDwvZGl2Pg0KPGRpdj5k cmFmdC1qaW4tY2RuaS1jb250ZW50LWRlZHVwbGljYXRpb24tb3B0aW1pemF0aW9uLTAzOiBCaHVt aXAgS2hhc25hYmlzaDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+RG8geW91IGhhdmUg YWNjZXNzIHRvIE1hcmNpbidzIGV4cGVyaW1lbnQuIHNldHVwLCB0cmFmZmljL25ldHdvcmsvY29u dGVudCZuYnNwO3Byb2ZpbGUsDQo8L2Rpdj4NCjxkaXY+YW5kIHJlc3VsdHM/IElmIHllcywgY2Fu IHlvdSBzaGFyZSB0aG9zZSB3aXRoIHVzLjwvZGl2Pg0KPGRpdj5JZiBub3QgY2FuIHlvdSBhc2sg TWFyY2luIHRvIHNoYXJlIHRoZSBzZXR1cCBpbmZvIGFuZCByZXN1bHRzIHdpdGggdXMgQVNBUC48 L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pk1hbnkmbmJzcDsgdGhhbmtzIGluIGFkdmFu Y2UuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5CZXN0LjwvZGl2Pg0KPGRpdj4mbmJz cDs8L2Rpdj4NCjxkaXY+Qmh1bWlwPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj49PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9k aXY+DQo8ZGl2PiZndDsmZ3Q7IERyYWZ0IG1pbnV0ZXMgZm9yIG91ciB0d28gQ0ROSSBzZXNzaW9u cyBvZiBJRVRGLTg1IGhhdmUgYmVlbiBwb3N0ZWQuIFlvdSBjYW4gYWNjZXNzIHRoZW0gZnJvbSB0 aGUgSUVURi04NSBNZWV0aW5nIE1hdGVyaWFsIHBhZ2Ugb3IgZGlyZWN0bHkgZnJvbTo8YnI+DQom Z3Q7Jmd0OyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzg1L21pbnV0 ZXMvbWludXRlcy04NS1jZG5pIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LmlldGYub3Jn L3Byb2NlZWRpbmdzLzg1L21pbnV0ZXMvbWludXRlcy04NS1jZG5pPC9hPi48YnI+DQo8YnI+DQot IHByb2JsZW0gb2YgZGUtZHVwbGljYXRpb24gZXhwbGFpbmVkIHdpdGggMyBzY2VuYXJpb3MuIDxi cj4NCi0gc3VydmV5IHVwIHRvIDYwJSBkYXRhIHN0b3JlZCBpcyBkdXBsaWNhdGVkLiA8YnI+DQoq TWFyY2luIFBpbGFyc2tpOiB3aGF0IGFyZSB0aGUgYXNzdW1wdGlvbnMgYmVoaW5kIHRoZXNlIG51 bWJlcnMgYmVjYXVzZSB0aGF0IGRvZXMgbm90IG1hdGNoIGF0IGFsbCB3aGF0IEkgc2VlIGluIG15 IGVudmlyb25tZW50DQo8YnI+DQoqQmh1bWlwOiB3aWxsIGJlIGV4cGxhaW5lZCBpbiB0aGlzIGRy YWZ0IG9yIGluIHNlcGFyYXRlIGRyYWZ0PGJyPg0KOjo6Ojo6PC9kaXY+DQo8ZGl2Pi0gT3B0aW9u IDIgLSBkZWNpZGUgaXQgaXMgYSBuaWNlLXRvLWhhdmUsIGJ1dCBpcyBub3QgY3J1Y2lhbCBmb3Ig aW5pdGlhbCB2ZXJzaW9ucyBvZiBDRE5JIGludGVyZmFjZXMuIFdlDQo8c3Ryb25nPjx1PmNvbnRp bnVlIHRoZSB3b3JrIG9uIGl0IGluc2lkZSB0aGUgV0c8L3U+PC9zdHJvbmc+LCZuYnNwOyBidXQg ZG8gbm90IGFpbSB0byBzdXBwb3J0IGl0IGluIGZpcnN0IHZlcnNpb24gb2YgdGhlIENETkkgaW50 ZXJmYWNlcy48YnI+DQo8L2Rpdj4NCjxkaXY+Ojo6Ojo6Ojo8L2Rpdj4NCjxkaXY+LSBPcHRpb24g MjogfjIwIHBlb3BsZTxicj4NCjxicj4NCjxkaXY+PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvZGl2Pg0KPC9kaXY+DQo8ZGl2PiZuYnNw OzwvZGl2Pg0KPGRpdj5PbiBNb24sIE5vdiAxMiwgMjAxMiBhdCA0OjE2IEFNLCBGcmFuY29pcyBM ZSBGYXVjaGV1ciAoZmxlZmF1Y2gpIDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBocmVmPSJtYWls dG86ZmxlZmF1Y2hAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZmxlZmF1Y2hAY2lzY28uY29t PC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfcXVv dGUiPg0KPGJsb2NrcXVvdGUgc3R5bGU9IkJPUkRFUi1MRUZUOiNjY2MgMXB4IHNvbGlkO01BUkdJ TjowcHggMHB4IDBweCAwLjhleDtQQURESU5HLUxFRlQ6MWV4IiBjbGFzcz0iZ21haWxfcXVvdGUi Pg0KSGkgZXZlcnlvbmUsPGJyPg0KPGJyPg0KVGhlIGRyYWZ0IG1pbnV0ZXMgaGF2ZSBiZWVuIHVw ZGF0ZWQgd2l0aDo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgKiB0aGUgY29ycmVj dGlvbiBkaXNjdXNzZWQgYmVsb3cgYnkgUmF5PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICogYSBjb3JyZWN0aW9uIG9uIHRoZSBTaG93LW9mLWhhbmQgcmVzdWx0cyBmb3IgdGhlIGxv bmctdGFpbCBJLUQgKHRoYXQgd2VyZSBzd2FwcGVkIGluIGVhcmxpZXIgdmVyc2lvbikgLSB0aGFu a3MgdG8gRGF2ZSBNZWx0b24gZm9yIHBvaW50aW5nIHRoYXQgb3V0Ljxicj4NCjxicj4NCkFueSBt b3JlIGNvbW1lbnRzL2NvcnJlY3Rpb25zPzxicj4NCjxzcGFuPjxmb250IGNvbG9yPSIjODg4ODg4 Ij48YnI+DQpGcmFuY29pczxicj4NCjwvZm9udD48L3NwYW4+DQo8ZGl2Pg0KPGRpdj48YnI+DQo8 YnI+DQpPbiA5IE5vdiAyMDEyLCBhdCAxNjoxMywgQnJhbmRlbmJ1cmcsIFIuIChSYXkpIHZhbiB3 cm90ZTo8YnI+DQo8YnI+DQomZ3Q7IEhpIEZyYW5jb2lzLDxicj4NCiZndDs8YnI+DQomZ3Q7IE9u ZSBjb21tZW50OiB0aGUgbWludXRlcyBub3RlIHRoYXQgdGhlIGxhc3QgcHJlc2VudGF0aW9uIG9u IFRodXJzZGF5IHdhcyBtZSBwcmVzZW50aW5nIHRoZSBIQVMgZXhwZXJpbWVudHMgZHJhZnQsIHdo aWxlIGl0IHdhcyBhY3R1YWxseSBCaHVtaXAgcHJlc2VudGluZyB0aGUgSW50cmEtQ0ROIHByb3Zp ZGVycyBkcmFmdCAod2UgZGl2ZXJnZWQgZnJvbSB0aGUgYWdlbmRhKS48YnI+DQomZ3Q7PGJyPg0K Jmd0OyBSYXk8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiA5IG5vdi4gMjAxMiwgYXQgMTA6MDQsICZx dW90O0ZyYW5jb2lzIExlIEZhdWNoZXVyIChmbGVmYXVjaCkmcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpmbGVmYXVjaEBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5mbGVmYXVjaEBjaXNjby5j b208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgRm9sa3MsPGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyBEcmFmdCBtaW51dGVzIGZvciBvdXIgdHdvIENETkkgc2Vzc2lv bnMgb2YgSUVURi04NSBoYXZlIGJlZW4gcG9zdGVkLiBZb3UgY2FuIGFjY2VzcyB0aGVtIGZyb20g dGhlIElFVEYtODUgTWVldGluZyBNYXRlcmlhbCBwYWdlIG9yIGRpcmVjdGx5IGZyb206PGJyPg0K Jmd0OyZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84NS9taW51 dGVzL21pbnV0ZXMtODUtY2RuaSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5pZXRmLm9y Zy9wcm9jZWVkaW5ncy84NS9taW51dGVzL21pbnV0ZXMtODUtY2RuaTwvYT4uPGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyBUaGFua3MgdG8gTWFyY2luIGZvciBwcm92aWRpbmcgcmF3IG5vdGVz Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgV2UgY291bGQgbm90IHF1aXRlIGNhcHR1cmUg YWxsIHN0YXRlbWVudHMgb2YgdGhlIGRpc2N1c3Npb24gaW4gc29tZSBvY2N1cnJlbmNlcywgYW5k IHRoZSBhdWRpbyByZWNvcmRpbmcgd29uJ3QgYmUgYXZhaWxhYmxlIGZvciBhIGxpdHRsZSB3aGls ZSwgYnV0IHRoZSBkcmFmdCBtaW51dGVzIGFpbSBhdCBjYXB0dXJpbmcgdGhlIGVzc2VudGlhbCBv ZiB0aGUgZGlzY3Vzc2lvbi48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IENvcnJlY3Rpb25z L2NvbW1lbnRzIHdlbGNvbWUuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBDaGVlcnM8YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEZyYW5jb2lzPGJyPg0KJmd0OyZndDsgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBDRE5p IG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpDRE5pQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+Q0ROaUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyA8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nkbmk8L2E+PGJyPg0K Jmd0OyBUaGlzIGUtbWFpbCBhbmQgaXRzIGNvbnRlbnRzIGFyZSBzdWJqZWN0IHRvIHRoZSBESVND TEFJTUVSIGF0IDxhIGhyZWY9Imh0dHA6Ly93d3cudG5vLm5sL2VtYWlsZGlzY2xhaW1lciIgdGFy Z2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy50bm8ubmwvZW1haWxkaXNjbGFpbWVyPC9hPjxicj4N CiZndDs8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCkNETmkgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkNETmlA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5DRE5pQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaSIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaTwvYT48YnI+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8YnIgY2xlYXI9ImFs bCI+DQombmJzcDsgPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPGJyIGNsZWFyPSJh bGwiPg0KPGJyPg0KJm5ic3A7PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_A60E005FD8778E41AE40379D75874B2D1DA7D434OPE10MB02tpgkco_-- From Marcin.Pilarski@orange.com Tue Nov 13 07:06:30 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F61021F86AA for ; Tue, 13 Nov 2012 07:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.487 X-Spam-Level: X-Spam-Status: No, score=0.487 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MH3cRQoEE9hG for ; Tue, 13 Nov 2012 07:06:29 -0800 (PST) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE0621F86A2 for ; Tue, 13 Nov 2012 07:06:26 -0800 (PST) Received: from 10.236.62.152 (EHLO OPE10HT02.tp.gk.corp.tepenet) ([10.236.62.152]) by mailin.tpsa.pl (MOS 3.10.10a-GA FastPath queued) with ESMTP id CYA29208; Tue, 13 Nov 2012 16:06:20 +0100 (CET) From: Pilarski Marcin - Korpo TP To: "'vumip1@gmail.com'" , "'flefauch@cisco.com'" Thread-Topic: Odp.: Re: [CDNi] Requesting Marcin Pilarski to share de-dup expt setup and results, ..Re: Draft IETF-85 minutes posted Thread-Index: AQHNwbBsfm8XrybbpEGFj8vo7IqhGA== Date: Tue, 13 Nov 2012 15:06:15 +0000 Message-ID: In-Reply-To: Accept-Language: pl-PL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_A60E005FD8778E41AE40379D75874B2D1DA7D3E0OPE10MB02tpgkco_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 13 Nov 2012 08:07:23 -0800 Cc: "'cdni@ietf.org'" , "'ramkri123@gmail.com'" Subject: [CDNi] Odp.: Re: Requesting Marcin Pilarski to share de-dup expt setup and results, ..Re: Draft IETF-85 minutes posted X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 15:06:30 -0000 --_000_A60E005FD8778E41AE40379D75874B2D1DA7D3E0OPE10MB02tpgkco_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBCaHVtaXAsDQoNCmhlcmUgaXMgb25lIG9mIHRoZW0sDQoNCkJlc3QgcmVnYXJkcywNCk1h cmNpbiBQaWxhcnNraQ0KDQotLS1TZW50IGZyb20gbW9iaWxlIGRldmljZQ0KDQpPZDogQi5LaGFz bmFiaXNoQGllZWUub3JnIFttYWlsdG86dnVtaXAxQGdtYWlsLmNvbV0NCld5c8WCYW5vOiBUdWVz ZGF5LCBOb3ZlbWJlciAxMywgMjAxMiAwNDowMSBQTQ0KRG86IEZyYW5jb2lzIExlIEZhdWNoZXVy IChmbGVmYXVjaCkgPGZsZWZhdWNoQGNpc2NvLmNvbT4NCkRXOiBjZG5pQGlldGYub3JnIDxjZG5p QGlldGYub3JnPjsgUmFtIEtyaXNobmFuIDxyYW1rcmkxMjNAZ21haWwuY29tPg0KVGVtYXQ6IFJl OiBbQ0ROaV0gUmVxdWVzdGluZyBNYXJjaW4gUGlsYXJza2kgdG8gc2hhcmUgZGUtZHVwIGV4cHQg c2V0dXAgYW5kIHJlc3VsdHMsIC4uUmU6IERyYWZ0IElFVEYtODUgbWludXRlcyBwb3N0ZWQNCg0K SGVsbG8gRnJhbmNvaXMsDQoNClBMUyBzZW5kIHVzIE1hcmNpbidzIGVtYWlsIGFkZHJlc3MsIGlm IHlvdSBoYXZlIGl0Lg0KDQpOb3Qgc3VyZSB3aGV0aGVyIE1hcmNpbiBtb25pdG9ycyB0aGUgZGlz Y3Vzc2lvbiBpbiB0aGUgQ0ROSSBXRy4NCg0KSWYgYW55b25lIGtub3dzIE1hcmNpbidzIGVtYWls IGFkZHJlc3MsIHBscyBmb3J3YXJkIHRoaXMgZW1haWwgQVNBUC4NCg0KVGhhbmtzDQoNCkJlc3Qu DQoNCkJodW1pcA0KDQoNCg0KDQpPbiBUdWUsIE5vdiAxMywgMjAxMiBhdCAyOjU3IEFNLCBGcmFu Y29pcyBMZSBGYXVjaGV1ciAoZmxlZmF1Y2gpIDxmbGVmYXVjaEBjaXNjby5jb208bWFpbHRvOmZs ZWZhdWNoQGNpc2NvLmNvbT4+IHdyb3RlOg0KSGVsbG8gQmh1bWlwLA0KSSBzdWdnZXN0IHlvdSBj b21tdW5pY2F0ZSBkaXJlY3RseSB3aXRoIE1hcmNpbi4NCkNoZWVycw0KRnJhbmNvaXMNCg0KT24g MTIgTm92IDIwMTIsIGF0IDE5OjUzLCBCLktoYXNuYWJpc2hAaWVlZS5vcmc8bWFpbHRvOkIuS2hh c25hYmlzaEBpZWVlLm9yZz4gd3JvdGU6DQoNCkhpIEZyYW5jb2lzICwNCg0KRHVyaW5nIHRoZSBw cmVzZW50YXRpb24gb2YgdGhlIGZvbGxvd2luZyBkcmFmdCBNYXJjaW4gUGlsYXJza2kgc3VnZ2Vz dGVkIHRoYXQgaW4gaGlzIENETkkgZXhwdC4NCnRoZSBwcm9ibGVtIG9mIGNvbnRlbnQgZHVwbGlj YXRpb24gZG9lcyBub3QgbWF0Y2ggYXQgYWxsIHdoYXQgaGUgaXMgc2VlIGluIGhpcw0KZW52aXJv bm1lbnQNCkNvbnRlbnQgRGUtZHVwbGljYXRpb24gZm9yIENETmkgT3B0aW1pemF0aW9uLA0KZHJh ZnQtamluLWNkbmktY29udGVudC1kZWR1cGxpY2F0aW9uLW9wdGltaXphdGlvbi0wMzogQmh1bWlw IEtoYXNuYWJpc2gNCg0KRG8geW91IGhhdmUgYWNjZXNzIHRvIE1hcmNpbidzIGV4cGVyaW1lbnQu IHNldHVwLCB0cmFmZmljL25ldHdvcmsvY29udGVudCBwcm9maWxlLA0KYW5kIHJlc3VsdHM/IElm IHllcywgY2FuIHlvdSBzaGFyZSB0aG9zZSB3aXRoIHVzLg0KSWYgbm90IGNhbiB5b3UgYXNrIE1h cmNpbiB0byBzaGFyZSB0aGUgc2V0dXAgaW5mbyBhbmQgcmVzdWx0cyB3aXRoIHVzIEFTQVAuDQoN Ck1hbnkgIHRoYW5rcyBpbiBhZHZhbmNlLg0KDQpCZXN0Lg0KDQpCaHVtaXANCg0KPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPj4gRHJh ZnQgbWludXRlcyBmb3Igb3VyIHR3byBDRE5JIHNlc3Npb25zIG9mIElFVEYtODUgaGF2ZSBiZWVu IHBvc3RlZC4gWW91IGNhbiBhY2Nlc3MgdGhlbSBmcm9tIHRoZSBJRVRGLTg1IE1lZXRpbmcgTWF0 ZXJpYWwgcGFnZSBvciBkaXJlY3RseSBmcm9tOg0KPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9j ZWVkaW5ncy84NS9taW51dGVzL21pbnV0ZXMtODUtY2RuaS4NCg0KLSBwcm9ibGVtIG9mIGRlLWR1 cGxpY2F0aW9uIGV4cGxhaW5lZCB3aXRoIDMgc2NlbmFyaW9zLg0KLSBzdXJ2ZXkgdXAgdG8gNjAl IGRhdGEgc3RvcmVkIGlzIGR1cGxpY2F0ZWQuDQoqTWFyY2luIFBpbGFyc2tpOiB3aGF0IGFyZSB0 aGUgYXNzdW1wdGlvbnMgYmVoaW5kIHRoZXNlIG51bWJlcnMgYmVjYXVzZSB0aGF0IGRvZXMgbm90 IG1hdGNoIGF0IGFsbCB3aGF0IEkgc2VlIGluIG15IGVudmlyb25tZW50DQoqQmh1bWlwOiB3aWxs IGJlIGV4cGxhaW5lZCBpbiB0aGlzIGRyYWZ0IG9yIGluIHNlcGFyYXRlIGRyYWZ0DQo6Ojo6OjoN Ci0gT3B0aW9uIDIgLSBkZWNpZGUgaXQgaXMgYSBuaWNlLXRvLWhhdmUsIGJ1dCBpcyBub3QgY3J1 Y2lhbCBmb3IgaW5pdGlhbCB2ZXJzaW9ucyBvZiBDRE5JIGludGVyZmFjZXMuIFdlIGNvbnRpbnVl IHRoZSB3b3JrIG9uIGl0IGluc2lkZSB0aGUgV0csICBidXQgZG8gbm90IGFpbSB0byBzdXBwb3J0 IGl0IGluIGZpcnN0IHZlcnNpb24gb2YgdGhlIENETkkgaW50ZXJmYWNlcy4NCjo6Ojo6Ojo6DQot IE9wdGlvbiAyOiB+MjAgcGVvcGxlDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KT24gTW9uLCBOb3YgMTIsIDIwMTIgYXQgNDox NiBBTSwgRnJhbmNvaXMgTGUgRmF1Y2hldXIgKGZsZWZhdWNoKSA8ZmxlZmF1Y2hAY2lzY28uY29t PG1haWx0bzpmbGVmYXVjaEBjaXNjby5jb20+PiB3cm90ZToNCkhpIGV2ZXJ5b25lLA0KDQpUaGUg ZHJhZnQgbWludXRlcyBoYXZlIGJlZW4gdXBkYXRlZCB3aXRoOg0KICAgICAgICAqIHRoZSBjb3Jy ZWN0aW9uIGRpc2N1c3NlZCBiZWxvdyBieSBSYXkNCiAgICAgICAgKiBhIGNvcnJlY3Rpb24gb24g dGhlIFNob3ctb2YtaGFuZCByZXN1bHRzIGZvciB0aGUgbG9uZy10YWlsIEktRCAodGhhdCB3ZXJl IHN3YXBwZWQgaW4gZWFybGllciB2ZXJzaW9uKSAtIHRoYW5rcyB0byBEYXZlIE1lbHRvbiBmb3Ig cG9pbnRpbmcgdGhhdCBvdXQuDQoNCkFueSBtb3JlIGNvbW1lbnRzL2NvcnJlY3Rpb25zPw0KDQpG cmFuY29pcw0KDQoNCk9uIDkgTm92IDIwMTIsIGF0IDE2OjEzLCBCcmFuZGVuYnVyZywgUi4gKFJh eSkgdmFuIHdyb3RlOg0KDQo+IEhpIEZyYW5jb2lzLA0KPg0KPiBPbmUgY29tbWVudDogdGhlIG1p bnV0ZXMgbm90ZSB0aGF0IHRoZSBsYXN0IHByZXNlbnRhdGlvbiBvbiBUaHVyc2RheSB3YXMgbWUg cHJlc2VudGluZyB0aGUgSEFTIGV4cGVyaW1lbnRzIGRyYWZ0LCB3aGlsZSBpdCB3YXMgYWN0dWFs bHkgQmh1bWlwIHByZXNlbnRpbmcgdGhlIEludHJhLUNETiBwcm92aWRlcnMgZHJhZnQgKHdlIGRp dmVyZ2VkIGZyb20gdGhlIGFnZW5kYSkuDQo+DQo+IFJheQ0KPg0KPiBPbiA5IG5vdi4gMjAxMiwg YXQgMTA6MDQsICJGcmFuY29pcyBMZSBGYXVjaGV1ciAoZmxlZmF1Y2gpIiA8ZmxlZmF1Y2hAY2lz Y28uY29tPG1haWx0bzpmbGVmYXVjaEBjaXNjby5jb20+PiB3cm90ZToNCj4NCj4+IEZvbGtzLA0K Pj4NCj4+IERyYWZ0IG1pbnV0ZXMgZm9yIG91ciB0d28gQ0ROSSBzZXNzaW9ucyBvZiBJRVRGLTg1 IGhhdmUgYmVlbiBwb3N0ZWQuIFlvdSBjYW4gYWNjZXNzIHRoZW0gZnJvbSB0aGUgSUVURi04NSBN ZWV0aW5nIE1hdGVyaWFsIHBhZ2Ugb3IgZGlyZWN0bHkgZnJvbToNCj4+IGh0dHA6Ly93d3cuaWV0 Zi5vcmcvcHJvY2VlZGluZ3MvODUvbWludXRlcy9taW51dGVzLTg1LWNkbmkuDQo+Pg0KPj4gVGhh bmtzIHRvIE1hcmNpbiBmb3IgcHJvdmlkaW5nIHJhdyBub3Rlcy4NCj4+DQo+PiBXZSBjb3VsZCBu b3QgcXVpdGUgY2FwdHVyZSBhbGwgc3RhdGVtZW50cyBvZiB0aGUgZGlzY3Vzc2lvbiBpbiBzb21l IG9jY3VycmVuY2VzLCBhbmQgdGhlIGF1ZGlvIHJlY29yZGluZyB3b24ndCBiZSBhdmFpbGFibGUg Zm9yIGEgbGl0dGxlIHdoaWxlLCBidXQgdGhlIGRyYWZ0IG1pbnV0ZXMgYWltIGF0IGNhcHR1cmlu ZyB0aGUgZXNzZW50aWFsIG9mIHRoZSBkaXNjdXNzaW9uLg0KPj4NCj4+IENvcnJlY3Rpb25zL2Nv bW1lbnRzIHdlbGNvbWUuDQo+Pg0KPj4gQ2hlZXJzDQo+Pg0KPj4gRnJhbmNvaXMNCj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBDRE5pIG1haWxp bmcgbGlzdA0KPj4gQ0ROaUBpZXRmLm9yZzxtYWlsdG86Q0ROaUBpZXRmLm9yZz4NCj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaQ0KPiBUaGlzIGUtbWFpbCBhbmQg aXRzIGNvbnRlbnRzIGFyZSBzdWJqZWN0IHRvIHRoZSBESVNDTEFJTUVSIGF0IGh0dHA6Ly93d3cu dG5vLm5sL2VtYWlsZGlzY2xhaW1lcg0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KQ0ROaSBtYWlsaW5nIGxpc3QNCkNETmlAaWV0Zi5vcmc8bWFp bHRvOkNETmlAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2NkbmkNCg0KDQoNCg0KDQoNCg0KLS0NCkJlc3QuDQoNCkJodW1pcCBLaGFzbmFiaXNoDQp2dW1p cDFAZ21haWwuY29tPG1haWx0bzp2dW1pcDFAZ21haWwuY29tPg0KYi5raGFzbmFiaXNoQGllZWUu b3JnPG1haWx0bzpiLmtoYXNuYWJpc2hAaWVlZS5vcmc+DQpiaHVtaXAua2hhc25hYmlzaEB6dGV1 c2EuY29tPG1haWx0bzpiaHVtaXAua2hhc25hYmlzaEB6dGV1c2EuY29tPg0KKzEtNzgxLTc1Mi04 MDAzIChtb2JpbGUpDQpodHRwOi8vdGlueXVybC5jb20vYmh1bWlwDQoNCiAgICAgICAgICAgICAg ICAgICBfX28NCiAgICAgICAgICAgICBfIGBcIDwsIF8NCi4uLi4uLi4uLi4gKCDigKIgKSAvICgg 4oCiICkgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLg0KDQo= --_000_A60E005FD8778E41AE40379D75874B2D1DA7D3E0OPE10MB02tpgkco_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGZvbnQgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRlYXIgQmh1bWlwLDxicj4NCjxicj4NCmhl cmUgaXMgb25lIG9mIHRoZW0sPGJyPg0KPGJyPg0KQmVzdCByZWdhcmRzLDxicj4NCk1hcmNpbiBQ aWxhcnNraTxicj4NCjxicj4NCi0tLVNlbnQgZnJvbSBtb2JpbGUgZGV2aWNlPC9mb250Pjxicj4N CiZuYnNwOzxicj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxmb250IHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48Yj5PZDwvYj46IEIuS2hhc25hYmlzaEBpZWVlLm9yZyBbbWFpbHRvOnZ1bWlw MUBnbWFpbC5jb21dDQo8YnI+DQo8Yj5XeXPFgmFubzwvYj46IFR1ZXNkYXksIE5vdmVtYmVyIDEz LCAyMDEyIDA0OjAxIFBNPGJyPg0KPGI+RG88L2I+OiBGcmFuY29pcyBMZSBGYXVjaGV1ciAoZmxl ZmF1Y2gpICZsdDtmbGVmYXVjaEBjaXNjby5jb20mZ3Q7IDxicj4NCjxiPkRXPC9iPjogY2RuaUBp ZXRmLm9yZyAmbHQ7Y2RuaUBpZXRmLm9yZyZndDs7IFJhbSBLcmlzaG5hbiAmbHQ7cmFta3JpMTIz QGdtYWlsLmNvbSZndDsgPGJyPg0KPGI+VGVtYXQ8L2I+OiBSZTogW0NETmldIFJlcXVlc3Rpbmcg TWFyY2luIFBpbGFyc2tpIHRvIHNoYXJlIGRlLWR1cCBleHB0IHNldHVwIGFuZCByZXN1bHRzLCAu LlJlOiBEcmFmdCBJRVRGLTg1IG1pbnV0ZXMgcG9zdGVkDQo8YnI+DQo8L2ZvbnQ+Jm5ic3A7PGJy Pg0KPC9kaXY+DQo8ZGl2Pjxmb250IHNpemU9IjQiIGZhY2U9Imdlb3JnaWEsc2VyaWYiPkhlbGxv IEZyYW5jb2lzLCA8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IHNpemU9IjQiIGZhY2U9Imdlb3Jn aWEsc2VyaWYiPjwvZm9udD4mbmJzcDs8L2Rpdj4NCjxkaXY+PGZvbnQgc2l6ZT0iNCIgZmFjZT0i Z2VvcmdpYSxzZXJpZiI+UExTIHNlbmQgdXMgTWFyY2luJ3MgZW1haWwgYWRkcmVzcywgaWYgeW91 IGhhdmUgaXQuPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBzaXplPSI0IiBmYWNlPSJnZW9yZ2lh LHNlcmlmIj48L2ZvbnQ+Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxmb250IHNpemU9IjQiIGZhY2U9Imdl b3JnaWEsc2VyaWYiPk5vdCBzdXJlIHdoZXRoZXIgTWFyY2luIG1vbml0b3JzIHRoZSBkaXNjdXNz aW9uIGluIHRoZSBDRE5JIFdHLjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgc2l6ZT0iNCIgZmFj ZT0iZ2VvcmdpYSxzZXJpZiI+PC9mb250PiZuYnNwOzwvZGl2Pg0KPGRpdj48Zm9udCBzaXplPSI0 IiBmYWNlPSJnZW9yZ2lhLHNlcmlmIj5JZiBhbnlvbmUga25vd3MgTWFyY2luJ3MgZW1haWwgYWRk cmVzcywgcGxzIGZvcndhcmQgdGhpcyBlbWFpbCBBU0FQLg0KPC9mb250PjwvZGl2Pg0KPGRpdj48 Zm9udCBzaXplPSI0IiBmYWNlPSJnZW9yZ2lhLHNlcmlmIj48L2ZvbnQ+Jm5ic3A7PC9kaXY+DQo8 ZGl2Pjxmb250IHNpemU9IjQiIGZhY2U9Imdlb3JnaWEsc2VyaWYiPlRoYW5rcyA8L2ZvbnQ+PC9k aXY+DQo8ZGl2Pjxmb250IHNpemU9IjQiIGZhY2U9Imdlb3JnaWEsc2VyaWYiPjwvZm9udD4mbmJz cDs8L2Rpdj4NCjxkaXY+PGZvbnQgc2l6ZT0iNCIgZmFjZT0iZ2VvcmdpYSxzZXJpZiI+QmVzdC48 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IHNpemU9IjQiIGZhY2U9Imdlb3JnaWEsc2VyaWYiPjwv Zm9udD4mbmJzcDs8L2Rpdj4NCjxkaXY+PGZvbnQgc2l6ZT0iNCIgZmFjZT0iZ2VvcmdpYSxzZXJp ZiI+Qmh1bWlwPC9mb250PjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPGJy Pg0KJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gVHVlLCBOb3YgMTMs IDIwMTIgYXQgMjo1NyBBTSwgRnJhbmNvaXMgTGUgRmF1Y2hldXIgKGZsZWZhdWNoKQ0KPHNwYW4g ZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86ZmxlZmF1Y2hAY2lzY28uY29tIiB0YXJnZXQ9 Il9ibGFuayI+ZmxlZmF1Y2hAY2lzY28uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJCT1JERVItTEVGVDojY2NjIDFweCBzb2xpZDtNQVJHSU46MHB4IDBw eCAwcHggMC44ZXg7UEFERElORy1MRUZUOjFleCIgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYg c3R5bGU9IldPUkQtV1JBUDpicmVhay13b3JkIj5IZWxsbyBCaHVtaXAsDQo8ZGl2Pkkgc3VnZ2Vz dCB5b3UgY29tbXVuaWNhdGUgZGlyZWN0bHkgd2l0aCBNYXJjaW4uPC9kaXY+DQo8ZGl2PkNoZWVy czwvZGl2Pg0KPHNwYW4gY2xhc3M9IkhPRW5aYiI+PGZvbnQgY29sb3I9IiM4ODg4ODgiPg0KPGRp dj5GcmFuY29pczwvZGl2Pg0KPC9mb250Pjwvc3Bhbj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJoNSI+ DQo8ZGl2Pjxicj4NCjxkaXY+DQo8ZGl2Pk9uIDEyIE5vdiAyMDEyLCBhdCAxOTo1MywgPGEgaHJl Zj0ibWFpbHRvOkIuS2hhc25hYmlzaEBpZWVlLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KQi5LaGFz bmFiaXNoQGllZWUub3JnPC9hPiB3cm90ZTo8L2Rpdj4NCjxicj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPg0KPGRpdj5IaSBGcmFuY29pcyAsPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRp dj5EdXJpbmcgdGhlIHByZXNlbnRhdGlvbiBvZiB0aGUgZm9sbG93aW5nIGRyYWZ0IE1hcmNpbiBQ aWxhcnNraSBzdWdnZXN0ZWQgdGhhdCBpbiBoaXMgQ0ROSSBleHB0Lg0KPC9kaXY+DQo8ZGl2PnRo ZSBwcm9ibGVtIG9mIGNvbnRlbnQgZHVwbGljYXRpb24gZG9lcyBub3QgbWF0Y2ggYXQgYWxsIHdo YXQgaGUgaXMgc2VlIGluIGhpczwvZGl2Pg0KPGRpdj5lbnZpcm9ubWVudCA8YnI+DQo8L2Rpdj4N CjxkaXY+Q29udGVudCBEZS1kdXBsaWNhdGlvbiBmb3IgQ0ROaSBPcHRpbWl6YXRpb24sIDwvZGl2 Pg0KPGRpdj5kcmFmdC1qaW4tY2RuaS1jb250ZW50LWRlZHVwbGljYXRpb24tb3B0aW1pemF0aW9u LTAzOiBCaHVtaXAgS2hhc25hYmlzaDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+RG8g eW91IGhhdmUgYWNjZXNzIHRvIE1hcmNpbidzIGV4cGVyaW1lbnQuIHNldHVwLCB0cmFmZmljL25l dHdvcmsvY29udGVudCZuYnNwO3Byb2ZpbGUsDQo8L2Rpdj4NCjxkaXY+YW5kIHJlc3VsdHM/IElm IHllcywgY2FuIHlvdSBzaGFyZSB0aG9zZSB3aXRoIHVzLjwvZGl2Pg0KPGRpdj5JZiBub3QgY2Fu IHlvdSBhc2sgTWFyY2luIHRvIHNoYXJlIHRoZSBzZXR1cCBpbmZvIGFuZCByZXN1bHRzIHdpdGgg dXMgQVNBUC48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pk1hbnkmbmJzcDsgdGhhbmtz IGluIGFkdmFuY2UuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5CZXN0LjwvZGl2Pg0K PGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Qmh1bWlwPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0K PGRpdj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IERyYWZ0IG1pbnV0ZXMgZm9yIG91ciB0d28gQ0RO SSBzZXNzaW9ucyBvZiBJRVRGLTg1IGhhdmUgYmVlbiBwb3N0ZWQuIFlvdSBjYW4gYWNjZXNzIHRo ZW0gZnJvbSB0aGUgSUVURi04NSBNZWV0aW5nIE1hdGVyaWFsIHBhZ2Ugb3IgZGlyZWN0bHkgZnJv bTo8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdz Lzg1L21pbnV0ZXMvbWludXRlcy04NS1jZG5pIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3 LmlldGYub3JnL3Byb2NlZWRpbmdzLzg1L21pbnV0ZXMvbWludXRlcy04NS1jZG5pPC9hPi48YnI+ DQo8YnI+DQotIHByb2JsZW0gb2YgZGUtZHVwbGljYXRpb24gZXhwbGFpbmVkIHdpdGggMyBzY2Vu YXJpb3MuIDxicj4NCi0gc3VydmV5IHVwIHRvIDYwJSBkYXRhIHN0b3JlZCBpcyBkdXBsaWNhdGVk LiA8YnI+DQoqTWFyY2luIFBpbGFyc2tpOiB3aGF0IGFyZSB0aGUgYXNzdW1wdGlvbnMgYmVoaW5k IHRoZXNlIG51bWJlcnMgYmVjYXVzZSB0aGF0IGRvZXMgbm90IG1hdGNoIGF0IGFsbCB3aGF0IEkg c2VlIGluIG15IGVudmlyb25tZW50DQo8YnI+DQoqQmh1bWlwOiB3aWxsIGJlIGV4cGxhaW5lZCBp biB0aGlzIGRyYWZ0IG9yIGluIHNlcGFyYXRlIGRyYWZ0PGJyPg0KOjo6Ojo6PC9kaXY+DQo8ZGl2 Pi0gT3B0aW9uIDIgLSBkZWNpZGUgaXQgaXMgYSBuaWNlLXRvLWhhdmUsIGJ1dCBpcyBub3QgY3J1 Y2lhbCBmb3IgaW5pdGlhbCB2ZXJzaW9ucyBvZiBDRE5JIGludGVyZmFjZXMuIFdlDQo8c3Ryb25n Pjx1PmNvbnRpbnVlIHRoZSB3b3JrIG9uIGl0IGluc2lkZSB0aGUgV0c8L3U+PC9zdHJvbmc+LCZu YnNwOyBidXQgZG8gbm90IGFpbSB0byBzdXBwb3J0IGl0IGluIGZpcnN0IHZlcnNpb24gb2YgdGhl IENETkkgaW50ZXJmYWNlcy48YnI+DQo8L2Rpdj4NCjxkaXY+Ojo6Ojo6Ojo8L2Rpdj4NCjxkaXY+ LSBPcHRpb24gMjogfjIwIHBlb3BsZTxicj4NCjxicj4NCjxkaXY+PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvZGl2Pg0KPC9kaXY+DQo8 ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5PbiBNb24sIE5vdiAxMiwgMjAxMiBhdCA0OjE2IEFNLCBG cmFuY29pcyBMZSBGYXVjaGV1ciAoZmxlZmF1Y2gpIDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBo cmVmPSJtYWlsdG86ZmxlZmF1Y2hAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZmxlZmF1Y2hA Y2lzY28uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Z21haWxfcXVvdGUiPg0KPGJsb2NrcXVvdGUgc3R5bGU9IkJPUkRFUi1MRUZUOiNjY2MgMXB4IHNv bGlkO01BUkdJTjowcHggMHB4IDBweCAwLjhleDtQQURESU5HLUxFRlQ6MWV4IiBjbGFzcz0iZ21h aWxfcXVvdGUiPg0KSGkgZXZlcnlvbmUsPGJyPg0KPGJyPg0KVGhlIGRyYWZ0IG1pbnV0ZXMgaGF2 ZSBiZWVuIHVwZGF0ZWQgd2l0aDo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgKiB0 aGUgY29ycmVjdGlvbiBkaXNjdXNzZWQgYmVsb3cgYnkgUmF5PGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICogYSBjb3JyZWN0aW9uIG9uIHRoZSBTaG93LW9mLWhhbmQgcmVzdWx0cyBm b3IgdGhlIGxvbmctdGFpbCBJLUQgKHRoYXQgd2VyZSBzd2FwcGVkIGluIGVhcmxpZXIgdmVyc2lv bikgLSB0aGFua3MgdG8gRGF2ZSBNZWx0b24gZm9yIHBvaW50aW5nIHRoYXQgb3V0Ljxicj4NCjxi cj4NCkFueSBtb3JlIGNvbW1lbnRzL2NvcnJlY3Rpb25zPzxicj4NCjxzcGFuPjxmb250IGNvbG9y PSIjODg4ODg4Ij48YnI+DQpGcmFuY29pczxicj4NCjwvZm9udD48L3NwYW4+DQo8ZGl2Pg0KPGRp dj48YnI+DQo8YnI+DQpPbiA5IE5vdiAyMDEyLCBhdCAxNjoxMywgQnJhbmRlbmJ1cmcsIFIuIChS YXkpIHZhbiB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7IEhpIEZyYW5jb2lzLDxicj4NCiZndDs8YnI+ DQomZ3Q7IE9uZSBjb21tZW50OiB0aGUgbWludXRlcyBub3RlIHRoYXQgdGhlIGxhc3QgcHJlc2Vu dGF0aW9uIG9uIFRodXJzZGF5IHdhcyBtZSBwcmVzZW50aW5nIHRoZSBIQVMgZXhwZXJpbWVudHMg ZHJhZnQsIHdoaWxlIGl0IHdhcyBhY3R1YWxseSBCaHVtaXAgcHJlc2VudGluZyB0aGUgSW50cmEt Q0ROIHByb3ZpZGVycyBkcmFmdCAod2UgZGl2ZXJnZWQgZnJvbSB0aGUgYWdlbmRhKS48YnI+DQom Z3Q7PGJyPg0KJmd0OyBSYXk8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiA5IG5vdi4gMjAxMiwgYXQg MTA6MDQsICZxdW90O0ZyYW5jb2lzIExlIEZhdWNoZXVyIChmbGVmYXVjaCkmcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpmbGVmYXVjaEBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5mbGVmYXVj aEBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgRm9sa3Ms PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBEcmFmdCBtaW51dGVzIGZvciBvdXIgdHdvIENE Tkkgc2Vzc2lvbnMgb2YgSUVURi04NSBoYXZlIGJlZW4gcG9zdGVkLiBZb3UgY2FuIGFjY2VzcyB0 aGVtIGZyb20gdGhlIElFVEYtODUgTWVldGluZyBNYXRlcmlhbCBwYWdlIG9yIGRpcmVjdGx5IGZy b206PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5n cy84NS9taW51dGVzL21pbnV0ZXMtODUtY2RuaSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3 dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84NS9taW51dGVzL21pbnV0ZXMtODUtY2RuaTwvYT4uPGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGFua3MgdG8gTWFyY2luIGZvciBwcm92aWRpbmcg cmF3IG5vdGVzLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgV2UgY291bGQgbm90IHF1aXRl IGNhcHR1cmUgYWxsIHN0YXRlbWVudHMgb2YgdGhlIGRpc2N1c3Npb24gaW4gc29tZSBvY2N1cnJl bmNlcywgYW5kIHRoZSBhdWRpbyByZWNvcmRpbmcgd29uJ3QgYmUgYXZhaWxhYmxlIGZvciBhIGxp dHRsZSB3aGlsZSwgYnV0IHRoZSBkcmFmdCBtaW51dGVzIGFpbSBhdCBjYXB0dXJpbmcgdGhlIGVz c2VudGlhbCBvZiB0aGUgZGlzY3Vzc2lvbi48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IENv cnJlY3Rpb25zL2NvbW1lbnRzIHdlbGNvbWUuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBD aGVlcnM8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEZyYW5jb2lzPGJyPg0KJmd0OyZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7 Jmd0OyBDRE5pIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpDRE5p QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Q0ROaUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0 OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nkbmk8 L2E+PGJyPg0KJmd0OyBUaGlzIGUtbWFpbCBhbmQgaXRzIGNvbnRlbnRzIGFyZSBzdWJqZWN0IHRv IHRoZSBESVNDTEFJTUVSIGF0IDxhIGhyZWY9Imh0dHA6Ly93d3cudG5vLm5sL2VtYWlsZGlzY2xh aW1lciIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy50bm8ubmwvZW1haWxkaXNjbGFpbWVy PC9hPjxicj4NCiZndDs8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCkNETmkgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOkNETmlAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5DRE5pQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaSIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaTwv YT48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8YnIg Y2xlYXI9ImFsbCI+DQombmJzcDsgPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPGJy IGNsZWFyPSJhbGwiPg0KPGJyPg0KLS0gPGJyPg0KPGRpdj5CZXN0Ljxicj4NCjxicj4NCkJodW1p cCBLaGFzbmFiaXNoPC9kaXY+DQo8ZGl2PjxhIGhyZWY9Im1haWx0bzp2dW1pcDFAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+dnVtaXAxQGdtYWlsLmNvbTwvYT4gPC9kaXY+DQo8ZGl2PjxhIGhy ZWY9Im1haWx0bzpiLmtoYXNuYWJpc2hAaWVlZS5vcmciIHRhcmdldD0iX2JsYW5rIj5iLmtoYXNu YWJpc2hAaWVlZS5vcmc8L2E+PC9kaXY+DQo8ZGl2PjxhIGhyZWY9Im1haWx0bzpiaHVtaXAua2hh c25hYmlzaEB6dGV1c2EuY29tIiB0YXJnZXQ9Il9ibGFuayI+Ymh1bWlwLmtoYXNuYWJpc2hAenRl dXNhLmNvbTwvYT4gJm5ic3A7PC9kaXY+DQo8ZGl2PiYjNDM7MS03ODEtNzUyLTgwMDMgKG1vYmls ZSkgPGJyPg0KPGEgaHJlZj0iaHR0cDovL3Rpbnl1cmwuY29tL2JodW1pcCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHA6Ly90aW55dXJsLmNvbS9iaHVtaXA8L2E+PC9kaXY+DQo8ZGl2Pjxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBfX288YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IF8gYFwgJmx0OywgXzxicj4NCi4uLi4uLi4uLi4gKCDigKIgKSAvICgg4oCiICkg Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjxicj4NCjwvZGl2Pg0KPGJyPg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_A60E005FD8778E41AE40379D75874B2D1DA7D3E0OPE10MB02tpgkco_-- From vumip1@gmail.com Fri Nov 16 12:06:18 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B7821F84F2 for ; Fri, 16 Nov 2012 12:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHjVdX6BEbcl for ; Fri, 16 Nov 2012 12:06:16 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id D1B3121F8495 for ; Fri, 16 Nov 2012 12:06:15 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2625238lbk.31 for ; Fri, 16 Nov 2012 12:06:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P9wVGvfPODd5LsOT3utbPSXVp/jMPRyGPD/7V5StxBU=; b=ezLAshpQ1a5iz7/4K7/W5qoGoUTzqMnvd/H+pWA/7A0zp/PlwVQmdmpV4TDgVcf65K FFwU8Rl6JQGynfZ19JfVY7Yk+11AV0eoVekL9aZccM4fr+LFt/Veo3z2CBd7vsQHXK1g QF5nJQURayQzm3Vk4HTyWd2T9KHYFBIAIc+rz9GPIpCDO3MqQ3BWrmwF/5JD1eFMJmHr YSGYR2tgijQLUTqCvWAJbkJYRJ2iOlqhISwDipBkDPlqm2fx39qi+zgzVGapOzxl+NNr DF89tZD/5+7127QGZQhSV0joLq7Ms+9Ivr5GHVT/wmFDbpRnKYotalYu0F2S+rra3dJh Is8w== MIME-Version: 1.0 Received: by 10.152.106.110 with SMTP id gt14mr5262905lab.1.1353096374613; Fri, 16 Nov 2012 12:06:14 -0800 (PST) Received: by 10.114.5.161 with HTTP; Fri, 16 Nov 2012 12:06:14 -0800 (PST) In-Reply-To: References: Date: Fri, 16 Nov 2012 15:06:14 -0500 Message-ID: From: "B.Khasnabish@ieee.org" To: Pilarski Marcin - Korpo TP Content-Type: multipart/alternative; boundary=f46d04071167c1763d04cea24c0a Cc: "cdni@ietf.org" , "ramkri123@gmail.com" Subject: Re: [CDNi] Odp.: Re: Odp.: Re: Requesting Marcin Pilarski to share de-dup expt setup and results, ..Re: Draft IETF-85 minutes posted X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 20:06:18 -0000 --f46d04071167c1763d04cea24c0a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Marcin, Thanks for responding. Are you saying that if you use DRM there is no duplication of contents even in the same provider environment. You mention that you see very small (may be less than 5%) duplications.. is that when you operate using DRM? How many CDN operators are interconnected in your setup? Is it possible to share the details of content distribution and operations setup in which your observation "*does not match at all"* what we cite in the slides? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://www.ietf.org/proceedings/85/minutes/minutes-85-cdni - see slides - problem of de-duplication explained with 3 scenarios. - survey up to 60% data stored is duplicated. *Marcin Pilarski: what are the assumptions behind these numbers because that *does not match at all what I see in my environment * . =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D By the way, there are also a few independent reports and studies which confirms the existence of duplicate content even in same operators environment, and that it is a non-trivial problem which need attention. Let us continue the discussing so that we can improve the draft before IETF86. Thanks again. Best. Bhumip On Tue, Nov 13, 2012 at 10:24 AM, Pilarski Marcin - Korpo TP < Marcin.Pilarski@orange.com> wrote: > Dear Bhumip, > > My comment and criticism was related to the yours setup that completely > neglected DRM technology existence that is common is almost all Orange's > setups. More over due to this fact the content is encrypted and packaged > for each CP with their individual key so de-duplication is not an issue a= t > all - because cannot be when different CP has different encryptions keys. > > So what I would like to see is paragraph about co-existence of existing > DRM technology and yours proposal before we do go any further. > > I hope this will help, > Marcin > > ---Sent from mobile device > > *Od*: B.Khasnabish@ieee.org [mailto:vumip1@gmail.com] > *Wys=C5=82ano*: Tuesday, November 13, 2012 04:20 PM > *Do*: Pilarski Marcin - Korpo TP > *DW*: flefauch@cisco.com ; cdni@ietf.org < > cdni@ietf.org>; ramkri123@gmail.com ; > li.mian@zte.com.cn > *Temat*: Re: Odp.: Re: [CDNi] Requesting Marcin Pilarski to share de-dup > expt setup and results, ..Re: Draft IETF-85 minutes posted > > Hello Marcin, > > During the presentation of the following draft you suggested that in your > CDNI > experiment the problem of content duplication does not match at all what > you > see in your environment. > > > Content De-duplication for CDNi Optimization, > > draft-jin-cdni-content-deduplication-optimization-03: Bhumip Khasnabish > > Can you share details of your experiment. setup, traffic/network/content > profile, > and results? > > We plan to update our drafts soon, and would appreciate quick feedback. > > Many thanks in advance. > > Best. > > Bhumip > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > >> Draft minutes for our two CDNI sessions of IETF-85 have been posted. > You can access them from the IETF-85 Meeting Material page or directly fr= om: > >> http://www.ietf.org/proceedings/85/minutes/minutes-85-cdni. > > - problem of de-duplication explained with 3 scenarios. > - survey up to 60% data stored is duplicated. > *Marcin Pilarski: what are the assumptions behind these numbers because > that does not match at all what I see in my environment > *Bhumip: will be explained in this draft or in separate draft > :::::: > - Option 2 - decide it is a nice-to-have, but is not crucial for initial > versions of CDNI interfaces. We continue the work on it inside the WG, b= ut > do not aim to support it in first version of the CDNI interfaces. > > :::::::: > - Option 2: ~20 people > > On Tue, Nov 13, 2012 at 10:06 AM, Pilarski Marcin - Korpo TP < > Marcin.Pilarski@orange.com> wrote: > >> Dear Bhumip, >> >> here is one of them, >> >> Best regards, >> Marcin Pilarski >> >> ---Sent from mobile device >> >> *Od*: B.Khasnabish@ieee.org [mailto:vumip1@gmail.com] >> *Wys=C5=82ano*: Tuesday, November 13, 2012 04:01 PM >> *Do*: Francois Le Faucheur (flefauch) >> *DW*: cdni@ietf.org ; Ram Krishnan >> *Temat*: Re: [CDNi] Requesting Marcin Pilarski to share de-dup expt >> setup and results, ..Re: Draft IETF-85 minutes posted >> >> Hello Francois, >> >> PLS send us Marcin's email address, if you have it. >> >> Not sure whether Marcin monitors the discussion in the CDNI WG. >> >> If anyone knows Marcin's email address, pls forward this email ASAP. >> >> Thanks >> >> Best. >> >> Bhumip >> >> >> >> >> On Tue, Nov 13, 2012 at 2:57 AM, Francois Le Faucheur (flefauch) < >> flefauch@cisco.com> wrote: >> >>> Hello Bhumip, >>> I suggest you communicate directly with Marcin. >>> Cheers >>> Francois >>> >>> On 12 Nov 2012, at 19:53, B.Khasnabish@ieee.org wrote: >>> >>> Hi Francois , >>> >>> During the presentation of the following draft Marcin Pilarski suggeste= d >>> that in his CDNI expt. >>> the problem of content duplication does not match at all what he is see >>> in his >>> environment >>> Content De-duplication for CDNi Optimization, >>> draft-jin-cdni-content-deduplication-optimization-03: Bhumip Khasnabish >>> >>> Do you have access to Marcin's experiment. setup, >>> traffic/network/content profile, >>> and results? If yes, can you share those with us. >>> If not can you ask Marcin to share the setup info and results with us >>> ASAP. >>> >>> Many thanks in advance. >>> >>> Best. >>> >>> Bhumip >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >> Draft minutes for our two CDNI sessions of IETF-85 have been posted. >>> You can access them from the IETF-85 Meeting Material page or directly = from: >>> >> http://www.ietf.org/proceedings/85/minutes/minutes-85-cdni. >>> >>> - problem of de-duplication explained with 3 scenarios. >>> - survey up to 60% data stored is duplicated. >>> *Marcin Pilarski: what are the assumptions behind these numbers because >>> that does not match at all what I see in my environment >>> *Bhumip: will be explained in this draft or in separate draft >>> :::::: >>> - Option 2 - decide it is a nice-to-have, but is not crucial for initia= l >>> versions of CDNI interfaces. We *continue the work on it inside the WG*= , >>> but do not aim to support it in first version of the CDNI interfaces. >>> :::::::: >>> - Option 2: ~20 people >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> On Mon, Nov 12, 2012 at 4:16 AM, Francois Le Faucheur (flefauch) < >>> flefauch@cisco.com> wrote: >>> >>>> Hi everyone, >>>> >>>> The draft minutes have been updated with: >>>> * the correction discussed below by Ray >>>> * a correction on the Show-of-hand results for the long-tail >>>> I-D (that were swapped in earlier version) - thanks to Dave Melton for >>>> pointing that out. >>>> >>>> Any more comments/corrections? >>>> >>>> Francois >>>> >>>> >>>> On 9 Nov 2012, at 16:13, Brandenburg, R. (Ray) van wrote: >>>> >>>> > Hi Francois, >>>> > >>>> > One comment: the minutes note that the last presentation on Thursday >>>> was me presenting the HAS experiments draft, while it was actually Bhu= mip >>>> presenting the Intra-CDN providers draft (we diverged from the agenda)= . >>>> > >>>> > Ray >>>> > >>>> > On 9 nov. 2012, at 10:04, "Francois Le Faucheur (flefauch)" < >>>> flefauch@cisco.com> wrote: >>>> > >>>> >> Folks, >>>> >> >>>> >> Draft minutes for our two CDNI sessions of IETF-85 have been posted= . >>>> You can access them from the IETF-85 Meeting Material page or directly= from: >>>> >> http://www.ietf.org/proceedings/85/minutes/minutes-85-cdni. >>>> >> >>>> >> Thanks to Marcin for providing raw notes. >>>> >> >>>> >> We could not quite capture all statements of the discussion in some >>>> occurrences, and the audio recording won't be available for a little w= hile, >>>> but the draft minutes aim at capturing the essential of the discussion= . >>>> >> >>>> >> Corrections/comments welcome. >>>> >> >>>> >> Cheers >>>> >> >>>> >> Francois >>>> >> _______________________________________________ >>>> >> CDNi mailing list >>>> >> CDNi@ietf.org >>>> >> https://www.ietf.org/mailman/listinfo/cdni >>>> > This e-mail and its contents are subject to the DISCLAIMER at >>>> http://www.tno.nl/emaildisclaimer >>>> > >>>> >>>> _______________________________________________ >>>> CDNi mailing list >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni >>>> >>> >>> >>> >>> >>> >>> >> >> >> >> > --f46d04071167c1763d04cea24c0a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Marcin,
=C2=A0
Thanks for responding.
=C2=A0
Are you saying that if you use DRM there is no duplication of contents= even in the
same provider environment.
You mention that you see very small (may be less than 5%) duplications= .. is
that when you operate using DRM?
How many CDN operators are interconnected in your setup?
Is it possible to share the details of content distribution and operat= ions setup
in which your observation
=C2=A0"does not match at all" what w= e cite=C2=A0=C2=A0in the slides?
=C2=A0
=C2=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
- see slides
- problem of de-duplication explained with 3 scenarios= .
- survey up to 60% data stored is duplicated.
*Marcin Pilarski: w= hat are the assumptions behind these numbers because
that does not match at all what I see in my environment =C2=A0.=C2=A0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

By the way, there are also a few independent reports and studies w= hich confirms the
existence of duplicate content even in same operators environment,
and that it =C2=A0is a non-trivial problem which need attention.
=C2=A0
Let us continue the discussing so that we can improve the draft before= IETF86.
=C2=A0
Thanks again.
=C2=A0
Best.
=C2=A0
Bhumip
=C2=A0
=C2=A0
On Tue, Nov 13, 2012 at 10:24 AM, Pilarski Marci= n - Korpo TP <Marcin.Pilarski@orange.com> wrote:
Dear Bhumip,

My comment and criticism was = related to the yours setup that completely neglected DRM technology existen= ce that is common is almost all Orange's setups. More over due to this = fact the content is encrypted and packaged for each CP with their individua= l key so de-duplication is not an issue at all - because cannot be when dif= ferent CP has different encryptions keys.

So what I would like to see is paragraph about co-existence of existing= DRM technology and yours proposal before we do go any further.

I ho= pe this will help,
Marcin

---Sent from mobile device
=C2=A0
Od: B.Khasnabish@ieee.org [mailto:<= a href=3D"mailto:vumip1@gmail.com" target=3D"_blank">vumip1@gmail.com] =
Wys=C5=82ano: Tuesday, November 13, 2012 04:20 PM
Do: Pila= rski Marcin - Korpo TP
DW: flefauch@cisco.com <flefauch@cisco.com>; cdni@ietf.org <cdni@ietf.org>; ramkri123@gmail.com <ramkri123@gmail.com>; li.mian@zte.com.cn <li.mian@zte.c= om.cn>
Temat: Re: Odp.: Re: [CDNi] Requesting Marcin Pilarski to share de-d= up expt setup and results, ..Re: Draft IETF-85 minutes posted
= =C2=A0
Hello Marcin,
=C2=A0
During the presentation of the following draft you suggested that in y= our CDNI
experiment the problem of content duplication does not match at all wh= at you
see in your environment.
=C2=A0
> Content De-duplication for CDNi Optimization,
> draft-jin-= cdni-content-deduplication-optimization-03: Bhumip Khasnabish
=C2=A0
= Can you share details of your=C2=A0experiment. setup, traffic/network/conte= nt profile,
and results?=C2=A0
=C2=A0
We plan to update our drafts soon, and would appreciate quick feedback= .
=C2=A0
Many=C2=A0 thanks in advance.
=C2=A0
Best.
=C2=A0
Bhumip=C2=A0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> Draft minutes for our two = CDNI sessions of IETF-85 have been posted. You can access them from the IET= F-85 Meeting Material page or directly from:
>> http://www.ietf.org/proceedings/85/minutes/minutes-8= 5-cdni.

- problem of de-duplication explained with 3 scenarios.
- survey up = to 60% data stored is duplicated.
*Marcin Pilarski: what are the assump= tions behind these numbers because that does not match at all what I see in= my environment
*Bhumip: will be explained in this draft or in separate draft
::::::
= - Option 2 - decide it is a nice-to-have, but is not crucial for initial ve= rsions of CDNI interfaces. We continue the work on it inside the WG,=C2=A0 = but do not aim to support it in first version of the CDNI interfaces.

::::::::
- Option 2: ~20 people

On Tue, Nov 13, 2012 at 10:06 AM, Pilarski Marci= n - Korpo TP <Marcin.Pilarski@orange.com> wrote:
Dear Bhumip,

here is one of them,

B= est regards,
Marcin Pilarski

---Sent from mobile device =C2=A0
Od: B.Khasnabish@ieee.org [mailto:<= a href=3D"mailto:vumip1@gmail.com" target=3D"_blank">vumip1@gmail.com] =
Wys=C5=82ano: Tuesday, November 13, 2012 04:01 PM
Do: Fran= cois Le Faucheur (flefauch) <flefauch@cisco.com>
DW: cdni@ietf.org <cdni@ietf.org>; Ram Krishnan <ramkri123@gmail.com&= gt;
Temat: Re: [CDNi] Requesting Marcin Pilarski to share de-dup expt se= tup and results, ..Re: Draft IETF-85 minutes posted
=C2=A0
Hello Francois,
=C2=A0
PLS send us Marcin's email= address, if you have it.
=C2=A0
Not sure whether Marcin monito= rs the discussion in the CDNI WG.
=C2=A0
If anyone knows Marcin's e= mail address, pls forward this email ASAP.
=C2=A0
Thanks
=C2=A0
Best.
=C2=A0
Bhumip
=C2=A0


=C2=A0
On Tue, Nov 13, 2012 at 2:57 AM, Francois Le Fau= cheur (flefauch) <flefauch@cisco.com> wrote:
Hello Bhumip,=20
I suggest you communicate directly with Marcin.
Cheers
Francois

On 12 Nov 2012, at 19:53, B.Khasnabish@ieee.org wrote:

Hi Francois ,
=C2=A0
During the presentation of the following draft Marcin Pilarski suggest= ed that in his CDNI expt.
the problem of content duplication does not match at all what he is se= e in his
environment
Content De-duplication for CDNi Optimization,
draft-jin-cdni-content-deduplication-optimization-03: Bhumip Khasnabis= h
=C2=A0
Do you have access to Marcin's experiment. setup, traffic/network/= content=C2=A0profile,
and results? If yes, can you share those with us.
If not can you ask Marcin to share the setup info and results with us = ASAP.
=C2=A0
Many=C2=A0 thanks in advance.
=C2=A0
Best.
=C2=A0
Bhumip
=C2=A0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> Draft minutes for our two CDNI sessions of IETF-85 have been = posted. You can access them from the IETF-85 Meeting Material page or direc= tly from:
>> http://www.ietf.org/proceedings/85/minu= tes/minutes-85-cdni.

- problem of de-duplication explained with 3 scenarios.
- survey up= to 60% data stored is duplicated.
*Marcin Pilarski: what are the assum= ptions behind these numbers because that does not match at all what I see i= n my environment
*Bhumip: will be explained in this draft or in separate draft
::::::
- Option 2 - decide it is a nice-to-have, but is not crucial for initi= al versions of CDNI interfaces. We continue the work on it insid= e the WG,=C2=A0 but do not aim to support it in first version = of the CDNI interfaces.
::::::::
- Option 2: ~20 people

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0
On Mon, Nov 12, 2012 at 4:16 AM, Francois Le Faucheur (flefauch) <fl= efauch@cisco.com> wrote:
Hi everyone,

The draft minutes= have been updated with:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * the correction di= scussed below by Ray
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * a correction on the Show-of-hand results for = the long-tail I-D (that were swapped in earlier version) - thanks to Dave M= elton for pointing that out.

Any more comments/corrections?

Francois


On 9 Nov 2012, at 16:13, Brandenburg, R. (Ray) van wrote:
<= br>> Hi Francois,
>
> One comment: the minutes note that the= last presentation on Thursday was me presenting the HAS experiments draft,= while it was actually Bhumip presenting the Intra-CDN providers draft (we = diverged from the agenda).
>
> Ray
>
> On 9 nov. 2012, at 10:04, "Francois L= e Faucheur (flefauch)" <flefauch@cisco.com> wrote:
>
>> Folks, >>
>> Draft minutes for our two CDNI sessions of IETF-85 hav= e been posted. You can access them from the IETF-85 Meeting Material page o= r directly from:
>> http://www.ietf.org/proceedings/= 85/minutes/minutes-85-cdni.
>>
>> Thanks to Marcin for providing raw notes.
>><= br>>> We could not quite capture all statements of the discussion in = some occurrences, and the audio recording won't be available for a litt= le while, but the draft minutes aim at capturing the essential of the discu= ssion.
>>
>> Corrections/comments welcome.
>>
>> = Cheers
>>
>> Francois
>> _______________________= ________________________
>> CDNi mailing list
>> CDNi@ietf.org
>> https://www.ietf.org/mailman/listinfo/cdni
> This e-mail a= nd its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer=
>

_______________________________________________
CDNi mailing= list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni


=C2=A0



=C2=A0



=C2=A0=20 --f46d04071167c1763d04cea24c0a-- From wwwrun@rfc-editor.org Mon Nov 19 17:16:48 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F0421F8432; Mon, 19 Nov 2012 17:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.236 X-Spam-Level: X-Spam-Status: No, score=-102.236 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7gnAZefXrAH; Mon, 19 Nov 2012 17:16:48 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 2F34721F8425; Mon, 19 Nov 2012 17:16:48 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 82D5AB1E002; Mon, 19 Nov 2012 17:09:29 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20121120010929.82D5AB1E002@rfc-editor.org> Date: Mon, 19 Nov 2012 17:09:29 -0800 (PST) Cc: cdni@ietf.org, rfc-editor@rfc-editor.org Subject: [CDNi] RFC 6770 on Use Cases for Content Delivery Network Interconnection X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 01:16:48 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6770 Title: Use Cases for Content Delivery Network Interconnection Author: G. Bertrand, Ed., E. Stephan, T. Burbridge, P. Eardley, K. Ma, G. Watson Status: Informational Stream: IETF Date: November 2012 Mailbox: gilles.bertrand@orange.com, emile.stephan@orange.com, trevor.burbridge@bt.com, philip.eardley@bt.com, kevin.ma@azukisystems.com, gwatson@velocix.com Pages: 16 Characters: 33281 Obsoletes: RFC3570 I-D Tag: draft-ietf-cdni-use-cases-10.txt URL: http://www.rfc-editor.org/rfc/rfc6770.txt Content Delivery Networks (CDNs) are commonly used for improving the End User experience of a content delivery service while keeping cost at a reasonable level. This document focuses on use cases that correspond to identified industry needs and that are expected to be realized once open interfaces and protocols supporting the interconnection of CDNs are specified and implemented. This document can be used to motivate the definition of the requirements to be supported by CDN Interconnection (CDNI) interfaces. It obsoletes RFC 3570. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Content Delivery Networks Interconnection Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From flefauch@cisco.com Tue Nov 20 00:03:38 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF52521F874F for ; Tue, 20 Nov 2012 00:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.267 X-Spam-Level: X-Spam-Status: No, score=-10.267 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPa-3HqZ74bX for ; Tue, 20 Nov 2012 00:03:33 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 871CC21F8538 for ; Tue, 20 Nov 2012 00:03:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11570; q=dns/txt; s=iport; t=1353398613; x=1354608213; h=from:to:subject:date:message-id:references:mime-version; bh=IO8hMhsKLFOFlD19CVRXD54Hrx2g+NaxOgNBFtlu28c=; b=kdtiOu6kPLiLCOQ97GUL45YT/zoX3Nysn98nX0XYl94ubirMytqwzwBJ LuKFlKaGqViIT3IeYsZyzS398H97yLxEt0LucLdz3vrxf9BZ/C7NoK/yZ 17iGHB1htnLKhuZGmVBpgbG2kQgwCeiNblFFnUFl4G2LHn4GtYip5s6LF E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYKAP03q1CtJXG+/2dsb2JhbABFuUgBiQuBAQeCHgEBAQQBAQEPATsgGwIBGQMBAgsCGwcnCgEUBwIIAgQTCAELBwIEAYdrC6ABj2WQUYwxGYN7YQOSSQWESo08gWuCb4FkNQ X-IronPort-AV: E=McAfee;i="5400,1158,6901"; a="144244313" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 20 Nov 2012 08:03:32 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAK83WM1022078 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 20 Nov 2012 08:03:32 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.192]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Tue, 20 Nov 2012 02:03:32 -0600 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: [CDNi] RFC 6770 on Use Cases for Content Delivery Network Interconnection Thread-Index: AQHNxry7f23xZHv5J0O6FUNei/egCg== Date: Tue, 20 Nov 2012 08:03:32 +0000 Message-ID: References: <20121120010929.82D5AB1E002@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.198] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D24BE03xmbrcdx10ciscocom_" MIME-Version: 1.0 Subject: [CDNi] Fwd: RFC 6770 on Use Cases for Content Delivery Network Interconnection X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 08:03:38 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D24BE03xmbrcdx10ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, We now have 2 RFCs behind us. Good ! Let's continue the momentum. Francois & Rich Begin forwarded message: From: > Subject: [CDNi] RFC 6770 on Use Cases for Content Delivery Network Intercon= nection Date: 20 November 2012 02:09:29 CET To: >, > Cc: >, > A new Request for Comments is now available in online RFC libraries. RFC 6770 Title: Use Cases for Content Delivery Network Interconnection Author: G. Bertrand, Ed., E. Stephan, T. Burbridge, P. Eardley, K. Ma, G. Watson Status: Informational Stream: IETF Date: November 2012 Mailbox: gilles.bertrand@orange.com, emile.stephan@orange.com, trevor.burbridge@bt.com, philip.eardley@bt.com, kevin.ma@azukisystems.com, gwatson@velocix.com Pages: 16 Characters: 33281 Obsoletes: RFC3570 I-D Tag: draft-ietf-cdni-use-cases-10.txt URL: http://www.rfc-editor.org/rfc/rfc6770.txt Content Delivery Networks (CDNs) are commonly used for improving the End User experience of a content delivery service while keeping cost at a reasonable level. This document focuses on use cases that correspond to identified industry needs and that are expected to be realized once open interfaces and protocols supporting the interconnection of CDNs are specified and implemented. This document can be used to motivate the definition of the requirements to be supported by CDN Interconnection (CDNI) interfaces. It obsoletes RFC 3570. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Content Delivery Networks Interconnection= Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC236DA6F2DA77449EF2D02DF4471A8D24BE03xmbrcdx10ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <81003395E771DF4E9B772EFE306EE0FF@cisco.com> Content-Transfer-Encoding: quoted-printable Hello,
We now have 2 RFCs behind us. Good !
Let's continue the momentum.
Francois & Rich

Begin forwarded message:

From: <<= a href=3D"mailto:rfc-editor@rfc-editor.org">rfc-editor@rfc-editor.org&g= t;
Subject: [C= DNi] RFC 6770 on Use Cases for Content Delivery Network Interconnection=
Date: 20 No= vember 2012 02:09:29 CET
To: <<= a href=3D"mailto:ietf-announce@ietf.org">ietf-announce@ietf.org>, &l= t;rfc-dist@rfc-editor.org>= ;
Cc: <<= a href=3D"mailto:cdni@ietf.org">cdni@ietf.org>, <rfc-editor@rfc-editor.org>


A new Request for Comments is now available in online RFC libraries.


       RFC 6770

       Title:     &n= bsp;Use Cases for Content Delivery
            &nb= sp;      Network Interconnection
       Author:     G= . Bertrand, Ed.,
            &nb= sp;      E. Stephan, T. Burbridge,
            &nb= sp;      P. Eardley, K. Ma,
            &nb= sp;      G. Watson
       Status:     I= nformational
       Stream:     I= ETF
       Date:     &nb= sp; November 2012
       Mailbox:    gilles.bertrand@orange.com,
            &nb= sp;      emile.stephan@orange.com,
            &nb= sp;      trevor.burbridge@bt.com,
            &nb= sp;      philip.eardley@bt.com,
            &nb= sp;      kevin.ma@azukisystems.com,
            &nb= sp;      gwatson@velocix.com
       Pages:     &n= bsp;16
       Characters: 33281
       Obsoletes:  RFC3570

       I-D Tag:    draft-= ietf-cdni-use-cases-10.txt

       URL:     &nbs= p;  http://= www.rfc-editor.org/rfc/rfc6770.txt

Content Delivery Networks (CDNs) are commonly used for improving the
End User experience of a content delivery service while keeping cost
at a reasonable level.  This document focuses on use cases that
correspond to identified industry needs and that are expected to be
realized once open interfaces and protocols supporting the
interconnection of CDNs are specified and implemented.  This document<= br> can be used to motivate the definition of the requirements to be
supported by CDN Interconnection (CDNI) interfaces.  It obsoletes RFC<= br> 3570.  This document is not an Internet Standards Track specification;=
it is published for informational purposes.

This document is a product of the Content Delivery Networks Interconnection= Working Group of the IETF.


INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
 http:/= /www.ietf.org/mailman/listinfo/ietf-announce
 h= ttp://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see ht= tp://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

--_000_FC236DA6F2DA77449EF2D02DF4471A8D24BE03xmbrcdx10ciscocom_-- From flefauch@cisco.com Wed Nov 21 01:49:34 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFF321F857B for ; Wed, 21 Nov 2012 01:49:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.574 X-Spam-Level: X-Spam-Status: No, score=-10.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeJ2XGWoIU7E for ; Wed, 21 Nov 2012 01:49:33 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2C91421F856D for ; Wed, 21 Nov 2012 01:49:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5430; q=dns/txt; s=iport; t=1353491373; x=1354700973; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=CdOPUOXqA3jzY6r+NaQ2ifysWZSJoYp8LAn3wFlAFds=; b=i6X/zW4dVMdrtL/HA6foHuo2K4SUiPBiDKyU46+oGGwu0ChWCf/4lRC1 bCRdFdGemLvwaRzJXgZ5GU0L2maSHGU71GpbuPPsQxmmzG59dKUSu1lCr 3LOLoypAxbd4+ebhVSTYUOSobP3afEGf8/+lP2WFqmKVCAu5UA5N1URtU U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggKAFWjrFCtJXHA/2dsb2JhbABEwkIWbAeCHgEBAQMBAQEBaxsCAQgRBAEBAQodBycLFAkIAgQTCId/Bgu2YIg9jDSEAmEDpj+Cb4IZ X-IronPort-AV: E=McAfee;i="5400,1158,6902"; a="144801265" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 21 Nov 2012 09:49:32 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qAL9nWoa011181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 21 Nov 2012 09:49:32 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.192]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Wed, 21 Nov 2012 03:49:32 -0600 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: [CDNi] Acronyms for the CDNI interfaces Thread-Index: AQHNvfsyv+R0Tv5ROk6hOdIj1ufyOpfhNkkAgACw7AD//59c0IAAaSwAgAT2GACAAAiMAIANlT2A Date: Wed, 21 Nov 2012 09:49:31 +0000 Message-ID: References: <291CC3F9E50E7641901A54E85D0977C6535F5DB898@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.198] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] Acronyms for the CDNI interfaces X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 09:49:34 -0000 All, So Just to close on that one. I believe we have an agreement for the following: * "CI" for the CDNI Control Interface * "MI" for the CDNI Metadata distribution Interface * "LI" for the CDNI Logging Interface * "RI" for the CDNI request routing/Redirection Interface * "FCI" for the CDNI request routing/Footprint & Capabilities adverti= sement Interface * no acronym defined for the umbrella "Request Routing Interface" * avoid using the umbrella term of "Request Routing Interface" and in= stead use the specific terms of "CDNI request routing/Redirection Interface= (RI)" and "CDNI request routing/Footprint & Capabilities advertisement Int= erface (FCI)" To all CDNI I-Ds editors, Please reflect the above agreement in all open Internet-Drafts. Francois=20 On 12 Nov 2012, at 19:24, Francois Le Faucheur (flefauch) wrote: >=20 > On 12 Nov 2012, at 18:53, Peterson, Larry wrote: >=20 >> I'm good with these, but in working through the framework=20 >> document, I note that we also make significant reference to=20 >> the generic Request Routing Interface. While we could add >> RRI to the set, and then fully qualify the two sub-interfaces >> (i.e., RR/RI and RR/FCI), I propose instead to stick with RI=20 >> and FCI, and just not use an acronym for the generic Request >> Routing Interface. (For me, the main value of the acronyms >> is in the figures, and we never need RRI.) >=20 > First, I agree with not having an acronym for the Request Routing Interfa= ce. >=20 > Secondly, as the "CDNI request routing/Redirection Interface" and "CDNI r= equest routing/Footprint & Capabilities advertisement Interface" are firmin= g up, there is probably less and less rationale for even referring to the R= equest Routing Interface per say. At the beginning we were not sure whether= the two components would be realized with one or two interfaces so we bund= led the two functions under the term Request Routing Interface, but now tha= t we are quite clear that they will be realized separately, we can probably= always refer to RI and FCI specifically. >=20 > So, with respect to the Framework, I'd suggest: > * explaining early in the document that the Request Routing Interface is= a logical grouping of RI and FCI, because the two relate to enabling reque= st routing > * then, whenever possible, only use the terms "CDNI request routing/Redi= rection Interface" and "CDNI request routing/Footprint & Capabilities adver= tisement Interface". And when you want to refer to both, then just list the= m both (instead of using "Request Routing Interface") either using the full= name or the acronym. >=20 > Makes sense? >=20 > Francois >=20 >>=20 >> Larry >>=20 >>=20 >> On Nov 9, 2012, at 9:07 AM, Francois Le Faucheur (flefauch) wrote: >>=20 >>> Works for me. So latest proposal on the table is: >>>=20 >>> * CI, MI, LI, RI, FCI >>>=20 >>>=20 >>> PS: and no, the "I" is not superfluous 8^) >>>=20 >>> On 9 Nov 2012, at 14:58, Kevin J Ma wrote: >>>=20 >>>> The "C" is somewhat superfluous? We could drop all the "C"s. >>>> CI, MI, LI, RI, and FI? >>>>=20 >>>> And, at the risk of opening a rat hole, "FI" seems to imply >>>> that footprint is more important than capabilities... :) >>>> "FCI"? >>>>=20 >>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf O= f Francois Le Faucheur (flefauch) >>>> Sent: Friday, November 09, 2012 8:37 AM >>>> To: B.Khasnabish@ieee.org >>>> Cc: cdni@ietf.org >>>> Subject: Re: [CDNi] Acronyms for the CDNI interfaces >>>>=20 >>>>=20 >>>> On 9 Nov 2012, at 04:03, B.Khasnabish@ieee.org wrote: >>>>=20 >>>>=20 >>>> Hi Francois, >>>>=20 >>>> Thanks. This is a good start. >>>>=20 >>>> As you know, "CLI" is widely used for "Command Line Interface," >>>> (http://en.wikipedia.org/wiki/Command-line_interface) >>>> so let us consider something different for "CDNI Logging Interface"=85 >>>>=20 >>>> "CLoI" ? >>>>=20 >>>>=20 >>>>=20 >>>> Best. >>>>=20 >>>> Bhumip >>>>=20 >>>>=20 >>>>=20 >>>> On Thu, Nov 8, 2012 at 4:51 PM, Francois Le Faucheur (flefauch) wrote: >>>> Folks, >>>>=20 >>>> As discussed during the Atlanta meeting, we need to agree on a set of = acronyms to designate the CDNI interfaces consistently across documents (pa= rticularly in figures where the full name cannot be used). >>>>=20 >>>> A base proposal is: >>>> * "CCI" for the CDNI Control Interface >>>> * "CMI" for the CDNI Metadata distribution Interface >>>> * "CLI" for the CDNI Logging Interface >>>> * "CRI" for the CDNI request routing/Redirection Interface >>>> * "CFI" for the CDNI request routing/Footprint & capabilities ad= vertisement Interface. >>>>=20 >>>> Let us know if you see issues with that, or if you want to offer a bet= ter proposal. >>>>=20 >>>> Cheers >>>>=20 >>>> Francois >>>>=20 >>>> PS: some of the acronyms above probably conflict with some acronyms yo= u've already encountered somewhere else before, but those don't seem to be = major conflict, and it'd be nice to stick to short acronyms. >>>> _______________________________________________ >>>> CDNi mailing list >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> >>=20 >=20 From flefauch@cisco.com Wed Nov 21 02:05:07 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A9121F881F for ; Wed, 21 Nov 2012 02:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.576 X-Spam-Level: X-Spam-Status: No, score=-10.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvSFwzM0YbNi for ; Wed, 21 Nov 2012 02:05:03 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id D819721F86C8 for ; Wed, 21 Nov 2012 02:05:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=701; q=dns/txt; s=iport; t=1353492303; x=1354701903; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=pqKrhH86Ur6eibtd3L2NhA48tGiDNyOkHV9BgyCAfkk=; b=gJYP0Z1CtR5Kf3dvSlIbdyUmnOQ6ctF7P0QHLOIfZwKYvWg15dpBJi64 /rzah3D2e7WtzHzDQsViKix3OErOHfd+6KJYdtIuvkjcpaoitDAFbKnLG a//9P8KVZdtgZagHsQhIEeUoFT4RwMKjP3hb1akrK+y9QuG2oxXpjTVXt Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUKAOqmrFCtJXG8/2dsb2JhbABEwkIWbAeCIAEEOlEBKhRCJwQbiAWdYqFJkDZhA6Y/gm+CGQ X-IronPort-AV: E=McAfee;i="5400,1158,6902"; a="144806218" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 21 Nov 2012 10:04:59 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qALA4xfJ024507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 21 Nov 2012 10:04:59 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.192]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Wed, 21 Nov 2012 04:04:58 -0600 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Confirming some IETF-85 decisions Thread-Index: AQHNx8+pxDEjRjrDOki2Ny1w43ylTQ== Date: Wed, 21 Nov 2012 10:04:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.198] Content-Type: text/plain; charset="us-ascii" Content-ID: <96B0F8BCBD9046439F1A5CCC9865EC92@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Confirming some IETF-85 decisions X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 10:05:09 -0000 All, As documented in the minutes, the following decisions were tentatively made= at IETF-85: * Content Deduplication: The WG will continue the work on this topic insid= e the WG, but will not aim to support it in first version of the CDNI inter= faces. * Long Tail Content: The WG will not continue the work on this topic insid= e the WG for now (at least not as a priority item) and will not aim to supp= ort something specific for it in first version of the CDNI interfaces. * CDNI Logging: draft-bertrand-cdni-logging is accepted as WG document We will consider these decisions confirmed unless we hear substantiated obj= ections by 30 Nov. Cheers Francois & Rich= From ben@niven-jenkins.co.uk Wed Nov 21 04:12:24 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD2C21F8882 for ; Wed, 21 Nov 2012 04:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0AG3kD8jQZm for ; Wed, 21 Nov 2012 04:12:17 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6455F21F87BB for ; Wed, 21 Nov 2012 04:12:17 -0800 (PST) Received: from [81.134.152.4] (helo=xxx.corp.velocix.com) by mail4.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Tb9A7-00036u-Ms; Wed, 21 Nov 2012 12:12:16 +0000 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Wed, 21 Nov 2012 12:12:12 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <60496D7E-F597-44C7-8DA2-A412E7D4C3B8@niven-jenkins.co.uk> References: <20121022185902.22651.23401.idtracker@ietfa.amsl.com> <021501cdb09a$9da68300$d8f38900$@comcast.net> To: Francois Le Faucheur (flefauch) X-Mailer: Apple Mail (2.1085) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "" , ietfdbh Subject: Re: [CDNi] I-D Action: draft-bertrand-cdni-logging-02.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 12:12:24 -0000 On 7 Nov 2012, at 16:21, Francois Le Faucheur (flefauch) wrote: > Good discussion. > The next rev of the logging draft will start documenting the = requirements for long exchange, specifically in terms of scalability and = reliability. >=20 > Quick question on an assumption below: >>=20 >> But as an example, let's assume a cache is delivering Live MS = Smoothstreaming and the clients are requesting the manifest every 10 = seconds then a CDN will be generating 1100 log lines a second for each = Gbps of traffic it is delivering. >=20 > So there are some assumption here on some average number of = simultaneous viewers of that Live stream, right? > Just to understand this figure, can you expand a bit on how this has = been derived, like is this based on observation in some production CDN = over a number of Live channels?=20 Sorry, I got my maths wrong. I was assuming each client was receiving an = average of 1 Mbps with 2 second chunks and a manifest request every 10 = seconds so 1000 clients per Gbps of traffic requesting a chunk each = every 2 seconds and a manifest request each every 10 seconds, so 600 = requests/s on average. Ben From flefauch@cisco.com Wed Nov 21 05:59:07 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA8E21F85E4 for ; Wed, 21 Nov 2012 05:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.334 X-Spam-Level: X-Spam-Status: No, score=-10.334 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yy0rdZrLIhu0 for ; Wed, 21 Nov 2012 05:59:06 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB4921F85DF for ; Wed, 21 Nov 2012 05:59:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1293; q=dns/txt; s=iport; t=1353506346; x=1354715946; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=kg07oAzrG0oob11hHh8wkA04sWuIkYdmloMzKof0RLc=; b=P2jgBIYys6BmqtKMrKFQ3fGF/mqRp+rZAH15lJOleRd3TVkEEdFTzR+E bQqDUiisf97DKxahfqp57XKTYtant4OkyBr7JNeVhk4RNuWEDxak7lWmz OXJgfLd+ujBDaIaH5y25djubH0N/Ydf1d3ddP0Qwzr8GxeOyK/yOynpVO I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOTcrFCtJV2Z/2dsb2JhbABEwkIWc4IeAQEBAwE6PxACAQgYChQQMiUCBA4Nh38GvzSMNIQCYQOmP4Jvghk X-IronPort-AV: E=McAfee;i="5400,1158,6902"; a="144812403" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 21 Nov 2012 13:59:06 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qALDx6Vu025776 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Nov 2012 13:59:06 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.192]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Wed, 21 Nov 2012 07:59:05 -0600 From: "Francois Le Faucheur (flefauch)" To: Ben Niven-Jenkins Thread-Topic: [CDNi] I-D Action: draft-bertrand-cdni-logging-02.txt Thread-Index: AQHNvQPn6KX8AbB/akGBgMXQIlxedZf0rWwAgAAd3AA= Date: Wed, 21 Nov 2012 13:59:04 +0000 Message-ID: References: <20121022185902.22651.23401.idtracker@ietfa.amsl.com> <021501cdb09a$9da68300$d8f38900$@comcast.net> <60496D7E-F597-44C7-8DA2-A412E7D4C3B8@niven-jenkins.co.uk> In-Reply-To: <60496D7E-F597-44C7-8DA2-A412E7D4C3B8@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.198] Content-Type: text/plain; charset="us-ascii" Content-ID: <75FC77C1ACBF9845BC934AF7B220CEFB@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , ietfdbh Subject: Re: [CDNi] I-D Action: draft-bertrand-cdni-logging-02.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 13:59:07 -0000 On 21 Nov 2012, at 13:12, Ben Niven-Jenkins wrote: >=20 > On 7 Nov 2012, at 16:21, Francois Le Faucheur (flefauch) wrote: >=20 >> Good discussion. >> The next rev of the logging draft will start documenting the requirement= s for long exchange, specifically in terms of scalability and reliability. >>=20 >> Quick question on an assumption below: >>>=20 >>> But as an example, let's assume a cache is delivering Live MS Smoothstr= eaming and the clients are requesting the manifest every 10 seconds then a = CDN will be generating 1100 log lines a second for each Gbps of traffic it = is delivering. >>=20 >> So there are some assumption here on some average number of simultaneous= viewers of that Live stream, right? >> Just to understand this figure, can you expand a bit on how this has bee= n derived, like is this based on observation in some production CDN over a = number of Live channels?=20 >=20 > Sorry, I got my maths wrong. I was assuming each client was receiving an = average of 1 Mbps with 2 second chunks and a manifest request every 10 seco= nds so 1000 clients per Gbps of traffic requesting a chunk each every 2 se= conds and a manifest request each every 10 seconds, so 600 requests/s on av= erage. Makes sense now. >=20 > Ben >=20 From roy@skytide.com Wed Nov 21 11:59:21 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0AC21F872D for ; Wed, 21 Nov 2012 11:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0xDTUL0T8tm for ; Wed, 21 Nov 2012 11:59:20 -0800 (PST) Received: from mail-pop3-1.server101.com (ns1.giga-sj-001.net [216.218.210.201]) by ietfa.amsl.com (Postfix) with ESMTP id EB53721F86D4 for ; Wed, 21 Nov 2012 11:59:20 -0800 (PST) Received: from [192.168.1.100] (70-36-140-147.dsl.dynamic.sonic.net [70.36.140.147]) (authenticated as roy@skytide.com with PLAIN (0 bits)) by mail-pop3-1.server101.com (8.13.7/8.12.8) with ESMTP id qALJxGj8031724; Thu, 22 Nov 2012 05:59:16 +1000 Message-ID: <50AD3294.5090907@skytide.com> Date: Wed, 21 Nov 2012 11:59:16 -0800 From: Roy Peterkofsky User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ben Niven-Jenkins References: <20121022185902.22651.23401.idtracker@ietfa.amsl.com> <021501cdb09a$9da68300$d8f38900$@comcast.net> <60496D7E-F597-44C7-8DA2-A412E7D4C3B8@niven-jenkins.co.uk> In-Reply-To: <60496D7E-F597-44C7-8DA2-A412E7D4C3B8@niven-jenkins.co.uk> Content-Type: multipart/alternative; boundary="------------060700000108090308050005" Cc: "" , ietfdbh Subject: Re: [CDNi] I-D Action: draft-bertrand-cdni-logging-02.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 19:59:21 -0000 This is a multi-part message in MIME format. --------------060700000108090308050005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit If you have 1000 clients concurrently, you can expect one video AND one audio fragment every two seconds per client = 1000 total reqs/second. If you add in your assumed 1 manifest request per 10 seconds per client ( x 1000 clients), that is another 100 reqs/second. Net effect, I think your original 1100 lines/second was correct (under the stated assumptions). On 11/21/2012 4:12 AM, Ben Niven-Jenkins wrote: > On 7 Nov 2012, at 16:21, Francois Le Faucheur (flefauch) wrote: > >> Good discussion. >> The next rev of the logging draft will start documenting the requirements for long exchange, specifically in terms of scalability and reliability. >> >> Quick question on an assumption below: >>> But as an example, let's assume a cache is delivering Live MS Smoothstreaming and the clients are requesting the manifest every 10 seconds then a CDN will be generating 1100 log lines a second for each Gbps of traffic it is delivering. >> So there are some assumption here on some average number of simultaneous viewers of that Live stream, right? >> Just to understand this figure, can you expand a bit on how this has been derived, like is this based on observation in some production CDN over a number of Live channels? > Sorry, I got my maths wrong. I was assuming each client was receiving an average of 1 Mbps with 2 second chunks and a manifest request every 10 seconds so 1000 clients per Gbps of traffic requesting a chunk each every 2 seconds and a manifest request each every 10 seconds, so 600 requests/s on average. > > Ben > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2013.0.2793 / Virus Database: 2629/5909 - Release Date: 11/21/12 > > -- Roy Peterkofsky Vice President, Product Management Skytide -- the leader in Digital Media Performance Management www.skytide.com (510) 250-4284 Read our new white paper: The 4 Keys to Telco CDN Success --------------060700000108090308050005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
If you have 1000 clients concurrently, you can expect one video AND one audio fragment every two seconds per client = 1000 total reqs/second.  If you add in your assumed 1 manifest request per 10 seconds per client ( x 1000 clients), that is another 100 reqs/second.  Net effect, I think your original 1100 lines/second was correct (under the stated assumptions).


On 11/21/2012 4:12 AM, Ben Niven-Jenkins wrote:
On 7 Nov 2012, at 16:21, Francois Le Faucheur (flefauch) wrote:


Good discussion.
The next rev of the logging draft will start documenting the requirements for long exchange, specifically in terms of scalability and reliability.

Quick question on an assumption below:

But as an example, let's assume a cache is delivering Live MS Smoothstreaming and the clients are requesting the manifest every 10 seconds then a CDN will be generating 1100 log lines a second for each Gbps of traffic it is delivering.

So there are some assumption here on some average number of simultaneous viewers of that Live stream, right?
Just to understand this figure, can you expand a bit on how this has been derived, like is this based on observation in some production CDN over a number of Live channels? 

Sorry, I got my maths wrong. I was assuming each client was receiving an average of 1 Mbps with 2 second chunks and a manifest request every 10 seconds  so 1000 clients per Gbps of traffic requesting a chunk each every 2 seconds and a manifest request each every 10 seconds, so 600 requests/s on average.

Ben

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2793 / Virus Database: 2629/5909 - Release Date: 11/21/12


--
Roy Peterkofsky
Vice President, Product Management
Skytide -- the leader in Digital Media Performance Management
www.skytide.com
(510) 250-4284

Read our new white paper: The 4 Keys to Telco CDN Success
--------------060700000108090308050005-- From vumip1@gmail.com Wed Nov 21 12:07:35 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62AF121F8756 for ; Wed, 21 Nov 2012 12:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQD5odzGAmw1 for ; Wed, 21 Nov 2012 12:07:34 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 977FB21F8733 for ; Wed, 21 Nov 2012 12:07:33 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so6156796lah.31 for ; Wed, 21 Nov 2012 12:07:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V6VjZa4BBRdNlPFWiRKj4try7cOdQ6QZVjmfxtDOrTc=; b=L/E9iIpiOBF7GcEZEAG4doK4BW0/wvCOq8xJ0kR3gxhY6SgVkjqxrwVf1zal0s8jlk bNrIWk4N9iUtxnQZu8XOzw1o7v0VCbdwmZzSTVM7ziisSFOSoFBjmLdOf9BA67yb/Vbe 0bq4+xXL2igNj2HeUgUvn0wXAtk48Ny6c4sZC66liEcl2uJTQSmb/PwdDw/CiwTIuhJg YCbNLx5hgJZ8fLxkDp6l8k/6zL+CZiaTb2GgYfch4wOaPjBbdP7Cx4zO56KroQJMmgSI 7/Rbde183NVCemEKE7ipo5xxTfOLpRqe10Gxb3mUTFU4nZgJGg9qAw9SIkyUnJLUVj8A EN1A== MIME-Version: 1.0 Received: by 10.112.83.229 with SMTP id t5mr7768340lby.89.1353528452429; Wed, 21 Nov 2012 12:07:32 -0800 (PST) Received: by 10.114.5.161 with HTTP; Wed, 21 Nov 2012 12:07:32 -0800 (PST) In-Reply-To: References: <291CC3F9E50E7641901A54E85D0977C6535F5DB898@MAILR002.mail.lan> Date: Wed, 21 Nov 2012 15:07:32 -0500 Message-ID: From: "B.Khasnabish@ieee.org" To: "Francois Le Faucheur (flefauch)" Content-Type: multipart/alternative; boundary=f46d04016d9d99b6e904cf06e62e Cc: "cdni@ietf.org" Subject: Re: [CDNi] Acronyms for the CDNI interfaces X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 20:07:35 -0000 --f46d04016d9d99b6e904cf06e62e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable You may also consider the following . * "CDN-CI" for the CDNI Control Interface * "CDN-MI" for the CDNI Metadata distribution Interface * "CDN-LI" for the CDNI Logging Interface * "CDN-RI" for the CDNI request routing/Redirection Interface * "CDN-FCI" for the CDNI request routing/Footprint & Capabilities advertisement Interface Thanks for considering these Francois .. Best. Bhumip On Wed, Nov 21, 2012 at 4:49 AM, Francois Le Faucheur (flefauch) < flefauch@cisco.com> wrote: > All, > > So Just to close on that one. > I believe we have an agreement for the following: > > * "CI" for the CDNI Control Interface > * "MI" for the CDNI Metadata distribution Interface > * "LI" for the CDNI Logging Interface > * "RI" for the CDNI request routing/Redirection Interface > * "FCI" for the CDNI request routing/Footprint & Capabilities > advertisement Interface > * no acronym defined for the umbrella "Request Routing Interface" > * avoid using the umbrella term of "Request Routing Interface" and > instead use the specific terms of "CDNI request routing/Redirection > Interface (RI)" and "CDNI request routing/Footprint & Capabilities > advertisement Interface (FCI)" > > > To all CDNI I-Ds editors, > Please reflect the above agreement in all open Internet-Drafts. > > Francois > > On 12 Nov 2012, at 19:24, Francois Le Faucheur (flefauch) wrote: > > > > > On 12 Nov 2012, at 18:53, Peterson, Larry wrote: > > > >> I'm good with these, but in working through the framework > >> document, I note that we also make significant reference to > >> the generic Request Routing Interface. While we could add > >> RRI to the set, and then fully qualify the two sub-interfaces > >> (i.e., RR/RI and RR/FCI), I propose instead to stick with RI > >> and FCI, and just not use an acronym for the generic Request > >> Routing Interface. (For me, the main value of the acronyms > >> is in the figures, and we never need RRI.) > > > > First, I agree with not having an acronym for the Request Routing > Interface. > > > > Secondly, as the "CDNI request routing/Redirection Interface" and "CDNI > request routing/Footprint & Capabilities advertisement Interface" are > firming up, there is probably less and less rationale for even referring = to > the Request Routing Interface per say. At the beginning we were not sure > whether the two components would be realized with one or two interfaces s= o > we bundled the two functions under the term Request Routing Interface, bu= t > now that we are quite clear that they will be realized separately, we can > probably always refer to RI and FCI specifically. > > > > So, with respect to the Framework, I'd suggest: > > * explaining early in the document that the Request Routing > Interface is a logical grouping of RI and FCI, because the two relate to > enabling request routing > > * then, whenever possible, only use the terms "CDNI request > routing/Redirection Interface" and "CDNI request routing/Footprint & > Capabilities advertisement Interface". And when you want to refer to both= , > then just list them both (instead of using "Request Routing Interface") > either using the full name or the acronym. > > > > Makes sense? > > > > Francois > > > >> > >> Larry > >> > >> > >> On Nov 9, 2012, at 9:07 AM, Francois Le Faucheur (flefauch) wrote: > >> > >>> Works for me. So latest proposal on the table is: > >>> > >>> * CI, MI, LI, RI, FCI > >>> > >>> > >>> PS: and no, the "I" is not superfluous 8^) > >>> > >>> On 9 Nov 2012, at 14:58, Kevin J Ma wrote: > >>> > >>>> The "C" is somewhat superfluous? We could drop all the "C"s. > >>>> CI, MI, LI, RI, and FI? > >>>> > >>>> And, at the risk of opening a rat hole, "FI" seems to imply > >>>> that footprint is more important than capabilities... :) > >>>> "FCI"? > >>>> > >>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > Of Francois Le Faucheur (flefauch) > >>>> Sent: Friday, November 09, 2012 8:37 AM > >>>> To: B.Khasnabish@ieee.org > >>>> Cc: cdni@ietf.org > >>>> Subject: Re: [CDNi] Acronyms for the CDNI interfaces > >>>> > >>>> > >>>> On 9 Nov 2012, at 04:03, B.Khasnabish@ieee.org wrote: > >>>> > >>>> > >>>> Hi Francois, > >>>> > >>>> Thanks. This is a good start. > >>>> > >>>> As you know, "CLI" is widely used for "Command Line Interface," > >>>> (http://en.wikipedia.org/wiki/Command-line_interface) > >>>> so let us consider something different for "CDNI Logging Interface"= =85 > >>>> > >>>> "CLoI" ? > >>>> > >>>> > >>>> > >>>> Best. > >>>> > >>>> Bhumip > >>>> > >>>> > >>>> > >>>> On Thu, Nov 8, 2012 at 4:51 PM, Francois Le Faucheur (flefauch) < > flefauch@cisco.com> wrote: > >>>> Folks, > >>>> > >>>> As discussed during the Atlanta meeting, we need to agree on a set o= f > acronyms to designate the CDNI interfaces consistently across documents > (particularly in figures where the full name cannot be used). > >>>> > >>>> A base proposal is: > >>>> * "CCI" for the CDNI Control Interface > >>>> * "CMI" for the CDNI Metadata distribution Interface > >>>> * "CLI" for the CDNI Logging Interface > >>>> * "CRI" for the CDNI request routing/Redirection Interface > >>>> * "CFI" for the CDNI request routing/Footprint & capabilities > advertisement Interface. > >>>> > >>>> Let us know if you see issues with that, or if you want to offer a > better proposal. > >>>> > >>>> Cheers > >>>> > >>>> Francois > >>>> > >>>> PS: some of the acronyms above probably conflict with some acronyms > you've already encountered somewhere else before, but those don't seem to > be major conflict, and it'd be nice to stick to short acronyms. > >>>> _______________________________________________ > >>>> CDNi mailing list > >>>> CDNi@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/cdni > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >> > > > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > --f46d04016d9d99b6e904cf06e62e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
You may also consider the following .
=A0
=A0=A0=A0=A0=A0 * "CDN-CI" for the CDNI Control Interface

=A0=A0=A0=A0=A0 * "CDN-MI" for the CDNI Metadata distrib= ution Interface
=A0=A0=A0=A0=A0 * "CDN-LI" for the CDNI Logging Interface
=A0=A0=A0=A0=A0 * "CDN-RI" for the CDNI request routing/Redi= rection Interface
=A0=A0=A0=A0=A0 * "CDN-FCI" for the CDNI request routing/Foo= tprint & Capabilities advertisement Interface

=A0
Thanks for considering these Francois ..
=A0
Best.
=A0
Bhumip


=A0
On Wed, Nov 21, 2012 at 4:49 AM, Francois Le Fau= cheur (flefauch) <flefauch@cisco.com> wrote:
All,

So Just to close on that = one.
I believe we have an agreement for the following:

=A0 =A0 = =A0 * "CI" for the CDNI Control Interface
=A0 =A0 =A0 * "MI" for the CDNI Metadata distribution Interface=A0 =A0 =A0 * "LI" for the CDNI Logging Interface
=A0 =A0 = =A0 * "RI" for the CDNI request routing/Redirection Interface
= =A0 =A0 =A0 * "FCI" for the CDNI request routing/Footprint & = Capabilities advertisement Interface
=A0 =A0 =A0 * no acronym defined for the umbrella "Request Routing Int= erface"
=A0 =A0 =A0 * avoid using the umbrella term of "Reques= t Routing Interface" and instead use the specific terms of "CDNI = request routing/Redirection Interface (RI)" and "CDNI request rou= ting/Footprint & Capabilities advertisement Interface (FCI)"


To all CDNI I-Ds editors,
Please reflect the above agreement in = all open Internet-Drafts.

Francois
=

On 12 Nov 2012, at 19:24, Francois Le Faucheur (flefauch) wrote:
>
> On 12 Nov 2012, at 18:53, Peterson, Larry wrote:
>=
>> I'm good with these, but in working through the framework<= br> >> document, I note that we also make significant reference to
>= ;> the generic Request Routing Interface. While we could add
>>= RRI to the set, and then fully qualify the two sub-interfaces
>> = (i.e., RR/RI and RR/FCI), I propose instead to stick with RI
>> and FCI, and just not use an acronym for the generic Request
&g= t;> Routing Interface. (For me, the main value of the acronyms
>&g= t; is in the figures, and we never need RRI.)
>
> First, I agre= e with not having an acronym for the Request Routing Interface.
>
> Secondly, as the "CDNI request routing/Redirection Interf= ace" and "CDNI request routing/Footprint & Capabilities adver= tisement Interface" are firming up, there is probably less and less ra= tionale for even referring to the Request Routing Interface per say. At the= beginning we were not sure whether the two components would be realized wi= th one or two interfaces so we bundled the two functions under the term Req= uest Routing Interface, but now that we are quite clear that they will be r= ealized separately, we can probably always refer to RI and FCI specifically= .
>
> So, with respect to the Framework, I'd suggest:
> = =A0 =A0 =A0 * explaining early in the document that the Request Routing Int= erface is a logical grouping of RI and FCI, because the two relate to enabl= ing request routing
> =A0 =A0 =A0 * then, whenever possible, only use the terms "CDNI r= equest routing/Redirection Interface" and "CDNI request routing/F= ootprint & Capabilities advertisement Interface". And when you wan= t to refer to both, then just list them both (instead of using "Reques= t Routing Interface") either using the full name or the acronym.
>
> Makes sense?
>
> Francois
>
>>
&= gt;> Larry
>>
>>
>> On Nov 9, 2012, at 9:07 A= M, Francois Le Faucheur (flefauch) wrote:
>>
>>> Works= for me. So latest proposal on the table is:
>>>
>>> * CI, MI, LI, RI, FCI
>>>
>&= gt;>
>>> PS: and no, the "I" is not superfluous 8^= )
>>>
>>> On 9 Nov 2012, at 14:58, Kevin J Ma wrote= :
>>>
>>>> The "C" is somewhat superfluous?= =A0We could drop all the "C"s.
>>>> CI, MI, LI, R= I, and FI?
>>>>
>>>> And, at the risk of open= ing a rat hole, "FI" seems to imply
>>>> that footprint is more important than capabilities... =A0:= )
>>>> "FCI"?
>>>>
>>>&= gt; From: cdni-b= ounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le Faucheur (f= lefauch)
>>>> Sent: Friday, November 09, 2012 8:37 AM
>>>>= ; To: B.Khasnabi= sh@ieee.org
>>>> Cc: cdni@ietf.org
>>>> Subject: Re: [CDNi] Acronyms for the CDNI interfaces
&g= t;>>>
>>>>
>>>> On 9 Nov 2012, at 04= :03, B.Khasnabis= h@ieee.org wrote:
>>>>
>>>>
>>>> Hi Francois,
&g= t;>>>
>>>> Thanks. This is a good start.
>>= ;>>
>>>> As you know, "CLI" is widely used f= or "Command Line Interface,"
>>>> (http://en.wikipedia.org/wiki/Command-line_interfac= e)
>>>> so let us consider something different for "= ;CDNI Logging Interface"=85
>>>>
>>>> "CLoI" ?
>>>>=
>>>>
>>>>
>>>> Best.
>&= gt;>>
>>>> Bhumip
>>>>
>>>&= gt;
>>>>
>>>> On Thu, Nov 8, 2012 at 4:51 PM, Franco= is Le Faucheur (flefauch) <flefauch@cisco.com> wrote:
>>>> Folks, >>>>
>>>> As discussed during the Atlanta meetin= g, we need to agree on a set of acronyms to designate the CDNI interfaces c= onsistently across documents (particularly in figures where the full name c= annot be used).
>>>>
>>>> A base proposal is:
>>>>= ; =A0 =A0 =A0 * "CCI" for the CDNI Control Interface
>>&= gt;> =A0 =A0 =A0 * "CMI" for the CDNI Metadata distribution In= terface
>>>> =A0 =A0 =A0 * "CLI" for the CDNI Logging Interfa= ce
>>>> =A0 =A0 =A0 * "CRI" for the CDNI request r= outing/Redirection Interface
>>>> =A0 =A0 =A0 * "CFI&qu= ot; for the CDNI request routing/Footprint & capabilities advertisement= Interface.
>>>>
>>>> Let us know if you see issues with tha= t, or if you want to offer a better proposal.
>>>>
>&g= t;>> Cheers
>>>>
>>>> Francois
>&= gt;>>
>>>> PS: some of the acronyms above probably conflict with some= acronyms you've already encountered somewhere else before, but those d= on't seem to be major conflict, and it'd be nice to stick to short = acronyms.
>>>> _______________________________________________
>>= ;>> CDNi mailing list
>>>> CDNi@ietf.org
>>>> https://www.iet= f.org/mailman/listinfo/cdni
>>>>
>>>>
>>>>
>>>>= ;
>>>>
>>>
>>> <ATT00001.c>>>
>

_______________________________________________ CDNi mailing list
CDN= i@ietf.org
https://www.ietf.org/mailman/listinfo/cdni



=A0=20 --f46d04016d9d99b6e904cf06e62e-- From vumip1@gmail.com Wed Nov 21 12:16:15 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED8E21F849A for ; Wed, 21 Nov 2012 12:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhVMrMnSvM3x for ; Wed, 21 Nov 2012 12:16:14 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E895621F8319 for ; Wed, 21 Nov 2012 12:16:13 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so6162862lah.31 for ; Wed, 21 Nov 2012 12:16:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6CUHCq7JlD89r6YZI7B0WVqKB26+e4BF4dLc3ZlHbcE=; b=DemJGzlES6nr/5zbAPX8/wmsbpH/wjaw8Qt2iNsC1ZFp+J8zDIKwgKiyfl57LnKjMP fh1Zf+tIgaU/vQ4XrZgQWMU09/ddJfH4mfdwNyEXgFftAjp5SWDRS/FBqQLVgzj9G1/y bKnAcwFuY6+drbz3N+3IpDm7Fq982dm7gy9iIVp5R3xThNbghTSYpTO5ysRp3fJWTcQq Tvz+X5KfEL/lrJA4AXvAD3Zr6iNvp6BKCi06PFi7wnlo7XjEDvzNbQ+NMQPxm0GZ7hWU 9CMjYcc5+h5eRaZ8ByBksMEgH75zTSSPDjOw4leA61TskN4BisCz1VhCXYtnOQg1tEU3 0fEw== MIME-Version: 1.0 Received: by 10.112.10.232 with SMTP id l8mr3443509lbb.69.1353528972789; Wed, 21 Nov 2012 12:16:12 -0800 (PST) Received: by 10.114.5.161 with HTTP; Wed, 21 Nov 2012 12:16:12 -0800 (PST) In-Reply-To: References: Date: Wed, 21 Nov 2012 15:16:12 -0500 Message-ID: From: "B.Khasnabish@ieee.org" To: "Francois Le Faucheur (flefauch)" Content-Type: multipart/alternative; boundary=e0cb4efe33809dca0b04cf0705eb Cc: "cdni@ietf.org" Subject: Re: [CDNi] Confirming some IETF-85 decisions X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 20:16:15 -0000 --e0cb4efe33809dca0b04cf0705eb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks Francois .. Yes, we'll continue to work on the de-dup draft, and plan to update it with inputs from other operators for including scenarios like the ones that Marcin mentioned (use of DRM). We welcome inputs / feedback / suggestions from others as well. For LTC draft, Ramki will contact you, and send further comments/suggestions. For the Logging draft, do you know *why Syslog is not the good * *answer for CDNi requirements* ? Best. Bhumip On Wed, Nov 21, 2012 at 5:04 AM, Francois Le Faucheur (flefauch) < flefauch@cisco.com> wrote: > All, > > As documented in the minutes, the following decisions were tentatively > made at IETF-85: > > * Content Deduplication: The WG will continue the work on this > topic inside the WG, but will not aim to support it in first version of t= he > CDNI interfaces. > > * Long Tail Content: The WG will not continue the work on this > topic inside the WG for now (at least not as a priority item) and will no= t > aim to support something specific for it in first version of the CDNI > interfaces. > > * CDNI Logging: draft-bertrand-cdni-logging is accepted as WG > document > > We will consider these decisions confirmed unless we hear substantiated > objections by 30 Nov. > > Cheers > > Francois & Rich > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > --=20 Best. Bhumip Khasnabish vumip1@gmail.com b.khasnabish@ieee.org bhumip.khasnabish@zteusa.com +1-781-752-8003 (mobile) http://tinyurl.com/bhumip __o _ `\ <, _ .......... ( =95 ) / ( =95 ) ...................... --e0cb4efe33809dca0b04cf0705eb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Thanks Francois ..
=A0
Yes, we'll continue to work on the de-dup draft, and plan to updat= e it
with inputs from other operators for including scenarios like the
ones that Marcin mentioned (use of DRM).
We welcome inputs / feedback / suggestions from others as well.
=A0
For LTC draft, Ramki will contact you, =A0and send further comments/su= ggestions.
=A0
For the Logging draft, do you know why Syslog is not the good
answer for CDNi requirements ?
=A0
Best.
=A0
Bhumip

=A0
On Wed, Nov 21, 2012 at 5:04 AM, Francois Le Fau= cheur (flefauch) <flefauch@cisco.com> wrote:
All,

As documented in the minu= tes, the following decisions were tentatively made at IETF-85:

=A0 = =A0 =A0 =A0 * Content Deduplication: The WG will continue the work on this = topic inside the WG, but will not aim to support it in first version of the= CDNI interfaces.

=A0 =A0 =A0 =A0 * Long Tail Content: The WG will not continue the work = on this topic inside the WG for now (at least not as a priority item) and w= ill not aim to support something specific for it in first version of the CD= NI interfaces.

=A0 =A0 =A0 =A0 * CDNI Logging: draft-bertrand-cdni-logging is accepted= as WG document

We will consider these decisions confirmed unless we= hear substantiated objections by 30 Nov.

Cheers

Francois &am= p; Rich
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://= www.ietf.org/mailman/listinfo/cdni



--
Best.

Bhumip Khasnabish

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 __o
=A0= =A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0 _ `\ <, _
.......... ( =95 ) / ( =95 = ) ......................

--e0cb4efe33809dca0b04cf0705eb-- From ramk@Brocade.com Wed Nov 21 12:47:52 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9507421F8818 for ; Wed, 21 Nov 2012 12:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.906 X-Spam-Level: X-Spam-Status: No, score=-2.906 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTWlU8dum7RN for ; Wed, 21 Nov 2012 12:47:52 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id 0866421F879C for ; Wed, 21 Nov 2012 12:47:51 -0800 (PST) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id qALKlnAe020877; Wed, 21 Nov 2012 12:47:51 -0800 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 18rjkp0s56-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 21 Nov 2012 12:47:50 -0800 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Wed, 21 Nov 2012 12:48:43 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Wed, 21 Nov 2012 12:47:49 -0800 From: ramki Krishnan To: "Francois Le Faucheur (flefauch)" , "cdni@ietf.org" Date: Wed, 21 Nov 2012 12:47:42 -0800 Thread-Topic: Confirming some IETF-85 decisions Thread-Index: AQHNx8+pxDEjRjrDOki2Ny1w43ylTZf0worw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-11-21_04:2012-11-21, 2012-11-20, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1207200000 definitions=main-1211210225 Subject: Re: [CDNi] Confirming some IETF-85 decisions X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 20:47:52 -0000 Dear Francois, We are incorporating the feedback from the meeting (from you, Kevin and oth= ers) in coming up with=20 (a) more information on relevance of LTC (long-tail content ) to CDNI=20 (b) a solution for the LTC problem without any new requirements in the CDNI= interfaces.=20 =20 Our target for the LTC support over CDNI is a best practices draft which pr= ovides guidance to vendors and operators on how to manage LTC deliver effec= tively and efficiently. =20 We expect to send this document out for review in the next 3-4 weeks and re= quest you to continue supporting this as a working group topic. Thanks,=20 Ramki (on behalf of long-tail co-authors) -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Fra= ncois Le Faucheur (flefauch) Sent: Wednesday, November 21, 2012 2:05 AM To: cdni@ietf.org Subject: [CDNi] Confirming some IETF-85 decisions All, As documented in the minutes, the following decisions were tentatively made= at IETF-85: * Content Deduplication: The WG will continue the work on this topic insid= e the WG, but will not aim to support it in first version of the CDNI inter= faces. * Long Tail Content: The WG will not continue the work on this topic insid= e the WG for now (at least not as a priority item) and will not aim to supp= ort something specific for it in first version of the CDNI interfaces. * CDNI Logging: draft-bertrand-cdni-logging is accepted as WG document We will consider these decisions confirmed unless we hear substantiated obj= ections by 30 Nov. Cheers Francois & Rich _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Wed Nov 21 23:55:42 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65AB21F879F for ; Wed, 21 Nov 2012 23:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.577 X-Spam-Level: X-Spam-Status: No, score=-10.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rP0bIUZj3OpA for ; Wed, 21 Nov 2012 23:55:41 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id E04BB21F879C for ; Wed, 21 Nov 2012 23:55:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19294; q=dns/txt; s=iport; t=1353570941; x=1354780541; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=m5QdYsmGems/A7VGGR8vL6kZsAE08+ACAyQfv5cBATE=; b=CaMlZWj+CgvAG4zUf9zhYPYZTqUb1z15mxVy/xgWjl+xS2YUtzBKeEU1 YYz/PoiAl8LEt/YrvLv/5BiKGDbeSwO2OLsnMkRm1xCjlAfc9vSSO0/+B F6rJwAMO6m3QR1xPgBGq5Ha0y9dVKDW/dCL9dRK9e8SUVtzYrWk1Oza1o g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAETZrVCtJXHA/2dsb2JhbABEuREBiQoWc4IeAQEBAwEBAQFrCxACAQgRBAEBAQodBycLFAkIAgQOBQiHfwYLtxeIPYw0g3BhA6ZAgm+CGQ X-IronPort-AV: E=McAfee;i="5400,1158,6903"; a="145176573" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 22 Nov 2012 07:55:40 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qAM7tdId027523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Nov 2012 07:55:39 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.192]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Thu, 22 Nov 2012 01:55:39 -0600 From: "Francois Le Faucheur (flefauch)" To: "B.Khasnabish@ieee.org" Thread-Topic: [CDNi] Acronyms for the CDNI interfaces Thread-Index: AQHNvfsyv+R0Tv5ROk6hOdIj1ufyOpfhNkkAgACw7AD//59c0IAAaSwAgAT2GACAAAiMAIANlT2AgACsrgCAAMXYAA== Date: Thu, 22 Nov 2012 07:55:39 +0000 Message-ID: References: <291CC3F9E50E7641901A54E85D0977C6535F5DB898@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.198] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D255C4Dxmbrcdx10ciscocom_" MIME-Version: 1.0 Cc: "" Subject: Re: [CDNi] Acronyms for the CDNI interfaces X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 07:55:42 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D255C4Dxmbrcdx10ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Bhumip, In my opinion, prepending "CDN" to the proposed acronyms: * is not useful since these acronyms will always be used in the context of = CDNI (and mostly in figures) * is confusing because it suggests these interfaces are generally applicabl= e to "CDNs" when they are applicable to "CDN Interconnection" (i.e. if we w= ere to prepend something it should probably be "CDNI" instead of "CDN") * is going in the opposite direction to the earlier decision to remove the = prepending "C" from all the acronyms (as they were proposed initially e.g. = CCI etc) * is making the acronyms overly long and hard to pronounce So I think we should stick to the acronyms announced below. As a matter of process, in the future I encourage you to try make suggestio= ns early into a discussion, instead of after the chairs send a note aiming = at closing a discussion that seem to have already run its course. Thanks Cheers Francois On 21 Nov 2012, at 21:07, B.Khasnabish@ieee.org wrote: You may also consider the following . * "CDN-CI" for the CDNI Control Interface * "CDN-MI" for the CDNI Metadata distribution Interface * "CDN-LI" for the CDNI Logging Interface * "CDN-RI" for the CDNI request routing/Redirection Interface * "CDN-FCI" for the CDNI request routing/Footprint & Capabilities adv= ertisement Interface Thanks for considering these Francois .. Best. Bhumip On Wed, Nov 21, 2012 at 4:49 AM, Francois Le Faucheur (flefauch) > wrote: All, So Just to close on that one. I believe we have an agreement for the following: * "CI" for the CDNI Control Interface * "MI" for the CDNI Metadata distribution Interface * "LI" for the CDNI Logging Interface * "RI" for the CDNI request routing/Redirection Interface * "FCI" for the CDNI request routing/Footprint & Capabilities adverti= sement Interface * no acronym defined for the umbrella "Request Routing Interface" * avoid using the umbrella term of "Request Routing Interface" and in= stead use the specific terms of "CDNI request routing/Redirection Interface= (RI)" and "CDNI request routing/Footprint & Capabilities advertisement Int= erface (FCI)" To all CDNI I-Ds editors, Please reflect the above agreement in all open Internet-Drafts. Francois On 12 Nov 2012, at 19:24, Francois Le Faucheur (flefauch) wrote: > > On 12 Nov 2012, at 18:53, Peterson, Larry wrote: > >> I'm good with these, but in working through the framework >> document, I note that we also make significant reference to >> the generic Request Routing Interface. While we could add >> RRI to the set, and then fully qualify the two sub-interfaces >> (i.e., RR/RI and RR/FCI), I propose instead to stick with RI >> and FCI, and just not use an acronym for the generic Request >> Routing Interface. (For me, the main value of the acronyms >> is in the figures, and we never need RRI.) > > First, I agree with not having an acronym for the Request Routing Interfa= ce. > > Secondly, as the "CDNI request routing/Redirection Interface" and "CDNI r= equest routing/Footprint & Capabilities advertisement Interface" are firmin= g up, there is probably less and less rationale for even referring to the R= equest Routing Interface per say. At the beginning we were not sure whether= the two components would be realized with one or two interfaces so we bund= led the two functions under the term Request Routing Interface, but now tha= t we are quite clear that they will be realized separately, we can probably= always refer to RI and FCI specifically. > > So, with respect to the Framework, I'd suggest: > * explaining early in the document that the Request Routing Interfa= ce is a logical grouping of RI and FCI, because the two relate to enabling = request routing > * then, whenever possible, only use the terms "CDNI request routing= /Redirection Interface" and "CDNI request routing/Footprint & Capabilities = advertisement Interface". And when you want to refer to both, then just lis= t them both (instead of using "Request Routing Interface") either using the= full name or the acronym. > > Makes sense? > > Francois > >> >> Larry >> >> >> On Nov 9, 2012, at 9:07 AM, Francois Le Faucheur (flefauch) wrote: >> >>> Works for me. So latest proposal on the table is: >>> >>> * CI, MI, LI, RI, FCI >>> >>> >>> PS: and no, the "I" is not superfluous 8^) >>> >>> On 9 Nov 2012, at 14:58, Kevin J Ma wrote: >>> >>>> The "C" is somewhat superfluous? We could drop all the "C"s. >>>> CI, MI, LI, RI, and FI? >>>> >>>> And, at the risk of opening a rat hole, "FI" seems to imply >>>> that footprint is more important than capabilities... :) >>>> "FCI"? >>>> >>>> From: cdni-bounces@ietf.org [mailto:cdni= -bounces@ietf.org] On Behalf Of Francois Le F= aucheur (flefauch) >>>> Sent: Friday, November 09, 2012 8:37 AM >>>> To: B.Khasnabish@ieee.org >>>> Cc: cdni@ietf.org >>>> Subject: Re: [CDNi] Acronyms for the CDNI interfaces >>>> >>>> >>>> On 9 Nov 2012, at 04:03, B.Khasnabish@ieee.org wrote: >>>> >>>> >>>> Hi Francois, >>>> >>>> Thanks. This is a good start. >>>> >>>> As you know, "CLI" is widely used for "Command Line Interface," >>>> (http://en.wikipedia.org/wiki/Command-line_interface) >>>> so let us consider something different for "CDNI Logging Interface"=85 >>>> >>>> "CLoI" ? >>>> >>>> >>>> >>>> Best. >>>> >>>> Bhumip >>>> >>>> >>>> >>>> On Thu, Nov 8, 2012 at 4:51 PM, Francois Le Faucheur (flefauch) > wrote: >>>> Folks, >>>> >>>> As discussed during the Atlanta meeting, we need to agree on a set of = acronyms to designate the CDNI interfaces consistently across documents (pa= rticularly in figures where the full name cannot be used). >>>> >>>> A base proposal is: >>>> * "CCI" for the CDNI Control Interface >>>> * "CMI" for the CDNI Metadata distribution Interface >>>> * "CLI" for the CDNI Logging Interface >>>> * "CRI" for the CDNI request routing/Redirection Interface >>>> * "CFI" for the CDNI request routing/Footprint & capabilities ad= vertisement Interface. >>>> >>>> Let us know if you see issues with that, or if you want to offer a bet= ter proposal. >>>> >>>> Cheers >>>> >>>> Francois >>>> >>>> PS: some of the acronyms above probably conflict with some acronyms yo= u've already encountered somewhere else before, but those don't seem to be = major conflict, and it'd be nice to stick to short acronyms. >>>> _______________________________________________ >>>> CDNi mailing list >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni >>>> >>>> >>>> >>>> >>>> >>> >>> >> > _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC236DA6F2DA77449EF2D02DF4471A8D255C4Dxmbrcdx10ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2F9AF20208A1DA4DA9C8EF45353D1054@cisco.com> Content-Transfer-Encoding: quoted-printable Hi Bhumip,

In my opinion, prepending "CDN" to the proposed acronym= s:
* is n= ot useful since these acronyms will always be used in the context of CDNI (= and mostly in figures)
* is c= onfusing because it suggests these interfaces are generally applicable to &= quot;CDNs" when they are applicable to "CDN Interconnection"= (i.e. if we were to prepend something it should probably be "CDNI" instead of "CDN")
* is g= oing in the opposite direction to the earlier decision to remove the prepen= ding "C" from all the acronyms (as they were proposed initially e= .g. CCI etc)
* is m= aking the acronyms overly long and hard to pronounce
So I think we should stick to the acronyms announced below.

As a matter of process, in the future I encourage you to try make sugg= estions early into a discussion, instead of after the chairs send a note ai= ming at closing a discussion that seem to have already run its course.

Thanks

Cheers

Francois

On 21 Nov 2012, at 21:07, B.K= hasnabish@ieee.org wrote:

You may also consider the following .
 
      * "CDN-CI" for the CDNI Contr= ol Interface

      * "CDN-MI" for the CDNI Metadata d= istribution Interface
      * "CDN-LI" for the CDNI Loggi= ng Interface
      * "CDN-RI" for the CDNI reque= st routing/Redirection Interface
      * "CDN-FCI" for the CDNI requ= est routing/Footprint & Capabilities advertisement Interface

 
Thanks for considering these Francois ..
 
Best.
 
Bhumip


 
On Wed, Nov 21, 2012 at 4:49 AM, Francois Le Fau= cheur (flefauch) <flefauch@cisco.com> wrote:
All,

So Just to close on that one.
I believe we have an agreement for the following:

      * "CI" for the CDNI Control Interface
      * "MI" for the CDNI Metadata distribution In= terface
      * "LI" for the CDNI Logging Interface
      * "RI" for the CDNI request routing/Redirect= ion Interface
      * "FCI" for the CDNI request routing/Footpri= nt & Capabilities advertisement Interface
      * no acronym defined for the umbrella "Request Ro= uting Interface"
      * avoid using the umbrella term of "Request Routi= ng Interface" and instead use the specific terms of "CDNI request= routing/Redirection Interface (RI)" and "CDNI request routing/Fo= otprint & Capabilities advertisement Interface (FCI)"


To all CDNI I-Ds editors,
Please reflect the above agreement in all open Internet-Drafts.

Francois

On 12 Nov 2012, at 19:24, Francois Le Faucheur (flefauch) wrote:

>
> On 12 Nov 2012, at 18:53, Peterson, Larry wrote:
>
>> I'm good with these, but in working through the framework
>> document, I note that we also make significant reference to
>> the generic Request Routing Interface. While we could add
>> RRI to the set, and then fully qualify the two sub-interfaces
>> (i.e., RR/RI and RR/FCI), I propose instead to stick with RI
>> and FCI, and just not use an acronym for the generic Request
>> Routing Interface. (For me, the main value of the acronyms
>> is in the figures, and we never need RRI.)
>
> First, I agree with not having an acronym for the Request Routing Inte= rface.
>
> Secondly, as the "CDNI request routing/Redirection Interface"= ; and "CDNI request routing/Footprint & Capabilities advertisement= Interface" are firming up, there is probably less and less rationale = for even referring to the Request Routing Interface per say. At the beginning we were not sure whether the two components would be real= ized with one or two interfaces so we bundled the two functions under the t= erm Request Routing Interface, but now that we are quite clear that they wi= ll be realized separately, we can probably always refer to RI and FCI specifically.
>
> So, with respect to the Framework, I'd suggest:
>       * explaining early in the document that the Reque= st Routing Interface is a logical grouping of RI and FCI, because the two r= elate to enabling request routing
>       * then, whenever possible, only use the terms &qu= ot;CDNI request routing/Redirection Interface" and "CDNI request = routing/Footprint & Capabilities advertisement Interface". And whe= n you want to refer to both, then just list them both (instead of using &qu= ot;Request Routing Interface") either using the full name or the acronym.
>
> Makes sense?
>
> Francois
>
>>
>> Larry
>>
>>
>> On Nov 9, 2012, at 9:07 AM, Francois Le Faucheur (flefauch) wrote:=
>>
>>> Works for me. So latest proposal on the table is:
>>>
>>> * CI, MI, LI, RI, FCI
>>>
>>>
>>> PS: and no, the "I" is not superfluous 8^)
>>>
>>> On 9 Nov 2012, at 14:58, Kevin J Ma wrote:
>>>
>>>> The "C" is somewhat superfluous?  We could = drop all the "C"s.
>>>> CI, MI, LI, RI, and FI?
>>>>
>>>> And, at the risk of opening a rat hole, "FI" see= ms to imply
>>>> that footprint is more important than capabilities... &nbs= p;:)
>>>> "FCI"?
>>>>
>>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Francois L= e Faucheur (flefauch)
>>>> Sent: Friday, November 09, 2012 8:37 AM
>>>> To: B.Khasnabish@ieee.org
>>>> Cc: cdn= i@ietf.org
>>>> Subject: Re: [CDNi] Acronyms for the CDNI interfaces
>>>>
>>>>
>>>> On 9 Nov 2012, at 04:03, B.Khasnabish@ieee.org wrote:
>>>>
>>>>
>>>> Hi Francois,
>>>>
>>>> Thanks. This is a good start.
>>>>
>>>> As you know, "CLI" is widely used for "Comm= and Line Interface,"
>>>> (http://en.wikipedia.org/wiki/Command-line_interfac= e)
>>>> so let us consider something different for "CDNI Logg= ing Interface"=85
>>>>
>>>> "CLoI" ?
>>>>
>>>>
>>>>
>>>> Best.
>>>>
>>>> Bhumip
>>>>
>>>>
>>>>
>>>> On Thu, Nov 8, 2012 at 4:51 PM, Francois Le Faucheur (flef= auch) <flefauch@= cisco.com> wrote:
>>>> Folks,
>>>>
>>>> As discussed during the Atlanta meeting, we need to agree = on a set of acronyms to designate the CDNI interfaces consistently across d= ocuments (particularly in figures where the full name cannot be used).
>>>>
>>>> A base proposal is:
>>>>       * "CCI" for the CDNI Contro= l Interface
>>>>       * "CMI" for the CDNI Metada= ta distribution Interface
>>>>       * "CLI" for the CDNI Loggin= g Interface
>>>>       * "CRI" for the CDNI reques= t routing/Redirection Interface
>>>>       * "CFI" for the CDNI reques= t routing/Footprint & capabilities advertisement Interface.
>>>>
>>>> Let us know if you see issues with that, or if you want to= offer a better proposal.
>>>>
>>>> Cheers
>>>>
>>>> Francois
>>>>
>>>> PS: some of the acronyms above probably conflict with some= acronyms you've already encountered somewhere else before, but those don't= seem to be major conflict, and it'd be nice to stick to short acronyms. >>>> _______________________________________________
>>>> CDNi mailing list
>>>> CDNi@ie= tf.org
>>>> https://www.ietf.org/mailman/listinfo/cdni
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> <ATT00001.c>
>>
>

_______________________________________________
CDNi mailing list
CDNi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cdni



 

--_000_FC236DA6F2DA77449EF2D02DF4471A8D255C4Dxmbrcdx10ciscocom_-- From flefauch@cisco.com Thu Nov 22 00:10:36 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C92C21F884A for ; Thu, 22 Nov 2012 00:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.077 X-Spam-Level: X-Spam-Status: No, score=-10.077 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPRtY7FcToyV for ; Thu, 22 Nov 2012 00:10:35 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B780A21F8753 for ; Thu, 22 Nov 2012 00:10:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8877; q=dns/txt; s=iport; t=1353571834; x=1354781434; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Aqh0Eo2e9Ha1VvxZdOG8/LUFrYP75z1pFWuk+MDghFI=; b=GzgcAeN6u3LgBpu62pR38jW5wdbEOomvxpgTPQedXT/usj4XS9Vor6x4 ZPGvnVT8IjvSLMOBaOGjRBz15kfMpRXcMZICCuOwdCyD/J9giDcf4kxY/ 2JTLJ7SBreBw/ci+x4zbDNAe8Loi5DOQp0Wm/41V4rBbxDcLZgxmXp2eN k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAEjdrVCtJXG//2dsb2JhbABBA7kSiQoWc4IfAQEEAQEBawsQAgEIIh0HIQYLFBECBAENBQiHcwMPC7V2DYlUi0tpgSWCS2EDkk2BXYJxihYDhQyCb4IZ X-IronPort-AV: E=McAfee;i="5400,1158,6903"; a="145137966" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 22 Nov 2012 08:10:32 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAM8AW5o025391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Nov 2012 08:10:32 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.192]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Thu, 22 Nov 2012 02:10:32 -0600 From: "Francois Le Faucheur (flefauch)" To: "B.Khasnabish@ieee.org Khasnabish" , Larry Peterson Thread-Topic: [CDNi] Confirming some IETF-85 decisions Thread-Index: AQHNx8+pxDEjRjrDOki2Ny1w43ylTZf1Hw8AgADHkwA= Date: Thu, 22 Nov 2012 08:10:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.198] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D255D9Cxmbrcdx10ciscocom_" MIME-Version: 1.0 Cc: "" Subject: Re: [CDNi] Confirming some IETF-85 decisions X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 08:10:36 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D255D9Cxmbrcdx10ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Bhumip, On 21 Nov 2012, at 21:16, B.Khasnabish@ieee.org wrote: Thanks Francois .. Yes, we'll continue to work on the de-dup draft, and plan to update it with inputs from other operators for including scenarios like the ones that Marcin mentioned (use of DRM). Good. Larrry, I also suggest that the cdni-framework document incorporates one pa= ragraph about the concept of content deduplication; something to simply int= roduce the notion that the exact _same content item from the same content p= rovider_ may end-up being handled by a given CDN through multiple CDN paths= and therefore that this can be handled by EITHER handling each instance se= parately OR by extra control plane smartness to correlate the multiple inst= ances in order to optimize the handling of the multiple instances (e.g. de-= deuplicate content). We welcome inputs / feedback / suggestions from others as well. For LTC draft, Ramki will contact you, and send further comments/suggestio= ns. For the Logging draft, do you know why Syslog is not the good answer for CDNi requirements ? As noted in the slides presented by Emile about the cdni-logging I-D: " =96 Key decisions remaining need WG input and control: =95 Refining of the data model =95 SelecRon of the Logging protocol =95 SelecRon of the mandatory fields and records " the selection of a logging protocol has not been made yet and Syslog is in = the list of candidates. The next version of the draft will start introduce considerations and requi= rements (scaling, reliability,=85) in view of facilitating this discussion. Input on pros&cons of using Syslog (or other candidate protocols) for CDNI = logging is welcome. Francois Best. Bhumip On Wed, Nov 21, 2012 at 5:04 AM, Francois Le Faucheur (flefauch) > wrote: All, As documented in the minutes, the following decisions were tentatively made= at IETF-85: * Content Deduplication: The WG will continue the work on this topi= c inside the WG, but will not aim to support it in first version of the CDN= I interfaces. * Long Tail Content: The WG will not continue the work on this topi= c inside the WG for now (at least not as a priority item) and will not aim = to support something specific for it in first version of the CDNI interface= s. * CDNI Logging: draft-bertrand-cdni-logging is accepted as WG docum= ent We will consider these decisions confirmed unless we hear substantiated obj= ections by 30 Nov. Cheers Francois & Rich _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni -- Best. Bhumip Khasnabish vumip1@gmail.com b.khasnabish@ieee.org bhumip.khasnabish@zteusa.com +1-781-752-8003 (mobile) http://tinyurl.com/bhumip __o _ `\ <, _ .......... ( =95 ) / ( =95 ) ...................... --_000_FC236DA6F2DA77449EF2D02DF4471A8D255D9Cxmbrcdx10ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5734C9FA0489F84E84C7A54860FBC313@cisco.com> Content-Transfer-Encoding: quoted-printable Hi Bhumip,

On 21 Nov 2012, at 21:16, B.K= hasnabish@ieee.org wrote:

Thanks Francois ..
 
Yes, we'll continue to work on the de-dup draft, and plan to update it=
with inputs from other operators for including scenarios like the
ones that Marcin mentioned (use of DRM).

Good.

Larrry, I also suggest that the cdni-framework document incorporates o= ne paragraph about the concept of content deduplication; something to simpl= y introduce the notion that the exact _same content item from the same cont= ent provider_ may end-up being handled by a given CDN through multiple CDN paths and therefore that this can be h= andled by EITHER handling each instance separately OR by extra control plan= e smartness to correlate the multiple instances in order to optimize the ha= ndling of the multiple instances (e.g. de-deuplicate content).


We welcome inputs / feedback / suggestions from others as well.
 
For LTC draft, Ramki will contact you,  and send further comments= /suggestions.
 
For the Logging draft, do you know why Syslog is not the good
answer for CDNi requirements ?

As noted in the slides presented by Emile about the cdni-logging I-D:<= /div>
"
=96 Key decisions remaining need WG input and control: 
=95 Refining of the data model
=95 SelecRon of the Logging protocol
=95 SelecRon of the mandatory fields and records
"
the selection of a logging protocol has not been made yet and Syslog i= s in the list of candidates.
The next version of the draft will start introduce considerations and = requirements (scaling, reliability,=85) in view of facilitating this discus= sion.
Input on pros&cons of using Syslog (or other candidate protocols) = for CDNI logging is welcome.

Francois


 
Best.
 
Bhumip

 
On Wed, Nov 21, 2012 at 5:04 AM, Francois Le Fau= cheur (flefauch) <flefauch@cisco.com> wrote:
All,

As documented in the minutes, the following decisions were tentatively made= at IETF-85:

        * Content Deduplication: The WG will continue t= he work on this topic inside the WG, but will not aim to support it in firs= t version of the CDNI interfaces.

        * Long Tail Content: The WG will not continue t= he work on this topic inside the WG for now (at least not as a priority ite= m) and will not aim to support something specific for it in first version o= f the CDNI interfaces.

        * CDNI Logging: draft-bertrand-cdni-logging is = accepted as WG document

We will consider these decisions confirmed unless we hear substantiated obj= ections by 30 Nov.

Cheers

Francois & Rich
_______________________________________________
CDNi mailing list
CDNi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cdni



--
Best.

Bhumip Khasnabish

            &nb= sp;      __o
             _ `\ &l= t;, _
.......... ( =95 ) / ( =95 ) ......................


--_000_FC236DA6F2DA77449EF2D02DF4471A8D255D9Cxmbrcdx10ciscocom_-- From flefauch@cisco.com Thu Nov 22 00:38:36 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663FC21F8629 for ; Thu, 22 Nov 2012 00:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.579 X-Spam-Level: X-Spam-Status: No, score=-10.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6qnUCYpbKos for ; Thu, 22 Nov 2012 00:38:35 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1206D21F8626 for ; Thu, 22 Nov 2012 00:38:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2949; q=dns/txt; s=iport; t=1353573515; x=1354783115; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ZxhYB1Vkq7fJ3c8CVosCCgL2WAvSCRma3jB+xAgWk4Y=; b=CySWBsZs7P4hHGWbFd6C6AyNanlzTNLUWrI6l8SAsbHTBiAAHDp3PLmN ozg1H+50oSqnHlCjap6G6OHMcZ5Z56to6aDEvpl+uujB3W0x5EM8HGUc/ yRlunCUAYzHEkyDQBMZLEKnGhAbQwLtKjLL3hxjScNuj2DlIYASJMKBfG Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKfirVCtJXG9/2dsb2JhbABEwhwWc4IeAQEBBCdSEAIBCBgKJDIlAgQOBQiIBb9kjDQhg09hA6ZAgm+BXB8e X-IronPort-AV: E=McAfee;i="5400,1158,6903"; a="145144539" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 22 Nov 2012 08:38:34 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qAM8cYi1015777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Nov 2012 08:38:34 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.192]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.001; Thu, 22 Nov 2012 02:38:34 -0600 From: "Francois Le Faucheur (flefauch)" To: "B.Khasnabish@ieee.org Khasnabish" Thread-Topic: [CDNi] Confirming some IETF-85 decisions Thread-Index: AQHNx8+pxDEjRjrDOki2Ny1w43ylTZf1Hw8AgADPaYA= Date: Thu, 22 Nov 2012 08:38:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.198] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [CDNi] Confirming some IETF-85 decisions X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 08:38:36 -0000 Bhumip, On 21 Nov 2012, at 21:16, B.Khasnabish@ieee.org wrote: >=20 > Yes, we'll continue to work on the de-dup draft, and plan to update it > with inputs from other operators for including scenarios like the > ones that Marcin mentioned (use of DRM). > We welcome inputs / feedback / suggestions from others as well. One input as an individual: There are situations where the "same content from the same content provider= " ends up being handled by a given CDN via more than one CDN-path (i.e. con= tent Cx from CSPa distributed CSPa-->uCDN1--->dCDN and also distributed CSP= a-->uCDN2-->dCDN), and therefore may be referenced by different URIs in tha= t given CDN (dCDN) and therefore appears as different content. I believe th= e occurrence of that situation is well understood and it is clear that one = could optimize that scenario by extra control plane smartness (e.g. to de-d= eduplicate content storage). During the Atlanta discussion, it seemed to me that some people just assume= d that if the same "content" is distributed by different CSPs (i.e. LatestB= lockbuster.mp4 is distributed by CSPa and CSPb) then it can be de-duplicate= d. I haven't thought extremely hard about that, but my gut reaction is that= we absolutely do not want to perform de-duplication in that scenario. Whil= e we may have two representations of the same "movie", each CSP representat= ion ought to be considered as the individual CSP asset. If CSPa uses a poor= encoder for the given content, I am not sure CSPb would be happy to have t= hat copy of content streamed to his end-users. If CSPb makes a mistake and = places the wrong content in his origin server, I am not sure CSPa would be = happy to have that copy of content streamed to his end-users. As pointed by= Marcin, it is also not possible to deduplicate anyways when DRM is used ov= er the content.=20 (note that I am keeping outside of the discussion potential low level oppor= tunistic content deduplication mechanisms that might be performed by a cach= e that notices that two blocks of apparently independent files happen to be= exactly identical) Whether you include the latter scenarios (i.e. LatestBlockbuster.mp4 distri= buted by CSPa and CSPb), or not, in your estimation of "content-duplication= " opportunities radically affect the figures you will come up with. I suspe= ct this partly explains the disconnect between your figures and Marcin. Do we agree that the former scenarios (Cx from CSPa distributed CSPa-->uCDN= 1--->dCDN and also distributed CSPa-->uCDN2-->dCDN) are a clear opportunity= for content-deduplication? Have you made an analysis of the latter scenarios (i.e. LatestBlockbuster.m= p4 distributed by CSPa and CSPb) and do you feel these scenarios should be = in scope of the CDNI content de-duplication mechanism? If yes, can you please comment on the few issues I brought up above? Cheers Francois From flefauch@cisco.com Thu Nov 22 07:20:05 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817FF21F891F for ; Thu, 22 Nov 2012 07:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.351 X-Spam-Level: X-Spam-Status: No, score=-10.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBNB16Ln4-Ka for ; Thu, 22 Nov 2012 07:20:04 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id BBEE221F84C9 for ; Thu, 22 Nov 2012 07:20:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=326; q=dns/txt; s=iport; t=1353597604; x=1354807204; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=+J7lyKVfo8b4fQW+lIcDMJFV0EmA5fpq/X/Rb3Ytcvs=; b=PLDSQLTa6gbmq4mBpEETulzh7qRW/BYgjS1oIF7wReBgbiQU6f2pdjlB H4Zm630Cee4oO35aPCFPkdfzfGwq5r6AA1F75EfiFGjbmHvtDdM1nVQBJ FDsM/dZWM2f0eLR6Am6gYqXmQcFQEwhs+OaTwgILvtjcm5T6Px+odf/yO k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAB5CrlCtJV2c/2dsb2JhbAA6CsIeFnOCIAEEJxM/EgEqFEInBAENDYgFwEaCRooCg19hA6ZDgm+CHQ X-IronPort-AV: E=McAfee;i="5400,1158,6903"; a="145217534" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 22 Nov 2012 15:20:04 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qAMFK4a4025615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Nov 2012 15:20:04 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.192]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.001; Thu, 22 Nov 2012 09:20:04 -0600 From: "Francois Le Faucheur (flefauch)" To: STEPHAN OLNC/OLN Emile , "BERTRAND OLNC/OLN Gilles" Thread-Topic: Requirement for CDNI Logs in uCDN --> dCDN direction? Thread-Index: AQHNyMTYyBisXxM+yEa+s6VodqnvHA== Date: Thu, 22 Nov 2012 15:20:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.198] Content-Type: text/plain; charset="us-ascii" Content-ID: <54460EB0FA672449B1FDCB7A356C17F3@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: [CDNi] Requirement for CDNI Logs in uCDN --> dCDN direction? X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 15:20:05 -0000 Emile, Gilles, In Atlanta, there was some non-conclusive discussion on whether or not ther= e was a strong enough requirement for passing CDNI Logging information from= uCDN to dCDN. Could you identify examples of CDNI Logging information that one may want t= o communicate from uCDN to dCDN? Thanks Francois From jeroen.famaey@intec.ugent.be Fri Nov 23 05:27:08 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184CC21F8570 for ; Fri, 23 Nov 2012 05:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.109 X-Spam-Level: X-Spam-Status: No, score=-5.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fh7m92gFFwbU for ; Fri, 23 Nov 2012 05:27:04 -0800 (PST) Received: from smtp1.ugent.be (smtp1.ugent.be [157.193.71.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD9B21F8514 for ; Fri, 23 Nov 2012 05:27:02 -0800 (PST) Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp1.ugent.be (Postfix) with ESMTP id BFAA68520; Fri, 23 Nov 2012 14:27:01 +0100 (CET) X-Virus-Scanned: by UGent DICT Received: from smtp1.ugent.be ([157.193.71.182]) by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id k-10K_nyTwCL; Fri, 23 Nov 2012 14:26:57 +0100 (CET) Received: from mail2.intec.ugent.be (mail2.intec.ugent.be [157.193.214.245]) by smtp1.ugent.be (Postfix) with ESMTP id AA472845E; Fri, 23 Nov 2012 14:26:57 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail2.intec.ugent.be (Postfix) with ESMTP id 8361B1F; Fri, 23 Nov 2012 14:26:57 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at intec.ugent.be Received: from mail2.intec.ugent.be ([127.0.0.1]) by localhost (mail2.intec.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ewt2I2ASwzq; Fri, 23 Nov 2012 14:26:57 +0100 (CET) Received: from [192.168.126.12] (vpn-zp-126-12.vpn [192.168.126.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jfamaey) by mail2.intec.ugent.be (Postfix) with ESMTPSA id 223BA1E; Fri, 23 Nov 2012 14:26:57 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_485049A4-9007-4C58-971F-E87989E2E435" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jeroen Famaey In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6535F6910DD@MAILR002.mail.lan> Date: Fri, 23 Nov 2012 14:26:56 +0100 Message-Id: References: <83440700-EEF7-4738-BA59-083AB4B2ED4E@intec.ugent.be> <291CC3F9E50E7641901A54E85D0977C6535F6910DD@MAILR002.mail.lan> To: Kevin J Ma X-Mailer: Apple Mail (2.1499) X-Miltered: at jchkm3 with ID 50AF79A1.002 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 50AF79A1.002 from mail2.intec.ugent.be/mail2.intec.ugent.be/157.193.214.245/mail2.intec.ugent.be/ X-j-chkmail-Score: MSGID : 50AF79A1.002 on smtp1.ugent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: "cdni@ietf.org" Subject: Re: [CDNi] New draft submitted draft-famaey-cdni-has-experiments-00 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 13:27:08 -0000 --Apple-Mail=_485049A4-9007-4C58-971F-E87989E2E435 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Kevin, Thanks for the feedback. We will definitely take this into account for = the next version of the draft. I've included my responses inline. > Hi Jeroen, > =20 > I read through the draft. It seems that it essentially shows the > upper bound on the encoded bitrate somewhere along the lines of: > =20 > B * (SD - (4 * D + C)) / SD > =20 > where SD is the segment duration, in this case 2 seconds, > 4 * D is the two WAN RTTs required for the redirect, and > C is the overhead of the access network latency plus the > processing delay for the redirect messages? That is indeed the case for content that is located upstream, in the = case of the Upstream policy. If the content is located downstream, or = one of the other redirection policies is used, this upper bound would be = different. > =20 > Certainly with HTTP adaptive protocols, it is the case that as > the RTT approaches SD, the viable encoded bitrate goes to zero, > even without redirects. It is a primary reason for using SD =3D 10 > with HLS and presumably why the native SS client seems to just > automatically use the redirect target for its subsequent requests. Using a higher SD indeed reduces the problems related to high RTT. = However, there are some downsides to increasing the SD as well. For = example, the bitrate adaptation algorithm will be able to react more = slowly, reducing optimality and the ability to adapt to changing network = conditions. Also, automatically switching to the redirect target for = subsequent requests might pose problems in CDN interconnection = scenario's, where subsequent segments may be located on different = servers, or even within different administrative domains. As such, we = believe it's also necessary to look into other techniques, including = manifest rewriting (which was addressed in the draft). > =20 > Pressumably the experiment is for a VoD scenario, i.e., all the > segments are immediately available for download? (Live delivery > poses other issues...) If the content provider selects a suitably > large SD to try to protect against the worst case scenario, the > impact to average encoded bitrate is probably less dramatic? This is true, we will consider varying the SD and reporting results on = that as well. > =20 > While I agree that there is higher probability of the inter-CDN > link having higher latency than the access network, there are > plenty of bad access networks out there. I was wondering if > the selected values for "per-client bandwidth B" were designed > to reflect any specific access network deployment scenarios? We currently have new results where we also looked at different = conditions within the access network (varying latencies and varying = client bandwidth). We are planning to report these in future versions = of the draft. > =20 > Selecting the "best" CDN to deliver the content (in this case > lowest latency request router, though, it works for other cases, > e.g., cheapest CDN) and sticking with it certainly has its > advantages. Is the intent of the draft just to support the > concept of manifest rewrite, or are there specific redirctions > or rewrite mechanisms that it would like to propose? Currently, our goal is to show the general advantages of more optimized = redirection mechanisms (that reduce the number of necessary redirects), = which can be achieved by some form of manifest rewriting. We have not = considered specific mechanisms as of yet. > =20 > thanx. > =20 > -- Kevin J. Ma Kind regards, Jeroen -- Dr. Jeroen Famaey Department of Information Technology Internet Based Communication Networks and Services (IBCN) Ghent University - iMinds Gaston Crommenlaan 8 (Bus 201), B-9050 Gent, Belgium T: +32 9 33 14938; T Secr: +32 (0)9 33 14900 F: +32 9 33 14899 E: jeroen.famaey@intec.UGent.be W: http://users.ugent.be/~jfamaey W: http://www.ibcn.intec.UGent.be=20 --Apple-Mail=_485049A4-9007-4C58-971F-E87989E2E435 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello = Kevin,

Thanks for the feedback.  We will = definitely take this into account for the next version of the draft. =  I've included my responses = inline.

Hi = Jeroen,
  I read through the = draft.  It seems that it essentially shows = the
  upper = bound on the encoded bitrate somewhere along the lines = of:
    B * (SD - (4 * D = + C)) / SD
  where SD is the segment = duration, in this case 2 seconds,
  4 * D is the two WAN RTTs required for the = redirect, and
  C = is the overhead of the access network latency plus = the
  = processing delay for the redirect = messages?
That is indeed the case = for content that is located upstream, in the case of the Upstream = policy.  If the content is located downstream, or one of the other = redirection policies is used, this upper bound would be = different.
 
  = Certainly with HTTP adaptive protocols, it is the case that = as
  the RTT = approaches SD, the viable encoded bitrate goes to = zero,
  even = without redirects.  It is a primary reason for using SD =3D = 10
  with HLS = and presumably why the native SS client seems to = just
  = automatically use the redirect target for its subsequent = requests.
Using a higher SD indeed = reduces the problems related to high RTT.  However, there are some = downsides to increasing the SD as well.  For example, the bitrate = adaptation algorithm will be able to react more slowly, reducing = optimality and the ability to adapt to changing network conditions. =  Also, automatically switching to the redirect target for = subsequent requests might pose problems in CDN interconnection = scenario's, where subsequent segments may be located on different = servers, or even within different administrative domains.  As such, = we believe it's also necessary to look into other techniques, including = manifest rewriting (which was addressed in the draft).
  Pressumably the experiment is = for a VoD scenario, i.e., all the
  segments are immediately available for = download?  (Live delivery
  poses other issues...)  If the content = provider selects a suitably
  impact to = average encoded bitrate is probably less = dramatic?
This is true, we will = consider varying the SD and reporting results on that as = well.
 
  = While I agree that there is higher probability of the = inter-CDN
  link = having higher latency than the access network, there = are
  plenty of = bad access networks out there.  I was wondering = if
  the = selected values for "per-client bandwidth B" were = designed
  to = reflect any specific access network deployment = scenarios?
We currently have new = results where we also looked at different conditions within the access = network (varying latencies and varying client bandwidth).  We are = planning to report these in future versions of the draft.
  Selecting the "best" CDN to = deliver the content (in this case
  lowest latency request router, though, it works = for other cases,
  = e.g., cheapest CDN) and sticking with it certainly has = its
  = advantages.  Is the intent of the draft just to support = the
  concept = of manifest rewrite, or are there specific = redirctions
  = or rewrite mechanisms that it would like to = propose?
Currently, our goal is to = show the general advantages of more optimized redirection mechanisms = (that reduce the number of necessary redirects), which can be achieved = by some form of manifest rewriting.  We have not considered = specific mechanisms as of yet.
thanx.
 
--  = Kevin J. = Ma

Kind = regards,
Jeroen

--
Dr. Jeroen Famaey
Department of Information = Technology
Internet Based Communication Networks and Services = (IBCN)
Ghent University - iMinds
Gaston Crommenlaan 8 (Bus 201), = B-9050 Gent, Belgium
T: +32 9 33 14938; T Secr: +32 (0)9 33 = 14900
F: +32 9 33 14899
E: jeroen.famaey@intec.UGent.be<= /a>
W: http://users.ugent.be/~jfamaey=
W: http://www.ibcn.intec.UGent.be=  
= --Apple-Mail=_485049A4-9007-4C58-971F-E87989E2E435-- From gilles.bertrand@orange.com Mon Nov 26 02:17:14 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08EA321F8687 for ; Mon, 26 Nov 2012 02:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LiV34TtV8cZR for ; Mon, 26 Nov 2012 02:17:13 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 17A1021F854B for ; Mon, 26 Nov 2012 02:17:12 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 6A9B62DC141; Mon, 26 Nov 2012 11:17:11 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id F3A794C06C; Mon, 26 Nov 2012 11:17:10 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Mon, 26 Nov 2012 11:17:09 +0100 From: To: "Francois Le Faucheur (flefauch)" , "STEPHAN Emile OLNC/OLN" Thread-Topic: Requirement for CDNI Logs in uCDN --> dCDN direction? Thread-Index: AQHNyMTYyBisXxM+yEa+s6VodqnvHJf73aFg Date: Mon, 26 Nov 2012 10:17:08 +0000 Message-ID: <4226_1353925031_50B341A7_4226_22_3_c01ce20a-23f8-4cc5-be00-4bf39f1fd0db@PEXCVZYH02.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: "" Subject: Re: [CDNi] Requirement for CDNI Logs in uCDN --> dCDN direction? X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 10:17:14 -0000 Hi Fran=E7ois, There are several use cases for providing Logging information from uCDN to = dCDN. The main ones are: - debugging - security auditing Quite often, both dCDN and uCDN have partial information about an event, an= d want to compare this information. For instance, if uCDN complains that ma= ny client requests are not served, such comparison helps establishing where= the problem is located and who is responsible for that. In this case, the = dCDN may for instance request the uCDN Logging information related to the H= TTP redirection from uCDN to dCDN and compare this information to its own c= ontent delivery logs.=20 Another example: if content acquisition does not work, the dCDN knows which= requests it has sent and the uCDN knows which ones it has received, as wel= l as what error may have occurred during the processing of these requests. = The dCDN may request uCDN's content acquisition Logging data and compare it= to its own content acquisition logs. Note that the need of supporting logging exchanges from uCDN to dCDN is one= among several arguments in favor of using CI interface for Logging control: [http://tools.ietf.org/html/draft-bertrand-cdni-logging-02#page-8] " The rationale for using the Control interface for Logging Control (instead of for instance using the Metadata interface) includes: o the Logging Control interactions typically define fairly static information for initializing and controlling the Logging interface, which matches the role of the Control Interface as described in [I-D.ietf-cdni-framework] and [RFC6707]. o the Logging Control information (specifying the Logging information format and scope is primarily intended to be consumed by the (typically fairly centralized) logical entity responsible for collecting intra-CDN logs, processing, filtering those and then exporting the relevant subset of logs/fields to the other CDNs. o the surrogates within a given CDN are typically not expected to need to be aware of the specific set of fields or set of events that have been requested by various interconnected CDNs. Rather the surrogates are likely to perform some generic logging for all services regardless of the peculiarities of every CDNI agreement. Processing (e.g. filtering, format adaptation) of the generic logging information generated by the Surrogates is expected to take place to ensure that each interconnected CDN receives the specific set of fields and logs it has requested through Logging Control. Therefore there is no need to ensure that the Logging control information be easily distributable through the CDNs right down to surrogates. o the Control interface is expected to support the capability to apply control at the granularity of content sets (e.g. for content Purge) which is required for Logging Control since it is expected that a CDN may require different sets of logging fields and events for different sets of content (e.g. because it only needs to perform coarse billing for a given CSP while it needs to provide detailed analytics for another CSP). " Best regards, Gilles -----Message d'origine----- De=A0: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com]=20 Envoy=E9=A0: jeudi 22 novembre 2012 16:20 =C0=A0: STEPHAN Emile OLNC/OLN; BERTRAND Gilles OLNC/OLN Cc=A0: Objet=A0: Requirement for CDNI Logs in uCDN --> dCDN direction? Emile, Gilles, In Atlanta, there was some non-conclusive discussion on whether or not ther= e was a strong enough requirement for passing CDNI Logging information from= uCDN to dCDN. Could you identify examples of CDNI Logging information that one may want t= o communicate from uCDN to dCDN? Thanks Francois ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From flefauch@cisco.com Wed Nov 28 07:19:09 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2777B21F8879 for ; Wed, 28 Nov 2012 07:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-B7XakeDi50 for ; Wed, 28 Nov 2012 07:19:07 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 979D821F8827 for ; Wed, 28 Nov 2012 07:19:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17155; q=dns/txt; s=iport; t=1354115947; x=1355325547; h=from:to:subject:date:message-id:mime-version; bh=w9lxuZJsbpxHBlErPq7yezs3RUqQx6ghTKhegrYAGp4=; b=lQ1J9cIFmL+gS0xFZc+A7LXlkCazY866RaVyJUzXFiNUbM78SnOs0KYU J5sccv2/Uv64swliAKzxvTs6aJsTWc8HhpRQr/5U+jvX2cvQCO6QIxRyR vBbE1l+de95jVi4pmlMn2mqyRjarWlFgdferI0H072bPUnUuFt3PIPd0n c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACAqtlCtJXG8/2dsb2JhbAArFwPAFRZzgiABAgJmAiMBHA4KBAw8JAMBAxuIBwwtnQSSXo5kjD8LG28HgkRhA6ZFgiFPgWw1 X-IronPort-AV: E=McAfee;i="5400,1158,6909"; a="147122901" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 28 Nov 2012 15:19:06 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qASFJ6iA014768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 28 Nov 2012 15:19:06 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.236]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.001; Wed, 28 Nov 2012 09:19:06 -0600 From: "Francois Le Faucheur (flefauch)" To: "" Thread-Topic: Informal discussion on CDNI interface to use for customization of CDNI Logging: 12 Dec 8:00am PST Thread-Index: AQHNzXu01LXAZKjTP06+PLNzLki8SQ== Date: Wed, 28 Nov 2012 15:19:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.198] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D292E97xmbrcdx10ciscocom_" MIME-Version: 1.0 Subject: [CDNi] Informal discussion on CDNI interface to use for customization of CDNI Logging: 12 Dec 8:00am PST X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 15:19:09 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D292E97xmbrcdx10ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, It appeared in Atlanta that we need more discussion to conclude on which CD= NI interface (CI or MI) is to be used for customization/control of CDNI Log= ging. To facilitate an informal discussion on that topic, I have setup a Webex se= ssion for remote participation: Date: Wednesday 12 December 2012 Start: 08:00 PST aka 17:00 CET Duration: 90 mins Webex details: see below Please mark this in your agenda if you are interested in attending. Again, note that this is not a formal session nor an IETF Interim Meeting. = Just an informal discussion to exchange views on that topic. Cheers Francois Topic: CDNI Logging Customization/Control Date: Wednesday, December 12, 2012 Time: 5:00 pm, Europe Time (Paris, GMT+01:00) Meeting Number: 207 377 422 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D211252322&UID=3D4843= 18167&PW=3DNMTM0ZDI5MmM0&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:207 377 422 CCP:+14085256800x207377422# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. --_000_FC236DA6F2DA77449EF2D02DF4471A8D292E97xmbrcdx10ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Hi,

It appeared in Atlanta that we need more discussion to conclude on whi= ch CDNI interface (CI or MI) is to be used for customization/control of CDN= I Logging.

To facilitate an informal discussion on that topic, I have setup a Web= ex session for remote participation:
Date:&= nbsp;Wednesday 12 December 2012
Start:=  08:00 PST aka 17:00 CET
Durati= on: 90 mins
Webex = details: see below

Please mark this in your agenda if you are interested in attending.

Again, note that this is not a formal session nor an IETF Interim Meet= ing. Just an informal discussion to exchange views on that topic.

Cheers

Francois 


Topic: CDNI Logging Cust= omization/Control = ;
Date: Wednesday, Decem= ber 12, 2012 
Time: 5:00 pm, Europe = Time (Paris, GMT+01:00) 
Meeting Number: 207 37= 7 422 
Password: cdni<= span class=3D"Apple-style-span" style=3D"font-family: Tahoma, Arial, sans-s= erif, Helvetica, Geneva; font-size: small; "> 

----------------------= --------------------------------- 
To join the meeting on= line(Now from mobile devices!) 
----------------------= --------------------------------- 
1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D21125= 2322&UID=3D484318167&PW=3DNMTM0ZDI5MmM0&RT=3DMiMyMw%3D%3D 
2. If requested, enter= your name and email address. 
3. If a password is re= quired, enter the meeting password: cdni 4. Click "Join&qu= ot;. 
5. If the meeting incl= udes a teleconference, follow the instructions that appear on your screen.<= /span> 

----------------------= --------------------------------- 
To join the audio conf= erence only 
----------------------= --------------------------------- 
To receive a call back= , provide your phone number when you join the meeting, or call the number b= elow and enter the access code. 
Call-in toll-free numb= er (US/Canada): +1-866-432-9903  Call-in toll number (U= S/Canada): +1-408-525-6800 
Toll-free dialing rest= rictions: = http://www.webex.com/pd= f/tollfree_restrictions.pdf 

Access code:207 377 42= 2 




CCP:+14085256800x2= 07377422# =

IMPORTANT NOTICE: This= WebEx service includes a feature that allows audio and any documents and o= ther materials exchanged or viewed during the session to be recorded. By joining this session, you automatically con= sent to such recordings. If you do not consent to the recording, discuss yo= ur concerns with the meeting host prior to the start of the recording or do= not join the session. Please note that any such recordings may be subject to discovery in the event of litig= ation.  --_000_FC236DA6F2DA77449EF2D02DF4471A8D292E97xmbrcdx10ciscocom_-- From flefauch@cisco.com Thu Nov 29 02:28:44 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C84221F89EC for ; Thu, 29 Nov 2012 02:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5tcR4FPNVX5 for ; Thu, 29 Nov 2012 02:28:43 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id B5F2021F8A61 for ; Thu, 29 Nov 2012 02:28:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33585; q=dns/txt; s=iport; t=1354184922; x=1355394522; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=j/TTCuI0aGQKnjgCdQvKa2ik/mKJKFSTUrycc0I9Av0=; b=bViILrtu0ejfOxln+vxjCwDBtzBO5j8pjttnkwJUFTSzy0fAwW/BOQ/T WyVKf7lBc/D565lje/BBHu2yC5cpUfO8Fe7jDXAXFvkmQ5lcmA/KZzZWM wCbBS2qj75hEBgBc0tQThJwrykeYX87g9cCOEhlsunfBNl6p1q3dpF89n A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFANI3t1CtJV2c/2dsb2JhbAAqFwPAIxZzgh8BAQICAQEBYwIGGwIBCBQOCgQIAQIBAwcnCxQQAQIBAxMIiAgMLbAtjlaMPwsbbweCRGEDpkWCI0+BbDU X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="147478591" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 29 Nov 2012 10:28:42 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qATASgwG026470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 29 Nov 2012 10:28:42 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.236]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 04:28:41 -0600 From: "Francois Le Faucheur (flefauch)" To: "" Thread-Topic: [CDNi] Informal discussion on CDNI interface to use for customization of CDNI Logging: 19 Dec 8:00am PST Thread-Index: AQHNzhxNfAJGl5qKVUuB8G1KiMDKCA== Date: Thu, 29 Nov 2012 10:28:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.198] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D2965F0xmbrcdx10ciscocom_" MIME-Version: 1.0 Subject: Re: [CDNi] Informal discussion on CDNI interface to use for customization of CDNI Logging: 19 Dec 8:00am PST X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 10:28:44 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D2965F0xmbrcdx10ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Meeting has been rescheduled to 19 Dec. So here are the updated details: Date: Wednesday 19 December 2012 Start: 08:00 PST aka 17:00 CET Duration: 90 mins Webex details: see below Please mark this in your agenda if you are interested in attending. Again, note that this is not a formal session nor an IETF Interim Meeting. = Just an informal discussion to exchange views on that topic. Francois Webex details: Topic: CDNI Logging Customization/Control Date: Wednesday, December 19, 2012 Time: 5:00 pm, Europe Time (Paris, GMT+01:00) Meeting Number: 207 377 422 Password: cdni ------------------------------------------------------- To join the meeting online ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D211252322&UID=3D4843= 18167&PW=3DNMTM0ZDI5MmM0&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:207 377 422 CCP:+14085256800x207377422# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. On 28 Nov 2012, at 16:19, Francois Le Faucheur (flefauch) wrote: Hi, It appeared in Atlanta that we need more discussion to conclude on which CD= NI interface (CI or MI) is to be used for customization/control of CDNI Log= ging. To facilitate an informal discussion on that topic, I have setup a Webex se= ssion for remote participation: Date: Wednesday 12 December 2012 Start: 08:00 PST aka 17:00 CET Duration: 90 mins Webex details: see below Please mark this in your agenda if you are interested in attending. Again, note that this is not a formal session nor an IETF Interim Meeting. = Just an informal discussion to exchange views on that topic. Cheers Francois Topic: CDNI Logging Customization/Control Date: Wednesday, December 12, 2012 Time: 5:00 pm, Europe Time (Paris, GMT+01:00) Meeting Number: 207 377 422 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D211252322&UID=3D4843= 18167&PW=3DNMTM0ZDI5MmM0&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:207 377 422 CCP:+14085256800x207377422# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC236DA6F2DA77449EF2D02DF4471A8D2965F0xmbrcdx10ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <65CB5C36E411374AB671AAFAB616269A@cisco.com> Content-Transfer-Encoding: quoted-printable
Folks,

Meeting has been rescheduled to 19 Dec. So here are the updated detail= s:

Date: Wednesday 19 December 2012
Start: 08:00 PST aka 17:00 CET
Duration: 90 mins
Webex details: see below

Please mark this in your agenda if you are interested in attending.

Again, note that this is not a formal session nor an IETF Interim Meeting. = Just an informal discussion to exchange views on that topic.

Francois



Webex details:

Topic: CDNI Logging Cust= omization/Control = ;
Date: Wednesday, Decem= ber 19, 2012 
Time: 5:00 pm, Europe = Time (Paris, GMT+01:00) 
Meeting Number: 207 37= 7 422 
Password: cdni<= span class=3D"Apple-style-span" style=3D"font-family: Tahoma, Arial, sans-s= erif, Helvetica, Geneva; font-size: small; "> 

----------------------= --------------------------------- 
To join the meeting on= line 
----------------------= --------------------------------- 
1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D21125= 2322&UID=3D484318167&PW=3DNMTM0ZDI5MmM0&RT=3DMiMyMw%3D%3D 
2. If requested, enter= your name and email address. 
3. If a password is re= quired, enter the meeting password: cdni 4. Click "Join&qu= ot;. 
5. If the meeting incl= udes a teleconference, follow the instructions that appear on your screen.<= /span> 

----------------------= --------------------------------- 
To join the audio conf= erence only 
----------------------= --------------------------------- 
To receive a call back= , provide your phone number when you join the meeting, or call the number b= elow and enter the access code. 
Call-in toll-free numb= er (US/Canada): +1-866-432-9903  Call-in toll number (U= S/Canada): +1-408-525-6800 
Toll-free dialing rest= rictions: = http://www.webex.com/pd= f/tollfree_restrictions.pdf 

Access code:207 377 42= 2 




CCP:+14085256800x2= 07377422# =

IMPORTANT NOTICE: This= WebEx service includes a feature that allows audio and any documents and o= ther materials exchanged or viewed during the session to be recorded. By joining this session, you automatically con= sent to such recordings. If you do not consent to the recording, discuss yo= ur concerns with the meeting host prior to the start of the recording or do= not join the session. Please note that any such recordings may be subject to discovery in the event of litig= ation. 
On 28 Nov 2012, at 16:19, Francois Le Faucheur (flefauch) wrote:

Hi,

It appeared in Atlanta that we need more discussion to conclude on whi= ch CDNI interface (CI or MI) is to be used for customization/control of CDN= I Logging.

To facilitate an informal discussion on that topic, I have setup a Web= ex session for remote participation:
Date:&= nbsp;Wednesday 12 December 2012
Start:=  08:00 PST aka 17:00 CET
Durati= on: 90 mins
Webex = details: see below

Please mark this in your agenda if you are interested in attending.

Again, note that this is not a formal session nor an IETF Interim Meet= ing. Just an informal discussion to exchange views on that topic.

Cheers

Francois 


Topic: CDNI Logging Cust= omization/Control = ;
Date: Wednesday, Decem= ber 12, 2012 
Time: 5:00 pm, Europe = Time (Paris, GMT+01:00) 
Meeting Number: 207 37= 7 422 
Password: cdni<= span class=3D"Apple-style-span" style=3D"font-family: Tahoma, Arial, sans-s= erif, Helvetica, Geneva; font-size: small; "> 

----------------------= --------------------------------- 
To join the meeting on= line(Now from mobile devices!) 
----------------------= --------------------------------- 
1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D21125= 2322&UID=3D484318167&PW=3DNMTM0ZDI5MmM0&RT=3DMiMyMw%3D%3D 
2. If requested, enter= your name and email address. 
3. If a password is re= quired, enter the meeting password: cdni 4. Click "Join&qu= ot;. 
5. If the meeting incl= udes a teleconference, follow the instructions that appear on your screen.<= /span> 

----------------------= --------------------------------- 
To join the audio conf= erence only 
----------------------= --------------------------------- 
To receive a call back= , provide your phone number when you join the meeting, or call the number b= elow and enter the access code. 
Call-in toll-free numb= er (US/Canada): +1-866-432-9903  Call-in toll number (U= S/Canada): +1-408-525-6800 
Toll-free dialing rest= rictions: = http://www.webex.com/pd= f/tollfree_restrictions.pdf 

Access code:207 377 42= 2 




CCP:+14085256800x2= 07377422# =

IMPORTANT NOTICE: This= WebEx service includes a feature that allows audio and any documents and o= ther materials exchanged or viewed during the session to be recorded. By joining this session, you automatically con= sent to such recordings. If you do not consent to the recording, discuss yo= ur concerns with the meeting host prior to the start of the recording or do= not join the session. Please note that any such recordings may be subject to discovery in the event of litig= ation. 
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

--_000_FC236DA6F2DA77449EF2D02DF4471A8D2965F0xmbrcdx10ciscocom_-- From oskar.vandeventer@tno.nl Thu Nov 29 02:34:45 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1EF521F89F3 for ; Thu, 29 Nov 2012 02:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.776 X-Spam-Level: *** X-Spam-Status: No, score=3.776 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, EXTRA_MPART_TYPE=1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeUsVBOuWkb8 for ; Thu, 29 Nov 2012 02:34:44 -0800 (PST) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5803C21F89F4 for ; Thu, 29 Nov 2012 02:34:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,182,1355094000"; d="gif'147?scan'147,208,217,147";a="626559" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1a.tno.nl with ESMTP; 29 Nov 2012 11:34:37 +0100 Received: from EXC-MBX01.tsn.tno.nl ([169.254.1.231]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.02.0318.004; Thu, 29 Nov 2012 11:34:37 +0100 From: "Deventer, M.O. (Oskar) van" To: "cdni@ietf.org" Thread-Topic: ETSI documents on CDN interconnection Thread-Index: Ac3OGmdbuGm/5HmRQUu8Lr5PyDeaRg== Date: Thu, 29 Nov 2012 10:34:36 +0000 Message-ID: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: multipart/related; boundary="_004_BA5A0ED6E909E749AD5CB0D3750A6D2A082FF4FEEXCMBX01tsntnon_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "Chatras, Bruno" , "Bonardi, Chantal" Subject: [CDNi] ETSI documents on CDN interconnection X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 10:34:45 -0000 --_004_BA5A0ED6E909E749AD5CB0D3750A6D2A082FF4FEEXCMBX01tsntnon_ Content-Type: multipart/alternative; boundary="_000_BA5A0ED6E909E749AD5CB0D3750A6D2A082FF4FEEXCMBX01tsntnon_" --_000_BA5A0ED6E909E749AD5CB0D3750A6D2A082FF4FEEXCMBX01tsntnon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear IETF CDNi friends, ETSI has just approved its CDNi requirements document TS 102 990. You can d= ownload it here. http://www.etsi.org/deliver/etsi_ts/102900_102999/102990 The document contains a set of use cases and requirements for CDN-I interco= nnection. ETSI has made an effort to stay aligned with terminology and use = cases as discussed in IETF. The document includes references to RFC 6770. Some of the use cases and requirements w= ould be considered "advanced" by IETF, and could be used as input for a fut= ure release of IETF CDNi. ETSI is also in the final phase of its CDNi architecture document TS 182 03= 2. You can download a recent draft here (ETSI account required). http://docbox.etsi.org/Board/BOARDE2NA/05-CONTRIBUTIONS/2012/BOARDE2NA(12)0= 3_010_WI2086_TS182032_CDN-I_Architecture_V006_output_draft.doc That document specifies functional elements, interfaces and protocol flows.= The next draft will also include examples of datamodels for CDNi, and a ma= pping between the ETSI and IETF architectures. I shall keep you informed ab= out this. Final ETSI approval and publication is planned for March 2013. Best regards, Oskar Dr. ir. M.O. (Oskar) van Deventer Senior Scientist Media Networking Media & Network Services T +31 (0)88 866 70 78 M +31 (0)65 191 49 18 E oskar.vandeventer@tno.nl Location Disclaimer [cid:image001.gif@01CDCE23.14782DD0] --_000_BA5A0ED6E909E749AD5CB0D3750A6D2A082FF4FEEXCMBX01tsntnon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear IETF CDNi friends,

 

ETSI has just approved its CDNi= requirements document TS 102 990. You can download it here.

http://www.etsi.org/deliver/etsi_ts/1= 02900_102999/102990

The document contains a set of = use cases and requirements for CDN-I interconnection. ETSI has made an effo= rt to stay aligned with terminology and use cases as discussed in IETF. The= document includes references to RFC 6770. Some of the use cases and requirements woul= d be considered “advanced” by IETF, and could be used as input = for a future release of IETF CDNi.

 

ETSI is also in the final phase= of its CDNi architecture document TS 182 032. You can download a recent dr= aft here (ETSI account required).

http://docbox.etsi.org/Board/BO= ARDE2NA/05-CONTRIBUTIONS/2012/BOARDE2NA(12)03_010_WI2086_TS182032_CDN-I_Arc= hitecture_V006_output_draft.doc

That document specifies functio= nal elements, interfaces and protocol flows. The next draft will also inclu= de examples of datamodels for CDNi, and a mapping between the ETSI and IETF= architectures. I shall keep you informed about this. Final ETSI approval and publication is planned for March 2013.=

 

Best regards,=

 

Oskar

 

 

Dr. ir= . M.O. (Oskar) van Deventer
Senior Scientist Media Networking
Media & Network Services

T = ;+31 (0)88 866 70 78
M +31 (0)65 191 49 18
E oskar.vandeventer@tno.nl

Location
Disclaimer
 =

 <= /o:p>

 

--_000_BA5A0ED6E909E749AD5CB0D3750A6D2A082FF4FEEXCMBX01tsntnon_-- --_004_BA5A0ED6E909E749AD5CB0D3750A6D2A082FF4FEEXCMBX01tsntnon_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=2396; creation-date="Thu, 29 Nov 2012 10:34:36 GMT"; modification-date="Thu, 29 Nov 2012 10:34:36 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhOgIkAPcAAAAAAAEBAQICAgMDAwQEBAUFBQYGBgcHBwgICAkJCQoKCgsLCwwMDA0NDQ4O Dg8PDxAQEBERERISEhMTExQUFBUVFRcXFxoaGhsbGxwcHB0dHR4eHiAgICEhISIiIiMjIyQkJCUl JSYmJicnJygoKCkpKSoqKisrKywsLC0tLTAwMDExMTIyMjMzMzQ0NDY2Njc3Nzg4ODk5OTo6Ojs7 Oz09PT8/P0FBQUNDQ0REREVFRUdHR0hISElJSUxMTE1NTVBQUFFRUVJSUlRUVFVVVVZWVldXV1hY WFpaWl1dXV9fX2NjY2RkZGZmZmhoaGlpaWpqamxsbG1tbW5ubm9vb3BwcHFxcXJycnNzc3R0dHV1 dXd3d3t7e3x8fH19fX5+fmaZzGeazGiazGqbzWuczWydzm2ezm6eznCfz3Ggz3Kh0HOh0HOi0HSi 0Haj0Xek0Xil0nmm0nqm0nyn036p1ICAgIGBgYKCgoODg4aGhoeHh4iIiIqKiouLi4yMjI+Pj5CQ kJGRkZKSkpOTk5SUlJWVlZaWlpeXl5iYmJqampubm5ycnJ2dnZ6enp+fn6CgoKGhoaKioqOjo6Wl paampqenp6ioqKmpqaqqqqurq6ysrK2tra6urq+vr7CwsLGxsbKysra2tre3t7i4uLm5ubq6uru7 u7y8vL6+vr+/v4Cq1IKs1YWt1oev16DA36vH467J5LLM5cDAwMLCwsPDw8TExMXFxcbGxsfHx8jI yMnJycrKysvLy8zMzM3Nzc7Ozs/Pz9DQ0NPT09XV1dbW1tfX19jY2NnZ2dvb29zc3N7e3t/f38DV 6sLW6sPX68TX68bZ7Mvc7czd7s7e7tLh8Nbk8dnl8uDg4OLi4uPj4+Tk5OXl5ebm5ufn5+jo6Ovr 6+zs7O3t7e7u7u/v7+fv9+jv9+rx+O3z+fDw8PHx8fLy8vPz8/T09PX19fb29vf39/H2+vX4+/b5 /Pf6/Pj4+Pn5+fr6+vv7+/r7/fr8/fv8/f39/fz9/v3+/v7+/v///yH5BAkAAP8ALAAAAAA6AiQA AAj+AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJO+3Mew1yWQ9ioJU0q1qtWrWCv6AsG1q9evXntw IjgDhQkRJqgQVKfHhwcBEmjsCYcwioGOgy78UwfgS9a/gAMLNooLgOHDiBMnFjBWoILEdP0JqqAY QARFBzlt+TeLFi9H6f6R6iVL0rt//kY1uvbPE65/11D925XIk71iQhxkWpeF1L91lyqp+2dsEzZG yAYrX868uUhdlaMrdnBMYIHE3P5ZkW74ikG7/3L+aMAAIMg/Eh0sAIjyT4kDHgt07fDwL4qVPAeG KFgySIGADNv01Q4JH7gQQjp7CKCCARPU49yDEEYoIUK9cGchACiw449i29RxIQCFFAReDhHcY0MI 55WwDwg3YANAF/4wMEQjAAizQS67gMKLCyT8k0QFe/X1CACo5AKAIXsAgAseALA24ZNQRvkXMB9y h0Q9iuVy3YUNeEPQiCn8A0QH5/Xwjws17ALAH/90QIM4BhDBgT+GIJDECRv4CCRfXyQZjDIAeJGk N4QAkIyUiCaqqFDhPFZldEkmZkRlB1Rmx5d35RDmmGWeWQM6DSiRDQFV/OMDAJtpEEM7H+S5hAH/ vYDT1ykAQDIJAKAMWuihi/bq668ycZNJJZXUkFgChhBLhXQDKNYsYicE4w8vIiTWAqbhbUomCWai +c8lDxSAAzj/SAKAL9oZMIIOEvyzyXW/9PXPFQccMMU/uhoK7L789ntSEom9MBAmj1aWy0CoJMYA RfsMd1A7/hC0zjcFvXOavxhnrLFHACMmw8AFK+bwP94kFsA9G6es8soX9cPPyzDHLLPM+uBj8803 50NQx4d9LBDBISNWyUCMJEZBQaPwgc5C3fBijy6a/EOPI4ws5A8++vDTT0yYkOC11yKAlcg8q8xh 9tlop6322my37fbbcMct99x012333XHTAU8s/nH07bffcLwh+OCEF164G20krvjijDPOhhqQRy75 5JKngcblmGeuueZnmOH556CHHnoZZJRu+umooz6GGKy37vrrrocBxuy012777bjnrvvta+ycmM// AH1YuNI9kFgDfaSSh6OH7UBQwihos1AfAHCzhAPzEnDEQuXcHgbrY5RehhlnXJ4G5Gwk7sYbcPQt xxzk+AHW/PMjksiFGdDzyu789+///wAMoAAHSMACGnCAsDCHGA7IwAY68IEQjKAEwdC7gfDMMMAT nmFOAAjpaOFRixgIPZgAgEb4Qx2VuAQ7/kEMTwCDGAKhHjcwwYVlrEAEtPCHKSCBjYN0T4Ku/tgG AoIGAD3c70KIgAcZJsjEJjrxiVDM3Rni4YooWvGKWMwiACsokAsCIIOJOcE/JlUZYlDgQyBwkEDA YTwMpCMEIlgBCdiBBwVUIBIxrN71LmGAAyShCRH4AQR+YZAfRnAM53gCEY34IST4QxVajKQkJ/lE azyDkpjMpCYJyEUf/Q5k0NpLCSpzjVJUijsHsEVB9AAAdigCALWgBQAWwaQ6OEyG1/sHDVoUgCJ0 4gJIKCQTo2GJRR6ROwHwBTU2ycxmOnN2rNgHJJ9JzWpGspNeBGMoWTgBxSzjH5/YUmUW4AmDsJKO ACDGMQBwByZJL4/Ww94ubwEAGzjBCX4Q/6YE48APGBjzQj/4RyusSdCCOnEa0jCoQhf6wE5+0GMD UdM2/8EL4yFGGQIZBhACoJgcTMWcrQwFACoxpFEwSY3/wKU8byCOBRhhGzwIhD4jyIxRELGIxDiE TnfKU50iQx7MCKpQh0rUohr1qEhNqlKXytSmOvWpUI2qVJvqDH9UwxlYzapWt8rVrnr1q2ANq1jH KtZmTPWsaE3rU6FBkHeIYhBwHUTUBOIPUsR1EJQgiDg2cdfQDOQXg4ACD5CAh2Ak5Jz/kEK9sPCP kw5Epbq8QfC6yYJ3EgSoaiVqPlLR0856VqeEZJloR0vagbiDHhLxxzhKy9rWuva1sI2tbD1nS9va 2va2uM2tbnfL29769rfADa5wh0vc4hr3uMhNrnKXy9zmOve50I2udKdL3epa97rYza52t8tdKAUE ADs= --_004_BA5A0ED6E909E749AD5CB0D3750A6D2A082FF4FEEXCMBX01tsntnon_--