From nobody Sun Mar 2 04:15:47 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 DAEB21A0C54 for ; Sun, 2 Mar 2014 04:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, 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 ci3h40aOTKvw for ; Sun, 2 Mar 2014 04:15:41 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id CA7F31A0923 for ; Sun, 2 Mar 2014 04:15:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 109EA106F2C; Sun, 2 Mar 2014 13:15:38 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEQupqdPJJWJ; Sun, 2 Mar 2014 13:15:37 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id DE09C106A50; Sun, 2 Mar 2014 13:15:27 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.233]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Sun, 2 Mar 2014 13:15:27 +0100 From: Jan Seedorf To: Kevin J Ma , Jan Seedorf , "cdni@ietf.org" Thread-Topic: Date/time for CDNI FCI meeting at IETF-89 Thread-Index: Ac82ECrXe6UrDwF8Q5G2+EwB4Gk3VQ== Date: Sun, 2 Mar 2014 12:15:27 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE63B2A6E5@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.214] 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/D79eQ6gbC15MjeVlTLC3ChxCyDQ Subject: [CDNi] Date/time for CDNI FCI meeting at IETF-89 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: Sun, 02 Mar 2014 12:15:46 -0000 Thanks, Kevin! Since I have not heard from Daryl, let's go for the Wednesda= y slot: *** WED, March 5th, 15:30-17:30 *** We will meet at the IETF registration desk. I will try to organize a room by then; otherwise we will have to find one. - Jan > -----Original Message----- > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > Sent: Friday, February 28, 2014 5:52 PM > To: Jan Seedorf; cdni@ietf.org > Subject: RE: CDNI FCI meeting at IETF-89 >=20 > I can make Wed if that is easiest. >=20 > > -----Original Message----- > > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Jan Seedorf > > Sent: Friday, February 28, 2014 11:39 AM > > To: cdni@ietf.org > > Subject: Re: [CDNi] CDNI FCI meeting at IETF-89 > > > > Thanks to all who filled in the doodle so far, it seems that TUE 13:00- > > 15:00 is the best slot; however, Daryl cannot make that one. Any chance > > you can make a slot before WED afternoon, Daryl? > > > > The 2nd best slot is WED 15:30-17:30, but Kevin cannot make that one. > > Kevin? > > > > Darly, Kevin, any chance that you guys can in fact make the respective > > slot above? > > > > - Jan > > > > > -----Original Message----- > > > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Jan Seedorf > > > Sent: Thursday, February 27, 2014 3:30 PM > > > To: cdni@ietf.org > > > Subject: [CDNi] CDNI FCI meeting at IETF-89 > > > > > > Dear all, > > > > > > I took the liberty of setting up a doodle to have some discussions on > > how to > > > continue with the two current FCI proposals during the IETF-89 week (= the > > > chairs allocated some time in the official CDNI slot on THU, but I am > > afraid it > > > will not be enough if we want to make some progress): > > > > > > http://www.doodle.com/xfn59dgm5nit9v4a#table > > > > > > I also took the liberty of inviting the ALTO chairs (in cc), as they = can > > hopefully > > > enlighten us on the ALTO WG timeframe and re-chartering, as > dependency > > > on the progress of the ALTO WG has repeatedly been mentioned as > being a > > > drawback of an ALTO-based approach. > > > > > > Please all fill in the doodle if you would like to participate in thi= s > > meeting at > > > IETF-89. > > > > > > - Jan > > > > > > > -----Original Message----- > > > > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Matt Caulfie= ld > > > > (mcaulfie) > > > > Sent: Saturday, February 22, 2014 9:51 AM > > > > To: cdni@ietf.org > > > > Subject: [CDNi] FCI Analysis > > > > > > > > As promised in Vancouver, I have read through the two current FCI > > > proposals > > > > (along with some of their normative references) and I have put > > together > > > the > > > > following analysis. > > > > > > > > The text below first reviews the CDNI Requirements for FCI as well = as > > some > > > > of the highlights from the FCI Semantics. Next, a short list of (wh= at > > I feel > > > are) > > > > the key points from each draft. Finally, my analysis comparing the > > drafts > > > > based on their approach to FCI (and not the quality or the level of > > detail in > > > > the documents). > > > > > > > > If you have not done so already, then I would also recommend readi= ng > > Jon > > > > Peterson's email from February 6 ("footprint and capabilities > > > mechanisms"). > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > FCI Requirements (draft-ietf-cdni-requirements) > > > > ------------------------------------------------------------- > > > > The CDNI FCI must allow a dCDN to communicate the following to a > uCDN: > > > > 1) Ability/willingness of dCDN to handle requests from uCDN > > > > 2) Information to facilitate selection of a dCDN by uCDN (e.g. > > capabilities, > > > > resources, affinities) > > > > 3) Aggregated versions of #1 and #2 in the cascaded CDN case > > > > 4) Administrative limits and policies (e.g. max number of requests) > > > > 5) Specific capabilities including: > > > > a) delivery protocol > > > > b) acquisition protocol > > > > c) redirection mode (DNS vs HTTP) > > > > d) logging options > > > > e) metadata options > > > > 6) Delivery authorization mechanisms (e.g. uri signing) > > > > > > > > The FCI must also support extensibility and versioning for new > > capabilities > > > > and footprints. > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > FCI Semantics (draft-ietf-cdni-footprint-capabilities-semantics) > > > > ------------------------------------------------------------- > > > > Design Decisions > > > > 1) Advertising Limited Coverage - should footprints be binary or ra= ted > > via > > > > qualitative score? > > > > 2) Capabilities and Dynamic Data - what capabilities are static vs > > dynamic? If > > > > dynamic, how dynamic? > > > > 3) Advertisement vs Queries - synchronous query response model (per > > > end > > > > client request) or state replication? > > > > 4) Avoiding / Handling Cheating dCDNs - capabilities should be > > eventually > > > > verifiable by the uCDN > > > > > > > > Mandatory footprint types: > > > > 1) List of ISO Country Codes > > > > 2) List of AS numbers > > > > 3) Set of IP-prefixes > > > > > > > > FCI must be able to convey the entire footprint/capabilities and > > optionally > > > > dynamic updates. > > > > > > > > Footprints and Capabilities are dependent and tied together. Certai= n > > > > capabilities are only available for specific footprints. > > > > > > > > Important to note that most footprint information will be agreed up= on > > out > > > of > > > > band (e.g. via contracts). FCI can be considered a means for provid= ing > > > > changes or updates to that previously agreed upon set of footprints > > and > > > > capabilities. > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > FCI using ALTO (draft-seedorf-cdni-request-routing-alto-06) > > > > ------------------------------------------------------------- > > > > This proposal is based on the ALTO (Application Layer Traffic > > Optimization) > > > > protocol (draft-ietf-alto-protocol), currently under development by > > the > > > ALTO > > > > working group. ALTO protocol specification is currently an Active > > Internet- > > > > Draft in the "Submitted to IESG for Publication" state. > > > > > > > > Each dCDN hosts an ALTO server. The uCDN uses an ALTO client to > > > determine > > > > footprint and capabilities of dCDN. > > > > > > > > An ALTO Network Map indicates coverage/reachability to groups of > > > > endpoints. Endpoints are grouped into PIDs. All endpoints within a > > single > > > PID > > > > share the same capabilities. > > > > > > > > Each PID is associated with a set of properties. Each property > > corresponds > > > to > > > > a capability. The concept of a PID Property Map is defined by draft= - > > roome- > > > > alto-pid-properties (an active Internet-Draft). The same draft defi= nes > > rules > > > > for implicit inheritance of properties for overlapping PIDs (e.g. o= ne > > PID may > > > > correspond to a set of IP prefixes which is a subset of another PID= ; > > in this > > > > case, properties in the PID Property Map for the bigger set (i.e. > > shorter IP > > > > prefix) also apply to the smaller set (i.e. longer IP prefix)). > > > > > > > > Presumably the uCDN is configured with the URI for an ALTO IRD > > > > (Information Resource Directory) per dCDN. The IRD in turn provides > > two > > > > URIs. One for accessing the dCDN's Network Map and another for the > > > > dCDN's PID Property Map. However, this is not described explicitly. > > > > > > > > The draft defines the same basic set of capabilities as defined in = the > > > > requirements but does not describe their encoding in depth. > > > > > > > > The ALTO protocol only registers IPv4 and IPv6 endpoint types. > > Assuming > > > > that this draft would register ISO Country Codes and AS numbers as > new > > > > endpoint types, but not clear from the text. > > > > > > > > ALTO Cost Map could be used to determine the cost of the dCDN > > delivering > > > > to each group of endpoints (PID). > > > > > > > > The PID concept offers a level of indirection between footprints an= d > > > > capabilities allowing them to vary independently. > > > > > > > > ALTO also offers filtered querying in order to avoid fetching an > > entire > > > > network map or pid property map. > > > > > > > > Future extensions to ALTO will include asynchronous notifications a= nd > > > > incremental updates as described by draft-schwan-alto-incr-updates > > > > (currently an Expired Internet-Draft). Expecting progress soon in t= his > > area > > > > from the ALTO WG. > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > FCI using HTTP and CDNI-specific Representation (draft-ma-cdni- > > > capabilities- > > > > 04) > > > > ------------------------------------------------------------- > > > > This proposal is based on a CDNI-specific representation of footpri= nts > > and > > > > capabilities. Footprints and capabilities are encoded in JSON and > > > transported > > > > via HTTP. > > > > > > > > Stated objective is to distill dCDN resource knowledge into simple = set > > of > > > > capabilities and their footprints. That is, each capability has an > > associated > > > > footprint. > > > > > > > > The draft defines the same basic set of capabilities as defined in = the > > > > requirements and provides some examples of their encoding. > > > > > > > > Each capability has a name, a list of values, and an optional list = of > > footprints. > > > > The list of values is specific to the capability name. > > > > > > > > The optional footprint list restricts its capability. Each footprin= t > > has a type, > > > list > > > > of values, and an optional mode. The list of values is specific to = the > > > footprint > > > > type. A registry is defined for footprint types and includes countr= y > > code, AS > > > > number, and IP prefix. > > > > > > > > The footprint mode may be set to "replace", "include", or "exclude" > > which > > > > indicates how the footprint should be treated with respect to > > "previous" > > > > footprint information. In this context, "previous" refers to > > incremental > > > > updates which are sent asynchronously from the dCDN to the uCDN. > The > > > > "replace" mode indicates that any previous information about the > > footprint > > > > should be discarded and replaced entirely with the new information. > > The > > > > "include" mode indicates an addition to the footprint while "exclud= e" > > > > indications a subtraction. > > > > > > > > The draft does not provide a means for conveying footprint cost > > > information. > > > > > > > > In practice, the dCDN FCI Server would return a full F&C document i= n > > > > response to HTTP GET requests. An HTTP GET would be used to initial= ize > > > the > > > > state of the uCDN. In response to a GET, all modes are set to > > "replace". > > > > > > > > The proposal also allows the dCDN to send asynchronous HTTP POSTs t= o > > > > uCDN for updating the F&C. Updates may use "include" and "exclude" > > > > modes for partial updates. Each update includes a sequence numbers > > (via > > > an > > > > CDNI-FCI-seq HTTP header) in order to detect loss. Lost updates res= ult > > in a > > > > reset and a re-initialization. > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Analysis > > > > ------------------------------------------------------------- > > > > > > > > Transport and Encoding: both proposals rely on HTTP transport and > JSON > > > > encoding. This is a good starting point and is in line with current > > CDNI WG > > > > documents (e.g. triggers and metadata drafts). > > > > > > > > Data Representation: in the case of draft-seedorf, the existing ALT= O > > > > representations for network and property maps are leveraged. These > > data > > > > structures clearly fit the CDNI use case and have the benefit of pr= ior > > > review. > > > > In the case of draft-ma, a new CDNI-specific representation is > > defined. > > > There > > > > is no clear technical deficiency with either approach given that a > > newly > > > > defined representation can be as flexible as needed and the ALTO > > > > representation is generic enough to support the CDNI use case. > > Leveraging > > > > an existing protocol has obvious advantages but it is unclear to me > > whether > > > > or not adding a dependency on the ALTO WG will be problematic in an= y > > > way. > > > > > > > > Hierarchy: in the case of draft-seedorf, footprints have capabiliti= es. > > In the > > > > case of draft-ma, capabilities have footprints. In the single CDN > > case, > > > neither > > > > option is deficient. In the cascaded CDN case, the draft-seedorf > > approach > > > > seems more intuitive. Aggregated footprint and capability informati= on > > is > > > > constructed simply by appending the footprints of all dCDNs. > > > > > > > > Cost Information: in the case of draft-seedorf, a loose description= is > > > provided > > > > of how to apply ALTO Cost Maps to footprints. In the case of draft-= ma, > > no > > > > solution is described. Cost information is only useful when multipl= e > > dCDNs > > > > can claim the same end clients in their footprint advertisements. > > However, > > > > regardless of the use case, business logic is likely to kick in bef= ore > > such cost > > > > metrics would be useful. Neither approach includes a definitive > > proposal in > > > > this area. > > > > > > > > Extensibility and Versioning: Versioning of the FCI protocol is not > > discussed > > > > by either draft. Extensibility is alluded to and is clearly possibl= e. > > However, > > > the > > > > details are lacking in this area. > > > > > > > > Dependence on ALTO WG: In the case of draft-seedorf, a dependency > is > > > > introduced on the ALTO WG and a few drafts in progress. In the case= of > > > draft- > > > > ma, no such dependency is required. The benefits of leveraging ALTO > > > include > > > > the ability to easily reuse the work that the ALTO WG has done in > > > hardening > > > > the error handling, security, encoding, and processing of the ALTO > > protocol. > > > > However, the difficulty of these efforts is not insurmountable and > > could be > > > > reproduced in a CDNI-specific proposal. > > > > > > > > Capability Inheritance: in the case of draft-seedorf, the PID Prope= rty > > Map > > > > defines rules for implicit inheritance between multiple overlapping > > PIDs. In > > > > the case of draft-ma, no special inheritance rules exist. These > > inheritance > > > > rules may complicate implementation of FCI. Completely explicit > > > capabilities, > > > > such as in draft-ma, may be a better approach. > > > > > > > > Update Notifications: in the case of draft-seedorf, no strong story > > for > > > update > > > > notifications is provided. The ALTO Incremental Updates draft is > > > referenced. > > > > However, this draft is expired. In the case of draft-ma, an HTTP PO= ST > > may > > > be > > > > sent from dCDN to uCDN which includes the incremental update. > Assuming > > > > that update notifications is a real requirement, then draft-ma has = a > > more > > > > concrete approach in this area. However, a bidirectional HTTP > > interface > > > > breaks the RESTful nature of the interface. > > > > > > > > Incremental Updates: in the case of draft-seedorf, the ALTO > > Incremental > > > > Update draft is referenced. This draft describes the use of JSON Pa= tch > > for > > > > encoding incremental changes to ALTO information. Additionally, ALT= O > > > allows > > > > for filtered queries which could be used for obtaining partial > > information. In > > > > the case of draft-ma, a scheme including sequence numbers, a new > HTTP > > > > header, and a "mode" is used for conveying incremental changes via > > HTTP > > > > POST. Like the update notifications, the draft-ma proposal is more > > concrete > > > > in this area. However, again, the ALTO approach is more RESTful. > > > Additionally, > > > > adding a new HTTP header for this purpose may not be workable. > > > > > > > > Draft Maturity: both draft-seedorf and draft-ma require another lev= el > > of > > > > detail. Neither describe versioning and extensibility. Neither disc= uss > > the > > > > encoding of logging and metadata capabilities which may pose > > significant > > > > challenges. > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Conclusion > > > > ------------------------------------------------------------- > > > > All in all, both drafts are well-written and viable candidates as a > > starting > > > point > > > > for our FCI standard. > > > > > > > > I would suggest that the working group must first decide whether th= e > > > > benefits of reusing the ALTO syntax and semantics outweigh the cost= s > > or if > > > > defining something CDNI-specific is a better option. As far as I ca= n > > tell, the > > > > data representation defined by ALTO meets the needs of CDNI. My > only > > > > concern is a dependency on the progress of the ALTO WG. Starting wi= th > > a > > > > CDNI-specific representation provides maximum flexibility. > > > > > > > > I would also recommend that we first focus on a simple HTTP GET > > interface > > > > and then, once stable, turn our attention to incremental updates. > > > > > > > > Cheers, > > > > Matt > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni From nobody Sun Mar 2 14:01:43 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 82DF01A0B34 for ; Sun, 2 Mar 2014 14:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.311 X-Spam-Level: X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.547] 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 WYmpAzB9ni5K for ; Sun, 2 Mar 2014 14:01:38 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 08DD31A0B28 for ; Sun, 2 Mar 2014 14:01:37 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id s22M1Pj0031232; Sun, 2 Mar 2014 15:01:26 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Sun, 02 Mar 2014 15:01:25 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0174.001; Sun, 2 Mar 2014 15:01:25 -0700 From: Daryl Malas To: Jan Seedorf , Kevin J Ma , "cdni@ietf.org" Thread-Topic: [CDNi] Date/time for CDNI FCI meeting at IETF-89 Thread-Index: AQHPNmL0mMAoEH+JcEKUpNmpCJsuNQ== Date: Sun, 2 Mar 2014 22:01:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="us-ascii" Content-ID: <39F9A06283968A4D9A0951A28A156E79@cablelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/OfzHlqRgpSzmL6gr-QikFTIkJak Subject: Re: [CDNi] Date/time for CDNI FCI meeting at IETF-89 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: Sun, 02 Mar 2014 22:01:41 -0000 Jan, Sorry, I was on holiday and then traveling this afternoon when I saw your email. My flight gets into London around 10:30am, so I should be able to make the meeting. If not readily apparent and as a note, I will only be at the IETF from Wednesday - Friday. Thanks, Daryl On 3/2/14, 7:15 AM, "Jan Seedorf" wrote: >Thanks, Kevin! Since I have not heard from Daryl, let's go for the >Wednesday slot: > >*** WED, March 5th, 15:30-17:30 *** > >We will meet at the IETF registration desk. > >I will try to organize a room by then; otherwise we will have to find one. > > - Jan > >> -----Original Message----- >> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >> Sent: Friday, February 28, 2014 5:52 PM >> To: Jan Seedorf; cdni@ietf.org >> Subject: RE: CDNI FCI meeting at IETF-89 >>=20 >> I can make Wed if that is easiest. >>=20 >> > -----Original Message----- >> > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Jan Seedorf >> > Sent: Friday, February 28, 2014 11:39 AM >> > To: cdni@ietf.org >> > Subject: Re: [CDNi] CDNI FCI meeting at IETF-89 >> > >> > Thanks to all who filled in the doodle so far, it seems that TUE >>13:00- >> > 15:00 is the best slot; however, Daryl cannot make that one. Any >>chance >> > you can make a slot before WED afternoon, Daryl? >> > >> > The 2nd best slot is WED 15:30-17:30, but Kevin cannot make that one. >> > Kevin? >> > >> > Darly, Kevin, any chance that you guys can in fact make the respective >> > slot above? >> > >> > - Jan >> > >> > > -----Original Message----- >> > > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Jan Seedorf >> > > Sent: Thursday, February 27, 2014 3:30 PM >> > > To: cdni@ietf.org >> > > Subject: [CDNi] CDNI FCI meeting at IETF-89 >> > > >> > > Dear all, >> > > >> > > I took the liberty of setting up a doodle to have some discussions >>on >> > how to >> > > continue with the two current FCI proposals during the IETF-89 week >>(the >> > > chairs allocated some time in the official CDNI slot on THU, but I >>am >> > afraid it >> > > will not be enough if we want to make some progress): >> > > >> > > http://www.doodle.com/xfn59dgm5nit9v4a#table >> > > >> > > I also took the liberty of inviting the ALTO chairs (in cc), as >>they can >> > hopefully >> > > enlighten us on the ALTO WG timeframe and re-chartering, as >> dependency >> > > on the progress of the ALTO WG has repeatedly been mentioned as >> being a >> > > drawback of an ALTO-based approach. >> > > >> > > Please all fill in the doodle if you would like to participate in >>this >> > meeting at >> > > IETF-89. >> > > >> > > - Jan >> > > >> > > > -----Original Message----- >> > > > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Matt >>Caulfield >> > > > (mcaulfie) >> > > > Sent: Saturday, February 22, 2014 9:51 AM >> > > > To: cdni@ietf.org >> > > > Subject: [CDNi] FCI Analysis >> > > > >> > > > As promised in Vancouver, I have read through the two current FCI >> > > proposals >> > > > (along with some of their normative references) and I have put >> > together >> > > the >> > > > following analysis. >> > > > >> > > > The text below first reviews the CDNI Requirements for FCI as >>well as >> > some >> > > > of the highlights from the FCI Semantics. Next, a short list of >>(what >> > I feel >> > > are) >> > > > the key points from each draft. Finally, my analysis comparing the >> > drafts >> > > > based on their approach to FCI (and not the quality or the level >>of >> > detail in >> > > > the documents). >> > > > >> > > > If you have not done so already, then I would also recommend >>reading >> > Jon >> > > > Peterson's email from February 6 ("footprint and capabilities >> > > mechanisms"). >> > > > >> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > > > FCI Requirements (draft-ietf-cdni-requirements) >> > > > ------------------------------------------------------------- >> > > > The CDNI FCI must allow a dCDN to communicate the following to a >> uCDN: >> > > > 1) Ability/willingness of dCDN to handle requests from uCDN >> > > > 2) Information to facilitate selection of a dCDN by uCDN (e.g. >> > capabilities, >> > > > resources, affinities) >> > > > 3) Aggregated versions of #1 and #2 in the cascaded CDN case >> > > > 4) Administrative limits and policies (e.g. max number of >>requests) >> > > > 5) Specific capabilities including: >> > > > a) delivery protocol >> > > > b) acquisition protocol >> > > > c) redirection mode (DNS vs HTTP) >> > > > d) logging options >> > > > e) metadata options >> > > > 6) Delivery authorization mechanisms (e.g. uri signing) >> > > > >> > > > The FCI must also support extensibility and versioning for new >> > capabilities >> > > > and footprints. >> > > > >> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > > > FCI Semantics (draft-ietf-cdni-footprint-capabilities-semantics) >> > > > ------------------------------------------------------------- >> > > > Design Decisions >> > > > 1) Advertising Limited Coverage - should footprints be binary or >>rated >> > via >> > > > qualitative score? >> > > > 2) Capabilities and Dynamic Data - what capabilities are static vs >> > dynamic? If >> > > > dynamic, how dynamic? >> > > > 3) Advertisement vs Queries - synchronous query response model >>(per >> > > end >> > > > client request) or state replication? >> > > > 4) Avoiding / Handling Cheating dCDNs - capabilities should be >> > eventually >> > > > verifiable by the uCDN >> > > > >> > > > Mandatory footprint types: >> > > > 1) List of ISO Country Codes >> > > > 2) List of AS numbers >> > > > 3) Set of IP-prefixes >> > > > >> > > > FCI must be able to convey the entire footprint/capabilities and >> > optionally >> > > > dynamic updates. >> > > > >> > > > Footprints and Capabilities are dependent and tied together. >>Certain >> > > > capabilities are only available for specific footprints. >> > > > >> > > > Important to note that most footprint information will be agreed >>upon >> > out >> > > of >> > > > band (e.g. via contracts). FCI can be considered a means for >>providing >> > > > changes or updates to that previously agreed upon set of >>footprints >> > and >> > > > capabilities. >> > > > >> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > > > FCI using ALTO (draft-seedorf-cdni-request-routing-alto-06) >> > > > ------------------------------------------------------------- >> > > > This proposal is based on the ALTO (Application Layer Traffic >> > Optimization) >> > > > protocol (draft-ietf-alto-protocol), currently under development >>by >> > the >> > > ALTO >> > > > working group. ALTO protocol specification is currently an Active >> > Internet- >> > > > Draft in the "Submitted to IESG for Publication" state. >> > > > >> > > > Each dCDN hosts an ALTO server. The uCDN uses an ALTO client to >> > > determine >> > > > footprint and capabilities of dCDN. >> > > > >> > > > An ALTO Network Map indicates coverage/reachability to groups of >> > > > endpoints. Endpoints are grouped into PIDs. All endpoints within a >> > single >> > > PID >> > > > share the same capabilities. >> > > > >> > > > Each PID is associated with a set of properties. Each property >> > corresponds >> > > to >> > > > a capability. The concept of a PID Property Map is defined by >>draft- >> > roome- >> > > > alto-pid-properties (an active Internet-Draft). The same draft >>defines >> > rules >> > > > for implicit inheritance of properties for overlapping PIDs (e.g. >>one >> > PID may >> > > > correspond to a set of IP prefixes which is a subset of another >>PID; >> > in this >> > > > case, properties in the PID Property Map for the bigger set (i.e. >> > shorter IP >> > > > prefix) also apply to the smaller set (i.e. longer IP prefix)). >> > > > >> > > > Presumably the uCDN is configured with the URI for an ALTO IRD >> > > > (Information Resource Directory) per dCDN. The IRD in turn >>provides >> > two >> > > > URIs. One for accessing the dCDN's Network Map and another for the >> > > > dCDN's PID Property Map. However, this is not described >>explicitly. >> > > > >> > > > The draft defines the same basic set of capabilities as defined >>in the >> > > > requirements but does not describe their encoding in depth. >> > > > >> > > > The ALTO protocol only registers IPv4 and IPv6 endpoint types. >> > Assuming >> > > > that this draft would register ISO Country Codes and AS numbers as >> new >> > > > endpoint types, but not clear from the text. >> > > > >> > > > ALTO Cost Map could be used to determine the cost of the dCDN >> > delivering >> > > > to each group of endpoints (PID). >> > > > >> > > > The PID concept offers a level of indirection between footprints >>and >> > > > capabilities allowing them to vary independently. >> > > > >> > > > ALTO also offers filtered querying in order to avoid fetching an >> > entire >> > > > network map or pid property map. >> > > > >> > > > Future extensions to ALTO will include asynchronous notifications >>and >> > > > incremental updates as described by draft-schwan-alto-incr-updates >> > > > (currently an Expired Internet-Draft). Expecting progress soon in >>this >> > area >> > > > from the ALTO WG. >> > > > >> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > > > FCI using HTTP and CDNI-specific Representation (draft-ma-cdni- >> > > capabilities- >> > > > 04) >> > > > ------------------------------------------------------------- >> > > > This proposal is based on a CDNI-specific representation of >>footprints >> > and >> > > > capabilities. Footprints and capabilities are encoded in JSON and >> > > transported >> > > > via HTTP. >> > > > >> > > > Stated objective is to distill dCDN resource knowledge into >>simple set >> > of >> > > > capabilities and their footprints. That is, each capability has an >> > associated >> > > > footprint. >> > > > >> > > > The draft defines the same basic set of capabilities as defined >>in the >> > > > requirements and provides some examples of their encoding. >> > > > >> > > > Each capability has a name, a list of values, and an optional >>list of >> > footprints. >> > > > The list of values is specific to the capability name. >> > > > >> > > > The optional footprint list restricts its capability. Each >>footprint >> > has a type, >> > > list >> > > > of values, and an optional mode. The list of values is specific >>to the >> > > footprint >> > > > type. A registry is defined for footprint types and includes >>country >> > code, AS >> > > > number, and IP prefix. >> > > > >> > > > The footprint mode may be set to "replace", "include", or >>"exclude" >> > which >> > > > indicates how the footprint should be treated with respect to >> > "previous" >> > > > footprint information. In this context, "previous" refers to >> > incremental >> > > > updates which are sent asynchronously from the dCDN to the uCDN. >> The >> > > > "replace" mode indicates that any previous information about the >> > footprint >> > > > should be discarded and replaced entirely with the new >>information. >> > The >> > > > "include" mode indicates an addition to the footprint while >>"exclude" >> > > > indications a subtraction. >> > > > >> > > > The draft does not provide a means for conveying footprint cost >> > > information. >> > > > >> > > > In practice, the dCDN FCI Server would return a full F&C document >>in >> > > > response to HTTP GET requests. An HTTP GET would be used to >>initialize >> > > the >> > > > state of the uCDN. In response to a GET, all modes are set to >> > "replace". >> > > > >> > > > The proposal also allows the dCDN to send asynchronous HTTP POSTs >>to >> > > > uCDN for updating the F&C. Updates may use "include" and "exclude" >> > > > modes for partial updates. Each update includes a sequence numbers >> > (via >> > > an >> > > > CDNI-FCI-seq HTTP header) in order to detect loss. Lost updates >>result >> > in a >> > > > reset and a re-initialization. >> > > > >> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > > > Analysis >> > > > ------------------------------------------------------------- >> > > > >> > > > Transport and Encoding: both proposals rely on HTTP transport and >> JSON >> > > > encoding. This is a good starting point and is in line with >>current >> > CDNI WG >> > > > documents (e.g. triggers and metadata drafts). >> > > > >> > > > Data Representation: in the case of draft-seedorf, the existing >>ALTO >> > > > representations for network and property maps are leveraged. These >> > data >> > > > structures clearly fit the CDNI use case and have the benefit of >>prior >> > > review. >> > > > In the case of draft-ma, a new CDNI-specific representation is >> > defined. >> > > There >> > > > is no clear technical deficiency with either approach given that a >> > newly >> > > > defined representation can be as flexible as needed and the ALTO >> > > > representation is generic enough to support the CDNI use case. >> > Leveraging >> > > > an existing protocol has obvious advantages but it is unclear to >>me >> > whether >> > > > or not adding a dependency on the ALTO WG will be problematic in >>any >> > > way. >> > > > >> > > > Hierarchy: in the case of draft-seedorf, footprints have >>capabilities. >> > In the >> > > > case of draft-ma, capabilities have footprints. In the single CDN >> > case, >> > > neither >> > > > option is deficient. In the cascaded CDN case, the draft-seedorf >> > approach >> > > > seems more intuitive. Aggregated footprint and capability >>information >> > is >> > > > constructed simply by appending the footprints of all dCDNs. >> > > > >> > > > Cost Information: in the case of draft-seedorf, a loose >>description is >> > > provided >> > > > of how to apply ALTO Cost Maps to footprints. In the case of >>draft-ma, >> > no >> > > > solution is described. Cost information is only useful when >>multiple >> > dCDNs >> > > > can claim the same end clients in their footprint advertisements. >> > However, >> > > > regardless of the use case, business logic is likely to kick in >>before >> > such cost >> > > > metrics would be useful. Neither approach includes a definitive >> > proposal in >> > > > this area. >> > > > >> > > > Extensibility and Versioning: Versioning of the FCI protocol is >>not >> > discussed >> > > > by either draft. Extensibility is alluded to and is clearly >>possible. >> > However, >> > > the >> > > > details are lacking in this area. >> > > > >> > > > Dependence on ALTO WG: In the case of draft-seedorf, a dependency >> is >> > > > introduced on the ALTO WG and a few drafts in progress. In the >>case of >> > > draft- >> > > > ma, no such dependency is required. The benefits of leveraging >>ALTO >> > > include >> > > > the ability to easily reuse the work that the ALTO WG has done in >> > > hardening >> > > > the error handling, security, encoding, and processing of the ALTO >> > protocol. >> > > > However, the difficulty of these efforts is not insurmountable and >> > could be >> > > > reproduced in a CDNI-specific proposal. >> > > > >> > > > Capability Inheritance: in the case of draft-seedorf, the PID >>Property >> > Map >> > > > defines rules for implicit inheritance between multiple >>overlapping >> > PIDs. In >> > > > the case of draft-ma, no special inheritance rules exist. These >> > inheritance >> > > > rules may complicate implementation of FCI. Completely explicit >> > > capabilities, >> > > > such as in draft-ma, may be a better approach. >> > > > >> > > > Update Notifications: in the case of draft-seedorf, no strong >>story >> > for >> > > update >> > > > notifications is provided. The ALTO Incremental Updates draft is >> > > referenced. >> > > > However, this draft is expired. In the case of draft-ma, an HTTP >>POST >> > may >> > > be >> > > > sent from dCDN to uCDN which includes the incremental update. >> Assuming >> > > > that update notifications is a real requirement, then draft-ma >>has a >> > more >> > > > concrete approach in this area. However, a bidirectional HTTP >> > interface >> > > > breaks the RESTful nature of the interface. >> > > > >> > > > Incremental Updates: in the case of draft-seedorf, the ALTO >> > Incremental >> > > > Update draft is referenced. This draft describes the use of JSON >>Patch >> > for >> > > > encoding incremental changes to ALTO information. Additionally, >>ALTO >> > > allows >> > > > for filtered queries which could be used for obtaining partial >> > information. In >> > > > the case of draft-ma, a scheme including sequence numbers, a new >> HTTP >> > > > header, and a "mode" is used for conveying incremental changes via >> > HTTP >> > > > POST. Like the update notifications, the draft-ma proposal is more >> > concrete >> > > > in this area. However, again, the ALTO approach is more RESTful. >> > > Additionally, >> > > > adding a new HTTP header for this purpose may not be workable. >> > > > >> > > > Draft Maturity: both draft-seedorf and draft-ma require another >>level >> > of >> > > > detail. Neither describe versioning and extensibility. Neither >>discuss >> > the >> > > > encoding of logging and metadata capabilities which may pose >> > significant >> > > > challenges. >> > > > >> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > > > Conclusion >> > > > ------------------------------------------------------------- >> > > > All in all, both drafts are well-written and viable candidates as >>a >> > starting >> > > point >> > > > for our FCI standard. >> > > > >> > > > I would suggest that the working group must first decide whether >>the >> > > > benefits of reusing the ALTO syntax and semantics outweigh the >>costs >> > or if >> > > > defining something CDNI-specific is a better option. As far as I >>can >> > tell, the >> > > > data representation defined by ALTO meets the needs of CDNI. My >> only >> > > > concern is a dependency on the progress of the ALTO WG. Starting >>with >> > a >> > > > CDNI-specific representation provides maximum flexibility. >> > > > >> > > > I would also recommend that we first focus on a simple HTTP GET >> > interface >> > > > and then, once stable, turn our attention to incremental updates. >> > > > >> > > > Cheers, >> > > > Matt >> > > > >> > > > >> > > > _______________________________________________ >> > > > 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 >> > >> > _______________________________________________ >> > CDNi mailing list >> > CDNi@ietf.org >> > https://www.ietf.org/mailman/listinfo/cdni > >_______________________________________________ >CDNi mailing list >CDNi@ietf.org >https://www.ietf.org/mailman/listinfo/cdni From nobody Mon Mar 3 01:44: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 DDB161A0974 for ; Mon, 3 Mar 2014 01:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, 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 5Poo_oBwZG-V for ; Mon, 3 Mar 2014 01:44:09 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADA71A0C0A for ; Mon, 3 Mar 2014 01:44:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 187E9106DFC; Mon, 3 Mar 2014 10:44:06 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8TKLQEcU6PM; Mon, 3 Mar 2014 10:44:06 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id ECBE0106F3D; Mon, 3 Mar 2014 10:43:50 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.233]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 3 Mar 2014 10:43:45 +0100 From: Jan Seedorf To: Daryl Malas , Jan Seedorf , Kevin J Ma , "cdni@ietf.org" Thread-Topic: [CDNi] Date/time for CDNI FCI meeting at IETF-89 Thread-Index: AQHPNmL0mMAoEH+JcEKUpNmpCJsuNZrPHTQw Date: Mon, 3 Mar 2014 09:43:46 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE63B2ADC1@PALLENE.office.hd> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.204] 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/Akfe_DII9Pj9eex9pI4y7jh2w34 Subject: Re: [CDNi] Date/time for CDNI FCI meeting at IETF-89 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, 03 Mar 2014 09:44:14 -0000 Hi Daryl, Thanks for the confirmation, good that you can join. See you on Wednesday, - Jan > -----Original Message----- > From: Daryl Malas [mailto:D.Malas@cablelabs.com] > Sent: Sunday, March 02, 2014 11:01 PM > To: Jan Seedorf; Kevin J Ma; cdni@ietf.org > Subject: Re: [CDNi] Date/time for CDNI FCI meeting at IETF-89 >=20 > Jan, >=20 > Sorry, I was on holiday and then traveling this afternoon when I saw your > email. My flight gets into London around 10:30am, so I should be able to > make the meeting. If not readily apparent and as a note, I will only be > at the IETF from Wednesday - Friday. >=20 > Thanks, >=20 > Daryl >=20 > On 3/2/14, 7:15 AM, "Jan Seedorf" wrote: >=20 > >Thanks, Kevin! Since I have not heard from Daryl, let's go for the > >Wednesday slot: > > > >*** WED, March 5th, 15:30-17:30 *** > > > >We will meet at the IETF registration desk. > > > >I will try to organize a room by then; otherwise we will have to find on= e. > > > > - Jan > > > >> -----Original Message----- > >> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > >> Sent: Friday, February 28, 2014 5:52 PM > >> To: Jan Seedorf; cdni@ietf.org > >> Subject: RE: CDNI FCI meeting at IETF-89 > >> > >> I can make Wed if that is easiest. > >> > >> > -----Original Message----- > >> > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Jan Seedorf > >> > Sent: Friday, February 28, 2014 11:39 AM > >> > To: cdni@ietf.org > >> > Subject: Re: [CDNi] CDNI FCI meeting at IETF-89 > >> > > >> > Thanks to all who filled in the doodle so far, it seems that TUE > >>13:00- > >> > 15:00 is the best slot; however, Daryl cannot make that one. Any > >>chance > >> > you can make a slot before WED afternoon, Daryl? > >> > > >> > The 2nd best slot is WED 15:30-17:30, but Kevin cannot make that one= . > >> > Kevin? > >> > > >> > Darly, Kevin, any chance that you guys can in fact make the respecti= ve > >> > slot above? > >> > > >> > - Jan > >> > > >> > > -----Original Message----- > >> > > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Jan Seedorf > >> > > Sent: Thursday, February 27, 2014 3:30 PM > >> > > To: cdni@ietf.org > >> > > Subject: [CDNi] CDNI FCI meeting at IETF-89 > >> > > > >> > > Dear all, > >> > > > >> > > I took the liberty of setting up a doodle to have some discussions > >>on > >> > how to > >> > > continue with the two current FCI proposals during the IETF-89 wee= k > >>(the > >> > > chairs allocated some time in the official CDNI slot on THU, but I > >>am > >> > afraid it > >> > > will not be enough if we want to make some progress): > >> > > > >> > > http://www.doodle.com/xfn59dgm5nit9v4a#table > >> > > > >> > > I also took the liberty of inviting the ALTO chairs (in cc), as > >>they can > >> > hopefully > >> > > enlighten us on the ALTO WG timeframe and re-chartering, as > >> dependency > >> > > on the progress of the ALTO WG has repeatedly been mentioned as > >> being a > >> > > drawback of an ALTO-based approach. > >> > > > >> > > Please all fill in the doodle if you would like to participate in > >>this > >> > meeting at > >> > > IETF-89. > >> > > > >> > > - Jan > >> > > > >> > > > -----Original Message----- > >> > > > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Matt > >>Caulfield > >> > > > (mcaulfie) > >> > > > Sent: Saturday, February 22, 2014 9:51 AM > >> > > > To: cdni@ietf.org > >> > > > Subject: [CDNi] FCI Analysis > >> > > > > >> > > > As promised in Vancouver, I have read through the two current FC= I > >> > > proposals > >> > > > (along with some of their normative references) and I have put > >> > together > >> > > the > >> > > > following analysis. > >> > > > > >> > > > The text below first reviews the CDNI Requirements for FCI as > >>well as > >> > some > >> > > > of the highlights from the FCI Semantics. Next, a short list of > >>(what > >> > I feel > >> > > are) > >> > > > the key points from each draft. Finally, my analysis comparing t= he > >> > drafts > >> > > > based on their approach to FCI (and not the quality or the level > >>of > >> > detail in > >> > > > the documents). > >> > > > > >> > > > If you have not done so already, then I would also recommend > >>reading > >> > Jon > >> > > > Peterson's email from February 6 ("footprint and capabilities > >> > > mechanisms"). > >> > > > > >> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > > > FCI Requirements (draft-ietf-cdni-requirements) > >> > > > ------------------------------------------------------------- > >> > > > The CDNI FCI must allow a dCDN to communicate the following to a > >> uCDN: > >> > > > 1) Ability/willingness of dCDN to handle requests from uCDN > >> > > > 2) Information to facilitate selection of a dCDN by uCDN (e.g. > >> > capabilities, > >> > > > resources, affinities) > >> > > > 3) Aggregated versions of #1 and #2 in the cascaded CDN case > >> > > > 4) Administrative limits and policies (e.g. max number of > >>requests) > >> > > > 5) Specific capabilities including: > >> > > > a) delivery protocol > >> > > > b) acquisition protocol > >> > > > c) redirection mode (DNS vs HTTP) > >> > > > d) logging options > >> > > > e) metadata options > >> > > > 6) Delivery authorization mechanisms (e.g. uri signing) > >> > > > > >> > > > The FCI must also support extensibility and versioning for new > >> > capabilities > >> > > > and footprints. > >> > > > > >> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > > > FCI Semantics (draft-ietf-cdni-footprint-capabilities-semantics) > >> > > > ------------------------------------------------------------- > >> > > > Design Decisions > >> > > > 1) Advertising Limited Coverage - should footprints be binary or > >>rated > >> > via > >> > > > qualitative score? > >> > > > 2) Capabilities and Dynamic Data - what capabilities are static = vs > >> > dynamic? If > >> > > > dynamic, how dynamic? > >> > > > 3) Advertisement vs Queries - synchronous query response model > >>(per > >> > > end > >> > > > client request) or state replication? > >> > > > 4) Avoiding / Handling Cheating dCDNs - capabilities should be > >> > eventually > >> > > > verifiable by the uCDN > >> > > > > >> > > > Mandatory footprint types: > >> > > > 1) List of ISO Country Codes > >> > > > 2) List of AS numbers > >> > > > 3) Set of IP-prefixes > >> > > > > >> > > > FCI must be able to convey the entire footprint/capabilities and > >> > optionally > >> > > > dynamic updates. > >> > > > > >> > > > Footprints and Capabilities are dependent and tied together. > >>Certain > >> > > > capabilities are only available for specific footprints. > >> > > > > >> > > > Important to note that most footprint information will be agreed > >>upon > >> > out > >> > > of > >> > > > band (e.g. via contracts). FCI can be considered a means for > >>providing > >> > > > changes or updates to that previously agreed upon set of > >>footprints > >> > and > >> > > > capabilities. > >> > > > > >> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > > > FCI using ALTO (draft-seedorf-cdni-request-routing-alto-06) > >> > > > ------------------------------------------------------------- > >> > > > This proposal is based on the ALTO (Application Layer Traffic > >> > Optimization) > >> > > > protocol (draft-ietf-alto-protocol), currently under development > >>by > >> > the > >> > > ALTO > >> > > > working group. ALTO protocol specification is currently an Activ= e > >> > Internet- > >> > > > Draft in the "Submitted to IESG for Publication" state. > >> > > > > >> > > > Each dCDN hosts an ALTO server. The uCDN uses an ALTO client to > >> > > determine > >> > > > footprint and capabilities of dCDN. > >> > > > > >> > > > An ALTO Network Map indicates coverage/reachability to groups of > >> > > > endpoints. Endpoints are grouped into PIDs. All endpoints within= a > >> > single > >> > > PID > >> > > > share the same capabilities. > >> > > > > >> > > > Each PID is associated with a set of properties. Each property > >> > corresponds > >> > > to > >> > > > a capability. The concept of a PID Property Map is defined by > >>draft- > >> > roome- > >> > > > alto-pid-properties (an active Internet-Draft). The same draft > >>defines > >> > rules > >> > > > for implicit inheritance of properties for overlapping PIDs (e.g= . > >>one > >> > PID may > >> > > > correspond to a set of IP prefixes which is a subset of another > >>PID; > >> > in this > >> > > > case, properties in the PID Property Map for the bigger set (i.e= . > >> > shorter IP > >> > > > prefix) also apply to the smaller set (i.e. longer IP prefix)). > >> > > > > >> > > > Presumably the uCDN is configured with the URI for an ALTO IRD > >> > > > (Information Resource Directory) per dCDN. The IRD in turn > >>provides > >> > two > >> > > > URIs. One for accessing the dCDN's Network Map and another for > the > >> > > > dCDN's PID Property Map. However, this is not described > >>explicitly. > >> > > > > >> > > > The draft defines the same basic set of capabilities as defined > >>in the > >> > > > requirements but does not describe their encoding in depth. > >> > > > > >> > > > The ALTO protocol only registers IPv4 and IPv6 endpoint types. > >> > Assuming > >> > > > that this draft would register ISO Country Codes and AS numbers = as > >> new > >> > > > endpoint types, but not clear from the text. > >> > > > > >> > > > ALTO Cost Map could be used to determine the cost of the dCDN > >> > delivering > >> > > > to each group of endpoints (PID). > >> > > > > >> > > > The PID concept offers a level of indirection between footprints > >>and > >> > > > capabilities allowing them to vary independently. > >> > > > > >> > > > ALTO also offers filtered querying in order to avoid fetching an > >> > entire > >> > > > network map or pid property map. > >> > > > > >> > > > Future extensions to ALTO will include asynchronous notification= s > >>and > >> > > > incremental updates as described by draft-schwan-alto-incr-updat= es > >> > > > (currently an Expired Internet-Draft). Expecting progress soon i= n > >>this > >> > area > >> > > > from the ALTO WG. > >> > > > > >> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > > > FCI using HTTP and CDNI-specific Representation (draft-ma-cdni- > >> > > capabilities- > >> > > > 04) > >> > > > ------------------------------------------------------------- > >> > > > This proposal is based on a CDNI-specific representation of > >>footprints > >> > and > >> > > > capabilities. Footprints and capabilities are encoded in JSON an= d > >> > > transported > >> > > > via HTTP. > >> > > > > >> > > > Stated objective is to distill dCDN resource knowledge into > >>simple set > >> > of > >> > > > capabilities and their footprints. That is, each capability has = an > >> > associated > >> > > > footprint. > >> > > > > >> > > > The draft defines the same basic set of capabilities as defined > >>in the > >> > > > requirements and provides some examples of their encoding. > >> > > > > >> > > > Each capability has a name, a list of values, and an optional > >>list of > >> > footprints. > >> > > > The list of values is specific to the capability name. > >> > > > > >> > > > The optional footprint list restricts its capability. Each > >>footprint > >> > has a type, > >> > > list > >> > > > of values, and an optional mode. The list of values is specific > >>to the > >> > > footprint > >> > > > type. A registry is defined for footprint types and includes > >>country > >> > code, AS > >> > > > number, and IP prefix. > >> > > > > >> > > > The footprint mode may be set to "replace", "include", or > >>"exclude" > >> > which > >> > > > indicates how the footprint should be treated with respect to > >> > "previous" > >> > > > footprint information. In this context, "previous" refers to > >> > incremental > >> > > > updates which are sent asynchronously from the dCDN to the uCDN. > >> The > >> > > > "replace" mode indicates that any previous information about the > >> > footprint > >> > > > should be discarded and replaced entirely with the new > >>information. > >> > The > >> > > > "include" mode indicates an addition to the footprint while > >>"exclude" > >> > > > indications a subtraction. > >> > > > > >> > > > The draft does not provide a means for conveying footprint cost > >> > > information. > >> > > > > >> > > > In practice, the dCDN FCI Server would return a full F&C documen= t > >>in > >> > > > response to HTTP GET requests. An HTTP GET would be used to > >>initialize > >> > > the > >> > > > state of the uCDN. In response to a GET, all modes are set to > >> > "replace". > >> > > > > >> > > > The proposal also allows the dCDN to send asynchronous HTTP > POSTs > >>to > >> > > > uCDN for updating the F&C. Updates may use "include" and > "exclude" > >> > > > modes for partial updates. Each update includes a sequence > numbers > >> > (via > >> > > an > >> > > > CDNI-FCI-seq HTTP header) in order to detect loss. Lost updates > >>result > >> > in a > >> > > > reset and a re-initialization. > >> > > > > >> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > > > Analysis > >> > > > ------------------------------------------------------------- > >> > > > > >> > > > Transport and Encoding: both proposals rely on HTTP transport an= d > >> JSON > >> > > > encoding. This is a good starting point and is in line with > >>current > >> > CDNI WG > >> > > > documents (e.g. triggers and metadata drafts). > >> > > > > >> > > > Data Representation: in the case of draft-seedorf, the existing > >>ALTO > >> > > > representations for network and property maps are leveraged. > These > >> > data > >> > > > structures clearly fit the CDNI use case and have the benefit of > >>prior > >> > > review. > >> > > > In the case of draft-ma, a new CDNI-specific representation is > >> > defined. > >> > > There > >> > > > is no clear technical deficiency with either approach given that= a > >> > newly > >> > > > defined representation can be as flexible as needed and the ALTO > >> > > > representation is generic enough to support the CDNI use case. > >> > Leveraging > >> > > > an existing protocol has obvious advantages but it is unclear to > >>me > >> > whether > >> > > > or not adding a dependency on the ALTO WG will be problematic in > >>any > >> > > way. > >> > > > > >> > > > Hierarchy: in the case of draft-seedorf, footprints have > >>capabilities. > >> > In the > >> > > > case of draft-ma, capabilities have footprints. In the single CD= N > >> > case, > >> > > neither > >> > > > option is deficient. In the cascaded CDN case, the draft-seedorf > >> > approach > >> > > > seems more intuitive. Aggregated footprint and capability > >>information > >> > is > >> > > > constructed simply by appending the footprints of all dCDNs. > >> > > > > >> > > > Cost Information: in the case of draft-seedorf, a loose > >>description is > >> > > provided > >> > > > of how to apply ALTO Cost Maps to footprints. In the case of > >>draft-ma, > >> > no > >> > > > solution is described. Cost information is only useful when > >>multiple > >> > dCDNs > >> > > > can claim the same end clients in their footprint advertisements= . > >> > However, > >> > > > regardless of the use case, business logic is likely to kick in > >>before > >> > such cost > >> > > > metrics would be useful. Neither approach includes a definitive > >> > proposal in > >> > > > this area. > >> > > > > >> > > > Extensibility and Versioning: Versioning of the FCI protocol is > >>not > >> > discussed > >> > > > by either draft. Extensibility is alluded to and is clearly > >>possible. > >> > However, > >> > > the > >> > > > details are lacking in this area. > >> > > > > >> > > > Dependence on ALTO WG: In the case of draft-seedorf, a > dependency > >> is > >> > > > introduced on the ALTO WG and a few drafts in progress. In the > >>case of > >> > > draft- > >> > > > ma, no such dependency is required. The benefits of leveraging > >>ALTO > >> > > include > >> > > > the ability to easily reuse the work that the ALTO WG has done i= n > >> > > hardening > >> > > > the error handling, security, encoding, and processing of the AL= TO > >> > protocol. > >> > > > However, the difficulty of these efforts is not insurmountable a= nd > >> > could be > >> > > > reproduced in a CDNI-specific proposal. > >> > > > > >> > > > Capability Inheritance: in the case of draft-seedorf, the PID > >>Property > >> > Map > >> > > > defines rules for implicit inheritance between multiple > >>overlapping > >> > PIDs. In > >> > > > the case of draft-ma, no special inheritance rules exist. These > >> > inheritance > >> > > > rules may complicate implementation of FCI. Completely explicit > >> > > capabilities, > >> > > > such as in draft-ma, may be a better approach. > >> > > > > >> > > > Update Notifications: in the case of draft-seedorf, no strong > >>story > >> > for > >> > > update > >> > > > notifications is provided. The ALTO Incremental Updates draft is > >> > > referenced. > >> > > > However, this draft is expired. In the case of draft-ma, an HTTP > >>POST > >> > may > >> > > be > >> > > > sent from dCDN to uCDN which includes the incremental update. > >> Assuming > >> > > > that update notifications is a real requirement, then draft-ma > >>has a > >> > more > >> > > > concrete approach in this area. However, a bidirectional HTTP > >> > interface > >> > > > breaks the RESTful nature of the interface. > >> > > > > >> > > > Incremental Updates: in the case of draft-seedorf, the ALTO > >> > Incremental > >> > > > Update draft is referenced. This draft describes the use of JSON > >>Patch > >> > for > >> > > > encoding incremental changes to ALTO information. Additionally, > >>ALTO > >> > > allows > >> > > > for filtered queries which could be used for obtaining partial > >> > information. In > >> > > > the case of draft-ma, a scheme including sequence numbers, a new > >> HTTP > >> > > > header, and a "mode" is used for conveying incremental changes v= ia > >> > HTTP > >> > > > POST. Like the update notifications, the draft-ma proposal is mo= re > >> > concrete > >> > > > in this area. However, again, the ALTO approach is more RESTful. > >> > > Additionally, > >> > > > adding a new HTTP header for this purpose may not be workable. > >> > > > > >> > > > Draft Maturity: both draft-seedorf and draft-ma require another > >>level > >> > of > >> > > > detail. Neither describe versioning and extensibility. Neither > >>discuss > >> > the > >> > > > encoding of logging and metadata capabilities which may pose > >> > significant > >> > > > challenges. > >> > > > > >> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > > > Conclusion > >> > > > ------------------------------------------------------------- > >> > > > All in all, both drafts are well-written and viable candidates a= s > >>a > >> > starting > >> > > point > >> > > > for our FCI standard. > >> > > > > >> > > > I would suggest that the working group must first decide whether > >>the > >> > > > benefits of reusing the ALTO syntax and semantics outweigh the > >>costs > >> > or if > >> > > > defining something CDNI-specific is a better option. As far as I > >>can > >> > tell, the > >> > > > data representation defined by ALTO meets the needs of CDNI. My > >> only > >> > > > concern is a dependency on the progress of the ALTO WG. Starting > >>with > >> > a > >> > > > CDNI-specific representation provides maximum flexibility. > >> > > > > >> > > > I would also recommend that we first focus on a simple HTTP GET > >> > interface > >> > > > and then, once stable, turn our attention to incremental updates= . > >> > > > > >> > > > Cheers, > >> > > > Matt > >> > > > > >> > > > > >> > > > _______________________________________________ > >> > > > 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 > >> > > >> > _______________________________________________ > >> > CDNi mailing list > >> > CDNi@ietf.org > >> > https://www.ietf.org/mailman/listinfo/cdni > > > >_______________________________________________ > >CDNi mailing list > >CDNi@ietf.org > >https://www.ietf.org/mailman/listinfo/cdni From nobody Mon Mar 3 03:07:04 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 939F61A0F13; Mon, 3 Mar 2014 03:07:00 -0800 (PST) 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 F2_eEDp5wWqT; Mon, 3 Mar 2014 03:06:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 647941A0E5A; Mon, 3 Mar 2014 03:06:57 -0800 (PST) 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.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140303110657.3368.11392.idtracker@ietfa.amsl.com> Date: Mon, 03 Mar 2014 03:06:57 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/vZFEBASYxOU7Xq1SvmD5OaY4IN0 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-framework-10.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: Mon, 03 Mar 2014 11:07:00 -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 : Framework for CDN Interconnection Authors : Larry Peterson Bruce Davie Ray van Brandenburg Filename : draft-ietf-cdni-framework-10.txt Pages : 54 Date : 2014-03-03 Abstract: This document presents a framework for Content Distribution Network Interconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs. CDN Interconnection requires the specification of interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs. The intent of this document is to outline what each interface needs to accomplish, and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. It obsoletes RFC 3466. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-framework/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-framework-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-framework-10 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 Mon Mar 3 03:25:00 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 ECA591A0F44 for ; Mon, 3 Mar 2014 03:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.047 X-Spam-Level: X-Spam-Status: No, score=-10.047 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.547, 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 ldpWQyKgU3RL for ; Mon, 3 Mar 2014 03:24:56 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDFD1A0F45 for ; Mon, 3 Mar 2014 03:24:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18041; q=dns/txt; s=iport; t=1393845893; x=1395055493; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EE5fmH57OP+PkPYul6VgjBGZ7fDZWZ61GaRF1O42LoI=; b=cEU0AyI7HI6W+tqexj5WhGVQcnhMl5nERGUGjrfh1pT4ahbnaBz9mOm4 xbS7S0XLDe4XPX5g/4q6Ctqnswj0SfFsUoEJjIbEx+2t0EW6qocG2GKPH oz4GWLZUUhaT9pd2t/x0YtTgFY9Wa3hBrCppndpjMLEFGFalXlrprip4Z 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAEdmFFOtJV2b/2dsb2JhbABagkJEO0sGBsBOgSAWdIIlAQEBBAEBASRHCwwEAgEIEQQBASgHJwsUCQgCBA4FCYdwCAXMOxeOVQQHBgODG4EUBJg8gTKLNIVFgy2CKg X-IronPort-AV: E=Sophos; i="4.97,577,1389744000"; d="scan'208,217"; a="24463228" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP; 03 Mar 2014 11:24:51 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s23BOpkD003736 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 3 Mar 2014 11:24:51 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.67]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Mon, 3 Mar 2014 05:24:51 -0600 From: "Francois Le Faucheur (flefauch)" To: "Matt Caulfield (mcaulfie)" Thread-Topic: Comments on draft-caulfield-cdni-rate-pacing-01.txt Thread-Index: AQHPK//VRagSHawbjEGTIHEYuqBOXQ== Date: Mon, 3 Mar 2014 11:24:51 +0000 Message-ID: References: <20140213183422.27184.59770.idtracker@ietfa.amsl.com> <166EBB70C264A9479E459B01B1BA6C924E0A7806@xmb-aln-x03.cisco.com> In-Reply-To: <166EBB70C264A9479E459B01B1BA6C924E0A7806@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] Content-Type: multipart/alternative; boundary="_000_D85B7C37BF314A9D8D42310816BF1425ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/rnUke73wIkgXKdPvTV8rIZtDpn0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Comments on draft-caulfield-cdni-rate-pacing-01.txt 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, 03 Mar 2014 11:24:59 -0000 --_000_D85B7C37BF314A9D8D42310816BF1425ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Matt, One more comment regarding section 4.1: =93 +----------------+---------------+---------+ | Algorithm Name | Specification | Version | +----------------+---------------+---------+ | token-bucket | RFCthis | 1 | +----------------+---------------+---------+ " I am not sure we want to have a full notion of =93Version=94 inside the Reg= istry (for example you=92d have to define a full notion of version handling= ). Instead I woudl suggest you simply have an algorithm name of =93token-bucke= t/v1=94. And if someone later defines a =93token-bucket/v2=94 it is simply = considered as another (unrelated) algorithm. Francois On 17 Feb 2014, at 17:50, Matt Caulfield (mcaulfie) > wrote: Thank you for the comments, Francois. I agree with your feedback below and will plan to incorporate it in the nex= t revision. Regards, Matt -----Original Message----- From: Francois Le Faucheur (flefauch) Sent: Monday, February 17, 2014 11:47 AM To: Matt Caulfield (mcaulfie) Cc: cdni@ietf.org Subject: Comments on draft-caulfield-cdni-rate-pacing-01.txt Hi Matt, (With my individual contributor's hat on) Comments below. HTH Francois *** section 2.1: " A CDN MAY advertise the "RatePacing" capability in the FCI if it implements this specification and at least one rate pacing algorithm registered in the Rate Pacing algorithms registry. " This suggests that we can end up in a situation where CDN1 advertises only = "token-bucket/v1" and CDN2 advertises only "rate-pacing-algorithm-bladibla"= . Should we not promote a situation where any CDN that supports rate-pacing s= upports at least one common rate-pacing algorithm (eg "token-bucket/v1")? I think this would make it a lot easier for an uCDN to define and market a = consistent service to a CSP. *** section 2.2.1: " For example, "token-bucket./v1" " should this read "token-bucket/v1" (without a dot)? *** section 2.3: What you are discussing here about dCDN selection based on "required" rate-= pacing is actually a generic concept (but simply applied here to rate-pacin= g). THis needs to be aligned to the discussions around FCI Manadatory/Optional = capabilities + cdni-metadata. In any case, I woudl suggest that you tweak your description to make it cle= ar that what you are describing is not specific to rate-pacing, but is just= describing how a generic concept applie sto rate-pacing. *** section 2.4 " Note that existing fields defined by [I-D.ietf-cdni-logging] include the bytes delivered and the time taken to service a request. However, the time taken includes the acquisition latency which is not relevant to rate pacing. " Given that the content items on which rate pacing is applied would be fairl= y large, I expect that the acquisition time would be typically negligible (= e.g. within a similar error margin as the difference between an "average ra= te" and the tocken bucket rate). But given this is an optional parameter, I don't have a problem in defining= it. *** section 2.4: OLD: " The "sc-rate" field indicates the rate in bytes per second as a decimal number. " NEW: " A new "sc-rate" CDNI Logging Field is defined to indicate the rate in bytes= per second as a decimal number. " *** section 2.4: OLD: " Note that existing fields defined by [I-D.ietf-cdni-logging] include the bytes delivered and the time taken to service a request. " NEW: " Note that existing fields defined by [I-D.ietf-cdni-logging] include the bytes delivered and the time taken to service a request, which could = be used to estimate the delivery rate. " *** section 3: "3. Rate Pacing Algorithm" Since this document specifies one particular algorithm, and since its param= eters are specified in this section, I'd suggest changing title to somethin= g like: "3. Tocken Bucket Rate Pacing Algorithm and Parameters". *** section 3: The first paragraph is a litlle confusing because "Tocken Bucket" sometimes= refers to the generic mechanisms and sometimes to how it is applied to CDN= I. I would recommend you distinguish the two: * the generic tolken bucket concept [RFC1363] * introduce a notion of "CDNI Tocken Bucket RAte Pacing" Then you can explian that : * this document specifies the "CDNI Tocken Bucket Rate Pacing" * it is based on the generic token bucket, but applied in a CDNI context (i= e by Surrogate when transmitting bytes of a response to a content * clarify which bytes are to be accounted for in the bucket (eg L1? L2? IP?= Transport? HTTP status response, HTTP headers,..) *** section 3: OLD: " If a RatePacing metadata object's "algo" value is "token-bucket/v1" then the metadata object's "params" is an object of type TokenBucketParams, described below. " NEW: " If a RatePacing metadata object's "algo" value is "token-bucket/v1" then the metadata object's "params" MUST be an object of type TokenBucketParams, described below. " *** Section 4.1: " New rate pacing algorithm registrations SHOULD specify RatePacing parameter objects as shown in Section 3.1 and SHOULD describe the algorithm for rate pacing. " Why is this SHOULD and not MUST? typos: "[I-D.ietf-cdni-footprint-capabilities-semantics]defines" -> "[I-D.ietf-cdn= i-footprint-capabilities-semantics] defines" "[I-D.ietf-cdni-footprint-capabilities-semantics]states" -> "[I-D.ietf-cdni= -footprint-capabilities-semantics] states" "IANA is requested to create new registry" -> "IANA is requested to create = a new registry" On 13 Feb 2014, at 19:34, Internet-Drafts@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : CDNI Rate Pacing Author : Matt Caulfield Filename : draft-caulfield-cdni-rate-pacing-01.txt Pages : 8 Date : 2014-02-13 Abstract: Rate pacing is a class of network traffic shaping which limits the transmission rate of data over a network. This document defines CDNI extensions for downstream CDNs to support rate pacing on behalf of upstream CDNs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-caulfield-cdni-rate-pacing/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-caulfield-cdni-rate-pacing-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-caulfield-cdni-rate-pacing-01 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --_000_D85B7C37BF314A9D8D42310816BF1425ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9D59F5D58C63FC469C1D3848C3BF5F0F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hi Matt,

