From nobody Tue Apr 8 02:12:31 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2DEC1A01CD for ; Tue, 8 Apr 2014 02:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmczs6_cmD1m for ; Tue, 8 Apr 2014 02:12:25 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6231A01C2 for ; Tue, 8 Apr 2014 02:12:24 -0700 (PDT) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginm.net ([86.14.227.47] helo=[192.168.0.3]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1WXS4o-0007zS-0v; Tue, 08 Apr 2014 10:12:18 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Niven-Jenkins In-Reply-To: <5FBAF9F8-8389-431B-95BC-9758273FBDF9@cisco.com> Date: Tue, 8 Apr 2014 10:12:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9BC6A215-2072-4E95-8B45-0E915ABFBDF4@niven-jenkins.co.uk> References: <5FBAF9F8-8389-431B-95BC-9758273FBDF9@cisco.com> To: Francois Le Faucher X-Mailer: Apple Mail (2.1874) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/-ogggOkJGxVkFmOsVlE5C1lvvII Cc: "draft-ietf-cdni-metadata@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 4] X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 08 Apr 2014 09:12:30 -0000 Francois, See inline for my views on a couple of your comments. I=92ve snipped out = your other comments that I=92m fine with. On 12 Mar 2014, at 13:51, Francois Le Faucheur (flefauch) = wrote: > *** somewhere (probably towards the beginning of the document): > Can you make sure the applicability of the metadata defined in this = documents is discussed in terms of what types of deliveries are = supported (HTTP/1.0, 1.1, 2.0 , HTTPS). I suggest you base that on the = text I proposed on the list for cdni-logging. > Also how about adding a summary of features supported by specified = metadata (eg geolocation, time window, multipe acquisitions, =85) What do you mean? I=92m not sure what you have in mind when you say a = =93summary of features supported by specified metadata=94?=20 =20 > *** section 4.1.3: > "First match applies.=94 > Might be worth turning into a full sentence explaining the context of = the =93match=94 ie when metadata is walked through to find the relevant = one for a piece of content to be processed , every path-pattern is = evaluated in the order they appear in paths object and then first match = applies.=85 up to you. This is a useful clarification IMO, we should include it. > *** section 4.1.6: > "The three literals \ , * and ? should be > escaped as \\, \* and \?. All other characters are treated as > literals.=94 > Why do you need to escape =93\=94? You need to escape the escape character so that you can represent the = escape character as a literal. Or in other words if I want to represent = =93\=94 I need to escape it to avoid it being mistaken for the escape = character otherwise I can=92t determine whether the next character is = escaped or not. > *** section 4.2.1.1: > Is it really useful to allow multiple endpoints within a source, given = it is possible to include multiple sources? > If you keep multiple endpoints within a source, can you also clarify = if there is any expected behavior from dCDN across the multiple = endpoints (single or ) There are two useful properties of having multiple endpoints within a = source IMO: 1) They share common auth properties so those do not have to be repeated = for each endpoint as would be the case if each endpoint was specified as = a separate source. 2) Endpoints within a source should be treated as equivalent/equal so = one can specify a list of sources in preference order and for each = source/preference rank one can specify a list of endpoints that are = equivalent, e.g. a pool of servers that are not behind a load balancer. Ben From nobody Tue Apr 8 03:43:50 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCF81A02FB for ; Tue, 8 Apr 2014 03:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_FROM=2.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpaWWmGEj48s for ; Tue, 8 Apr 2014 03:43:44 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id CBEF91A02E0 for ; Tue, 8 Apr 2014 03:43:37 -0700 (PDT) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginm.net ([86.14.227.47] helo=[192.168.0.3]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1WXTV4-0004cu-Ft; Tue, 08 Apr 2014 11:43:30 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Niven-Jenkins In-Reply-To: <18D8DD69-FA99-400B-83A0-A47790AB0209@cisco.com> Date: Tue, 8 Apr 2014 11:43:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2483D9BF-A4DD-440D-9D0B-E5161912ECF1@niven-jenkins.co.uk> References: <18D8DD69-FA99-400B-83A0-A47790AB0209@cisco.com> To: Francois Le Faucher X-Mailer: Apple Mail (2.1874) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/7HEtoC5EJC-aFHoPR1Nwd9Y7Imw Cc: "draft-ietf-cdni-metadata@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 5] X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 08 Apr 2014 10:43:48 -0000 Francois, Some comments inline. On 20 Mar 2014, at 18:33, Francois Le Faucheur (flefauch) = wrote: > *** section 4.2.2, 4.2.3 and 4.2.4. > It appears that the three types of allow/deny (LocationACL, = TimeWindowACL and ProtocolACL) and independent of each other. > So I can say , for this content: > (i) allow it in this Footprint and block it everywhere else Yes > (ii) allow it in this timewindow and block it at any other time. Yes and you can also express: allow it in this footprint for this time = window and block it from any other footprint or in any other time = window. > Is it possible to say , for this content: > (i) allow it in this timewindow from this footprint > (ii) allow it in a different timewindow ffrom this other = footprint > (iii) block it otherwise? No > Either way, can you ensure there is a discussion about that (perhpas = it comes up further down in the document and I have not seen it)? > If you feel this extra flexibility is not needed, then please state so = (and ideally indicate whether it could be added in teh future without = breaking all the current object structure). If this flexibility is = supported , then please add a note/example explaining how.=20 If we want to support policies that allow us to express complex = combinations of different types of ACL that could be done but I think it = introduces quite a bit of extra complexity so I=92d like to understand = the use case for needing it better first. Do content providers rely on CDNs to enforce such combinations of = different time windows in different footprints. Or do they use ACLs in = the CDN to enforce broad policy by footprint and/or time window and use = other mechanisms such as URI signing & not returning URIs to User Agents = outside of the time window by their CMS for more fine grained control? > *** section 4.2.4 > =93 > Property: action > Description: Defines whether the rule specifies protocols to > allow or deny. > ... > Property: direction > Description: Defines whether the ProtocolRule specifies > protocols for acquisition or delivery. > =93 > I don=92t quite get the semantics of this object when = direction=3Dacquisition.=20 > If it conditions how the dCDN is meant to change protocol to acquire = the content , then it shoudl not be cast as an allow/deny, but probably = more as part of the =93source=94 object that defines acquisition = behaviour. I don=92t remember why the direction property got introduced and I=92m = struggling to think of a reason for it. Protocol ACLs are for defining = delivery protocols. Acquisition protocols should be specified in the = Source object. Unless one of my co-authors can recall why we introduced it, I suggest = we remove the direction property altogether. > *** section 4.2.6: > "An Auth object defines authentication and authorization methods =93 = while 4.2.5 says "authorization methods =93. Is it authorization or = both authentication and authorisation? Good question. I think it can be either. IIRC we=92re reusing the same = Auth object to convey Authorisation of User Agent requests (if it=92s = included in a HostMetadata or PathMetadata object) and also = Authentication and/or Authorisation to an Acquisition Source (if it is = included in the auth property of a Source object). That=92s probably not obvious because we don=92t actually specify Auth = types that cover authorisation of user agent requests. > *** section 4.2.7 > =93 > Mandatory-to-Specify: No. Default is to consider query string > parameters when comparing URIs or to rely on other properties > of the Cache object. > =93=20 > What does =93rely on other properties of the Cache object=94 actually = mean? there is no other properties in that object. I=92m not sure to be honest. I think we anticipated having other = modifiers in the Cache object at some point, which we never included in = the end, but I don=92t recall. > *** general question about multiple instances of objects. > Is it correct that one expects only a single instance of top level = objects inside a given generic metadata object? > For example, there shoudl only be a single sources Metadata object = (which obvisouly can contain a list), but I should not have two sources, = right? Correct. > Is this explicitely stated somewhere? Can you ensure it is stated and = it is also stated what happens if you receive two of the same objects = (only keep the first one? in case of transit, redistribute or drop the = other instances?) I think we can say that uCDN MUST NOT include more than one of the same = object and that if they do then dCDN SHOULD use the first one in the = list. I don=92t have a strong opinion one way or the other in the case of = transit.=20 =20 > *** section 6.2 : > =93 > If any > PathMetadata match the request (and are linked rather than = embedded), > the CDNI metadata client makes another GET request for the > PathMetadata. > " > The fact that the text says =93match=94 instead of =93matches=94 = raises teh question of what hapens when more than one does match. = Looking back at 4.1.3, I don=92t see the answer to that question. I may = have already commented on that question. In any case, please make sure = this is specified (I would suggest in 4.1.3 and possibly in section 6.2 = where you describe the un-pilling of metadata). I=92d suggest first match wins, but you=92re right we should specify it = somewhere. Ben From nobody Tue Apr 8 04:45:15 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDDB1A0335 for ; Tue, 8 Apr 2014 04:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQwJIjqVmRVv for ; Tue, 8 Apr 2014 04:45:06 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5531A020A for ; Tue, 8 Apr 2014 04:45:06 -0700 (PDT) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginm.net ([86.14.227.47] helo=[192.168.0.3]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1WXUSZ-0001uZ-Iz; Tue, 08 Apr 2014 12:44:59 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Niven-Jenkins In-Reply-To: <5152EB8C-8B72-40A7-A0B3-0C887CA35258@cisco.com> Date: Tue, 8 Apr 2014 12:44:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5152EB8C-8B72-40A7-A0B3-0C887CA35258@cisco.com> To: Francois Le Faucher X-Mailer: Apple Mail (2.1874) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/ae1lSz_oBLLaPCoyazodIjoRQl4 Cc: "draft-ietf-cdni-metadata@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 6] X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 08 Apr 2014 11:45:11 -0000 Francois, See inline for a couple of comments. On 24 Mar 2014, at 18:57, Francois Le Faucheur (flefauch) = wrote: > *** section 6.4: > "Embedded, where the object is contained (or inlined) within a > property of an addressable object.=94 > What is the difference between =93inlined=94 and =93contained=94? They are synonyms for the same thing. > *** Section 6.4.1: > "the type name of that object as defined by this document.=94 > The phrase =93type name=94 was not clear to me. Should it not just be = the "object name=94? Yes I think so. > *** section 6.4.2: > "In addition to the properties specific to each object type, the keys > defined below may be present in any object.=94 > Wrt the _links key, I think it can appear =93instead=94 of the = property and not =93in addition to=94 the properties. Is that right? Yes > *** section 6.6: > "HTTP requests sent to a metadata server SHOULD include an Accept = header with the MIME-type > and version of the expected object.=93 > Can a metadata client indicate it it is happy to receive wither of two = versions eg "application/cdni.HostIndex.v1+json=94 or = "application/cdni.HostIndex.v2+json? I assme yes. Can you state that and = give some description or example? A HTTP Accept header allows a metadata client to indicate it is happy to = receive multiple versions. We should add some text to clarify. > *** section 7.1: > "the version number of the GenericMetadata set to which the > standard capability applies,=94 > I can=92t parse that. I am not sure what is this version as compared = to the versions that appear in MIME-Type. I think this section needs some work. It also says "The version field = should be incremented when new GenericMetadata type sets are added to = the registry=94, which is not what I think we want. When a new version = is defined it should get its own entry in the registry, it shouldn=92t = =91overwrite=92 the existing entry. > I am also a bit confused now as to the need to register those object = names, beause the Metadata Object names registered here actually never = appear in the encoded Metadata (which only lists the corresponding set = of properties).. I think this may be a historical carry through. The way a Generic = Metadata object is identified is through its type property. The value of = the type property is a Media Type. It may have been the Metadata Object = name in the past, I don=92t recall. I think what we need to do is = replace the Type Names with the actual Media Types registered for each = object? > Actually, this raises a serious high level question in my mind on the = way the metadata objects are defined. > So you define objects by names (eg HostIndex). But these object names = never appear in the actually encoding. What appears are the properties = comprised under the object name (e.g. =93hosts=94 for HostIndex). So it = is the first property name appearing (eg =93hosts=94) that needs to be = parsed to actually identify what objects this is (and therefore what = other properties follow). No. The top level object in the response does not include the Metadata = Object names but the response include a Media Type in the Content-Type = HTTP header that identifies the type of object being returned. =20 For generic Metadata, again the Metadata Object names are not included = but the type property of the Generic Metadata object contains the Media = Type of the object contained in the value property. > Now if you want to keep that approach, then you need to make sure that = a new object allocated in the GenericMetadata Type registry never = allocates the same first =93property name=94, right? otherwise you = can=92t parse teh encoding and know which object it is. I don=92t think = any such restrictions is currently identified in the document. See above, I don=92t think clashes are an issue as new objects will have = new Media Types defined that do not clash with the existing media types. =20 Ben From nobody Wed Apr 16 02:25:48 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20EAD1A008E; Wed, 16 Apr 2014 02:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edjtBd_1jVtR; Wed, 16 Apr 2014 02:25:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E470E1A0019; Wed, 16 Apr 2014 02:25:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140416092545.27931.32062.idtracker@ietfa.amsl.com> Date: Wed, 16 Apr 2014 02:25:45 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/YeSfL-gIwDzraWT-30drrjmDU9Q Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-redirection-02.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 16 Apr 2014 09:25:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF. Title : Request Routing Redirection Interface for CDN Interconnection Authors : Ben Niven-Jenkins Ray van Brandenburg Filename : draft-ietf-cdni-redirection-02.txt Pages : 26 Date : 2014-04-16 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-redirection-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-redirection-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 16 03:55:22 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B471A012D for ; Wed, 16 Apr 2014 03:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.077 X-Spam-Level: X-Spam-Status: No, score=-0.077 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.272] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABR_ahRkt5Px for ; Wed, 16 Apr 2014 03:55:19 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 86D721A012C for ; Wed, 16 Apr 2014 03:55:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,871,1389740400"; d="scan'208";a="24270332" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1a.tno.nl with ESMTP; 16 Apr 2014 12:55:13 +0200 Received: from EXC-MBX03.tsn.tno.nl ([fe80::e969:1300:fb9f:7e12]) by EXC-CASHUB02.tsn.tno.nl ([fe80::8c02:de2a:3094:171%14]) with mapi id 14.03.0123.003; Wed, 16 Apr 2014 12:55:13 +0200 From: "Brandenburg, R. (Ray) van" To: "cdni@ietf.org" Thread-Topic: New version of redirection draft Thread-Index: Ac9ZYixrxAl7eUXBRi60bXJASNc+yA== Date: Wed, 16 Apr 2014 10:55:13 +0000 Message-ID: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/y3AFz_MLz5I0317BrcXJO6oSnT8 Subject: [CDNi] New version of redirection draft X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 16 Apr 2014 10:55:21 -0000 Hi all, We've just uploaded a new -02 version of draft-ietf-cdni-redirection. New elements in this version include: A mechanism allowing the dCDN to resp= ond with an error dictionary in the redirection response, including an init= ial set of error codes, more examples of both HTTP and DNS redirection requ= ests/responses, and a method for handling of HTTP Headers in the redirectio= n request and response. = In addition, we've addressed Francois' review from back in November and per= formed a general document clean-up. Still on the todo list is the IANA sect= ion. = I would appreciate your reviews and comments. = Ray -----Original Message----- From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: woensdag 16 april 2014 11:26 To: i-d-announce@ietf.org Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-redirection-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : Request Routing Redirection Interface for CDN Int= erconnection Authors : Ben Niven-Jenkins Ray van Brandenburg Filename : draft-ietf-cdni-redirection-02.txt Pages : 26 Date : 2014-04-16 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-redirection-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-redirection-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u ni= et de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, = wordt u verzocht dat aan de afzender te melden en het bericht te verwijdere= n. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de = wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verban= d houdt met risico's verbonden aan het elektronisch verzenden van berichten. = This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. From nobody Wed Apr 16 05:00:02 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BBE1A0140 for ; Wed, 16 Apr 2014 05:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.874 X-Spam-Level: X-Spam-Status: No, score=-12.874 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mo01qJhUG8OQ for ; Wed, 16 Apr 2014 04:59:56 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 773461A010B for ; Wed, 16 Apr 2014 04:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4589; q=dns/txt; s=iport; t=1397649593; x=1398859193; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pqqE0FHlxyzRTNjGWMAfMGDzFcWOZuHorRDgcBgo4X4=; b=LkNKxPVrpugGNxqo/i5zB7I4561CbPijPIUobWrJ3HKTd1mDYsb5zgIl 6NV6Yz8E50nXn8DTOZ5FSTi+4G6IgLQq/9S+u304l/t8PuhFrGckia3Z0 ojz3f1evyXJV3hPfPDqZGs3Q/aDFFY1xDr532Edvav+eQ8QGU34xbTnGe o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FABhwTlOtJV2a/2dsb2JhbABZgwY7V8MzgSEWdIIlAQEBAwEOVxQFCwIBCBguMiUCBA4Fh3QIx14XjXc4MweDJIEUAQOUeYNtkkmDMYIr X-IronPort-AV: E=Sophos;i="4.97,872,1389744000"; d="scan'208";a="318176433" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 16 Apr 2014 11:59:53 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3GBxrcE025431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Apr 2014 11:59:53 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Wed, 16 Apr 2014 06:59:52 -0500 From: "Francois Le Faucheur (flefauch)" To: Niven-Jenkins Ben Thread-Topic: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 4] Thread-Index: AQHPPfo5FZ9ksOgGXEmnpowH35ksBQ== Date: Wed, 16 Apr 2014 11:59:52 +0000 Message-ID: References: <5FBAF9F8-8389-431B-95BC-9758273FBDF9@cisco.com> <9BC6A215-2072-4E95-8B45-0E915ABFBDF4@niven-jenkins.co.uk> In-Reply-To: <9BC6A215-2072-4E95-8B45-0E915ABFBDF4@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.197] Content-Type: text/plain; charset="Windows-1252" Content-ID: <19D20357A2305D4C83DA0A009C543DC9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/ug-L7Ic0jS9aRnr-RUog2Jhs0cs Cc: "draft-ietf-cdni-metadata@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 4] X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 16 Apr 2014 12:00:01 -0000 Hi Ben, Thanks for looking into all the comments. My turn now to wlak through your = responses. See below: On 8 Apr 2014, at 11:12, Ben Niven-Jenkins wrote: > Francois, >=20 > See inline for my views on a couple of your comments. I=92ve snipped out = your other comments that I=92m fine with. >=20 > On 12 Mar 2014, at 13:51, Francois Le Faucheur (flefauch) wrote: >=20 >> *** somewhere (probably towards the beginning of the document): >> Can you make sure the applicability of the metadata defined in this docu= ments is discussed in terms of what types of deliveries are supported (HTTP= /1.0, 1.1, 2.0 , HTTPS). I suggest you base that on the text I proposed on = the list for cdni-logging. >> Also how about adding a summary of features supported by specified metad= ata (eg geolocation, time window, multipe acquisitions, =85) >=20 > What do you mean? I=92m not sure what you have in mind when you say a =93= summary of features supported by specified metadata=94?=20 I am thinking of a summary of what are the features of the distribution pol= icies supported by the metadata specified in this version of the document. = Something indicating that with these metadata it is possible to support geo= graphical access control, time access control, multiple content origination= , content origination authorization, =85. To me it woudl be very useful fo= r a reader to get upfront a high level understanding of what can actually b= e achieved (in terms of content distributon policies) across CDNs interconn= ected via cdni-metadata. BTW, if there are a number of functionality that are deliberately not suppo= rted by the current spec , it woudl be worth stating so. Otherwise one has to read the whole detailed document to get a feeling for = what functionality it provides. >=20 >> *** section 4.1.3: >> "First match applies.=94 >> Might be worth turning into a full sentence explaining the context of th= e =93match=94 ie when metadata is walked through to find the relevant one f= or a piece of content to be processed , every path-pattern is evaluated in = the order they appear in paths object and then first match applies.=85 up t= o you. >=20 > This is a useful clarification IMO, we should include it. Good. >=20 >> *** section 4.1.6: >> "The three literals \ , * and ? should be >> escaped as \\, \* and \?. All other characters are treated as >> literals.=94 >> Why do you need to escape =93\=94? >=20 > You need to escape the escape character so that you can represent the esc= ape character as a literal. Or in other words if I want to represent =93\= =94 I need to escape it to avoid it being mistaken for the escape character= otherwise I can=92t determine whether the next character is escaped or not= . I guess I was getting tired when I wrote that. Please ignore my comment. >=20 >=20 >> *** section 4.2.1.1: >> Is it really useful to allow multiple endpoints within a source, given i= t is possible to include multiple sources? >> If you keep multiple endpoints within a source, can you also clarify if = there is any expected behavior from dCDN across the multiple endpoints (sin= gle or ) >=20 > There are two useful properties of having multiple endpoints within a sou= rce IMO: >=20 > 1) They share common auth properties so those do not have to be repeated = for each endpoint as would be the case if each endpoint was specified as a = separate source. Good point. >=20 > 2) Endpoints within a source should be treated as equivalent/equal so one= can specify a list of sources in preference order and for each source/pref= erence rank one can specify a list of endpoints that are equivalent, e.g. a= pool of servers that are not behind a load balancer. I am fine with that approach, but as per my other comments, the document sh= ould be explicit about whether there is (or not) a semantics associated to = order of sources (i.e. is the order of sources meant to be a strict prefer= ence, or something else, or are they equivalent?) and whether there is a se= mantics associated to the order of endpoints within a source (i.e is the or= der of endpoints meant to be a strict preference, or something else, or are= they equivalent?) . I think you recommend =93priority for sources=94 and = =93equivalent for endpoints=94. That works for me, but we want that to be m= ade explicit and agreed by the group. Francois > Ben >=20 From nobody Wed Apr 16 05:18:08 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26271A0145 for ; Wed, 16 Apr 2014 05:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.473 X-Spam-Level: X-Spam-Status: No, score=-7.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_FROM=2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-fUiVIZWNky for ; Wed, 16 Apr 2014 05:18:00 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 942091A0135 for ; Wed, 16 Apr 2014 05:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7246; q=dns/txt; s=iport; t=1397650665; x=1398860265; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=z/ZF58sJHUWJrkD/b1Gtub5E/ILMas5rbZb739tvTOk=; b=Lxvf5XgmDcPlered2yAn5ojr92lc4QdnZx9MNndTeVLbZynX8w+PxpzS eqqBRw26HaMnnyRIv9fXiDtes8VjajgM4F/dHFY4K6flbKp7LZtcilVs5 +BPAY+dRNKT0MRDEPFlguDvtbgBnpMYkTNh8C5E2PvNKbxVNaM0Fp8t8J o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAMxzTlOtJA2K/2dsb2JhbABZgwaBEsM0gR8WdIIlAQEBAwF5BQsCAQgYLjIlAgQOBYd0CMdnF44vMweDJIEUAQOYZpJJgzGCKw X-IronPort-AV: E=Sophos;i="4.97,872,1389744000"; d="scan'208";a="36276449" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-1.cisco.com with ESMTP; 16 Apr 2014 12:17:45 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s3GCHieV029013 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Apr 2014 12:17:45 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Wed, 16 Apr 2014 07:17:44 -0500 From: "Francois Le Faucheur (flefauch)" To: Niven-Jenkins Ben Thread-Topic: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 5] Thread-Index: AQHPRGr1yeV4B3O4okSfYul82dNGiQ== Date: Wed, 16 Apr 2014 12:17:44 +0000 Message-ID: References: <18D8DD69-FA99-400B-83A0-A47790AB0209@cisco.com> <2483D9BF-A4DD-440D-9D0B-E5161912ECF1@niven-jenkins.co.uk> In-Reply-To: <2483D9BF-A4DD-440D-9D0B-E5161912ECF1@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.197] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/9qQTzTIMRzBpwhjUiecI9xqiPE4 Cc: "draft-ietf-cdni-metadata@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 5] X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 16 Apr 2014 12:18:06 -0000 On 8 Apr 2014, at 12:43, Ben Niven-Jenkins wrote: > Francois, >=20 > Some comments inline. >=20 > On 20 Mar 2014, at 18:33, Francois Le Faucheur (flefauch) wrote: >=20 >> *** section 4.2.2, 4.2.3 and 4.2.4. >> It appears that the three types of allow/deny (LocationACL, TimeWindowAC= L and ProtocolACL) and independent of each other. >> So I can say , for this content: >> (i) allow it in this Footprint and block it everywhere else >=20 > Yes >=20 >> (ii) allow it in this timewindow and block it at any other time. >=20 > Yes >=20 > and you can also express: allow it in this footprint for this time window= and block it from any other footprint or in any other time window. >=20 >> Is it possible to say , for this content: >> (i) allow it in this timewindow from this footprint >=20 >> (ii) allow it in a different timewindow ffrom this other footprint >=20 >> (iii) block it otherwise? >=20 > No >=20 >> Either way, can you ensure there is a discussion about that (perhpas it = comes up further down in the document and I have not seen it)? >> If you feel this extra flexibility is not needed, then please state so (= and ideally indicate whether it could be added in teh future without breaki= ng all the current object structure). If this flexibility is supported , th= en please add a note/example explaining how.=20 >=20 > If we want to support policies that allow us to express complex combinati= ons of different types of ACL that could be done but I think it introduces = quite a bit of extra complexity so I=92d like to understand the use case fo= r needing it better first. >=20 > Do content providers rely on CDNs to enforce such combinations of differe= nt time windows in different footprints. Or do they use ACLs in the CDN to = enforce broad policy by footprint and/or time window and use other mechanis= ms such as URI signing & not returning URIs to User Agents outside of the t= ime window by their CMS for more fine grained control? I am not arguing we need the extra flexibility. But I recommend that the te= xt makes it clear as to what the current properties allow and don=92t allow= (eg along the lines of what is said above). If one wnated to add the extra flexibility later, do you have a feel for wh= ether this could be achieved by extending the current properties ? or would= one have to define completely new properties superseding the current ones? >=20 >> *** section 4.2.4 >> =93 >> Property: action >> Description: Defines whether the rule specifies protocols to >> allow or deny. >> ... >> Property: direction >> Description: Defines whether the ProtocolRule specifies >> protocols for acquisition or delivery. >> =93 >> I don=92t quite get the semantics of this object when direction=3Dacquis= ition.=20 >> If it conditions how the dCDN is meant to change protocol to acquire the= content , then it shoudl not be cast as an allow/deny, but probably more a= s part of the =93source=94 object that defines acquisition behaviour. >=20 > I don=92t remember why the direction property got introduced and I=92m st= ruggling to think of a reason for it. Protocol ACLs are for defining delive= ry protocols. Acquisition protocols should be specified in the Source objec= t. >=20 > Unless one of my co-authors can recall why we introduced it, I suggest we= remove the direction property altogether. That works for me. >=20 >> *** section 4.2.6: >> "An Auth object defines authentication and authorization methods =93 whi= le 4.2.5 says "authorization methods =93. Is it authorization or both auth= entication and authorisation? >=20 > Good question. I think it can be either. IIRC we=92re reusing the same Au= th object to convey Authorisation of User Agent requests (if it=92s include= d in a HostMetadata or PathMetadata object) and also Authentication and/or = Authorisation to an Acquisition Source (if it is included in the auth prope= rty of a Source object). That=92s a good explanation. Can you convey that in the document, and make = sure =93authentication=94, =93authorization=94 and "authentication and aut= horization=94 are used accurately ? >=20 > That=92s probably not obvious because we don=92t actually specify Auth ty= pes that cover authorisation of user agent requests. >=20 >> *** section 4.2.7 >> =93 >> Mandatory-to-Specify: No. Default is to consider query string >> parameters when comparing URIs or to rely on other properties >> of the Cache object. >> =93=20 >> What does =93rely on other properties of the Cache object=94 actually me= an? there is no other properties in that object. >=20 > I=92m not sure to be honest. I think we anticipated having other modifier= s in the Cache object at some point, which we never included in the end, bu= t I don=92t recall. So you could just remove =93rely on other properties of the Cache object=94= , right? >=20 >> *** general question about multiple instances of objects. >> Is it correct that one expects only a single instance of top level objec= ts inside a given generic metadata object? >> For example, there shoudl only be a single sources Metadata object (whic= h obvisouly can contain a list), but I should not have two sources, right? >=20 > Correct. >=20 >> Is this explicitely stated somewhere? Can you ensure it is stated and it= is also stated what happens if you receive two of the same objects (only k= eep the first one? in case of transit, redistribute or drop the other insta= nces?) >=20 > I think we can say that uCDN MUST NOT include more than one of the same o= bject and that if they do then dCDN SHOULD use the first one in the list. That works for me.=20 When crafting the final text, please think carefully about whether the stat= ement applies to all objects or whether it only applies to a subset of obje= cts (which obviously need to be identified). >=20 > I don=92t have a strong opinion one way or the other in the case of trans= it.=20 I don=92t have a strong view either. =93redistribute" has the benefit that if a 2nd instance is used in some une= xpected vendor-specifc way, this can be propagated. =93drop=94 has the benefit of removing what would normally be useless redun= dant information. Perhaps a SHOUL drop is the way to go (ie drop unless you know better). >=20 >> *** section 6.2 : >> =93 >> If any >> PathMetadata match the request (and are linked rather than embedded), >> the CDNI metadata client makes another GET request for the >> PathMetadata. >> " >> The fact that the text says =93match=94 instead of =93matches=94 raises = teh question of what hapens when more than one does match. Looking back at = 4.1.3, I don=92t see the answer to that question. I may have already commen= ted on that question. In any case, please make sure this is specified (I wo= uld suggest in 4.1.3 and possibly in section 6.2 where you describe the un= -pilling of metadata). >=20 > I=92d suggest first match wins, but you=92re right we should specify it s= omewhere. Good. >=20 > Ben >=20 From nobody Wed Apr 16 05:28:28 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32891A0146 for ; Wed, 16 Apr 2014 05:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvh8bUZPH6VL for ; Wed, 16 Apr 2014 05:28:25 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1F11A0145 for ; Wed, 16 Apr 2014 05:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3773; q=dns/txt; s=iport; t=1397651302; x=1398860902; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=an7ROjmpBaaWfcraCjc74rZmZHkamAu34KPB8RA45vM=; b=WC39esp8ZSnwOq2FyQPNCf9c4klU8diwtxJwYUOn/SQ0o+7HwxwGHRJl kcxIGYvz4hf2RdvgF5Ic3o9ueLbd2aR9c7LI1aWXtB1z3ewAPgKwe1c64 5NyTCooprr/W4Ypiim1GtIUQo6be3g5vNZ3OwLpOpzltVhLqzo8SWTuNR I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAOd2TlOtJV2Y/2dsb2JhbABPCoMGO1fDNIEgFnSCJQEBAQMBeQULAgEIGC4yJQIEDgWHdAjHcheOBikzB4MkgRQEmGaSSYMxgis X-IronPort-AV: E=Sophos;i="4.97,872,1389744000"; d="scan'208";a="36292072" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP; 16 Apr 2014 12:28:21 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3GCSLYL021556 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Apr 2014 12:28:21 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Wed, 16 Apr 2014 07:28:21 -0500 From: "Francois Le Faucheur (flefauch)" To: Niven-Jenkins Ben Thread-Topic: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 6] Thread-Index: AQHPR5Lilga6cDELrEes+o61AeZYVg== Date: Wed, 16 Apr 2014 12:28:20 +0000 Message-ID: References: <5152EB8C-8B72-40A7-A0B3-0C887CA35258@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.55.161.197] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/sWZw0QXBVZBMrVqicVrOtbwnvnA Cc: "draft-ietf-cdni-metadata@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 6] X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 16 Apr 2014 12:28:27 -0000 (agreed items removed)=20 On 8 Apr 2014, at 13:44, Ben Niven-Jenkins wrote: > Francois, >=20 > See inline for a couple of comments. >=20 > On 24 Mar 2014, at 18:57, Francois Le Faucheur (flefauch) wrote: >=20 >> *** section 6.4: >> "Embedded, where the object is contained (or inlined) within a >> property of an addressable object.=94 >> What is the difference between =93inlined=94 and =93contained=94? >=20 > They are synonyms for the same thing. I don=92t think adding =93inlined=94 brings much, since (to me) it is less = clear and less commonly used than =93contained=94. So how about: s/contained (or inlined)/contained/ >=20 >> *** section 7.1: >> "the version number of the GenericMetadata set to which the >> standard capability applies,=94 >> I can=92t parse that. I am not sure what is this version as compared to = the versions that appear in MIME-Type. >=20 > I think this section needs some work. Good. When the new text is ready, please flag that on the list as this may involv= e non-negligible changes worth getting reviews. > It also says "The version field should be incremented when new GenericMet= adata type sets are added to the registry=94, which is not what I think we = want. When a new version is defined it should get its own entry in the regi= stry, it shouldn=92t =91overwrite=92 the existing entry. >=20 >> I am also a bit confused now as to the need to register those object nam= es, beause the Metadata Object names registered here actually never appear = in the encoded Metadata (which only lists the corresponding set of properti= es).. >=20 > I think this may be a historical carry through. The way a Generic Metadat= a object is identified is through its type property. The value of the type = property is a Media Type. It may have been the Metadata Object name in the = past, I don=92t recall. I think what we need to do is replace the Type Name= s with the actual Media Types registered for each object? That sounds right. That will cleans things up . Please work out the ramific= ations this may have in different parts of the document.=20 And I think that will also address my comments below. Thanks Francois >=20 >> Actually, this raises a serious high level question in my mind on the wa= y the metadata objects are defined. >> So you define objects by names (eg HostIndex). But these object names ne= ver appear in the actually encoding. What appears are the properties compri= sed under the object name (e.g. =93hosts=94 for HostIndex). So it is the fi= rst property name appearing (eg =93hosts=94) that needs to be parsed to act= ually identify what objects this is (and therefore what other properties fo= llow). >=20 > No. The top level object in the response does not include the Metadata Ob= ject names but the response include a Media Type in the Content-Type HTTP h= eader that identifies the type of object being returned. =20 >=20 > For generic Metadata, again the Metadata Object names are not included bu= t the type property of the Generic Metadata object contains the Media Type = of the object contained in the value property. >=20 >> Now if you want to keep that approach, then you need to make sure that a= new object allocated in the GenericMetadata Type registry never allocates = the same first =93property name=94, right? otherwise you can=92t parse teh= encoding and know which object it is. I don=92t think any such restriction= s is currently identified in the document. >=20 > See above, I don=92t think clashes are an issue as new objects will have = new Media Types defined that do not clash with the existing media types. >=20 > Ben >=20 >=20 From nobody Fri Apr 18 10:07:34 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADF91A01FE for ; Fri, 18 Apr 2014 10:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.173 X-Spam-Level: X-Spam-Status: No, score=-9.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_42=0.6, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pm0nRF2eLyE for ; Fri, 18 Apr 2014 10:07:28 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD091A01DE for ; Fri, 18 Apr 2014 10:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4494; q=dns/txt; s=iport; t=1397840844; x=1399050444; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=qm9hRMolkhBU0QfmLimKJHXVKf1nF0AzhQbt+rTxAY4=; b=dJbMqpTyzEsgjuV3pWEw7AuUajjc/XIR9a8Bm22f3+rVYRyVFIdNTmiq Xn02udvKNb0WyQJXv4C80x9WsnYyS/Nth+U4APSNXb/HuZw9U24E7NGpN MfYRl0DX384AuRbEhqCEpODwi260lQilC+oeQTwMia5F1cvZn9Q6INarP k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAE9bUVOtJA2D/2dsb2JhbABagwZPV8N0gR0WdIIseRIBLVMnBA6IRs0aF45igyuBFASVAINukk+DMYIr X-IronPort-AV: E=Sophos;i="4.97,885,1389744000"; d="scan'208";a="36961334" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP; 18 Apr 2014 17:07:24 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s3IH7O1k008961 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Apr 2014 17:07:24 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Fri, 18 Apr 2014 12:07:23 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: cdni-logging : Proposed adjustments on MUST/SHOULD/MAY Thread-Index: AQHPWyiq6YspE+w3vkCZBF90v1PnIQ== Date: Fri, 18 Apr 2014 17:07:22 +0000 Message-ID: <7C4FD086-4264-443B-8791-6FE7C48C7FB1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.197] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8124D79BDA440149B128A1FEA27D3503@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/0eLeux91qZ4UYj_tVVZ_xTaxl44 Cc: ietfdbh Subject: [CDNi] cdni-logging : Proposed adjustments on MUST/SHOULD/MAY X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 17:07:32 -0000 Folks, (as a cdni-logging author) David kindly conducted an early OPSDIR review of cdni-logging (and a very t= horough one, I may add).=20 This message discusses the proposed resolutions that affect MUST/SHOULD/MAY= statements. Please review/comment: 1) Current text: " The fields names listed in the "Fields" directive MAY be listed in the order in which they are listed in Section 3.4.1 or MAY be listed in any other order. =93 The proposal is to replace by: " The fields names listed in the "Fields" directive MUST be listed in the order in which they are listed in Section 3.4.1. =93 This would simplify implementation a bit and facilitates interoperability. Can anyone see a good use case for exchanging fields in a different order? 2) Current text: =93 The server-side implementation SHOULD use HTTP cache control headers on the subscription feed to indicate the frequency at which the client-side is to poll for updates. =93 The proposal is to replace by: =93 The server-side implementation MUST set HTTP cache control headers on the subscription feed to indicate the frequency at which the client-side is to poll for updates. =93 This would simplify implementation a bit and facilitates interoperability. Can anyone see a good use case for not setting cache control headers (note = that the other side may decide to poll independently of those, but at least= it knowd those are always valid) ? 3) Current text: " If it supports redundant CDNI Logging feed, the client-side SHOULD use the UUID of the CDNI Logging File, presented in the atom:id element of the Atom feed, to avoid unnecessarily pulling and storing each CDNI Logging File more than once. =93 The proposal is to replace by: =93 If it supports redundant CDNI Logging feed, the client-side MUST use the UUID of the CDNI Logging File, presented in the atom:id element of the Atom feed, to avoid unnecessarily pulling and storing each CDNI Logging File more than once. " This would simplify implementation a bit and facilitates interoperability. Can anyone see a good use case for not using the UUID?=20 4)=20 In section 4.2 , current text =93 To do so, the client-side: o MUST use HTTP v1.1 [RFC2616]; " The proposal is to edit the text to say that the client-side MUST implement= HTTP v1.1 and MAY also support other HTTP versions and MAY negotiate which= HTTP version is actually used. THis woudl allow to move to HTTP v2 while = still complying with the spec. The server-side text probably needs the corresponding adjustments. 5) Current text: =93 o SHOULD support exchange of CDNI Logging Files with "gzip" content encoding (as defined in [RFC2616]) applied to the representation. " The proposal is to replace by: =93 o MUST support exchange of CDNI Logging Files with "gzip" content encoding (as defined in [RFC2616]) applied to the representation. =93 Given the concern about size of logging file it feel useful to have at leas= t one common compression scheme. 6) Current text: =93 In an environment where any such protection is required, TLS SHOULD be used for transport of the CDNI Logging feed and the CDNI Logging File pull unless alternate methods are used for ensuring the confidentiality of the information in the logging files (such as setting up an IPsec tunnel between the two CDNs or using a physically secured internal network between two CDNs that are owned by the same corporate entity). Both parties of the transaction (uCDN and dCDN) SHOULD use mutual authentication. =93 The proposal is to update to: =93 In an environment where any such protection is required, TLS SHOULD be used (including authentication of the remote end) by the server-side a= nd the client-side of the CDNI Logging feed and of the CDNI Logging pull me= chanism unless alternate methods are used for ensuring the confidentiality of the information in the logging files (such as setting up an IPsec tunnel between the two CDNs or using a physically secured internal network between two CDNs that are owned by the same corporate entity). =93 This is because it does not really make sense to say that =93both ends use = mutual authentication=94, rather both ends need to authenticate the remote = end (which collectively achieves mutual authentication). =20 Any concern with that? Francois= From nobody Fri Apr 18 16:40:33 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49D31A0505 for ; Fri, 18 Apr 2014 16:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.428 X-Spam-Level: X-Spam-Status: No, score=0.428 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZuMuMb-xs_d for ; Fri, 18 Apr 2014 16:40:28 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 2A16E1A0503 for ; Fri, 18 Apr 2014 16:40:28 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta06.westchester.pa.mail.comcast.net with comcast id rbWv1n0040vyq2s56bgPBz; Fri, 18 Apr 2014 23:40:23 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta05.westchester.pa.mail.comcast.net with comcast id rbgP1n00L2yZEBF3RbgPrH; Fri, 18 Apr 2014 23:40:23 +0000 From: "ietfdbh" To: "'Francois Le Faucheur \(flefauch\)'" , References: <7C4FD086-4264-443B-8791-6FE7C48C7FB1@cisco.com> In-Reply-To: <7C4FD086-4264-443B-8791-6FE7C48C7FB1@cisco.com> Date: Fri, 18 Apr 2014 19:39:55 -0400 Message-ID: <039101cf5b5f$812cc790$838656b0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJh5O8GRf2FVleY5aSLiPCAjYlStZny63tw Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397864423; bh=RKR/+LWXawyKvmrvakEFzlxQ2WDfctrm7Z+92Txqn8E=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=K9HtSPxZ0UCADi2tjIEA0ukqX/TP1IpUyZHSmoyFcdx71irpppkdXzDW+t+37S0xf 2GWZdvtwVQe6NlTPZp0Tftr9lpiPTjh6RlzF+0VvESZzqf6YNAkwUorwREboNHFdRR EjxPC98QhfpHMBTjl1lwkZptqGrJJZnYnb0pxErZI81lCFl70Mx16vu+1gd5AST0mH kpwJJP4zQzt6tOhnIk7zutrbcBsXFNlCSTHx8k7gx4rTO2SnQC2r61f4FFs/QXM0az 0BNImWOIcwAuRHdSripCTTIBwgPZXFG9nnmXJ22ksfFOzvsagdHDkP0bxQsGYlWW8L qna98iV+oDUHw== Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/E57oUEZ8Fnn7KBp1hAQO_zoouyw Subject: Re: [CDNi] cdni-logging : Proposed adjustments on MUST/SHOULD/MAY X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 18 Apr 2014 23:40:30 -0000 Hi, Inline. David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] > Sent: Friday, April 18, 2014 1:07 PM > To: cdni@ietf.org > Cc: Francois Le Faucheur (flefauch); ietfdbh > Subject: cdni-logging : Proposed adjustments on MUST/SHOULD/MAY > > Folks, > > (as a cdni-logging author) > > David kindly conducted an early OPSDIR review of cdni-logging (and a very > thorough one, I may add). > > This message discusses the proposed resolutions that affect > MUST/SHOULD/MAY statements. Please review/comment: > [...] > > 2) > Current text: > " > The server-side implementation SHOULD use HTTP cache control headers > on the subscription feed to indicate the frequency at which the > client-side is to poll for updates. > " > The proposal is to replace by: > " > The server-side implementation MUST set HTTP cache control headers > on the subscription feed to indicate the frequency at which the > client-side is to poll for updates. > " > This would simplify implementation a bit and facilitates interoperability. > Can anyone see a good use case for not setting cache control headers (note > that the other side may decide to poll independently of those, but at least it > knowd those are always valid) ? > Forgive me if I should already know this. Section 4 talks about managing the ATOM feed, but only once does it mention HTTP, and that is the sentence you are discussing. Is HTTP the only way to control the frequency of polling? Or does it just make the most sense since this document focuses on HTTP? If, for whatever reason, an implementer or operator chose not to support HTTP cache control headers, Could an implementer/operator choose another protocol to specify the polling frequency? Are cache control headers at all controversial, say for security considerations? [...] > > 4) > In section 4.2 , current text > " > To do so, the client-side: > o MUST use HTTP v1.1 [RFC2616]; > " > The proposal is to edit the text to say that the client-side MUST implement > HTTP v1.1 and MAY also support other HTTP versions and MAY negotiate > which HTTP version is actually used. THis woudl allow to move to HTTP v2 > while still complying with the spec. > The server-side text probably needs the corresponding adjustments. s/ THis woudl allow to move to HTTP v2 while still complying with the spec./This would allow operators and implementers to choose to use later versions of HTTP to take advantage of new features, while still ensuring interoperability with systems that only support v.1.1./ [...] > > Francois= dbh From nobody Tue Apr 22 00:47:21 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2011A0125 for ; Tue, 22 Apr 2014 00:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHENGzWHhsv2 for ; Tue, 22 Apr 2014 00:47:15 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id A91D01A0138 for ; Tue, 22 Apr 2014 00:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1030; q=dns/txt; s=iport; t=1398152820; x=1399362420; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ONsjAli6VUodBFMwkBsiQRPOH4X/htEXIKW5JXCNStE=; b=fCjemqXSwmKj9WGWsCobk9ejlfEB8QWts8rIgIo09ozPkFxNxhNWo7WQ Z2Jwls6thxAT2XRie/9pZ0GcW4p8lPZ8I3e77cPNnU/HpcXNUsWJv+9Q/ ShzQG1Npw2prZgbkfgd/XPHF/PEIgIjKsE0f4oLKnXHtKJ7hHbnJPsY9o M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAB0dVlOtJA2M/2dsb2JhbABWA4MGT1fEF4EdFnSCJQEBAQMBeQULAgEIRjIlAgQOBYgtAwkIxUgIhnAXjiMjEAcRgxOBFAEDmHCSUoMxgis X-IronPort-AV: E=Sophos;i="4.97,902,1389744000"; d="scan'208";a="37681753" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-8.cisco.com with ESMTP; 22 Apr 2014 07:47:00 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s3M7l0tI010673 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Apr 2014 07:47:00 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Tue, 22 Apr 2014 02:47:00 -0500 From: "Francois Le Faucheur (flefauch)" To: ietfdbh Thread-Topic: cdni-logging : Proposed adjustments on MUST/SHOULD/MAY Thread-Index: AQHPXf8KijjmV2dPA06kPUBF5wl0Jw== Date: Tue, 22 Apr 2014 07:46:59 +0000 Message-ID: <5594166F-88DC-4B9C-AC39-0A08A9521CCB@cisco.com> References: <7C4FD086-4264-443B-8791-6FE7C48C7FB1@cisco.com> <039101cf5b5f$812cc790$838656b0$@comcast.net> In-Reply-To: <039101cf5b5f$812cc790$838656b0$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.101.7] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/TliiEqmKzsKoYnChWHzCvbzMbIQ Cc: "cdni@ietf.org" Subject: Re: [CDNi] cdni-logging : Proposed adjustments on MUST/SHOULD/MAY X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 07:47:19 -0000 On 19 Apr 2014, at 01:39, ietfdbh wrote: > Hi, >=20 > Inline. >=20 > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 >=20 <=85> >>=20 >> 4) >> In section 4.2 , current text >> " >> To do so, the client-side: >> o MUST use HTTP v1.1 [RFC2616]; >> " >> The proposal is to edit the text to say that the client-side MUST > implement >> HTTP v1.1 and MAY also support other HTTP versions and MAY negotiate >> which HTTP version is actually used. THis woudl allow to move to HTTP v= 2 >> while still complying with the spec. >> The server-side text probably needs the corresponding adjustments. >=20 > s/ THis woudl allow to move to HTTP v2 while still complying with the > spec./This would allow operators and implementers to choose to use later > versions of HTTP to take advantage of new features, while still ensuring > interoperability with systems that only support v.1.1./ Agreed. Thanks. >=20 > [...] >=20 >>=20 >> Francois=3D >=20 > dbh >=20 From nobody Tue Apr 22 00:48:33 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E67161A0134 for ; Tue, 22 Apr 2014 00:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjNdvduXBOa9 for ; Tue, 22 Apr 2014 00:48:30 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 30DD81A0125 for ; Tue, 22 Apr 2014 00:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2230; q=dns/txt; s=iport; t=1398152902; x=1399362502; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iSygbS0Vwqh58blttG8dXMgbSoOS+y7cnuMIjvqjBos=; b=OsEHMrhOvkNXczxOG2B14sEc3zHAVKPCgyby9UMVU6pMQwa0Mlifuneo 4QCkMDoud8Jt8Gt6sHuGPS/hYElHDptxOeG51KHayKCb2oWVO/D9PQbxg kmzOSt0ZBdvlEMX10FnKZoHvJWpaivre5RwbRQtnblgud1gddVYodmNGm 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAAYeVlOtJV2d/2dsb2JhbABWA4MGT1fEF4EbFnSCJQEBAQMBOj8FBwQCAQgOAwQBAQ4RCQcyFAkIAgQBDQWILQMJCMVHCIZwF44jIxAHBguDE4EUAQOYcJJSgzGCKw X-IronPort-AV: E=Sophos;i="4.97,902,1389744000"; d="scan'208";a="319399548" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 22 Apr 2014 07:48:21 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s3M7mLBe001573 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Apr 2014 07:48:21 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Tue, 22 Apr 2014 02:48:21 -0500 From: "Francois Le Faucheur (flefauch)" To: Rob Murray , Niven-Jenkins Ben Thread-Topic: cdni-logging : Proposed adjustments on MUST/SHOULD/MAY Thread-Index: AQHPXf87mcmLBPltakK4cV7wITvfng== Date: Tue, 22 Apr 2014 07:48:20 +0000 Message-ID: References: <7C4FD086-4264-443B-8791-6FE7C48C7FB1@cisco.com> <039101cf5b5f$812cc790$838656b0$@comcast.net> In-Reply-To: <039101cf5b5f$812cc790$838656b0$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.101.7] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/f9iXSO9LciqyLYr7bkoQVlrTnIc Cc: "cdni@ietf.org" , ietfdbh Subject: Re: [CDNi] cdni-logging : Proposed adjustments on MUST/SHOULD/MAY X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 07:48:33 -0000 Rob, Ben,=20 Any thoughts on the ATOM feed polling control question below? On 19 Apr 2014, at 01:39, ietfdbh wrote: > Hi, >=20 > Inline. >=20 > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 >=20 >> -----Original Message----- >> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] >> Sent: Friday, April 18, 2014 1:07 PM >> To: cdni@ietf.org >> Cc: Francois Le Faucheur (flefauch); ietfdbh >> Subject: cdni-logging : Proposed adjustments on MUST/SHOULD/MAY >>=20 >> Folks, >>=20 >> (as a cdni-logging author) >>=20 >> David kindly conducted an early OPSDIR review of cdni-logging (and a ver= y >> thorough one, I may add). >>=20 >> This message discusses the proposed resolutions that affect >> MUST/SHOULD/MAY statements. Please review/comment: >>=20 > [...] >>=20 >> 2) >> Current text: >> " >> The server-side implementation SHOULD use HTTP cache control headers >> on the subscription feed to indicate the frequency at which the >> client-side is to poll for updates. >> " >> The proposal is to replace by: >> " >> The server-side implementation MUST set HTTP cache control headers >> on the subscription feed to indicate the frequency at which the >> client-side is to poll for updates. >> " >> This would simplify implementation a bit and facilitates interoperabilit= y. >> Can anyone see a good use case for not setting cache control headers (no= te >> that the other side may decide to poll independently of those, but at > least it >> knowd those are always valid) ? >>=20 > Forgive me if I should already know this. >=20 > Section 4 talks about managing the ATOM feed, but only once does it menti= on > HTTP, and that is the sentence you are discussing. > Is HTTP the only way to control the frequency of polling? Or does it just > make the most sense since this document focuses on HTTP? >=20 > If, for whatever reason, an implementer or operator chose not to support > HTTP cache control headers, > Could an implementer/operator choose another protocol to specify the poll= ing > frequency? > Are cache control headers at all controversial, say for security > considerations? >=20 > [...] From nobody Tue Apr 22 07:40:29 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79671A0499 for ; Tue, 22 Apr 2014 07:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drQdbOqHihfP for ; Tue, 22 Apr 2014 07:40:20 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id AC3FC1A0424 for ; Tue, 22 Apr 2014 07:40:20 -0700 (PDT) Received: from aputeaux-554-1-70-217.w82-124.abo.wanadoo.fr ([82.124.93.217] helo=[192.168.1.132]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1Wcbro-0002Ax-Il; Tue, 22 Apr 2014 15:40:13 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Niven-Jenkins In-Reply-To: <4F2F12C0-A71D-4A32-BDA7-5DE0007B0149@cisco.com> Date: Tue, 22 Apr 2014 15:40:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4A93FDFB-5FE4-4C71-855C-CA321CE477C0@niven-jenkins.co.uk> References: <20140214214618.22993.11019.idtracker@ietfa.amsl.com> <4F2F12C0-A71D-4A32-BDA7-5DE0007B0149@cisco.com> To: Francois Le Faucher X-Mailer: Apple Mail (2.1874) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/tWadGfTAUH0JMQtU6uXYy4In2FM Cc: "draft-ietf-cdni-metadata@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 1] X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 14:40:26 -0000 Francois, Following up on this. I have made all the editorial changes you suggest = below to the authors working copy of -07 so you should see them once we = publish a new version. Ben On 18 Feb 2014, at 16:39, Francois Le Faucheur (flefauch) = wrote: > Folks, >=20 > I=92ve started a WG Chair review of draft-ietf-cdni-metadata-06. Below = is a first batch of comments. >=20 > Francois >=20 >=20 >=20 > ***Title: > s/CDN Interconnect Metadata/CDN Interconnection Metadata/ >=20 >=20 > *** Authors: > You currently list 6 authors, which I think exceeds the maximum = expected number. You may need to consider splitting =93editors=94 and = =93Contributing Authors=94 >=20 >=20 > *** throughout the document: > s/Metadata Interface/Metadata interface/ >=20 >=20 > *** section1: > OLD: > " > CDNI enables a downstream CDN to service content requests on behalf > of an upstream CDN. The CDNI metadata associated with a piece of > content (or with a set of contents) provides a downstream CDN with > sufficient information for servicing content requests on behalf of = an > upstream CDN in accordance with the policies defined by the = upstream > CDN. >=20 > The CDNI Metadata Interface is introduced by [RFC6707] along with > three other interfaces that may be used to compose a CDNI solution > (Control, Request Routing and Logging). [I-D.ietf-cdni-framework] > expands on the information provided in [RFC6707] and describes each > interface, and the relationships between them, in more detail. The > requirements for the CDNI metadata interface are specified in > [I-D.ietf-cdni-requirements]. > =93 > NEW: > =93 > Content Delivery Networks Interconnection (CDNI) ([RFC6707]) enables a = downstream CDN to service content requests on behalf of an upstream CDN. = =20 >=20 > The CDNI Metadata interface is discussed in = [I-D.ietf-cdni-framework] along with > four other interfaces that may be used to compose a CDNI solution > (CDNI Control interface, CDNI Request Routing Redirection interface, = CDNI Footprint & Capabilities Advertisement interface interface and = Logging interface ). [I-D.ietf-cdni-framework] > describes each interface, and the relationships between them. The > requirements for the CDNI metadata interface are specified in > [I-D.ietf-cdni-requirements]. > The CDNI metadata associated with a piece of > content (or with a set of contents) provides a downstream CDN with > sufficient information for servicing content requests on behalf of = an > upstream CDN in accordance with the policies defined by the = upstream > CDN. > " >=20 >=20 > *** section 1: > OLD: > =93 > o A data structure for mapping content requests to CDNI Metadata > properties (Section 3). > =93 > NEW: > =93 > o A data structure for mapping content requests and redirection = requests to CDNI Metadata > properties (Section 3). > =93 >=20 >=20 > *** section 1: > s/Redirection Requests/redirection requests/ > s/Content Requests/content requests/ >=20 >=20 > *** section 1: > =93 > Specifically, this document proposes: > o A data structure for mapping content requests to CDNI Metadata > properties (Section 3). > o An initial set of CDNI Metadata properties (Section 4.2). > o A RESTful web service for the transfer of CDNI Metadata > (Section 6). > =93 > Is there a reason why the metadtaa structure defined in sectio 4.1 is = not mentioned here?=20 > To me it seems an important part of the metadata specification. >=20 >=20 > *** section 2: > s/The proposed CDNI Metadata Interface/The CDNI Metadata Interface/ >=20 > *** section 2: > s/Deterministic mapping from redirection and content = requests/Deterministic mapping from redirection requests and content = requests/ >=20 >=20 > *** section 2: > s/5. Leverage/5. Leveraging of/ >=20 >=20 > OLD: > =93 > Cacheability improves the latency of acquiring metadata while > maintaining its freshness and therefore improves the latency of > serving content requests. The CDNI Metadata Interface uses HTTP to > achieve cacheability. > =93 > NEW: > =93 > Cacheability improves the latency of acquiring metadata while > maintaining its freshness, and therefore improves the latency of > serving content requests and redirection requests, without = sacrifing accuracy. The CDNI Metadata Interface uses HTTP and its = existing cahing mechanisms to > achieve CDNI metadata cacheability. > " >=20 >=20 > *** section 3: > OLD: > =93 > to be retrieved by a dCDN once, even if it is referenced by the CDNI > Metadata of multiple Hostnames. > =93 > NEW: > =93 > to be retrieved and stored by a dCDN once, even if it is referenced by = the CDNI > Metadata of multiple Hostnames or of multiple URI paths. >=20 >=20 > *** title of section 3.1 > s/HostIndex, HostMetadata & PathMetadata objects/HostIndex, = HostMetadata and PathMetadata objects/ >=20 >=20 > *** section 3.1: > s/uCDN's CDNI Metadata data store/uCDN CDNI Metadata data store/ >=20 >=20 > *** section 3.1: > OLD: > =93 > It enables surrogates in the dCDN to > deterministically discover, on receipt of a User Agent request for > content, which other CDNI Metadata objects it requires in order to > deliver the requested content. > =93 > NEW: > =93 > It enables the dCDN to > deterministically discover, on receipt of a User Agent request for > content, which other CDNI Metadata objects it requires in order to > deliver the requested content. > =93 > [Rationale: the MI is intended to be used between uCDN and dCDN. It = might also be used inside teh dCDN and by surrogate sthemselves, but = that is not necessary. So we may want to refer to the MI endpoints as = =93the uCDN=94 and =93dCDN=94 (and not the "dCDN Surrogates=94) ] >=20 >=20 > *** section 3.1: > OLD: > =93 > When looking up CDNI Metadata, the downstream CDN looks > up the requested Hostname (or IP address) in the HostIndex,=20 > =93 > NEW: > =93 > When looking up CDNI Metadata, the downstream CDN looks > up the requested Hostname (or IP address) against the HostMatch = entries in the HostIndex,=20 > =93 >=20 > *** section 3.1: > OLD: > =93 > Besides containing the default CDNI Metadata for the specified > Hostname, HostMetadata and PathMetadata objects may also contain > PathMatch objects which in turn contain PathMetadata objects. > =93 > NEW: > =93 > HostMetadata and PathMetadata objects may also contain > PathMatch objects which in turn contain PathMetadata objects. > =93 > [Rationale: the main part of the sentence is applicable to both = HostMetadata and PathMetadata, which grammatically suggests that the = first part of the sentence is also applicable to both, while it is only = applicable to Hostmetadata] >=20 >=20 > *** section 3.1: > s/For the purposes of retrieving CDNI Metadata all/For the purposes of = retrieving CDNI Metadata, all/ >=20 >=20 > *** section 3.1, Table1. > "The relationships in Figure 1 are summarised in Table 1 below.=94 > I think Table 1, contains the exact same information as Figure 1. = .i.e., Table 1 does not provide a =93summary=94. It just shows the same = information in a different way. Or am I missing some information in = Figure 1 that is not in Table 1? > I was going to comment that perhaps we could get rid of Table 1, but I = can see that it may be worth expressing it in a tabular manner as well, = so I am OK to keep Table 1. But you may want to: > * tweak the text to say something like: > "The relationships in Figure 1 are also represented in a tabular = format in Table 1 below.=94 > * adjust the titles of Figure 1 and Table 1 because it is confusing to = have them show teh same information but have different titles. Maybe = something like: > o "Figure 1: Relationships between CDNI Metadata Objects (Diagram = Representation)=94 > o =93Table 1: Relationships between CDNI Metadata Objects (Table = Representation)=94 >=20 >=20 > *** section 3.1, Table1 > "Objects it References=94 > should this say "Objects it References or Contains=94 ? >=20 >=20 > *** section 3,1: Table 2 > s/A HostMatch object defines a hostname/A HostMatch object defines a = hostname (or IP address)/ >=20 >=20 >=20 > *** Section 3.1, Table 2 > for Hostmatch it says "contains or references=94 > for HostMetadata it says "contains (or references)=94 > you should use the same style (unless there is a reason not to). >=20 >=20 > Begin forwarded message: >=20 >> Resent-From: >> From: >> Subject: New Version Notification - draft-ietf-cdni-metadata-06.txt >> Date: 14 February 2014 22:46:18 CET >> Resent-To: , , = , , , = , , >> To: , = , = >>=20 >>=20 >> A new version (-06) has been submitted for draft-ietf-cdni-metadata: >> http://www.ietf.org/internet-drafts/draft-ietf-cdni-metadata-06.txt >>=20 >>=20 >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata/ >>=20 >> Diff from previous version: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-metadata-06 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> IETF Secretariat. >>=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Tue Apr 22 07:47:48 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507A61A0642 for ; Tue, 22 Apr 2014 07:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRQDCz-KRIBu for ; Tue, 22 Apr 2014 07:47:43 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id CA5141A0646 for ; Tue, 22 Apr 2014 07:46:56 -0700 (PDT) Received: from aputeaux-554-1-70-217.w82-124.abo.wanadoo.fr ([82.124.93.217] helo=[192.168.1.132]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1WcbyE-0002HY-Sg; Tue, 22 Apr 2014 15:46:51 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Niven-Jenkins In-Reply-To: Date: Tue, 22 Apr 2014 15:46:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0D41E73F-3448-4118-B73B-EE2DAAAF6029@niven-jenkins.co.uk> References: <20140214214618.22993.11019.idtracker@ietfa.amsl.com> To: Francois Le Faucher X-Mailer: Apple Mail (2.1874) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/mFlk4TcJ4xqL0ip7d0iw46TVucY Cc: "draft-ietf-cdni-metadata@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 2] X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 22 Apr 2014 14:47:47 -0000 Francois, Just to confirm (as it might be hard to track from the e-mail chain), = Kevin has updated the authors=92 working copy of -07 to incorporate all = the editorial changes you suggest below. The only open issue remaining from this batch of comments is the = definition of a =91Do Not Serve=92 metadata object. That isn=92t purely = editorial so needs a bit of discussion amongst the authors but we=92ve = put an editors note in our working copy of -07 so we don=92t forget to = cover it. Ben On 21 Feb 2014, at 16:34, Francois Le Faucheur (flefauch) = wrote: >=20 > *** section 3.1: Table 2: > "A PathMetadata object contains the CDNI GenericMetadata objects=94 > Should this say =93contains or references=94? > Same comment for =93GenericMetadata=94? > Because of the inconsistencies in the description, I guess I am not = 100% clear at this stage as to whether it is always possible to "either = contain or reference=94, or whetehr there are some cases where it = =93always contains=94. Please make sure this is made clear. >=20 >=20 > *** section 3.2: > OLD: > =93 > If the > dCDN does not understand or support the property type and the > property type is not mandatory to enforce, then the GenericMetadata > object may be safely ignored. > =93 > NEW: > =93 > If the > dCDN does not understand or support the property type and the > property type is not mandatory to enforce, then the GenericMetadata > object may be safely ignored and the dCDN MUST process > the content request in accordance with the rest of the CDNI = metadata. > =93 >=20 >=20 > *** section 3.2:=20 > " > If the dCDN does not understand > or support the property type it is also not going to be able to > properly propagate the Metadata for cascaded distribution.=20 > =93 > This sentence is placed in the middle of the 2nd paragraph while it = discusses metadata redistribution which is not the subject of the 2nd = paragraph and is fully discussed in the 3rd paragraph. So that sentence = should be removed from 2nd paragraph and merged with 3rd paragraph (or = removed altogether it it is redundant with 3rd paragraph).=20 >=20 >=20 > *** section 3.2 > s/optimially/optimally/ >=20 >=20 > ***section 3.2: > I would suggest capitalizing the two terms you define everywhere to = make it clear that these are very precise terms that you define here.=20= > =93Mandatory To Enforce=94 (or =93Mandatory-To-Enforce=94) > =93Safe To Redistribute=94 (or =93Safe-To-Redistribute=94) > another option coudl to quote the corresponding property names defined = later ie =93madatory-to-enforce=94/=93safe-to-redistribute=94. >=20 >=20 > *** section 3.3: > OLD: > =93 > the TimeWindowACL defined in the PathMetadata would override the > TimeWindowACL defined in the HostMetadata > =93 > NEW: > =93 > the TimeWindowACL defined in the PathMetadata would override the > TimeWindowACL defined in the HostMetadata for > all User Agent requests for content under "example.com/movies" > =93 >=20 >=20 > *** section 3.3: > =93 > The PathMetadata defined TimeWindowACL would override the > TimeWindowACL defined in the HostMetadata for all User Agent = requests > for movies. > =93 > This seems 100% redundant with the previous example. If this is = correct, just remove. If this is not correct, clarify what extra = information it brings. >=20 >=20 > *** section 3.4: > =93The type > SHOULD be descriptive, and MAY be hierarchical to support = aggregating > groups of properties for the purpose of readability and for avoiding > name conflicts between vendor extensions. A dotted alpha-numeric > notation is suggested for human readability.=94 > I think all the normative language about metadata types shoudl be = moved to the relevant IANA sub-section (unless we conclude differently = in the thread about that question started in the context of = cdni-logging). So I=92d see all the quoted text above be merged into the = appropriate IANA sub-section. =20 >=20 > *** section 3.4: > " Metadata types defined by this document are not hierarchical." > I suggest adding an explanation or example about what you mean by = =93hierarchical=94. >=20 > On 14 Feb 2014, at 22:46, Internet-Drafts@ietf.org wrote: >=20 >>=20 >> A new version (-06) has been submitted for draft-ietf-cdni-metadata: >> http://www.ietf.org/internet-drafts/draft-ietf-cdni-metadata-06.txt >>=20 >>=20 >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata/ >>=20 >> Diff from previous version: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-metadata-06 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> IETF Secretariat. >>=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Fri Apr 25 07:30:23 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3761A04FA for ; Fri, 25 Apr 2014 07:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.773 X-Spam-Level: X-Spam-Status: No, score=-9.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60M_-XRbTfiw for ; Fri, 25 Apr 2014 07:30:18 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 958EE1A026F for ; Fri, 25 Apr 2014 07:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1590; q=dns/txt; s=iport; t=1398436209; x=1399645809; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=0UGWcl4CnjFBI3+E2xQOWa+6r3YatRNnYkhPKUYOfuU=; b=Nu0iIia4Hta+Z+B4lq6SPRgfTClUwuV35xRw6qbW1zrqVcn6YQ12Qvfk u87yaO98rjz4USm9y4/t3wEdEJxvFxznctZt8n6qV6ad8UeT4/ihn/Z14 bptO88VXy25BhuSe7m4xU15zHFa489LoRuM8n5r2c0wFLySdXjZqs2JvK w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAARxWlOtJA2F/2dsb2JhbABZgwZPV8UuFnSCLIELAYEAJwSIVA2XdrJmF44Fg3+BFQSZBYE4kSSDMYIr X-IronPort-AV: E=Sophos;i="4.97,927,1389744000"; d="scan'208";a="38708110" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP; 25 Apr 2014 14:30:09 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s3PEU935010711 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 25 Apr 2014 14:30:09 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Fri, 25 Apr 2014 09:30:08 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Poll for adoption of draft-leung-cdni-uri-signing-05 as a WG document Thread-Index: AQHPYJLbBLWZVv2kWEicqD5z2NlW1A== Date: Fri, 25 Apr 2014 14:30:08 +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.199] Content-Type: text/plain; charset="Windows-1252" Content-ID: <7ECF12B27D70C54691138E25BD529B62@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/EeUizxPlgRNuW3myNPhSjcMIni4 Subject: [CDNi] Poll for adoption of draft-leung-cdni-uri-signing-05 as a WG document X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 25 Apr 2014 14:30:21 -0000 Folks, During the London meeting: * authors confirmed that they believe the latest version of draft-leung-cd= ni-uri-signing resolved the issue related to draft-ietf-appsawg-uri-get-off= -my-lawn-04.txt. * WG chairs agreed to take to the list the question of adopting draft-leun= g-cdni-uri-signing-05 as a WG document to ensure it gets sufficient review. This message is to encourage review of draft-leung-cdni-uri-signing-05 (htt= p://tools.ietf.org/id/draft-leung-cdni-uri-signing-05.txt) and sollicite fe= edback on adopting it as a WG document to address the corresponding milesto= ne on our charter. Please do so by end of 12 May (ie within the next 2 weeks). Francois & Daryl, CDNI WG Chairs For convenience, quote from IETF-89 CDNI WG meeting minutes : " Daryl (as chair): This is a deliverable on our charter, but not many people= have read the draft yet, so will take question for WG adoption to the list= to give people time to read it.=20 =93 For convenience, relevant excerpt from the CDNI WG charter (http://tools.ie= tf.org/wg/cdni/charters): =93 The working group will focus on the following items: <=85> - A specification for "CDNI URI Signing". This document will specify a mechanism that allows interconnected CDNs to support access control by signing content URIs. This may involve extensions to the CDNI interfaces (e.g. CDNI Metadata interface, CDNI Logging interface). <=85> Goals and Milestones: <=85> Sep 2014 - Submit specification of URI Signing for CDNI to IESG as Propos= ed Standard "= From nobody Fri Apr 25 07:52:14 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0271A04B6 for ; Fri, 25 Apr 2014 07:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.772 X-Spam-Level: X-Spam-Status: No, score=-9.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gT5D6F4hjwXJ for ; Fri, 25 Apr 2014 07:52:04 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 58A0A1A04E8 for ; Fri, 25 Apr 2014 07:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7269; q=dns/txt; s=iport; t=1398437518; x=1399647118; h=from:to:subject:date:message-id:references:mime-version; bh=JmFsXBRU+pvYG078FtIRV+f0uoUJIul6VZRFebKEk5w=; b=PA16NbtuLIiITRzez9f/x4TplIAvsxzo1Lj/JzMCXd05LTYDqlb7yKSl MwXKyewHxy1uTGUt1LZpwKABPv2FNihRfY6ydHUEYWr+iAQcDPSdDgL21 V/bBspRMeyx9hf+h0ohgDFBI05btbamRMCfGYZ0PNPC8ICE2NIM+B0qLp s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFADZ1WlOtJA2J/2dsb2JhbABZgwZPV7smgUKHOIEQFnSCJQEBAQQBAQFrGwIBGQMBAigHJwsUBwIIAgQTCYg4DcpRF44FAwEBPhcHgih2gRUEmQWBOJEkgXKBP4FyOQ X-IronPort-AV: E=Sophos; i="4.97,927,1389744000"; d="scan'208,217"; a="38709378" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-6.cisco.com with ESMTP; 25 Apr 2014 14:51:57 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3PEpvm8010511 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 25 Apr 2014 14:51:57 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Fri, 25 Apr 2014 09:51:57 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: [CDNi] Poll for adoption of draft-leung-cdni-uri-signing-05 as a WG document Thread-Index: AQHPYJXnTK3paN8uOk+QQc+WLZgWaA== Date: Fri, 25 Apr 2014 14:51:56 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.199] Content-Type: multipart/alternative; boundary="_000_BDC9627DFE534A6B95AD4D678F72F74Eciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/fTl5nKaAVtz5basJX7f-zJAY8Zs Subject: [CDNi] Fwd: Poll for adoption of draft-leung-cdni-uri-signing-05 as a WG document X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 25 Apr 2014 14:52:08 -0000 --_000_BDC9627DFE534A6B95AD4D678F72F74Eciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Folks, Just to be clear, this is a follow up from Daryl=92s earlier message of 25 = April (http://www.ietf.org/mail-archive/web/cdni/current/msg01837.html), wh= ich issued a similar request. We did not received much feedback so would li= ke to give another opportunity for more feedback. Francois Begin forwarded message: From: "Francois Le Faucheur (flefauch)" > Subject: [CDNi] Poll for adoption of draft-leung-cdni-uri-signing-05 as a W= G document Date: 25 April 2014 16:30:08 CEST To: "cdni@ietf.org" > Folks, During the London meeting: * authors confirmed that they believe the latest version of draft-leung-cdn= i-uri-signing resolved the issue related to draft-ietf-appsawg-uri-get-off-= my-lawn-04.txt. * WG chairs agreed to take to the list the question of adopting draft-leung= -cdni-uri-signing-05 as a WG document to ensure it gets sufficient review. This message is to encourage review of draft-leung-cdni-uri-signing-05 (htt= p://tools.ietf.org/id/draft-leung-cdni-uri-signing-05.txt) and sollicite fe= edback on adopting it as a WG document to address the corresponding milesto= ne on our charter. Please do so by end of 12 May (ie within the next 2 weeks). Francois & Daryl, CDNI WG Chairs For convenience, quote from IETF-89 CDNI WG meeting minutes : " Daryl (as chair): This is a deliverable on our charter, but not many people= have read the draft yet, so will take question for WG adoption to the list= to give people time to read it. =93 For convenience, relevant excerpt from the CDNI WG charter (http://tools.ie= tf.org/wg/cdni/charters): =93 The working group will focus on the following items: <=85> - A specification for "CDNI URI Signing". This document will specify a mechanism that allows interconnected CDNs to support access control by signing content URIs. This may involve extensions to the CDNI interfaces (e.g. CDNI Metadata interface, CDNI Logging interface). <=85> Goals and Milestones: <=85> Sep 2014 - Submit specification of URI Signing for CDNI to IESG as Propose= d Standard " _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_BDC9627DFE534A6B95AD4D678F72F74Eciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Folks,

Just to be clear, this is a follow up from Daryl=92s earlier message o= f 25 April (http://www.ietf.org/mail-archive/web/cdni/current/msg01837.htm= l), which issued a similar request. We did not received much feedback so would like to give another opportunit= y for more feedback.

Francois

Begin forwarded message:

From:= "Francois Le Fauc= heur (flefauch)" <flefauch@ci= sco.com>
Subje= ct: [CDNi] Poll for adoption= of draft-leung-cdni-uri-signing-05 as a WG document
Date:= 25 April 2014 16:30:08= CEST

Folks,

During the London meeting:
* authors c= onfirmed that they believe the latest version of draft-leung-cdni-uri-signi= ng resolved the issue related to draft-ietf-appsawg-uri-get-off-my-lawn-04.= txt.
* WG chairs= agreed to take to the list the question of adopting draft-leung-cdni-uri-s= igning-05 as a WG document to ensure it gets sufficient review.

This message is to encourage review of draft-leung-cdni-uri-signing-05 (http:= //tools.ietf.org/id/draft-leung-cdni-uri-signing-05.txt) and sollicite = feedback on adopting it as a WG document to address the corresponding milestone on our charter.
Please do so by end of 12 May (ie within the next 2 weeks).

Francois & Daryl, CDNI WG Chairs



For convenience, quote from IETF-89 CDNI WG meeting minutes :
"
Daryl (as chair): This is a deliverable on our charter, but not many people= have read the draft yet, so will take question for WG adoption to the list= to give people time to read it.
=93


For convenience, relevant excerpt from the CDNI WG charter (http://tools.ietf.org/wg/cdni/charters<= /a>):
=93
The working group will focus on the following items:
<=85>
 - A specification for "CDNI URI Signing". This document wil= l specify a
   mechanism that allows interconnected CDNs to support acce= ss control
   by signing content URIs. This may involve extensions to t= he CDNI
   interfaces (e.g. CDNI Metadata interface, CDNI Logging in= terface).

<=85>

Goals and Milestones:
<=85>
 Sep 2014 - Submit specification of URI Signing for CDNI to IESG as Pr= oposed Standard
"
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

--_000_BDC9627DFE534A6B95AD4D678F72F74Eciscocom_-- From nobody Fri Apr 25 09:53:25 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC091A0268 for ; Fri, 25 Apr 2014 09:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.799 X-Spam-Level: * X-Spam-Status: No, score=1.799 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nP-J1VfNBEPI for ; Fri, 25 Apr 2014 09:53:20 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id A429A1A064F for ; Fri, 25 Apr 2014 09:53:19 -0700 (PDT) Received: from host4.velocix.com ([81.134.152.4] helo=xxx.corp.velocix.com) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1WdjN9-0001vo-0W; Fri, 25 Apr 2014 17:53:11 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Niven-Jenkins In-Reply-To: <7C4FD086-4264-443B-8791-6FE7C48C7FB1@cisco.com> Date: Fri, 25 Apr 2014 17:53:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <94DAC133-0CA7-4772-AA80-0F6D7D21A39C@niven-jenkins.co.uk> References: <7C4FD086-4264-443B-8791-6FE7C48C7FB1@cisco.com> To: Francois Le Faucher X-Mailer: Apple Mail (2.1874) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/MKmJwVeo1oZOB5SdD_EWb8y89Lc Cc: "cdni@ietf.org" , ietfdbh Subject: Re: [CDNi] cdni-logging : Proposed adjustments on MUST/SHOULD/MAY X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 25 Apr 2014 16:53:22 -0000 Francois, Rob, Grant and I chatted this over, our thoughts are inline below. On 18 Apr 2014, at 18:07, Francois Le Faucheur (flefauch) = wrote: > Folks, >=20 > (as a cdni-logging author) >=20 > David kindly conducted an early OPSDIR review of cdni-logging (and a = very thorough one, I may add).=20 >=20 > This message discusses the proposed resolutions that affect = MUST/SHOULD/MAY statements. Please review/comment: >=20 > 1) > Current text: > " > The fields names listed in the "Fields" directive MAY be listed in > the order in which they are listed in Section 3.4.1 or MAY be listed > in any other order. > =93 > The proposal is to replace by: > " > The fields names listed in the "Fields" directive MUST be listed in > the order in which they are listed in Section 3.4.1. > =93 > This would simplify implementation a bit and facilitates = interoperability. > Can anyone see a good use case for exchanging fields in a different = order? We=92re not convinced such a change does actually simplify = implementation. Each implementation (CDN) will have its own internal log = format. In order to transfer logs across the CDNI logging interface, = each CDN may have to transform from its internal format to the CDNI = logging interface format. However if a CDN uses a similar log format = (e.g. w3c but with fields in a different order to section 3.4.1) then = under the old text it would=92t have to transform, whereas the new text = would force it to, actually making the implementation harder (and = changing from a MAY to a MUST does=92t make the work of CDN that have to = transform any easier either/simpler either). The log format is based on a well known de-facto standard format (w3c), = interoperability is achieved by parsing the Fields directives to = determine the log field ordering. All the change does is allow = implementations to be lazier (rather than parse the fields directive, = assume that log fields are in a certain order). That may appear to aid = interop but we don=92t think it does really, as it may cause other = issues, e.g. if a dCDN includes optional log fields and implementations = are being lazy, will they fail to properly parse such valid CDNI log = files? If everyone has to parse the fields directive, then initial = implementation bugs may be more prevalent but long term interoperability = is higher as implementations are less likely to barf when presented log = files with additional optional log fields. > 2) > Current text: > =93 > The server-side implementation SHOULD use HTTP cache control headers > on the subscription feed to indicate the frequency at which the > client-side is to poll for updates. > =93 > The proposal is to replace by: > =93 > The server-side implementation MUST set HTTP cache control headers > on the subscription feed to indicate the frequency at which the > client-side is to poll for updates. > =93 > This would simplify implementation a bit and facilitates = interoperability. > Can anyone see a good use case for not setting cache control headers = (note that the other side may decide to poll independently of those, but = at least it knowd those are always valid) ? Saying the server-side MUST set HTTP cache control headers seems OK. But = (if the document does;t already), it should mention that a client may = have out of band configuration/information that overrides the polling = frequency hinted at through the HTTP cache control headers. Also the = document would need to specify what a cache control of = no-store/max-age=3D0 etc. means. Presumably it means =93poll as often as = you like=94 but that should be stated explicitly (if it isn;t already). > 3) > Current text: > " > If it supports redundant CDNI Logging feed, the client-side > SHOULD use the UUID of the CDNI Logging File, presented in the > atom:id element of the Atom feed, to avoid unnecessarily pulling and > storing each CDNI Logging File more than once. > =93 > The proposal is to replace by: > =93 > If it supports redundant CDNI Logging feed, the client-side > MUST use the UUID of the CDNI Logging File, presented in the > atom:id element of the Atom feed, to avoid unnecessarily pulling and > storing each CDNI Logging File more than once. > " > This would simplify implementation a bit and facilitates = interoperability. > Can anyone see a good use case for not using the UUID? We don;t see how this simplifies implementation or facilitates interop. = What it does is reduce the amount of log download traffic, as a client = will only retrieve a log file once, but that does=92t make = implementation or interop simpler/easier. Also it seems quite a draconian rule. If a client wants to download a = log twice, why should=92t it be able to? > 4)=20 > In section 4.2 , current text > =93 > To do so, the client-side: > o MUST use HTTP v1.1 [RFC2616]; > " > The proposal is to edit the text to say that the client-side MUST = implement HTTP v1.1 and MAY also support other HTTP versions and MAY = negotiate which HTTP version is actually used. THis woudl allow to move = to HTTP v2 while still complying with the spec. > The server-side text probably needs the corresponding adjustments. Sounds OK. > 5) > Current text: > =93 > o SHOULD support exchange of CDNI Logging Files with "gzip" content > encoding (as defined in [RFC2616]) applied to the representation. > " > The proposal is to replace by: > =93 > o MUST support exchange of CDNI Logging Files with "gzip" content > encoding (as defined in [RFC2616]) applied to the representation. > =93 > Given the concern about size of logging file it feel useful to have at = least one common compression scheme. The goal is laudable. However there have recently been various = exploits/attacks (e.g. BREACH) where an attacker can utilise information = she knows that is reflected back in HTTP bodies to probe the compression = context when compression is used in combination with encrypted transport = such as TLS. The scenario is slightly different to the CDNI Logging = interface but I think a similar sort of attack could possibly be = constructed for CDNI Logging and folks are starting to take a general = approach of not doing =91blind=92 content compression over secure = channels (e.g. over TLS) as there is the risk of information leakage = that BREACH/CRIME/etc attacks expose. That isn=92t to say that = compression isn=92t suitable when using a secure channel, just that it = needs more thought than applying a single compression context across the = entire content being transferred (e.g. separate compression contexts for = sensitive/non-sensitive data). I=92m not expert enough on security/BREACH/etc to say whether CDNI = logging would avoid such issues and =91blind=92 compression is =91safe=92 = but we should be cautious about introducing mandatory support for = something that could be a security hole. Someone more qualified should = probably analyse/comment. A easy/safe option would be to leave it as a SHOULD rather than change = to a MUST. > 6) > Current text: > =93 > In an environment where any such protection is required, TLS SHOULD > be used for transport of the CDNI Logging feed and the CDNI Logging > File pull unless alternate methods are used for ensuring the > confidentiality of the information in the logging files (such as > setting up an IPsec tunnel between the two CDNs or using a = physically > secured internal network between two CDNs that are owned by the same > corporate entity). Both parties of the transaction (uCDN and dCDN) > SHOULD use mutual authentication. > =93 > The proposal is to update to: > =93 > In an environment where any such protection is required, TLS SHOULD > be used (including authentication of the remote end) by the = server-side and the client-side of the CDNI Logging feed and of the CDNI = Logging pull mechanism unless alternate methods are used for ensuring = the > confidentiality of the information in the logging files (such as > setting up an IPsec tunnel between the two CDNs or using a physically > secured internal network between two CDNs that are owned by the same > corporate entity). > =93 > This is because it does not really make sense to say that =93both ends = use mutual authentication=94, rather both ends need to authenticate the = remote end (which collectively achieves mutual authentication). =20 > Any concern with that? No. HTH Ben >=20 > Francois > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Fri Apr 25 09:59:29 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45231A00CB for ; Fri, 25 Apr 2014 09:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0boktn2pJlrL for ; Fri, 25 Apr 2014 09:59:21 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id A0EEB1A03D7 for ; Fri, 25 Apr 2014 09:59:21 -0700 (PDT) Received: from host4.velocix.com ([81.134.152.4] helo=[172.18.0.148]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1WdjT0-0006JH-MX; Fri, 25 Apr 2014 17:59:15 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Niven-Jenkins In-Reply-To: <039101cf5b5f$812cc790$838656b0$@comcast.net> Date: Fri, 25 Apr 2014 17:59:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <255A728C-3673-4C4F-A4E4-5A936C4FA0AD@niven-jenkins.co.uk> References: <7C4FD086-4264-443B-8791-6FE7C48C7FB1@cisco.com> <039101cf5b5f$812cc790$838656b0$@comcast.net> To: ietfdbh X-Mailer: Apple Mail (2.1874) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/TOX6MlKryBMSD0CML7_eZwhwbRU Cc: cdni@ietf.org Subject: Re: [CDNi] cdni-logging : Proposed adjustments on MUST/SHOULD/MAY X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 25 Apr 2014 16:59:23 -0000 David, See inline, On 19 Apr 2014, at 00:39, ietfdbh wrote: > Hi, >=20 > Inline. >=20 > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 >=20 >> -----Original Message----- >> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] >> Sent: Friday, April 18, 2014 1:07 PM >> To: cdni@ietf.org >> Cc: Francois Le Faucheur (flefauch); ietfdbh >> Subject: cdni-logging : Proposed adjustments on MUST/SHOULD/MAY >>=20 >> Folks, >>=20 >> (as a cdni-logging author) >>=20 >> David kindly conducted an early OPSDIR review of cdni-logging (and a = very >> thorough one, I may add). >>=20 >> This message discusses the proposed resolutions that affect >> MUST/SHOULD/MAY statements. Please review/comment: >>=20 > [...] >>=20 >> 2) >> Current text: >> " >> The server-side implementation SHOULD use HTTP cache control headers >> on the subscription feed to indicate the frequency at which the >> client-side is to poll for updates. >> " >> The proposal is to replace by: >> " >> The server-side implementation MUST set HTTP cache control headers >> on the subscription feed to indicate the frequency at which the >> client-side is to poll for updates. >> " >> This would simplify implementation a bit and facilitates = interoperability. >> Can anyone see a good use case for not setting cache control headers = (note >> that the other side may decide to poll independently of those, but at > least it >> knowd those are always valid) ? >>=20 > Forgive me if I should already know this. >=20 > Section 4 talks about managing the ATOM feed, but only once does it = mention > HTTP, and that is the sentence you are discussing. > Is HTTP the only way to control the frequency of polling? Or does it = just > make the most sense since this document focuses on HTTP? Atom specifies no way to control the frequency of polling. Using HTTP = cache control headers is the =91de facto=92/=91best practice=92 = according to various internet sources (e.g. stack overflow) http://stackoverflow.com/questions/939642/policy-for-polling-rss I would expect some deployments to control the frequency via out of band = mechanisms (e.g. agreed configuration between uCDN & dCDN). > If, for whatever reason, an implementer or operator chose not to = support > HTTP cache control headers, > Could an implementer/operator choose another protocol to specify the = polling > frequency? I don=92t see why not. HTTP cache control headers are only ever a hint = anyway, there is nothing in HTTP that mandates a client actually caches = something that is marked as cacheable. > Are cache control headers at all controversial, say for security > considerations? I don=92t think so. They=92re widely used for content on the web and = within HTTP-based APIs. I can=92t think of any additional security = considerations related to caching the atom feed itself that would=92t = apply to any other cacheable content transferred over HTTP. Regards Ben =20 > [...] >>=20 >> 4) >> In section 4.2 , current text >> " >> To do so, the client-side: >> o MUST use HTTP v1.1 [RFC2616]; >> " >> The proposal is to edit the text to say that the client-side MUST > implement >> HTTP v1.1 and MAY also support other HTTP versions and MAY negotiate >> which HTTP version is actually used. THis woudl allow to move to = HTTP v2 >> while still complying with the spec. >> The server-side text probably needs the corresponding adjustments. >=20 > s/ THis woudl allow to move to HTTP v2 while still complying with the > spec./This would allow operators and implementers to choose to use = later > versions of HTTP to take advantage of new features, while still = ensuring > interoperability with systems that only support v.1.1./ >=20 > [...] >=20 >>=20 >> Francois=3D >=20 > dbh >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Fri Apr 25 10:24:39 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8CA81A02CC for ; Fri, 25 Apr 2014 10:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptFy65mW29YX for ; Fri, 25 Apr 2014 10:24:35 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 540F21A028B for ; Fri, 25 Apr 2014 10:24:35 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta07.westchester.pa.mail.comcast.net with comcast id uBwg1n0011GhbT857HQUWN; Fri, 25 Apr 2014 17:24:28 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta07.westchester.pa.mail.comcast.net with comcast id uHQU1n00A2yZEBF3THQU38; Fri, 25 Apr 2014 17:24:28 +0000 From: "ietfdbh" To: "'Ben Niven-Jenkins'" References: <7C4FD086-4264-443B-8791-6FE7C48C7FB1@cisco.com> <039101cf5b5f$812cc790$838656b0$@comcast.net> <255A728C-3673-4C4F-A4E4-5A936C4FA0AD@niven-jenkins.co.uk> In-Reply-To: <255A728C-3673-4C4F-A4E4-5A936C4FA0AD@niven-jenkins.co.uk> Date: Fri, 25 Apr 2014 13:28:58 -0400 Message-ID: <028901cf60ab$d78eae40$86ac0ac0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJh5O8GRf2FVleY5aSLiPCAjYlStQG/3PklAY8L1fCZ4xRMUA== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1398446668; bh=Vx737XfAuHJehnJwFdA7zaxmifsnxzLd3jucCnzypeM=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=eHBX0axaMNXI5z3uTOrC8cbd0rO5HPBRKPTXWUXvNowD7MT7iShNFbgx8+Jr47s5e eFE1nBlnQyUngHyPNf9qxZiF5Wmsl4LAwoyhDJu8ed7KABM3ssQ+EGuWiN31NC26M/ EL5zG98kOELvK/UnZygVEp/rKAMhqRUaEBPL1aUQFpt99TOlA2zTiOf1iYs6jB7fJH i1DOwl++cAOP5wUkgxTfl7Ahi1Jo/9VZJeIUjo0biSVdBgTJpm7AJxFfM7smnYjWkN r2tjN6rjaDyqNFDGmADQPO25QWc5TdmWETRyudGSdjEW5Aj9xHpU+bNtD4AvvSUY9B HfMZHOt3NywwA== Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/EbIQfVx6gx8Q2PBVedEUb-JZaxY Cc: cdni@ietf.org Subject: Re: [CDNi] cdni-logging : Proposed adjustments on MUST/SHOULD/MAY X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 25 Apr 2014 17:24:38 -0000 Hi, So it sounds to me like using HTTP cache control headers should be a SHOULD use, not a MUST use. This could be a MUST-implement for baseline interoperability reasons, just like HTTPv1.1 "the server-side implementation MUST be able to set ..." would be correct. Then whether to USE the cache headers, or another mechanism, is an operational runtime decision. "the server-side implement SHOULD set ..." would be a runtime decision, not an implementation decision. I think your best approach is to clearly separate implementation requirements from use requirements. David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: Friday, April 25, 2014 12:59 PM > To: ietfdbh > Cc: Francois Le Faucher; cdni@ietf.org > Subject: Re: [CDNi] cdni-logging : Proposed adjustments on > MUST/SHOULD/MAY > > David, > > See inline, > > On 19 Apr 2014, at 00:39, ietfdbh wrote: > > > Hi, > > > > Inline. > > > > David Harrington > > ietfdbh@comcast.net > > +1-603-828-1401 > > > >> -----Original Message----- > >> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] > >> Sent: Friday, April 18, 2014 1:07 PM > >> To: cdni@ietf.org > >> Cc: Francois Le Faucheur (flefauch); ietfdbh > >> Subject: cdni-logging : Proposed adjustments on MUST/SHOULD/MAY > >> > >> Folks, > >> > >> (as a cdni-logging author) > >> > >> David kindly conducted an early OPSDIR review of cdni-logging (and a very > >> thorough one, I may add). > >> > >> This message discusses the proposed resolutions that affect > >> MUST/SHOULD/MAY statements. Please review/comment: > >> > > [...] > >> > >> 2) > >> Current text: > >> " > >> The server-side implementation SHOULD use HTTP cache control headers > >> on the subscription feed to indicate the frequency at which the > >> client-side is to poll for updates. > >> " > >> The proposal is to replace by: > >> " > >> The server-side implementation MUST set HTTP cache control headers > >> on the subscription feed to indicate the frequency at which the > >> client-side is to poll for updates. > >> " > >> This would simplify implementation a bit and facilitates interoperability. > >> Can anyone see a good use case for not setting cache control headers > (note > >> that the other side may decide to poll independently of those, but at > > least it > >> knowd those are always valid) ? > >> > > Forgive me if I should already know this. > > > > Section 4 talks about managing the ATOM feed, but only once does it > mention > > HTTP, and that is the sentence you are discussing. > > Is HTTP the only way to control the frequency of polling? Or does it just > > make the most sense since this document focuses on HTTP? > > Atom specifies no way to control the frequency of polling. Using HTTP cache > control headers is the 'de facto'/'best practice' according to various internet > sources (e.g. stack overflow) > > http://stackoverflow.com/questions/939642/policy-for-polling-rss > > I would expect some deployments to control the frequency via out of band > mechanisms (e.g. agreed configuration between uCDN & dCDN). > > > If, for whatever reason, an implementer or operator chose not to support > > HTTP cache control headers, > > Could an implementer/operator choose another protocol to specify the > polling > > frequency? > > I don't see why not. HTTP cache control headers are only ever a hint anyway, > there is nothing in HTTP that mandates a client actually caches something > that is marked as cacheable. > > > > Are cache control headers at all controversial, say for security > > considerations? > > I don't think so. They're widely used for content on the web and within > HTTP-based APIs. I can't think of any additional security considerations > related to caching the atom feed itself that would't apply to any other > cacheable content transferred over HTTP. > > Regards > Ben > > > > [...] > >> > >> 4) > >> In section 4.2 , current text > >> " > >> To do so, the client-side: > >> o MUST use HTTP v1.1 [RFC2616]; > >> " > >> The proposal is to edit the text to say that the client-side MUST > > implement > >> HTTP v1.1 and MAY also support other HTTP versions and MAY negotiate > >> which HTTP version is actually used. THis woudl allow to move to HTTP v2 > >> while still complying with the spec. > >> The server-side text probably needs the corresponding adjustments. > > > > s/ THis woudl allow to move to HTTP v2 while still complying with the > > spec./This would allow operators and implementers to choose to use later > > versions of HTTP to take advantage of new features, while still ensuring > > interoperability with systems that only support v.1.1./ > > > > [...] > > > >> > >> Francois= > > > > dbh > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni From nobody Mon Apr 28 02:18:07 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B281A099B for ; Mon, 28 Apr 2014 02:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOeXl7fX82mx for ; Mon, 28 Apr 2014 02:18:02 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9FE1A0998 for ; Mon, 28 Apr 2014 02:18:02 -0700 (PDT) Received: from host4.velocix.com ([81.134.152.4] helo=xxx.corp.velocix.com) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1WehhH-0002E3-Vb; Mon, 28 Apr 2014 10:18:00 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Niven-Jenkins In-Reply-To: <936509A0-8B78-4134-B0CD-7D29FE403E54@cisco.com> Date: Mon, 28 Apr 2014 10:17:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <936509A0-8B78-4134-B0CD-7D29FE403E54@cisco.com> To: Francois Le Faucher X-Mailer: Apple Mail (2.1874) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/CA55lV3ULGaFz1BdG7VsPi2uLU4 Cc: "draft-ietf-cdni-metadata@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 3] X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 28 Apr 2014 09:18:05 -0000 Francois, Following up on this. I have made all the editorial changes you suggest = below to the authors working copy of -07 so you should see them once we = publish a new version. Ben On 11 Mar 2014, at 18:57, Francois Le Faucheur (flefauch) = wrote: >=20 >=20 > *** section 4, and Abstract: > The word =93core=94 appears twice in the whole document. > Abstract: "This document describes both the core set of CDNI metadata = and > the protocol for exchanging that metadata.=94 > Section 4: "Section 4.2 provides the definitions for the set of core = metadata > objects which may be contained within a GenericMetadata object.=94 > I think what it is meant to convey is =93the set of essential CDNI = metadata objects that are therefore defined in this document, but we = expect that additional metadata objects may be defined in the future in = separate documents.=94 >=20 > Perhaps it woudl be clearer if you=92d say somethink like: > Abstract: "This document describes both a base set of CDNI metadata = and > the protocol for exchanging that metadata.=94 > Section 4: "Section 4.2 provides the definitions for a base set of = core metadata > objects which may be contained within a GenericMetadata object.=94 >=20 > I believe that somewhere below in the document, extensibility is = discussed with the notion of how one might define additional objects. = Please double check that, and in case it is not clear enough, you could = add an explicit note to convey that "we expect that additional metadata = objects may be defined in the future in separate documents.=94 >=20 >=20 > *** section 4: > =93 as they define the semantics, enforcement options, and = serialization rules for specific properties.=94 > is "serialization rules=94 the right term here? >=20 >=20 > *** section 4: > "Property objects may be composed of or contain > references to other objects. In those cases the value of the > property can be either an object of that type=94 > This paragraph uses =93property=94, =93property object=94 and = =93object=94. If they refer to teh same thing, you should use a single = term. If they mean something different, then you need to clarify that. >=20 >=20 > *** section 4: > "Note: In the following sections, the term "mandatory-to-specify" is > used to convey which objects or properties must be specified for a > given parent object or property. When mandatory-to-specify is set = to > true, it implies that if the parent object is specified, then the > defined object or property MUST also be specified, e.g., a HostMatch > object without a host to match against does not make sense, > therefore, the host is mandatory-to-specify inside a parent = HostMatch > object. > =93 > I think the Note above uses the term =93parent=94 in a different = meaning than how it is defined in "3.3. Metadata Inheritance and = Override=94, which made it difficult to understand at first read. > In section 3.3, inheritance is across HostMetada and PathMetadata and = PathMetadata etc.: > "HostMetadata and PathMetadata objects form an > inheritance tree where each node in the tree inherits or overrides > the property values set by its parent. > =93 > So a HostMetadata may be a =93parent=94 to a =93PathMetadata" > In the section 4 Note, =93parent" is used to mean a PathMatch that = points to a PathMetadata. This is very different to me, because there is = no =93inheritance=94 and overrride in that case. It is just a pointer. > My suggestion would be to not use the word =93parent=94 in section 4 = Note. Perhaps ypu could talk about a =93referring object =93. >=20 >=20 > *** Section 4.1 and 4.2: > "4.1. CDNI Metadata Structural Object Descriptions=94 > "4.2. CDNI Metadata Property Object Descriptions=94 > I had a hard time working out from the titles waht was covered in each = section. =20 > Again the word property is used in one tittle and not the other. Also, = combining 5 consecutive words leaves room for ambiguity (eg is it the = object that is structural or the description). > How about: > =934.1. Descriptions of the CDNI Structural Metadata Objects=94 > "4.2. Description of the CDNI Generic Metadata Objects=94 >=20 >=20 > *** section 4.1: > " Each of the sub-sections below describe the structural objects = defined in Table 2.=94 > The PatternMatch object is actually not defined in Table2 nor in = Figure 1. It looks like it was added afterwards. I think you need to = extend Table 2 and Figure 1 to add that PatternMatch object. >=20 >=20 > *** section 4.1.4: > "The HostMatch object also contains a reference to Metadata objects=94 > "Description: CDNI Metadata to apply when delivering content that = matches this host.=94 > So the overview text says the object =93references=94 metadata, and = the description says it =93contains" metadata. > I brought up that general point before about teh earlier sections. I = assume it will also be addressed in all teh object description sections = and won=92t comment on this anymore. >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Mon Apr 28 02:32:45 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7791A0786 for ; Mon, 28 Apr 2014 02:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exaQpFfePG_X for ; Mon, 28 Apr 2014 02:32:41 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id E59381A075F for ; Mon, 28 Apr 2014 02:32:40 -0700 (PDT) Received: from host4.velocix.com ([81.134.152.4] helo=xxx.corp.velocix.com) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1WehvT-0006u6-9y; Mon, 28 Apr 2014 10:32:39 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Niven-Jenkins In-Reply-To: <5FBAF9F8-8389-431B-95BC-9758273FBDF9@cisco.com> Date: Mon, 28 Apr 2014 10:32:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5FBAF9F8-8389-431B-95BC-9758273FBDF9@cisco.com> To: Francois Le Faucher X-Mailer: Apple Mail (2.1874) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/XoylqaqXmCWKLZG293OTA0pV3-I Cc: "draft-ietf-cdni-metadata@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 4] X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 28 Apr 2014 09:32:43 -0000 Francois, I have incorporated the editorial comments from below. Some of your = comments require some discussions with my co-authors so I=92ve marked = them as =93Design=94 below and we=92ll follow up later with proposed = resolutions for them. Ben On 12 Mar 2014, at 13:51, Francois Le Faucheur (flefauch) = wrote: > (Note: I stopped detailed review at 4.2.4 even if I have a few = comments beyond that). >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > General comments: >=20 > *** somewhere (probably towards the beginning of the document): > Can you make sure the applicability of the metadata defined in this = documents is discussed in terms of what types of deliveries are = supported (HTTP/1.0, 1.1, 2.0 , HTTPS). I suggest you base that on the = text I proposed on the list for cdni-logging. > Also how about adding a summary of features supported by specified = metadata (eg geolocation, time window, multipe acquisitions, =85) Design, will address in a follow-up e-mail. > *** use of MUST: > I think this needs a clean-up: > o there are a number of appropriate MUST statements on detailed = things, but I can=92t see one statement clarifying exhaustively which = object is mandatory to implement as an uCDN and as a dCDN. Can you make = sure this is covered , if not already covered? > o there are a few =93must=94 that we may want to replace with = alternate phrases ( =93needs to=94, =93has to=94, =85) > o there are MUSTs in the IANA section (eg 7.1). Based on the = conversation we had in teh contaxt of cdni-logging, I assume these will = be edited out.=20 Design, will address in a follow-up e-mail. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Detailed comments: >=20 >=20 > *** section 4.1.3: > "First match applies.=94 > Might be worth turning into a full sentence explaining the context of = the =93match=94 ie when metadata is walked through to find the relevant = one for a piece of content to be processed , every path-pattern is = evaluated in the order they appear in paths object and then first match = applies.=85 up to you. Done. > *** section 4.1.5: > OLD: > =93 > A PathMetadata object contains the CDNI Metadata properties for > content served with the associated URI path (defined in a PathMatch > object). > =93 > NEW: > =93 > A PathMetadata object contains the CDNI Metadata properties for > content served with the associated URI path (defined in a PathMatch > object) and possibly children PathMatch objects . > =93 Done. > *** section 4.1.5: > OLD: > =93 > Note that if CDNI metadata is used as an input to CDNI > request routing and DNS-based redirection is employed, then any > metadata at the PathMetadata level or below will be inaccessible at > request routing time. > =93 > NEW: > =93 > Note that if DNS-based redirection is employed, then any > metadata at the PathMetadata level or below will be inaccessible at > request routing time because only the content request hostname is = available at request routing time. > =93 Done. > *** section 4.1.6: > "The three literals \ , * and ? should be > escaped as \\, \* and \?. All other characters are treated as > literals.=94 > Why do you need to escape =93\=94? Addressed already, no change required. > *** section 4.1.7: > =93 > Property: type > Description: CDNI Metadata property object type. > Type: String > Mandatory-to-Specify: Yes. >=20 > Property: value > Description: CDNI Metadata property object. > Type: matches the type property above > " > To me it would be easier to follow if you renamed the properties from = =93type=94 and =93value=94 to something like =93generic-metadata-type=94 = and "generic-metadata-value=94.=20 > Obviously, you'd need to reflect these changes in other places. Design, will address in a follow-up e-mail. > *** section 4.1.7: > "Type: matches the type property above=94 > This is an exemple of things that are hard to parse currently. With = the proposed change above this could read: > "Type: matches the generic-metadata-type of the property above=94 Depends how we address previous comment, will address in a follow-up = e-mail. > *** section 4.2: > OLD: > =93 > The property objects defined below are intended to be used in the > GenericMetadata object value field as defined in Section 4.1.7.=20 > =93 > NEW: > " > The property objects defined below are intended to be used in the > GenericMetadata object generic-metadata-value propery as defined in = Section 4.1.7 and their type used in the generic-metadata-type property = as defined in section 4.1.7.=20 > =93 > Let me kow if this is not correct. Depends how we address previous comment, will address in a follow-up = e-mail. > *** section 4.2: > =93 > All of the objects defined below are considered both mandatory to = enforce > and safe to redistribute. > =93 > is it allowed to distribute them with no-MtE or no-StR? what woudl = happen then? > Would it be appropriate to state that all the objects MUST be = distributed with MtE and StR? can you add a statement about behavior or = receipt if received otherwise? Design, will address in a follow-up e-mail. > *** section 4..2.1: > =93 > Description: Sources from which the dCDN can acquire content, > listed in priority order.=94 > you may want to use =93preference=94 instead of =93priority=94 (which = is an overloaded term) and explain what it means i.e. the dCDN is = expected to always use the first one , unless it does not work? or is = dCDN allowed to load balance across multiple sources? should there be a = mechanism to control whether it is single source + backup or multple = sources?=20 Design, will address in a follow-up e-mail. > *** section 4.2.1.1: > Is it really useful to allow multiple endpoints within a source, given = it is possible to include multiple sources? > If you keep multiple endpoints within a source, can you also clarify = if there is any expected behavior from dCDN across the multiple = endpoints (single or ) Design, will address in a follow-up e-mail. > *** section 4.2.2: > OLD: > =93 > Description: Access control list which applies restrictions to > delivery based on client location. > " > NEW: > =93 > Description: Access control list which allows or blocks > delivery based on client location. > =93 Done. > ***section 4.2.2.1: > I assume that the rules are discussed somewhere in the document (that = I have not got to yet) on usage of the LocationACLMetadata. > For example: > * if I only include one single LocationRule object that allows = Footprint1, does it mean that a delievery from outside Footprint 1 is = allowed or denied? > * if I have overlapping footprints, which applies? first one? > If these rules are not made explicit yet, please add them. Design, will address in a follow-up e-mail. > *** section 4.2.3: > OLD: > =93 > Description: Access control list which applies restrictions to > delivery based on request time. > " > NEW: > =93 > Description: Access control list which allows or blocks=20 > delivery based on request time. > =93 Done. > *** section 4.2.3: > OLD: > =93 > Description: Access control list which applies restrictions to > delivery based on delivery protocol. > =93 > NEW: > =93 > Description: Access control list which allows or blocks > delivery based on delivery protocol. > =93 Done. > *** section 6.2:=20 > "Where a downstream CDN is interconnected with multiple upstream CDNs, > the downstream CDN must decide which upstream CDN's CDNI metadata > should be used to handle a particular User Agent request. > =94 > s/must decide/needs to determine/ Done. > *** Section 6.4.2.1: > OLD: > =93 6.4.2.1. JSON Example=94 > NEW: > " 6.4.2.1. Encoded CDNI Metadata Example=94 Done. > *** section 7.1.1.1=94 > =93 > DVD Region code (i.e., integer in the range 0-6).=20 > =93 > add a reference that specifies these values. Design as looking at DVD specs we may need to change the representation, = will address in a follow-up e-mail. Ben From nobody Mon Apr 28 03:35:13 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E9F1A096E for ; Mon, 28 Apr 2014 03:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_FROM=2.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNAi3xXP0DUH for ; Mon, 28 Apr 2014 03:35:09 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0DF1A08EA for ; Mon, 28 Apr 2014 03:35:08 -0700 (PDT) Received: from host4.velocix.com ([81.134.152.4] helo=xxx.corp.velocix.com) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1Weitu-0007RO-Cr; Mon, 28 Apr 2014 11:35:07 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Niven-Jenkins In-Reply-To: <18D8DD69-FA99-400B-83A0-A47790AB0209@cisco.com> Date: Mon, 28 Apr 2014 11:35:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6EAB1A28-2BC9-4EEC-A850-ADE753155C70@niven-jenkins.co.uk> References: <18D8DD69-FA99-400B-83A0-A47790AB0209@cisco.com> To: Francois Le Faucher X-Mailer: Apple Mail (2.1874) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/0D3-R9dynlJ3k99FGKdeBZTsP1k Cc: "draft-ietf-cdni-metadata@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 5] X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 28 Apr 2014 10:35:11 -0000 Francois, I have incorporated the editorial comments from below. Some of your = comments require some discussions with my co-authors so I=92ve marked = them as =93Design=94 below and we=92ll follow up later with proposed = resolutions for them. On 20 Mar 2014, at 18:33, Francois Le Faucheur (flefauch) = wrote: > I got down to 6.2. and need to stop now. This is a loooooong review. > Francois >=20 >=20 > *** section 4.2.2.2 > OLD: > =93 > Property: type > =93 > NEW > =93 > Property: footprint-type > =93 > (end reflect that change in rest of the document if needed)=20 Done > *** section 4.2.2.2 > OLD: > =93 > Property: value > =93 > NEW > =93 > Property: footprint-value > =93 > (end reflect that change in rest of the document if needed)=20 Done > *** section 4.2.3 and 4.2.3.1 > both have the same property name ie "Property: times=94. Perhaps the = property in 4.2.3.1 could be renamed to something like =93windows=94 Done > *** section 4.2.4 > OLD: > =93 > Description: Access control list which applies restrictions to > delivery based on delivery protocol. > =93 > NEW: > =93 > Description: Access control list which allows or blocks > delivery based on delivery protocol. > =93 Done > *** section 4.2.2, 4.2.3 and 4.2.4. > It appears that the three types of allow/deny (LocationACL, = TimeWindowACL and ProtocolACL) and independent of each other. > So I can say , for this content: > (i) allow it in this Footprint and block it everywhere else > (ii) allow it in this timewindow and block it at any other time. > Is it possible to say , for this content: > (i) allow it in this timewindow from this footprint > (ii) allow it in a different timewindow ffrom this other = footprint > (iii) block it otherwise? > Either way, can you ensure there is a discussion about that (perhpas = it comes up further down in the document and I have not seen it)? > If you feel this extra flexibility is not needed, then please state so = (and ideally indicate whether it could be added in teh future without = breaking all the current object structure). If this flexibility is = supported , then please add a note/example explaining how.=20 Design, will address in a follow-up e-mail. > *** section 4.2.4 > =93 > Property: action > Description: Defines whether the rule specifies protocols to > allow or deny. > ... > Property: direction > Description: Defines whether the ProtocolRule specifies > protocols for acquisition or delivery. > =93 > I don=92t quite get the semantics of this object when = direction=3Dacquisition.=20 > If it conditions how the dCDN is meant to change protocol to acquire = the content , then it shoudl not be cast as an allow/deny, but probably = more as part of the =93source=94 object that defines acquisition = behaviour. Done > *** section 4.2.4 > It is not obvious to me what are the rules when things are partially = specified. For example, if it says Protocol1/allow/acquisition, then is = delivery of Protocol1 allowed or denied? Can you add an explicit = statement about that? Done > *** section 4.2.4.1: > "Type: Enumeration [allow|deny]+=94 : I assume the =93+=94 should be = removed? Done. > *** section 4.2.5 > =93 > Authorization Metadata define content authorization methods. > Property: methods > Description: Options for authenticating content requests. All > options in the list are equally valid. > " > I assume =93Options for authenticating=94 should read =93Options for = authorising=94, right? >=20 > Also, similar to previous comments, I=92d suggest having slightly more = explicit property names. So I=92d rename =93methods=94 into something = like =93auth-methods" >=20 > =93Content authorisation methods=94 is not clear. ie it is not the = content that is authorised, but the request. so perhaps replace with = =93Content request authorisation methods=94 or =93Delivery authorisation = methods=94 >=20 > "All options in the list are equally valid.=94 I think you mean more = something like =93Delivery for a content request is authorized if any of = the authorisation method in the list is satisfied for that request=94. Design, will address in a follow-up e-mail. > *** section 4.2.6: > I understand that Auth objects are meant to be listed within the = =93Authorization Metadata=94 object (2.6.5) so shoudl section 2.4.6 not = be numbered 2.4.5.1 in line with what is done above for other objects? = Is there something different here? Done > *** section 4.2.6: > "An Auth object defines authentication and authorization methods =93 = while 4.2.5 says "authorization methods =93. Is it authorization or = both authentication and authorisation? Design, will address in a follow-up e-mail. > *** section 4.2.6=20 > again =93property: type=94 =97> =93property: auth-type=94? Done > *** section 4.2.6: > =93 > 4.2.6. Auth > An Auth object defines authentication and authorization methods to = be > used during content delivery and content acquisition. >=20 > Property: type > Description: Registered Auth type (see Section 7.1.1.3). > ... >=20 > Property: value > Description: Auth object conforming to the specification > associated with the registered Auth type. > =93 > There is some circular reference here: Auth is an object with a type = and a value, and the value is an Auth object. I think you need to tweak = wording of the Description for the value. Design, will address in a follow-up e-mail. > *** section 7.1.1.3=20 > I think the section title (and registry) should be renamed from = "Authentication Sub-Registry=94 to "Authentication Type Sub-Registry=94 = (and =93CDNI Metadata Auth=94 to "CDNI Metadata Auth Type=94) >=20 > I recommend the text be more explicit that the IANA has to create a = registry (or sub-registry) for the "CDNI Metadata Auth Type=94. >=20 > s/Type name/Type/ Design, will address in a follow-up e-mail. > *** section 4.2.7 > =93 > Mandatory-to-Specify: No. Default is to consider query string > parameters when comparing URIs or to rely on other properties > of the Cache object. > =93=20 > What does =93rely on other properties of the Cache object=94 actually = mean? there is no other properties in that object. Done > *** general question about multiple instances of objects. > Is it correct that one expects only a single instance of top level = objects inside a given generic metadata object? > For example, there shoudl only be a single sources Metadata object = (which obvisouly can contain a list), but I should not have two sources, = right? > Is this explicitely stated somewhere? Can you ensure it is stated and = it is also stated what happens if you receive two of the same objects = (only keep the first one? in case of transit, redistribute or drop the = other instances?) Design, will address in a follow-up e-mail. > *** section 4.3.1: > " Property: type=94 =97> " Property: metadata-object-type=94 Done > *** section 4.3.2-4.3.5 > 4.3.2 explicitely states a Type and Mandatory-to-Specify while 4.3.3, = 4.3.4 and 4.3.5 do not. Shoudln=92t all sections state the Type and = Mandatory-to-Specify? Design, will address in a follow-up e-mail. > *** Section 5: > OLD: > =93 > any delegated requests for that content will fail, so > there is no reason to delegate those requests. > =93 > NEW: > =93 > any delegated requests for that content will fail, so > the uCDN is likely to want to avoid delegating those requests to = that dCDN. > =93 Done > /If a the/if the/ Done > OLD: > =93 > so there is likely > no reason to delegate those requests. > =93 > NEW: > =93 > so again the uCDN is likely to want to avoid delegating those requests = to that dCDN.=94 Done > *** section 5: > OLD: > " > The CDNI Footprint and Capabilities Interface provides a means of > advertising capabilities from dCDN to uCDN. Support for optional > metadata and support for optional metadata values may be advertised > using the capabilities interface. > =93 > NEW: > =93 > The CDNI Footprint and Capabilities Interface (FCI) = [I-D.ietf-cdni-framework] provides a means of > advertising capabilities from dCDN to uCDN. Support for optional > metadata and support for optional metadata values may be advertised > using the FCI. > =93 Done > *** section 5: > OLD: > =93 > for the metadata defined in Section 4.2 > =93 > NEW: > =93 > for the metadata defined in the present document. > =93 Done > *** section 5. > I understand there is no =93optional=94 metadata that require = capability adevrtisemnet (ie only optional values require = advertisement). Since the text explained the two cases previously, I = would suggest adding a statement right befrore section 5.1 stating that = the present document does not define optional metadata so no = capabilities advertisement are required for that, but it defines two = metadata objects with optional values and the corresponding capabilities = are specified in section 5.1 and 5.2. Design, will address in a follow-up e-mail. > *** section 5 > Since no capabilities are defined for the Footprint types, this infers = that an implementation must implement all of the footprint types defined = in section 7.1.1.1. Right? > Where is it specified in the document that implementation MUST = implement all the Footprint types? Can you make sure the mandatory to = implement aspects of this are clearly specified somewhere? Design, will address in a follow-up e-mail. > *** section 5.1: > I have the same comment as for section 4.2.4. ie I am not clear on why = the protocol rules for acquisition as referred to as =93authorisation=94. > I don=92t think you need to re-explain why it is useful to adevrtise = the capabilities (eg to allow proper redirection) since this was = explaine in section 5 in a generic way (and more accurately since it = brought up the notion of mandatory-to-enforce). > So I=92d shorten the text in that section. >=20 > Also , this does not actually specifiy the actual capabilities nor = provide a ref to where they will be defined. Can you add a statement, = along the lines of =93the corresponding capabilities and protocol to = advertise them are outside the scope of this document and are expected = to be specified in the FCI.=20 Design, will address in a follow-up e-mail. > *** section 5.2 > I don=92t think you need to re-explain why it is useful to adevrtise = the capabilities (eg to allow proper redirection) since this was = explaine in section 5 in a generic way (and more accurately since it = brought up the notion of mandatory-to-enforce). > OLD: > =93 > The Authorization object contains a list of Auth values. The dCDN > MUST advertise which authorization algorithms it supports so that = the > uCDN knows what type of content requests it can redirect to the = dCDN. > If the dCDN does not support a given authorization algorithm, the > uCDN should not delegate requests requiring that algorithm to the > dCDN as the dCDN will not be able to properly acquire the content or > enforce delivery restrictions. > =93 > NEW: > =93 > The Authorization object contains a list of Auth values. The dCDN > MUST advertise in its FCI capabilities which authorization types it = supports. > " >=20 > Also , this does not actually specifiy the actual capabilities nor = provide a ref to where they will be defined. Can you add a statement, = along the lines of =93the corresponding capabilities and protocol to = advertise them are outside the scope of this document and are expected = to be specified in the FCI.=20 Done. > *** section 6: > OLD: > =93 > for example in response to receiving a CDNI Request Routing request = from an Upstream CDN > " > NEW: > =93 > for example in response to a query from an Upstream CDN over the CDNI = Request Routing Redirection interface (RI) [I-D.ietf-cdni-redirection]. > =93 > where [I-D.ietf-cdni-redirection] is added to the list of Informative = References. Done > *** section 6: > s/prepositioned CDNI Metadata acquisition/Pre-positioned CDNI Metadata = acquisition/ > (just to align to terminology of RFC6707) Done > *** Section 6: > 2nd paragraph. I suggest breaking it into two sentences for easier = readability. Done > *** section 6: > OLD > =93 > The CDNI Metadata interface is built on the principles of RESTful web > services. This means that requests and responses over the interface > are built around the transfer of representations of hyperlinked > resources. > =93 > NEW: > =93 > The CDNI Metadata interface is built on the principles of RESTful web > services. In particular, this means that requests and responses = over the interface > are built around the transfer of representations of hyperlinked > resources. > =93 > (my point is that the second sentence does not hold as a definition of = RESTful web services=94. Done > *** section 6: > I suggest that the first time the phrase =93CDNI server=94 is use, it = is clarified that this refers to the uCDN side of the CDNI Metadata = interface. > Same for =93CDNI client=94. Done > *** section 6.1: > OLD: > =93 > Servers implementing the CDNI Metadata > interface MUST support the HTTP GET and HEAD methods. > =93 > NEW: > =93 > An implementation of the CDNI Metadata server MUST support the HTTP = GET and HEAD methods. > =93 >=20 > What about the client? MUST support GET and MAY support HEAD? Done > *** section 6.1: > OLD: > =93 > Server implementations of > this interface SHOULD reject all methods other than GET and HEAD. > =93 > NEW: > =93 > An implementation of the CDNI Metadata server SHOULD reject all = methods other than GET and HEAD. > =93 Done > *** section 6.1: last paragraph > Is there a reason the may statements are not =93MAY=94 statements? > (and then adjust text to say =93an implementation of the CDNI = Metatadat server =85=94 Done > *** section 6.2 > =93 > In the general case a CDNI Metadata server makes each instance of an > addressable CDNI Metadata object available via a unique URI and > therefore in order to retrieve CDNI Metadata, a CDNI Metadata client > first makes a HTTP GET request for the URI of 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. > =93 > This makes it sounds like it is only in the general case that the = client starts with a GET on HostIndex. Is this not always true? > If it is then , how about just saying: > =93 > To retrieve CDNI metadata, a CDNI Metadata client > first makes a HTTP GET request for the URI of 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. > =93 Done > *** section 6.2 : > =93 > If any > PathMetadata match the request (and are linked rather than = embedded), > the CDNI metadata client makes another GET request for the > PathMetadata. > " > The fact that the text says =93match=94 instead of =93matches=94 = raises teh question of what hapens when more than one does match. = Looking back at 4.1.3, I don=92t see the answer to that question. I may = have already commented on that question. In any case, please make sure = this is specified (I would suggest in 4.1.3 and possibly in section 6.2 = where you describe the un-pilling of metadata). Done > *** section 6.2: > s/the downstream CDN must decide/the downstream CDN needs to = determine/ Done Ben From nobody Mon Apr 28 07:03:46 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDBD1A0A19 for ; Mon, 28 Apr 2014 07:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bklTd_cquChb for ; Mon, 28 Apr 2014 07:03:37 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 47BD31A0983 for ; Mon, 28 Apr 2014 07:03:31 -0700 (PDT) Received: from host4.velocix.com ([81.134.152.4] helo=xxx.corp.velocix.com) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1Wem9Z-0000i3-3n; Mon, 28 Apr 2014 15:03:30 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Niven-Jenkins In-Reply-To: <5152EB8C-8B72-40A7-A0B3-0C887CA35258@cisco.com> Date: Mon, 28 Apr 2014 15:03:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9A1BC635-80D7-4689-8C04-31F35D183067@niven-jenkins.co.uk> References: <5152EB8C-8B72-40A7-A0B3-0C887CA35258@cisco.com> To: Francois Le Faucher X-Mailer: Apple Mail (2.1874) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/F-7DPnsuBcTIN93DpnObXaV_GBc Cc: "draft-ietf-cdni-metadata@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 6] X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 28 Apr 2014 14:03:42 -0000 Francois, I have incorporated the editorial comments from below. Some of your = comments require some discussions with my co-authors so I=92ve marked = them as =93Design=94 below and we=92ll follow up later with proposed = resolutions for them. On 24 Mar 2014, at 18:57, Francois Le Faucheur (flefauch) = wrote: > Below is the last batch. >=20 > Overall, I think the document is in good shape. > There are a whole slew of comments that are intended to improve the = doc and its readability. > But, embedded in there, there are also a number of more important = comments and questions that require some work and some discussions = before the doc can move forward (in my opinion). Since I did my review = over separate times, I might have lost track of a few things and perhaps = some of the issues I bring up are more or less already addressed, don=92t = hesitate to say so. >=20 > I hope this review helps. >=20 > Francois >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > *** section 6.3: > s/either discovered by or configured in the downstream CDN./either = configured in, or discovered by, the downstream CDN./ Done > *** section 6.4: > "Embedded, where the object is contained (or inlined) within a > property of an addressable object.=94 > What is the difference between =93inlined=94 and =93contained=94? Done > *** section 6.4: > OLD: > =93 > to mean either Y is directly embedded in X or that Y is linked to by = X. > " > NEW: > OLD: > =93 > to mean that Y is either directly embedded in X or is linked to by X. > =93 Done > *** section 6.4: > s/and which are separately addressable./and which are made separately = addressable./ Done > *** section 6.4.1: > s/All MIME types are prefixed./All MIME types for CDNI Metadata = objects are prefixed/ Done > *** section 6.4.1: > OLD: > " > The MIME type for each object matches > =93 > NEW: > " > The MIME type for each object then contains > =93 Done. > *** Section 6.4.1: > "the type name of that object as defined by this document.=94 > The phrase =93type name=94 was not clear to me. Should it not just be = the "object name=94? > For example, HostIndex is not defined as a type, it is just used as = the object name.=20 Done > *** Section 6.4.1: > OLD: > " > Table 3 lists a few examples of > the MIME Media Type for each object (resource) that is retrievable > through the CDNI Metadata interface. > =93 > NEW: > =93 > Table 3 lists a few examples of > the MIME Media Type for some object (resource) that are retrievable > through the CDNI Metadata interface. > =93 Done > *** section 6.4.1: > "See http://www.iana.org/assignments/media-types/index.html for = reference." > I was not quite sure what to do with that reference at this point in = the document. > Perhaps you coudl remove that sentence and just include teh reference = in brackets in the first sentence of section 6.4.1 like=20 > =93All MIME types ([IANA-MIME-TYPES]) for CDNI Metadata objects =85=94 Done (I just removed the URI reference as it didn=92t seem to add = anything) > *** section 6.4.2: > "CDNI Metadata objects are encoded as JSON objects=94 > This sentence leaves it ambiguous as to whether one CDNI metadat data = object can be encoded as only a single JSON object or as multiple JSON = objects. I think it is only the former. If this is true then, I suggest = =93A CDNI Metadata objects is encoded as a JSON object=94 Done > *** section 6.4.2: > OLD: > =93 > Dictionary keys in JSON are case sensitive and therefore by > convention any dictionary key defined by this document (for example > the names of CDNI Metadata object properties) MUST be represented in > lowercase. > =93 > NEW: > =93 > Dictionary keys in JSON are case sensitive. By > convention any dictionary key defined by this document (for example > the names of CDNI Metadata object properties) MUST be represented in > lowercase. > =93 > [Rationale: the 2nd part is not a consequence of the first.] Done > *** section 6.4.2: > =93If absent, all URLs in the remainder of the document must be = absolute URLs.=94 > I don=92t think =93document=94 is the right word here. please calrify = the scope of =93base=94 (eg single object, until there is another =93base=94= something else)? Done > *** section 6.4.2: > s/The links of this object to/The links from this object to/ Done > *** section 6.4.2: > "In addition to the properties specific to each object type, the keys > defined below may be present in any object.=94 > Wrt the _links key, I think it can appear =93instead=94 of the = property and not =93in addition to=94 the properties. Is that right? > For example: > "host": "video.example.com", > "_links": { > "host-metadata" : { > "type": "application/cdni.HostMetadata.v1+json", > "href": "http://metadata.example.ucdn.com/video" > we have _links=94 appear instead of =93host-metadata=94 (and then it = happens that _links contains =93host-metadata=94 ). > Can you tweak the text accordingly (not that for =93base=94 it may be = in addition, I am not sure). Done > *** section 6.4.2.1. > =93metadata.example.ucdn.com=94=20 > I think we want example domain names that finish with =93.example.com=94= or =93.example=94. The framework uses =93.example=94 for the cdn = hostnames so how about =93metadata.ucn.example=94 ? > (note that I think =93video.example.com=94 is good because it shows = the content hostnames and the cdn hostnames in completely different = domains). > Obviously this needs to be reflected everywhere. Done > I understand that URI structure is completely arbitrary but I think: > * using "http://metadata.example.ucdn.com/host1234=94 instead of = "http://metadata.example.ucdn.com/video=94 and > * using "http://metadata.example.ucdn.com/host6789=94 instead of = "http://metadata.example.ucdn.com/images=94 > woudl be more illustrative (ie it avoids using teh same patterns in = request hostnames and metadata URIs, which might be confusing for the = reader). And it is in line with the = ""http://metadata.ucdn.example.com/auth1234=94 example you have below. Done > *** section 6.4.2.1. > " > "locations": [ > { > "locations": [ > { "iprange": "192.168.0.0/16" } > ], > "action": "deny" > =93 > Should the 2nd =93locations=94 occurence above not read =93footprints"? > Then why do we not see the =93type=94 and =93value=94 properties = defined under footprints? >=20 > =93iprange=94 is not one of the footprint types defined in 7.1.1.1, = which defines IPv4range and IPv6range. Done > *** section 6.4.2.1 > " > "protocols": [ > { > "protocols": [ > "ftp" > ], > "action": "deny" > =93 > This makes me realise that it woudl be wise to rename the ProtocolACL = object property into something like =93protocol-acl=94 or whatever but = something different to =93protocols=94. So the example above would read: > " > =93protocol-acl": [ > { > "protocols": [ > "ftp" > ], > "action": "deny" > =93 > This would avoid having two properties (embedded in each other) share = the same name, which is bound to create confusion. > This goes bcak to a comment I made in different places about using = more explicit and unique property names throughout the document.=20 Design, will address in a follow-up e-mail. > *** section 6.4.2.1=20 > OLD: > " > "pattern": "/videos/trailers/*=94 > " > NEW: > =93 > "pattern": "/video/trailers/*=94 > " Done > *** section 6.4.2.1=20 > OLD: > " > "pattern": "/videos/movies/*=94 > " > NEW: > =93 > "pattern": "/video/movies/*=94 > =93 Done > *** section 6.4.2.1 > "href": "http://metadata.ucdn.example.com/videos/trailers=94 and = "href": "http://metadata.ucdn.example.com/videos/movies" > same comment as before, I=92d suggest something like = "http://metadata.ucdn.example.com/host1234/path9876" and = "http://metadata.ucdn.example.com/host1234/path7654=94 >=20 > same for "href": = "http://metadata.ucdn.example.com/videos/movies/hd=94, I=92d suggest = something like "http://metadata.ucdn.example.com/host1234/path5432=94 = (I don=92t think we need to illustrate the hierarchy of path match into = teh path metadata uris) Done. > *** section 6.4.2.1 > " > "times": [ > "times": [ > =93 > same comment as above for =93protocols=94: the top property should be = renamed (eg to something like "times-acl=94). I changed 2nd occurrence to windows to align with a change in metadata = object specification from one of you previous comments. > *** section 6.4.2.1 > " > "type": =93allow" > =93 > I think this should read : > =93 > =93action": =93allow=94 > =93 Done > *** section 6.5: > "proprietary and/or custom property Metadata=94 > What is the difference between proprietary and custom? Perhaps we = should just talk about vendor specific? Done > *** section 6.5: > OLD: > =93 > Note: Identification of the property Metadata defining organization > in the property Metadata type decreases the possibility of property > Metadata type collision. =20 > =93 > NEW: > =93 > Note: Identification inside the property Metadata type of the = organization that defined the proprietary property Metadata decreases = the possibility of property > Metadata type collision. =20 > =93 > Are we really talking about =93property Metadata type=94? or should = this read =93Metadata property name=94? I changed it to "Note: Identification, within the type name defined for = a property Metadata object, of the organization that defined the = extension property Metadata decreases the possibility of property = Metadata type collisions." which hopefully addresses both comments. > *** section 6.5.1 > "property Metadata=94 same as above: is this not more =93Metadata = property=94 (or =93Metadata properties=94)? Design, will address in a follow-up e-mail. > *** section 6.5.1 > "The uCDN may or may not know which property Metadata the dCDN > supports. =93 > I think this statement is intended to apply to vendor-specific = properties, so you should be explicit about that in the text of 6.5.1 = (as opposed to just imply it from teh discussion in section 6.5) and = always talk about =93vendor specific properties=94 . Design, will address in a follow-up e-mail. > *** section 6.5.1=20 > OLD: > =93 > In cases where the uCDN supports Metadata that the dCDN > does not, the dCDN MUST be aware of any Metadata marked as > "mandatory-to-enforce". If a CDN does not understand or is unable = to > perform the functions associated with any "mandatory-to-enforce" > Metadata, the CDN MUST NOT service any requests for the = corresponding > content. > =93 > NEW: > =93 > In the cases where the uCDN supports vendor-specific Metadata that the = dCDN > does not, the dCDN MUST enforce the semantics of the = "mandatory-to-enforce=94: If a dCDN does not understand or is unable to > perform the functions associated with any "mandatory-to-enforce=94 = vendor-specific > Metadata, the dCDN MUST NOT service any requests for the = corresponding > content. > =93 Done > *** section 6.5.1=20 > "Any standard which defines a new GenericMetadata Type MUST also > define whether or not the new metadata is mandatory-to-enforce." > Should it not also define whether it is "safe-to-redistribute=94? > I don=92t think it is appropriate to talk about =93standard=94. I = suggest rephrasing into something like =93Any document specifying new = GenericMetadata =85.=94. Done > *** section 6.5.1=20 > s/Thus, the dCDN MUST evaluate/Thus, the dCDN MUST always evaluate/ Done > *** section 6.5.2: > I would suggest changing the title of that section (and the text = accordingly) to something like =93Metadata conflicts=94. Because the = concept of metadata =93overide" is defined in section 3,3 and is = something different (ie same metadata but applying at different =93host = path" levels). >=20 > With this change of terminology (ie conflict vs override), I think the = Note could be summarised as saying that potentially conflicting metadata = may be used as long as they are structured in way that ensures that = Metadata ovveride rules avoid any actual conflict (by ensuring that = potentially conflicting metadata apply to different sets of requests). = Do you agree? to me this is easier to read than the current statement. Design, will address in a follow-up e-mail. > *** section 6.6: > =93 > The version of CDNI Metadata Structural objects is specified by the > HTTP Content-Type header. Upon responding to a request for an > object, a metadata server MUST include a Content-Type header with = the > MIME-type and version number of the object. > =93=20 > I think the wording needs to be changed because the version is part of = the MIME-type whiel the text above suggests it is conveyed in addition = to the MIME-type. > Perhaps change to: > =93 > The version of CDNI Metadata Structural objects is conveyed inside the = MIME-Type that is included in the HTTP Content-Type header. Upon = responding to a request for an > object, a metadata server MUST include a Content-Type header with = the > MIME-type containing the version number of the object. > =93 Done > *** section 6.6: > " > Unless stated otherwise, the > version of each object defined by this document is version 1. > =93 > I don=92t think any objects is defined here with a version different = to v1, so how about just saying: > =93the version of each object defined by this document is version 1.=94 Done > *** section 6.6: > "HTTP requests sent to a metadata server SHOULD include an Accept = header with the MIME-type > and version of the expected object.=93 > Can a metadata client indicate it it is happy to receive wither of two = versions eg "application/cdni.HostIndex.v1+json=94 or = "application/cdni.HostIndex.v2+json? I assme yes. Can you state that and = give some description or example? Done > *** section 6.6: > " > Any document which defines a new type of > GenericMetadata should specify the version number which it = describes." > should=97>MUST or SHOULD? Done (changed to a MUST) > *** section 7: > I don't think the proposed MIME Type allocation approach works.=20 > I think you propose: > * to have IANA allocate only the MIME-Type prefix = ("application/cdni=94) > * then assume that the CDNI Metadata spec implicitely allocates = de-facto the complete MIME-Types through a =93rule=94 which says add the = name of a metadata object + v1 + jason.=20 > I think you want to explicitely request IANA to allocate each and = every individual MIME-Type (eg all teh ones mentioned in Table 3 + the = other ones needed). > As an analogy, note that ALTO has an allocation in the MIME-TYPE = registry for each ALTO type (alto-costmap+json , = alto-costmapfilter+jso, alto-directory+json, etc.). > Also, for information, in teh cdni-logging spec we are requsting = allocation of the "application/cdni.LoggingFile=94 MIME-Type. Design, will address in a follow-up e-mail. > *** Section 7: > Why is there not a registry for the Structural metadata objects (like = there is for the generic metadata)? > Would this not make it more future-proof and extensible in case there = is a need in the future to extend the structural metadata objects? Design, will address in a follow-up e-mail. > *** section 7.1 > s/a new IANA registry is requested for "CDNI GenericMetadata Types" = namespace./a new IANA registry is requested for the "CDNI = GenericMetadata Types" namespace./ Done > *** section 7.1: > " > | Auth | RFCthis | 1 | true | true | > =93 > I think what should appear here is =93Authorization=94 (currently in = section 4.2.5) and not =93Auth=94 (currently in section 4.2.6 ). This = relates to an earlier comment that section 4.2.6 should probably be = turned into 4.2.5.1 (since Authorization contains a List of Auth). Design, will address in a follow-up e-mail. > *** section 7.1: > "the version number of the GenericMetadata set to which the > standard capability applies,=94 > I can=92t parse that. I am not sure what is this version as compared = to the versions that appear in MIME-Type. >=20 > I am also a bit confused now as to the need to register those object = names, beause the Metadata Object names registered here actually never = appear in the encoded Metadata (which only lists the corresponding set = of properties).. >=20 > Actually, this raises a serious high level question in my mind on the = way the metadata objects are defined. > So you define objects by names (eg HostIndex). But these object names = never appear in the actually encoding. What appears are the properties = comprised under the object name (e.g. =93hosts=94 for HostIndex). So it = is the first property name appearing (eg =93hosts=94) that needs to be = parsed to actually identify what objects this is (and therefore what = other properties follow). > Now if you want to keep that approach, then you need to make sure that = a new object allocated in the GenericMetadata Type registry never = allocates the same first =93property name=94, right? otherwise you = can=92t parse teh encoding and know which object it is. I don=92t think = any such restrictions is currently identified in the document. > Would it not be simpler to first list the object name in the encoding = (and then it does not matter if different objects reuse the same = property name)? >=20 > [I am not doing a complete review of the IANA section as I think we = need to close on teh previous question first]. >=20 > While I am on this, I don=92t think I have seen in the document exact = rules about which metadata object can appear and in which order, and = how many times (as I have already commented). For example, in Generic = metadata , is the object order completely unrestricted? what happens if = you have multiple instances of objects, etc.. We want to have exact = rules (on sending side and receiving side) about all this. Design, will address in a follow-up e-mail. > *** section 7.1: > =93MUST=94" as discussed before I assume you will be removing any = RFC2119 terminology from the IANA section. Design, will address in a follow-up e-mail. > *** section 8: > I think the security discussion needs some work. > Some suggestions: > * The text first indicates that the interface is to be secured = via transport security, and then it talks about bad things that can = happens with malicious server/client. This suggests that these bad = things happen even when the interface is secured. I recommend you = explain the security concern first, and then explain that these can be = protected against via transport security mechanisms. > * regarding security mechanisms, please look at the latest = approach decided for cdni-logging and align approach and wording (ie you = SHOULD use TLS except in such and such situations, you need to do this = re cipher suites,..). > * when discussing security risks, I recommend you distinguish = those that relate to authentication (ie someone spoofing the other end), = to confidentiality protection (e.g. someone being able to see metadata), = to integrity protection (someone being able to modify metadata).=20 Design, will address in a follow-up e-mail. > *** Appendix A:=20 > Like we did for cdni-logging, this appendix tracking compliance to = requirements is historical and should be removed at publication time. So = please add a note for RFC Editor stating that this whole appendix is to = be removed at publication. I=92ve removed Appendix A now to save the RFC Editor the work later. Ben From nobody Tue Apr 29 10:56:02 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C281A0957 for ; Tue, 29 Apr 2014 10:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heuEClbwkysE for ; Tue, 29 Apr 2014 10:55:53 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCA31A04E8 for ; Tue, 29 Apr 2014 10:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2419; q=dns/txt; s=iport; t=1398794152; x=1400003752; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=gODh8Dtms4MX66zVdt62owIES+KJq9yEsd2ZBfPIMYo=; b=nK1pN8AcMnUl7nRJZCW2aNyzWY1bvsJ5pgnT58vSK42jl5TI+Ug6qgGj oLe03A1oe58PtZEb0Av2rocFQr0WzPdcct8IKNJZlQMnaZpb1pI03S3qD CCT+v8FoAkKmE8YsNcH+sTf/Rzdd89Y5YyWV3nOB79Y5uSg3k6CSrZo01 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAATnX1OtJV2d/2dsb2JhbABZgwZPV71AhzmBJRZ0giUBAQEEAQEBNzQXBAIBCBEEAQELFAkHJwsUCQgCBAESCIg5DckjF417IzgGgx6BFQSaTJEmgXKBP4Ir X-IronPort-AV: E=Sophos;i="4.97,952,1389744000"; d="scan'208";a="321318242" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 29 Apr 2014 17:55:52 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s3THtpTA012342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 29 Apr 2014 17:55:51 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.55]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Tue, 29 Apr 2014 12:55:51 -0500 From: "Matt Caulfield (mcaulfie)" To: "Francois Le Faucheur (flefauch)" , "cdni@ietf.org" Thread-Topic: [CDNi] Poll for adoption of draft-leung-cdni-uri-signing-05 as a WG document Thread-Index: AQHPYJLbBLWZVv2kWEicqD5z2NlW1Jso5Oyg Date: Tue, 29 Apr 2014 17:55:51 +0000 Message-ID: <166EBB70C264A9479E459B01B1BA6C924E13A96C@xmb-aln-x03.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.76.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/7j_fQa2oMTXMhq5RcSIT6Xyw39c Subject: Re: [CDNi] Poll for adoption of draft-leung-cdni-uri-signing-05 as a WG document X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 17:55:55 -0000 URI signing is an essential feature of existing CDNs and therefore importan= t for CDNI to support. The draft in question has been through several revis= ions and I think would serve as an excellent starting point for WG adoption= . The algorithm it proposes is generic and the impact on existing CDNI inte= rfaces is in line other CDNI drafts. I am in favor of adopting draft-leung-cdni-uri-signing-05 as a WG document. Matt -----Original Message----- From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le Faucheur= (flefauch) Sent: Friday, April 25, 2014 10:30 AM To: cdni@ietf.org Subject: [CDNi] Poll for adoption of draft-leung-cdni-uri-signing-05 as a W= G document Folks, During the London meeting: * authors confirmed that they believe the latest version of draft-leung-cd= ni-uri-signing resolved the issue related to draft-ietf-appsawg-uri-get-off= -my-lawn-04.txt. * WG chairs agreed to take to the list the question of adopting draft-leun= g-cdni-uri-signing-05 as a WG document to ensure it gets sufficient review. This message is to encourage review of draft-leung-cdni-uri-signing-05 (htt= p://tools.ietf.org/id/draft-leung-cdni-uri-signing-05.txt) and sollicite fe= edback on adopting it as a WG document to address the corresponding milesto= ne on our charter. Please do so by end of 12 May (ie within the next 2 weeks). Francois & Daryl, CDNI WG Chairs For convenience, quote from IETF-89 CDNI WG meeting minutes : " Daryl (as chair): This is a deliverable on our charter, but not many people= have read the draft yet, so will take question for WG adoption to the list= to give people time to read it.=20 " For convenience, relevant excerpt from the CDNI WG charter (http://tools.ie= tf.org/wg/cdni/charters): " The working group will focus on the following items: <...> - A specification for "CDNI URI Signing". This document will specify a mechanism that allows interconnected CDNs to support access control by signing content URIs. This may involve extensions to the CDNI interfaces (e.g. CDNI Metadata interface, CDNI Logging interface). <...> Goals and Milestones: <...> Sep 2014 - Submit specification of URI Signing for CDNI to IESG as Propos= ed Standard " _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From nobody Tue Apr 29 11:06:07 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0A11A0945 for ; Tue, 29 Apr 2014 11:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mn8w64oKj2Vq for ; Tue, 29 Apr 2014 11:06:04 -0700 (PDT) Received: from exprod5og112.obsmtp.com (exprod5og112.obsmtp.com [64.18.0.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6BA1A093C for ; Tue, 29 Apr 2014 11:06:04 -0700 (PDT) Received: from mail-qc0-f170.google.com ([209.85.216.170]) (using TLSv1) by exprod5ob112.postini.com ([64.18.4.12]) with SMTP ID DSNKU1/qCwQwCxTuuvJI8tz+Zhx4rAn6rCCX@postini.com; Tue, 29 Apr 2014 11:06:03 PDT Received: by mail-qc0-f170.google.com with SMTP id x13so667050qcv.29 for ; Tue, 29 Apr 2014 11:06:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SKP2mh3emQWewVBJTqesg8vE/OcOvmejlLntBkPsFtc=; b=kg2IyDu4k1ZT5Be7njY13rr61DsCnmRG0ptsY1CT957pBBlL4FXLDiMncBgfshqzam boANec9pdOiEPlh8WIESNlG+9UuXcWRpujNw2q7gdMaQd/YwSq4y7BoWJcj49DXAEUdg QF1vgJth9RRBotkftywdxoG9JvedgYwjYwOfoIxtKx/WnHGC0JqVuR5SJ8wys2cI2KMW BPTcj8ZR/oATVWneDSL6IDtNCoPGArPxWS4ElNlCEe/n2099GjyL9AypkTxNLTecpYF8 1Tj+ov/FPy8oTfPbDo/lr7AjVGyvhgbU8/bCzfLo+VAT1ix0Lzx1TEiFCRMHR4qgykMz SYbw== X-Gm-Message-State: ALoCoQmL9+uv9K7HX3xD+5veLN/bKycJus1k/OOPm128fgnnhskyhm04SXEDTD8C4RgyumYZgrC1MaUBdvBKGmJfFkAnfGZezbzOJDyaP2syD2oZy/yaZyRruAnXgbDMqZnBgbyJ+0W3 X-Received: by 10.140.85.102 with SMTP id m93mr1297781qgd.26.1398794762549; Tue, 29 Apr 2014 11:06:02 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.85.102 with SMTP id m93mr1296740qgd.26.1398794752846; Tue, 29 Apr 2014 11:05:52 -0700 (PDT) Received: by 10.224.193.197 with HTTP; Tue, 29 Apr 2014 11:05:52 -0700 (PDT) In-Reply-To: <166EBB70C264A9479E459B01B1BA6C924E13A96C@xmb-aln-x03.cisco.com> References: <166EBB70C264A9479E459B01B1BA6C924E13A96C@xmb-aln-x03.cisco.com> Date: Tue, 29 Apr 2014 11:05:52 -0700 Message-ID: From: Scott Leibrand To: "Matt Caulfield (mcaulfie)" Content-Type: multipart/alternative; boundary=001a11c128165b9f2804f83248ac Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/q3KAGZ-FKXboH-AuaP7ldTJszFA Cc: "cdni@ietf.org" Subject: Re: [CDNi] Poll for adoption of draft-leung-cdni-uri-signing-05 as a WG document X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 29 Apr 2014 18:06:06 -0000 --001a11c128165b9f2804f83248ac Content-Type: text/plain; charset=UTF-8 +1 -Scott On Tue, Apr 29, 2014 at 10:55 AM, Matt Caulfield (mcaulfie) < mcaulfie@cisco.com> wrote: > URI signing is an essential feature of existing CDNs and therefore > important for CDNI to support. The draft in question has been through > several revisions and I think would serve as an excellent starting point > for WG adoption. The algorithm it proposes is generic and the impact on > existing CDNI interfaces is in line other CDNI drafts. > > I am in favor of adopting draft-leung-cdni-uri-signing-05 as a WG document. > > Matt > > -----Original Message----- > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le > Faucheur (flefauch) > Sent: Friday, April 25, 2014 10:30 AM > To: cdni@ietf.org > Subject: [CDNi] Poll for adoption of draft-leung-cdni-uri-signing-05 as a > WG document > > Folks, > > During the London meeting: > * authors confirmed that they believe the latest version of > draft-leung-cdni-uri-signing resolved the issue related to > draft-ietf-appsawg-uri-get-off-my-lawn-04.txt. > * WG chairs agreed to take to the list the question of adopting > draft-leung-cdni-uri-signing-05 as a WG document to ensure it gets > sufficient review. > > This message is to encourage review of draft-leung-cdni-uri-signing-05 ( > http://tools.ietf.org/id/draft-leung-cdni-uri-signing-05.txt) and > sollicite feedback on adopting it as a WG document to address the > corresponding milestone on our charter. > Please do so by end of 12 May (ie within the next 2 weeks). > > Francois & Daryl, CDNI WG Chairs > > > > For convenience, quote from IETF-89 CDNI WG meeting minutes : > " > Daryl (as chair): This is a deliverable on our charter, but not many > people have read the draft yet, so will take question for WG adoption to > the list to give people time to read it. > " > > > For convenience, relevant excerpt from the CDNI WG charter ( > http://tools.ietf.org/wg/cdni/charters): > " > The working group will focus on the following items: > <...> > - A specification for "CDNI URI Signing". This document will specify a > mechanism that allows interconnected CDNs to support access control > by signing content URIs. This may involve extensions to the CDNI > interfaces (e.g. CDNI Metadata interface, CDNI Logging interface). > > <...> > > Goals and Milestones: > <...> > Sep 2014 - Submit specification of URI Signing for CDNI to IESG as > Proposed Standard " > _______________________________________________ > 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 > -- The information in this message may be confidential. It is intended solely for the addressee(s). If you are not the intended recipient, any disclosure, copying or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. --001a11c128165b9f2804f83248ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