One more comment regarding section 4.1:
=93
               +----------------+---------------+=
---------+
               | Algorithm Name | Specification | Version |
               +----------------+---------------+---------+
               | token-bucket   | RFCthis       | 1       |
               +----------------+---------------+---------+

"
I am not sure we want to have a full notion of =93Version=94 inside th= e Registry (for example you=92d have to define a full notion of version han= dling).
Instead I woudl suggest you simply have an algorithm name of =93token-= bucket/v1=94. And if someone later defines a =93token-bucket/v2=94 it is si= mply considered as another (unrelated) algorithm.

Francois 


On 17 Feb 2014, at 17:50, Matt Caulfield (mcaulfie) <mcaulfie@cisco.com> wrote:

Thank you for the comments, Francois.

I agree with your feedback below and will plan to incorporate it in the nex= t revision.

Regards,
Matt

-----Original Message-----
From: Francois Le Faucheur (flefauch)
Sent: Monday, February 17, 2014 11:47 AM
To: Matt Caulfield (mcaulfie)
Cc: cdni@ietf.org
Subject: Comments on draft-caulfield-cdni-rate-pacing-01.txt

Hi Matt,

(With my individual contributor's hat on)

Comments below.

HTH

Francois



*** section 2.1:
"
A CDN MAY advertise the "RatePacing" capability in the FCI if it<= br>   implements this specification and at least one rate pacing algo= rithm
  registered in the Rate Pacing algorithms registry.
"
This suggests that we can end up in a situation where CDN1 advertises only = "token-bucket/v1" and CDN2 advertises only "rate-pacing-algo= rithm-bladibla".
Should we not promote a situation where any CDN that supports rate-pacing s= upports at least one common rate-pacing algorithm (eg "token-bucket/v1= ")?
I think this would make it a lot easier for an uCDN to define and market a = consistent service to a CSP.


*** section 2.2.1:
"
For example, "token-bucket./v1"
"
should this read "token-bucket/v1" (without a dot)?


*** section 2.3:
What you are discussing here about dCDN selection based on "required&q= uot; rate-pacing is actually a generic concept (but simply applied here to = rate-pacing).
THis needs to be aligned to the discussions around FCI Manadatory/Optional = capabilities + cdni-metadata.
In any case, I woudl suggest that you tweak your description to make it cle= ar that what you are describing is not specific to rate-pacing, but is just= describing how a generic concept applie sto rate-pacing.



*** section 2.4
"
Note that existing fields defined by [I-D.ietf-cdni-logging] include
  the bytes delivered and the time taken to service a request.   However, the time taken includes the acquisition latency which = is not
  relevant to rate pacing.
"
Given that the content items on which rate pacing is applied would be fairl= y large, I expect that the acquisition time would be typically negligible (= e.g. within a similar error margin as the difference between an "avera= ge rate" and the tocken bucket rate).
But given this is an optional parameter, I don't have a problem in defining= it.


*** section 2.4:
OLD:
"
The "sc-rate" field indicates the rate in bytes per
  second as a decimal number.
"
NEW:
"
A new "sc-rate" CDNI Logging Field is defined to indicate the rat= e in bytes per
  second as a decimal number.
"


*** section 2.4:
OLD:
"
Note that existing fields defined by [I-D.ietf-cdni-logging] include
  the bytes delivered and the time taken to service a request. "
NEW:
"
Note that existing fields defined by [I-D.ietf-cdni-logging] include
  the bytes delivered and the time taken to service a request, wh= ich could be used to estimate the delivery rate.
"



*** section 3:
"3.  Rate Pacing Algorithm"
Since this document specifies one particular algorithm, and since its param= eters are specified in this section, I'd suggest changing title to somethin= g like:
"3. Tocken Bucket Rate Pacing Algorithm and Parameters".



*** section 3:
The first paragraph is a litlle confusing because "Tocken Bucket"= sometimes refers to the generic mechanisms and sometimes to how it is appl= ied to CDNI.
I would recommend you distinguish the two:
* the gener= ic tolken bucket concept [RFC1363]
* introduce= a notion of "CDNI Tocken Bucket RAte Pacing"
Then you can explian that :
* this docu= ment specifies the "CDNI Tocken Bucket Rate Pacing"
* it is bas= ed on the generic token bucket, but applied in a CDNI context (ie by Surrog= ate when transmitting bytes of a response to a content
* clarify w= hich bytes are to be accounted for in the bucket (eg L1? L2? IP? Transport?= HTTP status response, HTTP headers,..)


*** section 3:
OLD:
"
If a RatePacing metadata object's "algo" value is "token-buc= ket/v1"
  then the metadata object's "params" is an object of t= ype
  TokenBucketParams, described below.
"
NEW:
"
If a RatePacing metadata object's "algo" value is "token-buc= ket/v1"
  then the metadata object's "params" MUST be an object= of type
  TokenBucketParams, described below.
"

*** Section 4.1:
"
New rate pacing algorithm registrations SHOULD specify RatePacing
  parameter objects as shown in Section 3.1 and SHOULD describe t= he
  algorithm for rate pacing.
"
Why is this SHOULD and not MUST?



typos:

"[I-D.ietf-cdni-footprint-capabilities-semantics]defines" -> &= quot;[I-D.ietf-cdni-footprint-capabilities-semantics] defines"

"[I-D.ietf-cdni-footprint-capabilities-semantics]states" -> &q= uot;[I-D.ietf-cdni-footprint-capabilities-semantics] states"

"IANA is requested to create new registry" -> "IANA is re= quested to create a new registry"

On 13 Feb 2014, at 19:34, Inter= net-Drafts@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


      Title      &nb= sp;    : CDNI Rate Pacing
      Author      &n= bsp;   : Matt Caulfield
Filename &n= bsp;      : draft-caulfield-cdni-rate-pacing-= 01.txt
Pages  = ;         : 8
Date  =           : 2014-02-13
Abstract:
 Rate pacing is a class of network traffic shaping which limits the  transmission rate of data over a network.  This document defines= CDNI
 extensions for downstream CDNs to support rate pacing on behalf of  upstream CDNs.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-caulfield-cdni-rate-pacing/<= br>
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-caulfield-cdni-rate-pacing-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-caulfield-cdni-rate-pacing-01


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/

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


--_000_D85B7C37BF314A9D8D42310816BF1425ciscocom_-- From nobody Mon Mar 3 06:23:19 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 CBC011A017E for ; Mon, 3 Mar 2014 06:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 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, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 Iy7KhkzJfs4c for ; Mon, 3 Mar 2014 06:23:12 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE1B1A0132 for ; Mon, 3 Mar 2014 06:23:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24796; q=dns/txt; s=iport; t=1393856590; x=1395066190; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xqXkWAQNiaXC5Vx4xhBVWk6kGyRag4qIhiNkMDU0xI4=; b=X5Xyw9ZYkG//z/JcK4lFXuVVwaBUgdJNgcCzCIcIrJ+MAFGES/IpJWC0 Y2MJXslwD/7Hkrjf7rDxvtuNiYDjrBV9/RTol65QHoFGf5RiiKfGXClxZ AqPCo51HOgY9LAjJgJyg52yPJN2ONezwXXSKlu6+OgDS1B0y0aNUBSU7y E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgHAN6PFFOtJV2Z/2dsb2JhbABagkREOEkGBrNjiFOBIhYBdIN9AQEBBAEBASQGQQsMBAIBCBEEAQELFgcHJwsUCQgCBA4FCAGHewgFxCgXjmEtBAYBBgODGoETBJlGiy2FN4Mrgio X-IronPort-AV: E=Sophos;i="4.97,863,1389744000"; d="scan'208,217";a="304625256" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 03 Mar 2014 14:23:09 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s23EN8pd027647 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 3 Mar 2014 14:23:08 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.138]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Mon, 3 Mar 2014 08:23:08 -0600 From: "Matt Caulfield (mcaulfie)" To: "Francois Le Faucheur (flefauch)" Thread-Topic: Comments on draft-caulfield-cdni-rate-pacing-01.txt Thread-Index: AQHPK//VRagSHawbjEGTIHEYuqBOXZq5qHGwgBYKh4D//8z14A== Date: Mon, 3 Mar 2014 14:23:07 +0000 Message-ID: <166EBB70C264A9479E459B01B1BA6C924E0D5E6D@xmb-aln-x03.cisco.com> References: <20140213183422.27184.59770.idtracker@ietfa.amsl.com> <166EBB70C264A9479E459B01B1BA6C924E0A7806@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.69.105] Content-Type: multipart/alternative; boundary="_000_166EBB70C264A9479E459B01B1BA6C924E0D5E6Dxmbalnx03ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/FXkEGu53vV7Nt4z9maK-QJS-8cI Cc: "cdni@ietf.org" Subject: Re: [CDNi] Comments on draft-caulfield-cdni-rate-pacing-01.txt 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, 03 Mar 2014 14:23:17 -0000 --_000_166EBB70C264A9479E459B01B1BA6C924E0D5E6Dxmbalnx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Francois, Yes, I tend to agree. A flat name space (with no version) would be easier t= o manage. I will incorporate this (and your other comments) in my next revi= sion. Thank you, Matt From: Francois Le Faucheur (flefauch) Sent: Monday, March 03, 2014 6:25 AM To: Matt Caulfield (mcaulfie) Cc: Francois Le Faucheur (flefauch); cdni@ietf.org Subject: Re: Comments on draft-caulfield-cdni-rate-pacing-01.txt Hi Matt, One more comment regarding section 4.1: " +----------------+---------------+---------+ | Algorithm Name | Specification | Version | +----------------+---------------+---------+ | token-bucket | RFCthis | 1 | +----------------+---------------+---------+ " I am not sure we want to have a full notion of "Version" inside the Registr= y (for example you'd have to define a full notion of version handling). Instead I woudl suggest you simply have an algorithm name of "token-bucket/= v1". And if someone later defines a "token-bucket/v2" it is simply consider= ed as another (unrelated) algorithm. Francois On 17 Feb 2014, at 17:50, Matt Caulfield (mcaulfie) > wrote: Thank you for the comments, Francois. I agree with your feedback below and will plan to incorporate it in the nex= t revision. Regards, Matt -----Original Message----- From: Francois Le Faucheur (flefauch) Sent: Monday, February 17, 2014 11:47 AM To: Matt Caulfield (mcaulfie) Cc: cdni@ietf.org Subject: Comments on draft-caulfield-cdni-rate-pacing-01.txt Hi Matt, (With my individual contributor's hat on) Comments below. HTH Francois *** section 2.1: " A CDN MAY advertise the "RatePacing" capability in the FCI if it implements this specification and at least one rate pacing algorithm registered in the Rate Pacing algorithms registry. " This suggests that we can end up in a situation where CDN1 advertises only = "token-bucket/v1" and CDN2 advertises only "rate-pacing-algorithm-bladibla"= . Should we not promote a situation where any CDN that supports rate-pacing s= upports at least one common rate-pacing algorithm (eg "token-bucket/v1")? I think this would make it a lot easier for an uCDN to define and market a = consistent service to a CSP. *** section 2.2.1: " For example, "token-bucket./v1" " should this read "token-bucket/v1" (without a dot)? *** section 2.3: What you are discussing here about dCDN selection based on "required" rate-= pacing is actually a generic concept (but simply applied here to rate-pacin= g). THis needs to be aligned to the discussions around FCI Manadatory/Optional = capabilities + cdni-metadata. In any case, I woudl suggest that you tweak your description to make it cle= ar that what you are describing is not specific to rate-pacing, but is just= describing how a generic concept applie sto rate-pacing. *** section 2.4 " Note that existing fields defined by [I-D.ietf-cdni-logging] include the bytes delivered and the time taken to service a request. However, the time taken includes the acquisition latency which is not relevant to rate pacing. " Given that the content items on which rate pacing is applied would be fairl= y large, I expect that the acquisition time would be typically negligible (= e.g. within a similar error margin as the difference between an "average ra= te" and the tocken bucket rate). But given this is an optional parameter, I don't have a problem in defining= it. *** section 2.4: OLD: " The "sc-rate" field indicates the rate in bytes per second as a decimal number. " NEW: " A new "sc-rate" CDNI Logging Field is defined to indicate the rate in bytes= per second as a decimal number. " *** section 2.4: OLD: " Note that existing fields defined by [I-D.ietf-cdni-logging] include the bytes delivered and the time taken to service a request. " NEW: " Note that existing fields defined by [I-D.ietf-cdni-logging] include the bytes delivered and the time taken to service a request, which could = be used to estimate the delivery rate. " *** section 3: "3. Rate Pacing Algorithm" Since this document specifies one particular algorithm, and since its param= eters are specified in this section, I'd suggest changing title to somethin= g like: "3. Tocken Bucket Rate Pacing Algorithm and Parameters". *** section 3: The first paragraph is a litlle confusing because "Tocken Bucket" sometimes= refers to the generic mechanisms and sometimes to how it is applied to CDN= I. I would recommend you distinguish the two: * the generic tolken bucket concept [RFC1363] * introduce a notion of "CDNI Tocken Bucket RAte Pacing" Then you can explian that : * this document specifies the "CDNI Tocken Bucket Rate Pacing" * it is based on the generic token bucket, but applied in a CDN= I context (ie by Surrogate when transmitting bytes of a response to a conte= nt * clarify which bytes are to be accounted for in the bucket (eg= L1? L2? IP? Transport? HTTP status response, HTTP headers,..) *** section 3: OLD: " If a RatePacing metadata object's "algo" value is "token-bucket/v1" then the metadata object's "params" is an object of type TokenBucketParams, described below. " NEW: " If a RatePacing metadata object's "algo" value is "token-bucket/v1" then the metadata object's "params" MUST be an object of type TokenBucketParams, described below. " *** Section 4.1: " New rate pacing algorithm registrations SHOULD specify RatePacing parameter objects as shown in Section 3.1 and SHOULD describe the algorithm for rate pacing. " Why is this SHOULD and not MUST? typos: "[I-D.ietf-cdni-footprint-capabilities-semantics]defines" -> "[I-D.ietf-cdn= i-footprint-capabilities-semantics] defines" "[I-D.ietf-cdni-footprint-capabilities-semantics]states" -> "[I-D.ietf-cdni= -footprint-capabilities-semantics] states" "IANA is requested to create new registry" -> "IANA is requested to create = a new registry" On 13 Feb 2014, at 19:34, Internet-Drafts@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : CDNI Rate Pacing Author : Matt Caulfield Filename : draft-caulfield-cdni-rate-pacing-01.txt Pages : 8 Date : 2014-02-13 Abstract: Rate pacing is a class of network traffic shaping which limits the transmission rate of data over a network. This document defines CDNI extensions for downstream CDNs to support rate pacing on behalf of upstream CDNs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-caulfield-cdni-rate-pacing/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-caulfield-cdni-rate-pacing-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-caulfield-cdni-rate-pacing-01 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --_000_166EBB70C264A9479E459B01B1BA6C924E0D5E6Dxmbalnx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Francois,

 

Yes, I tend to agree. A fla= t name space (with no version) would be easier to manage. I will incorporat= e this (and your other comments) in my next revision.

 

Thank you,

Matt

 

From: Francois= Le Faucheur (flefauch)
Sent: Monday, March 03, 2014 6:25 AM
To: Matt Caulfield (mcaulfie)
Cc: Francois Le Faucheur (flefauch); cdni@ietf.org
Subject: Re: Comments on draft-caulfield-cdni-rate-pacing-01.txt

 

Hi Matt,

 

One more comment regarding section 4.1:

“

       =
;        +----------------+-----=
----------+---------+
       =
;        | Algorithm Name | Specificatio=
n | Version |
       =
;        +----------------+-----=
----------+---------+
       =
;        | token-bucket   | RF=
Cthis       | 1     =
  |
       =
;        +----------------+-----=
----------+---------+

 

"

I am not sure we want to have a full notion of ̶= 0;Version” inside the Registry (for example you’d have to defin= e a full notion of version handling).

Instead I woudl suggest you simply have an algorithm= name of “token-bucket/v1”. And if someone later defines a R= 20;token-bucket/v2” it is simply considered as another (unrelated) al= gorithm.

 

Francois 

 

 

On 17 Feb 2014, at 17:50, Matt Caulfield (mcaulfie) = <mcaulfie@cisco.com> wrote:=



Thank you for the comments, Francois.

I agree with your feedback below and will plan to incorporate it in the nex= t revision.

Regards,
Matt

-----Original Message-----
From: Francois Le Faucheur (flefauch)
Sent: Monday, February 17, 2014 11:47 AM
To: Matt Caulfield (mcaulfie)
Cc: cdni@ietf.org
Subject: Comments on draft-caulfield-cdni-rate-pacing-01.txt

Hi Matt,

(With my individual contributor's hat on)

Comments below.

HTH

Francois



*** section 2.1:
"
A CDN MAY advertise the "RatePacing" capability in the FCI if it<= br>   implements this specification and at least one rate pacing algo= rithm
  registered in the Rate Pacing algorithms registry.
"
This suggests that we can end up in a situation where CDN1 advertises only = "token-bucket/v1" and CDN2 advertises only "rate-pacing-algo= rithm-bladibla".
Should we not promote a situation where any CDN that supports rate-pacing s= upports at least one common rate-pacing algorithm (eg "token-bucket/v1= ")?
I think this would make it a lot easier for an uCDN to define and market a = consistent service to a CSP.


*** section 2.2.1:
"
For example, "token-bucket./v1"
"
should this read "token-bucket/v1" (without a dot)?


*** section 2.3:
What you are discussing here about dCDN selection based on "required&q= uot; rate-pacing is actually a generic concept (but simply applied here to = rate-pacing).
THis needs to be aligned to the discussions around FCI Manadatory/Optional = capabilities + cdni-metadata.
In any case, I woudl suggest that you tweak your description to make it cle= ar that what you are describing is not specific to rate-pacing, but is just= describing how a generic concept applie sto rate-pacing.



*** section 2.4
"
Note that existing fields defined by [I-D.ietf-cdni-logging] include
  the bytes delivered and the time taken to service a request.   However, the time taken includes the acquisition latency which = is not
  relevant to rate pacing.
"
Given that the content items on which rate pacing is applied would be fairl= y large, I expect that the acquisition time would be typically negligible (= e.g. within a similar error margin as the difference between an "avera= ge rate" and the tocken bucket rate).
But given this is an optional parameter, I don't have a problem in defining= it.


*** section 2.4:
OLD:
"
The "sc-rate" field indicates the rate in bytes per
  second as a decimal number.
"
NEW:
"
A new "sc-rate" CDNI Logging Field is defined to indicate the rat= e in bytes per
  second as a decimal number.
"


*** section 2.4:
OLD:
"
Note that existing fields defined by [I-D.ietf-cdni-logging] include
  the bytes delivered and the time taken to service a request. "
NEW:
"
Note that existing fields defined by [I-D.ietf-cdni-logging] include
  the bytes delivered and the time taken to service a request, wh= ich could be used to estimate the delivery rate.
"



*** section 3:
"3.  Rate Pacing Algorithm"
Since this document specifies one particular algorithm, and since its param= eters are specified in this section, I'd suggest changing title to somethin= g like:
"3. Tocken Bucket Rate Pacing Algorithm and Parameters".



*** section 3:
The first paragraph is a litlle confusing because "Tocken Bucket"= sometimes refers to the generic mechanisms and sometimes to how it is appl= ied to CDNI.
I would recommend you distinguish the two:
       &n= bsp;    * the generic tolken bucket concept [RFC1363]=
       &n= bsp;    * introduce a notion of "CDNI Tocken Buc= ket RAte Pacing"
Then you can explian that :
       &n= bsp;    * this document specifies the "CDNI Tock= en Bucket Rate Pacing"
       &n= bsp;    * it is based on the generic token bucket, bu= t applied in a CDNI context (ie by Surrogate when transmitting bytes of a r= esponse to a content
       &n= bsp;    * clarify which bytes are to be accounted for= in the bucket (eg L1? L2? IP? Transport? HTTP status response, HTTP header= s,..)


*** section 3:
OLD:
"
If a RatePacing metadata object's "algo" value is "token-buc= ket/v1"
  then the metadata object's "params" is an object of t= ype
  TokenBucketParams, described below.
"
NEW:
"
If a RatePacing metadata object's "algo" value is "token-buc= ket/v1"
  then the metadata object's "params" MUST be an object= of type
  TokenBucketParams, described below.
"

*** Section 4.1:
"
New rate pacing algorithm registrations SHOULD specify RatePacing
  parameter objects as shown in Section 3.1 and SHOULD describe t= he
  algorithm for rate pacing.
"
Why is this SHOULD and not MUST?



typos:

"[I-D.ietf-cdni-footprint-capabilities-semantics]defines" -> &= quot;[I-D.ietf-cdni-footprint-capabilities-semantics] defines"

"[I-D.ietf-cdni-footprint-capabilities-semantics]states" -> &q= uot;[I-D.ietf-cdni-footprint-capabilities-semantics] states"

"IANA is requested to create new registry" -> "IANA is re= quested to create a new registry"

On 13 Feb 2014, at 19:34, Inter= net-Drafts@ietf.org wrote:



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


      Title      &nb= sp;    : CDNI Rate Pacing
      Author      &n= bsp;   : Matt Caulfield
       &n= bsp;    Filename       =  : draft-caulfield-cdni-rate-pacing-01.txt
       &n= bsp;    Pages       &nb= sp;   : 8
       &n= bsp;    Date       &nbs= p;    : 2014-02-13

Abstract:
 Rate pacing is a class of network traffic shaping which limits the  transmission rate of data over a network.  This document defines= CDNI
 extensions for downstream CDNs to support rate pacing on behalf of  upstream CDNs.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-caulfield-cdni-rate-pacing/<= br>
There's also a htmlized version available at:
= http://tools.ietf.org/html/draft-caulfield-cdni-rate-pacing-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-caulfield-cdni-rate-pacing= -01


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/

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

 

 

--_000_166EBB70C264A9479E459B01B1BA6C924E0D5E6Dxmbalnx03ciscoc_-- From nobody Mon Mar 3 07:33:38 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 395301A01EA; Mon, 3 Mar 2014 07:33:33 -0800 (PST) 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 bG7oG_8SBLd7; Mon, 3 Mar 2014 07:33:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C306C1A01CB; Mon, 3 Mar 2014 07:33:24 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140303153324.17255.11212.idtracker@ietfa.amsl.com> Date: Mon, 03 Mar 2014 07:33:24 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/mhO0YYOXfi3xryC8XzSyq9Safxc Cc: cdni@ietf.org Subject: [CDNi] Last Call: (Framework for CDN Interconnection) to Informational RFC X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org 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, 03 Mar 2014 15:33:33 -0000 The IESG has received a request from the Content Delivery Networks Interconnection WG (cdni) to consider the following document: - 'Framework for CDN Interconnection' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-03-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting.L This is a three-week IETF Last Call because it's starting during IETF week. We want to give people a chance to read it and talk about issues this week, while still giving two full weeks for people to review while not at an IETF meeting. Abstract This document presents a framework for Content Distribution Network Interconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs. CDN Interconnection requires the specification of interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs. The intent of this document is to outline what each interface needs to accomplish, and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. It obsoletes RFC 3466. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-cdni-framework/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-cdni-framework/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Mar 3 07:37:01 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 6D2271A01E8 for ; Mon, 3 Mar 2014 07:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 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, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 1zsJIIUPsLl2 for ; Mon, 3 Mar 2014 07:36:58 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0451F1A01ED for ; Mon, 3 Mar 2014 07:36:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6867; q=dns/txt; s=iport; t=1393861015; x=1395070615; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ht9vjyLlrGLi4FVSwHk7Bk0ws7OF2SgU76oUnZuzwQs=; b=WRRwr9H2UXPCBPQPfHEsx3pW8nYKBw3OJ5KCzMwY1m0NBCAXiyHLVKgG JqXFyMAjqNnmsnR5ffvvMDpqDkvq70RS34WU86wk3gz/2KSmRXgCStwPZ T0BXCphlWBslE2DlVeq1/WxwMTLXp7+zxe0UTficG95u+rEvhZypL6+GO 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAOCgFFOtJXG9/2dsb2JhbABagwY7V8BQgSIWdIIlAQEBBC0+DgwEAgEIEQQBAQEnBzIUCQgCBA4FG4dezDUXjlkGAQYDgxuBFASMaYtTh0aKZYMtgio X-IronPort-AV: E=Sophos;i="4.97,578,1389744000"; d="scan'208,217";a="307711206" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 03 Mar 2014 15:36:55 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s23FasUi003010 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Mar 2014 15:36:54 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.67]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Mon, 3 Mar 2014 09:36:54 -0600 From: "Francois Le Faucheur (flefauch)" To: "Peterson, Jon" Thread-Topic: IANA instructions Re: [CDNi] I-D Action: draft-ietf-cdni-logging-09.txt Thread-Index: AQHPNvZnVqcc6SD/x0aVebpCe7+a1A== Date: Mon, 3 Mar 2014 15:36:53 +0000 Message-ID: <1E9698DB-9394-4A0B-80F6-8876D1A5A519@cisco.com> References: <596979554D802045BBD45C051A4399E40D441952@STNTEXMB10.cis.neustar.com> In-Reply-To: <596979554D802045BBD45C051A4399E40D441952@STNTEXMB10.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.29] Content-Type: multipart/alternative; boundary="_000_1E9698DB93944A0B80F68876D1A5A519ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/aCJWQO62y8XtXE6lQipgHq4eN3U Cc: "cdni@ietf.org" Subject: Re: [CDNi] IANA instructions Re: I-D Action: draft-ietf-cdni-logging-09.txt 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, 03 Mar 2014 15:37:00 -0000 --_000_1E9698DB93944A0B80F68876D1A5A519ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Got you. The RFC2119 normative language has been removed from the "working version= =94. Thanks Francois On 28 Feb 2014, at 14:43, Peterson, Jon > wrote: No, I recommended removing the normative language because RFC2119 language = is not applicable to IANA Considerations. Strictly speaking, RFC2119 normat= ive primitives are intended to constrain implementation behavior, for confo= rmance testing, and not to shape internal IETF process. We sometimes see no= rmative language in requirements for future specifications (e.g., "the even= tual solution SHOULD support anycast") but even this is a bit dodgy. Now that much said, I doubt IANA would be confused by MUST statements, but = I would still recommend changing the language in the logging draft to lower= case terms rather than 2119 primitives, and avoiding anything that looks l= ike a MAY or SHOULD. If you want to enforce constraints on parameter regist= rations, you need to set a policy other than "Spec Required", probably "Exp= ert Review" by someone who understands the constraints. We can't expect IAN= A to understand when conditions like those in the last paragraph of 5.3 are= met. Jon Peterson Neustar, Inc. Sent with Good (www.good.com) -----Original Message----- From: Francois Le Faucheur (flefauch) [flefauch@cisco.com] Sent: Thursday, February 20, 2014 08:51 AM Eastern Standard Time To: Peterson, Jon Cc: Francois Le Faucheur (flefauch); cdni@ietf.org; K= evin J Ma Subject: IANA instructions Re: [CDNi] I-D Action: draft-ietf-cdni-logging-0= 9.txt Hi Jon, In his review comments on cdni-logging, Kevin said: On 19 Feb 2014, at 02:00, Kevin J Ma > wrote: > > section 5.x: Jon had a comment on the FCI semantics draft to remove > normative language from IANA instructions (which we also > applied to the MI draft). We probably want to do the > same here? > Was the reason for which you recommended that the FCI semantics I-D removes= normative language from IANA instructions the fact that FCI semantics is g= oing for Informational Track? If yes, then that would not apply to cdni-logging. If no, can you describe the reason and whether/how you see that impacting (= or not) cdni-logging, given the current IANA section wording? Thanks Francois --_000_1E9698DB93944A0B80F68876D1A5A519ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Got you.

The RFC2119 normative language has been removed from the "working= version=94.

Thanks

Francois

On 28 Feb 2014, at 14:43, Peterson, Jon <jon.peterson@neustar.biz> wrote:

IANA instructions Re: [CDNi] I-D Action: draft-ietf-cdni-logging-09.= txt
No, I recommended removing the normative language because RFC2119 lang= uage is not applicable to IANA Considerations. Strictly speaking, RFC2119 n= ormative primitives are intended to constrain implementation behavior, for = conformance testing, and not to shape internal IETF process. We sometimes see normative language in requir= ements for future specifications (e.g., "the eventual solution SHOULD = support anycast") but even this is a bit dodgy.

Now that much said, I doubt IANA would be confused by MUST statements, but = I would still recommend changing the language in the logging draft to lower= case terms rather than 2119 primitives, and avoiding anything that looks l= ike a MAY or SHOULD. If you want to enforce constraints on parameter registrations, you need to set a polic= y other than "Spec Required", probably "Expert Review" = by someone who understands the constraints. We can't expect IANA to underst= and when conditions like those in the last paragraph of 5.3 are met.

Jon Peterson
Neustar, Inc.



Sent with Good (www.good.com)


-----Original Message-----
From: Francois Le Faucheur (flefauch) [flefauch@cisco.com]
Sent: Thursday, February 20, 2014 08:51 AM Eastern Standard Tim= e
To: Peterson, Jon
Cc: Francois Le Faucheur (flefauch); cdni@ietf.org; Kevin J Ma
Subject: IANA instructions Re: [CDNi] I-D Action: draft-ietf-cd= ni-logging-09.txt

Hi Jon,

In his review comments on cdni-logging, Kevin said:

On 19 Feb 2014, at 02:00, Kevin J Ma <kevin.ma@azukisystems.com> wrote:
>
> section 5.x: Jon had a comment on the FCI semantics draft to remove >            = ; normative language from IANA instructions (which we also
>            = ; applied to the MI draft).  We probably want to do the
>            = ; same here?
>

Was the reason for which you recommended that the FCI semantics I-D removes= normative language from IANA instructions the fact that FCI semantics is g= oing for Informational Track?
If yes, then that would not apply to cdni-logging.
If no, can you describe the reason and whether/how you see that impacting (= or not) cdni-logging, given the current IANA section wording?

Thanks

Francois


--_000_1E9698DB93944A0B80F68876D1A5A519ciscocom_-- From nobody Mon Mar 3 07:58:51 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 9473F1A0237; Mon, 3 Mar 2014 07:58:49 -0800 (PST) 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 qkiPyjGFM5fP; Mon, 3 Mar 2014 07:58:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B291A00BE; Mon, 3 Mar 2014 07:58:47 -0800 (PST) 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.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140303155847.1445.8716.idtracker@ietfa.amsl.com> Date: Mon, 03 Mar 2014 07:58:47 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/W5zw6YvLXSpASu0XWksXgMGoCL8 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-logging-10.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: Mon, 03 Mar 2014 15:58:49 -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 : CDNI Logging Interface Authors : Francois Le Faucheur Gilles Bertrand Iuniana Oprescu Roy Peterkofsky Filename : draft-ietf-cdni-logging-10.txt Pages : 45 Date : 2014-03-03 Abstract: This memo specifies the Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework. First, it describes a reference model for CDNI logging. Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-logging-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-logging-10 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 Tue Mar 4 03:09:36 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 E71901A029F for ; Tue, 4 Mar 2014 03:09:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.547] 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 7MESGM1dmNoy for ; Tue, 4 Mar 2014 03:09:32 -0800 (PST) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 962F41A02F9 for ; Tue, 4 Mar 2014 03:09:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.97,584,1389740400"; d="scan'208";a="3535433" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 04 Mar 2014 12:09:27 +0100 Received: from EXC-MBX03.tsn.tno.nl ([fe80::e969:1300:fb9f:7e12]) by EXC-CASHUB03.tsn.tno.nl ([fe80::6d39:f277:173e:a926%13]) with mapi id 14.03.0123.003; Tue, 4 Mar 2014 12:09:26 +0100 From: "Brandenburg, R. (Ray) van" To: S Moonesamy , "draft-ietf-cdni-framework.all@tools.ietf.org" Thread-Topic: Last Call: (Framework for CDN Interconnection) to Informational RFC Thread-Index: AQHPN3lUADvHWfNS1EyGygb+oPelM5rQtKqA Date: Tue, 4 Mar 2014 11:09:25 +0000 Message-ID: In-Reply-To: <6.2.5.6.2.20140303205434.0c2752a8@resistor.net> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [134.221.225.153] Content-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/n1Gofo1hJqOeNeSC517T1oQQOV8 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Last Call: (Framework for CDN Interconnection) to Informational RFC 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, 04 Mar 2014 11:09:35 -0000 Hi S., Thanks for you comments. Please see my responses inline. Best regards, Ray On 04/03/14 06:00, "S Moonesamy" wrote: >At 07:33 03-03-2014, The IESG wrote: > >>The IESG has received a request from the Content Delivery Networks >>Interconnection WG (cdni) to consider the following document: >>- 'Framework for CDN Interconnection' >> as Informational RFC >> >>The IESG plans to make a decision in the next few weeks, and solicits >>final comments on this action. Please send substantive comments to the > >I took a quick look at the draft. > >Section 2.1.1 discusses about "DNS Redirection". I don't think that >it fits as redirection as used within a DNS context. There is an >assumption that the recursive resolver is local. The term "DNS >server" is ambiguous. I think it=B9s important that note that the terminology in this document, and other CDNI documents, aligns with terminology as found in the CDN space, some of which may conflict with terminology as used in some other IETF WGs. A large share of (global) CDNs are currently using DNS to effectively =8Credirect=B9 end users to one of their servers, hence the term DNS Redirection. I appreciate that such terminology would have another meaning when uttered in e.g. a DNS WG. Ideally, it would be best to line up our terminology, however, at this point, I would rather make sure the terminology in this document lines up with other CDNI documents such as RFC6707 and 6770. = > > "DNS responses are cached by downstream servers so the TTL on the > response must be set to an appropriate value so as to preserve the > fresheness of the redirection." > >These (DNS) servers are not downstream servers. Are you saying that you would rather use a different term for such =8Cdownstream=B9 DNS servers? Do you have a suggestion? > >Section 2.1.2 does not provide a good discussion about why HTTP >redirection is not the preferred choice. The draft mentions that the >disadvantage of HTTP redirection is that it requires application >support. All web browsers support HTTP redirection. There are >disadvantages to using DNS to serve content. There is an assumption >that a user with an IP address in, for example, Japan will understand >localized content for that country. I see your point. I agree that the way it is written right now, the discussion might seem a bit lopsided, especially since the section on DNS Redirection does not list disadvantages. I will add those. In general, I would like to add that for the purposes of the CDNI Framework document, we are not in a position where we would like to advise for or against either HTTP or DNS as a redirection mechanism, the only thing that is important is that the CDNI interfaces allow for CDNs that use either of the two mechanisms to successfully interconnect. > >In Section 3.2: > > "2. A Request Router for Operator A processes the HTTP request and > recognizes that the end-user is best served by another CDN," > >Routers do not process HTTP requests. Again, I think this a matter of terminology. A Request Router in a CDN is not a router in the =8CIP-router=B9 sense, but an application level device which performs (HTTP) 302 redirects in order to load balance between multiple (HTTP) servers and/or CDNs. > >In Section 3.4: > > "One approach to ensuring that the client's IP address > prefix is correctly determined in such situations is described in > [I-D.vandergaast-edns-client-subnet]" > >That Internet-Draft was discussed previously. There are privacy >implications in sending information which was not usually sent as >part of a DNS request. Since this draft has expired and no longer seems to be active, I will remove the reference to it. > >In Section 4.4, "Referrer" is misspelled. Thanks. Will update. > >The draft does not discuss about content delivered over HTTPS. There >are issues, e.g. see >http://www.ietf.org/mail-archive/web/ietf/current/msg86077.html >Given that the IETF considers pervasive monitoring as an attack, >there is an expectation that the problem would be taken into >consideration for a framework document. >From the point of CDNI, it doesn=B9t really matter whether the actual content is delivered via HTTP, HTTPS, RTSP or some other mechanism, hence the fact that most examples use HTTP. What exactly would you like to see discussed regarding HTTPS? > >The CDNI WG Charter mentions that: > > "Such content includes, but is not limited to, web pages and images > delivered via HTTP, and streaming of continuous media delivered via > HTTP, RTSP, RTMP, etc. CDNs typically provide services to multiple > Content Service Providers (CSPs)." > >The only upper layer protocol discussed in the draft is HTTP. > >Regards, >S. Moonesamy > Thanks again, Ray 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 Tue Mar 4 11:55:01 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 304961A01B0 for ; Tue, 4 Mar 2014 11:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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.547, 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 hfrpxlUEGdoq for ; Tue, 4 Mar 2014 11:54:59 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 5A87D1A0255 for ; Tue, 4 Mar 2014 11:54:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2714; q=dns/txt; s=iport; t=1393962895; x=1395172495; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LqLn4gE9+Na02wfJf1CwK9MGqKe6OWw3dCwPFnBoSW0=; b=GGQAeGjoqxxiAtmd3qrOoKtmaODDcE7V+aj6Jvyla//+xSB/GAk2tUEN xZo19RESz2vIDQGfqSLWTtSnyUsFk1GmefHdzKfnkL4ZAewUnjMibo3fy eMFKJXusZKj9kii9sUKc1JWucbVWAMvfXACScIvqjxLw1mZvSqvSuU3Kx M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0FAJ0uFlOtJV2a/2dsb2JhbABagwY7UQaDA71vGIEHFnSCJQEBAQQjEUMCDAQCAQgRBAEBAwIGHQMCAgIwFAEGAQEFAwIEDgUIAYdwCAWtDaAtF4EpjHcxBwaCaTWBFASZbpB5gy2BaiQc X-IronPort-AV: E=Sophos;i="4.97,587,1389744000"; d="scan'208";a="24876971" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-2.cisco.com with ESMTP; 04 Mar 2014 19:54:54 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s24JssOS031241 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Mar 2014 19:54:54 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.138]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Tue, 4 Mar 2014 13:54:54 -0600 From: "Kent Leung (kleung)" To: "cdni@ietf.org" Thread-Topic: New Version Notification for draft-leung-cdni-uri-signing-05.txt Thread-Index: AQHPN+Incs/IzTHN8UiZ6LVSreELe5rRVi3A Date: Tue, 4 Mar 2014 19:54:53 +0000 Message-ID: References: <20140304194425.2320.71142.idtracker@ietfa.amsl.com> In-Reply-To: <20140304194425.2320.71142.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.125.223] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/gCFS-MBFSOtHS2TAC3DBxfD5T6w Cc: "mnot@mnot.net" Subject: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-05.txt 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, 04 Mar 2014 19:55:01 -0000 RllJLiBUaGlzIHZlcnNpb24gaW5jb3Jwb3JhdGVkIHRoZSB0ZXh0IHByb3ZpZGVkIGJ5IE1hcmsg Ti4gdGhhdCBhZGRyZXNzZWQgdGhlICJVUkkgU3F1YXR0aW5nIiBpc3N1ZS4gIEFsc28sIHRoZSBy ZXZpZXcgY29tbWVudHMgZnJvbSBLZXZpbiB3ZXJlIGFkZHJlc3NlZCB0b28uDQoNCktlbnQNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBUdWVzZGF5LCBNYXJj aCAwNCwgMjAxNCA3OjQ0IFBNDQpUbzogUmF5IHZhbiBCcmFuZGVuYnVyZzsgS2VudCBMZXVuZyAo a2xldW5nKTsgQmlsbCBEb3duZXk7IEJpbGwgRG93bmV5OyBTY290dCBMZWlicmFuZDsgU2NvdHQg TGVpYnJhbmQ7IEtlbnQgTGV1bmcgKGtsZXVuZyk7IEZyYW5jb2lzIExlIEZhdWNoZXVyIChmbGVm YXVjaCk7IFJheSB2YW4gQnJhbmRlbmJ1cmc7IEZyYW5jb2lzIExlIEZhdWNoZXVyIChmbGVmYXVj aCkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGV1bmctY2Ru aS11cmktc2lnbmluZy0wNS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGV1 bmctY2RuaS11cmktc2lnbmluZy0wNS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0 ZWQgYnkgS2VudCBMZXVuZyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5h bWU6CQlkcmFmdC1sZXVuZy1jZG5pLXVyaS1zaWduaW5nDQpSZXZpc2lvbjoJMDUNClRpdGxlOgkJ VVJJIFNpZ25pbmcgZm9yIENETiBJbnRlcmNvbm5lY3Rpb24gKENETkkpDQpEb2N1bWVudCBkYXRl OgkyMDE0LTAzLTA0DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkzNQ0K VVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWxldW5nLWNkbmktdXJpLXNpZ25pbmctMDUudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGV1bmctY2RuaS11cmktc2lnbmluZy8NCkh0 bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sZXVuZy1jZG5p LXVyaS1zaWduaW5nLTA1DQpEaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtbGV1bmctY2RuaS11cmktc2lnbmluZy0wNQ0KDQpBYnN0cmFjdDoNCiAg IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyB0aGUgY29uY2VwdCBvZiBVUkkgc2lnbmluZyBz dXBwb3J0cyB0aGUNCiAgIGNvbnRlbnQgYWNjZXNzIGNvbnRyb2wgcmVxdWlyZW1lbnRzIG9mIENE TkkgYW5kIHByb3Bvc2VzIGEgVVJJDQogICBzaWduaW5nIHNjaGVtZS4NCg0KICAgVGhlIHByb3Bv c2VkIFVSSSBzaWduaW5nIG1ldGhvZCBzcGVjaWZpZXMgdGhlIGluZm9ybWF0aW9uIG5lZWRlZCB0 bw0KICAgYmUgaW5jbHVkZWQgaW4gdGhlIFVSSSBhbmQgdGhlIGFsZ29yaXRobSB1c2VkIHRvIGF1 dGhvcml6ZSBhbmQgdG8NCiAgIHZhbGlkYXRlIGFjY2VzcyByZXF1ZXN0cyBmb3IgdGhlIGNvbnRl bnQgcmVmZXJlbmNlZCBieSB0aGUgVVJJLiAgU29tZQ0KICAgb2YgdGhlIGluZm9ybWF0aW9uIG1h eSBiZSBhY2Nlc3NlZCBieSB0aGUgQ0ROIHZpYSBjb25maWd1cmF0aW9uIG9yDQogICBDRE5JIG1l dGFkYXRhLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Thu Mar 6 04:58:16 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 1ED4D1A03CA for ; Mon, 3 Mar 2014 23:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 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.547] 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 YTj09tmkCH7V for ; Mon, 3 Mar 2014 23:13:35 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B762C1A03C6 for ; Mon, 3 Mar 2014 23:13:35 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.129.2]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s247DIvS027336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Mar 2014 23:13:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1393917211; bh=mBAIBN8oc1UmjxsnaBpdIKwlZcHnXDkRXtFGy/fXcas=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=T4ufpTk01NYIBA4HnwzNhe6A48DqcnzLTBVgWB4GHRS6sTWMckCDT9LeYnhlCEx6l v7VmGrXoo3SFlZDRFM6Z+zJbQmzqCgra5pF6ogX41tA4h0sQh4De4pddjvFL5X5tWG kUK+CPE1VmHozlP52NNDlNGdODgE4Z6P6n7dH6yI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1393917211; i=@elandsys.com; bh=mBAIBN8oc1UmjxsnaBpdIKwlZcHnXDkRXtFGy/fXcas=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=k1H08wcarOUpbGlHTisCjK/KQHH2r/bQ+5q4NgJir0vlu3JENfY/xpvULbACbH9Ge TlOp90P0zmforBgCu8mUYLVVfuU8Ep7DsB+JgCpNpH7+kzHzBzsNYP+hasefmHv74x XMM8ZFMRNo4t9O8nuKy/vSkTweCfT+0DMvCYtrxI= Message-Id: <6.2.5.6.2.20140303205434.0c2752a8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 03 Mar 2014 22:00:17 -0800 To: draft-ietf-cdni-framework.all@tools.ietf.org From: S Moonesamy In-Reply-To: <20140303153324.17255.11212.idtracker@ietfa.amsl.com> References: <20140303153324.17255.11212.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/-fn8Vl4oUFZP2pQ-8pv_jA3VLiA X-Mailman-Approved-At: Thu, 06 Mar 2014 04:58:14 -0800 Cc: cdni@ietf.org Subject: Re: [CDNi] Last Call: (Framework for CDN Interconnection) to Informational RFC 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, 04 Mar 2014 07:13:38 -0000 At 07:33 03-03-2014, The IESG wrote: >The IESG has received a request from the Content Delivery Networks >Interconnection WG (cdni) to consider the following document: >- 'Framework for CDN Interconnection' > as Informational RFC > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the I took a quick look at the draft. Section 2.1.1 discusses about "DNS Redirection". I don't think that it fits as redirection as used within a DNS context. There is an assumption that the recursive resolver is local. The term "DNS server" is ambiguous. "DNS responses are cached by downstream servers so the TTL on the response must be set to an appropriate value so as to preserve the fresheness of the redirection." These (DNS) servers are not downstream servers. Section 2.1.2 does not provide a good discussion about why HTTP redirection is not the preferred choice. The draft mentions that the disadvantage of HTTP redirection is that it requires application support. All web browsers support HTTP redirection. There are disadvantages to using DNS to serve content. There is an assumption that a user with an IP address in, for example, Japan will understand localized content for that country. In Section 3.2: "2. A Request Router for Operator A processes the HTTP request and recognizes that the end-user is best served by another CDN," Routers do not process HTTP requests. In Section 3.4: "One approach to ensuring that the client's IP address prefix is correctly determined in such situations is described in [I-D.vandergaast-edns-client-subnet]" That Internet-Draft was discussed previously. There are privacy implications in sending information which was not usually sent as part of a DNS request. In Section 4.4, "Referrer" is misspelled. The draft does not discuss about content delivered over HTTPS. There are issues, e.g. see http://www.ietf.org/mail-archive/web/ietf/current/msg86077.html Given that the IETF considers pervasive monitoring as an attack, there is an expectation that the problem would be taken into consideration for a framework document. The CDNI WG Charter mentions that: "Such content includes, but is not limited to, web pages and images delivered via HTTP, and streaming of continuous media delivered via HTTP, RTSP, RTMP, etc. CDNs typically provide services to multiple Content Service Providers (CSPs)." The only upper layer protocol discussed in the draft is HTTP. Regards, S. Moonesamy From nobody Thu Mar 6 04:58:18 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 AF94D1A00E3 for ; Wed, 5 Mar 2014 04:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.547, T_DKIM_INVALID=0.01] 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 ier_MNRcfpdO for ; Wed, 5 Mar 2014 04:50:59 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62AE51A006B for ; Wed, 5 Mar 2014 04:50:59 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.139.192]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s25Cofhw027971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Mar 2014 04:50:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1394023855; bh=SRVVKlE9koRygf1t2axmp6zPgjoWfaHdY1hkauWi+ME=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=SRRH64QGq0qHB5543z8ehi2iCoNwPLE2DfjseCa6sp/ccZ4i9Hz0q10BNfh7VM9lZ a6e4QDmHgMd5HiNf0aVc2aJz/GHTrWzUgBjMJOa12e8ge0BWZVhO0EXMii47Xuo6eG opjUTFDTQLVZ9dm5PTYGJN1ERbkKSVzAF6asDWpY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1394023855; i=@elandsys.com; bh=SRVVKlE9koRygf1t2axmp6zPgjoWfaHdY1hkauWi+ME=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=LH6o/Rs/TtcIozVe0JegLKDQqsiUJ4cm37uYc3Xml4SCle/DCDI84UQIQPYacTIXZ c4Z3rtwcOjQ8YPKnf4PaehksKx1GovYjZ+HcHztU3/i5b6q0RUJrltm3vC4sHJ8SNs /d769zRDBIfGEVSLRheVFNdGRXTqyJHEgBWZLTQ0= Message-Id: <6.2.5.6.2.20140305042046.0d4d0c00@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 05 Mar 2014 04:46:48 -0800 To: "Brandenburg, R. (Ray) van" , draft-ietf-cdni-framework.all@tools.ietf.org From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20140303205434.0c2752a8@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/XDCEC0VxrmJsNZxYXudZPgwa4-Y X-Mailman-Approved-At: Thu, 06 Mar 2014 04:58:14 -0800 Cc: cdni@ietf.org Subject: Re: [CDNi] Last Call: (Framework for CDN Interconnection) to Informational RFC 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, 05 Mar 2014 12:51:00 -0000 Hi Ray, At 03:09 04-03-2014, Brandenburg, R. (Ray) van wrote: >I think it's important that note that the terminology in this document, >and other CDNI documents, aligns with terminology as found in the CDN >space, some of which may conflict with terminology as used in some other >IETF WGs. A large share of (global) CDNs are currently using DNS to >effectively redirect end users to one of their servers, hence the term >DNS Redirection. I appreciate that such terminology would have another >meaning when uttered in e.g. a DNS WG. Ideally, it would be best to line >up our terminology, however, at this point, I would rather make sure the >terminology in this document lines up with other CDNI documents such as >RFC6707 and 6770. If I understood correctly CDNI builds upon existing IETF specifications, e.g. DNS. The draft does not even reference those specifications. I'll defer to the relevant Area Director on the question of terminology. >Are you saying that you would rather use a different term for such >"downstream" DNS servers? Do you have a suggestion? I don't think that "downstream" DNS servers is appropriate. The term "recursive name server" is a better fit. >I see your point. I agree that the way it is written right now, the >discussion might seem a bit lopsided, especially since the section on DNS >Redirection does not list disadvantages. I will add those. In general, I >would like to add that for the purposes of the CDNI Framework document, we >are not in a position where we would like to advise for or against either >HTTP or DNS as a redirection mechanism, the only thing that is important >is that the CDNI interfaces allow for CDNs that use either of the two >mechanisms to successfully interconnect. I was not arguing for or against either alternative. I think that it is worthwhile to provide information which would not mislead the reader. >Again, I think this a matter of terminology. A Request Router in a CDN is >not a router in the IP-router sense, but an application level device >which performs (HTTP) 302 redirects in order to load balance between >multiple (HTTP) servers and/or CDNs. I'll defer to the relevant Area Director on the question of terminology. > From the point of CDNI, it doesn't really matter whether the actual >content is delivered via HTTP, HTTPS, RTSP or some other mechanism, hence >the fact that most examples use HTTP. What exactly would you like to see >discussed regarding HTTPS? I think that the working group could have at least considered HTTPS and determine whether there are issues worth discussing or not. AS it stands, the draft looks like HTTP was used as the general case for all content that is delivered. Regards, S. Moonesamy From nobody Thu Mar 6 07:35: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 3964E1A0142 for ; Thu, 6 Mar 2014 07:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.31 X-Spam-Level: X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] 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 FX3rZkBnEz49 for ; Thu, 6 Mar 2014 07:34:51 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id B863D1A0108 for ; Thu, 6 Mar 2014 07:34:51 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id s26FYiAC014430; Thu, 6 Mar 2014 08:34:44 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Thu, 06 Mar 2014 08:34:44 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0174.001; Thu, 6 Mar 2014 08:34:44 -0700 From: Daryl Malas To: "cdni@ietf.org" Thread-Topic: [CDNi] URI Signing for CDNI Working Group Draft Thread-Index: AQHPOVGYw3b21la5Dkimbh8ScN6pDA== Date: Thu, 6 Mar 2014 15:34:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.5.0.27] Content-Type: multipart/alternative; boundary="_000_CF3E4611186AEdmalascablelabscom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/H2jLsPtW2DU03MxNXHJh6GeNZCE Subject: [CDNi] URI Signing for CDNI Working Group 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: Thu, 06 Mar 2014 15:34:54 -0000 --_000_CF3E4611186AEdmalascablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All, During today=92s working group meeting, we agreed the latest draft revision= of this draft (http://tools.ietf.org/html/draft-leung-cdni-uri-signing-05)= is substantial for us to adopt it as a working group item. However, Franc= ois and I did not feel comfortable conducting a =93Hum,=94 since there were= not a lot of people present who had read the draft. This draft was propos= ed in response to the following charter item: 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). In addition, the working group has the following milestone: Sep 2014 - Submit specification of URI Signing for CDNI to IESG as Proposed= Standard With this in mind, we are requesting people read the draft in preparation f= or this draft to be accepted as a working group item, which will occur on M= arch 21st. If anyone has any major concerns with this, please post comment= s and concerns to the list. Regards, Daryl & Francois --_000_CF3E4611186AEdmalascablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <58E66FD3E7F4F9429780B85080697F0E@cablelabs.com> Content-Transfer-Encoding: quoted-printable
All,

During today=92s working group meeting, we agreed the latest draft revision= of this draft (http://tools.ietf.org/html/draft-leung-cdni-uri-signing-05)= is substantial for us to adopt it as a working group item.  However, Francois and I did not feel comfortab= le conducting a =93Hum,=94 since there were not a lot of people present who= had read the draft.  This draft was proposed in response to the follo= wing charter item:

A specification for "CDNI URI Signing". This document will s= pecify 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).

In addition, the working group has the following milestone:

Sep 2014 - Submit specification of URI Signing = for CDNI to IESG as Proposed Standard

With this in mind, we are requesting people read the draft in preparation f= or this draft to be accepted as a working group item, which will occur on M= arch 21st.  If anyone has any major concerns with this, please post co= mments and concerns to the list.

Regards,

Daryl & Francois



--_000_CF3E4611186AEdmalascablelabscom_-- From nobody Thu Mar 6 07:39:47 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 80D1F1A017D for ; Thu, 6 Mar 2014 07:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.547] 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 GDwlLumsAiio for ; Thu, 6 Mar 2014 07:39:43 -0800 (PST) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC051A00A2 for ; Thu, 6 Mar 2014 07:39:42 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.97,601,1389740400"; d="scan'208";a="22245587" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 06 Mar 2014 16:39:37 +0100 Received: from EXC-MBX03.tsn.tno.nl ([fe80::e969:1300:fb9f:7e12]) by EXC-CASHUB01.tsn.tno.nl ([fe80::b855:be6:1aa8:4d0f%13]) with mapi id 14.03.0123.003; Thu, 6 Mar 2014 16:39:37 +0100 From: "Brandenburg, R. (Ray) van" To: S Moonesamy , "draft-ietf-cdni-framework.all@tools.ietf.org" Thread-Topic: Last Call: (Framework for CDN Interconnection) to Informational RFC Thread-Index: AQHPOHGOGd3MgXnzqEq1CWehHVWkvJrUIuGA Date: Thu, 6 Mar 2014 15:39:36 +0000 Message-ID: References: <6.2.5.6.2.20140303205434.0c2752a8@resistor.net> <6.2.5.6.2.20140305042046.0d4d0c00@elandnews.com> In-Reply-To: <6.2.5.6.2.20140305042046.0d4d0c00@elandnews.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [134.221.225.153] Content-ID: <3500D17473DB94468D544A92D17D1001@tno.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/LKILfeb0SbiZvDuHYX3X3Y2AEFU Cc: "cdni@ietf.org" Subject: Re: [CDNi] Last Call: (Framework for CDN Interconnection) to Informational RFC 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: Thu, 06 Mar 2014 15:39:45 -0000 Hi S., On 05/03/14 12:46, "S Moonesamy" wrote: >Hi Ray, >At 03:09 04-03-2014, Brandenburg, R. (Ray) van wrote: >>I think it's important that note that the terminology in this document, >>and other CDNI documents, aligns with terminology as found in the CDN >>space, some of which may conflict with terminology as used in some other >>IETF WGs. A large share of (global) CDNs are currently using DNS to >>effectively redirect end users to one of their servers, hence the term >>DNS Redirection. I appreciate that such terminology would have another >>meaning when uttered in e.g. a DNS WG. Ideally, it would be best to line >>up our terminology, however, at this point, I would rather make sure the >>terminology in this document lines up with other CDNI documents such as >>RFC6707 and 6770. > >If I understood correctly CDNI builds upon existing IETF >specifications, e.g. DNS. The draft does not even reference those >specifications. = You=B9re right that the document mentions DNS, however, I=B9m not sure that warrants an (informative) reference to a DNS specification. Do you have a specific DNS spec in mind that you would like to see referenced? >I'll defer to the relevant Area Director on the >question of terminology. > >>Are you saying that you would rather use a different term for such >>"downstream" DNS servers? Do you have a suggestion? > >I don't think that "downstream" DNS servers is appropriate. The term >"recursive name server" is a better fit. In order to understand the meaning of the sentence, I think it=B9s helpful to clarify the fact that we=B9re talking about a DNS server in the Downstream CDN, hence the term downstream DNS server. I=B9m a not sure whether recursive name server would cover the meaning as well. How about =8CDNS responses are cached by servers in the dCDN=B9? > >>I see your point. I agree that the way it is written right now, the >>discussion might seem a bit lopsided, especially since the section on DNS >>Redirection does not list disadvantages. I will add those. In general, I >>would like to add that for the purposes of the CDNI Framework document, >>we >>are not in a position where we would like to advise for or against either >>HTTP or DNS as a redirection mechanism, the only thing that is important >>is that the CDNI interfaces allow for CDNs that use either of the two >>mechanisms to successfully interconnect. > >I was not arguing for or against either alternative. I think that it >is worthwhile to provide information which would not mislead the reader. Again, our intention is not to hint at a =8Cpreferred=B9 choice between HTTP or DNS, or to =8Clead=B9 (let alone mislead) the reader in any direction. I will try to rephrase the paragraph to remove any words that might sound as such. = > >>Again, I think this a matter of terminology. A Request Router in a CDN is >>not a router in the IP-router sense, but an application level device >>which performs (HTTP) 302 redirects in order to load balance between >>multiple (HTTP) servers and/or CDNs. > >I'll defer to the relevant Area Director on the question of terminology. > >> From the point of CDNI, it doesn't really matter whether the actual >>content is delivered via HTTP, HTTPS, RTSP or some other mechanism, hence >>the fact that most examples use HTTP. What exactly would you like to see >>discussed regarding HTTPS? > >I think that the working group could have at least considered HTTPS >and determine whether there are issues worth discussing or not. AS >it stands, the draft looks like HTTP was used as the general case for >all content that is delivered. Ok. = > >Regards, >S. Moonesamy = > Thanks, Ray 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 Thu Mar 6 07:51:06 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 474FA1A00BA for ; Thu, 6 Mar 2014 07:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DXVB_FuJunra for ; Thu, 6 Mar 2014 07:51:00 -0800 (PST) Received: from p01c11o145.mxlogic.net (p01c11o145.mxlogic.net [208.65.144.68]) by ietfa.amsl.com (Postfix) with ESMTP id CB3081A00DE for ; Thu, 6 Mar 2014 07:50:27 -0800 (PST) Received: from unknown [69.25.75.234] (EHLO HUB024.mail.lan) by p01c11o145.mxlogic.net(mxl_mta-7.2.4-1) with ESMTP id 04998135.2b318803f940.89489.00-552.203719.p01c11o145.mxlogic.net (envelope-from ); Thu, 06 Mar 2014 08:50:24 -0700 (MST) X-MXL-Hash: 531899405914d7b2-eac37e04422d91c22570eeeed3c04c7573428f5a Received: from unknown [69.25.75.234] (EHLO HUB024.mail.lan) by p01c11o145.mxlogic.net(mxl_mta-7.2.4-1) over TLS secured channel with ESMTP id f4898135.0.86610.00-306.196245.p01c11o145.mxlogic.net (envelope-from ); Thu, 06 Mar 2014 08:46:27 -0700 (MST) X-MXL-Hash: 531898532edb7f08-90539d3c2c22c47a9fda313a13d6e19e49bf07d5 Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB024.mail.lan ([10.110.17.24]) with mapi; Thu, 6 Mar 2014 10:45:12 -0500 From: Kevin J Ma To: Daryl Malas , "cdni@ietf.org" Date: Thu, 6 Mar 2014 10:46:13 -0500 Thread-Topic: [CDNi] URI Signing for CDNI Working Group Draft Thread-Index: AQHPOVGYw3b21la5Dkimbh8ScN6pDJrUMhhQ Message-ID: <291CC3F9E50E7641901A54E85D0977C6D542C14B41@MAILR002.mail.lan> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_291CC3F9E50E7641901A54E85D0977C6D542C14B41MAILR002maill_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/jzKbc_kGxrKMxFlcGpn3zDrAIXY Subject: Re: [CDNi] URI Signing for CDNI Working Group 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: Thu, 06 Mar 2014 15:51:02 -0000 --_000_291CC3F9E50E7641901A54E85D0977C6D542C14B41MAILR002maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Daryl, As one of the few non-authors in the room that had read the draft, I'll just throw out my hum for adoption. The latest version is in pretty good shape. Last week I sent comments to the list on the current version and have discussed them with the authors this week. Assuming those comments get addressed I think draft-leung is a good basis for the wg draft. -- Kevin J. Ma From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Daryl Malas Sent: Thursday, March 06, 2014 10:35 AM To: cdni@ietf.org Subject: [CDNi] URI Signing for CDNI Working Group Draft All, During today's working group meeting, we agreed the latest draft revision o= f this draft (http://tools.ietf.org/html/draft-leung-cdni-uri-signing-05) i= s substantial for us to adopt it as a working group item. However, Francoi= s and I did not feel comfortable conducting a "Hum," since there were not a= lot of people present who had read the draft. This draft was proposed in = response to the following charter item: 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). In addition, the working group has the following milestone: Sep 2014 - Submit specification of URI Signing for CDNI to IESG as Proposed= Standard With this in mind, we are requesting people read the draft in preparation f= or this draft to be accepted as a working group item, which will occur on M= arch 21st. If anyone has any major concerns with this, please post comment= s and concerns to the list. Regards, Daryl & Francois --_000_291CC3F9E50E7641901A54E85D0977C6D542C14B41MAILR002maill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Daryl,

 

  As one of the few non-authors in t= he room that had read the draft, I'll

 just= throw out my hum for adoption.  The latest version is in pretty good<= o:p>

  shape.  Last week I sent comments to = the list on the current version and

 have d= iscussed them with the authors this week.  Assuming those comments

  get addressed I think draft-leung is a good b= asis for the wg draft.

 

--  Kevin J. Ma

 

From: CDNi [mailto:cdni-boun= ces@ietf.org] On Behalf Of Daryl Malas
Sent: Thursday, Mar= ch 06, 2014 10:35 AM
To: cdni@ietf.org
Subject: [CDNi] = URI Signing for CDNI Working Group Draft

<= p class=3DMsoNormal> 

All= ,

 

During today’s work= ing group meeting, we agreed the latest draft revision of this draft (http://to= ols.ietf.org/html/draft-leung-cdni-uri-signing-05) is substantial for u= s to adopt it as a working group item.  However, Francois and I did no= t feel comfortable conducting a “Hum,” since there were not a l= ot of people present who had read the draft.  This draft was proposed = in response to the following charter item:

=

 

A specification for "CDNI URI Signing". This= document will specify a

mechanism that allows interconnected CDNs to support access control=

by signing conte= nt URIs. This may involve extensions to the CDNI

interfaces (e.g. CDNI Metadata interface, C= DNI Logging interface).

 

In addition, the working group has the following milestone:

 

<= /div>

Sep 2014 - Submit specification of URI Signing for CDNI to= IESG as Proposed Standard

 

With this in mind, we are requesting people read the draft in prepa= ration for this draft to be accepted as a working group item, which will oc= cur on March 21st.  If anyone has any major concerns with this, please= post comments and concerns to the list.

 

Regards,

 

Dary= l & Francois

=  

 = ;

 

= --_000_291CC3F9E50E7641901A54E85D0977C6D542C14B41MAILR002maill_-- From nobody Mon Mar 10 14:00:26 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 534D51A04C5 for ; Mon, 10 Mar 2014 14:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 97pwa6q9Lw2U for ; Mon, 10 Mar 2014 14:00:21 -0700 (PDT) Received: from p01c12o145.mxlogic.net (p01c12o145.mxlogic.net [208.65.145.68]) by ietfa.amsl.com (Postfix) with ESMTP id 878631A04A6 for ; Mon, 10 Mar 2014 14:00:21 -0700 (PDT) Received: from unknown [69.25.75.234] (EHLO HUB016.mail.lan) by p01c12o145.mxlogic.net(mxl_mta-7.2.4-1) with ESMTP id 0e72e135.2b3cdd421940.29830.00-584.87040.p01c12o145.mxlogic.net (envelope-from ); Mon, 10 Mar 2014 15:00:16 -0600 (MDT) X-MXL-Hash: 531e27e063494e7f-065eec703b53f70808d6fad6605684c3b5662f5a Received: from unknown [69.25.75.234] (EHLO HUB016.mail.lan) by p01c12o145.mxlogic.net(mxl_mta-7.2.4-1) over TLS secured channel with ESMTP id cb72e135.0.29495.00-078.86062.p01c12o145.mxlogic.net (envelope-from ); Mon, 10 Mar 2014 14:59:49 -0600 (MDT) X-MXL-Hash: 531e27c519e328b9-65e34bb9309fd04a01f70b9bf9c00e462f3cbb7b Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Mon, 10 Mar 2014 16:59:39 -0400 From: Kevin J Ma To: "Francois Le Faucheur (flefauch)" , "draft-ietf-cdni-metadata@tools.ietf.org" , "cdni@ietf.org" Date: Mon, 10 Mar 2014 16:59:39 -0400 Thread-Topic: WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 2] Thread-Index: AQHPLyLW+grR8OSmCE+3oXnY+ir15JracUag Message-ID: <291CC3F9E50E7641901A54E85D0977C6D542CDC16A@MAILR002.mail.lan> References: <20140214214618.22993.11019.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/mL-5ZNa1CkVAJvD62CCV3TJdf68 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: Mon, 10 Mar 2014 21:00:24 -0000 Hi Francois, Thanks for the comments (looking forward to the rest); responses inline: > -----Original Message----- > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le > Faucheur (flefauch) > Sent: Friday, February 21, 2014 11:35 AM > To: draft-ietf-cdni-metadata@tools.ietf.org; cdni@ietf.org > Subject: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch > 2] >=20 >=20 > *** section 3.1: Table 2: > "A PathMetadata object contains the CDNI GenericMetadata objects" > Should this say "contains or references"? > Same comment for "GenericMetadata"? > 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 contai= n > or reference", or whetehr there are some cases where it "always contains"= . > Please make sure this is made clear. Changed PathMetadata to include "or references". wrt GenericMetadata, imo, the GenericMetadata object should be the minimum = atomic unit for the MI. HostMetadata and PathMetadata objects reference GenericMe= tadata objects, but the Generic Metadata object contains a full object, references= to which should've been made at a higher level (i.e., in the HostMetadata or=20 PathMetadata object in which it is contained). It may contain references t= o member data, but not to another GenericMetadata object. I have clarified t= he text. > *** section 3.2: > OLD: > " > 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. > " > NEW: > " > 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. > " Done. =20 > *** section 3.2: > " > 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. > " > 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). Removed that sentance and added normative text for handling metadata which is not safe to redistribute. One question I have is: If the content is both "mandatory-to-enforce" and not "safe-to-redistribu= te", and the transit CDN doesn't understand/support it, then the transit CDN M= UST instruct the downstream CDN to reject all requests for that content? We do not have a defined mechanism for this today. Should we define and return a well known auto-reject Metadata object? (An HTTP response code seems too heavy handed, e.g., if the dCDN just requested all metadata, and only 1 sub-path has a metadata issue.) > *** section 3.2 > s/optimially/optimally/ Done. > ***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. > "Mandatory To Enforce" (or "Mandatory-To-Enforce") > "Safe To Redistribute" (or "Safe-To-Redistribute") > another option coudl to quote the corresponding property names defined > later ie "madatory-to-enforce"/"safe-to-redistribute". Done. Went with quotes and dashes ("madatory-to-enforce"/"safe-to-redistri= bute"). > *** section 3.3: > OLD: > " > the TimeWindowACL defined in the PathMetadata would override the > TimeWindowACL defined in the HostMetadata > " > NEW: > " > 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" > " Done. > *** section 3.3: > " > The PathMetadata defined TimeWindowACL would override the > TimeWindowACL defined in the HostMetadata for all User Agent requests > for movies. > " > 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. Removed. > *** section 3.4: > "The 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." > I think all the normative language about metadata types shoudl be moved t= o > the relevant IANA sub-section (unless we conclude differently in the > thread about that question started in the context of cdni-logging). So I'= d > see all the quoted text above be merged into the appropriate IANA sub- > section. Moved and merged. > *** section 3.4: > " Metadata types defined by this document are not hierarchical." > I suggest adding an explanation or example about what you mean by > "hierarchical". Removed. -- Kevin J. Ma From nobody Tue Mar 11 06:07:24 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 3A4F81A066C for ; Tue, 11 Mar 2014 06:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 k322Ia1Tzfda for ; Tue, 11 Mar 2014 06:07:21 -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 F32AA1A043F for ; Tue, 11 Mar 2014 06:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1761; q=dns/txt; s=iport; t=1394543233; x=1395752833; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7D48KIptPyWp62Cpow98QUsmnSo47LiI7Y40OBOiL5Q=; b=A2rBqDJFOqbCE3NNSyccMCLfABppVcuvtY/du4w4alJm2uiRUW1+nVpX 5d7EOBLYmUT5vtInu3Obq/gEgDXt2VeMaMfGAQWWOE8x1fTnyujA2me1P 23oWeXVKKH4xI2qPvrnRYfS+cVptOWKjcMkDBs+CmDO2LvF5gLQ+wO29u A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAD4JH1OtJXG+/2dsb2JhbABagwY7V8E2gSEWdIIlAQEBAwF5BQsCAQhGMiUCBA6HdgjRGBeOKTMHgySBFAEDmEWSLYMtgis X-IronPort-AV: E=Sophos;i="4.97,630,1389744000"; d="scan'208";a="309509302" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 11 Mar 2014 13:07:13 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2BD7DRQ010067 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Mar 2014 13:07:13 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.151]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Tue, 11 Mar 2014 08:07:12 -0500 From: "Francois Le Faucheur (flefauch)" To: Kevin J Ma Thread-Topic: WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 2] Thread-Index: AQHPLyLW+grR8OSmCE+3oXnY+ir15JracUaggAHZ5oA= Date: Tue, 11 Mar 2014 13:07:12 +0000 Message-ID: <76DDDCA9-5916-45F6-8620-0FCFE3E0105C@cisco.com> References: <20140214214618.22993.11019.idtracker@ietfa.amsl.com> <291CC3F9E50E7641901A54E85D0977C6D542CDC16A@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6D542CDC16A@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] Content-Type: text/plain; charset="Windows-1252" Content-ID: <45D91C393BFE5A48B611941BE1DF3737@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/927PdSH6nnpdWQPoz5ixGrhYk7o 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, 11 Mar 2014 13:07:23 -0000 Hi Kevin, Thanks for addressing the comments.=20 Focusing on the remaining open item below: >=20 > One question I have is: > If the content is both "mandatory-to-enforce" and not "safe-to-redistrib= ute", > and the transit CDN doesn't understand/support it, then the transit CDN = MUST > instruct the downstream CDN to reject all requests for that content? Right. > We do not have a defined mechanism for this today. > Should we define and return a well known auto-reject Metadata object? > (An HTTP response code seems too heavy handed, e.g., if the dCDN just > requested all metadata, and only 1 sub-path has a metadata issue.) If the metadata object is both "mandatory-to-enforce" and not "safe-to-redi= stribute=94, then how about we indicate that: *A* a transit CDN request routing function is expected to attempt to not r= edirect request for corresponding content further to downstream CDNs, and *B* a transit CDN CDNI metadata function MUST update the metadata to add a= newly defined =93do-not-serve=94 object that will instruct the dCDN (and w= e specify somewhere that any cDN that sees that object MUST not serve the c= ontent, regardles of what the other metadata says). We need to think about = whetehr we want to leave the initial object that was "mandatory-to-enforce"= and not "safe-to-redistribute=94 , or wehether it should be removed (on th= e grounds that it contains non-sensical information since it has not been p= roperly =93updated=94 by the transit CDN). I am not sure if *B* is what you also meant. ie the word =93return=94 confu= sed me, since teh approach I describe above does not return anything new, b= ut just adds something in the propagated metadata. Makes sense? = From nobody Tue Mar 11 06:27:18 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 7FBD81A06A7 for ; Tue, 11 Mar 2014 06:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4LPL4SrQ_aWa for ; Tue, 11 Mar 2014 06:27:15 -0700 (PDT) Received: from p01c11o142.mxlogic.net (p01c11o142.mxlogic.net [208.65.144.65]) by ietfa.amsl.com (Postfix) with ESMTP id 08BDA1A0674 for ; Tue, 11 Mar 2014 06:27:15 -0700 (PDT) Received: from unknown [69.25.75.234] (EHLO HUB025.mail.lan) by p01c11o142.mxlogic.net(mxl_mta-7.2.4-1) with ESMTP id d2f0f135.2b375ca00940.2866.00-502.8070.p01c11o142.mxlogic.net (envelope-from ); Tue, 11 Mar 2014 07:27:09 -0600 (MDT) X-MXL-Hash: 531f0f2d0c65b890-89c95eb59e82785a097b22bd6c21239f40fdd513 Received: from unknown [69.25.75.234] (EHLO HUB025.mail.lan) by p01c11o142.mxlogic.net(mxl_mta-7.2.4-1) over TLS secured channel with ESMTP id 0fc0f135.0.15813.00-392.43038.p01c11o142.mxlogic.net (envelope-from ); Tue, 11 Mar 2014 07:17:40 -0600 (MDT) X-MXL-Hash: 531f0cf44e56cbca-8ec7b3760ec58e3e0135bd4805fc67b8d97a8f71 Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Tue, 11 Mar 2014 09:17:35 -0400 From: Kevin J Ma To: "Francois Le Faucheur (flefauch)" Date: Tue, 11 Mar 2014 09:17:33 -0400 Thread-Topic: WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 2] Thread-Index: AQHPLyLW+grR8OSmCE+3oXnY+ir15JracUaggAHZ5oD//600kA== Message-ID: <291CC3F9E50E7641901A54E85D0977C6E7B8597C42@MAILR002.mail.lan> References: <20140214214618.22993.11019.idtracker@ietfa.amsl.com> <291CC3F9E50E7641901A54E85D0977C6D542CDC16A@MAILR002.mail.lan> <76DDDCA9-5916-45F6-8620-0FCFE3E0105C@cisco.com> In-Reply-To: <76DDDCA9-5916-45F6-8620-0FCFE3E0105C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/lpXuONostwX3QO2TWXdq0_-vmGE 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, 11 Mar 2014 13:27:17 -0000 Hi Francois, "*B*" was precisely what I was thinking, replacing all of the existing metadata for the Hosts/Paths that had unsupported MtE and non-StR=20 metadata with a well known do-not-serve metadata object. I will add that and some additional text for "*A*" unless someone objects? thanx! -- Kevin J. Ma > -----Original Message----- > From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] > Sent: Tuesday, March 11, 2014 9:07 AM > To: Kevin J Ma > Cc: Francois Le Faucheur (flefauch); draft-ietf-cdni- > metadata@tools.ietf.org; cdni@ietf.org > Subject: Re: WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 2] >=20 > Hi Kevin, >=20 > Thanks for addressing the comments. > Focusing on the remaining open item below: >=20 > > > > One question I have is: > > If the content is both "mandatory-to-enforce" and not "safe-to- > redistribute", > > and the transit CDN doesn't understand/support it, then the transit CD= N > MUST > > instruct the downstream CDN to reject all requests for that content? >=20 > Right. >=20 > > We do not have a defined mechanism for this today. > > Should we define and return a well known auto-reject Metadata object? > > (An HTTP response code seems too heavy handed, e.g., if the dCDN just > > requested all metadata, and only 1 sub-path has a metadata issue.) >=20 >=20 > If the metadata object is both "mandatory-to-enforce" and not "safe-to- > redistribute", then how about we indicate that: > *A* a transit CDN request routing function is expected to attempt to > not redirect request for corresponding content further to downstream CDNs= , > and > *B* a transit CDN CDNI metadata function MUST update the metadata to > add a newly defined "do-not-serve" object that will instruct the dCDN (an= d > we specify somewhere that any cDN that sees that object MUST not serve th= e > content, regardles of what the other metadata says). We need to think > about whetehr we want to leave the initial object that was "mandatory-to- > enforce" and not "safe-to-redistribute" , or wehether it should be remove= d > (on the grounds that it contains non-sensical information since it has no= t > been properly "updated" by the transit CDN). >=20 > I am not sure if *B* is what you also meant. ie the word "return" confuse= d > me, since teh approach I describe above does not return anything new, but > just adds something in the propagated metadata. >=20 > Makes sense? From nobody Tue Mar 11 10:31:41 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 50EBD1A0584 for ; Tue, 11 Mar 2014 10:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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.547, 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 vrxP8btnVKoH for ; Tue, 11 Mar 2014 10:31:38 -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 D17E31A074F for ; Tue, 11 Mar 2014 10:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1770; q=dns/txt; s=iport; t=1394559092; x=1395768692; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=fKgHA59YqWy7TzIA4GRfpcz7rbXTBBnh8ZBA+d9Woq0=; b=Xj4sqnijLvHR0Jbd1y1nVOBVclvsuJc/TrfhXNO5b8xYu4D2nNOUG5ar A3hRb/gv0tO4TxDWx2deFct09eFPBvmA0Zaq04Djb+fi85mT96/p/s/PJ Gc5LGaGe4+vKR9v/nRrhRtvzCDG2gciv43YcbiqWgEhnNGzYakGn0Hjk3 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAO1HH1OtJXG8/2dsb2JhbABagwY7V8JoFnSCLIELAYEAJwSIDKB9k0WdCBeOCIN/gRQEmEWKVodXgW+BPoIr X-IronPort-AV: E=Sophos;i="4.97,632,1389744000"; d="scan'208";a="26610801" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-6.cisco.com with ESMTP; 11 Mar 2014 17:31:31 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2BHVVQ1002399 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 11 Mar 2014 17:31:31 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.151]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Tue, 11 Mar 2014 12:31:31 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: cdni-logging - proposed text for applicability of "cdni_http_request_v1" Record-Type Thread-Index: AQHPPU+9RdJ2TwakBkeVtQfTM5Fdlg== Date: Tue, 11 Mar 2014 17:31:30 +0000 Message-ID: <9A13C730-95F0-4A93-B989-84D8AFDFA9F9@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8A86C2EA182F324989D21C54B26A1692@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/8F1k5tVNEMea1MyaMMIFYiLmpCA Subject: [CDNi] cdni-logging - proposed text for applicability of "cdni_http_request_v1" Record-Type 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, 11 Mar 2014 17:31:39 -0000 Folks, (as a cdni-logging editor) Below is the proposed text to discuss applicability of the "cdni_http_reque= st_v1" Record-Type to HTTP/1.0. HTTP/1.1, HTTP/2.0 and HTTPS, in line with = the approach described in London by Iuniana. Please let us know if you have any comments/suggestions on that. Cheers Francois " 3.4.1. HTTP Request Logging Record This section defines the CDNI Logging Record of Record-Type "cdni_http_request_v1". It is applicable to content delivery performed by the dCDN using HTTP/1.0([RFC1945]), HTTP/1.1([RFC2616]) or HTTPS ([RFC2818]). We observe that, in case of HTTPS delivery, there may be value in logging additional information specific to the operation of HTTP over TLS and we note that this is outside the scope of the present document and may be addressed in a future document defining another CDNI Logging Record or another version of the HTTP Request Logging Record. The "cdni_http_request_v1" Record-Type is also expected to be applicable to HTTP/2.0 ([I-D.ietf-httpbis-http2]) which is still under development at the time of writing the present document, since a fundamental design tenet of HTTP/2.0 is to preserve the HTTP/1.1 semantics. We observe that, in case of HTTP/2.0 delivery, there may be value in logging additional information specific to the additional functionality of HTTP/2.0 and we note that this is outside the scope of the present document and may be addressed in a future document defining another CDNI Logging Record or another version of the HTTP Request Logging Record. The "cdni_http_request_v1" Record-Type contains the following CDNI Logging Fields, listed by their field name: =85 "= From nobody Tue Mar 11 11:16:57 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 721451A0743 for ; Tue, 11 Mar 2014 11:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.448 X-Spam-Level: X-Spam-Status: No, score=-9.448 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_31=0.6, RP_MATCHES_RCVD=-0.547, 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 QO43W6qqknuT for ; Tue, 11 Mar 2014 11:16:50 -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 7D5221A0473 for ; Tue, 11 Mar 2014 11:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3303; q=dns/txt; s=iport; t=1394561805; x=1395771405; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FurG8x1KJxSGxFEWrS0YLCtWERflHcNpXzbvqkaY2N4=; b=A7fkmXXQWHRFznuLrEk+kH2dqcDi7l+Lyb0CKUT5gqB6kceDUqqQLWOP 1lViqzOsyZpsyAUYpg0IH6YjHf4rKhXApGT//EBIAGo6TkD5ZbVcx9zz9 sQ0hJNZMhEOWlHamaGMJ1m25GmTwEpbqnpeLB9btKymFEegWucMmRc/D7 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAHRSH1OtJV2c/2dsb2JhbABagwY7V8FJgSAWdIIlAQEBAwF5BQcEAgEIEQQBASgHMhQJCAIEDgWHcQjRTReOKTMHBoMegRQBA5hFki2DLYIr X-IronPort-AV: E=Sophos;i="4.97,632,1389744000"; d="scan'208";a="26622169" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP; 11 Mar 2014 18:16:44 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2BIGiRM011374 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Mar 2014 18:16:44 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.151]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Tue, 11 Mar 2014 13:16:44 -0500 From: "Francois Le Faucheur (flefauch)" To: Kevin J Ma Thread-Topic: WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 2] Thread-Index: AQHPLyLW+grR8OSmCE+3oXnY+ir15A== Date: Tue, 11 Mar 2014 18:16:43 +0000 Message-ID: <1AA9EE0E-0E50-4481-BBC2-AE8D012F3B6F@cisco.com> References: <20140214214618.22993.11019.idtracker@ietfa.amsl.com> <291CC3F9E50E7641901A54E85D0977C6D542CDC16A@MAILR002.mail.lan> <76DDDCA9-5916-45F6-8620-0FCFE3E0105C@cisco.com> <291CC3F9E50E7641901A54E85D0977C6E7B8597C42@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6E7B8597C42@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] Content-Type: text/plain; charset="Windows-1252" Content-ID: <608DE4DA8FBA864EA025B4DA457B75F6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/ctsojdS8p27ZvjbuuA84cdh7TLk 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, 11 Mar 2014 18:16:53 -0000 On 11 Mar 2014, at 14:17, Kevin J Ma wrote: > Hi Francois, >=20 > "*B*" was precisely what I was thinking, replacing all of the existing > metadata for the Hosts/Paths that had unsupported MtE and non-StR=20 > metadata with a well known do-not-serve metadata object. I will add > that and some additional text for "*A*" unless someone objects? Sounds good. Regarding the "do-not-serve metadata object=94, it may have applicability c= ompletely independently of the "MtE and non-StR=94 situation, eg if an uCDN= wants to explicitely tell dCDN to no longer serve some content on its beha= lf. So we want to define that object in its own right , and then simply spe= cifiy it is to be used in the "MtE and non-StR=94 situation ie we don;t wa= nt to have the "do-not-serve metadata object=94 definition tie to the "MtE = and non-StR=94 situation. I think that is exactly what you meant by "well known=94 but thought it was= worth making that explicit to everyone. Cheers Francois >=20 > thanx! >=20 > -- Kevin J. Ma >=20 >> -----Original Message----- >> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] >> Sent: Tuesday, March 11, 2014 9:07 AM >> To: Kevin J Ma >> Cc: Francois Le Faucheur (flefauch); draft-ietf-cdni- >> metadata@tools.ietf.org; cdni@ietf.org >> Subject: Re: WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 2= ] >>=20 >> Hi Kevin, >>=20 >> Thanks for addressing the comments. >> Focusing on the remaining open item below: >>=20 >>>=20 >>> One question I have is: >>> If the content is both "mandatory-to-enforce" and not "safe-to- >> redistribute", >>> and the transit CDN doesn't understand/support it, then the transit CDN >> MUST >>> instruct the downstream CDN to reject all requests for that content? >>=20 >> Right. >>=20 >>> We do not have a defined mechanism for this today. >>> Should we define and return a well known auto-reject Metadata object? >>> (An HTTP response code seems too heavy handed, e.g., if the dCDN just >>> requested all metadata, and only 1 sub-path has a metadata issue.) >>=20 >>=20 >> If the metadata object is both "mandatory-to-enforce" and not "safe-to- >> redistribute", then how about we indicate that: >> *A* a transit CDN request routing function is expected to attempt to >> not redirect request for corresponding content further to downstream CDN= s, >> and >> *B* a transit CDN CDNI metadata function MUST update the metadata to >> add a newly defined "do-not-serve" object that will instruct the dCDN (a= nd >> we specify somewhere that any cDN that sees that object MUST not serve t= he >> content, regardles of what the other metadata says). We need to think >> about whetehr we want to leave the initial object that was "mandatory-to= - >> enforce" and not "safe-to-redistribute" , or wehether it should be remov= ed >> (on the grounds that it contains non-sensical information since it has n= ot >> been properly "updated" by the transit CDN). >>=20 >> I am not sure if *B* is what you also meant. ie the word "return" confus= ed >> me, since teh approach I describe above does not return anything new, bu= t >> just adds something in the propagated metadata. >>=20 >> Makes sense? From nobody Tue Mar 11 11:20: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 640CF1A07A2 for ; Tue, 11 Mar 2014 11:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 YTabFQ2fz3gX for ; Tue, 11 Mar 2014 11:20:34 -0700 (PDT) Received: from p01c12o142.mxlogic.net (p01c12o142.mxlogic.net [208.65.145.65]) by ietfa.amsl.com (Postfix) with ESMTP id 40AD81A0798 for ; Tue, 11 Mar 2014 11:20:31 -0700 (PDT) Received: from unknown [69.25.75.234] (EHLO HUB023.mail.lan) by p01c12o142.mxlogic.net(mxl_mta-7.2.4-1) with ESMTP id 9e35f135.2aebe220f940.130502.00-494.379292.p01c12o142.mxlogic.net (envelope-from ); Tue, 11 Mar 2014 12:20:25 -0600 (MDT) X-MXL-Hash: 531f53e97161f133-ac7c672b840423fe0ce5fb3214675348e9bd2d2f Received: from unknown [69.25.75.234] (EHLO HUB023.mail.lan) by p01c12o142.mxlogic.net(mxl_mta-7.2.4-1) over TLS secured channel with ESMTP id 3735f135.0.129059.00-208.375078.p01c12o142.mxlogic.net (envelope-from ); Tue, 11 Mar 2014 12:19:37 -0600 (MDT) X-MXL-Hash: 531f53b97b925323-b6e4c4fcf4d1053fb8cc87af4b5df98e562cb1f1 Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Tue, 11 Mar 2014 14:18:27 -0400 From: Kevin J Ma To: "Francois Le Faucheur (flefauch)" Date: Tue, 11 Mar 2014 14:18:24 -0400 Thread-Topic: WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 2] Thread-Index: AQHPLyLW+grR8OSmCE+3oXnY+ir15JrcThmw Message-ID: <291CC3F9E50E7641901A54E85D0977C6E7B8597E6C@MAILR002.mail.lan> References: <20140214214618.22993.11019.idtracker@ietfa.amsl.com> <291CC3F9E50E7641901A54E85D0977C6D542CDC16A@MAILR002.mail.lan> <76DDDCA9-5916-45F6-8620-0FCFE3E0105C@cisco.com> <291CC3F9E50E7641901A54E85D0977C6E7B8597C42@MAILR002.mail.lan> <1AA9EE0E-0E50-4481-BBC2-AE8D012F3B6F@cisco.com> In-Reply-To: <1AA9EE0E-0E50-4481-BBC2-AE8D012F3B6F@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/9Ja6e-ShEtfzMuhsRH6rD2VEBpI 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, 11 Mar 2014 18:20:36 -0000 > I think that is exactly what you meant by "well known" but thought it was > worth making that explicit to everyone. Good clarification. Correct, that's what I meant by "well known". thanx. > -----Original Message----- > From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] > Sent: Tuesday, March 11, 2014 2:17 PM > To: Kevin J Ma > Cc: Francois Le Faucheur (flefauch); draft-ietf-cdni- > metadata@tools.ietf.org; cdni@ietf.org > Subject: Re: WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 2] >=20 >=20 > On 11 Mar 2014, at 14:17, Kevin J Ma wrote: >=20 > > Hi Francois, > > > > "*B*" was precisely what I was thinking, replacing all of the existing > > metadata for the Hosts/Paths that had unsupported MtE and non-StR > > metadata with a well known do-not-serve metadata object. I will add > > that and some additional text for "*A*" unless someone objects? >=20 > Sounds good. > Regarding the "do-not-serve metadata object", it may have applicability > completely independently of the "MtE and non-StR" situation, eg if an uCD= N > wants to explicitely tell dCDN to no longer serve some content on its > behalf. So we want to define that object in its own right , and then > simply specifiy it is to be used in the "MtE and non-StR" situation ie w= e > don;t want to have the "do-not-serve metadata object" definition tie to > the "MtE and non-StR" situation. > I think that is exactly what you meant by "well known" but thought it was > worth making that explicit to everyone. >=20 > Cheers >=20 > Francois >=20 > > > > thanx! > > > > -- Kevin J. Ma > > > >> -----Original Message----- > >> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] > >> Sent: Tuesday, March 11, 2014 9:07 AM > >> To: Kevin J Ma > >> Cc: Francois Le Faucheur (flefauch); draft-ietf-cdni- > >> metadata@tools.ietf.org; cdni@ietf.org > >> Subject: Re: WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch > 2] > >> > >> Hi Kevin, > >> > >> Thanks for addressing the comments. > >> Focusing on the remaining open item below: > >> > >>> > >>> One question I have is: > >>> If the content is both "mandatory-to-enforce" and not "safe-to- > >> redistribute", > >>> and the transit CDN doesn't understand/support it, then the transit > CDN > >> MUST > >>> instruct the downstream CDN to reject all requests for that content? > >> > >> Right. > >> > >>> We do not have a defined mechanism for this today. > >>> Should we define and return a well known auto-reject Metadata object? > >>> (An HTTP response code seems too heavy handed, e.g., if the dCDN just > >>> requested all metadata, and only 1 sub-path has a metadata issue.) > >> > >> > >> If the metadata object is both "mandatory-to-enforce" and not "safe-to= - > >> redistribute", then how about we indicate that: > >> *A* a transit CDN request routing function is expected to attempt to > >> not redirect request for corresponding content further to downstream > CDNs, > >> and > >> *B* a transit CDN CDNI metadata function MUST update the metadata to > >> add a newly defined "do-not-serve" object that will instruct the dCDN > (and > >> we specify somewhere that any cDN that sees that object MUST not serve > the > >> content, regardles of what the other metadata says). We need to think > >> about whetehr we want to leave the initial object that was "mandatory- > to- > >> enforce" and not "safe-to-redistribute" , or wehether it should be > removed > >> (on the grounds that it contains non-sensical information since it has > not > >> been properly "updated" by the transit CDN). > >> > >> I am not sure if *B* is what you also meant. ie the word "return" > confused > >> me, since teh approach I describe above does not return anything new, > but > >> just adds something in the propagated metadata. > >> > >> Makes sense? From nobody Tue Mar 11 11:58: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 323071A07C7 for ; Tue, 11 Mar 2014 11:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 tI83Zk0ofGt1 for ; Tue, 11 Mar 2014 11:58:04 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 91A071A077D for ; Tue, 11 Mar 2014 11:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4673; q=dns/txt; s=iport; t=1394564279; x=1395773879; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=aNyVtbLu+nwk3y0TIm8/MfnSfY884DoGSYsfJIXh5Uc=; b=jzjI9JFOOdeoUra4hJzYQuSFm0il9614XR81bosPFLPmj/5fhEG4CH8Q HDi/wmv78os16+g6+FkMcMHHYMOc6sYucglp/vbRCeP1KSj/FvboomBbP N3k6JOkd9L32JtPph7P0Y8UPDz3W2k2Wje1xq9lU/P5mUaSSzcxQV9Y76 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAFJcH1OtJXG+/2dsb2JhbABagwaBEsFJgSIWdIIseRIBgQAnBA4kh1rRLxeOXIMrgRQEkzmFDJItgy2CKw X-IronPort-AV: E=Sophos;i="4.97,632,1389744000"; d="scan'208";a="309562630" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 11 Mar 2014 18:57:58 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2BIvwPB020857 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Mar 2014 18:57:58 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.151]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Tue, 11 Mar 2014 13:57:58 -0500 From: "Francois Le Faucheur (flefauch)" To: "draft-ietf-cdni-metadata@tools.ietf.org" Thread-Topic: WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 3] Thread-Index: AQHPPVvRuNRYy1ujckGBRpWDAt4DDg== Date: Tue, 11 Mar 2014 18:57:57 +0000 Message-ID: <936509A0-8B78-4134-B0CD-7D29FE403E54@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] Content-Type: text/plain; charset="Windows-1252" Content-ID: <49417ECFA6F01649BBBB4F19D034B290@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/l8PsmEOisT_pJAGHN64eEwPlu7Y Cc: "cdni@ietf.org" Subject: [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: Tue, 11 Mar 2014 18:58:06 -0000 *** 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 metada= ta 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 ad= ditional metadata objects may be defined in the future in separate document= s.=94 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 met= adata objects which may be contained within a GenericMetadata object.=94 I believe that somewhere below in the document, extensibility is discussed = with the notion of how one might define additional objects. Please double c= heck that, and in case it is not clear enough, you could add an explicit no= te to convey that "we expect that additional metadata objects may be define= d in the future in separate documents.=94 *** section 4: =93 as they define the semantics, enforcement options, and serialization ru= les for specific properties.=94 is "serialization rules=94 the right term here? *** 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 mea= n something different, then you need to clarify that. *** 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 th= an 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 PathM= etadata 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 =93inh= eritance=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. *** 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 sect= ion. =20 Again the word property is used in one tittle and not the other. Also, comb= ining 5 consecutive words leaves room for ambiguity (eg is it the object th= at 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 *** section 4.1: " Each of the sub-sections below describe the structural objects defined i= n 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 a= nd Figure 1 to add that PatternMatch object. *** 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 t= his host.=94 So the overview text says the object =93references=94 metadata, and the des= cription 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. From nobody Wed Mar 12 06:52: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 AB9E21A09A3 for ; Wed, 12 Mar 2014 06:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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.547, 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 x5uBuFh3D0ve for ; Wed, 12 Mar 2014 06:52:00 -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 008DD1A0722 for ; Wed, 12 Mar 2014 06:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7080; q=dns/txt; s=iport; t=1394632314; x=1395841914; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=8ss5DBzYmqL0pdUqacyJSpiz2ARjl9dtm5GmPaFixH0=; b=NffJN9nkd8SUGiK22djAwAjnH11InU5uByHaGLbpKG//nhhIdVIuNUEA ByXO/rPyjvWhi09w1rxUqSuChf95WoiWRn8iOQa4kuhzGSbc9rDdaQV0s 3QqiHllElKxr10aWRD1OLkgA0Iw44pNaW6iWb5c/knQDaUblHV1S0A28p k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFACVlIFOtJV2Y/2dsb2JhbABagwY7V8FTgRsWdIIsDlcUEgGBACcEDod+0gIXjXFrgyuBFASUWYNski2DLYIr X-IronPort-AV: E=Sophos;i="4.97,638,1389744000"; d="scan'208";a="26867722" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP; 12 Mar 2014 13:51:53 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2CDprkK030829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Mar 2014 13:51:53 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.151]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Wed, 12 Mar 2014 08:51:53 -0500 From: "Francois Le Faucheur (flefauch)" To: "draft-ietf-cdni-metadata@tools.ietf.org" Thread-Topic: WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 4] Thread-Index: AQHPPfo5FZ9ksOgGXEmnpowH35ksBQ== Date: Wed, 12 Mar 2014 13:51:53 +0000 Message-ID: <5FBAF9F8-8389-431B-95BC-9758273FBDF9@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] Content-Type: text/plain; charset="Windows-1252" Content-ID: <99DED49B93028744AC8496491D2714C9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/3gAIW5aLuPccfOkCcF6kiMJO6H8 Cc: "cdni@ietf.org" Subject: [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, 12 Mar 2014 13:52:04 -0000 (Note: I stopped detailed review at 4.2.4 even if I have a few comments bey= ond that). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D General comments: *** somewhere (probably towards the beginning of the document): Can you make sure the applicability of the metadata defined in this documen= ts 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) *** 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 mandat= ory to implement as an uCDN and as a dCDN. Can you make sure this is covere= d , if not already covered? o there are a few =93must=94 that we may want to replace with alternate phr= ases ( =93needs to=94, =93has to=94, =85) o there are MUSTs in the IANA section (eg 7.1). Based on the conversation w= e had in teh contaxt of cdni-logging, I assume these will be edited out.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Detailed comments: *** 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 th= e order they appear in paths object and then first match applies.=85 up to = you. *** 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 *** 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 availa= ble at request routing time. =93 *** 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? *** section 4.1.7: =93 Property: type Description: CDNI Metadata property object type. Type: String Mandatory-to-Specify: Yes. 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 =93ty= pe=94 and =93value=94 to something like =93generic-metadata-type=94 and "ge= neric-metadata-value=94.=20 Obviously, you'd need to reflect these changes in other places. *** 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 pro= posed change above this could read: "Type: matches the generic-metadata-type of the property above" *** 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 Sect= ion 4.1.7 and their type used in the generic-metadata-type property as defi= ned in section 4.1.7.=20 =93 Let me kow if this is not correct. *** 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 t= hen? Would it be appropriate to state that all the objects MUST be distributed w= ith MtE and StR? can you add a statement about behavior or receipt if recei= ved otherwise? *** 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 al= ways use the first one , unless it does not work? or is dCDN allowed to loa= d balance across multiple sources? should there be a mechanism to control w= hether it is single source + backup or multple sources?=20 *** section 4.2.1.1: Is it really useful to allow multiple endpoints within a source, given it i= s possible to include multiple sources? If you keep multiple endpoints within a source, can you also clarify if the= re is any expected behavior from dCDN across the multiple endpoints (single= or ) *** 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. " ***section 4.2.2.1: I assume that the rules are discussed somewhere in the document (that I hav= e 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 denie= d? * if I have overlapping footprints, which applies? first one? If these rules are not made explicit yet, please add them. *** 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. " *** 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 *** 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/ *** Section 6.4.2.1: OLD: =93 6.4.2.1. JSON Example=94 NEW: " 6.4.2.1. Encoded CDNI Metadata Example=94 *** 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. From nobody Thu Mar 13 03:05:54 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 E17771A09AD for ; Thu, 13 Mar 2014 03:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 V1sVRX5zIvVR for ; Thu, 13 Mar 2014 03:05:49 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1371A099A for ; Thu, 13 Mar 2014 03:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=208; q=dns/txt; s=iport; t=1394705143; x=1395914743; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=bfztwPU+oG0bRpgnDHXZ6L68pmVUjRxKQGjd3V1LA2M=; b=VjUUBzHfNLmODuosFjrg1/ox6n+ur5H9Yy1gpiul6YdaOK9Ic8qca29B 34Y3kDw/4RlVPeNEnBE8Rp5SyZvrrceoKMKAbbo4I6t+t/zXmP2U5Jjit ss3uHp2egOllHhd/7/ZWNH31RVOWf+woZhPj7S99Asgp7AtqLgo3KE9P7 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJuBIVOtJXG8/2dsb2JhbABZgwY7V8J7FnSCLDpRAT5CJwQch3ANomywfBeSB4EUBJhFki2DLYIr X-IronPort-AV: E=Sophos;i="4.97,646,1389744000"; d="scan'208";a="309836504" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 13 Mar 2014 10:05:42 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2DA5gvw012224 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 13 Mar 2014 10:05:42 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.151]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Thu, 13 Mar 2014 05:05:42 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: IETF-89 CDNI WG Draft Minutes available Thread-Index: AQHPPqPKQey/H0RhUUaUISPCX4LsZw== Date: Thu, 13 Mar 2014 10:05:41 +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.196] Content-Type: text/plain; charset="us-ascii" Content-ID: <787E2656CDFE13439318218363667B16@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/8lXbsbZb4AuYIEoxKMS9e-xoCIs Subject: [CDNi] IETF-89 CDNI WG Draft Minutes available 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: Thu, 13 Mar 2014 10:05:51 -0000 Hi, Draft minutes have been uploaded: http://www.ietf.org/proceedings/89/minutes/minutes-89-cdni Please review and comment if needed. Cheers Francois PS: Thanks to Ray for his accurate notes From nobody Thu Mar 13 23:56:55 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 14FF51A0062 for ; Thu, 13 Mar 2014 23:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 P80a6fI4bGpv for ; Thu, 13 Mar 2014 23:56:51 -0700 (PDT) Received: from p01c12o142.mxlogic.net (p01c12o142.mxlogic.net [208.65.145.65]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD461A0059 for ; Thu, 13 Mar 2014 23:56:51 -0700 (PDT) Received: from unknown [69.25.75.234] (EHLO HUB012.mail.lan) by p01c12o142.mxlogic.net(mxl_mta-7.2.4-1) with ESMTP id d28a2235.2b2da7e52940.78425.00-588.208681.p01c12o142.mxlogic.net (envelope-from ); Fri, 14 Mar 2014 00:56:45 -0600 (MDT) X-MXL-Hash: 5322a82d52a1fd18-00e7b77f9dbb35f3b355af21cc044bb0fc3b0503 Received: from unknown [69.25.75.234] (EHLO HUB012.mail.lan) by p01c12o142.mxlogic.net(mxl_mta-7.2.4-1) over TLS secured channel with ESMTP id 608a2235.0.78332.00-363.208459.p01c12o142.mxlogic.net (envelope-from ); Fri, 14 Mar 2014 00:56:07 -0600 (MDT) X-MXL-Hash: 5322a80739ecbc30-9759b49327517f7b073ea293db8783d23ecc0838 Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Fri, 14 Mar 2014 02:55:59 -0400 From: Kevin J Ma To: "Francois Le Faucheur (flefauch)" , "cdni@ietf.org" Date: Fri, 14 Mar 2014 02:54:48 -0400 Thread-Topic: cdni-logging - proposed text for applicability of "cdni_http_request_v1" Record-Type Thread-Index: AQHPPU+9RdJ2TwakBkeVtQfTM5FdlprfxQ3A Message-ID: <291CC3F9E50E7641901A54E85D0977C6E7B85989AB@MAILR002.mail.lan> References: <9A13C730-95F0-4A93-B989-84D8AFDFA9F9@cisco.com> In-Reply-To: <9A13C730-95F0-4A93-B989-84D8AFDFA9F9@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/B1iLwuc5nZqDuY-_8_okTVMFPVU Subject: Re: [CDNi] cdni-logging - proposed text for applicability of "cdni_http_request_v1" Record-Type 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, 14 Mar 2014 06:56:53 -0000 Hi Francois, The text looks good to me. One nit: I would change the two cases of "in case of" -> "in the case of"= . thanx. -- Kevin J. Ma > -----Original Message----- > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le > Faucheur (flefauch) > Sent: Tuesday, March 11, 2014 1:32 PM > To: cdni@ietf.org > Subject: [CDNi] cdni-logging - proposed text for applicability of > "cdni_http_request_v1" Record-Type >=20 > Folks, >=20 > (as a cdni-logging editor) >=20 > Below is the proposed text to discuss applicability of the > "cdni_http_request_v1" Record-Type to HTTP/1.0. HTTP/1.1, HTTP/2.0 and > HTTPS, in line with the approach described in London by Iuniana. > Please let us know if you have any comments/suggestions on that. >=20 > Cheers >=20 > Francois >=20 >=20 > " > 3.4.1. HTTP Request Logging Record >=20 > This section defines the CDNI Logging Record of Record-Type > "cdni_http_request_v1". It is applicable to content delivery > performed by the dCDN using HTTP/1.0([RFC1945]), HTTP/1.1([RFC2616]) > or HTTPS ([RFC2818]). We observe that, in case of HTTPS delivery, > there may be value in logging additional information specific to the > operation of HTTP over TLS and we note that this is outside the scope > of the present document and may be addressed in a future document > defining another CDNI Logging Record or another version of the HTTP > Request Logging Record. >=20 > The "cdni_http_request_v1" Record-Type is also expected to be > applicable to HTTP/2.0 ([I-D.ietf-httpbis-http2]) which is still > under development at the time of writing the present document, since > a fundamental design tenet of HTTP/2.0 is to preserve the HTTP/1.1 > semantics. We observe that, in case of HTTP/2.0 delivery, there may > be value in logging additional information specific to the additional > functionality of HTTP/2.0 and we note that this is outside the scope > of the present document and may be addressed in a future document > defining another CDNI Logging Record or another version of the HTTP > Request Logging Record. >=20 > The "cdni_http_request_v1" Record-Type contains the following CDNI > Logging Fields, listed by their field name: > ... > " > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Fri Mar 14 07:45:06 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 C15991A015B for ; Fri, 14 Mar 2014 07:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 b-9dtEAThCJo for ; Fri, 14 Mar 2014 07:45:00 -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 A664D1A0154 for ; Fri, 14 Mar 2014 07:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2629; q=dns/txt; s=iport; t=1394808294; x=1396017894; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3uhuxPOAc+8AngugE9fK+Z9zHS3UBU9h8SqNKjnI0yQ=; b=kqrP3ThnjpOgRDiL4WttJO8IwlFd8LtRHw9bZ6472H7tbZw1VkcXHoe2 zEYktk2n3wRNVs3uDAMDaoo6Q63GMok+K0krj4lDq4Pl4vKx6IK4uSPNZ sBc4tk7ehSrJfbhc3vl1cqAmg6lc/fKr9xifujCu1P77yfHtyeJNutzPj E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAEgVI1OtJV2b/2dsb2JhbABZgwY7V7pChzCBFxZ0giUBAQEDAQEBASRHCwUHBAIBCBEEAQEoBycLFAkIAgQOBYdxCA21SZ4WEwSOEyEzBwaDHoEUAQOYRYpXh1eBb4E+gis X-IronPort-AV: E=Sophos;i="4.97,655,1389744000"; d="scan'208";a="310375447" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 14 Mar 2014 14:44:53 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2EEirRU016560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Mar 2014 14:44:53 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.151]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Fri, 14 Mar 2014 09:44:53 -0500 From: "Francois Le Faucheur (flefauch)" To: Kevin J Ma Thread-Topic: cdni-logging - proposed text for applicability of "cdni_http_request_v1" Record-Type Thread-Index: AQHPPU+9RdJ2TwakBkeVtQfTM5FdlprfxQ3AgAE8DwA= Date: Fri, 14 Mar 2014 14:44:52 +0000 Message-ID: <41A65FF5-A39F-4875-889D-522D87E795DB@cisco.com> References: <9A13C730-95F0-4A93-B989-84D8AFDFA9F9@cisco.com> <291CC3F9E50E7641901A54E85D0977C6E7B85989AB@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6E7B85989AB@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.52] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2099FD722DB03D4CA04DA5A431C280EC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/HPY01HM-DR3C65dDVJKpjUMf2FI Cc: "cdni@ietf.org" Subject: Re: [CDNi] cdni-logging - proposed text for applicability of "cdni_http_request_v1" Record-Type 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, 14 Mar 2014 14:45:04 -0000 On 14 Mar 2014, at 07:54, Kevin J Ma wrote: > Hi Francois, >=20 > The text looks good to me. Great. > One nit: I would change the two cases of "in case of" -> "in the case of= =94. Fixed. Thanks >=20 > thanx. >=20 > -- Kevin J. Ma >=20 >> -----Original Message----- >> From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le >> Faucheur (flefauch) >> Sent: Tuesday, March 11, 2014 1:32 PM >> To: cdni@ietf.org >> Subject: [CDNi] cdni-logging - proposed text for applicability of >> "cdni_http_request_v1" Record-Type >>=20 >> Folks, >>=20 >> (as a cdni-logging editor) >>=20 >> Below is the proposed text to discuss applicability of the >> "cdni_http_request_v1" Record-Type to HTTP/1.0. HTTP/1.1, HTTP/2.0 and >> HTTPS, in line with the approach described in London by Iuniana. >> Please let us know if you have any comments/suggestions on that. >>=20 >> Cheers >>=20 >> Francois >>=20 >>=20 >> " >> 3.4.1. HTTP Request Logging Record >>=20 >> This section defines the CDNI Logging Record of Record-Type >> "cdni_http_request_v1". It is applicable to content delivery >> performed by the dCDN using HTTP/1.0([RFC1945]), HTTP/1.1([RFC2616]) >> or HTTPS ([RFC2818]). We observe that, in case of HTTPS delivery, >> there may be value in logging additional information specific to the >> operation of HTTP over TLS and we note that this is outside the scope >> of the present document and may be addressed in a future document >> defining another CDNI Logging Record or another version of the HTTP >> Request Logging Record. >>=20 >> The "cdni_http_request_v1" Record-Type is also expected to be >> applicable to HTTP/2.0 ([I-D.ietf-httpbis-http2]) which is still >> under development at the time of writing the present document, since >> a fundamental design tenet of HTTP/2.0 is to preserve the HTTP/1.1 >> semantics. We observe that, in case of HTTP/2.0 delivery, there may >> be value in logging additional information specific to the additional >> functionality of HTTP/2.0 and we note that this is outside the scope >> of the present document and may be addressed in a future document >> defining another CDNI Logging Record or another version of the HTTP >> Request Logging Record. >>=20 >> The "cdni_http_request_v1" Record-Type contains the following CDNI >> Logging Fields, listed by their field name: >> ... >> " >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni From nobody Mon Mar 17 06:36: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 0DF421A03DD for ; Mon, 17 Mar 2014 06:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 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, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 U_nN-sVuiO46 for ; Mon, 17 Mar 2014 06:36:27 -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 86DA31A0248 for ; Mon, 17 Mar 2014 06:36:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8486; q=dns/txt; s=iport; t=1395063380; x=1396272980; h=from:to:subject:date:message-id:references:mime-version; bh=6HaOn++Fo1AXpPxkxHfeF034CuQ3az4D+PZrTlvHN+k=; b=Y72jt1omOeYUi1xasH7z7Pe9YhmaavZ0xbOXCHE9CtQGuwy1JUzW1pXt WSjhEmA/9f4TMqDU185IQD/5jiEpy478dNx4yV+b3kR7izNsZZ2UCGuTF 7p/ef5VVOfW48l4M8p5p3BJK6RLwdTyXppDC2kepPw5Mk4VOvvIfK4ii8 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAJ/5JlOtJXG+/2dsb2JhbABZgwY7V8IBgRgWdIIlAQEBBIEJAgEZAwECJAQHIREUBwIIAgQTh2UDEcsmDYcvF4xQggcXB4MegRQEiRqLQIF/gW2MZ4VIgW+BPoIr X-IronPort-AV: E=Sophos;i="4.97,670,1389744000"; d="scan'208,217";a="310896422" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 17 Mar 2014 13:36:19 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2HDaJnt023389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 17 Mar 2014 13:36:19 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.151]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Mon, 17 Mar 2014 08:36:19 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Last Call: (Framework for CDN Interconnection) to Informational RFC Thread-Index: AQHPP1NslSiFquNebUq01Cfc0Jifsg== Date: Mon, 17 Mar 2014 13:36:18 +0000 Message-ID: <8B9D8F0A-BCE6-4CB8-BFCE-1495067A8587@cisco.com> References: <6.2.5.6.2.20140313215236.0c4d7210@elandnews.com> 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_8B9D8F0ABCE64CB8BFCE1495067A8587ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/0hg5D0AmoUQ-roEelYHQ5OjmPqw Subject: [CDNi] Fwd: Last Call: (Framework for CDN Interconnection) to Informational RFC 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, 17 Mar 2014 13:36:30 -0000 --_000_8B9D8F0ABCE64CB8BFCE1495067A8587ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just forwarding this message to the list (since it got blocked by Mailer by= error). Begin forwarded message: Resent-From: > From: S Moonesamy > Subject: Re: Last Call: (Framework for C= DN Interconnection) to Informational RFC Date: 14 March 2014 06:19:16 CET Resent-To: >, >, >, >, >, > To: "Brandenburg, R. (Ray) van" >, > Cc: > Hi Ray, At 08:39 06-03-2014, Brandenburg, R. (Ray) van wrote: You=B9re right that the document mentions DNS, however, I=B9m not sure that warrants an (informative) reference to a DNS specification. Do you have a specific DNS spec in mind that you would like to see referenced? I would not describe the issue as being about references. It is about what= existing material has to be covered if a specification is building on prev= ious IETF specifications. In this case the proponents of the specification= would have gone through RFC 1035 In order to understand the meaning of the sentence, I think it=B9s helpful to clarify the fact that we=B9re talking about a DNS server in the Downstream CDN, hence the term downstream DNS server. I=B9m a not sure whether recursive name server would cover the meaning as well. How about DNS responses are cached by servers in the dCDN? Thanks for the explanation. From an outsider's point of view it is only us= eful to know what type of name server the client is interacting with. What= happens the background, i.e. the CDN part, is not important. Saying that = "DNS responses are cached by servers" does not provide that information. Again, our intention is not to hint at a preferred choice between HTTP or DNS, or to lead (let alone mislead) the reader in any direction. I will try to rephrase the paragraph to remove any words that might sound as such. Sorry for the "mislead". I chose the word quickly. The point is that you = know how all this works. The average reader (who has not participated in t= he working group) might read that as a choice. Regards, S. Moonesamy --_000_8B9D8F0ABCE64CB8BFCE1495067A8587ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <5F315545CE1BA245B85DE182F64C2888@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Just forwarding this message to the list (since it got blocked by Mailer by= error).


Begin forwarded message:

From:= S Moonesamy <sm+ietf@elandsys.com>
Subje= ct: Re: Last Call: <draft= -ietf-cdni-framework-10.txt> (Framework for CDN Interconnection) to Info= rmational RFC
Date:= 14 March 2014 06:19:16= CET
To: <= /b>"Brandenburg, R. (R= ay) van" <ray.vanbrand= enburg@tno.nl>, <draft-ietf-cdni-framework.all@tools.ietf.org>
Cc: <= /b><cdni@ietf.org>

Hi Ray,
At 08:39 06-03-2014, Brandenburg, R. (Ray) van wrote:
You=B9re right that the document mentions DNS, ho= wever, I=B9m not sure that
warrants an (informative) reference to a DNS specification. Do you have a specific DNS spec in mind that you would like to see referenced?

I would not describe the issue as being about references.  It is about= what existing material has to be covered if a specification is building on= previous IETF specifications.  In this case the proponents of the spe= cification would have gone through RFC 1035

In order to understand the meaning of the sentenc= e, I think it=B9s helpful
to clarify the fact that we=B9re talking about a DNS server in the
Downstream CDN, hence the term downstream DNS server. I=B9m a not sure
whether recursive name server would cover the meaning as well. How about DNS responses are cached by servers in the dCDN?

Thanks for the explanation.  From an outsider's point of view it is on= ly useful to know what type of name server the client is interacting with. =  What happens the background, i.e. the CDN part, is not important. &nb= sp;Saying that "DNS responses are cached by servers" does not provide that information.

Again, our intention is not to hint at a preferre= d choice between HTTP
or DNS, or to lead (let alone mislead) the reader in any direction. I
will try to rephrase the paragraph to remove any words that might sound as<= br> such.

Sorry for the "mislead".  I chose the word quickly.  Th= e point is that you know how all this works.  The average reader (who = has not participated in the working group) might read that as a choice.

Regards,
S. Moonesamy

--_000_8B9D8F0ABCE64CB8BFCE1495067A8587ciscocom_-- From nobody Mon Mar 17 07:52:59 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 9FA8F1A0415 for ; Mon, 17 Mar 2014 07:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.047 X-Spam-Level: X-Spam-Status: No, score=-10.047 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.547, 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 28BYKLyJKVfH for ; Mon, 17 Mar 2014 07:52:53 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 799341A014D for ; Mon, 17 Mar 2014 07:52:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8907; q=dns/txt; s=iport; t=1395067965; x=1396277565; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=0GrRuENawdfN6lrw2kbxpu1S5MFL0tWhoblD6zasnlo=; b=EMoq+lAUF7U8/AQlomQQsHEoSgd9e9c9EzFSbI6vG84JEbIFNaBvTctQ SNAi8xObsTEFjdRWJJzGkGSUPndNBDly8BIAfKGB3OW09HYTW1wAo9v6S a4nkOdwND765LQeJId+6k4aYBwHywtxgYxrOo4n5Yu7/iJMF9tOBHDGLO s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAGgLJ1OtJV2b/2dsb2JhbABZgwY7V7pRhzCBGRZ0giUBAQEEAQEBJEcXBAIBCBEEAQEoBycLFAkIAgQTh3kNtGSdURMEjhRbBoMegRQEmEaKWIdXgW+BPoIr X-IronPort-AV: E=Sophos; i="4.97,670,1389744000"; d="scan'208,217"; a="28054813" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP; 17 Mar 2014 14:52:45 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2HEqjVB004302 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 17 Mar 2014 14:52:45 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.151]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Mon, 17 Mar 2014 09:52:44 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: cdni-logging - proposed text for applicability of "cdni_http_request_v1" Record-Type Thread-Index: AQHPPU+9RdJ2TwakBkeVtQfTM5Fdlg== Date: Mon, 17 Mar 2014 14:52:43 +0000 Message-ID: References: <9A13C730-95F0-4A93-B989-84D8AFDFA9F9@cisco.com> <291CC3F9E50E7641901A54E85D0977C6E7B85989AB@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6E7B85989AB@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.199] Content-Type: multipart/alternative; boundary="_000_E1C86E8BF3F044B3B0A3BD031657EE51ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/PUopThSF0pDvKMY96pUTx6Sb1vk Subject: Re: [CDNi] cdni-logging - proposed text for applicability of "cdni_http_request_v1" Record-Type 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, 17 Mar 2014 14:52:56 -0000 --_000_E1C86E8BF3F044B3B0A3BD031657EE51ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Folks, We received a suggestion to include examples of additional things that migh= t be nice to log for HTTP/2.0 in future CDNI Logging Records, so we=92d twe= aked the HTTP/2.0 paragraph into: " The "cdni_http_request_v1" Record-Type is also expected to be applicable to HTTP/2.0 [I-D.ietf-httpbis-http2] (which is still under development at the time of writing the present document) since a fundamental design tenet of HTTP/2.0 is to preserve the HTTP/1.1 semantics. We observe that, in the case of HTTP/2.0 delivery, there may be value in logging additional information specific to the additional functionality of HTTP/2.0 (e.g. information related to connection identification, to stream identification, to stream priority and to flow control). We note that such additional information is outside the scope of the present document and may be addressed in a future document defining another CDNI Logging Record or another version of the HTTP Request Logging Record. =93 Let us know if you have comments. Cheers Francois On 14 Mar 2014, at 07:54, Kevin J Ma > wrote: Hi Francois, The text looks good to me. One nit: I would change the two cases of "in case of" -> "in the case of". thanx. -- Kevin J. Ma -----Original Message----- From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le Faucheur (flefauch) Sent: Tuesday, March 11, 2014 1:32 PM To: cdni@ietf.org Subject: [CDNi] cdni-logging - proposed text for applicability of "cdni_http_request_v1" Record-Type Folks, (as a cdni-logging editor) Below is the proposed text to discuss applicability of the "cdni_http_request_v1" Record-Type to HTTP/1.0. HTTP/1.1, HTTP/2.0 and HTTPS, in line with the approach described in London by Iuniana. Please let us know if you have any comments/suggestions on that. Cheers Francois " 3.4.1. HTTP Request Logging Record This section defines the CDNI Logging Record of Record-Type "cdni_http_request_v1". It is applicable to content delivery performed by the dCDN using HTTP/1.0([RFC1945]), HTTP/1.1([RFC2616]) or HTTPS ([RFC2818]). We observe that, in case of HTTPS delivery, there may be value in logging additional information specific to the operation of HTTP over TLS and we note that this is outside the scope of the present document and may be addressed in a future document defining another CDNI Logging Record or another version of the HTTP Request Logging Record. The "cdni_http_request_v1" Record-Type is also expected to be applicable to HTTP/2.0 ([I-D.ietf-httpbis-http2]) which is still under development at the time of writing the present document, since a fundamental design tenet of HTTP/2.0 is to preserve the HTTP/1.1 semantics. We observe that, in case of HTTP/2.0 delivery, there may be value in logging additional information specific to the additional functionality of HTTP/2.0 and we note that this is outside the scope of the present document and may be addressed in a future document defining another CDNI Logging Record or another version of the HTTP Request Logging Record. The "cdni_http_request_v1" Record-Type contains the following CDNI Logging Fields, listed by their field name: ... " _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_E1C86E8BF3F044B3B0A3BD031657EE51ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Folks, 

We received a suggestion to include examples of additional things that= might be nice to log for HTTP/2.0 in future CDNI Logging Records, so we=92= d tweaked the HTTP/2.0 paragraph into:
"
   The "cdni_http_request_v1&quo=
t; Record-Type is also expected to be
   applicable to HTTP/2.0 [I-D.ietf-httpbis-http2] (which is still under
   development at the time of writing the present document) since a
   fundamental design tenet of HTTP/2.0 is to preserve the HTTP/1.1
   semantics.  We observe that, in the case of HTTP/2.0 delivery, there
   may be value in logging additional information specific to the
   additional functionality of HTTP/2.0 (e.g. information related to
   connection identification, to stream identification, to stream
   priority and to flow control).  We note that such additional
   information is outside the scope of the present document and may be
   addressed in a future document defining another CDNI Logging Record
   or another version of the HTTP Request Logging Record.
=93
Let us know if you have comments.

Cheers

Francois



On 14 Mar 2014, at 07:54, Kevin J Ma <kevin.ma@azukisystems.com> wrote:

Hi Francois,

 The text looks good to me.
 One nit: I would change the two cases of "in case of" ->= "in the case of".

thanx.

--  Kevin J. Ma

-----Original Message-----
From: CDNi [mailto:cdni-bounces@ie= tf.org] On Behalf Of Francois Le
Faucheur (flefauch)
Sent: Tuesday, March 11, 2014 1:32 PM
To: cdni@ietf.org
Subject: [CDNi] cdni-logging - proposed text for applicability of
"cdni_http_request_v1" Record-Type