-Scott


On Tue, Apr 29, 2014 at 10:55 AM, Mat= t Caulfield (mcaulfie) <mcaulfie@cisco.com> wrote:
URI signing is an essential feature of exist= ing CDNs and therefore important for CDNI to support. The draft in question= has been through several revisions and I think would serve as an excellent= starting point for WG adoption. The algorithm it proposes is generic and t= he impact on existing CDNI interfaces is in line other CDNI drafts.

I am in favor of adopting draft-leung-cdni-uri-signing-05 as a WG document.=

Matt

-----Original Message-----
From: CDNi [mailto:cdni-bounces@ie= tf.org] On Behalf Of Francois Le Faucheur (flefauch)
Sent: Friday, April 25, 2014 10:30 AM
To: cdni@ietf.org
Subject: [CDNi] Poll for adoption of draft-leung-cdni-uri-signing-05 as a W= G document

Folks,

During the London meeting:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * authors confirmed that they believe the lates= t version of draft-leung-cdni-uri-signing resolved the issue related to dra= ft-ietf-appsawg-uri-get-off-my-lawn-04.txt.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * WG chairs agreed to take to the list the ques= tion of adopting draft-leung-cdni-uri-signing-05 as a WG document to ensure= it gets sufficient review.

This message is to encourage review of draft-leung-cdni-uri-signing-05 (http://tools.ietf.org/id/draft-leung-cdni-uri-signing-05.txt) and sollicite feedback on adopting it as a WG document to address the c= orresponding milestone on our charter.
Please do so by end of 12 May (ie within the next 2 weeks).

Francois & Daryl, CDNI WG Chairs



For convenience, quote from IETF-89 CDNI WG meeting minutes :
"
Daryl (as chair): This is a deliverable on our charter, but not many people= have read the draft yet, so will take question for WG adoption to the list= to give people time to read it.
"


For convenience, relevant excerpt from the CDNI WG charter (http://tools.ietf.org= /wg/cdni/charters):
"
The working group will focus on the following items:
<...>
=C2=A0 - A specification for "CDNI URI Signing". = This document will specify a
=C2=A0 =C2=A0 mechanism that allows interconnected CDNs to support access c= ontrol
=C2=A0 =C2=A0 by signing content URIs. This may involve extensions to the C= DNI
=C2=A0 =C2=A0 interfaces (e.g. CDNI Metadata interface, CDNI Logging interf= ace).

<...>

Goals and Milestones:
<...>
=C2=A0 Sep 2014 - Submit specificat= ion of URI Signing for CDNI to IESG as Proposed Standard "
_______________________________________________
CDNi mailing list
CDNi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cdni

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


The information in this message may be confidential. = =C2=A0It is intended solely for
the addre= ssee(s). =C2=A0If you are not the intended recipient, any disclosure,
copying or distribution of the message, or any= action or omission taken by you
in relia= nce on it, is prohibited and may be unlawful. =C2=A0Please immediately
contact the sender if you have received this = message in error.

--001a11c128165b9f2804f83248ac--