Folks,

(as a cdni-logging editor)

Below is the proposed text to discuss applicability of the
"cdni_http_request_v1" Record-Type to HTTP/1.0. HTTP/1.1, HTTP/2.= 0 and
HTTPS, in line with the approach described in London by Iuniana.
Please let us know if you have any comments/suggestions on that.

Cheers

Francois


"
3.4.1.  HTTP Request Logging Record

  This section defines the CDNI Logging Record of Record-Type
  "cdni_http_request_v1".  It is applicable to con= tent delivery
  performed by the dCDN using HTTP/1.0([RFC1945]), HTTP/1.1([RFC2= 616])
  or HTTPS ([RFC2818]).  We observe that, in case of HTTPS d= elivery,
  there may be value in logging additional information specific t= o the
  operation of HTTP over TLS and we note that this is outside the= scope
  of the present document and may be addressed in a future docume= nt
  defining another CDNI Logging Record or another version of the = HTTP
  Request Logging Record.

  The "cdni_http_request_v1" Record-Type is also expect= ed to be
  applicable to HTTP/2.0 ([I-D.ietf-httpbis-http2]) which is stil= l
  under development at the time of writing the present document, = since
  a fundamental design tenet of HTTP/2.0 is to preserve the HTTP/= 1.1
  semantics.  We observe that, in case of HTTP/2.0 delivery,= there may
  be value in logging additional information specific to the addi= tional
  functionality of HTTP/2.0 and we note that this is outside the = scope
  of the present document and may be addressed in a future docume= nt
  defining another CDNI Logging Record or another version of the = HTTP
  Request Logging Record.

  The "cdni_http_request_v1" Record-Type contains the f= ollowing CDNI
  Logging Fields, listed by their field name:
 ...
"
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

--_000_E1C86E8BF3F044B3B0A3BD031657EE51ciscocom_-- From nobody Thu Mar 20 07:32:36 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 34C6F1A03FD for ; Thu, 20 Mar 2014 07:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.047 X-Spam-Level: X-Spam-Status: No, score=-10.047 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.547, 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 EyMDxfkha0V0 for ; Thu, 20 Mar 2014 07:32:33 -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 CA3D51A03CA for ; Thu, 20 Mar 2014 07:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5346; q=dns/txt; s=iport; t=1395325944; x=1396535544; h=from:to:cc:subject:date:message-id:mime-version; bh=i5Yhi++M9gnKKM6Uh/gkPqCbGqoYL8cgcpZa0w9WE/s=; b=QuLYwUu/n6NN9ktjofKAcl75NONVNdlrkAxCvpDQcFcntVAM12YpYqF1 HN3GjH2+IPKKDK3mIN7j7NS7MgNL5RbRymDCWfTtwM6IeYVw6wJWadY/y T3G5dEOzonq0Wn//p1cyIHN612ZlMu27cUYf9p/gHf/rLJXz9AkwVnFsY Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEFAKT7KlOtJV2Z/2dsb2JhbABZgwY7V7ldiHGBGBZ0gix5EgEMdCcEDod+Dc9SF45lgyuBFASYR4EykH6DLYIr X-IronPort-AV: E=Sophos; i="4.97,695,1389744000"; d="scan'208,217"; a="29003784" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP; 20 Mar 2014 14:32:23 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2KEWNRx013068 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Mar 2014 14:32:23 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.233]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Thu, 20 Mar 2014 09:32:23 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: draft text re TLS cipher suites (for cdni-logging and other cdni interfaces) Thread-Index: AQHPREk0Mmr5obthYE6g5XE65CEH3Q== Date: Thu, 20 Mar 2014 14:32:22 +0000 Message-ID: <65877168-CBC6-4D3B-91E5-8437F6EECD2F@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.96.157] Content-Type: multipart/alternative; boundary="_000_65877168CBC64D3B91E58437F6EECD2Fciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/OtiPwKfGJ_W3WojzSE67y9xF3eQ Subject: [CDNi] draft text re TLS cipher suites (for cdni-logging and other cdni interfaces) 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: Thu, 20 Mar 2014 14:32:35 -0000 --_000_65877168CBC64D3B91E58437F6EECD2Fciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Folks, Here is the draft text proposed by Jan (with input from Jon, and small edit= orial enhancements from me) for inclusion in cdni-logging: =93 A CDNI Logging implementation MUST support the TLS_DHE_RSA_WITH_AES_128_GCM= _SHA256 cipher suite [RFC5288]. A CDNI Logging implementation SHOULD favor = cipher suites which support perfect forward secrecy over non-perfect forwar= d secrecy cipher suites. =94 Please review and comment if needed. A few additional points: * the statements around TLS and cipher suites discussed here in the context= of cdni-logging are expected to apply to all the CDNI interfaces (unless t= here is some specific reason to do otherwise for a given interface) * there is no final position on this from IESG yet. So we may have to adapt= the text based on IESG review. * Jan identified that the rtcweb group has been looking at the same questio= n ( "http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-09=94 secti= on 5.5) and used their draft text and approach (ie RTCWEB decided not to re= quire the use of PFS, but to say that if both sides support it, it should b= e used) as a basis. Cheers Francois PS: For memory, here is an excerpt fom the IETF-89 meeting minutes where TL= S cipher suites were discussed: " Spencer Dawkins: IESG currently looking at cipher suites and perfect forwar= d secrecy. No formal decision yet about whether specifying cipher suites is= mandatory for drafts. Jan S.: Once IESG is done, I=92m willing to help with updating draft to ref= lect outcome. Rob Murray: Will we have the same discussion for other interfaces as well? = Maybe have transport in separate draft? Daryl M.: Don=92t think that=92s a good idea. Jan, could you help with reco= mmendation while we wait for IESG (i.e. send proposed text for that to auth= ors)? Jan S.: Ok. Spencer D.: Most important thing right now is that you=92ve thought about i= t. Fact that we=92re having this discussion is a good sign. =93 --_000_65877168CBC64D3B91E58437F6EECD2Fciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Folks,

Here is the draft text proposed by Jan (with input from Jon, and small= editorial enhancements from me) for inclusion in cdni-logging:
=93
A CDNI Logging implementation MUST support the TLS_DHE_RSA_WITH_AES= _128_GCM_SHA256 cipher suite [RFC5288]. A CDNI Logging implementation SHOUL= D favor cipher suites which support perfect forward secrecy over non-perfec= t forward secrecy cipher suites.
=94

Please review and comment if needed.

A few additional points:
* the = statements around TLS and cipher suites discussed here in the context of cd= ni-logging are expected to apply to all the CDNI interfaces (unless there i= s some specific reason to do otherwise for a given interface)
* ther= e is no final position on this from IESG yet. So we may have to adapt the t= ext based on IESG review.
* Jan = identified that the rtcweb group has been looking at the same question (&nb= sp;"http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-09= =94 section 5.5) and used their draft text and approach (ie RTCWEB decided not= to require the use of PFS, but to say that if both sides support it, it sh= ould be used) as a basis. 


Cheers

Francois

PS: For memory, here is an excerpt fom the IETF-89 meeting minutes whe= re TLS cipher suites were discussed: 
"
Spencer Dawkins: IESG currently looking at cipher suites and perfect f= orward secrecy. No formal decision yet about whether specifying cipher suit= es is mandatory for drafts. 
Jan S.: Once IESG is done, I=92m willing to help with updating draft to ref= lect outcome.
Rob Murray: Will we have the same discussion for other interfaces as well? = Maybe have transport in separate draft?
Daryl M.: Don=92t think that=92s a good idea. Jan, could you help with reco= mmendation while we wait for IESG (i.e. send proposed text for that to = ;authors)?
Jan S.: Ok. 
Spencer D.: Most important thing right now is that you=92ve thought about i= t. Fact that we=92re having this discussion is a good sign. 
=93
--_000_65877168CBC64D3B91E58437F6EECD2Fciscocom_-- From nobody Thu Mar 20 08: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 6EF741A0782 for ; Thu, 20 Mar 2014 08:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 QijkfMniNkdZ for ; Thu, 20 Mar 2014 08:40:25 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id E34DD1A076C for ; Thu, 20 Mar 2014 08:40:24 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 0DC5532443A; Thu, 20 Mar 2014 16:40:15 +0100 (CET) Received: from pmexch31.intranet-paris.francetelecom.fr (unknown [10.100.76.21]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id DC782238059; Thu, 20 Mar 2014 16:40:14 +0100 (CET) Received: from PMEXCB1D.intranet-paris.francetelecom.fr ([10.100.76.12]) by pmexch31.intranet-paris.francetelecom.fr ([10.100.76.21]) with mapi; Thu, 20 Mar 2014 16:40:14 +0100 From: To: "Francois Le Faucheur (flefauch)" , "cdni@ietf.org" Date: Thu, 20 Mar 2014 16:40:13 +0100 Thread-Topic: draft text re TLS cipher suites (for cdni-logging and other cdni interfaces) Thread-Index: AQHPREk0Mmr5obthYE6g5XE65CEH3ZrqDasw Message-ID: <27392_1395330014_532B0BDE_27392_671_1_8F0D2F5E4AAB7249BC7339A3E944DEDD227D680A79@PMEXCB1D.intranet-paris.francetelecom.fr> References: <65877168-CBC6-4D3B-91E5-8437F6EECD2F@cisco.com> In-Reply-To: <65877168-CBC6-4D3B-91E5-8437F6EECD2F@cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_8F0D2F5E4AAB7249BC7339A3E944DEDD227D680A79PMEXCB1Dintra_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/6kMIcf462UGQLPGTMU8mBez5v90 Subject: Re: [CDNi] draft text re TLS cipher suites (for cdni-logging and other cdni interfaces) 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: Thu, 20 Mar 2014 15:40:28 -0000 --_000_8F0D2F5E4AAB7249BC7339A3E944DEDD227D680A79PMEXCB1Dintra_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all, I would have phrased it as "A CDNI Logging implementation MUST support the = TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite [RFC5288]. An implementati= on of the CDNI Logging Interface SHOULD prefer cipher suites which support = perfect forward secrecy over cipher suites that don't." My 2 eurocents... -- iuniana De : CDNi [mailto:cdni-bounces@ietf.org] De la part de Francois Le Faucheur= (flefauch) Envoy=E9 : jeudi 20 mars 2014 15:32 =C0 : cdni@ietf.org Objet : [CDNi] draft text re TLS cipher suites (for cdni-logging and other = cdni interfaces) Folks, Here is the draft text proposed by Jan (with input from Jon, and small edit= orial enhancements from me) for inclusion in cdni-logging: " A CDNI Logging implementation MUST support the TLS_DHE_RSA_WITH_AES_128_GCM= _SHA256 cipher suite [RFC5288]. A CDNI Logging implementation SHOULD favor = cipher suites which support perfect forward secrecy over non-perfect forwar= d secrecy cipher suites. " Please review and comment if needed. A few additional points: * the statements around TLS and cipher suites discussed here in the context= of cdni-logging are expected to apply to all the CDNI interfaces (unless t= here is some specific reason to do otherwise for a given interface) * there is no final position on this from IESG yet. So we may have to adapt= the text based on IESG review. * Jan identified that the rtcweb group has been looking at the same questio= n ( "http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-09" section= 5.5) and used their draft text and approach (ie RTCWEB decided not to requ= ire the use of PFS, but to say that if both sides support it, it should be = used) as a basis. Cheers Francois PS: For memory, here is an excerpt fom the IETF-89 meeting minutes where TL= S cipher suites were discussed: " Spencer Dawkins: IESG currently looking at cipher suites and perfect forwar= d secrecy. No formal decision yet about whether specifying cipher suites is= mandatory for drafts. Jan S.: Once IESG is done, I'm willing to help with updating draft to refle= ct outcome. Rob Murray: Will we have the same discussion for other interfaces as well? = Maybe have transport in separate draft? Daryl M.: Don't think that's a good idea. Jan, could you help with recommen= dation while we wait for IESG (i.e. send proposed text for that to authors)? Jan S.: Ok. Spencer D.: Most important thing right now is that you've thought about it.= Fact that we're having this discussion is a good sign. " ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_8F0D2F5E4AAB7249BC7339A3E944DEDD227D680A79PMEXCB1Dintra_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello all,

=  

I wo= uld have phrased it as “A CDNI Logging i= mplementation MUST support the TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 cipher s= uite [RFC5288]. An implementation of the CDNI Logging Interface SHOULD pref= er cipher suites which support perfect forward secrecy over cipher suites t= hat don’t.”

 

My 2 euroc= ents…

-= - iuniana

 

De : CDNi [mailto:cdni-bounces= @ietf.org] De la part de Francois Le Faucheur (flefauch)
Envoy= =E9 : jeudi 20 mars 2014 15:32
=C0 : cdni@ietf.org<= br>Objet : [CDNi] draft text re TLS cipher suites (for cdni-log= ging and other cdni interfaces)

 

Folks,

=

 

Here is the draft = text proposed by Jan (with input from Jon, and small editorial enhancements= from me) for inclusion in cdni-logging:

“

=

A CDNI Logging impleme= ntation MUST support the TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite [= RFC5288]. A CDNI Logging implementation SHOULD favor cipher suites which su= pport perfect forward secrecy over non-perfect forward secrecy cipher = suites.

”

 

Please review and comment if needed.<= /p>

 =

A fe= w additional points:

* the statements around TLS and cipher suites discusse= d here in the context of cdni-logging are expected to apply to all the CDNI= interfaces (unless there is some specific reason to do otherwise for a giv= en interface)

* there is no final position on this from IESG yet. So we may= have to adapt the text based on IESG review.

* Jan identified that the rtc= web group has been looking at the same question ( "http://tools.ie= tf.org/html/draft-ietf-rtcweb-security-arch-09” section 5.5) and = used their draft text and approach (ie RTCWEB decided not to require the us= e of PFS, but to say that if both sides support it, it should be used) as a= basis. 

 

 

Cheers

 

Francois

 

PS: For memo= ry, here is an excerpt fom the IETF-89 meeting minutes where TLS cipher sui= tes were discussed: 

"

Spencer Dawkins: IESG currently looking at= cipher suites and perfect forward secrecy. No formal decision yet about wh= ether specifying cipher suites is mandatory for drafts. 
Jan S= .: Once IESG is done, I’m willing to help with updating draft to refl= ect outcome.
Rob Murray: Will we have the same discussion for other inte= rfaces as well? Maybe have transport in separate draft?
Daryl M.: Don= 217;t think that’s a good idea. Jan, could you help with recommendati= on while we wait for IESG (i.e. send proposed text for that to authors= )?
Jan S.: Ok. 
Spencer D.: Most important thing right now is th= at you’ve thought about it. Fact that we’re having this discuss= ion is a good sign. 

“

____=
___________________________________________________________________________=
__________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
= --_000_8F0D2F5E4AAB7249BC7339A3E944DEDD227D680A79PMEXCB1Dintra_-- From nobody Thu Mar 20 11:34: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 E4D191A0720 for ; Thu, 20 Mar 2014 11:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.748 X-Spam-Level: X-Spam-Status: No, score=-12.748 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, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 l6i2woK6K2X8 for ; Thu, 20 Mar 2014 11:34:10 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 139781A06E1 for ; Thu, 20 Mar 2014 11:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14555; q=dns/txt; s=iport; t=1395340441; x=1396550041; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=bDdSP2rd3oOQOEU8VuBTDZygOuxa41zEJZowICvjaU8=; b=k6gCKcDWdmltdzPFeyrpFB/SlA8qtzjut19n7HVueQ5Hccrghh/Jc0uK m15K+C2gBBacGAjpPf+bU+59A22Gb8XJrfGPXV/VjxQbhDdodw5v/oGSj rcwwuQvSfdIHNzuw0iYfZjkUJYhKljLVyt9+ZRWL46kKtpalQuRpLwdYz I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAD4zK1OtJXHB/2dsb2JhbABZgwY7V8JRgRoWdIIseRIBgQAnBAoEh37PfxeOZYMrgRQElFuDbJIwgy2CKw X-IronPort-AV: E=Sophos;i="4.97,696,1389744000"; d="scan'208";a="308689727" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 20 Mar 2014 18:34:00 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2KIY0jQ002851 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Mar 2014 18:34:00 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.233]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Thu, 20 Mar 2014 13:34:00 -0500 From: "Francois Le Faucheur (flefauch)" To: "draft-ietf-cdni-metadata@tools.ietf.org" Thread-Topic: WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 5] Thread-Index: AQHPRGr1yeV4B3O4okSfYul82dNGiQ== Date: Thu, 20 Mar 2014 18:33:59 +0000 Message-ID: <18D8DD69-FA99-400B-83A0-A47790AB0209@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.96.157] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2743CE9DE20A4E44AFF8279BF4B475FF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/Hdpf4jeejtl821dmH2arElseVJM Cc: "cdni@ietf.org" Subject: [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: Thu, 20 Mar 2014 18:34:13 -0000 I got down to 6.2. and need to stop now. This is a loooooong review. Francois *** 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 *** 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 *** section 4.2.3 and 4.2.3.1 both have the same property name ie "Property: times=94. Perhaps the proper= ty in 4.2.3.1 could be renamed to something like =93windows" *** 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 *** section 4.2.2, 4.2.3 and 4.2.4. It appears that the three types of allow/deny (LocationACL, TimeWindowACL a= nd 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 com= es 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 *** 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=3Dacquisiti= on.=20 If it conditions how the dCDN is meant to change protocol to acquire the co= ntent , then it shoudl not be cast as an allow/deny, but probably more as = part of the =93source=94 object that defines acquisition behaviour. *** section 4.2.4 It is not obvious to me what are the rules when things are partially specif= ied. For example, if it says Protocol1/allow/acquisition, then is delivery = of Protocol1 allowed or denied? Can you add an explicit statement about tha= t? *** section 4.2.4.1: "Type: Enumeration [allow|deny]+=94 : I assume the =93+=94 should be remove= d? *** 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 author= ising=94, right? Also, similar to previous comments, I=92d suggest having slightly more expl= icit property names. So I=92d rename =93methods=94 into something like =93a= uth-methods" =93Content authorisation methods=94 is not clear. ie it is not the content = that is authorised, but the request. so perhaps replace with =93Content req= uest authorisation methods=94 or =93Delivery authorisation methods=94 "All options in the list are equally valid.=94 I think you mean more someth= ing like =93Delivery for a content request is authorized if any of the auth= orisation method in the list is satisfied for that request=94. *** section 4.2.6: I understand that Auth objects are meant to be listed within the =93Authori= zation 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 somethi= ng different here? *** 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 authent= ication and authorization? *** section 4.2.6=20 again =93property: type=94 =97> =93property: auth-type=94? *** 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. Property: type Description: Registered Auth type (see Section 7.1.1.3). ... 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 o= f the Description for the value. *** section 7.1.1.3=20 I think the section title (and registry) should be renamed from "Authentica= tion Sub-Registry=94 to "Authentication Type Sub-Registry=94 (and =93CDNI M= etadata Auth=94 to "CDNI Metadata Auth Type=94) I recommend the text be more explicit that the IANA has to create a registr= y (or sub-registry) for the "CDNI Metadata Auth Type=94. s/Type name/Type/ *** 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. *** 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 o= bvisouly 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 instance= s?) *** section 4.3.1: " Property: type=94 =97> " Property: metadata-object-type" *** 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-t= o-Specify? *** 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 dC= DN. =93 /If a the/if the/ 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 t= hat dCDN.=94 *** 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-framewor= k] 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 *** section 5: OLD: =93 for the metadata defined in Section 4.2 =93 NEW: =93 for the metadata defined in the present document. =93 *** section 5. I understand there is no =93optional=94 metadata that require capability ad= evrtisemnet (ie only optional values require advertisement). Since the text= explained the two cases previously, I would suggest adding a statement rig= ht befrore section 5.1 stating that the present document does not define op= tional 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. *** 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 sec= tion 7.1.1.1. Right? Where is it specified in the document that implementation MUST implement al= l the Footprint types? Can you make sure the mandatory to implement aspects= of this are clearly specified somewhere? *** 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 c= apabilities (eg to allow proper redirection) since this was explaine in sec= tion 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. 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 lin= es 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 *** section 5.2 I don=92t think you need to re-explain why it is useful to adevrtise the c= apabilities (eg to allow proper redirection) since this was explaine in sec= tion 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 supp= orts. " 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 lin= es 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 *** 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 Reque= st Routing Redirection interface (RI) [I-D.ietf-cdni-redirection]. =93 where [I-D.ietf-cdni-redirection] is added to the list of Informative Refer= ences. *** section 6: s/prepositioned CDNI Metadata acquisition/Pre-positioned CDNI Metadata acqu= isition/ (just to align to terminology of RFC6707) *** Section 6: 2nd paragraph. I suggest breaking it into two sentences for easier readabil= ity. *** 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 th= e 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 REST= ful web services=94. *** section 6: I suggest that the first time the phrase =93CDNI server=94 is use, it is cl= arified that this refers to the uCDN side of the CDNI Metadata interface. Same for =93CDNI client=94. *** 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 What about the client? MUST support GET and MAY support HEAD? *** 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 oth= er than GET and HEAD. =93 *** 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 ser= ver =85=94 *** 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 st= arts 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 *** 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-pi= lling of metadata). *** section 6.2: s/the downstream CDN must decide/the downstream CDN needs to determine/= From nobody Fri Mar 21 09:48: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 9FEAE1A08D2 for ; Fri, 21 Mar 2014 09:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.194 X-Spam-Level: X-Spam-Status: No, score=-104.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 jid62jNNsV10 for ; Fri, 21 Mar 2014 09:48:30 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2D51A046A for ; Fri, 21 Mar 2014 09:48:30 -0700 (PDT) Received: from stntexhc12.cis.neustar.com (unknown [10.31.58.71]) by stihiron2.va.neustar.com with smtp (TLS: TLSv1/SSLv3,128bits,AES128-SHA) id 6b08_4c06_83502d31_1f3e_4061_aceb_e793aee73431; Fri, 21 Mar 2014 12:48:07 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.252]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Fri, 21 Mar 2014 12:48:07 -0400 From: "Peterson, Jon" To: "iuniana.oprescu@orange.com" , "Francois Le Faucheur (flefauch)" , "cdni@ietf.org" Thread-Topic: [CDNi] draft text re TLS cipher suites (for cdni-logging and other cdni interfaces) Thread-Index: AQHPRSVVpTGjVeBI+0C5LwpyR6Fi/Q== Date: Fri, 21 Mar 2014 16:48:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [192.168.129.118] Content-Type: multipart/alternative; boundary="_000_CF51BB38EB480jonpetersonneustarbiz_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/IQqs6PtSWkZnp1tckmkzL5G-RoU Subject: Re: [CDNi] draft text re TLS cipher suites (for cdni-logging and other cdni interfaces) 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, 21 Mar 2014 16:48:33 -0000 --_000_CF51BB38EB480jonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Works for me. Jon Peterson Neustar, Inc. From: "iuniana.oprescu@orange.com" > Date: Thursday, March 20, 2014 at 8:40 AM To: "Francois Le Faucheur (flefauch)" >, "cdni@ietf.org" > Subject: Re: [CDNi] draft text re TLS cipher suites (for cdni-logging and o= ther cdni interfaces) Hello all, I would have phrased it as =93A CDNI Logging implementation MUST support th= e TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite [RFC5288]. An implementa= tion of the CDNI Logging Interface SHOULD prefer cipher suites which suppor= t perfect forward secrecy over cipher suites that don=92t.=94 My 2 eurocents=85 -- iuniana De : CDNi [mailto:cdni-bounces@ietf.org] De la part de Francois Le Faucheur= (flefauch) Envoy=E9 : jeudi 20 mars 2014 15:32 =C0 : cdni@ietf.org Objet : [CDNi] draft text re TLS cipher suites (for cdni-logging and other = cdni interfaces) Folks, Here is the draft text proposed by Jan (with input from Jon, and small edit= orial enhancements from me) for inclusion in cdni-logging: =93 A CDNI Logging implementation MUST support the TLS_DHE_RSA_WITH_AES_128_GCM= _SHA256 cipher suite [RFC5288]. A CDNI Logging implementation SHOULD favor = cipher suites which support perfect forward secrecy over non-perfect forwar= d secrecy cipher suites. =94 Please review and comment if needed. A few additional points: * the statements around TLS and cipher suites discussed here in the context= of cdni-logging are expected to apply to all the CDNI interfaces (unless t= here is some specific reason to do otherwise for a given interface) * there is no final position on this from IESG yet. So we may have to adapt= the text based on IESG review. * Jan identified that the rtcweb group has been looking at the same questio= n ( "http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-09=94 secti= on 5.5) and used their draft text and approach (ie RTCWEB decided not to re= quire the use of PFS, but to say that if both sides support it, it should b= e used) as a basis. Cheers Francois PS: For memory, here is an excerpt fom the IETF-89 meeting minutes where TL= S cipher suites were discussed: " Spencer Dawkins: IESG currently looking at cipher suites and perfect forwar= d secrecy. No formal decision yet about whether specifying cipher suites is= mandatory for drafts. Jan S.: Once IESG is done, I=92m willing to help with updating draft to ref= lect outcome. Rob Murray: Will we have the same discussion for other interfaces as well? = Maybe have transport in separate draft? Daryl M.: Don=92t think that=92s a good idea. Jan, could you help with reco= mmendation while we wait for IESG (i.e. send proposed text for that to auth= ors)? Jan S.: Ok. Spencer D.: Most important thing right now is that you=92ve thought about i= t. Fact that we=92re having this discussion is a good sign. =93 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_CF51BB38EB480jonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <37E2FE614178DC47B0A1E8148431F827@neustar.biz> Content-Transfer-Encoding: quoted-printable

Works for me.

Jon Peterson
Neustar, Inc.

From: "iuniana.oprescu@orange.com" <iuniana.oprescu@orange.com>
Date: Thursday, March 20, 2014 at 8= :40 AM
To: "Francois Le Faucheur (fle= fauch)" <flefauch@cisco.com>, "cdni@ietf.org" <= cdni@ietf.org>
Subject: Re: [CDNi] draft text re T= LS cipher suites (for cdni-logging and other cdni interfaces)

Hello all,

 

I would have phrased= it as =93A CDNI Logging implementation MUST= support the TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite [RFC5288]. An implementation of the CDNI Logging Interface SH= OULD prefer cipher suites which support perfect forward secrecy over cipher= suites that don=92t.=94

 

My 2 eurocents=85

-- iuniana

 

De : CDNi [mailto:cdni-bounces@ietf.org] De la part de Francois Le Faucheur (flefauch)
Envoy=E9 : jeudi 20 mars 2014 15:32
=C0 : cdni@ietf.org
Objet : [CDNi] draft text re TLS cipher suites (for cdni-loggin= g and other cdni interfaces)

 

Folks,

 

Here is the draft text = proposed by Jan (with input from Jon, and small editorial enhancements from= me) for inclusion in cdni-logging:

=93

A CDNI Logging imple= mentation MUST support the TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite= [RFC5288]. A CDNI Logging implementation SHOULD favor cipher suites which = support perfect forward secrecy over non-perfect forward secrecy cipher suites.

=94

 

Please review and comme= nt if needed.

 

A few additional points= :

* the statements around= TLS and cipher suites discussed here in the context of cdni-logging are ex= pected to apply to all the CDNI interfaces (unless there is some specific r= eason to do otherwise for a given interface)

* there is no final pos= ition on this from IESG yet. So we may have to adapt the text based on IESG= review.

* Jan identified that t= he rtcweb group has been looking at the same question ( "http://t= ools.ietf.org/html/draft-ietf-rtcweb-security-arch-09=94 section 5.5) and used their draft text and approach (ie RTCWEB decided not= to require the use of PFS, but to say that if both sides support it, it sh= ould be used) as a basis. 

 

 

Cheers

 

Francois

 

PS: For memory, here is= an excerpt fom the IETF-89 meeting minutes where TLS cipher suites were di= scussed: 

"

Spencer Dawkins: IESG c= urrently looking at cipher suites and perfect forward secrecy. No formal de= cision yet about whether specifying cipher suites is mandatory for dra= fts. 
Jan S.: Once IESG is done, I=92m willing to help with updating draft to ref= lect outcome.
Rob Murray: Will we have the same discussion for other interfaces as well? = Maybe have transport in separate draft?
Daryl M.: Don=92t think that=92s a good idea. Jan, could you help with reco= mmendation while we wait for IESG (i.e. send proposed text for that to = ;authors)?
Jan S.: Ok. 
Spencer D.: Most important thing right now is that you=92ve thought about i= t. Fact that we=92re having this discussion is a good sign. 

=93

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_CF51BB38EB480jonpetersonneustarbiz_-- From nobody Mon Mar 24 11:57: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 906651A02BF for ; Mon, 24 Mar 2014 11:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.012 X-Spam-Level: X-Spam-Status: No, score=-7.012 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_35=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 7DbfjC8XgmJk for ; Mon, 24 Mar 2014 11:57:23 -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 7746B1A02BA for ; Mon, 24 Mar 2014 11:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18295; q=dns/txt; s=iport; t=1395687442; x=1396897042; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=bAuN9/glelM3hjNlzi3NOR0UKqprZPI0zsniRtWMdlo=; b=Rn8AiM2lXZKtaCCgitgaEQBXhTWTuiH92J66rhI6oWYx7vlTnlI2pJec 97Xng3GmP0+qTVlb6fiuO0akokTd6AI3eX+9JeE5BkOudVgTl8DmoXurp v5dmWoZ4WnBAosq6ibFgBmzx1/6oHhgyuvNo9jXYOc2t5LnR2KAm+eWXn c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAD1/MFOtJXG+/2dsb2JhbABPCoMGO1fCcYEfFnSCLHkSAYEAJwQODodwDc9BF44eXAKDKYEUBJReg2yBMpB/gy2CKw X-IronPort-AV: E=Sophos;i="4.97,722,1389744000"; d="scan'208";a="29943331" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-6.cisco.com with ESMTP; 24 Mar 2014 18:57:22 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2OIvMBD030983 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Mar 2014 18:57:22 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.233]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Mon, 24 Mar 2014 13:57:22 -0500 From: "Francois Le Faucheur (flefauch)" To: "draft-ietf-cdni-metadata@tools.ietf.org" Thread-Topic: WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 6] Thread-Index: AQHPR5Lilga6cDELrEes+o61AeZYVg== Date: Mon, 24 Mar 2014 18:57:21 +0000 Message-ID: <5152EB8C-8B72-40A7-A0B3-0C887CA35258@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.198] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/68YNBPgX6aPwiTRMezGzoHFeaC8 Cc: "cdni@ietf.org" Subject: [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, 24 Mar 2014 18:57:30 -0000 Below is the last batch. 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 ca= n 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 br= ing up are more or less already addressed, don=92t hesitate to say so. I hope this review helps. Francois =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D *** section 6.3: s/either discovered by or configured in the downstream CDN./either configur= ed in, or discovered by, the downstream CDN./ *** 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? *** 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 *** section 6.4: s/and which are separately addressable./and which are made separately addre= ssable./ *** section 6.4.1: s/All MIME types are prefixed./All MIME types for CDNI Metadata objects are= prefixed/ *** section 6.4.1: OLD: " The MIME type for each object matches =93 NEW: " The MIME type for each object then contains =93 *** 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 obj= ect name.=20 *** 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 *** 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 do= cument. Perhaps you coudl remove that sentence and just include teh reference in br= ackets in the first sentence of section 6.4.1 like=20 =93All MIME types ([IANA-MIME-TYPES]) for CDNI Metadata objects =85" *** 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 objec= t 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 Me= tadata objects is encoded as a JSON object=94 *** 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.] *** section 6.4.2: =93If absent, all URLs in the remainder of the document must be absolute UR= Ls.=94 I don=92t think =93document=94 is the right word here. please calrify the s= cope of =93base=94 (eg single object, until there is another =93base=94 som= ething else)? *** section 6.4.2: s/The links of this object to/The links from this object to/ *** 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 happen= s that _links contains =93host-metadata=94 ). Can you tweak the text accordingly (not that for =93base=94 it may be in ad= dition, I am not sure). *** 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 con= tent hostnames and the cdn hostnames in completely different domains). Obviously this needs to be reflected everywhere. I understand that URI structure is completely arbitrary but I think: * using "http://metadata.example.ucdn.com/host1234=94 instead of "http://m= etadata.example.ucdn.com/video=94 and * using "http://metadata.example.ucdn.com/host6789=94 instead of "http://m= etadata.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 exam= ple you have below. *** 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 un= der footprints? =93iprange=94 is not one of the footprint types defined in 7.1.1.1, which d= efines IPv4range and IPv6range. *** section 6.4.2.1 " "protocols": [ { "protocols": [ "ftp" ], "action": "deny" =93 This makes me realise that it woudl be wise to rename the ProtocolACL objec= t 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 s= ame name, which is bound to create confusion. This goes bcak to a comment I made in different places about using more exp= licit and unique property names throughout the document.=20 *** section 6.4.2.1=20 OLD: " "pattern": "/videos/trailers/*=94 " NEW: =93 "pattern": "/video/trailers/*" " *** section 6.4.2.1=20 OLD: " "pattern": "/videos/movies/*=94 " NEW: =93 "pattern": "/video/movies/*" " *** 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/host1= 234/path7654=94 same for "href": "http://metadata.ucdn.example.com/videos/movi= es/hd=94, I=92d suggest something like "http://metadata.ucdn.example.com/ho= st1234/path5432=94 (I don=92t think we need to illustrate the hierarchy of= path match into teh path metadata uris) *** section 6.4.2.1 " "times": [ "times": [ =93 same comment as above for =93protocols=94: the top property should be renam= ed (eg to something like "times-acl=94). *** section 6.4.2.1 " "type": =93allow" =93 I think this should read : =93 =93action": =93allow=94 =93 *** section 6.5: "proprietary and/or custom property Metadata=94 What is the difference between proprietary and custom? Perhaps we should ju= st talk about vendor specific? *** 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 organizati= on 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 re= ad =93Metadata property name=94? *** section 6.5.1 "property Metadata=94 same as above: is this not more =93Metadata property= =94 (or =93Metadata properties=94)? *** 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 ju= st imply it from teh discussion in section 6.5) and always talk about =93ve= ndor specific properties=94 . *** 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-enfor= ce=94: If a dCDN does not understand or is unable to perform the functions associated with any "mandatory-to-enforce=94 vendo= r-specific Metadata, the dCDN MUST NOT service any requests for the corresponding content. =93 *** 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 r= ephrasing into something like =93Any document specifying new GenericMetadat= a =85.=94. *** section 6.5.1=20 s/Thus, the dCDN MUST evaluate/Thus, the dCDN MUST always evaluate/ *** section 6.5.2: I would suggest changing the title of that section (and the text accordingl= y) to something like =93Metadata conflicts=94. Because the concept of metad= ata =93overide" is defined in section 3,3 and is something different (ie sa= me metadata but applying at different =93host path" levels). 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 ovve= ride rules avoid any actual conflict (by ensuring that potentially conflict= ing metadata apply to different sets of requests). Do you agree? to me this= is easier to read than the current statement. *** 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 M= IME-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 *** 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 *** section 6.6: "HTTP requests sent to a metadata server SHOULD include an Accept header wi= th the MIME-type and version of the expected object.=93 Can a metadata client indicate it it is happy to receive wither of two vers= ions eg "application/cdni.HostIndex.v1+json=94 or "application/cdni.HostInd= ex.v2+json? I assme yes. Can you state that and give some description or ex= ample? *** 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? =20 *** 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 t= he complete MIME-Types through a =93rule=94 which says add the name of a me= tadata object + v1 + jason.=20 I think you want to explicitely request IANA to allocate each and every ind= ividual MIME-Type (eg all teh ones mentioned in Table 3 + the other ones n= eeded). As an analogy, note that ALTO has an allocation in the MIME-TYPE registry f= or each ALTO type (alto-costmap+json , alto-costmapfilter+jso, alto-directo= ry+json, etc.). Also, for information, in teh cdni-logging spec we are requsting allocation= of the "application/cdni.LoggingFile=94 MIME-Type. *** 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? *** section 7.1 s/a new IANA registry is requested for "CDNI GenericMetadata Types" namespa= ce./a new IANA registry is requested for the "CDNI GenericMetadata Types" n= amespace./ *** section 7.1: " | Auth | RFCthis | 1 | true | true | =93 I think what should appear here is =93Authorization=94 (currently in sectio= n 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). *** 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 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)= .. Actually, this raises a serious high level question in my mind on the way t= he 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 actual= ly identify what objects this is (and therefore what other properties follo= w). Now if you want to keep that approach, then you need to make sure that a ne= w object allocated in the GenericMetadata Type registry never allocates the= same first =93property name=94, right? otherwise you can=92t parse teh en= coding and know which object it is. I don=92t think any such restrictions i= s 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)? [I am not doing a complete review of the IANA section as I think we need to= close on teh previous question first]. 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 t= imes (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 a= nd receiving side) about all this. *** section 7.1: =93MUST=94" as discussed before I assume you will be removing any RFC2119 t= erminology from the IANA section. *** section 8: I think the security discussion needs some work. Some suggestions: * The text first indicates that the interface is to be secured via transpo= rt security, and then it talks about bad things that can happens with mali= cious server/client. This suggests that these bad things happen even when t= he interface is secured. I recommend you explain the security concern first= , and then explain that these can be protected against via transport securi= ty mechanisms. * regarding security mechanisms, please look at the latest approach decide= d for cdni-logging and align approach and wording (ie you SHOULD use TLS ex= cept in such and such situations, you need to do this re cipher suites,..). * when discussing security risks, I recommend you distinguish those that r= elate to authentication (ie someone spoofing the other end), to confidentia= lity protection (e.g. someone being able to see metadata), to integrity pro= tection (someone being able to modify metadata).=20 *** Appendix A:=20 Like we did for cdni-logging, this appendix tracking compliance to requirem= ents 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.= From nobody Tue Mar 25 04:05:32 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 1528D1A03BC for ; Tue, 25 Mar 2014 04:04:44 -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 GrhtP68LZSuZ for ; Tue, 25 Mar 2014 04:04:40 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9EC1A03BA for ; Tue, 25 Mar 2014 04:04:39 -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 1WSP9p-0003Ow-O3; Tue, 25 Mar 2014 11:04:38 +0000 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Ben Niven-Jenkins In-Reply-To: Date: Tue, 25 Mar 2014 11:03:18 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <147CBB6C-9F42-4758-909C-2FD9B96DB289@niven-jenkins.co.uk> References: To: Daryl Malas X-Mailer: Apple Mail (2.1085) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/gZ0wrXYdz-Dx0wNfMqzAlxahfZA Cc: "cdni@ietf.org" Subject: Re: [CDNi] URI Signing for CDNI Working Group 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: Tue, 25 Mar 2014 11:04:44 -0000 Daryl, Authors, I gave the draft a quick read. It seems a reasonable starting point. While I was reading the draft I noticed a couple of things in it that I = think are worth raising: 1) In section 2 the draft says "Any attributes appended in such way = after the URI Signature has been calculated are not validated for the = purpose of content access authorization." If additional query parameters can be appended to the URI which are not = validated, could a UA obtain content that it isn't authorised to obtain = by adding additional query parameters? It seems like something that = could be worth discussing in the security considerations section? 2) Section 2.2 allows the KeyID to be included in the Signed URI. This = also seems like it might open a security hole as a malicious UA could = strip the original URISigningPackage attribute, sign the URI with a Key = under its control (possibly altering other things like the actual URI or = expiry time) and include the appropriate KeyID for that new Key in the = new URISigningPackage. Is there a use case for signalling the KeyID within the Signed URI = itself? 3) Regarding hash functions & digital signature algorithms, the draft = hints at allowing several options for each and defines a default in case = a particular algorithm is not specified in the URISigningPackage. This seems a bit overkill to me. To aid inter-operability, I think it = would be better to specify a single algorithm for each unless there are = use cases for requiring support for more than one algorithm in the first = version defined in the draft? Regards Ben =20 On 6 Mar 2014, at 15:34, Daryl Malas wrote: > All, >=20 > During today=92s working group meeting, we agreed the latest draft = revision of this draft = (http://tools.ietf.org/html/draft-leung-cdni-uri-signing-05) is = substantial for us to adopt it as a working group item. However, = Francois and I did not feel comfortable conducting a =93Hum,=94 since = there were not a lot of people present who had read the draft. This = draft was proposed in response to the following charter item: >=20 > 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). >=20 > In addition, the working group has the following milestone: >=20 > Sep 2014 - Submit specification of URI Signing for CDNI to IESG as = Proposed Standard >=20 > With this in mind, we are requesting people read the draft in = preparation for this draft to be accepted as a working group item, which = will occur on March 21st. If anyone has any major concerns with this, = please post comments and concerns to the list. >=20 > Regards, >=20 > Daryl & Francois >=20 >=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Tue Mar 25 07:00: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 5ECA41A011E for ; Tue, 25 Mar 2014 07:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 DwxXOeUFdU7r for ; Tue, 25 Mar 2014 07:00:42 -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 56E321A011B for ; Tue, 25 Mar 2014 07:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2428; q=dns/txt; s=iport; t=1395756041; x=1396965641; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hTLjU5Q5odc9psgp3SwQpp1El3tVAf/A1tPqfsREE0Q=; b=dcVISnf4J0Ff4C3LHI7snqGqQO+GmyoGEdsLuMu7ZqRlSpZbF0znjDi2 bXOivXEUGn1koVjt7E83YyEUTyJpYbuV1mDUrPlKNwkKXApJR4UwVulfr R8ONhBhR8MUA84E130LajZnx9gin1cn04UiQlgF6UxmLkA1UshQIG+/CF M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFADqLMVOtJV2d/2dsb2JhbABZgwY7V7s4hzWBGhZ0giUBAQEDAQEBAWsLEAIBCBguJwslAgQOBYdxCA3PExeOOzMHgySBFASYTYEykQCDLoIr X-IronPort-AV: E=Sophos;i="4.97,728,1389744000"; d="scan'208";a="312731733" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 25 Mar 2014 14:00:41 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2PE0fND008293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Mar 2014 14:00:41 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.121]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 25 Mar 2014 09:00:40 -0500 From: "Francois Le Faucheur (flefauch)" To: Niven-Jenkins Ben Thread-Topic: [CDNi] URI Signing for CDNI Working Group Draft Thread-Index: AQHPSBo16deBcTp1PU21bkpsvYQa55ryKNGA Date: Tue, 25 Mar 2014 14:00:40 +0000 Message-ID: <793F6A07-720C-4ABE-A289-D1EADA3E339A@cisco.com> References: <147CBB6C-9F42-4758-909C-2FD9B96DB289@niven-jenkins.co.uk> In-Reply-To: <147CBB6C-9F42-4758-909C-2FD9B96DB289@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.198] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2F16FB1920762942A661B0E46F8729C9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/VftO8MuJfPdANTzxSoc9pbTNxIM Cc: "cdni@ietf.org" Subject: Re: [CDNi] URI Signing for CDNI Working Group 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: Tue, 25 Mar 2014 14:00:45 -0000 On 25 Mar 2014, at 12:03, Ben Niven-Jenkins wrote= : >=20 >=20 > 3) Regarding hash functions & digital signature algorithms, the draft hin= ts at allowing several options for each and defines a default in case a par= ticular algorithm is not specified in the URISigningPackage. >=20 > This seems a bit overkill to me. To aid inter-operability, I think it wou= ld be better to specify a single algorithm for each unless there are use ca= ses for requiring support for more than one algorithm in the first version = defined in the draft? For interoperability, we=92d want to specify one "Mandatory to Implement=94= algorithm for each. On top of that, if useful, additional algorithms can = be allowed without compromising interoperability. Francois >=20 > Regards > Ben >=20 >=20 > On 6 Mar 2014, at 15:34, Daryl Malas wrote: >=20 >> All, >>=20 >> During today=92s working group meeting, we agreed the latest draft revis= ion of this draft (http://tools.ietf.org/html/draft-leung-cdni-uri-signing-= 05) is substantial for us to adopt it as a working group item. However, Fr= ancois and I did not feel comfortable conducting a =93Hum,=94 since there w= ere not a lot of people present who had read the draft. This draft was pro= posed in response to the following charter item: >>=20 >> 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). >>=20 >> In addition, the working group has the following milestone: >>=20 >> Sep 2014 - Submit specification of URI Signing for CDNI to IESG as Propo= sed Standard >>=20 >> With this in mind, we are requesting people read the draft in preparatio= n for this draft to be accepted as a working group item, which will occur o= n March 21st. If anyone has any major concerns with this, please post comm= ents and concerns to the list. >>=20 >> Regards, >>=20 >> Daryl & Francois >>=20 >>=20 >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Tue Mar 25 07:13:42 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 8DCC21A0151; Tue, 25 Mar 2014 07:13:37 -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 1EhlZCZCZCpO; Tue, 25 Mar 2014 07:13:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF151A011B; Tue, 25 Mar 2014 07:13:36 -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.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140325141336.28456.21350.idtracker@ietfa.amsl.com> Date: Tue, 25 Mar 2014 07:13:36 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/wvSvC3OTUROU8UEVdjxA2s4GL-Y Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-logging-11.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: Tue, 25 Mar 2014 14:13:38 -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 : CDNI Logging Interface Authors : Francois Le Faucheur Gilles Bertrand Iuniana Oprescu Roy Peterkofsky Filename : draft-ietf-cdni-logging-11.txt Pages : 46 Date : 2014-03-25 Abstract: This memo specifies the Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework. First, it describes a reference model for CDNI logging. Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-logging-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-logging-11 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 Tue Mar 25 07:18: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 4E0431A0150 for ; Tue, 25 Mar 2014 07:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 7MPt_GtcPkTA for ; Tue, 25 Mar 2014 07:18:41 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 664181A011B for ; Tue, 25 Mar 2014 07:18:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2126; q=dns/txt; s=iport; t=1395757121; x=1396966721; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=OKgc0KDz+GDQi4OKRiddmp64ryJlym4FxOadAypnupY=; b=Xq6r5QgCi8BeayKM8DmQulcRBUHjB+8FE3kupXhCjsA2v0PZUFBTOnrB 3EFDt9WKFpzP4wEDUCJTtETqV/PfdMXJ5soKCj0G6V0aSgC8YAUzkJ2vz oi4l0pcJvk+FOKueEUk0QSSyT7/KjFV+LufFuNRVgWU+yY6vqrFTvVT3p s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIFAOyPMVOtJXHA/2dsb2JhbABZgwY7UQa7OIc1gRoWdIIlAQEBAwEBAQE3NBsCAQg2ECcLJQIEEwmHaAgIBc8WF44aITqDJIEUBJhNgTKRAIMugis X-IronPort-AV: E=Sophos;i="4.97,728,1389744000"; d="scan'208";a="309674670" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 25 Mar 2014 14:18:28 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2PEIRWM028398 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 25 Mar 2014 14:18:27 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.121]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Tue, 25 Mar 2014 09:18:27 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-logging-11.txt Thread-Index: AQHPSDRt/plw9vNWEU+vGDoFzFvgdJryLZSA Date: Tue, 25 Mar 2014 14:18:26 +0000 Message-ID: <447B00A7-944A-452A-ABD1-A5A19D4B676D@cisco.com> References: <20140325141336.28456.21350.idtracker@ietfa.amsl.com> In-Reply-To: <20140325141336.28456.21350.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.198] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/NEiUXG125s2Ziqf7vr0wMZXejRE Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-logging-11.txt 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, 25 Mar 2014 14:18:43 -0000 (as a document editor) This new version includes resolution of the two outstanding items as agreed= in London and discussed on the list: * applicability of CDNI Logging record to HTTP/1.0, HTTP/1.1, HTTP/2.0 and= HTTP * requirements language about TLS and associated cipher suites Cheers Francois On 25 Mar 2014, at 15:13, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Content Delivery Networks Interconnectio= n Working Group of the IETF. >=20 > Title : CDNI Logging Interface > Authors : Francois Le Faucheur > Gilles Bertrand > Iuniana Oprescu > Roy Peterkofsky > Filename : draft-ietf-cdni-logging-11.txt > Pages : 46 > Date : 2014-03-25 >=20 > Abstract: > This memo specifies the Logging interface between a downstream CDN > (dCDN) and an upstream CDN (uCDN) that are interconnected as per the > CDN Interconnection (CDNI) framework. First, it describes a > reference model for CDNI logging. Then, it specifies the CDNI > Logging File format and the actual protocol for exchange of CDNI > Logging Files. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-cdni-logging-11 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-11 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Tue Mar 25 08:53:24 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 5888B1A0179 for ; Tue, 25 Mar 2014 08:53:02 -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 FcBWg9xSUVrN for ; Tue, 25 Mar 2014 08:52:59 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id C34691A0153 for ; Tue, 25 Mar 2014 08:52:59 -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 1WSTeq-0006FG-Se; Tue, 25 Mar 2014 15:52:57 +0000 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Ben Niven-Jenkins In-Reply-To: <793F6A07-720C-4ABE-A289-D1EADA3E339A@cisco.com> Date: Tue, 25 Mar 2014 15:52:52 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147CBB6C-9F42-4758-909C-2FD9B96DB289@niven-jenkins.co.uk> <793F6A07-720C-4ABE-A289-D1EADA3E339A@cisco.com> To: "Francois Le Faucheur (flefauch)" X-Mailer: Apple Mail (2.1085) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/8oOfhEebAeKtf89ieNjFos1yiOM Cc: "cdni@ietf.org" Subject: Re: [CDNi] URI Signing for CDNI Working Group 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: Tue, 25 Mar 2014 15:53:02 -0000 Francois, On 25 Mar 2014, at 14:00, Francois Le Faucheur (flefauch) wrote: >=20 > On 25 Mar 2014, at 12:03, Ben Niven-Jenkins = wrote: >>=20 >>=20 >> 3) Regarding hash functions & digital signature algorithms, the draft = hints at allowing several options for each and defines a default in case = a particular algorithm is not specified in the URISigningPackage. >>=20 >> This seems a bit overkill to me. To aid inter-operability, I think it = would be better to specify a single algorithm for each unless there are = use cases for requiring support for more than one algorithm in the first = version defined in the draft? >=20 > For interoperability, we=92d want to specify one "Mandatory to = Implement=94 algorithm for each. On top of that, if useful, additional = algorithms can be allowed without compromising interoperability. Fair point. What I'm suggesting is we pick one for interoperability = (mandatory to implement) and unless anyone can show a use case for = having more than one at this time, we just stick with that single = mandatory to implement algorithm until such time as a use case requiring = a different algorithm appears. Ben >=20 > Francois >=20 >>=20 >> Regards >> Ben >>=20 >>=20 >> On 6 Mar 2014, at 15:34, Daryl Malas wrote: >>=20 >>> All, >>>=20 >>> During today=92s working group meeting, we agreed the latest draft = revision of this draft = (http://tools.ietf.org/html/draft-leung-cdni-uri-signing-05) is = substantial for us to adopt it as a working group item. However, = Francois and I did not feel comfortable conducting a =93Hum,=94 since = there were not a lot of people present who had read the draft. This = draft was proposed in response to the following charter item: >>>=20 >>> 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). >>>=20 >>> In addition, the working group has the following milestone: >>>=20 >>> Sep 2014 - Submit specification of URI Signing for CDNI to IESG as = Proposed Standard >>>=20 >>> With this in mind, we are requesting people read the draft in = preparation for this draft to be accepted as a working group item, which = will occur on March 21st. If anyone has any major concerns with this, = please post comments and concerns to the list. >>>=20 >>> Regards, >>>=20 >>> Daryl & Francois >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 From nobody Wed Mar 26 04:48:20 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 3AA1B1A0310 for ; Wed, 26 Mar 2014 04:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.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 RXJJzEprIAoX for ; Wed, 26 Mar 2014 04:48:10 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 3626F1A0307 for ; Wed, 26 Mar 2014 04:48:09 -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 1WSmJT-0000U2-08; Wed, 26 Mar 2014 11:48:07 +0000 From: Ben Niven-Jenkins Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Mar 2014 11:48:04 +0000 Message-Id: <86571176-B0EC-4D80-9D2B-1FC68D469A92@niven-jenkins.co.uk> To: cdni@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/4XmMRtvP1hEsUwMO5UoWWiLWMQM Cc: Mark Nottingham Subject: [CDNi] Applicability of draft-nottingham-http-problem to CDNI Redirection interface 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, 26 Mar 2014 11:48:16 -0000 CDNIers, cc'ing Mark Nottingham as the author of draft-nottingham-http-problem in = case he has any views. Previously Francois asked whether we should use = draft-nottingham-http-problem to communicate errors for the CDNI = Redirection interface (draft-ietf-cdni-redirection). During IETF89 in London I presented my view that using = draft-nottingham-http-problem is not applicable to the CDNI Redirection = interface and took an action to follow-up by sending my reasoning to the = mailing list. draft-nottingham-http-problem "defines a "problem detail" as a way to = carry machine-readable details of errors in a HTTP response, to avoid = the need to invent new error response formats for HTTP APIs." And it also says "Note that problem details are (naturally) not the only = way to convey the details of a problem in HTTP; if the response is still = a representation of a resource, for example, it's often preferable to = accommodate describing the relevant details in that application=92s = format.=94 In the case of draft-ietf-cdni-redirection we have our own response = format for communicating details of the redirection from dCDN to uCDN. Currently we have defined our own format for errors (aligned with the = response format for successful requests) and what we have specified = contains all the same fields as specified draft-nottingham-http-problem, = with the only significant difference being that = draft-nottingham-http-problem uses a Media Type for communicating the = error code, whereas draft-ietf-cdni-redirection uses a numeric code. Having a separate format for errors doesn't seem to make much sense to = me, especially as there may be cases where we need to communicate = details of a redirection and signal an error within the same response. Therefore IMO we are in the situation quoted from = draft-nottingham-http-problem above, i.e. we already have an application = specific format for responses and therefore IMO it is preferable to = accommodate errors within our existing response body format rather than = trying to leverage a more generic mechanism such as that described in = draft-nottingham-http-problem. Unless anyone feels strongly otherwise, we will continue to define CDNI = Redirection interface errors in the application specific format we = currently have in draft-ietf-cdni-redirection. Regards Ben From nobody Sat Mar 29 09:09:30 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 67B321A0639 for ; Sat, 29 Mar 2014 09:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.126 X-Spam-Level: ** X-Spam-Status: No, score=2.126 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 tzRw1Qmpmlt4 for ; Sat, 29 Mar 2014 09:09:28 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFF91A02DB for ; Sat, 29 Mar 2014 09:09:28 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id s2TG9Peu017883 for ; Sat, 29 Mar 2014 10:09:25 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Sat, 29 Mar 2014 10:09:25 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0174.001; Sat, 29 Mar 2014 10:09:24 -0600 From: Daryl Malas To: "cdni@ietf.org" Thread-Topic: [CDNi] CDNI Logging WGLC Thread-Index: AQHPS2lAK60zQ9yu4ky/Sz06Ag82bQ== Date: Sat, 29 Mar 2014 16:09:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.5.0.27] Content-Type: multipart/alternative; boundary="_000_CF5CAEC3199E4dmalascablelabscom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/tVx0bKCi1vRQvA34atflAx4vnWs Subject: [CDNi] CDNI Logging WGLC 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: Sat, 29 Mar 2014 16:09:29 -0000 --_000_CF5CAEC3199E4dmalascablelabscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, As we discussed in the last IETF meeting, after the remaining issues were a= ddressed per the meeting minutes, we are going to WGLC for the CDNI logging= draft (http://tools.ietf.org/html/draft-ietf-cdni-logging-11). These issu= es were addressed in rev 11 of the logging draft, so we are beginning a las= t call on this draft. This last call will take place starting today throug= h April 11th. If there are any remaining questions, concerns or issues, pl= ease send them to the mailing list during this time frame. Regards, Daryl & Francois --_000_CF5CAEC3199E4dmalascablelabscom_ Content-Type: text/html; charset="us-ascii" Content-ID: <51D70CEA1A1D3C42BF1AA868E136749C@cablelabs.com> Content-Transfer-Encoding: quoted-printable
All,

As we discussed in the last IETF meeting, after the remaining issues w= ere addressed per the meeting minutes, we are going to WGLC for the CDNI lo= gging draft (http://tools.ietf.org/html/draft-ietf-cdni-logging-11).  These issues were addressed in rev 11 of the logging draft, so we ar= e beginning a last call on this draft.  This last call will take place= starting today through April 11th.  If there are any remaining questi= ons, concerns or issues, please send them to the mailing list during this time frame.

Regards,

Daryl & Francois
--_000_CF5CAEC3199E4dmalascablelabscom_--