On Mon, Feb 10, 2014 = at 4:08 PM, Kevin J Ma <kevin.ma@azukisystems.com> w= rote:

Basically that's what I meant.
Initialization as well as asynchronous/incremental updates.

> -----Original Message-----
> From: Peterson, Jon [mailto:jon.peterson@neustar.biz]

> Sent: Monday, February 10, 2014 2:56 PM=
> To: Kevin J Ma; Jan Seedorf; cdni@iet= f.org
> Subject: Re: footprint and capability mechanisms
>
>

> Do you mean inefficienci= es beyond the need for asynchronous and
> incremental updates? This is the discussion I think we need to have. >
> Jon Peterson
> Neustar, Inc.
>
> On 2/9/14, 8:47 PM, "Kevin J Ma" <kevin.ma@azukisystems.com> wrote:
>
> >I think my question is still about the actual call flows for the A= LTO
> >implementation, and whether there are any significant inefficienci= es?
> >Though, to Jon's point, both approaches are going to need more= work,
> >so it's hard to assess from the current state.
> >
> >I believe Matt had an action from Vancouver to also do an analysis= ?
> >
> >-- =A0Kevin J. Ma
> >
> >> -----Original Message-----
> >> From: CDNi [mailto:c= dni-bounces@ietf.org] On Behalf Of Jan Seedorf
> >> Sent: Friday, February 07, 2014 4:01 AM
> >> To: Peterson, Jon; cdni@ietf= .org
> >> Subject: Re: [CDNi] footprint and capability mechanisms
> >>
> >> Dear Jon,
> >>
> >> Thank you for the good and fair summary below, this is pretty= much the
> >> status quo. Just one comment: the reason why some of the nece= ssary ALTO
> >> extensions have been delayed is that the ADs/chairs have disa= llowed
> such
> >> work to be discussed before the core ALTO protocol has been p= ublished;
> >> just recently green light for continuing work on extensions h= as been
> >> given.
> >>
> >> What in my view it boils down to (as you highlight below): > >> -- ALTO has error handling, encoding, security worked out (pr= o for
> using
> >> ALTO)
> >> -- incremental and asynchronous updates for ALTO is early sta= ge; in
> fact
> >> the ALTO WG is right now re-chartering to add those two items= to the
> >> charter item list, early work exists, but it will take some t= ime for
> >>those
> >> specs to be ready (con for using ALTO)
> >>
> >> What Richard and I have in mind was to drive these
> >>very-soon-to-be-on-the-
> >> chartered ALTO extensions (i.e. incremental/asynchronous upda= tes) by
> the
> >> concrete CDNI FCI use case. In other words we intend to defin= e a
> >>solution
> >> for CDNI/FCI and kick that back into the ALTO WG. But no doub= t, having
> >> these ALTO extensions done in ALTO will likely take longer th= an the
> >> current CDNI milestone for the FCI solution spec.
> >>
> >> Kevin, all: anything you want to share to the discussion?
> >>
> >> =A0- Jan
> >>
> >> > -----Original Message-----
> >> > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Peterson, Jon
> >> > Sent: Thursday, February 06, 2014 7:41 PM
> >> > To: cdni@ietf.org > >> > Subject: [CDNi] footprint and capability mechanisms
> >> >
> >> > Following our discussion about the FCI mechanism in Vanc= ouver, I took
> >>a
> >> > look at two drafts out there today: draft-ma and draft-s= eedorf. In
> >> short,
> >> > I think both express promising directions, and both have= a long way
> to
> >> go
> >> > before they will describe fully fleshed-out mechanisms. = At a high
> >>level,
> >> > their architectures are similar: both are about pushing = JSON objects
> >> that
> >> > describe footprints and capability via HTTP. It=B9s ofte= n when the
> >>choices
> >> > are so similar that it=B9s hardest to figure out which i= s the right
> >> approach.
> >> >
> >> > One of the prominent distinctions between the two is tha= t Kevin
> >> specifies
> >> > a capability-sharing system with an optional footprint, = whereas Jan
> >> > specifies a footprint-sharing system with the option of = capabilities.
> >> > Jan=B9s choice is an artifact of using ALTO as a basis, = which already
> >>has
> >> a
> >> > concept of sharing 'network maps' in this fashio= n, and can be
> extended
> >> to
> >> > add further information to these maps such as capability= . Kevin works
> >> from
> >> > the ground up on a bespoke system for sharing capabiliti= es, which may
> >> not
> >> > ever involve sharing footprint data. I=B9ve turned this = over in my head
> >>a
> >> > bunch of times, and I=B9m not really sure there=B9s any = practical
> >>advantage
> >> > one approach has over the other. One of the non-obvious = reasons why
> is
> >> > that the concept of a PID (the groupings of network elem= ents) in ALTO
> >>is
> >> > so abstract that it serves as a layer of indirection, an= d can serve
> >>as a
> >> > placeholder for a footprint that=B9s effectively specifi= ed implicitly.
> >> >
> >> > An important feature we want this mechanism to have is i= ncremental
> FCI
> >> > updates. Both Kevin and Jan have a story about this, tho= ugh I think
> >>both
> >> > will require substantial work to advance. Kevin, for exa= mple,
> >>sketches a
> >> > system of primitives (replace, include, exclude) to allo= w a dCDN to
> >> update
> >> > a uCDN about changes, based on tracking update sequencin= g with a new
> >> > 'CDNI-FCI-Seq' HTTP header. State freshness of w= eb resources is a
> >>pretty
> >> > thoroughly-studied problem, though, and there are other = HTTP
> >>facilities
> >> > (Etags, say) that address this. I think it=B9s pretty un= likely that our
> >> > problem is enough of a special case that we could convin= ce
> Application
> >> > folks here at the IETF that we need to standardize a cus= tom HTTP
> >>header
> >> > for it. Jan=B9s draft, on the other hand, references exi= sting ALTO work
> >>on
> >> > incremental updates, in particular draft-schwan-alto-inc= r-updates.
> >>That
> >> > draft contains a good overview of the different approach= es, including
> >> HTTP
> >> > If-Modified-Since and Etags, as well as looking at JSON-= specific
> >> > incremental change techniques like JSON Patch (RFC6902).= Sounds
> great,
> >> but
> >> > - draft-schwan is currently an expired I-D (for like a y= ear), and it
> >>is
> >> > really more of a survey than a draft that makes a concre= te
> >> recommendation.
> >> > This work would need to be resumed and made far more con= crete for
> this
> >> to
> >> > be a viable approach.
> >> >
> >> > Asynchronous updates are another very important feature.= We don=B9t
> want
> >> > to
> >> > force uCDNs to poll dCDNs, we want dCDNs to be capable o= f
> >>asynchronously
> >> > notifying uCDNs when a change to network state happens. = Kevin again
> >>has
> >> a
> >> > sketch of a solution here, where capability information = can either be
> >> > acquired by a GET from the uCDN or a POST by the dCDN. W= hile as
> >> described
> >> > it is very lightweight, I suspect it=B9s probably a bit = too
> lightweight:
> >> I=B9d
> >> > want to know a lot more about how resource identifiers a= re discovered
> >>or
> >> > formulated, and a ton more about error-handling and secu= rity. This
> >> > mechanism almost certainly should be ReST-based, as it w= ill then
> >>inherit
> >> > many of the right principles. ALTO, based on Jan=B9s dra= ft, of course
> is
> >> > already ReST-based, and has exhaustive sections on JSON = encoding,
> >> errors,
> >> > security, and the way to formulate queries via POSTs. Wh= at it lacks
> is
> >> an
> >> > asynchronous publication capability. Once again, there a= re some I-Ds
> >>we
> >> > can point to, but nothing I=B9d consider very concrete. = Worse still,
> >>even
> >> > the capability data that ALTO might carry is based on a = -00 I-D
> >> > (draft-roome-alto-pid-properties) which is very sketchy,= to the point
> >> > where providing even a mock-up of the JSON encoding for = capabilities
> >>in
> >> > ALTO is probably impossible today.
> >> >
> >> > So where does this leave us? Fleshing out either of thes= e approaches
> >> will
> >> > take work. We don=B9t want to do needless work articulat= ing two
> >>proposals
> >> > where we only need one. It is however difficult to have = a serious
> >> > discussion about the advantages of either mechanism when= they are
> only
> >> > specified to this limited degree. Ideally some kind of m= erger would
> be
> >> > possible here, and the sooner we can get to that the bet= ter. I don=B9t
> >> think
> >> > the baseline JSON formats for rendering either footprint= s or
> >>capability
> >> > will ultimately vary significantly in the two proposals.= It then just
> >> > becomes a question of whether it is more practical to st= art tabula
> >>rasa,
> >> > as Kevin does, or to build on an existing mechanism, as = Jan does.
> ALTO
> >> > comes with baggage, but that baggage has accumulated fro= m several
> >>years
> >> > now of comment and review, and surely a lot of those com= ponents (like
> >> > error handling, encoding, security) would have to be inc= orporate into
> >> > Kevin=B9s draft if we went forward with it. I suspect th= at would
> >> ultimately
> >> > be a longer path, but neither of these paths are particu= larly short.
> >> >
> >> > Jon Peterson
> >> > Neustar, Inc.
> >> >
> >> >
> >> > _______________________________________________
> >> > 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
ht= tps://www.ietf.org/mailman/listinfo/cdni

--
=

--=A0

=A0=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

| Y. Richard Yang <yry@cs.yale.edu> =A0 |

| Professor of Compute= r Science =A0 =A0 =A0 |

| http://www.cs.yale.edu/~yry/ =A0 =A0 =A0 = =A0|

=A0=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

--bcaec529985f6c316404f214a4b4-- From jon.peterson@neustar.biz Mon Feb 10 16:42:49 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 2A0FC1A04E0 for ; Mon, 10 Feb 2014 16:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.296 X-Spam-Level: X-Spam-Status: No, score=-104.296 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 S2m2K9dlikND for ; Mon, 10 Feb 2014 16:42:46 -0800 (PST) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 804E91A070F for ; Mon, 10 Feb 2014 16:42:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1392079511; x=1707432200; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=QMR2VoStAQ x+VI8Or3gxZMkJolvt4Ybp12Ykbpjaiik=; b=VgIDwHcbd4fuTgwhytVF5OT/ya n7whZ/bEsZqBBzxCxmK8UfEn2PN2qinhuDnZby8Mi6Qh50fxumUrwSWJf/vg== Received: from ([10.31.58.71]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.41057495; Mon, 10 Feb 2014 19:45:10 -0500 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.252]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Mon, 10 Feb 2014 19:42:39 -0500 From: "Peterson, Jon" To: Scott Wainner , "cdni@ietf.org" Thread-Topic: [CDNi] footprint and capability mechanisms Thread-Index: AQHPI2r+MKQy3HwHMU6O1Xni5u+2KZqvTCKA//+/DgA= Date: Tue, 11 Feb 2014 00:42:38 +0000 Message-ID: References: <52F937F7.60008@cisco.com> In-Reply-To: <52F937F7.60008@cisco.com> 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.128.86] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: W/FfFE3PrRNjrRQhihEdiw== Content-Type: text/plain; charset="us-ascii" Content-ID: <70997062F8843F4BBCB3635CACCE5342@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] footprint and capability mechanisms 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 Feb 2014 00:42:49 -0000 Good points, a few notes inline. Jon Peterson Neustar, Inc. On 2/10/14, 12:35 PM, "Scott Wainner" wrote: >My opinion is: > >1) the capabilities must match before we even care about the properties >of the footprint >2) the properties of the footprint are likely defined in a contract >(i.e. global coverage, regional coverage) >3) retraction of a portion of footprint probably violates a contractual >obligation; therefore, no CDN would announce it >4) the advertisement of a footprint (that conforms to a contract) is >probably just a means of automating the CDN selection by the uCDN which >already has the ability to statically assign a footprint to a dCDN based >on the contract >5) the uCDN probably has many other rules that it must consider before >footprint comes into play (i.e. geo-location, quotas, performance, >time-of-day, etc.). For example, footprint becomes somewhat irrelevant >if the performance of the dCDN doesn't meet an SLA. It doesn't matter >how close the dCDN is to the client. If the dCDN can't deliver the >content in a timely manner or with sufficient throughput, the uCDN >should pick a different dCDN. I'm mostly on the same page as you (especially about 3), though I suspect that your point 2 applies as well to point 1: the capabilities will also largely be a matter for the contracts. I heartily concur that decisions in the future, like decisions today, will depend mostly on factors like you describe in 5: quotas, performance and so on. >> >> This work would need to be resumed and made far more concrete for this >>to >> be a viable approach. >... or deferred so we can get a basic Footprint and Capabilities >Interface specified. Most likely the dCDN will want to advertise global >coverage (to maximize their perceived utility). The exception is an ISP >CDN that only wants to serve content for their own clients. Thus, a >specific footprint is defined which probably correlates with the ISP's >address space advertised via E-BGP. Agreed that incremental updates don't need to be a day-one feature, and that dCDNs are likely to advertise global coverage. If everyone could have agreed two years ago that footprint just meant what prefixes you advertise in BGP... we would have been done two years ago. >> >>[snip] >> where providing even a mock-up of the JSON encoding for capabilities in >> ALTO is probably impossible today. >If we simplify the requirements, we might conclude that a RESTful POST >from the dCDN that describes the capabilities and the associated >footprint is all we need. What the uCDN needs to know is the >availability of the dCDN's ability to route content requests. The >recursive mode is no problem, but the iterative mode may be a problem. >Having a periodic HTTP POST from the dCDN to the uCDN may serve as a >'keep-alive' for a given capability and footprint. I'm not sure I can go that far. If we grant that FCI is worth sharing at all, I think it's still useful for a uCDN to get able to send a GET to the dCDN to request its FCI state. It doesn't incur any additional complexity that I can see. Moreover, you do need to talk about things like error handling, and the encoding and processing of the FCI information itself, for this to be more than just a sketch. It's not just "use REST and we're done." >We can focus on enhancing the granularity of the advertisement in a >subsequent release. You are certainly right to counsel that we not require that either of these proposals do everything out of the gate. From internet-drafts@ietf.org Thu Feb 13 05:10:13 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E655F1A0237; Thu, 13 Feb 2014 05:10:13 -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 xR7lrxC3lkJL; Thu, 13 Feb 2014 05:10:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F39811A0236; Thu, 13 Feb 2014 05:10:11 -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.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140213131011.12134.40084.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 05:10:11 -0800 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-logging-09.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: Thu, 13 Feb 2014 13:10:14 -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-09.txt Pages : 45 Date : 2014-02-13 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-logging-09 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 flefauch@cisco.com Thu Feb 13 05:20:03 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 C8FF41A0244 for ; Thu, 13 Feb 2014 05:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 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.548, 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 htALvs0lB34Z for ; Thu, 13 Feb 2014 05:20:01 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id C82351A0243 for ; Thu, 13 Feb 2014 05:20:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2229; q=dns/txt; s=iport; t=1392297601; x=1393507201; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dCxAXQXfHHav67dJwVNY+Ilrj06QhYzP8XAT6SIjtOI=; b=d9Yx8b1PwZsXl8ymd835Hextdiuib2DX0YvOt5TBG30zqkr4gAh2BkhN YGwn01MAdy+ehoGwLWumUmkWVCszTyXmpHKEYMs/U/c6erishHJqxAHrQ pFDHQ0yO0GNi9Aj/uyRNae5vPpG3YtL8A0qogJVBbHSXyzSk8mX4vMIIY g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFAGfF/FKtJV2d/2dsb2JhbABZgwY4UQa/S4EWFnSCJQEBAQMBAQEBNzQLEAIBCDYQJwslAgQOBQmHdAgIBcg2F45GMweDJIEUBJgsgTKQcYMtgio X-IronPort-AV: E=Sophos;i="4.95,838,1384300800"; d="scan'208";a="20153925" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-1.cisco.com with ESMTP; 13 Feb 2014 13:20:00 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1DDK0ZJ013260 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 13:20:00 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 07:20:00 -0600 From: "Francois Le Faucheur (flefauch)" To: Kevin J Ma Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-logging-09.txt Thread-Index: AQHPKLzwyQVwxW4CdEOqzBoL7rRz05qzj7KA Date: Thu, 13 Feb 2014 13:19:59 +0000 Message-ID: References: <20140213131011.12134.40084.idtracker@ietfa.amsl.com> In-Reply-To: <20140213131011.12134.40084.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 Cc: "cdni@ietf.org" Subject: Re: [CDNi] 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: Thu, 13 Feb 2014 13:20:04 -0000 Hi Kevin and all, We just posted the updated version of cdni-logging that addresses Kevin's r= eview comments as discussed on the list (including latest comment about pri= vacy). Could you please review and let us know if you have additional comments bef= ore we move on to the next step (as agreed in Vancouver) which is to submit= the document to Working Group Last Call? Thanks Francois & Iuniana On 13 Feb 2014, at 14:10,

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-09.txt > Pages : 45 > Date : 2014-02-13 >=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-09 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-09 >=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 flefauch@cisco.com Thu Feb 13 06:23: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 D9C0D1A0240 for ; Thu, 13 Feb 2014 06:23:16 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, 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 r6_9VkwZ_bi3 for ; Thu, 13 Feb 2014 06:23:12 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id E01911A0237 for ; Thu, 13 Feb 2014 06:23:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36376; q=dns/txt; s=iport; t=1392301391; x=1393510991; h=from:to:cc:subject:date:message-id:references: mime-version; bh=sgVc2a37k2blJyWOW/mRf9see5mKUTAzVechZrD8iJI=; b=YbBKhxeIqk7QW0Nb53ha0VxcHp+dxYnFuWpsoLso+xXeSeOG7PdSi3cK 158H7IkgY/+ObnvRoH/6Ki6rqHhfGiiStwxcbuiHSgofnDslHeVBOq+4S /is3YxhU33xdOlEbq4XKn8EKpEeU6m7q1PYDKZqn3KaT4SJfp4btRb+zM o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0HANzU/FKtJXG8/2dsb2JhbABZgwY4UQa2eIhUgRYWdIIlAQEBBAEBARdUCxACARkDAQIhBwcnCxQJCAIEDgUJh3wIBcgNF44lMhENBAYHA4ImdYEUBJRDg2mBMpBxgy2CKg X-IronPort-AV: E=Sophos;i="4.95,838,1384300800"; d="scan'208,217";a="20168832" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-1.cisco.com with ESMTP; 13 Feb 2014 14:23:10 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1DENAaQ007010 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 14:23:10 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 08:23:09 -0600 From: "Francois Le Faucheur (flefauch)" To: "draft-ietf-cdni-redirection@tools.ietf.org" Thread-Topic: New version of draft-ietf-cdni-redirection for London Thread-Index: AQHPKMcea361Oq5WPECHoF//X7Rgxw== Date: Thu, 13 Feb 2014 14:23:09 +0000 Message-ID: <5B81A942-EEB2-488D-BDC9-2493EEF78264@cisco.com> References: <38D49197-8105-4F01-B65D-A8E649F2C33E@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: multipart/alternative; boundary="_000_5B81A942EEB2488DBDC92493EEF78264ciscocom_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] New version of draft-ietf-cdni-redirection for London 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 Feb 2014 14:23:17 -0000 --_000_5B81A942EEB2488DBDC92493EEF78264ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable To authors of draft-ietf-cdni-redirection, Could you please rev up the document for the London Meeting? Note that the Cut-off date is Friday 14 Feb (ie tomorrow). A number of points to be addressed were raised in Vancouver (including how = to deal with errors). Also, my review comments from November 2013 (see belo= w) still need to be addressed. Thanks Francois Begin forwarded message: From: "Francois Le Faucheur (flefauch)" > Subject: [CDNi] Coments on draft-ietf-cdni-redirection-01.txt Date: 6 November 2013 05:02:38 CET To: Ben Niven-Jenkins > Cc: "cdni@ietf.org" > Ben and all, Some comments: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D *** OLD: " If the RI is used between the uCDN and one or more dCDNs. The dCDN's RI response may contain a Redirection Target ... " NEW: " If the RI is used between the uCDN and one or more dCDNs, the dCDNs' RI response will typically contain a Redirection Target ... " *** OLD: " where the attributes of a User Agent's requests are encapsulated along with any other data that can aid the downstream CDN in processing the requests. The RI response encapsulates the attributes " NEW: " where the attributes of a User Agent's requests are conveyed along with any other data that can aid the downstream CDN in processing the requests. The RI response conveys the attributes " [as discussed before, "encapsulates" incorrectly suggests they are conveyed= by embedding their native format] *** OLD: " To assist the routing decision of a Downstream CDN, the Upstream CDN shall convey as much information as possible to the Downstream CDN, for example the URI of the requested content and the User Agent's location information, when those are known by the uCDN Request Routing system. " NEW: " To assist the routing decision of a Downstream CDN, the Upstream CDN conveys the necessary information to the Downstream CDN, for example the URI of the requested content and the User Agent's location information, when those are known by the uCDN Request Routing system. Based on its policy, the Upstream CDN can decide to also = convey additional information about the request (e.g. HTTP request headers)= to allow the Downstream CDN to make a more informed decision. " *** section 4.2, table illustrating "Top-Level keys in RI requests/response= s" The table (or the text that follow it) needs to indicate more exhaustively = which key is Mandatory or not (separately for request and for response). *** section 4.2, table illustrating "Top-Level keys in RI requests/response= s" "Transit CDNs should check the cdn-path and not cascade the RI request to d= ownstream CDNs that are already listed in cdn-path." This wording is redun= dant with some text further in teh document also discussing use of cdn-path= and it is not worded properly with RFC2119 keywords. I suggest removing it= from the table. *** OLD: " The dns dictionary of a RI request for DNS based redirection MUST contain the following keys: resolver-ip, qtype, qclass, qname and the value of each MUST be the value of the appropriate part of the User Agent's DNS query/request. " NEW: " The dns dictionary of a RI request for DNS based redirection MUST contain all the keys identified as Mandatory in the table above, and the value of each MUST be the value of the appropriate part of the User Agent's DNS query/request. " [In general, I think the doc needs a good clean-up to provide more exchaust= ive description of what is mandatory and what is not and better use of RFC2= 119 terminology] *** section 4.4.2 " For DNS based redirection the dCDN needs to return one of the following to the uCDN in the RI response: o The IP address of (or a CNAME to) the RT (if the dCDN is performing DNS based redirection); or o The IP address of (or a CNAME to) a RT which is a Request Router (if the dCDN is performing HTTP based redirection). " It is a little confusing to read that "for DNS-based redirection, the dCDN = needs to return =85 (if the dCDN is performing HTTP based redirection)". So= you need to distinguish more explicitely between the redirection method us= ed between the USer Agent & uCDN versus the redirection method used by the= dCDN. This probably affects also 4.4.1 (and 4.5) since its title refers t= o the redirection method used between the User Agent & uCDN. *** section 4.4.2 OLD: " Response must contain at least one of a, aaaa, cname. " NEW: " RI Response for DNS based redirection MUST contain all the keys identified = as Mandatory in the table above, as well as at least one of a, aaaa, cname. " *** section 4.4.2 why is the name in the response called "name" while it is called "name" in = the query? Should it not be also called "qname" (if it is always is equal t= o the qname of the query) or "rename" (if it can be different in some situa= tions)? *** OLD: " The http dictionary of a RI request for HTTP based redirection MUST contain the following keys: c-ip, cs-method, cs-version and cs-uri and the value of each MUST be the value of the appropriate part of the User Agent's DNS query/request. " NEW: " The http dictionary of a RI request for HTTP based redirection MUST contain all the keys identifed as Mandatory in the previous table and the= value of each MUST be the value of the appropriate part of the User Agent= 's HTTP request. " *** section 4.6 " Additionally, an RI response MUST NOT be reused unless the request from the User Agent would generate an identical RI request to the dCDN as the one that resulted in the cached RI response. " This "MUST NOT" statement is immediately contradicted by the subsequent par= agraph introducing the notion of Scope. So it cannot stay as is. Also, you need to discuss the case of a request with everything identical e= xcept with different HTTP headers. That woudl generate a different RI reque= st, yet can you reuse a previous RI response or not? *** section 4.6: OLD: " "http": { "sc-status": 302, "cs-uri": "http://www.example.com" "sc-location": "http://sur1.dcdn.example/ucdn/example.com", " NEW: " "http": { "sc-status": 302, "cs-uri": "http://www.example.com/movie100.mp4" "sc-location": "http://sur1.dcdn.example/ucdn/example/movie100.mp4", " *** section 4.7: " [[Editor's note: We've tried to keep error specification light weight & provide the hooks needed to help with debugging without trying to be overly prescriptive " I see the intent, but I don't get what you are proposing exactly: to not de= fine error values at all? to define a few only and allow implementations to= easily define others with (or without?) registering those before? Perhaps this could be achieved by creating a name based registry, with very= easy allocation of new names. *** section 4.8: In general, the text of that section could read better. There is overlap between the 3rd paragraph and the first one. OLD: " In order to prevent and detect RI request loops, each CDN MUST insert its CDN Provider ID into the cdn-path key of every RI request it originates or cascades. " NEW: " In order to prevent and detect RI request loops, each CDN MUST insert its CDN Provider ID into the cdn-path key of every RI request it originates, and MUST append its CDN Provider ID into the cdn-path key of = every RI request it cascades. " OLD: " Transit CDNs should check the cdn-path and not cascade the RI request to downstream CDNs that are already listed in cdn-path. CDNs MUST NOT propagate to any downstream CDNs if the number of CDN Provider IDs in cdn-path (including the CDN's own Provider ID) is equal to or greater than max-hops. " NEW: " Transit CDNs MUST check the cdn-path and not cascade the RI request to downstream CDNs that are already listed in cdn-path. CDNs MUST NOT propagate to any downstream CDNs if the number of CDN Provider IDs in cdn-path (after appending their own CDN Provider ID) is equal to or great= er than max-hops. " *** section 5: " Information passed over the RI could be considered personal or sensitive, for example RI requests contain parts of a User Agent's original request and RI responses reveal information about the dCDN's policy for which surrogates should serve which content/user locations. " You can state after that paragraph, that a mitigation approach is for uCDN = RI implementation to support a policy that minimises the information convey= ed in the RI requests (or even possibly performs some anonimisation of the = client IP address). *** section 5: " The RI interface also provides a mechanism whereby a uCDN could probe a dCDN and infer the dCDN's edge topology by making repeated RI requests for different content and/or UA IP addresses and correlating the responses from the dCDN. Additionally the ability for a dCDN to indicate that a RI response applies more widely that the original request (via the scope dictionary) may significantly reduce the number of RI requests required to probe and infer the dCDN's edge topology. The same information could be obtained in the absence of the RI interface, but it could be more difficult to gather as it would require a distributed set of machines with a range of different IP addresses each making requests directly to the dCDN. However, the RI facilitates easier collection of such information as it enables a single client to query the dCDN for a redirection/surrogate selection on behalf of any UA IP address. " You could perhaps state that: * by definition, use of recursive redirection assumes that dCDN is willing = to provide more vsisbility to uCDN than with iterative. * if that is a concern, dCDN could mitigate the problem by somewhat obfusca= ting the information returned (eg providing hostnames/CNAMEs that do not ma= p to surrogates 1 to 1), or could return RTs that are subject to a second l= evel resolution (eg regional Request Routers) which, pushed to the extreme,= effectively degrades back to iterative redirection. * section 5: When discussing benefits of using TLS, please clarifies TLS comes "for free= " thanks to the HTTP transport of RI. Also, mention TLS also provides integrity protection (e.g. a RI response ca= nnot be modified). Editos: =3D=3D=3D=3D=3D *** s/(RI) is one of the main building blocks/(RI) is one of the building b= locks/ *** s/it is down to the uCDN to decide/it is up to the uCDN to decide/ *** s/in this draft/in this document/ [multiple occurrences] *** s/and could be extended/and could be extended in future versions/ *** s/to help the Upstream CDN with future RI requests/to help the Upstream= CDN handle future RI requests/ *** allocate a TAble number to all the tables, for easier reference in the = text. *** s/cacheable & not stale/cacheable and not stale/ *** s/It should be noted that the loop detection & prevention mechanisms de= scribed above only cover preventing and detecting loops within the RI itsel= f./It should be noted that the loop detection and prevention mechanisms des= cribed above only prevents and detects loops within the RI itself./ *** s/As well as loops with the RI itself,/In addition to loops with the RI= itself,/ On 21 Oct 2013, at 11:27, Ben Niven-Jenkins > wrote: Colleagues, This is an update to the redirection interface specification to add additio= nal editorial text around data plane loop detection, media types to use, th= e JSON encoding and the security considerations. There are still some things outstanding within the document but any review = or suggestions for additional text would be most welcome :-) Ben Begin forwarded message: From: internet-drafts@ietf.org Date: 21 October 2013 10:30:41 GMT+01:00 To: i-d-announce@ietf.org Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-redirection-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection = Working Group of the IETF. Title : Request Routing Redirection Interface for CDN Interconnec= tion Author(s) : Wang Danhua Ben Niven-Jenkins He Xiaoyan Ge Chen Ni Wei Filename : draft-ietf-cdni-redirection-01.txt Pages : 24 Date : 2013-10-21 Abstract: The Request Routing Interface comprises of (1) the asynchronous advertisement of footprint and capabilities by a downstream CDN that allows a upstream CDN to decide whether to redirect particular user requests to that downstream CDN; and (2) the synchronous operation of an upstream CDN requesting whether a downstream CDN is prepared to accept a user request and of a downstream CDN responding with how to actually redirect the user request. This document describes an interface for the latter part, i.e. the CDNI request routing/ Redirection Interface. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-redirection-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-redirection-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_5B81A942EEB2488DBDC92493EEF78264ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8EFE2AE8C64B804796B1078FF313054A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable To authors of draft-ietf-cdni-redirection,

Could you please rev up the document for the London Meeting?

Note that the Cut-off date is Friday 14 Feb (ie tomorrow).

A number of points to be addressed were raised in Vancouver (including= how to deal with errors). Also, my review comments from November 2013 (see= below) still need to be addressed.

Thanks

Francois

Begin forwarded message:

From:= "Francois Le Fauc= heur (flefauch)" <flefauch@ci= sco.com>

Subje= ct: [CDNi] Coments on draft-= ietf-cdni-redirection-01.txt

Date:= 6 November 2013 05:02:= 38 CET

To: <= /b>Ben Niven-Jenkins <ben@niven-jenkins.co.uk>

Cc: <= /b>"cdni@ietf.org" <cdni@ietf.org>

Ben and all,

Some comments:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

***
OLD:
"
If the RI is used between the uCDN
  and one or more dCDNs. The dCDN's RI response may contain= a
  Redirection Target ...
"
NEW:
"
If the RI is used between the uCDN
  and one or more dCDNs, the dCDNs' RI response will typically co= ntain a
  Redirection Target ...
"

***
OLD:
"
where the attributes of a User
  Agent's requests are encapsulated along with any other data tha= t can
  aid the downstream CDN in processing the requests. The RI= response
  encapsulates the attributes
"
NEW:
"
where the attributes of a User
  Agent's requests are conveyed along with any other data that ca= n
  aid the downstream CDN in processing the requests. The RI= response
  conveys the attributes
"
[as discussed before, "encapsulates" incorrectly suggests they ar= e conveyed by embedding their native format]

***
OLD:
"
To assist the routing decision of a Downstream CDN, the Upstream CDN
  shall convey as much information as possible to the Downstream = CDN,
  for example the URI of the requested content and the User Agent= 's
  location information, when those are known by the uCDN Request<= br>   Routing system.
"
NEW:
"
To assist the routing decision of a Downstream CDN, the Upstream CDN
  conveys the necessary information to the Downstream CDN,
  for example the URI of the requested content and the User Agent= 's
  location information, when those are known by the uCDN Request<= br>   Routing system. Based on its policy, the Upstream CDN can decid= e to also convey additional information about the request (e.g. HTTP reques= t headers) to allow the Downstream CDN to make a more informed decision.
"

*** section 4.2, table illustrating "Top-Level keys in RI requests/res= ponses"
The table (or the text that follow it) needs to indicate more exhaustively = which key is Mandatory or not (separately for request and for response).

*** section 4.2, table illustrating "Top-Level keys in RI requests/res= ponses"
"Transit CDNs should check the cdn-path and not cascade the RI request= to downstream CDNs that are already listed in cdn-path." This w= ording is redundant with some text further in teh document also discussing = use of cdn-path and it is not worded properly with RFC2119 keywords. I suggest removing it from the table.

***
OLD:
"
The dns dictionary of a RI request for DNS based redirection MUST
  contain the following keys: resolver-ip, qtype, qclass, qname a= nd the
  value of each MUST be the value of the appropriate part of the = User
  Agent's DNS query/request.
"
NEW:
"
The dns dictionary of a RI request for DNS based redirection MUST
  contain all the keys identified as Mandatory in the table above= , and the
  value of each MUST be the value of the appropriate part of the = User
  Agent's DNS query/request.
"
[In general, I think the doc needs a good clean-up to provide more exchaust= ive description of what is mandatory and what is not and better use of RFC2= 119 terminology]

*** section 4.4.2
"
  For DNS based redirection the dCDN needs to return one of the   following to the uCDN in the RI response:
  o The IP address of (or a CNAME to) the RT (if the dCDN i= s
     performing DNS based redirection); or
  o The IP address of (or a CNAME to) a RT which is a Reque= st Router
     (if the dCDN is performing HTTP based redirec= tion).
"
It is a little confusing to read that "for DNS-based redirection, the = dCDN needs to return =85 (if the dCDN is performing HTTP based redirection)= ". So you need to distinguish more explicitely between the redirection= method used between the USer Agent & uCDN versus the redirection method used by the dCDN. This probably affects also 4.4.1 = (and 4.5) since its title refers to the redirection method used betwe= en the User Agent & uCDN.

*** section 4.4.2
OLD:
"
Response must contain at least one of a, aaaa, cname.
"
NEW:
"
RI Response for DNS based redirection MUST contain all the keys identified = as Mandatory in the table above, as well as at least one of a, aaaa, cname.=
"

*** section 4.4.2
why is the name in the response called "name" while it is called = "name" in the query? Should it not be also called "qname&quo= t; (if it is always is equal to the qname of the query) or "rename&quo= t; (if it can be different in some situations)?

***
OLD:
"
The http dictionary of a RI request for HTTP based redirection MUST
  contain the following keys: c-ip, cs-method, cs-version and cs-= uri
  and the value of each MUST be the value of the appropriate part= of
  the User Agent's DNS query/request.
"
NEW:
"
The http dictionary of a RI request for HTTP based redirection MUST
  contain all the keys identifed as Mandatory in the previous tab= le and the value of each MUST be the value of the appropriate part of = ;the User Agent's HTTP request.
"

*** section 4.6
"
Additionally, an RI response MUST NOT be reused unless the request
  from the User Agent would generate an identical RI request to t= he
  dCDN as the one that resulted in the cached RI response.
"
This "MUST NOT" statement is immediately contradicted by the subs= equent paragraph introducing the notion of Scope. So it cannot stay as is.<= br> Also, you need to discuss the case of a request with everything identical e= xcept with different HTTP headers. That woudl generate a different RI reque= st, yet can you reuse a previous RI response or not?

*** section 4.6:
OLD:
"
    "http": {
      "sc-status": 302,
      "cs-uri": "http://www.example.com"
      "sc-location":
        "http://sur1.dcdn.example/ucdn/example.com<= /a>",
"
NEW:
"
    "http": {
      "sc-status": 302,
      "cs-uri": "http://www.example.com/movie100.mp4&= quot;
      "sc-location":
        "http://sur1.dcdn.example/ucdn/exa= mple/movie100.mp4",
"

*** section 4.7:
"
[[Editor's note: We've tried to keep error specification light weight
  & provide the hooks needed to help with debugging without t= rying to
  be overly prescriptive
"
I see the intent, but I don't get what you are proposing exactly: to not de= fine error values at all? to define a few only and allow implementations to= easily define others with (or without?) registering those before?
Perhaps this could be achieved by creating a name based registry, with very= easy allocation of new names.

*** section 4.8: In general, the text of that section could read better. There is overlap between the 3rd paragraph and the first one.
OLD:
"
In order to prevent and detect RI request loops, each CDN MUST insert
  its CDN Provider ID into the cdn-path key of every RI request i= t
  originates or cascades.
"
NEW:
"
In order to prevent and detect RI request loops, each CDN MUST insert
  its CDN Provider ID into the cdn-path key of every RI request i= t
  originates, and MUST append its CDN Provider ID into the cdn-pa= th key of every RI request it
  cascades.
"

OLD:
"
Transit CDNs
  should check the cdn-path and not cascade the RI request to
  downstream CDNs that are already listed in cdn-path. CDNs= MUST NOT
  propagate to any downstream CDNs if the number of CDN Provider = IDs in
  cdn-path (including the CDN's own Provider ID) is equal to or g= reater
  than max-hops.
"
NEW:
"
Transit CDNs
  MUST check the cdn-path and not cascade the RI request to
  downstream CDNs that are already listed in cdn-path. CDNs= MUST NOT
  propagate to any downstream CDNs if the number of CDN Provider = IDs in
  cdn-path (after appending their own CDN Provider ID) is equal t= o or greater
  than max-hops.
"

*** section 5:
"
Information passed over the RI could be considered personal or
  sensitive, for example RI requests contain parts of a User Agen= t's
  original request and RI responses reveal information about the = dCDN's
  policy for which surrogates should serve which content/user
  locations.
"
You can state after that paragraph, that a mitigation approach is for uCDN = RI implementation to support a policy that minimises the information convey= ed in the RI requests (or even possibly performs some anonimisation of the = client IP address).

*** section 5:
"

  The RI interface also provides a mechanism whereby a uCDN could= probe
  a dCDN and infer the dCDN's edge topology by making repeated RI=
  requests for different content and/or UA IP addresses and corre= lating
  the responses from the dCDN. Additionally the ability for= a dCDN to
  indicate that a RI response applies more widely that the origin= al
  request (via the scope dictionary) may significantly reduce the=
  number of RI requests required to probe and infer the dCDN's ed= ge
  topology.
  The same information could be obtained in the absence of the RI=
  interface, but it could be more difficult to gather as it would=
  require a distributed set of machines with a range of different= IP
  addresses each making requests directly to the dCDN. Howe= ver, the RI
  facilitates easier collection of such information as it enables= a
  single client to query the dCDN for a redirection/surrogate sel= ection
  on behalf of any UA IP address.
"
You could perhaps state that:
* by defini= tion, use of recursive redirection assumes that dCDN is willing to provide = more vsisbility to uCDN than with iterative.
* if that i= s a concern, dCDN could mitigate the problem by somewhat obfuscating the in= formation returned (eg providing hostnames/CNAMEs that do not map to surrog= ates 1 to 1), or could return RTs that are subject to a second level resolution (eg regional Request Routers) whi= ch, pushed to the extreme, effectively degrades back to iterative redirecti= on.

* section 5:
When discussing benefits of using TLS, please clarifies TLS comes "for= free" thanks to the HTTP transport of RI.
Also, mention TLS also provides integrity protection (e.g. a RI response ca= nnot be modified).

Editos:
=3D=3D=3D=3D=3D

*** s/(RI) is one of the main building blocks/(RI) is one of the building b= locks/
*** s/it is down to the uCDN to decide/it is up to the uCDN to decide/
*** s/in this draft/in this document/   [multiple occurrences] *** s/and could be extended/and could be extended in future versions/
*** s/to help the Upstream CDN with future RI requests/to help the Upstream= CDN handle future RI requests/
*** allocate a TAble number to all the tables, for easier reference in the = text.
*** s/cacheable & not stale/cacheable and not stale/
*** s/It should be noted that the loop detection & prevention mechanism= s described above only cover preventing and detecting loops within the RI i= tself./It should be noted that the loop detection and prevention mechanisms= described above only prevents and detects loops within the RI itself./
*** s/As well as loops with the RI itself,/In addition to loops with the RI= itself,/

On 21 Oct 2013, at 11:27, Ben Niven-Jenkins <ben@niven-jenkins.co.uk> wrote:

Colleagues,

This is an update to the redirection interface specification to add additio= nal editorial text around data plane loop detection, media types to use, th= e JSON encoding and the security considerations.

There are still some things outstanding within the document but any review = or suggestions for additional text would be most welcome :-)

Ben

Begin forwarded message:

From: internet-drafts@ietf.org
Date: 21 October 2013 10:30:41 GMT+01:00
To: i-d-announce@ietf.org
Cc: cdni@ietf.org
Subject: [CDNi] I-D Action: draft-ietf-cdni-redirection-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Content Delivery Networks Interconnection = Working Group of the IETF.

Title = ;         : Request Routing Re= direction Interface for CDN Interconnection
Author(s) &= nbsp;     : Wang Danhua
            &nb= sp;          Ben Niven-Je= nkins
            &nb= sp;          He Xiaoyan             &nb= sp;          Ge Chen
            &nb= sp;          Ni Wei
Filename &n= bsp;      : draft-ietf-cdni-redirection-01.tx= t
Pages = ;         : 24
Date =           : 2013-10-21
Abstract:
The Request Routing Interface comprises of (1) the asynchronous
advertisement of footprint and capabilities by a downstream CDN that
allows a upstream CDN to decide whether to redirect particular user
requests to that downstream CDN; and (2) the synchronous operation of
an upstream CDN requesting whether a downstream CDN is prepared to
accept a user request and of a downstream CDN responding with how to
actually redirect the user request. This document describes an
interface for the latter part, i.e. the CDNI request routing/
Redirection Interface.

The IETF datatracker status page for this draft is:
ht= tps://datatracker.ietf.org/doc/draft-ietf-cdni-redirection

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

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

Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

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

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

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

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

--_000_5B81A942EEB2488DBDC92493EEF78264ciscocom_-- From flefauch@cisco.com Thu Feb 13 06:58:09 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 17DB91A02A8 for ; Thu, 13 Feb 2014 06:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.742 X-Spam-Level: X-Spam-Status: No, score=-12.742 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_74=0.6, J_CHICKENPOX_84=0.6, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 3aAcUY3RJvhK for ; Thu, 13 Feb 2014 06:58:06 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6951A0295 for ; Thu, 13 Feb 2014 06:58:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=931; q=dns/txt; s=iport; t=1392303484; x=1393513084; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=gVP/v7njEKnFrQsqX5K66+bkE+NAWQpCKE1oPfC9xwc=; b=WaW033o/c8XOn4f9SeGUYb613hsVcc4QEGHsvtpF6XxLguRV4xZaZJb+ KbVLef4J1khZIAYqejtUNRguV/9bIpII9hruDNcMBG+WRK9jRJ2GiIzB/ pBICyBTmXe5Iij8dUoHI/gFf8gCOxkEMDDX2lnqD6sSnZPdWafRa7AsNU c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AosjAErc/FKtJXHA/2dsb2JhbABZgwaBD79MDoEJFnSCLHkSAYEAJwQOiArICxeOJVSDK4EUBJgskiODLYIq X-IronPort-AV: E=Sophos;i="4.95,838,1384300800"; d="scan'208";a="303835892" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 13 Feb 2014 14:58:04 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1DEw3pg019798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 14:58:03 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 08:58:03 -0600 From: "Francois Le Faucheur (flefauch)" To: "draft-ietf-cdni-control-triggers@tools.ietf.org" Thread-Topic: draft-ietf-cdni-control-triggers Thread-Index: AQHPKMv++QtTMdL67E+SFhDF3O/+Tw== Date: Thu, 13 Feb 2014 14:58:02 +0000 Message-ID: <4F542BB4-A585-4926-B5EA-1FD24FA89822@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: <0CD1CF78A36F474E989887604164DEA3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] draft-ietf-cdni-control-triggers 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 Feb 2014 14:58:09 -0000 To authors of draft-ietf-cdni-control-triggers, Version -02 was published in Dec 2013 i.e. after Vancouver. Are there remaining open items on this document? If yes, can you post a new rev for London? Cheers Francois: PS: whenever, you post a new rev, please fix a number of formatting issues = (skipped lines at the wrong spot) that makes the doc less readable. For exa= mple: OLD: " Mandatory: Yes Property: etime =93 NEW: =93 Mandatory: Yes Property: etime =93 OLD: =93 Mandatory: Yes. Property: metadata.urls, content.urls, metadata.patterns, content.patterns Description: Metadata and content references copied from the =93 NEW: =93 Mandatory: Yes. =20 Property: metadata.urls, content.urls, metadata.patterns, content.patterns Description: Metadata and content references copied from the "= From nobody Thu Feb 13 09:45:40 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 5495C1A038B for ; Thu, 13 Feb 2014 09:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.248 X-Spam-Level: X-Spam-Status: No, score=-1.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_74=0.6, J_CHICKENPOX_84=0.6, RP_MATCHES_RCVD=-0.548] 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 x2yfzvMM3bQo for ; Thu, 13 Feb 2014 09:45:33 -0800 (PST) Received: from owa.velocix.com (mail-out1.velocix.com [81.134.152.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9BACA1A036E for ; Thu, 13 Feb 2014 09:45:32 -0800 (PST) Received: from EXB01-MLT.corp.velocix.com ([169.254.2.235]) by EXC00CAM.corp.velocix.com ([172.18.4.40]) with mapi id 14.02.0347.000; Thu, 13 Feb 2014 17:45:29 +0000 From: Rob Murray To: "Francois Le Faucheur (flefauch)" Thread-Topic: draft-ietf-cdni-control-triggers Thread-Index: AQHPKMv++QtTMdL67E+SFhDF3O/+T5qzdS0A Date: Thu, 13 Feb 2014 17:45:29 +0000 Message-ID: <49C77373835C5A479BC2A84B2A1D66BD8EE923B1@EXB01-MLT.corp.velocix.com> References: <4F542BB4-A585-4926-B5EA-1FD24FA89822@cisco.com> In-Reply-To: <4F542BB4-A585-4926-B5EA-1FD24FA89822@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [81.134.152.4] 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/SznfYoaCjOkEOyYt36pWH_j47LU Cc: "draft-ietf-cdni-control-triggers@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] draft-ietf-cdni-control-triggers 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 Feb 2014 17:45:34 -0000 Hi Francois, No open items apart from the formatting problems you've spotted, we'll fix = those in the next rev - even if nothing else comes up, we'll at least need = to update refs after the London meeting. It looks like I forgot to email the list describing the -02 revision... it = was mainly to update the JSON link format, as discussed in Vancouver. It al= so had some updated refs, and removed a redundant "editor's note" about whe= ther to use http or https. Cheers, Rob. On 13 Feb 2014, at 14:58, Francois Le Faucheur (flefauch) wrote: > To authors of draft-ietf-cdni-control-triggers, >=20 > Version -02 was published in Dec 2013 i.e. after Vancouver. > Are there remaining open items on this document? > If yes, can you post a new rev for London? >=20 > Cheers >=20 > Francois: >=20 > PS: whenever, you post a new rev, please fix a number of formatting issue= s (skipped lines at the wrong spot) that makes the doc less readable. For e= xample: >=20 > OLD: > " > Mandatory: Yes > Property: etime > =93 > NEW: > =93 > Mandatory: Yes >=20 > Property: etime > =93 >=20 >=20 > OLD: > =93 > Mandatory: Yes. > Property: metadata.urls, content.urls, metadata.patterns, > content.patterns >=20 > Description: Metadata and content references copied from the > =93 > NEW: > =93 > Mandatory: Yes. >=20 > Property: metadata.urls, content.urls, metadata.patterns, > content.patterns > Description: Metadata and content references copied from the > " From nobody Thu Feb 13 17:27:05 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 EFAD51A0053 for ; Thu, 13 Feb 2014 17:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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.548, 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 IzE0Y2zX-06p for ; Thu, 13 Feb 2014 17:27:00 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id CE9E41A000E for ; Thu, 13 Feb 2014 17:27:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3326; q=dns/txt; s=iport; t=1392341220; x=1393550820; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=GzeyGm2h0mSpU0bCBt+9FZGA/KaPOz5vN5LwkOb42ok=; b=F7pT2dgQkhZMl6FvGk2x3qCYh2XAuEOPzH+K294JVS+r4vCjevqWuI60 7t1/Mekx3HD9JjZisi+JYyWxv99Htdyslolp19O+3npGUM/D87W4fHUMp ftjVxP6VDVfhfWcdXX2r9sjS9HxXXYtc25vKzzyWFru7xnBNKXIKKCNCL k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAD5w/VKtJXG8/2dsb2JhbABZgwY4UQaDALxSGIEBFnSCJQEBAQQjEUMOBAIBCBEEAQEDAgYdAwICAjAUAQYBAQUDAgQTCAGHfAgFpk6iEReBKY0fOAaCaTWBFASZXpBxgy2BaiQc X-IronPort-AV: E=Sophos;i="4.95,842,1384300800"; d="scan'208";a="303950998" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 14 Feb 2014 01:26:59 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1E1Qxqw023887 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 14 Feb 2014 01:26:59 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.95]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 19:26:59 -0600 From: "Kent Leung (kleung)" To: "cdni@ietf.org" Thread-Topic: New Version Notification for draft-leung-cdni-uri-signing-04.txt Thread-Index: AQHPKSE/6bfrvz+NZUu2V+2oz9AUzpqz8KrA Date: Fri, 14 Feb 2014 01:26:58 +0000 Message-ID: References: <20140214010816.22518.21143.idtracker@ietfa.amsl.com> In-Reply-To: <20140214010816.22518.21143.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.75.61] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/t6U7Syh93Y5UEWqQ2hYKTu5wDuI Subject: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-04.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: Fri, 14 Feb 2014 01:27:03 -0000 RllJLiBUaGlzIG5ldyB2ZXJzaW9uIGFkZHJlc3NlZCBzb21lIG9mIHRoZSBpc3N1ZXMgYW5kIGNv bW1lbnRzIHJhaXNlZCBkdXJpbmcgbGFzdCBJRVRGIHNlc3Npb24uIFRoZSBrZXkgY2hhbmdlcyBh cmU6DQoNCi0gVXBkYXRlZCB0aGUgZG9jdW1lbnQgdG8gYmUgaW4gbGluZSB3aXRoIHRoZSBuZXcg YXBwcm9hY2ggb2YgbWFuZGF0b3J5IHBhY2thZ2luZyBhbmQgZW5jYXBzdWxhdGVkIGluZm9ybWF0 aW9uIGVsZW1lbnRzLg0KLSBPbmx5IG9uZSBhdHRyaWJ1dGUgaW4gdGhlIFVSSSBxdWVyeSBzdHJp bmcgaXMgdXNlZCBmb3IgVVJJIFNpZ25pbmcuIFRoZSBhdHRyaWJ1dGUgbmFtZSBpcyBwcm92aWRl ZCBieSBDRE5JIG1ldGFkYXRhIG9yIHZpYSBjb25maWd1cmF0aW9uLg0KLSBBZGp1c3RlZCBzZWN0 aW9uIDIgdG8gbWFrZSBhIGNsZWFyIGRpc3RpbmN0aW9uIGJldHdlZW4gYW4gaW5mb3JtYXRpb24g ZWxlbWVudCAodGhlIHRocmVlIGNhdGVnb3JpZXMpIGFuZCB0aGUgcGFja2FnaW5nIGF0dHJpYnV0 ZS4gDQotIEZpeGVkIGluY29uc2lzdGVuY2llcyBhbmQgZXJyb3JzIGluIHRoZSBkb2N1bWVudCB3 aGljaCBhZGRyZXNzZWQgS2V2aW4ncyBjb21tZW50cw0KDQpLZW50DQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDEzLCAyMDE0 IDU6MDggUE0NClRvOiBSYXkgdmFuIEJyYW5kZW5idXJnOyBLZW50IExldW5nIChrbGV1bmcpOyBC aWxsIERvd25leTsgQmlsbCBEb3duZXk7IFNjb3R0IExlaWJyYW5kOyBTY290dCBMZWlicmFuZDsg S2VudCBMZXVuZyAoa2xldW5nKTsgRnJhbmNvaXMgTGUgRmF1Y2hldXIgKGZsZWZhdWNoKTsgUmF5 IHZhbiBCcmFuZGVuYnVyZzsgRnJhbmNvaXMgTGUgRmF1Y2hldXIgKGZsZWZhdWNoKQ0KU3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1sZXVuZy1jZG5pLXVyaS1zaWdu aW5nLTA0LnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1sZXVuZy1jZG5pLXVy aS1zaWduaW5nLTA0LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBLZW50 IExldW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0 LWxldW5nLWNkbmktdXJpLXNpZ25pbmcNClJldmlzaW9uOgkwNA0KVGl0bGU6CQlVUkkgU2lnbmlu ZyBmb3IgQ0ROIEludGVyY29ubmVjdGlvbiAoQ0ROSSkNCkRvY3VtZW50IGRhdGU6CTIwMTQtMDIt MTMNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTM0DQpVUkw6ICAgICAg ICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGV1bmctY2Ru aS11cmktc2lnbmluZy0wNC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1sZXVuZy1jZG5pLXVyaS1zaWduaW5nLw0KSHRtbGl6ZWQ6ICAg ICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxldW5nLWNkbmktdXJpLXNpZ25p bmctMDQNCkRpZmY6ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1sZXVuZy1jZG5pLXVyaS1zaWduaW5nLTA0DQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1 bWVudCBkZXNjcmliZXMgaG93IHRoZSBjb25jZXB0IG9mIFVSSSBzaWduaW5nIHN1cHBvcnRzIHRo ZQ0KICAgY29udGVudCBhY2Nlc3MgY29udHJvbCByZXF1aXJlbWVudHMgb2YgQ0ROSSBhbmQgcHJv cG9zZXMgYSBVUkkNCiAgIHNpZ25pbmcgc2NoZW1lLg0KDQogICBUaGUgcHJvcG9zZWQgVVJJIHNp Z25pbmcgbWV0aG9kIHNwZWNpZmllcyB0aGUgaW5mb3JtYXRpb24gbmVlZGVkIHRvDQogICBiZSBp bmNsdWRlZCBpbiB0aGUgVVJJIGFuZCB0aGUgYWxnb3JpdGhtIHVzZWQgdG8gYXV0aG9yaXplIGFu ZCB0bw0KICAgdmFsaWRhdGUgYWNjZXNzIHJlcXVlc3RzIGZvciB0aGUgY29udGVudCByZWZlcmVu Y2VkIGJ5IHRoZSBVUkkuICBTb21lDQogICBvZiB0aGUgaW5mb3JtYXRpb24gbWF5IGJlIGFjY2Vz c2VkIGJ5IHRoZSBDRE4gdmlhIGNvbmZpZ3VyYXRpb24gb3INCiAgIENETkkgbWV0YWRhdGEuDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0 Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Fri Feb 14 01:30: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 80D6C1A00BA for ; Fri, 14 Feb 2014 01:30: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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvmKeZmZ7T-l for ; Fri, 14 Feb 2014 01:30:28 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 979541A00A8 for ; Fri, 14 Feb 2014 01:30:28 -0800 (PST) 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 1WEF6G-0007g8-Ie; Fri, 14 Feb 2014 09:30:25 +0000 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Ben Niven-Jenkins In-Reply-To: <5B81A942-EEB2-488D-BDC9-2493EEF78264@cisco.com> Date: Fri, 14 Feb 2014 09:30:21 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <331F008B-634B-4C7B-892E-34AB382750B6@niven-jenkins.co.uk> References: <38D49197-8105-4F01-B65D-A8E649F2C33E@cisco.com> <5B81A942-EEB2-488D-BDC9-2493EEF78264@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/uX3rGBZ06L2Z2xYeEDSSux77bGw Cc: "draft-ietf-cdni-redirection@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] New version of draft-ietf-cdni-redirection for London 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 Feb 2014 09:30:33 -0000 Francois, On 13 Feb 2014, at 14:23, Francois Le Faucheur (flefauch) wrote: > To authors of draft-ietf-cdni-redirection, >=20 > Could you please rev up the document for the London Meeting? >=20 > Note that the Cut-off date is Friday 14 Feb (ie tomorrow). I don't have the cycles to up rev the document today. In Vancouver you were going to try and find someone with some cycles to = help with the editing, how is that progressing? Although I haven't managed to do anything to the draft itself, I have = managed to spend some time going over the draft and identifying a list = of edits that need to be made (including your comments below) and open = items (such as errors) along with some thoughts on how to resolve them. = Unfortunately, I haven't had any time to fold them into the draft as = actual text. Regards Ben >=20 > A number of points to be addressed were raised in Vancouver (including = how to deal with errors). Also, my review comments from November 2013 = (see below) still need to be addressed. >=20 > Thanks >=20 > Francois >=20 > Begin forwarded message: >=20 >> From: "Francois Le Faucheur (flefauch)" >> Subject: [CDNi] Coments on draft-ietf-cdni-redirection-01.txt >> Date: 6 November 2013 05:02:38 CET >> To: Ben Niven-Jenkins >> Cc: "cdni@ietf.org" >>=20 >> Ben and all, >>=20 >> Some comments: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> *** >> OLD: >> " >> If the RI is used between the uCDN >> and one or more dCDNs. The dCDN's RI response may contain a >> Redirection Target ...=20 >> " >> NEW: >> " >> If the RI is used between the uCDN >> and one or more dCDNs, the dCDNs' RI response will typically = contain a >> Redirection Target ...=20 >> " >>=20 >>=20 >> *** >> OLD: >> " >> where the attributes of a User >> Agent's requests are encapsulated along with any other data that = can >> aid the downstream CDN in processing the requests. The RI response >> encapsulates the attributes >> " >> NEW: >> " >> where the attributes of a User >> Agent's requests are conveyed along with any other data that can >> aid the downstream CDN in processing the requests. The RI response >> conveys the attributes >> " >> [as discussed before, "encapsulates" incorrectly suggests they are = conveyed by embedding their native format] >>=20 >>=20 >> *** >> OLD: >> " >> To assist the routing decision of a Downstream CDN, the Upstream CDN >> shall convey as much information as possible to the Downstream CDN, >> for example the URI of the requested content and the User Agent's >> location information, when those are known by the uCDN Request >> Routing system. >> " >> NEW: >> " >> To assist the routing decision of a Downstream CDN, the Upstream CDN >> conveys the necessary information to the Downstream CDN, >> for example the URI of the requested content and the User Agent's >> location information, when those are known by the uCDN Request >> Routing system. Based on its policy, the Upstream CDN can decide to = also convey additional information about the request (e.g. HTTP request = headers) to allow the Downstream CDN to make a more informed decision. >>=20 >> " >>=20 >> *** section 4.2, table illustrating "Top-Level keys in RI = requests/responses" >> The table (or the text that follow it) needs to indicate more = exhaustively which key is Mandatory or not (separately for request and = for response). >>=20 >>=20 >> *** section 4.2, table illustrating "Top-Level keys in RI = requests/responses" >> "Transit CDNs should check the cdn-path and not cascade the RI = request to downstream CDNs that are already listed in cdn-path." This = wording is redundant with some text further in teh document also = discussing use of cdn-path and it is not worded properly with RFC2119 = keywords. I suggest removing it from the table. >>=20 >>=20 >> *** >> OLD: >> " >> The dns dictionary of a RI request for DNS based redirection MUST >> contain the following keys: resolver-ip, qtype, qclass, qname and = the >> value of each MUST be the value of the appropriate part of the User >> Agent's DNS query/request. >> " >> NEW: >> " >> The dns dictionary of a RI request for DNS based redirection MUST >> contain all the keys identified as Mandatory in the table above, = and the >> value of each MUST be the value of the appropriate part of the User >> Agent's DNS query/request. >> " >> [In general, I think the doc needs a good clean-up to provide more = exchaustive description of what is mandatory and what is not and better = use of RFC2119 terminology] >>=20 >>=20 >> *** section 4.4.2 >> " >> For DNS based redirection the dCDN needs to return one of the >> following to the uCDN in the RI response: >> o The IP address of (or a CNAME to) the RT (if the dCDN is >> performing DNS based redirection); or >> o The IP address of (or a CNAME to) a RT which is a Request Router >> (if the dCDN is performing HTTP based redirection). >> " >> It is a little confusing to read that "for DNS-based redirection, the = dCDN needs to return =85 (if the dCDN is performing HTTP based = redirection)". So you need to distinguish more explicitely between the = redirection method used between the USer Agent & uCDN versus the = redirection method used by the dCDN. This probably affects also 4.4.1 = (and 4.5) since its title refers to the redirection method used between = the User Agent & uCDN. >>=20 >> *** section 4.4.2 >> OLD: >> " >> Response must contain at least one of a, aaaa, cname. >> " >> NEW: >> " >> RI Response for DNS based redirection MUST contain all the keys = identified as Mandatory in the table above, as well as at least one of = a, aaaa, cname. >> " >>=20 >> *** section 4.4.2 >> why is the name in the response called "name" while it is called = "name" in the query? Should it not be also called "qname" (if it is = always is equal to the qname of the query) or "rename" (if it can be = different in some situations)? >>=20 >>=20 >> *** >> OLD: >> " >> The http dictionary of a RI request for HTTP based redirection MUST >> contain the following keys: c-ip, cs-method, cs-version and cs-uri >> and the value of each MUST be the value of the appropriate part of >> the User Agent's DNS query/request. >> " >> NEW: >> " >> The http dictionary of a RI request for HTTP based redirection MUST >> contain all the keys identifed as Mandatory in the previous table = and the value of each MUST be the value of the appropriate part of the = User Agent's HTTP request. >> " >>=20 >>=20 >> *** section 4.6 >> " >> Additionally, an RI response MUST NOT be reused unless the request >> from the User Agent would generate an identical RI request to the >> dCDN as the one that resulted in the cached RI response. >> " >> This "MUST NOT" statement is immediately contradicted by the = subsequent paragraph introducing the notion of Scope. So it cannot stay = as is. >> Also, you need to discuss the case of a request with everything = identical except with different HTTP headers. That woudl generate a = different RI request, yet can you reuse a previous RI response or not? >>=20 >>=20 >> *** section 4.6: >> OLD: >> " >> "http": { >> "sc-status": 302, >> "cs-uri": "http://www.example.com" >> "sc-location": >> "http://sur1.dcdn.example/ucdn/example.com", >> " >> NEW: >> " >> "http": { >> "sc-status": 302, >> "cs-uri": "http://www.example.com/movie100.mp4" >> "sc-location": >> "http://sur1.dcdn.example/ucdn/example/movie100.mp4", >> " >>=20 >>=20 >> *** section 4.7: >> " >> [[Editor's note: We've tried to keep error specification light weight >> & provide the hooks needed to help with debugging without trying to >> be overly prescriptive=20 >> " >> I see the intent, but I don't get what you are proposing exactly: to = not define error values at all? to define a few only and allow = implementations to easily define others with (or without?) registering = those before? >> Perhaps this could be achieved by creating a name based registry, = with very easy allocation of new names. >>=20 >>=20 >> *** section 4.8: In general, the text of that section could read = better. >> There is overlap between the 3rd paragraph and the first one. >> OLD: >> " >> In order to prevent and detect RI request loops, each CDN MUST insert >> its CDN Provider ID into the cdn-path key of every RI request it >> originates or cascades. >> " >> NEW: >> " >> In order to prevent and detect RI request loops, each CDN MUST insert >> its CDN Provider ID into the cdn-path key of every RI request it >> originates, and MUST append its CDN Provider ID into the cdn-path = key of every RI request it >> cascades. >> " >>=20 >> OLD: >> " >> Transit CDNs >> should check the cdn-path and not cascade the RI request to >> downstream CDNs that are already listed in cdn-path. CDNs MUST NOT >> propagate to any downstream CDNs if the number of CDN Provider IDs = in >> cdn-path (including the CDN's own Provider ID) is equal to or = greater >> than max-hops. >> " >> NEW: >> " >> Transit CDNs >> MUST check the cdn-path and not cascade the RI request to >> downstream CDNs that are already listed in cdn-path. CDNs MUST NOT >> propagate to any downstream CDNs if the number of CDN Provider IDs = in >> cdn-path (after appending their own CDN Provider ID) is equal to or = greater >> than max-hops. >> " >>=20 >>=20 >> *** section 5: >> " >> Information passed over the RI could be considered personal or >> sensitive, for example RI requests contain parts of a User Agent's >> original request and RI responses reveal information about the = dCDN's >> policy for which surrogates should serve which content/user >> locations. >> "=20 >> You can state after that paragraph, that a mitigation approach is for = uCDN RI implementation to support a policy that minimises the = information conveyed in the RI requests (or even possibly performs some = anonimisation of the client IP address). >>=20 >>=20 >> *** section 5: >> " >>=20 >> The RI interface also provides a mechanism whereby a uCDN could = probe >> a dCDN and infer the dCDN's edge topology by making repeated RI >> requests for different content and/or UA IP addresses and = correlating >> the responses from the dCDN. Additionally the ability for a dCDN = to >> indicate that a RI response applies more widely that the original >> request (via the scope dictionary) may significantly reduce the >> number of RI requests required to probe and infer the dCDN's edge >> topology. >> The same information could be obtained in the absence of the RI >> interface, but it could be more difficult to gather as it would >> require a distributed set of machines with a range of different IP >> addresses each making requests directly to the dCDN. However, the = RI >> facilitates easier collection of such information as it enables a >> single client to query the dCDN for a redirection/surrogate = selection >> on behalf of any UA IP address. >> " >> You could perhaps state that: >> * by definition, use of recursive redirection assumes that dCDN is = willing to provide more vsisbility to uCDN than with iterative.=20 >> * if that is a concern, dCDN could mitigate the problem by somewhat = obfuscating the information returned (eg providing hostnames/CNAMEs that = do not map to surrogates 1 to 1), or could return RTs that are subject = to a second level resolution (eg regional Request Routers) which, pushed = to the extreme, effectively degrades back to iterative redirection. >>=20 >>=20 >> * section 5: >> When discussing benefits of using TLS, please clarifies TLS comes = "for free" thanks to the HTTP transport of RI. >> Also, mention TLS also provides integrity protection (e.g. a RI = response cannot be modified). >>=20 >>=20 >> Editos: >> =3D=3D=3D=3D=3D >>=20 >> *** s/(RI) is one of the main building blocks/(RI) is one of the = building blocks/ >> *** s/it is down to the uCDN to decide/it is up to the uCDN to = decide/ >> *** s/in this draft/in this document/ [multiple occurrences] >> *** s/and could be extended/and could be extended in future versions/ >> *** s/to help the Upstream CDN with future RI requests/to help the = Upstream CDN handle future RI requests/ >> *** allocate a TAble number to all the tables, for easier reference = in the text. >> *** s/cacheable & not stale/cacheable and not stale/ >> *** s/It should be noted that the loop detection & prevention = mechanisms described above only cover preventing and detecting loops = within the RI itself./It should be noted that the loop detection and = prevention mechanisms described above only prevents and detects loops = within the RI itself./ >> *** s/As well as loops with the RI itself,/In addition to loops with = the RI itself,/ >>=20 >> On 21 Oct 2013, at 11:27, Ben Niven-Jenkins = wrote: >>=20 >>> Colleagues, >>>=20 >>> This is an update to the redirection interface specification to add = additional editorial text around data plane loop detection, media types = to use, the JSON encoding and the security considerations. >>>=20 >>> There are still some things outstanding within the document but any = review or suggestions for additional text would be most welcome :-) >>>=20 >>> Ben >>>=20 >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: internet-drafts@ietf.org >>>> Date: 21 October 2013 10:30:41 GMT+01:00 >>>> To: i-d-announce@ietf.org >>>> Cc: cdni@ietf.org >>>> Subject: [CDNi] I-D Action: draft-ietf-cdni-redirection-01.txt >>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>> Title : Request Routing Redirection Interface for CDN = Interconnection >>>> Author(s) : Wang Danhua >>>> Ben Niven-Jenkins >>>> He Xiaoyan >>>> Ge Chen >>>> Ni Wei >>>> Filename : draft-ietf-cdni-redirection-01.txt >>>> Pages : 24 >>>> Date : 2013-10-21 >>>>=20 >>>> Abstract: >>>> The Request Routing Interface comprises of (1) the asynchronous >>>> advertisement of footprint and capabilities by a downstream CDN = that >>>> allows a upstream CDN to decide whether to redirect particular user >>>> requests to that downstream CDN; and (2) the synchronous operation = of >>>> an upstream CDN requesting whether a downstream CDN is prepared to >>>> accept a user request and of a downstream CDN responding with how = to >>>> actually redirect the user request. This document describes an >>>> interface for the latter part, i.e. the CDNI request routing/ >>>> Redirection Interface. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-cdni-redirection-01 >>>>=20 >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-redirection-01 >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of = submission >>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>=20 >>>> 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 >>>=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 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Fri Feb 14 01:40:10 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 6BA141A00A8 for ; Fri, 14 Feb 2014 01:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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.548, 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 yIubGXrhGuzB for ; Fri, 14 Feb 2014 01:40:07 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1F00B1A0102 for ; Fri, 14 Feb 2014 01:39:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=133; q=dns/txt; s=iport; t=1392370790; x=1393580390; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=NJag16dsz20CMMYUQ/9YG8m8gm2z/MsMlc8WzmuvsU4=; b=AbSsUb5aQxuYBfjNcAWoogZVb3/dQnzQ9xYKGllZ5iq5M0u7dZouuH6H H5rDspxXhDwMcr25QXOLZEqaN/BncT3YcGLnyaAZgDlH1eOTZQZLa6F0i oqT7FOAwY9RuJchjZ0NF/AyTDJ8YTkqiA5omBu8WbecKPw64aU+o830gs A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFABnj/VKtJXG8/2dsb2JhbABZgwaBD78ygRYWdIIsOj8SAT5CJwQOiArIcBeOJVSDK4EUBJgskiODLYIq X-IronPort-AV: E=Sophos;i="4.95,843,1384300800"; d="scan'208";a="303870091" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 14 Feb 2014 09:39:49 +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 s1E9dnT2000321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 14 Feb 2014 09:39:49 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.86]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 03:39:49 -0600 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: CDNI London WG : Agenda slot requests Thread-Index: AQHPKWizvwI9iYFu202Vz/S41DLpGg== Date: Fri, 14 Feb 2014 09:39:48 +0000 Message-ID: <42CF81B2-EC89-482F-9BAD-2B6317F93F39@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="us-ascii" Content-ID: <62E8EA1EF06F5941BBD0278F35F2C5C8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/hJj3c91OjgXGXnvTIVifQ2QZDOk Subject: [CDNi] CDNI London WG : Agenda slot requests 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 Feb 2014 09:40:08 -0000 Hello, Please send agenda slot requests to Daryl and I, as we are putting teh agen= da together. Cheers Francois & Daryl= From nobody Fri Feb 14 01:42:37 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 8E91E1A01E4 for ; Fri, 14 Feb 2014 01:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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.548, 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 Z8waGasHky9f for ; Fri, 14 Feb 2014 01:42:27 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 054BC1A00D5 for ; Fri, 14 Feb 2014 01:42:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17119; q=dns/txt; s=iport; t=1392370946; x=1393580546; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Jje/58aPmlQqAp7NdBYENVZ/4TOnyDdGzwAXqFkHGS4=; b=aayGQ4njl5wnjoPAfwq1H6CsuUYGv4dHvozgz1ndHf0WvZA9A2muOW6L sIZzeFqrvj+QZuT82OuHT3yihijWzrqeBNlwIvik2R6Y+H5CYioOwAUPP 16bWTU4plwtEvdzWSK5UxJ+dQ+KmkZhdWhmeeNZ5GRyyE/No3Tx69ToW+ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAGXk/VKtJXG//2dsb2JhbABZgwY4UQa/MoEWFnSCJQEBAQMBAQEBawsFCwIBCBEDAQIBLicLHQgCBA4FCYd0CAgFyGMXjiUhMwcGgx6BFASUQ4NpgTKQcYMtgio X-IronPort-AV: E=Sophos;i="4.95,843,1384300800"; d="scan'208";a="304056967" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 14 Feb 2014 09:42:25 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1E9gOMm010743 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 09:42:24 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.86]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 03:42:24 -0600 From: "Francois Le Faucheur (flefauch)" To: Niven-Jenkins Ben Thread-Topic: [CDNi] New version of draft-ietf-cdni-redirection for London Thread-Index: AQHPKMcea361Oq5WPECHoF//X7Rgx5q04cmAgAADXYA= Date: Fri, 14 Feb 2014 09:42:24 +0000 Message-ID: <586501AC-267C-4F8B-AC6D-5D225EA0A1CF@cisco.com> References: <38D49197-8105-4F01-B65D-A8E649F2C33E@cisco.com> <5B81A942-EEB2-488D-BDC9-2493EEF78264@cisco.com> <331F008B-634B-4C7B-892E-34AB382750B6@niven-jenkins.co.uk> In-Reply-To: <331F008B-634B-4C7B-892E-34AB382750B6@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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/3vNy2eJ7shO5J656aRRuNLXzPOo Cc: "draft-ietf-cdni-redirection@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] New version of draft-ietf-cdni-redirection for London 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 Feb 2014 09:42:35 -0000 Hi Ben, On 14 Feb 2014, at 10:30, Ben Niven-Jenkins wrote= : > Francois, >=20 > On 13 Feb 2014, at 14:23, Francois Le Faucheur (flefauch) wrote: >=20 >> To authors of draft-ietf-cdni-redirection, >>=20 >> Could you please rev up the document for the London Meeting? >>=20 >> Note that the Cut-off date is Friday 14 Feb (ie tomorrow). >=20 > I don't have the cycles to up rev the document today. >=20 > In Vancouver you were going to try and find someone with some cycles to h= elp with the editing, how is that progressing? Aryl and I are looking into that. > Although I haven't managed to do anything to the draft itself, I have man= aged to spend some time going over the draft and identifying a list of edit= s that need to be made (including your comments below) and open items (suc= h as errors) along with some thoughts on how to resolve them. Good. Let=92s make sure you hook up in London with the TBD editor(s), so this inf= ormation is passed on effectively. Thanks Francois=20 > Unfortunately, I haven't had any time to fold them into the draft as actu= al text. >=20 > Regards > Ben >=20 >=20 >>=20 >> A number of points to be addressed were raised in Vancouver (including h= ow to deal with errors). Also, my review comments from November 2013 (see b= elow) still need to be addressed. >>=20 >> Thanks >>=20 >> Francois >>=20 >> Begin forwarded message: >>=20 >>> From: "Francois Le Faucheur (flefauch)" >>> Subject: [CDNi] Coments on draft-ietf-cdni-redirection-01.txt >>> Date: 6 November 2013 05:02:38 CET >>> To: Ben Niven-Jenkins >>> Cc: "cdni@ietf.org" >>>=20 >>> Ben and all, >>>=20 >>> Some comments: >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> *** >>> OLD: >>> " >>> If the RI is used between the uCDN >>> and one or more dCDNs. The dCDN's RI response may contain a >>> Redirection Target ...=20 >>> " >>> NEW: >>> " >>> If the RI is used between the uCDN >>> and one or more dCDNs, the dCDNs' RI response will typically contain a >>> Redirection Target ...=20 >>> " >>>=20 >>>=20 >>> *** >>> OLD: >>> " >>> where the attributes of a User >>> Agent's requests are encapsulated along with any other data that can >>> aid the downstream CDN in processing the requests. The RI response >>> encapsulates the attributes >>> " >>> NEW: >>> " >>> where the attributes of a User >>> Agent's requests are conveyed along with any other data that can >>> aid the downstream CDN in processing the requests. The RI response >>> conveys the attributes >>> " >>> [as discussed before, "encapsulates" incorrectly suggests they are conv= eyed by embedding their native format] >>>=20 >>>=20 >>> *** >>> OLD: >>> " >>> To assist the routing decision of a Downstream CDN, the Upstream CDN >>> shall convey as much information as possible to the Downstream CDN, >>> for example the URI of the requested content and the User Agent's >>> location information, when those are known by the uCDN Request >>> Routing system. >>> " >>> NEW: >>> " >>> To assist the routing decision of a Downstream CDN, the Upstream CDN >>> conveys the necessary information to the Downstream CDN, >>> for example the URI of the requested content and the User Agent's >>> location information, when those are known by the uCDN Request >>> Routing system. Based on its policy, the Upstream CDN can decide to al= so convey additional information about the request (e.g. HTTP request heade= rs) to allow the Downstream CDN to make a more informed decision. >>>=20 >>> " >>>=20 >>> *** section 4.2, table illustrating "Top-Level keys in RI requests/resp= onses" >>> The table (or the text that follow it) needs to indicate more exhaustiv= ely which key is Mandatory or not (separately for request and for response)= . >>>=20 >>>=20 >>> *** section 4.2, table illustrating "Top-Level keys in RI requests/resp= onses" >>> "Transit CDNs should check the cdn-path and not cascade the RI request = to downstream CDNs that are already listed in cdn-path." This wording is r= edundant with some text further in teh document also discussing use of cdn-= path and it is not worded properly with RFC2119 keywords. I suggest removin= g it from the table. >>>=20 >>>=20 >>> *** >>> OLD: >>> " >>> The dns dictionary of a RI request for DNS based redirection MUST >>> contain the following keys: resolver-ip, qtype, qclass, qname and the >>> value of each MUST be the value of the appropriate part of the User >>> Agent's DNS query/request. >>> " >>> NEW: >>> " >>> The dns dictionary of a RI request for DNS based redirection MUST >>> contain all the keys identified as Mandatory in the table above, and t= he >>> value of each MUST be the value of the appropriate part of the User >>> Agent's DNS query/request. >>> " >>> [In general, I think the doc needs a good clean-up to provide more exch= austive description of what is mandatory and what is not and better use of = RFC2119 terminology] >>>=20 >>>=20 >>> *** section 4.4.2 >>> " >>> For DNS based redirection the dCDN needs to return one of the >>> following to the uCDN in the RI response: >>> o The IP address of (or a CNAME to) the RT (if the dCDN is >>> performing DNS based redirection); or >>> o The IP address of (or a CNAME to) a RT which is a Request Router >>> (if the dCDN is performing HTTP based redirection). >>> " >>> It is a little confusing to read that "for DNS-based redirection, the d= CDN needs to return =85 (if the dCDN is performing HTTP based redirection)"= . So you need to distinguish more explicitely between the redirection metho= d used between the USer Agent & uCDN versus the redirection method used by= the dCDN. This probably affects also 4.4.1 (and 4.5) since its title refe= rs to the redirection method used between the User Agent & uCDN. >>>=20 >>> *** section 4.4.2 >>> OLD: >>> " >>> Response must contain at least one of a, aaaa, cname. >>> " >>> NEW: >>> " >>> RI Response for DNS based redirection MUST contain all the keys identif= ied as Mandatory in the table above, as well as at least one of a, aaaa, cn= ame. >>> " >>>=20 >>> *** section 4.4.2 >>> why is the name in the response called "name" while it is called "name"= in the query? Should it not be also called "qname" (if it is always is equ= al to the qname of the query) or "rename" (if it can be different in some s= ituations)? >>>=20 >>>=20 >>> *** >>> OLD: >>> " >>> The http dictionary of a RI request for HTTP based redirection MUST >>> contain the following keys: c-ip, cs-method, cs-version and cs-uri >>> and the value of each MUST be the value of the appropriate part of >>> the User Agent's DNS query/request. >>> " >>> NEW: >>> " >>> The http dictionary of a RI request for HTTP based redirection MUST >>> contain all the keys identifed as Mandatory in the previous table and = the value of each MUST be the value of the appropriate part of the User Ag= ent's HTTP request. >>> " >>>=20 >>>=20 >>> *** section 4.6 >>> " >>> Additionally, an RI response MUST NOT be reused unless the request >>> from the User Agent would generate an identical RI request to the >>> dCDN as the one that resulted in the cached RI response. >>> " >>> This "MUST NOT" statement is immediately contradicted by the subsequent= paragraph introducing the notion of Scope. So it cannot stay as is. >>> Also, you need to discuss the case of a request with everything identic= al except with different HTTP headers. That woudl generate a different RI r= equest, yet can you reuse a previous RI response or not? >>>=20 >>>=20 >>> *** section 4.6: >>> OLD: >>> " >>> "http": { >>> "sc-status": 302, >>> "cs-uri": "http://www.example.com" >>> "sc-location": >>> "http://sur1.dcdn.example/ucdn/example.com", >>> " >>> NEW: >>> " >>> "http": { >>> "sc-status": 302, >>> "cs-uri": "http://www.example.com/movie100.mp4" >>> "sc-location": >>> "http://sur1.dcdn.example/ucdn/example/movie100.mp4", >>> " >>>=20 >>>=20 >>> *** section 4.7: >>> " >>> [[Editor's note: We've tried to keep error specification light weight >>> & provide the hooks needed to help with debugging without trying to >>> be overly prescriptive=20 >>> " >>> I see the intent, but I don't get what you are proposing exactly: to no= t define error values at all? to define a few only and allow implementation= s to easily define others with (or without?) registering those before? >>> Perhaps this could be achieved by creating a name based registry, with = very easy allocation of new names. >>>=20 >>>=20 >>> *** section 4.8: In general, the text of that section could read better= . >>> There is overlap between the 3rd paragraph and the first one. >>> OLD: >>> " >>> In order to prevent and detect RI request loops, each CDN MUST insert >>> its CDN Provider ID into the cdn-path key of every RI request it >>> originates or cascades. >>> " >>> NEW: >>> " >>> In order to prevent and detect RI request loops, each CDN MUST insert >>> its CDN Provider ID into the cdn-path key of every RI request it >>> originates, and MUST append its CDN Provider ID into the cdn-path key = of every RI request it >>> cascades. >>> " >>>=20 >>> OLD: >>> " >>> Transit CDNs >>> should check the cdn-path and not cascade the RI request to >>> downstream CDNs that are already listed in cdn-path. CDNs MUST NOT >>> propagate to any downstream CDNs if the number of CDN Provider IDs in >>> cdn-path (including the CDN's own Provider ID) is equal to or greater >>> than max-hops. >>> " >>> NEW: >>> " >>> Transit CDNs >>> MUST check the cdn-path and not cascade the RI request to >>> downstream CDNs that are already listed in cdn-path. CDNs MUST NOT >>> propagate to any downstream CDNs if the number of CDN Provider IDs in >>> cdn-path (after appending their own CDN Provider ID) is equal to or gr= eater >>> than max-hops. >>> " >>>=20 >>>=20 >>> *** section 5: >>> " >>> Information passed over the RI could be considered personal or >>> sensitive, for example RI requests contain parts of a User Agent's >>> original request and RI responses reveal information about the dCDN's >>> policy for which surrogates should serve which content/user >>> locations. >>> "=20 >>> You can state after that paragraph, that a mitigation approach is for u= CDN RI implementation to support a policy that minimises the information co= nveyed in the RI requests (or even possibly performs some anonimisation of = the client IP address). >>>=20 >>>=20 >>> *** section 5: >>> " >>>=20 >>> The RI interface also provides a mechanism whereby a uCDN could probe >>> a dCDN and infer the dCDN's edge topology by making repeated RI >>> requests for different content and/or UA IP addresses and correlating >>> the responses from the dCDN. Additionally the ability for a dCDN to >>> indicate that a RI response applies more widely that the original >>> request (via the scope dictionary) may significantly reduce the >>> number of RI requests required to probe and infer the dCDN's edge >>> topology. >>> The same information could be obtained in the absence of the RI >>> interface, but it could be more difficult to gather as it would >>> require a distributed set of machines with a range of different IP >>> addresses each making requests directly to the dCDN. However, the RI >>> facilitates easier collection of such information as it enables a >>> single client to query the dCDN for a redirection/surrogate selection >>> on behalf of any UA IP address. >>> " >>> You could perhaps state that: >>> * by definition, use of recursive redirection assumes that dCDN is will= ing to provide more vsisbility to uCDN than with iterative.=20 >>> * if that is a concern, dCDN could mitigate the problem by somewhat obf= uscating the information returned (eg providing hostnames/CNAMEs that do no= t map to surrogates 1 to 1), or could return RTs that are subject to a seco= nd level resolution (eg regional Request Routers) which, pushed to the extr= eme, effectively degrades back to iterative redirection. >>>=20 >>>=20 >>> * section 5: >>> When discussing benefits of using TLS, please clarifies TLS comes "for = free" thanks to the HTTP transport of RI. >>> Also, mention TLS also provides integrity protection (e.g. a RI respons= e cannot be modified). >>>=20 >>>=20 >>> Editos: >>> =3D=3D=3D=3D=3D >>>=20 >>> *** s/(RI) is one of the main building blocks/(RI) is one of the buildi= ng blocks/ >>> *** s/it is down to the uCDN to decide/it is up to the uCDN to decide/ >>> *** s/in this draft/in this document/ [multiple occurrences] >>> *** s/and could be extended/and could be extended in future versions/ >>> *** s/to help the Upstream CDN with future RI requests/to help the Upst= ream CDN handle future RI requests/ >>> *** allocate a TAble number to all the tables, for easier reference in = the text. >>> *** s/cacheable & not stale/cacheable and not stale/ >>> *** s/It should be noted that the loop detection & prevention mechanism= s described above only cover preventing and detecting loops within the RI i= tself./It should be noted that the loop detection and prevention mechanisms= described above only prevents and detects loops within the RI itself./ >>> *** s/As well as loops with the RI itself,/In addition to loops with th= e RI itself,/ >>>=20 >>> On 21 Oct 2013, at 11:27, Ben Niven-Jenkins w= rote: >>>=20 >>>> Colleagues, >>>>=20 >>>> This is an update to the redirection interface specification to add ad= ditional editorial text around data plane loop detection, media types to us= e, the JSON encoding and the security considerations. >>>>=20 >>>> There are still some things outstanding within the document but any re= view or suggestions for additional text would be most welcome :-) >>>>=20 >>>> Ben >>>>=20 >>>>=20 >>>> Begin forwarded message: >>>>=20 >>>>> From: internet-drafts@ietf.org >>>>> Date: 21 October 2013 10:30:41 GMT+01:00 >>>>> To: i-d-announce@ietf.org >>>>> Cc: cdni@ietf.org >>>>> Subject: [CDNi] I-D Action: draft-ietf-cdni-redirection-01.txt >>>>>=20 >>>>>=20 >>>>> A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. >>>>> This draft is a work item of the Content Delivery Networks Interconne= ction Working Group of the IETF. >>>>>=20 >>>>> Title : Request Routing Redirection Interface for CDN Inter= connection >>>>> Author(s) : Wang Danhua >>>>> Ben Niven-Jenkins >>>>> He Xiaoyan >>>>> Ge Chen >>>>> Ni Wei >>>>> Filename : draft-ietf-cdni-redirection-01.txt >>>>> Pages : 24 >>>>> Date : 2013-10-21 >>>>>=20 >>>>> Abstract: >>>>> The Request Routing Interface comprises of (1) the asynchronous >>>>> advertisement of footprint and capabilities by a downstream CDN that >>>>> allows a upstream CDN to decide whether to redirect particular user >>>>> requests to that downstream CDN; and (2) the synchronous operation of >>>>> an upstream CDN requesting whether a downstream CDN is prepared to >>>>> accept a user request and of a downstream CDN responding with how to >>>>> actually redirect the user request. This document describes an >>>>> interface for the latter part, i.e. the CDNI request routing/ >>>>> Redirection Interface. >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection >>>>>=20 >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-cdni-redirection-01 >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-redirection-01 >>>>>=20 >>>>>=20 >>>>> Please note that it may take a couple of minutes from the time of sub= mission >>>>> 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 >>>>=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 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 From nobody Fri Feb 14 08:49:12 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 BED581A0270 for ; Fri, 14 Feb 2014 08:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 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.548, 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 LxL3jV1uvQnV for ; Fri, 14 Feb 2014 08:49:08 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0D91A02A3 for ; Fri, 14 Feb 2014 08:49:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3338; q=dns/txt; s=iport; t=1392396546; x=1393606146; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CjC2ES9GmvN+o1F0Y9CSlHxQeCkhGPWOLDPN7r498DY=; b=RrYcXRMbUSbi5BVGclGYCaEnjwyTxv8LY7w4TICbfeHpaMGoXHt/UhAd HnRCzxYzlfdwIUCG090+NSxppJduEnx3NVzeH3ZGOKyk9lOxMPirWPqYK jRsMW/HCifnzP2EgTejMtKEJ6fbu493l7dHRMt2KGIuB76iKGADaesV13 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAM9I/lKtJXHA/2dsb2JhbABZgwY4UQa/MoEUFnSCJQEBAQQBAQE3NAkCDAQCAQgRBAEBCxQJBycLFAcBAQUDAgQOBQgBh3sBCAXIExeOSDEHBoMegRQEmV6QcYMtgWokHA X-IronPort-AV: E=Sophos;i="4.95,845,1384300800"; d="scan'208";a="20513776" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-1.cisco.com with ESMTP; 14 Feb 2014 16:48:52 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1EGmq2h023021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 16:48:52 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.95]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 10:48:52 -0600 From: "Kent Leung (kleung)" To: "mnot@mnot.net" Thread-Topic: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-04.txt Thread-Index: AQHPKaSkSiCHgkFotUeXsMbWLbtp6A== Date: Fri, 14 Feb 2014 16:48:52 +0000 Message-ID: References: <20140214010816.22518.21143.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.231.45] 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/_a9AMx10ACOyKnjQMs8a315tdAQ Cc: "cdni@ietf.org" Subject: [CDNi] FW: FW: New Version Notification for draft-leung-cdni-uri-signing-04.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: Fri, 14 Feb 2014 16:49:10 -0000 Hi Mark. We had a discussion about "URI Squatting" issues with this draft a= t the last IETF. This particular issue is covered in draft-ietf-appsawg-uri= -get-off-my-lawn. There was a consensus to use CDNI Metadata Interface to d= efine the attribute name(s) in the URI query string as the resolution. The = revision to this draft addressed the point that you've raised (see 2nd bull= et below). Please let me know if you have any comments or concerns. Thanks. Kent -----Original Message----- From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Kent Leung (kleung) Sent: Thursday, February 13, 2014 5:27 PM To: cdni@ietf.org Subject: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signi= ng-04.txt FYI. This new version addressed some of the issues and comments raised duri= ng last IETF session. The key changes are: - Updated the document to be in line with the new approach of mandatory pac= kaging and encapsulated information elements. - Only one attribute in the URI query string is used for URI Signing. The a= ttribute name is provided by CDNI metadata or via configuration. - Adjusted section 2 to make a clear distinction between an information ele= ment (the three categories) and the packaging attribute.=20 - Fixed inconsistencies and errors in the document which addressed Kevin's = comments Kent -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Thursday, February 13, 2014 5:08 PM To: Ray van Brandenburg; Kent Leung (kleung); Bill Downey; Bill Downey; Sco= tt Leibrand; Scott Leibrand; Kent Leung (kleung); Francois Le Faucheur (fle= fauch); Ray van Brandenburg; Francois Le Faucheur (flefauch) Subject: New Version Notification for draft-leung-cdni-uri-signing-04.txt A new version of I-D, draft-leung-cdni-uri-signing-04.txt has been successfully submitted by Kent Leung and posted to the IETF reposi= tory. Name: draft-leung-cdni-uri-signing Revision: 04 Title: URI Signing for CDN Interconnection (CDNI) Document date: 2014-02-13 Group: Individual Submission Pages: 34 URL: http://www.ietf.org/internet-drafts/draft-leung-cdni-uri-si= gning-04.txt Status: https://datatracker.ietf.org/doc/draft-leung-cdni-uri-signi= ng/ Htmlized: http://tools.ietf.org/html/draft-leung-cdni-uri-signing-04 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-leung-cdni-uri-sig= ning-04 Abstract: This document describes how the concept of URI signing supports the content access control requirements of CDNI and proposes a URI signing scheme. The proposed URI signing method specifies the information needed to be included in the URI and the algorithm used to authorize and to validate access requests for the content referenced by the URI. Some of the information may be accessed by the CDN via configuration or CDNI metadata. = =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From nobody Fri Feb 14 11:51: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 475321A02B9; Fri, 14 Feb 2014 11:51:17 -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 05RsucQ8FSky; Fri, 14 Feb 2014 11:51:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 616E61A0368; Fri, 14 Feb 2014 11:49:56 -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.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214194956.23453.84310.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 11:49:56 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/nOoWonISToWHNUSwnHUY6qTgcwU Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities-semantics-02.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 19:51:17 -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 Request Routing: Footprint and Capabilities Semantics Authors : Jan Seedorf Jon Peterson Stefano Previdi Ray van Brandenburg Kevin J. Ma Filename : draft-ietf-cdni-footprint-capabilities-semantics-02.txt Pages : 18 Date : 2014-02-14 Abstract: This document tries to capture the semantics of the "Footprint and Capabilities Advertisement" part of the CDNI Request Routing interface, i.e. the desired meaning and what "Footprint and Capabilities Advertisement" is expected to offer within CDNI. The discussion in this document has the goal to facilitate the choosing of one or more suitable protocols for "Footprint and Capabilities Advertisement" within CDNI Request Routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-footprint-capabilities-semantics/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-footprint-capabilities-semantics-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-footprint-capabilities-semantics-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 13:28:17 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 93BDC1A0434; Fri, 14 Feb 2014 13:28:12 -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 1Zh7cFHRz8-U; Fri, 14 Feb 2014 13:28:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4292D1A02F2; Fri, 14 Feb 2014 13:28:09 -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.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214212809.17388.80523.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 13:28:09 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/5nxGAP7YBLDKi8SWUbVEzDSDezo Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-metadata-05.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: Fri, 14 Feb 2014 21:28:12 -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 : CDN Interconnect Metadata Authors : Ben Niven-Jenkins Rob Murray Grant Watson Matt Caulfield Kent Leung Kevin J. Ma Filename : draft-ietf-cdni-metadata-05.txt Pages : 42 Date : 2014-02-14 Abstract: The CDNI Metadata Interface enables interconnected CDNs to exchange content distribution metadata in order to enable content acquisition and delivery. The CDNI metadata associated with a piece of content provides a downstream CDN with sufficient information for the downstream CDN to service content requests on behalf of an upstream CDN. This document describes both the core set of CDNI metadata and the protocol for exchanging that metadata. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-metadata-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-metadata-05 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 Fri Feb 14 13:46: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 5D3931A03A9; Fri, 14 Feb 2014 13:46:24 -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 H7FP6qYAeMGa; Fri, 14 Feb 2014 13:46:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6331A042C; Fri, 14 Feb 2014 13:46:18 -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.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214214618.22993.16551.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 13:46:18 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/IwwxzZqNLlBhe1ed2MyV9Mm_8KE Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-metadata-06.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: Fri, 14 Feb 2014 21:46:24 -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 : CDN Interconnect Metadata Authors : Ben Niven-Jenkins Rob Murray Grant Watson Matt Caulfield Kent Leung Kevin J. Ma Filename : draft-ietf-cdni-metadata-06.txt Pages : 42 Date : 2014-02-14 Abstract: The CDNI Metadata Interface enables interconnected CDNs to exchange content distribution metadata in order to enable content acquisition and delivery. The CDNI metadata associated with a piece of content provides a downstream CDN with sufficient information for the downstream CDN to service content requests on behalf of an upstream CDN. This document describes both the core set of CDNI metadata and the protocol for exchanging that metadata. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-metadata-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-metadata-06 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 Sun Feb 16 17:17:27 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 67D0D1A02F9 for ; Sun, 16 Feb 2014 17:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TqCUjwee97q0 for ; Sun, 16 Feb 2014 17:17:18 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 05EBF1A02E3 for ; Sun, 16 Feb 2014 17:17:17 -0800 (PST) Received: from [192.168.1.55] (unknown [118.209.8.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 589A250A84; Sun, 16 Feb 2014 20:17:12 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Mark Nottingham In-Reply-To: Date: Mon, 17 Feb 2014 12:17:08 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <294BC0AD-FABA-42DA-ADDB-91F9279ACD31@mnot.net> References: <20140214010816.22518.21143.idtracker@ietfa.amsl.com> To: "Kent Leung (kleung)" X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/W1ouhubPGuSlSsbajP8V-rYaiqE Cc: "cdni@ietf.org" Subject: Re: [CDNi] New Version Notification for draft-leung-cdni-uri-signing-04.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, 17 Feb 2014 01:17:21 -0000 Hi Kent, Thanks for the heads up. I'm looking a the draft and the diffs quickly, so apologies if I'm = misreading it. In Sections 3 and 4, as I understand it, you're using a temporary URI = with all of the various metatdata you're interested in added to it, = taking a signature of it, and then adding that signature to the actual = URI with the parameter that's communicated by the metadata interface, = correct? If so, the text could be a little more clear about this -- the way that = it's written, it's easy to think that 'URISigningPackage' is static and = unchanging.=20 E.g., in section 3: > 5. Append the parameter name used to indicate the URI Signing=09 > Package Attribute. This parameter name is communicated = via the=09 > CDNI Metadata Interface. Alternatively, it is set to=09 > 'URISigningPackage' by configuration. Append the string=09= > "URISigningPackage=3D" to the message. This would be more clear as something like: """ 5. Append the parameter name used to indicate the URI Signing Package = Attribute, as communicated via the CDNI Metadata interface, followed by = an "=3D". If non is communicated by the metadata interface, it defaults = to "URISigningPackage". For example, if the CDNI Metadata interface = specifies "SIG", append the string "SIG=3D" to the message. """ and so forth. More deeply, the draft assumes that URIs always have query strings = encoded in the format specified by HTML = . While = that format is extremely common, it isn't a constraint on URIs -- even = HTTP URIs. One way to avoid this would be to have the CDNI Metadata Interface = convey a URI Template to specify where the signature goes: http://tools.ietf.org/html/rfc6570 https://code.google.com/p/uri-templates/wiki/Implementations Cheers, On 15 Feb 2014, at 3:48 am, Kent Leung (kleung) = wrote: > Hi Mark. We had a discussion about "URI Squatting" issues with this = draft at the last IETF. This particular issue is covered in = draft-ietf-appsawg-uri-get-off-my-lawn. There was a consensus to use = CDNI Metadata Interface to define the attribute name(s) in the URI query = string as the resolution. The revision to this draft addressed the point = that you've raised (see 2nd bullet below). Please let me know if you = have any comments or concerns. Thanks. >=20 > Kent >=20 >=20 > -----Original Message----- > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Kent Leung = (kleung) > Sent: Thursday, February 13, 2014 5:27 PM > To: cdni@ietf.org > Subject: [CDNi] FW: New Version Notification for = draft-leung-cdni-uri-signing-04.txt >=20 > FYI. This new version addressed some of the issues and comments raised = during last IETF session. The key changes are: >=20 > - Updated the document to be in line with the new approach of = mandatory packaging and encapsulated information elements. > - Only one attribute in the URI query string is used for URI Signing. = The attribute name is provided by CDNI metadata or via configuration. > - Adjusted section 2 to make a clear distinction between an = information element (the three categories) and the packaging attribute.=20= > - Fixed inconsistencies and errors in the document which addressed = Kevin's comments >=20 > Kent >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: Thursday, February 13, 2014 5:08 PM > To: Ray van Brandenburg; Kent Leung (kleung); Bill Downey; Bill = Downey; Scott Leibrand; Scott Leibrand; Kent Leung (kleung); Francois Le = Faucheur (flefauch); Ray van Brandenburg; Francois Le Faucheur = (flefauch) > Subject: New Version Notification for = draft-leung-cdni-uri-signing-04.txt >=20 >=20 > A new version of I-D, draft-leung-cdni-uri-signing-04.txt > has been successfully submitted by Kent Leung and posted to the IETF = repository. >=20 > Name: draft-leung-cdni-uri-signing > Revision: 04 > Title: URI Signing for CDN Interconnection (CDNI) > Document date: 2014-02-13 > Group: Individual Submission > Pages: 34 > URL: = http://www.ietf.org/internet-drafts/draft-leung-cdni-uri-signing-04.txt > Status: = https://datatracker.ietf.org/doc/draft-leung-cdni-uri-signing/ > Htmlized: = http://tools.ietf.org/html/draft-leung-cdni-uri-signing-04 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-leung-cdni-uri-signing-04 >=20 > Abstract: > This document describes how the concept of URI signing supports the > content access control requirements of CDNI and proposes a URI > signing scheme. >=20 > The proposed URI signing method specifies the information needed to > be included in the URI and the algorithm used to authorize and to > validate access requests for the content referenced by the URI. = Some > of the information may be accessed by the CDN via configuration or > CDNI metadata. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni -- Mark Nottingham http://www.mnot.net/ From nobody Mon Feb 17 07:36: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 D174E1A020C for ; Mon, 17 Feb 2014 07:36:03 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 x3Tj4r4LTsFg for ; Mon, 17 Feb 2014 07:36:01 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id CD8331A01FB for ; Mon, 17 Feb 2014 07:36:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6397; q=dns/txt; s=iport; t=1392651358; x=1393860958; h=from:to:subject:date:message-id:references:mime-version; bh=LlprPg1/GqCPyAvD/+8kBywS6KztkesN7Hun4NVRsOw=; b=VJoRiJPHUXgKpTUyF731gaE7CyZZMzDtnceeHFlNAGMPq6sLxUEPAl1Y +sRxmITEnCuO2qEvtfBCKE4ramts16bzniUWmh+qrTxhshrmDKIEmxg2y LSyyqTKs0fMOXauJ6wGFjrl+PkIypSOSmbWufH3Ntz6XtiDz+w1Q8/ps3 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AosFAPQrAlOtJV2Y/2dsb2JhbABZgwY4UQa/OIEfFnSCJQEBAQQBAQFrGwIBGQMBAigHJwsUBwIIAgQTCYd8CAXLaBeOcA0KB4IpdYEUBJgsgTKLL4VCgy2CKg X-IronPort-AV: E=Sophos;i="4.95,861,1384300800"; d="scan'208,217";a="106154994" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by mtv-iport-4.cisco.com with ESMTP; 17 Feb 2014 15:35:48 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1HFZhiW024636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 17 Feb 2014 15:35:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Mon, 17 Feb 2014 09:35:45 -0600 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: I-D Action: draft-caulfield-cdni-rate-pacing-01.txt Thread-Index: AQHPK/XsGRGgKlbe/0yNRobk7zb+RA== Date: Mon, 17 Feb 2014 15:35:45 +0000 Message-ID: <44C7B2F6-7BE6-4315-B4BC-33C7A287CEFF@cisco.com> References: <20140213183422.27184.59770.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.200] Content-Type: multipart/alternative; boundary="_000_44C7B2F67BE64315B4BC33C7A287CEFFciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/3jzc1HltH8lspEBshmzvtsr6izQ Subject: [CDNi] Fwd: I-D Action: 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, 17 Feb 2014 15:36:04 -0000 --_000_44C7B2F67BE64315B4BC33C7A287CEFFciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI. Francois Begin forwarded message: From: > Subject: I-D Action: draft-caulfield-cdni-rate-pacing-01.txt Date: 13 February 2014 19:34:22 CET To: > Reply-To: > 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 submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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_44C7B2F67BE64315B4BC33C7A287CEFFciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <3A49C60047B3D44588B1EBD8CAA3B6DA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable FYI.
Francois

Begin forwarded message:

From:= <internet-drafts@ietf.org>

Subje= ct: I-D Action: draft-caulfi= eld-cdni-rate-pacing-01.txt

Date:= 13 February 2014 19:34= :22 CET

To: <= /b><i-d-announce@ietf.org>

Reply= -To: <internet-drafts@ietf.org>

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 d= efines 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 submissio= n
until the htmlized version and diff are available at tools.ietf.org.

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

_______________________________________________
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_44C7B2F67BE64315B4BC33C7A287CEFFciscocom_-- From nobody Mon Feb 17 08:46: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 2DDA41A025B for ; Mon, 17 Feb 2014 08:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 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.548, 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 qywxNuNv1rJI for ; Mon, 17 Feb 2014 08:46:47 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 52F411A00CD for ; Mon, 17 Feb 2014 08:46:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6242; q=dns/txt; s=iport; t=1392655605; x=1393865205; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SsU+Fpcu4MHQMtFv4nDN52xOiolcIvS2Gjz3xHd1IDY=; b=JKznPz2Cq6uJOPo8E+zqxx0n6i2PdrHgIeA3z947acfevBAMGQL5MvKB wnJnOT/YDAOo5ep72VZjPuKN2pSH1D8x9QVrq4OqpLSTmgMup8ZLBAeo6 5N6eVvJlZw33b+CMAA02L3p2EP2e7uPkfsByndUFHgac7UJjXTIm0NToH 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowFAB48AlOtJV2a/2dsb2JhbABZgwY4SwYGvziBHxZ0giUBAQEDAQEBAWsLEAIBTicLJQIEDgUJh3QICAXLbxePAQIFgySBFASYLIEyiy+FQoMtgio X-IronPort-AV: E=Sophos;i="4.95,861,1384300800"; d="scan'208";a="21022368" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP; 17 Feb 2014 16:46:44 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1HGkhkS002855 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 17 Feb 2014 16:46:44 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Mon, 17 Feb 2014 10:46:43 -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, 17 Feb 2014 16:46:42 +0000 Message-ID: References: <20140213183422.27184.59770.idtracker@ietfa.amsl.com> In-Reply-To: <20140213183422.27184.59770.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.200] Content-Type: text/plain; charset="Windows-1252" Content-ID: <6656C2131CD5CE47AD2D5A5F4E130D0E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/GGX0ugs0rq52rOJKrn_8tcHusH0 Cc: "cdni@ietf.org" Subject: [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, 17 Feb 2014 16:46:50 -0000 Hi Matt, (With my individual contributor=92s 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. =93 This suggests that we can end up in a situation where CDN1 advertises only = "token-bucket/v1=94 and CDN2 advertises only =93rate-pacing-algorithm-bladi= bla=94.=20 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=94)? 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: =93 For example, "token-bucket./v1=94 =93 should this read "token-bucket/v1=94 (without a dot)? *** section 2.3: What you are discussing here about dCDN selection based on =93required=94 r= ate-pacing is actually a generic concept (but simply applied here to rate-p= acing). 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 =93 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. =93 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 =93average = rate=94 and the tocken bucket rate).=20 But given this is an optional parameter, I don=92t have a problem in defini= ng it. *** section 2.4: OLD: =93 The "sc-rate" field indicates the rate in bytes per second as a decimal number. =93 NEW: =93 A new "sc-rate" CDNI Logging Field is defined to indicate the rate in bytes= per second as a decimal number. =93 *** section 2.4: OLD: =93 Note that existing fields defined by [I-D.ietf-cdni-logging] include the bytes delivered and the time taken to service a request. =93 NEW: =93 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. =93 *** section 3: "3. Rate Pacing Algorithm" Since this document specifies one particular algorithm, and since its param= eters are specified in this section, I=92d suggest changing title to someth= ing like: =933. Tocken Bucket Rate Pacing Algorithm and Parameters=94. *** section 3: The first paragraph is a litlle confusing because =93Tocken Bucket=94 somet= imes refers to the generic mechanisms and sometimes to how it is applied to= CDNI. I would recommend you distinguish the two: * the generic tolken bucket concept [RFC1363] * introduce a notion of =93CDNI Tocken Bucket RAte Pacing=94=20 Then you can explian that : * this document specifies the =93CDNI Tocken Bucket Rate Pacing=94=20 * it is based on the generic token bucket, but applied in a CDNI context (= ie by Surrogate when transmitting bytes of a response to a content=20 * clarify which bytes are to be accounted for in the bucket (eg L1? L2? IP= ? Transport? HTTP status response, HTTP headers,..) *** section 3: OLD: =93 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. =93 NEW: =93 If a RatePacing metadata object's "algo" value is "token-bucket/v1" then the metadata object's "params=94 MUST be an object of type TokenBucketParams, described below. =93 *** Section 4.1: =93 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=94 =97> "[I-D.ietf= -cdni-footprint-capabilities-semantics] defines=94 "[I-D.ietf-cdni-footprint-capabilities-semantics]states=94 =97> "[I-D.ietf-= cdni-footprint-capabilities-semantics] states=94 "IANA is requested to create new registry=94 =97> "IANA is requested to cre= ate a new registry=94 On 13 Feb 2014, at 19:34, Internet-Drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : CDNI Rate Pacing > Author : Matt Caulfield > Filename : draft-caulfield-cdni-rate-pacing-01.txt > Pages : 8 > Date : 2014-02-13 >=20 > 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. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-caulfield-cdni-rate-pacing/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-caulfield-cdni-rate-pacing-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-caulfield-cdni-rate-pacing-01 >=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 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Feb 17 08:50:35 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 9EBF01A03F6 for ; Mon, 17 Feb 2014 08:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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.548, 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 3R5wbX3I0487 for ; Mon, 17 Feb 2014 08:50:23 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id CBD161A0246 for ; Mon, 17 Feb 2014 08:50:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6531; q=dns/txt; s=iport; t=1392655821; x=1393865421; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4KKhSf94P1aQhIv7gqhqUR1XQfB1wn3ewPLxbIaqWjw=; b=BbV1JDtYjwNPifNYpyXcO9BK6VIcX7MF/+Xg0Tr+1/4Jip0ePQP44EHv 7H8E4YYsIYgsAIHmmjN/W9XLBuTR2aXQGwuZcy9jBf84magqx7Yq4oRPB KPLNmBn8lvxCfAEaho64G3Khco7f001jpI8jx9Io2in5i2DsJRQPjvW9J s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0FAFQ9AlOtJV2d/2dsb2JhbABZgwY4SwYGvziBHxZ0giUBAQEDAQEBASQTNAsMBAIBCBEEAQELFBAnCx0IAgQOBQgBh3QICAXLbxeOUDECBQaDHoEUBJleiy+FQoMtgio X-IronPort-AV: E=Sophos;i="4.95,861,1384300800"; d="scan'208";a="102991234" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by mtv-iport-1.cisco.com with ESMTP; 17 Feb 2014 16:50:21 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1HGo2sb012647 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 17 Feb 2014 16:50:20 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.174]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Mon, 17 Feb 2014 10:50:06 -0600 From: "Matt Caulfield (mcaulfie)" To: "Francois Le Faucheur (flefauch)" Thread-Topic: Comments on draft-caulfield-cdni-rate-pacing-01.txt Thread-Index: AQHPK//VRagSHawbjEGTIHEYuqBOXZq5qHGw Date: Mon, 17 Feb 2014 16:50:05 +0000 Message-ID: <166EBB70C264A9479E459B01B1BA6C924E0A7806@xmb-aln-x03.cisco.com> References: <20140213183422.27184.59770.idtracker@ietfa.amsl.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/9lSdYAxXc-6uRlS6OHyOMIMxXRw 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, 17 Feb 2014 16:50:31 -0000 Thank you for the comments, Francois.=20 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)=20 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"= .=20 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).=20 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"=20 Then you can explian that : * this document specifies the "CDNI Tocken Bucket Rate Pacing"=20 * it is based on the generic token bucket, but applied in a CDNI context (= ie by Surrogate when transmitting bytes of a response to a content=20 * 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: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : CDNI Rate Pacing > Author : Matt Caulfield > Filename : draft-caulfield-cdni-rate-pacing-01.txt > Pages : 8 > Date : 2014-02-13 >=20 > 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. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-caulfield-cdni-rate-pacing/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-caulfield-cdni-rate-pacing-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-caulfield-cdni-rate-pacing-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Tue Feb 18 02:20: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 19FEB1A032B for ; Tue, 18 Feb 2014 02:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 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.548, 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 NGjde3MBuj8Z for ; Tue, 18 Feb 2014 02:20:04 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 58E591A0625 for ; Tue, 18 Feb 2014 02:20:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=153; q=dns/txt; s=iport; t=1392718801; x=1393928401; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=+iayau+4AHUuXD+NaRoHTjiU6RYFdpAh6QIAB1v2AfQ=; b=FIhcZ/dI4oG1PlGpJNicmQNVKkFr3Lvks7MgLarSAE4pygwt8cxWm9w9 a5lG2JMSyRvnV9PgOCj1aOq2wE4m4JlkABlY8ORpA85bC9GFgUm1aeA/z 1gynM2rCLuPdoQOexnLzy4us2HrMDgzbYeu2XyJwxjLgbUze2uyQbS/xt M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAKEyA1OtJV2a/2dsb2JhbABZgwY4V79GgR8WdIIsOlEBPkInBByHfA2ZfLEiF44tg3+BFASYLJIjgy2CKg X-IronPort-AV: E=Sophos;i="4.97,501,1389744000"; d="scan'208";a="21226865" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP; 18 Feb 2014 10:20:01 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1IAK1cY012312 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 18 Feb 2014 10:20:01 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.67]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 04:20:00 -0600 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Draft CDNI WG London Agenda posted Thread-Index: AQHPLJL6iI6K+YgHIkCVhShaKFBKpQ== Date: Tue, 18 Feb 2014 10:20:00 +0000 Message-ID: <73D89426-E69F-4ED4-9FA7-ADF8130FE0E9@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.200] Content-Type: text/plain; charset="us-ascii" Content-ID: <3B556C013ADC4B46A7B7001F83B7D0A9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/c1K_oe5qPVMt5exu54aq3reT2Lw Subject: [CDNi] Draft CDNI WG London Agenda posted 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, 18 Feb 2014 10:20:06 -0000 http://www.ietf.org/proceedings/89/agenda/agenda-89-cdni Please review and let Drayl and I know if changes are needed. Cheers Francois & Daryl From nobody Tue Feb 18 08:39: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 01EAF1A04D4 for ; Tue, 18 Feb 2014 08:39:53 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 OeRVMX0BP70I for ; Tue, 18 Feb 2014 08:39:49 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3871A069B for ; Tue, 18 Feb 2014 08:39:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25387; q=dns/txt; s=iport; t=1392741585; x=1393951185; h=from:to:subject:date:message-id:references:mime-version; bh=RvbS/tLpjjipI0MwEv3YL52C0Jf8a98pF6iMY2lxBds=; b=ii0+1BEF/+fYyp4AczanQ9HhB1x6BGIEu2LA4zN62Fs8Ez5qazrHHE2H v6HxES84GdpXL7kz+ooxAyinc1YyakQcqwb29I1BXE4uFZAHfHE5mid0C lPRV1ipPWFyfUSrrhWci1OkkTcpTVHfmtfdszgBOo9fJ9o2fhsmeNoieW w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AosFAHiMA1OtJV2c/2dsb2JhbABZgwY4UQa/UIEaFnSCJQEBAQRyFwIBGQMBAigHIREUCQgCBAEJCQkSh1YDEQgFw3QNiA8XjGeBeBEXB4MegRQElEOBfYFsgTKLLIVFgy2CKg X-IronPort-AV: E=Sophos;i="4.97,502,1389744000"; d="scan'208,217";a="304841833" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 18 Feb 2014 16:39:44 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1IGdiFS021794 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Feb 2014 16:39:44 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.67]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 10:39:44 -0600 From: "Francois Le Faucheur (flefauch)" To: "draft-ietf-cdni-metadata@tools.ietf.org" , "cdni@ietf.org" Thread-Topic: WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 1] Thread-Index: AQHPLMgG0KaeXw/n50SXdQyecGjjhQ== Date: Tue, 18 Feb 2014 16:39:43 +0000 Message-ID: <4F2F12C0-A71D-4A32-BDA7-5DE0007B0149@cisco.com> References: <20140214214618.22993.11019.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.200] Content-Type: multipart/alternative; boundary="_000_4F2F12C0A71D4A32BDA75DE0007B0149ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/I-ojFxLwGGLm3K4cNQdLypKV7lM Subject: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 1] X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 16:39:53 -0000 --_000_4F2F12C0A71D4A32BDA75DE0007B0149ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Folks, I=92ve started a WG Chair review of draft-ietf-cdni-metadata-06. Below is a= first batch of comments. Francois ***Title: s/CDN Interconnect Metadata/CDN Interconnection Metadata/ *** Authors: You currently list 6 authors, which I think exceeds the maximum expected nu= mber. You may need to consider splitting =93editors=94 and =93Contributing = Authors=94 *** throughout the document: s/Metadata Interface/Metadata interface/ *** section1: OLD: " CDNI enables a downstream CDN to service content requests on behalf of an upstream CDN. The CDNI metadata associated with a piece of content (or with a set of contents) provides a downstream CDN with sufficient information for servicing content requests on behalf of an upstream CDN in accordance with the policies defined by the upstream CDN. The CDNI Metadata Interface is introduced by [RFC6707] along with three other interfaces that may be used to compose a CDNI solution (Control, Request Routing and Logging). [I-D.ietf-cdni-framework] expands on the information provided in [RFC6707] and describes each interface, and the relationships between them, in more detail. The requirements for the CDNI metadata interface are specified in [I-D.ietf-cdni-requirements]. =93 NEW: =93 Content Delivery Networks Interconnection (CDNI) ([RFC6707]) enables a down= stream CDN to service content requests on behalf of an upstream CDN. The CDNI Metadata interface is discussed in [I-D.ietf-cdni-framework] al= ong with four other interfaces that may be used to compose a CDNI solution (CDNI Control interface, CDNI Request Routing Redirection interface, CDNI= Footprint & Capabilities Advertisement interface interface and Logging int= erface ). [I-D.ietf-cdni-framework] describes each interface, and the relationships between them. The requirements for the CDNI metadata interface are specified in [I-D.ietf-cdni-requirements]. The CDNI metadata associated with a piece of content (or with a set of contents) provides a downstream CDN with sufficient information for servicing content requests on behalf of an upstream CDN in accordance with the policies defined by the upstream CDN. " *** section 1: OLD: =93 o A data structure for mapping content requests to CDNI Metadata properties (Section 3). =93 NEW: =93 o A data structure for mapping content requests and redirection requests t= o CDNI Metadata properties (Section 3). =93 *** section 1: s/Redirection Requests/redirection requests/ s/Content Requests/content requests/ *** section 1: =93 Specifically, this document proposes: o A data structure for mapping content requests to CDNI Metadata properties (Section 3). o An initial set of CDNI Metadata properties (Section 4.2). o A RESTful web service for the transfer of CDNI Metadata (Section 6). =93 Is there a reason why the metadtaa structure defined in sectio 4.1 is not m= entioned here? To me it seems an important part of the metadata specification. *** section 2: s/The proposed CDNI Metadata Interface/The CDNI Metadata Interface/ *** section 2: s/Deterministic mapping from redirection and content requests/Deterministic= mapping from redirection requests and content requests/ *** section 2: s/5. Leverage/5. Leveraging of/ OLD: =93 Cacheability improves the latency of acquiring metadata while maintaining its freshness and therefore improves the latency of serving content requests. The CDNI Metadata Interface uses HTTP to achieve cacheability. =93 NEW: =93 Cacheability improves the latency of acquiring metadata while maintaining its freshness, and therefore improves the latency of serving content requests and redirection requests, without sacrifing acc= uracy. The CDNI Metadata Interface uses HTTP and its existing cahing mecha= nisms to achieve CDNI metadata cacheability. " *** section 3: OLD: =93 to be retrieved by a dCDN once, even if it is referenced by the CDNI Metadata of multiple Hostnames. =93 NEW: =93 to be retrieved and stored by a dCDN once, even if it is referenced by the = CDNI Metadata of multiple Hostnames or of multiple URI paths. *** title of section 3.1 s/HostIndex, HostMetadata & PathMetadata objects/HostIndex, HostMetadata an= d PathMetadata objects/ *** section 3.1: s/uCDN's CDNI Metadata data store/uCDN CDNI Metadata data store/ *** section 3.1: OLD: =93 It enables surrogates in the dCDN to deterministically discover, on receipt of a User Agent request for content, which other CDNI Metadata objects it requires in order to deliver the requested content. =93 NEW: =93 It enables the dCDN to deterministically discover, on receipt of a User Agent request for content, which other CDNI Metadata objects it requires in order to deliver the requested content. =93 [Rationale: the MI is intended to be used between uCDN and dCDN. It might a= lso be used inside teh dCDN and by surrogate sthemselves, but that is not n= ecessary. So we may want to refer to the MI endpoints as =93the uCDN=94 and= =93dCDN=94 (and not the "dCDN Surrogates=94) ] *** section 3.1: OLD: =93 When looking up CDNI Metadata, the downstream CDN looks up the requested Hostname (or IP address) in the HostIndex, =93 NEW: =93 When looking up CDNI Metadata, the downstream CDN looks up the requested Hostname (or IP address) against the HostMatch entries = in the HostIndex, =93 *** section 3.1: OLD: =93 Besides containing the default CDNI Metadata for the specified Hostname, HostMetadata and PathMetadata objects may also contain PathMatch objects which in turn contain PathMetadata objects. =93 NEW: =93 HostMetadata and PathMetadata objects may also contain PathMatch objects which in turn contain PathMetadata objects. =93 [Rationale: the main part of the sentence is applicable to both HostMetada= ta and PathMetadata, which grammatically suggests that the first part of th= e sentence is also applicable to both, while it is only applicable to Hostm= etadata] *** section 3.1: s/For the purposes of retrieving CDNI Metadata all/For the purposes of retr= ieving CDNI Metadata, all/ *** section 3.1, Table1. "The relationships in Figure 1 are summarised in Table 1 below.=94 I think Table 1, contains the exact same information as Figure 1. .i.e., Ta= ble 1 does not provide a =93summary=94. It just shows the same information = in a different way. Or am I missing some information in Figure 1 that is no= t in Table 1? I was going to comment that perhaps we could get rid of Table 1, but I can = see that it may be worth expressing it in a tabular manner as well, so I am= OK to keep Table 1. But you may want to: * tweak the text to say something like: "The relationships in Figure 1 are also represented in a tabular format in = Table 1 below.=94 * adjust the titles of Figure 1 and Table 1 because it is confusing to have= them show teh same information but have different titles. Maybe something = like: o "Figure 1: Relationships between CDNI Metadata Objects (Diagram Represent= ation)=94 o =93Table 1: Relationships between CDNI Metadata Objects (Table Representa= tion)=94 *** section 3.1, Table1 "Objects it References=94 should this say "Objects it References or Contains=94 ? *** section 3,1: Table 2 s/A HostMatch object defines a hostname/A HostMatch object defines a hostna= me (or IP address)/ *** Section 3.1, Table 2 for Hostmatch it says "contains or references=94 for HostMetadata it says "contains (or references)=94 you should use the same style (unless there is a reason not to). Begin forwarded message: Resent-From: > From: > Subject: New Version Notification - draft-ietf-cdni-metadata-06.txt Date: 14 February 2014 22:46:18 CET Resent-To: >, >, >, >, >, >, >, > To: >, >, > A new version (-06) has been submitted for draft-ietf-cdni-metadata: http://www.ietf.org/internet-drafts/draft-ietf-cdni-metadata-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-metadata-06 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. --_000_4F2F12C0A71D4A32BDA75DE0007B0149ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4F30235ED4C36641B043D11274420A13@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Folks,

I=92ve started a WG Chair review of draft-ietf-cdni-metadata-06. = Below is a first batch of comments.

Francois

***Title:

s/CDN Interconnect Metadata/CDN Interconnection Metadata/

*** Authors:

You currently list 6 authors, which I think exceeds the maximum expect= ed number. You may need to consider splitting =93editors=94 and =93Contribu= ting Authors=94

*** throughout the document:

s/Metadata Interface/Metadata interface/

*** section1:

OLD:

"

CDNI enables a downstream CDN to service content requests on behalf
of an upstream CDN. The CDNI metadata associated wi= th a piece of

content (or with a set of contents) provides a downstream= CDN with

sufficient information for servicing content requests on = behalf of an

upstream CDN in accordance with the policies defined by t= he upstream

CDN.

The CDNI Metadata Interface is introduced by [RFC6707] al= ong with

three other interfaces that may be used to compose a CDNI= solution

(Control, Request Routing and Logging). [I-D.ietf-cdni-fr= amework]

expands on the information provided in [RFC6707] and desc= ribes each

interface, and the relationships between them, in more de= tail. The

requirements for the CDNI metadata interface are specifie= d in

[I-D.ietf-cdni-requirements].

=93

NEW:

=93

Content Delivery Networks Interconnection (CDNI) ([RFC6707]) enables a= downstream CDN to service content requests on behalf of an upstream CDN. &= nbsp;

The CDNI Metadata interface is discussed in [I-D.ietf-cdn= i-framework] along with

four other interfaces that may be used to compose a CDNI = solution

(CDNI Control interface, CDNI Request Routing Redirection inter= face, CDNI Footprint & Capabilities Advertisement interface interface a= nd Logging interface ). [I-D.ietf-cdni-framework]

describes each interface, and the relationships between t= hem. The

requirements for the CDNI metadata interface are specifie= d in

[I-D.ietf-cdni-requirements].

The CDNI metadata associated with a piece of

content (or with a set of contents) provides a downstream= CDN with

sufficient information for servicing content requests on = behalf of an

upstream CDN in accordance with the policies defined by t= he upstream

CDN.

"

*** section 1:

OLD:

=93

o A data structure for mapping content requests to CDNI Metadata=

properties (Section 3).

=93

NEW:

=93

o A data structure for mapping content requests and redirection = requests to CDNI Metadata

properties (Section 3).

=93

*** section 1:

s/Redirection Requests/redirection requests/

s/Content Requests/content requests/

*** section 1:

=93

Specifically, this document proposes:

o A data structure for mapping content requests to = CDNI Metadata

properties (Section 3).

o An initial set of CDNI Metadata properties (Secti= on 4.2).

o A RESTful web service for the transfer of CDNI Me= tadata

(Section 6).

=93

Is there a reason why the metadtaa structure defined in sectio 4.1 is = not mentioned here?

To me it seems an important part of the metadata specification.

*** section 2:

s/The proposed CDNI Metadata Interface/The CDNI Metadata Interface/

*** section 2:

s/Deterministic mapping from redirection and content requests/Determin= istic mapping from redirection requests and content requests/

*** section 2:

s/5. Leverage/5. Leveraging of/

OLD:

=93

Cacheability improves the latency of acquiring metadata while

maintaining its freshness and therefore improves the late= ncy of

serving content requests. The CDNI Metadata Interfa= ce uses HTTP to

achieve cacheability.

=93

NEW:

=93

Cacheability improves the latency of acquiring metadata while

maintaining its freshness, and therefore improves the lat= ency of

serving content requests and redirection requests, withou= t sacrifing accuracy. The CDNI Metadata Interface uses HTTP and its e= xisting cahing mechanisms to

achieve CDNI metadata cacheability.

"

*** section 3:

OLD:

=93

to be retrieved by a dCDN once, even if it is referenced by the CDNI
Metadata of multiple Hostnames.

=93

NEW:

=93

to be retrieved and stored by a dCDN once, even if it is referenced by= the CDNI

Metadata of multiple Hostnames or of multiple URI paths.<= /div>

*** title of section 3.1

s/HostIndex, HostMetadata & PathMetadata objects/HostIndex, HostMe= tadata and PathMetadata objects/

*** section 3.1:

s/uCDN's CDNI Metadata data store/uCDN CDNI Metadata data store/

*** section 3.1:

OLD:

=93

It enables surrogates in the dCDN to

deterministically discover, on receipt of a User Agent re= quest for

content, which other CDNI Metadata objects it requires in= order to

deliver the requested content.

=93

NEW:

=93

It enables the dCDN to

deterministically discover, on receipt of a User Agent re= quest for

content, which other CDNI Metadata objects it requires in= order to

deliver the requested content.

=93

[Rationale: the MI is intended to be used between uCDN and dCDN. It mi= ght also be used inside teh dCDN and by surrogate sthemselves, but that is = not necessary. So we may want to refer to the MI endpoints as =93the uCDN= =94 and =93dCDN=94 (and not the "dCDN Surrogates=94) ]

*** section 3.1:

OLD:

=93

When looking up CDNI Metadata, the downstream CDN looks

up the requested Hostname (or IP address) in the HostInde= x,

=93

NEW:

=93

When looking up CDNI Metadata, the downstream CDN looks

up the requested Hostname (or IP address) against the Hos= tMatch entries in the HostIndex,

=93

*** section 3.1:

OLD:

=93

Besides containing the default CDNI Metadata for the specified

Hostname, HostMetadata and PathMetadata objects may also = contain

PathMatch objects which in turn contain PathMetadata obje= cts.

=93

NEW:

=93

HostMetadata and PathMetadata objects may also contain

PathMatch objects which in turn contain PathMetadata obje= cts.

=93

[Rationale: the main part of the sentence is applicable to both = HostMetadata and PathMetadata, which grammatically suggests that the first = part of the sentence is also applicable to both, while it is only applicabl= e to Hostmetadata]

*** section 3.1:

s/For the purposes of retrieving CDNI Metadata all/For the purposes of= retrieving CDNI Metadata, all/

*** section 3.1, Table1.

"The relationships in Figure 1 are summarised in Table 1 below.= =94

I think Table 1, contains the exact same information as Figure 1. .i.e= ., Table 1 does not provide a =93summary=94. It just shows the same informa= tion in a different way. Or am I missing some information in Figure 1 that = is not in Table 1?

I was going to comment that perhaps we could get rid of Table 1, but I= can see that it may be worth expressing it in a tabular manner as well, so= I am OK to keep Table 1. But you may want to:

* = ; tweak the text to say something like:

"The relationships in Figure 1 are also represented in a tabular = format in Table 1 below.=94

* adju= st the titles of Figure 1 and Table 1 because it is confusing to have them = show teh same information but have different titles. Maybe something like:<= /div>
o &quo= t;Figure 1: Relationships between CDNI Metadata Objects (Diagram Representa= tion)=94

o =93T= able 1: Relationships between CDNI Metadata Objects (Table Representat= ion)=94

*** section 3.1, Table1

"Objects it References=94

should this say "Objects it References or Contains=94 ?

*** section 3,1: Table 2

s/A HostMatch object defines a hostname/A HostMatch object defines a h= ostname (or IP address)/

*** Section 3.1, Table 2

for Hostmatch it says "contains or references=94

for HostMetadata it says "contains (or references)=94

you should use the same style (unless there is a reason not to).

Begin forwarded message:

Resen= t-From: <wg-alias-bounces@tools.ietf.org>

From:= <internet-drafts@ietf.org>

Subje= ct: New Version Notification= - draft-ietf-cdni-metadata-06.txt

Date:= 14 February 2014 22:46= :18 CET

Resen= t-To: <ben@velocix.com>, <gwatson@velocix.com>, <kevin.ma@azukisystems.com>, <kleung@cisco.com>, <mcaulfie@cisco.com>, <= rmurray@velocix.com>, <d.malas@cablelabs.com>, <flefauch@cisco.com>

To: <= /b><cdni-chairs@tools.ietf.org>, <draft-ietf-cdni-metadat= a@tools.ietf.org>, <spencerdawkins.ietf@g= mail.com>

A new version (-06) has been submitted for draft-ietf-cdni-metadata:
http://www.ietf.org/internet-drafts/draft-ietf-cdni-metadata-06.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-metadata-06

Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

IETF Secretariat.

--_000_4F2F12C0A71D4A32BDA75DE0007B0149ciscocom_-- From nobody Tue Feb 18 17:00: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 7B64E1A0534 for ; Tue, 18 Feb 2014 17:00:29 -0800 (PST) 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 v_awD2qLPFQR for ; Tue, 18 Feb 2014 17:00:26 -0800 (PST) Received: from p01c12o145.mxlogic.net (p01c12o145.mxlogic.net [208.65.145.68]) by ietfa.amsl.com (Postfix) with ESMTP id CB1C81A052A for ; Tue, 18 Feb 2014 17:00:25 -0800 (PST) Received: from unknown [69.25.75.234] (EHLO HUB016.mail.lan) by p01c12o145.mxlogic.net(mxl_mta-7.2.4-1) with ESMTP id 72204035.2ac878c2d940.170568.00-506.386544.p01c12o145.mxlogic.net (envelope-from ); Tue, 18 Feb 2014 18:00:23 -0700 (MST) X-MXL-Hash: 530402272c9b9414-feade54d4a00a616eb309a23624cd7bc7616714e 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 f1204035.0.170530.00-224.386467.p01c12o145.mxlogic.net (envelope-from ); Tue, 18 Feb 2014 18:00:16 -0700 (MST) X-MXL-Hash: 5304022060178156-6f1abc4e4e62d12ff1a322a4a299350e0ffdf9f8 Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Tue, 18 Feb 2014 20:00:03 -0500 From: Kevin J Ma To: "Francois Le Faucheur (flefauch)" Date: Tue, 18 Feb 2014 20:00:01 -0500 Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-logging-09.txt Thread-Index: AQHPKLzwyQVwxW4CdEOqzBoL7rRz05qzj7KAgAg5a8A= Message-ID: <291CC3F9E50E7641901A54E85D0977C6D542760848@MAILR002.mail.lan> References: <20140213131011.12134.40084.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/cKtg3RILVZFIJe4b46R5r2J4DFY Cc: "cdni@ietf.org" Subject: Re: [CDNi] 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: Wed, 19 Feb 2014 01:00:29 -0000 Hi Francois and Iuniana, I went through the updated doc. It looks good. A couple of questions/comments/typos/notes below. (Note: It's a much shorter list this time. ;) thanx! -- Kevin J. Ma section 2.1, first bullet: "dCDN, control" -> "dCDN or control"? both "customization" and "customisation" are used. do we care about consistency wrt "z"s? (same in fourth bullet) should we just remove this reference to CI/MI? "We note that the CDNI Control interface or the CDNI Metadata interface appear as candidate interfaces on which to potentially build such a customisation mechanism in the future. " "Before such a" -> "Until such a" "UCDN" -> "uCDN" I don't follow the use of parentheticals here: "to generate (respectively, expect) in dCDN (respectively, in uCDN)." It wasn't clear to me what this is trying to say, so I don't have a proposed alternative. section 2.1: In thinking about the dCDN log aggregation, it occured to me that logs would not be temporally coherent, as logs from dCDNs will be off by N x M, where N is the depth of the dCDN and M is the non-real-time log retrieval interval. I don't think it's an issue, but I don't recall if we ever discussed or mentioned it. section 2.2.5.6.2: "such as the one averaged on a long period" -> "such as those averaged over long periods" "non-real- time" -> "non-real-time" section 3.1: technically CRLF is two octets; not sure if the BNF cares? "NHTAB =3D " section 3.4.1: for cs() and sc() do we want to limit this to zero or one, per value= ? "occurrence: there MAY be zero, one or any number of instances of this field." an alternative might be to restrict the definition of the Fields directive to disallow duplicate FIENAMEs? section 4.1.4: "dcdn.example" -> "dcdn.example.com"? section 4.2: client-side requirements, third bullet, missing semicolon: "in the CDNI Logging Feed" -> ""in the CDNI Logging Feed;" section 4.2: "unability to serve" -> "inability to serve" 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? section 5.2: "Field i.e.," -> "Field, i.e.," section 5.3: "a semantics that is" -> "semantics that are" section 6.1: "appropraite" -> "appropriate" section 6.3: "independently of IP" -> "independent of IP" > -----Original Message----- > From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] > Sent: Thursday, February 13, 2014 8:20 AM > To: Kevin J Ma > Cc: Francois Le Faucheur (flefauch); cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-logging-09.txt >=20 > Hi Kevin and all, >=20 > We just posted the updated version of cdni-logging that addresses Kevin's > review comments as discussed on the list (including latest comment about > privacy). >=20 > Could you please review and let us know if you have additional comments > before we move on to the next step (as agreed in Vancouver) which is to > submit the document to Working Group Last Call? >=20 > Thanks >=20 > Francois & Iuniana >=20 >=20 > On 13 Feb 2014, at 14:10, drafts@ietf.org> wrote: >=20 > > > > 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-09.txt > > Pages : 45 > > Date : 2014-02-13 > > > > 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-09 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-09 > > > > > > 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/ > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni From nobody Wed Feb 19 12:56: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 9EDFB1A0152 for ; Wed, 19 Feb 2014 12:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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.548, 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 4bWF8aZ1-ldM for ; Wed, 19 Feb 2014 12:56:36 -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 6BACF1A0150 for ; Wed, 19 Feb 2014 12:56:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6197; q=dns/txt; s=iport; t=1392843393; x=1394052993; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=n+IGFmWecYVNFHfGun/fHM0dyr3kJqgtowfJGV2tH+E=; b=Jy1AjHcHvpZGTxtjsZ3Eb2+l19M4Dq9GWXpebc/XbBTzzySR2r4an+8E on21IYzys9oG4RgfANFep/4KfpmB2W6b3WkGtCLxIJUH9Nxj90mQoNdR6 gFqEKb5Lcmdg0PxyjPF1vqhToIAQ20rWBmzWOBcrhDN/X212elMDpkhX4 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAIUZBVOtJXG9/2dsb2JhbABZgwY4UQbAB4EcFnSCJQEBAQMBAQEBNzQJAgUHBAIBCA4DBAEBCxQJBycLFAkIAgQOBQgBh3QHAQgFzioXjjMxBwaDHoEUBJlikHKDLYFoAh4EAhw X-IronPort-AV: E=Sophos;i="4.97,507,1389744000"; d="scan'208";a="305213072" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 19 Feb 2014 20:56:32 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1JKuW4h021425 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Feb 2014 20:56:32 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.138]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 14:56:32 -0600 From: "Kent Leung (kleung)" To: Mark Nottingham Thread-Topic: [CDNi] New Version Notification for draft-leung-cdni-uri-signing-04.txt Thread-Index: AQHPLbURn5JUUyTIEUaAm7vNBa9RCg== Date: Wed, 19 Feb 2014 20:56:32 +0000 Message-ID: References: <20140214010816.22518.21143.idtracker@ietfa.amsl.com> <294BC0AD-FABA-42DA-ADDB-91F9279ACD31@mnot.net> In-Reply-To: <294BC0AD-FABA-42DA-ADDB-91F9279ACD31@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.231.136] 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/4c6p1_OqTc2PmMGI8fHi5Lt5zYw Cc: "cdni@ietf.org" Subject: Re: [CDNi] New Version Notification for draft-leung-cdni-uri-signing-04.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: Wed, 19 Feb 2014 20:56:39 -0000 Hi Mark. See comments below. -----Original Message----- From: Mark Nottingham [mailto:mnot@mnot.net]=20 Sent: Sunday, February 16, 2014 5:17 PM To: Kent Leung (kleung) Cc: cdni@ietf.org Subject: Re: [CDNi] New Version Notification for draft-leung-cdni-uri-signi= ng-04.txt Hi Kent, Thanks for the heads up. I'm looking a the draft and the diffs quickly, so apologies if I'm misreadi= ng it. In Sections 3 and 4, as I understand it, you're using a temporary URI with = all of the various metatdata you're interested in added to it, taking a sig= nature of it, and then adding that signature to the actual URI with the par= ameter that's communicated by the metadata interface, correct? KL> Right. If so, the text could be a little more clear about this -- the way that it'= s written, it's easy to think that 'URISigningPackage' is static and unchan= ging.=20 E.g., in section 3: > 5. Append the parameter name used to indicate the URI Signing=09 > Package Attribute. This parameter name is communicated via the= =09 > CDNI Metadata Interface. Alternatively, it is set to=09 > 'URISigningPackage' by configuration. Append the string=09 > "URISigningPackage=3D" to the message. This would be more clear as something like: """ 5. Append the parameter name used to indicate the URI Signing Package Attri= bute, as communicated via the CDNI Metadata interface, followed by an "=3D"= . If non is communicated by the metadata interface, it defaults to "URISign= ingPackage". For example, if the CDNI Metadata interface specifies "SIG", = append the string "SIG=3D" to the message. """ and so forth. KL> OK. We can add an example. For your text, ""=3D". If non is communicate= d by the metadata interface, it defaults to "URISigningPackage"", are you s= aying it's OK to default to an attribute name specified in the draft? If so= , would this attribute name need to be IANA-based? I'd like the clarify the= language. More deeply, the draft assumes that URIs always have query strings encoded = in the format specified by HTML . While that format is extremely common, it isn't a c= onstraint on URIs -- even HTTP URIs. One way to avoid this would be to have the CDNI Metadata Interface convey a= URI Template to specify where the signature goes: http://tools.ietf.org/html/rfc6570 https://code.google.com/p/uri-templates/wiki/Implementations KL> OK. We'll need to look at this when the CDNI Metadata interface section= is filled in. Thanks. Kent Cheers, On 15 Feb 2014, at 3:48 am, Kent Leung (kleung) wrote: > Hi Mark. We had a discussion about "URI Squatting" issues with this draft= at the last IETF. This particular issue is covered in draft-ietf-appsawg-u= ri-get-off-my-lawn. There was a consensus to use CDNI Metadata Interface to= define the attribute name(s) in the URI query string as the resolution. Th= e revision to this draft addressed the point that you've raised (see 2nd bu= llet below). Please let me know if you have any comments or concerns. Thank= s. >=20 > Kent >=20 >=20 > -----Original Message----- > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Kent Leung (kleung= ) > Sent: Thursday, February 13, 2014 5:27 PM > To: cdni@ietf.org > Subject: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-sig= ning-04.txt >=20 > FYI. This new version addressed some of the issues and comments raised du= ring last IETF session. The key changes are: >=20 > - Updated the document to be in line with the new approach of mandatory p= ackaging and encapsulated information elements. > - Only one attribute in the URI query string is used for URI Signing. The= attribute name is provided by CDNI metadata or via configuration. > - Adjusted section 2 to make a clear distinction between an information e= lement (the three categories) and the packaging attribute.=20 > - Fixed inconsistencies and errors in the document which addressed Kevin'= s comments >=20 > Kent >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: Thursday, February 13, 2014 5:08 PM > To: Ray van Brandenburg; Kent Leung (kleung); Bill Downey; Bill Downey; S= cott Leibrand; Scott Leibrand; Kent Leung (kleung); Francois Le Faucheur (f= lefauch); Ray van Brandenburg; Francois Le Faucheur (flefauch) > Subject: New Version Notification for draft-leung-cdni-uri-signing-04.txt >=20 >=20 > A new version of I-D, draft-leung-cdni-uri-signing-04.txt > has been successfully submitted by Kent Leung and posted to the IETF repo= sitory. >=20 > Name: draft-leung-cdni-uri-signing > Revision: 04 > Title: URI Signing for CDN Interconnection (CDNI) > Document date: 2014-02-13 > Group: Individual Submission > Pages: 34 > URL: http://www.ietf.org/internet-drafts/draft-leung-cdni-uri-= signing-04.txt > Status: https://datatracker.ietf.org/doc/draft-leung-cdni-uri-sig= ning/ > Htmlized: http://tools.ietf.org/html/draft-leung-cdni-uri-signing-0= 4 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-leung-cdni-uri-s= igning-04 >=20 > Abstract: > This document describes how the concept of URI signing supports the > content access control requirements of CDNI and proposes a URI > signing scheme. >=20 > The proposed URI signing method specifies the information needed to > be included in the URI and the algorithm used to authorize and to > validate access requests for the content referenced by the URI. Some > of the information may be accessed by the CDN via configuration or > CDNI metadata. >=20 >=20 >=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 > The IETF Secretariat >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni -- Mark Nottingham http://www.mnot.net/ From nobody Thu Feb 20 03:48:17 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 A9BBC1A00B9 for ; Thu, 20 Feb 2014 03:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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.548, 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 ch_CULok93p6 for ; Thu, 20 Feb 2014 03:48:10 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C70311A0061 for ; Thu, 20 Feb 2014 03:48:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8532; q=dns/txt; s=iport; t=1392896886; x=1394106486; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YwBxcizPGypYf3yovExqL73f/d6pLOQev5vgbuNB0UA=; b=i+O+4J6rv/oe58CG6ERsBG0MIszgbT25POEg8nSmu/qZlkVXO/l5f5m4 hrjKJ1NoTaCYTBmMuE7KAQfCqZu+akr/vrKOV1i+/pU88bUBIkqUiO00V o5gFfK1vgQCgZ1hkNvvM+sFw3yAsRRASq9pw9psBbldRV2THhaDlTEA06 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAO/qBVOtJXG8/2dsb2JhbABZgwY4UQbACoENFnSCJQEBAQMBAQEBCRtHCwUHBAIBCBEEAQEBJwcnCxQJCAIEDgUJFodeCAgFzk4Xjg0kCCsHAgSDHoEUBJgwgTKQcoMtgWlB X-IronPort-AV: E=Sophos;i="4.97,512,1389744000"; d="scan'208";a="305348970" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 20 Feb 2014 11:48:06 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1KBm56d026373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Feb 2014 11:48:05 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; Thu, 20 Feb 2014 05:48:03 -0600 From: "Francois Le Faucheur (flefauch)" To: Kevin J Ma Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-logging-09.txt Thread-Index: AQHPKLzwyQVwxW4CdEOqzBoL7rRz05qzj7KAgAg5a8CAAq02AA== Date: Thu, 20 Feb 2014 11:48:03 +0000 Message-ID: <3DF6394F-C649-45CD-BE51-33AEEFEEEA28@cisco.com> References: <20140213131011.12134.40084.idtracker@ietfa.amsl.com> <291CC3F9E50E7641901A54E85D0977C6D542760848@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6D542760848@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.200] Content-Type: text/plain; charset="Windows-1252" Content-ID: <96D23E2C72C87D4E91BDC1DA5AE5AFC8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/H4GIJLFcp7woBVsNbZGg5w6JeDk Cc: "cdni@ietf.org" Subject: Re: [CDNi] 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: Thu, 20 Feb 2014 11:48:14 -0000 Hi Kevin On 19 Feb 2014, at 02:00, Kevin J Ma wrote: > Hi Francois and Iuniana, >=20 > I went through the updated doc. Thanks much. > It looks good. Great. > A couple of questions/comments/typos/notes below. > (Note: It's a much shorter list this time. ;) >=20 There are only 2 items that need more discussions: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 3.4.1: for cs() and sc() > do we want to limit this to zero or one, per valu= e? > "occurrence: there MAY be zero, one or any number of instances > of this field." > an alternative might be to restrict the definition of the Fields > directive to disallow duplicate FIENAMEs? It is not obvious to me that it will never be valid in HTTP to have the sam= e header appear more than once. Or is there a fundamental principle of HTTP= that guarantees this won=92t (usefully) happen? > 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? We=92ll need some guidance here. I=92ll bring that separately on the list. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D All other comments have been resolved (see below for details): > thanx! >=20 > -- Kevin J. Ma >=20 > section 2.1, first bullet: > "dCDN, control" -> "dCDN or control=94? fixed. >=20 > both "customization" and "customisation" are used. > do we care about consistency wrt "z"s? (same in fourth bullet) all instances turned to =93z=94. > should we just remove this reference to CI/MI? > "We note > that the CDNI Control interface or the CDNI Metadata interface > appear as candidate interfaces on which to potentially build such > a customisation mechanism in the future. =93 This was useful at the time when we were unsure as to whether this woudl be= in/out of scope and when we explored the candidate mechanisms. Today, I ag= ree that this sentence does not bring much. Removed. > "Before such a" -> "Until such a=94 done. >=20 > "UCDN" -> =93uCDN" >=20 fixed > I don't follow the use of parentheticals here: > "to generate (respectively, expect) in dCDN > (respectively, in uCDN)." > It wasn't clear to me what this is trying to say, so > I don't have a proposed alternative. rephrased to: =93 Until such a mechanism is available, the uCDN and dCDN are expected to agre= e off-line on what exact set of CDNI Logging information is to be provided = by the dCDN to the uCDN, and to rely on management plane actions to configu= re the CDNI Logging functions in the dCDN to generate this information set = and in the uCDN to expect this information set. " > section 2.1: In thinking about the dCDN log aggregation, it occured to > me that logs would not be temporally coherent, agreed. > as logs > from dCDNs will be off by N x M, where N is the depth of > the dCDN and M is the non-real-time log retrieval > interval. I don=92t think the time lag has to be as bad as NxM, but the key point is = that log files are not synchronised so they cannot be coherent. > I don't think it's an issue, but I don't > recall if we ever discussed or mentioned it. I don=92t think this raises a special issue. More of an operational conside= ration. I think there may be quite a set of operational considerations invo= lved in inter-operator logging exchange, but I don't really see them in sco= pe for this document. >=20 > section 2.2.5.6.2: > "such as the one averaged on a long period" -> > "such as those averaged over long periods=94 fixed > "non-real- time" -> "non-real-time=94 fixed > section 3.1: > technically CRLF is two octets; not sure if the BNF cares? that=92s broken > "NHTAB =3D =94 replaced by : "NHTAB =3D =94 this avoids any potential confusion with our CRLF line separator. > section 3.4.1: for cs() and sc() > do we want to limit this to zero or one, per valu= e? > "occurrence: there MAY be zero, one or any number of instances > of this field." > an alternative might be to restrict the definition of the Fields > directive to disallow duplicate FIENAMEs? It is not obvious to me that it will never be valid in HTTP to have the sam= e header appear more than once. Or is there a fundamental principle of HTTP= that guarantees this won=92t (usefully) happen? >=20 > section 4.1.4: "dcdn.example" -> "dcdn.example.com=94? =93.example=94 is also a recommended example domain name, and it is also th= e one used in teh latest version of cdni-framework. >=20 > section 4.2: client-side requirements, third bullet, missing semicolon: > "in the CDNI Logging Feed" -> ""in the CDNI Logging Feed;=94 fixed >=20 > section 4.2: "unability to serve" -> "inability to serve=94 > section 5.2: "Field i.e.," -> "Field, i.e.," > section 5.3: "a semantics that is" -> "semantics that are" > section 6.1: "appropraite" -> =93appropriate" >=20 4 above fixed. > section 6.3: "independently of IP" -> "independent of IP=94 I think the adverb, and not the adjective, is needed here, so I kept =93ind= ependently=94 for now. Thanks !!! >=20 >> -----Original Message----- >> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] >> Sent: Thursday, February 13, 2014 8:20 AM >> To: Kevin J Ma >> Cc: Francois Le Faucheur (flefauch); cdni@ietf.org >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-logging-09.txt >>=20 >> Hi Kevin and all, >>=20 >> We just posted the updated version of cdni-logging that addresses Kevin'= s >> review comments as discussed on the list (including latest comment about >> privacy). >>=20 >> Could you please review and let us know if you have additional comments >> before we move on to the next step (as agreed in Vancouver) which is to >> submit the document to Working Group Last Call? >>=20 >> Thanks >>=20 >> Francois & Iuniana >>=20 >>=20 >> On 13 Feb 2014, at 14:10, > drafts@ietf.org> wrote: >>=20 >>>=20 >>> 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. >>>=20 >>> Title : CDNI Logging Interface >>> Authors : Francois Le Faucheur >>> Gilles Bertrand >>> Iuniana Oprescu >>> Roy Peterkofsky >>> Filename : draft-ietf-cdni-logging-09.txt >>> Pages : 45 >>> Date : 2014-02-13 >>>=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-09 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-09 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of >> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> 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 >=20 From nobody Thu Feb 20 04:05: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 DA2441A00E0 for ; Thu, 20 Feb 2014 04:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 INt9h8hG9MA7 for ; Thu, 20 Feb 2014 04:05:15 -0800 (PST) Received: from owa.velocix.com (mail-out1.velocix.com [81.134.152.10]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9C91A00DC for ; Thu, 20 Feb 2014 04:05:15 -0800 (PST) Received: from EXB01-MLT.corp.velocix.com ([169.254.2.235]) by EXC00CAM.corp.velocix.com ([172.18.4.40]) with mapi id 14.02.0347.000; Thu, 20 Feb 2014 12:05:10 +0000 From: Rob Murray To: "Francois Le Faucheur (flefauch)" Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-logging-09.txt Thread-Index: AQHPKLz4oEV8XKNZZUGUztres0SGkJqzKxyAgAifP4CAAkdjgIAABMkA Date: Thu, 20 Feb 2014 12:05:10 +0000 Message-ID: <49C77373835C5A479BC2A84B2A1D66BD8EEA2D1C@EXB01-MLT.corp.velocix.com> References: <20140213131011.12134.40084.idtracker@ietfa.amsl.com> <291CC3F9E50E7641901A54E85D0977C6D542760848@MAILR002.mail.lan> <3DF6394F-C649-45CD-BE51-33AEEFEEEA28@cisco.com> In-Reply-To: <3DF6394F-C649-45CD-BE51-33AEEFEEEA28@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.224.120.220] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5BF98B90D125DE4EA095D45DB0C4A8D1@velocix.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/m5G7huqDrXUSpfBzUueCJuftrpA Cc: "cdni@ietf.org" Subject: Re: [CDNi] 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: Thu, 20 Feb 2014 12:05:17 -0000 On 20 Feb 2014, at 11:48, Francois Le Faucheur (flefauch) wrote: >> section 3.4.1: for cs() and sc() >> do we want to limit this to zero or one, per valu= e? >> "occurrence: there MAY be zero, one or any number of instances >> of this field." >> an alternative might be to restrict the definition of the Fields >> directive to disallow duplicate FIENAMEs? >=20 > It is not obvious to me that it will never be valid in HTTP to have the s= ame header appear more than once. Or is there a fundamental principle of HT= TP that guarantees this won=92t (usefully) happen? It can't usefully happen - http header values can be lists separated by com= mas, in which case the header can appear more than once in the response but= semantically there's only one value (and I'd think it should be logged as = one value). Or, if a header appears more than once but it isn't a list, the cache can t= reat the response as invalid. Or it might decide to pick one of the given v= alues. (Multiple values for one header shouldn't happen, but there's nothin= g stopping a server from doing it by mistake.) >From RFC2616, section 4.2 ... Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded. Rob. From nobody Thu Feb 20 05:41:40 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 1950F1A0162 for ; Thu, 20 Feb 2014 05:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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.548, 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 Xtlz2xjMdjxD for ; Thu, 20 Feb 2014 05:41:36 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4706A1A016C for ; Thu, 20 Feb 2014 05:41:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2425; q=dns/txt; s=iport; t=1392903693; x=1394113293; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=j5g2HWa+Q4GegkqCiOj4iInSn50HyEnTMCF9bV6k7Ds=; b=CSE9hhcqI79bjLhqs/YzdTTYsz/AoxRL1McZ47y+ElNlvfcrDiDIpzMT CCQ3TBA5YwNgN6u0Y51t0MWiFZikcDIfFJzMm6tzEtm1Tr7lzdzthCvjf XylGiN+FQJN2Sd2hh6mI+1hH/H+IN8CN0UyD2QIhOXihiD8W9T8W9K/wf 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFALcEBlOtJXHB/2dsb2JhbABZgwY4V8AKgQwWdIIlAQEBAwF5EAIBCA4KLjIlAgQBDQUfh14IzksXjg0kCCsHgySBFAEDlEeDaZIkgy2BaUE X-IronPort-AV: E=Sophos;i="4.97,512,1389744000"; d="scan'208";a="305368532" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 20 Feb 2014 13:41:32 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1KDfWdt000891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Feb 2014 13:41:32 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.67]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Thu, 20 Feb 2014 07:41:32 -0600 From: "Francois Le Faucheur (flefauch)" To: Rob Murray , Kevin J Ma Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-logging-09.txt Thread-Index: AQHPKLzwyQVwxW4CdEOqzBoL7rRz05qzj7KAgAg5a8CAAq02AIAABMkAgAAa64A= Date: Thu, 20 Feb 2014 13:41:31 +0000 Message-ID: <56B4D1F8-605E-4012-92BD-435BE48B1ED4@cisco.com> References: <20140213131011.12134.40084.idtracker@ietfa.amsl.com> <291CC3F9E50E7641901A54E85D0977C6D542760848@MAILR002.mail.lan> <3DF6394F-C649-45CD-BE51-33AEEFEEEA28@cisco.com> <49C77373835C5A479BC2A84B2A1D66BD8EEA2D1C@EXB01-MLT.corp.velocix.com> In-Reply-To: <49C77373835C5A479BC2A84B2A1D66BD8EEA2D1C@EXB01-MLT.corp.velocix.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.200] Content-Type: text/plain; charset="Windows-1252" Content-ID: <74593EA23331BF4BAF1D9B80C15B737B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/2XHMAUkQ0yCkCGgvzEOZ-3Vd_qQ Cc: "cdni@ietf.org" Subject: Re: [CDNi] 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: Thu, 20 Feb 2014 13:41:39 -0000 Hi Rob, Kevin, Good info. So for both cs() and sc(), I modified t= he text to : "occurrence: there MAY be zero, one or any number of instances of this fiel= d. For a given , there MUST be zero or exactly one instan= ce of this field.=94 Cheers Francois On 20 Feb 2014, at 13:05, Rob Murray wrote: >=20 > On 20 Feb 2014, at 11:48, Francois Le Faucheur (flefauch) wrote: >=20 >>> section 3.4.1: for cs() and sc() >>> do we want to limit this to zero or one, per valu= e? >>> "occurrence: there MAY be zero, one or any number of instances >>> of this field." >>> an alternative might be to restrict the definition of the Fields >>> directive to disallow duplicate FIENAMEs? >>=20 >> It is not obvious to me that it will never be valid in HTTP to have the = same header appear more than once. Or is there a fundamental principle of H= TTP that guarantees this won=92t (usefully) happen? >=20 > It can't usefully happen - http header values can be lists separated by c= ommas, in which case the header can appear more than once in the response b= ut semantically there's only one value (and I'd think it should be logged a= s one value). >=20 > Or, if a header appears more than once but it isn't a list, the cache can= treat the response as invalid. Or it might decide to pick one of the given= values. (Multiple values for one header shouldn't happen, but there's noth= ing stopping a server from doing it by mistake.) >=20 > From RFC2616, section 4.2 ... >=20 > Multiple message-header fields with the same field-name MAY be > present in a message if and only if the entire field-value for that > header field is defined as a comma-separated list [i.e., #(values)]. > It MUST be possible to combine the multiple header fields into one > "field-name: field-value" pair, without changing the semantics of the > message, by appending each subsequent field-value to the first, each > separated by a comma. The order in which header fields with the same > field-name are received is therefore significant to the > interpretation of the combined field value, and thus a proxy MUST NOT > change the order of these field values when a message is forwarded. >=20 > Rob. >=20 From nobody Thu Feb 20 05:51: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 571AE1A0171 for ; Thu, 20 Feb 2014 05:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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.548, 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 OSwM-9OZLOP7 for ; Thu, 20 Feb 2014 05:50:54 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFDE1A0174 for ; Thu, 20 Feb 2014 05:50:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=794; q=dns/txt; s=iport; t=1392904250; x=1394113850; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=arULuR+IGqtjo5dgVPhueA/7WYZKwtPQIKHGUZU5REk=; b=W7r2r5dYe1+3r9jDkXXo1trILLmBQ908x/Cs326MSMELvC/wnDCOSrj6 cGW/e+VqFaki22asKs5V2rf8E05DkdtzK5ZXtr850cQKizc5Q13ah0E+d 4c3POmJbTbB0UQeIIn+MmRueenqI74lc03nAJJva26vPpnD7HC9tETINo g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAwHBlOtJV2d/2dsb2JhbABZgwaBD8AKgQwWdIIlAQEBBDo/EAIBIB4QMiUCBA4FiAXORheOZAeDJIEUAQOYMJIkgy2CKg X-IronPort-AV: E=Sophos;i="4.97,512,1389744000"; d="scan'208";a="305352198" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 20 Feb 2014 13:50:50 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1KDooNt022747 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Feb 2014 13:50:50 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.67]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Thu, 20 Feb 2014 07:50:49 -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: AQHPKLzwyQVwxW4CdEOqzBoL7rRz0w== Date: Thu, 20 Feb 2014 13:50:49 +0000 Message-ID: References: <20140213131011.12134.40084.idtracker@ietfa.amsl.com> <291CC3F9E50E7641901A54E85D0977C6D542760848@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6D542760848@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.200] Content-Type: text/plain; charset="us-ascii" Content-ID: <1E66D66F3FA250418A02242F5599301B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/1yTH5kgu2rPVRtPGMycrdMjPwSY Cc: "cdni@ietf.org" Subject: [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: Thu, 20 Feb 2014 13:50:58 -0000 Hi Jon, In his review comments on cdni-logging, Kevin said: On 19 Feb 2014, at 02:00, Kevin J Ma wrote: >=20 > 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? >=20 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= From nobody Thu Feb 20 19:38: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 8E8551A03CC for ; Thu, 20 Feb 2014 19:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.225 X-Spam-Level: X-Spam-Status: No, score=-0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] 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 ex-DhoAq9zqJ for ; Thu, 20 Feb 2014 19:38:24 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id B47701A02E4 for ; Thu, 20 Feb 2014 19:38:22 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee25306c9a15ed-985ed; Fri, 21 Feb 2014 11:36:02 +0800 (CST) X-RM-TRANSID: 2ee25306c9a15ed-985ed Received: from cliff (unknown[117.134.2.145]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee35306c99f4af-2961e; Fri, 21 Feb 2014 11:36:02 +0800 (CST) X-RM-TRANSID: 2ee35306c99f4af-2961e Date: Fri, 21 Feb 2014 11:38:13 +0800 From: yiqiuchao To: "Francois Le Faucheur (flefauch)" References: <20140213131011.12134.40084.idtracker@ietfa.amsl.com>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.88[cn] Mime-Version: 1.0 Message-ID: <201402211137118185825@chinamobile.com> Content-Type: multipart/related; boundary="----=_001_NextPart325326163058_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/zMiJ3p_I-7e4In42OGWOwGL2VbU Cc: "cdni@ietf.org" Subject: [CDNi] some comments.//Re: Re: I-D Action: draft-ietf-cdni-logging-09.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: yiqiuchao 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 Feb 2014 03:38:27 -0000 This is a multi-part message in MIME format. ------=_001_NextPart325326163058_=---- Content-Type: multipart/alternative; boundary="----=_002_NextPart106231072172_=----" ------=_002_NextPart106231072172_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgRnJhbmNvaXMsIA0KSSBoYXZlIHJlYWQgdGhlIGRyYWZ0IGFuZCBsZWFudCBhIGxvdCwgdGhh bmtzLiANCkFuZCBJIGhhdmUgc29tZSBjb21tZW50cyBhcyBiZWxvdyB3aGljaCBhcmUgaGlnaGxp Z2h0ZWQgaW4gcmVko7oNCjEuIFBhZ2UgNzoNCiAgIDYuICAgQXNzdW1pbmcgdGhhdCBkQ0RObiBp cyBzZWxlY3RlZCBhcyBhIHNlcnZpbmcgZENETiBwcm92aWRlciwgdGhlDQogICAgICAgIGVuZC11 c2VyIGRvZXMgYSBETlMgbG9va3VwIHVzaW5nIGRDRE5uoa9zIGRpc3Rpbmd1aXNoZWQNCiAgICAg ICAgQ0ROLWRvbWFpbiAocGVlci1kQ0RObi0xLmRDRE5uLm5ldCkuICBkQ0RObi0xoa9zIChkQ0RO bidzKUROUyByZXNvbHZlcg0KICAgICAgICByZXR1cm5zIHRoZSBJUCBhZGRyZXNzIG9mIGEgcmVx dWVzdCByb3V0ZXIgZm9yIGRDRE5uLg0KICAgNy4gICBUaGUgcmVxdWVzdCByb3V0ZXIgZm9yIGRD RE4xKGRDRE5uKSBwcm9jZXNzZXMgdGhlIEhUVFAgcmVxdWVzdCBhbmQNCiAgICAgICAgc2VsZWN0 cyBhIHN1aXRhYmxlIGRlbGl2ZXJ5IG5vZGUgdG8gc2VydmUgdGhlIGVuZC11c2VyIHJlcXVlc3Qs DQogICAgICAgIGFuZCByZXR1cm5zIGEgMzAyIHJlZGlyZWN0IG1lc3NhZ2UgZm9yIGEgbmV3IFVS TCBjb25zdHJ1Y3RlZCBieQ0KICAgICAgICByZXBsYWNpbmcgdGhlIGhvc3RuYW1lIGJ5IGEgc3Vi ZG9tYWluIG9mIHRoZSBkQ0RObqGvcw0KICAgICAgICBkaXN0aW5ndWlzaGVkIENETi1kb21haW4g dGhhdCBwb2ludHMgdG8gdGhlIHNlbGVjdGVkIGRlbGl2ZXJ5DQogICAgICAgIG5vZGUuDQogICBh bmQgdGhlIGZpZ3VyZSAxIGluIFBhZ2UgNiBzaG91bGQgYmUgbW9kaWZpZWQgYXMgd2VsbC4NCg0K Mi4gUGFnZSAxMCwgdHlwb3M6DQoNCg0KMy4gSSB0aGluayB0aGUgQ05BTUVlZCBkb21haW4gbmFt ZSBzaG91bGQgYmUgYWRkZWQgdG8gdGhlIGVuZCBvZiB0aGUgb3JpZ2luYWwgb25lLCBzbyB0aGUg ZENETjEuY2RuLmNzcC5jb20gc2hvd2VkIGluIHRoZSBhYm92ZSBmaWd1cmUgc2hvdWxkIGJlIGNk bi5jc3AuY29tLmRDRE4xLm5ldC4NCg0KDQoNCnlpcWl1Y2hhbyBmcm9tIENoaW5hIE1vYmlsZQ0K DQpGcm9tOiBGcmFuY29pcyBMZSBGYXVjaGV1ciAoZmxlZmF1Y2gpDQpEYXRlOiAyMDE0LTAyLTEz IDIxOjE5DQpUbzogS2V2aW4gSiBNYQ0KQ0M6IGNkbmlAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb Q0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLWxvZ2dpbmctMDkudHh0DQpIaSBLZXZp biBhbmQgYWxsLA0KDQpXZSBqdXN0IHBvc3RlZCB0aGUgdXBkYXRlZCB2ZXJzaW9uIG9mIGNkbmkt bG9nZ2luZyB0aGF0IGFkZHJlc3NlcyBLZXZpbidzIHJldmlldyBjb21tZW50cyBhcyBkaXNjdXNz ZWQgb24gdGhlIGxpc3QgKGluY2x1ZGluZyBsYXRlc3QgY29tbWVudCBhYm91dCBwcml2YWN5KS4N Cg0KQ291bGQgeW91IHBsZWFzZSByZXZpZXcgYW5kIGxldCB1cyBrbm93IGlmIHlvdSBoYXZlIGFk ZGl0aW9uYWwgY29tbWVudHMgYmVmb3JlIHdlIG1vdmUgb24gdG8gdGhlIG5leHQgc3RlcCAoYXMg YWdyZWVkIGluIFZhbmNvdXZlcikgd2hpY2ggaXMgdG8gc3VibWl0IHRoZSBkb2N1bWVudCB0byBX b3JraW5nIEdyb3VwIExhc3QgQ2FsbD8NCg0KVGhhbmtzDQoNCkZyYW5jb2lzICYgSXVuaWFuYQ0K DQoNCk9uIDEzIEZlYiAyMDE0LCBhdCAxNDoxMCwgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4g PGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQoNCj4gDQo+IEEgTmV3IEludGVybmV0 LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJl Y3Rvcmllcy4NCj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29udGVudCBEZWxp dmVyeSBOZXR3b3JrcyBJbnRlcmNvbm5lY3Rpb24gV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4N Cj4gDQo+ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBDRE5JIExvZ2dpbmcgSW50ZXJmYWNlDQo+ ICAgICAgICBBdXRob3JzICAgICAgICAgOiBGcmFuY29pcyBMZSBGYXVjaGV1cg0KPiAgICAgICAg ICAgICAgICAgICAgICAgICAgR2lsbGVzIEJlcnRyYW5kDQo+ICAgICAgICAgICAgICAgICAgICAg ICAgICBJdW5pYW5hIE9wcmVzY3UNCj4gICAgICAgICAgICAgICAgICAgICAgICAgIFJveSBQZXRl cmtvZnNreQ0KPiAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1jZG5pLWxvZ2dpbmctMDku dHh0DQo+ICBQYWdlcyAgICAgICAgICAgOiA0NQ0KPiAgRGF0ZSAgICAgICAgICAgIDogMjAxNC0w Mi0xMw0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgVGhpcyBtZW1vIHNwZWNpZmllcyB0aGUgTG9nZ2lu ZyBpbnRlcmZhY2UgYmV0d2VlbiBhIGRvd25zdHJlYW0gQ0RODQo+ICAgKGRDRE4pIGFuZCBhbiB1 cHN0cmVhbSBDRE4gKHVDRE4pIHRoYXQgYXJlIGludGVyY29ubmVjdGVkIGFzIHBlciB0aGUNCj4g ICBDRE4gSW50ZXJjb25uZWN0aW9uIChDRE5JKSBmcmFtZXdvcmsuICBGaXJzdCwgaXQgZGVzY3Jp YmVzIGENCj4gICByZWZlcmVuY2UgbW9kZWwgZm9yIENETkkgbG9nZ2luZy4gIFRoZW4sIGl0IHNw ZWNpZmllcyB0aGUgQ0ROSQ0KPiAgIExvZ2dpbmcgRmlsZSBmb3JtYXQgYW5kIHRoZSBhY3R1YWwg cHJvdG9jb2wgZm9yIGV4Y2hhbmdlIG9mIENETkkNCj4gICBMb2dnaW5nIEZpbGVzLg0KPiANCj4g DQo+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0K PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNkbmktbG9nZ2lu Zy8NCj4gDQo+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0K PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNkbmktbG9nZ2luZy0wOQ0K PiANCj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0K PiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWNkbmktbG9nZ2lu Zy0wOQ0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+ IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoN Cj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IENETmkgbWFpbGluZyBsaXN0 DQo+IENETmlAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jZG5pDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpDRE5pIG1haWxpbmcgbGlzdA0KQ0ROaUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jZG5p ------=_002_NextPart106231072172_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Francois,

I have read the draft and leant a lot= ,=20 thanks.

And I have some comments as below whi= ch are=20 highlighted in red=A3=BA

1. Page 7:

   6.   Assuming that dCDNn&n= bsp;is selected as a serving dCDN provider,&= nbsp;the

        end-user does&nb= sp;a DNS lookup using dCDNn=A1=AFs distinguished<= /DIV>
        CDN-domain (peer= -dCDNn-1.dCDNn.net).  dCDNn-1=A1=AFs (dCDNn's)DNS resolver

        returns the = ;IP address of a request router for dCD= Nn.

   7.   The request router&nb= sp;for dCDN1(dCDNn) processes the HTTP&= nbsp;request and

        selects a s= uitable delivery node to serve the end-user&= nbsp;request,

        and returns = ;a 302 redirect message for a new URL&n= bsp;constructed by

        replacing the&nb= sp;hostname by a subdomain of the dCDNn=A1= =AFs

        distinguished CD= N-domain that points to the selected deliver= y

        node.

   and the figure 1 in Page 6 should be modified as well.

2. Page 10, typos:

3. I think the CNAMEed domain name should be added to the end of the=20 original one, so the dCDN1.cdn.csp.com showed in the above figure should b= e=20 cdn.csp.com.dCDN1.net.

yiqiuchao from China Mobile

From: Francois Le F= aucheur=20 (flefauch)

Date: 2014-02-13 21:19

To: Kevin J=20 Ma

CC: cdni@ietf.org
Subject: Re: [CDNi] I-D Action:=20 draft-ietf-cdni-logging-09.txt

Hi Kevin and all,

We just posted the updated version of&n= bsp;cdni-logging that addresses Kevin's review co= mments as discussed on the list (including&n= bsp;latest comment about privacy).

Could you please review and let us = ;know if you have additional comments before= we move on to the next step (as&n= bsp;agreed in Vancouver) which is to submit&= nbsp;the document to Working Group Last Call= ?

Thanks

Francois & Iuniana

On 13 Feb 2014, at 14:10, <internet-= drafts@ietf.org> <internet-drafts@ietf.org> wrote:

>

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

> This draft is a work item of&= nbsp;the Content Delivery Networks Interconnection&nbs= p;Working Group of the IETF.

>

>        Title  =          : CDNI Log= ging Interface

>        Authors &nbs= p;       : Francois Le F= aucheur

>           = ;            &= nbsp;  Gilles Bertrand

>           = ;            &= nbsp;  Iuniana Oprescu

>           = ;            &= nbsp;  Roy Peterkofsky

> =20 Filename        : draft-ietf-= cdni-logging-09.txt

> =20 Pages           :&n= bsp;45

> =20 Date           &nbs= p;: 2014-02-13

>

> Abstract:

>   This memo specifies the Log= ging interface between a downstream CDN

>   (dCDN) and an upstream CDN&= nbsp;(uCDN) that are interconnected as per t= he

>   CDN Interconnection (CDNI) frame= work.  First, it describes a

>   reference model for CDNI lo= gging.  Then, it specifies the CDNI

>   Logging File format and the= actual protocol for exchange of CDNI

>   Logging Files.

>

>

> The IETF datatracker status page f= or this draft is:

> https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/
>

> There's also a htmlized version av= ailable at:

> http://tools.ietf.org/html/draft-ietf-cdni-logging-09

>

> A diff from the previous version&n= bsp;is available at:

> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-= 09

>

>

> Please note that it may take = a couple of minutes from the time of&nb= sp;submission

> until the htmlized version and dif= f are available at tools.ietf.org.

>

> Internet-Drafts are also available by&n= bsp;anonymous FTP at:

> ftp://ftp.ietf.org/internet-drafts/

>

> _______________________________________________

> 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

------=_002_NextPart106231072172_=------ ------=_001_NextPart325326163058_=---- Content-Type: image/jpeg; name="Catch.jpg" Content-Transfer-Encoding: base64 Content-ID: <_Foxmail.0@9896C0AB-292A-4311-8EF2-0DA257A59FDE> /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCADiAe4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD+/iii igAr82vgsWP/AAVU/b6BZiq/sl/8E78KSdoz42/bsJIHQE98da/SWvhT4V/DPx3on/BRD9sn4r6r 4a1Cy+HfxA/Zv/Yk8I+DfFc3kf2b4g8R/DrxX+19e+NtIstkzXH2rw5a+O/CE9+JoIo9mv2JheYm UR3B25unuSX3q343FP8AgV0t28JZdXy5jgpysutoRlJ22jFy2TZ910UUVAwooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAQ9D9D/Kvzi/4JIlm/wCCe/7P 7OzMzf8AC1SWYlic/Gz4kdSSSa/R09D9DXw5/wAE2/hr45+EH7FfwX+HXxJ8N3/hHxr4dX4hDW/D 2pmA32nnVfir451vT/ONrNcQH7VpWpWN7F5cz/ubmPdhtyiVfnl25YW9bzvb0ur9rq+6Jfxw/wAN X86Vtfk/Wztsz7koooqigooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAPzc8Clj/wVy/a ZG5to/4J7fsY4XJ2gt+0N+3BkgdMnHWv0jr4X8IfDTx1Yf8ABSf4+/F+88N6hb/DbxR+xZ+yt8O9 A8XP5H9l6p408FfGv9rjxF4q8PW+2Y3P2/RNF8c+EdRvBJbpD5GvWRilkfzUj+6KVHTAYGL0lF5v zRekl7TiPOq0Lrdc9KpTqRv8VOcJq8ZJu8Z72cZtUWsJw4Y5JrWM/Y8C8KYaryS2l7LEUa1CpZvk rUqlKVp05RRRRRTICiiigAooooAKKKKACiiigApodC7Rh1MiKjvGGBdUkLiNmXO5VcxyBGIAYo4B O1sOr82vgsWP/BVT9voFmKr+yX/wTvwpJ2jPjb9uwkgdAT3x1qormvra0ZPa+yvb57X6BL3adSp/ J7HTv7bFUMNvrbl9tz7O/Ly6c3Mv0lor8zvFnw40f9r/APbD+Nfww+NGoeI9Z+BP7N/w5+DUWhfB bTPFnijwr4P8c/Ef4ux+M/EviHx98T7HwrrGiyfEGy8P+HdA8L+HfAfhXxPLqHhPRNRk8XeIZNGv NeuNF1DRPOPi9+wr4S+B/wCz5/wUD1HQPil8aNY+E3jz9nWPVfh18HPEHxa+LWrWPwB8T/Bjwn8V fE51H4U+NtT+Il/4t0HQfE3iDXtC1geENPutO0nw/ceGItNsmufDNxpvh/QeLFYpYTLsbj6sP91w 2KxUKEJc0508JVlGUKs2lClVrYelUxeHVN4iDpyw9PEVMNXqVqeG7MFhHj8xwWX0Ki5sXi8Fg3Wn FqnGpjHRjzUo6zqQw1SvGjiPaxw8vaUcS8OsRSjhquK/Xiiv5rfHcV9qH7DN/wDsyftBeJvHviX4 t/s96F+zP8SPgV8Un+I/j7w34v8Aip+zr8W/iP8ADbwvpXibV/EPhjxJoeoeLPGXgGPUvEPwR+KE +sXOq3t3Pp3hnx/qq2l38TNOLfRH/BTvwL+zD4t+Lf7JnwL+IvxnX9nbXvFmk+N/EGsfFO5/aS8W fBjUvDfwR+Cfh57fTdK0G/m+IvhvRdR8T6/8YviB8MrYXOo22pa5rHhfTfGcc91PBYS+T346H1HF SoPmxEXmMsLRdBQ9vXwuHhVnj61OhVq0o/Xcu+r4tYzLVWc6LwGPp1MRDEYWVB+Zl2IhmOFp4lXw 6ll6xlSNVSap1a1OlXwNG9KNSXsMxw+Iw1TB4upCkqjxmCboRoYj6xT/AHKor8MvjB8VtO/bG/4I 9t401TxvLqHi611b4dfDX4heNPg/8RNY0JY/i18O/j94X+DfxQ1jwh40+H2vWF0+jazrFl4i1Tw7 dWeqS2eoeHdb0rUFWaOe3kr5P/aw+Nnxb+Mv7K3jH9jnVPHvjLSvi1+xl4P8e69+2j428K+Jdd8J eKfEFr8JZrLwr+zTcXev+Gr/AEvWtJ/4ak/t7w1+0OU0/UI47jQ/AnirwrfNLBdXUTzODWLxOCpu FarSqxqYaUPaKGMyqjTjXzLNaftKUKtOlgcNUoYlUqtKMsXTxeFjRn7WpUp0tITvhYYqpGVGEVOh jIydOU8Jms5So4LK5OnOdKdXGYunWwDryq0qOGxlNUqr5alOcv6faK/nW/bm039nT4EftW+OfGXx G+Cn7Svxm8K+Hf2B3+J48FfCLxd+0bqukQa/8NvFOr6Lbav4pufBXjP+zPA9vd+EfD+naBN4s1i0 +xssFxqeore3iXtxL+u37J37Ofh79nzSfiZN4L8Q+JbvwL8X/G+hfFLwj4H8Sa54t8TN8KrC6+Ff w88J6h4P03xD4z8W+LNX1ay1DXvCureNJphJpFrb6j4qvbKHS/8ARm1C+WG5MRhVi1JxpSWPjD3V Jqvgs/zHIlh6vvJwniP7Jx+OpygqtOFGjClWlTrVqcW6zlQxP1WcUqnLhJ3ctKkMRkOR57VnRtFu UcKuIMuwk/aqg6tWVWpRU4UppfWdFFfB3ij42ftLfFP4v/Ff4XfsseHPgppfh34BaloHhT4m/E74 7S+N9YsvEfxO8QeD9C+IJ+GHgXwV4DuNEvLe00PwT4t8Ial4o+JWueJbi007UvE1toei+BPE8+ma 1cWUc3vckU5zVOpXkoqUvZ0KUqcKuIq8sZShQpzrUaTnytzr18PhaMauLxOGoVdFG8ZSbUYxcY3k 7c1SbtTpQX2qk2nKy0p0oVcRWlTw1CvWp/c1nqFhqMbzafe2l/DHNJbyS2dzDdRpPEQJYXeB3VZo yQJI2IdCQGUVbr+dn4I+N/iD8M/2W/24tJ8B/DnQv2QviT49/wCCoHgr9nL+wvh9D4a1Hw98G9a+ N9z+yX8FvF/xH+Gc1l4f0TQNctkt/FmufEj4a6zq/hDRpdYu9R8Par4u8JadqFxrGhQ/fHiz/gl5 8Flg8Fax8FPHXxs+BnxP8K/En4T+Ode+KmifG342eK/Evxc0XwB8RvC/jbxZ4K+N8XiP4nSQfFzT /iXpWg3/AIb1TVPHb63qOhTax/bekkm0k0u+1pQdTD5bi3ZYTH4Th2tUrU5Qq/VsTnXD2Q8RYuio qSWIw+VYLiLL5zxNKpzYylKUsLh514ywyibUamMopS9vhsZnGHjSnF03OlleaY/KqNSbd3Sr46vl 2JjCg4yhQq05Rr14UnCvP9LqK/I/XP2XPg38bP8AgpD+0hbfEjTvHWsWVp+y7+yv4zsdP0v4zfGj wfpmm+KfEPj79pvwtrWu6Vpngv4geHrDStQ1LQfAXhCxuZtOt7Yt/YVndKFvDPcS/MX7VHgrWNR/ Zv8A20P2XfE/xQ+MWtWX7OPxo/Zh1H4DfFuL4tfELT/jX4M8E/HzxH8PrePw5rXxSsvEUHivxx4g +H8utePdG8P+KPG2o+INZ1DwjqHhM+KrjX/EelXPiHUcFOSownKnJ1ZwlUhSpuEo1PZZjDAVsPSq 1JUf9rlzTxOFhWhRwlalQrRxGNwVT2Ea+kowjipYd1EoQnhKdSrKMrweMyqhmlKs6cebmw1JYinh sTKE54mFSpCdDCYml7WVH+g2opriC3EZnmigEs0dvEZpEjEs8zbYoYy7Lvmlb5Y41y7twqk1+DHx AlHxgvf2TvB/x9uPEB/am/Zv/bc+FX7PPxk1Dw5448eeBbD4h+ENR8KeOfGPg34oQ+G/CXifRdG1 Dwf8dNB0bwx478m5sdQt9D8VWniz4fLezTeD9Vgr6k/be/Z/+D3/AAub9kL9oK58DadqnxkH7Zfw C8O6d471271bxBqnhjRG0/xZp93pnge31zUNQ0zwDa6tap5evx+CrDQP+EidpZ9dOozzSyvtRUa1 TL1GpGVHHcW5Zwyq9NTcXRzd8MTwOaUYVY0ak4VMNxTg61TCYiOFrUJUa9KblNJPnxM5YenmPNTa r4DhDMOKPYylG0quWS4opYrLalWDqQio1+FcbGljsO8VQxFOvhq1KHs5uUf1IoooqTUKK/P7W/jf +1N8ZPir8YPAX7J+ifArwx4O/Z+8V6f8OvHXxO+P9v4/8T/8Jz8Urjwf4b8d6v4J8AeBvh9q3hKb SvDvhXw/4w8MWut/EvXvFuovL4ov9U0LSfh7qEHhy51a+563/a0/ad0L4NeCo/id+zN4S8H/ALW/ xY/aH8cfs8fCz4QWnxU1PU/hZrsvha58b6za/F+/+KM/gKw8Q2nwrn+FHgDxD8V5JE+Hn/CVXenQ 2Hhey0Ia/qtuIlTftYUpwjJ/WMPhMXhU1y/WsLj6uEo4HE0JytTlRxbx2GrUJynFSwNRZm+XLf8A aypx9m5czjalWr4fEST5lha2FwuNxuKhiFG84fVaGX4qOIkoyhRxcFl85LMJLCv9F31CwivIdPkv bSPULmN5rexe5hS8uIYs+ZLDbM4mljjwd7xoypg7iMVbr8RvHun/AB8sf+Civ/BOi4/aK+E3wA1r xPf+J/j/AG/hb9pj4HaNq+i3cOi6f+zX8WLnVPgv4z0Xx5Nr3jbQ7dr/AFa38U+Fb3RvHfiLwv4s fTfEl1qvh3wPq2j6bH4i9y0X4+f8FAfil8bf2qfhT8MPhz+yt4W8Ofs1fE7TPCumfEf4h+JfiZr8 fxRtvFPwv8C/FPw14Qg8HeGIdG1LwRrum6L41srbxp8QNQ1TX9Esry7sI/C3gTxWkWqyWLk4xjTb ldyw2LxdRwjKUaVDB4uGGrSkkvbc8Pa0pKi6SrYmTf8AZ9PG06uEq4pJNyqJK0YPDRjzuMZVJYmn Jw5dXBwdSDg6iqOGHUl9eeDlRxkMN+o9FeIfs1/GiD9on4B/CX43weH5/CZ+JngjRfFN34Xub+LV ZfDup3tuF1bQxqsNvaRarFpeqRXllb6olpZrqNvDFeiztfP+zx+31dSEqVSdOfLzU5yhLknCpHmh JxfLUg5QnG60nCUoSVnFtNMiElOMZpSipRUkpxlCaUknaUJJShJXtKMkpRd00mgor85rP45/tifH 7XfiXrn7Kvhv9nPw38Ifhd8SPHfwm0zXPj7N8StW8TfG/wAb/CvX73wd8SP7Btfh9PpNn8IvBOie PdI1/wADaV4v1mH4o63r1/oGra6vw/0/RF0Z9es+LP2sP2h/AH7Ddh+0X8Rv2b9O+H3x0k1jSdB8 Y/CLUfF3iLxT4I+EsGtfFofD26+InjLxr4Q8Daj4o1j4ZeCPCk8PxS8Ua1oXgSO8n8K29zM9toFl 9q1bS8faR9hTrv3Y1vqLpQqONKc4ZlyfUaj9o4Qp063PF1ZVZw/s+MozzNYKnUpynryP6xLDL3ql OpiqNRwUpqnXwM3TxlCSgpTdahUUqajCEvrFSM6WEeIq06kIfohRX5ofsmftWfGP45/E7U/C1v8A ET9hj9pb4TWHw98Qa9qfx1/ZE+Ln9pHwN8S4NZ8K2fhf4WfED4S3njL4kazpieIdG1HxTrlh40sv GlzFcf8ACL3um6n4Z8NXZ0/+2OE+B37RX/BR79ob/hcMPhz4XfsmfDaP4DfGr4l/BbUvEHjXxD8W PE+kfG/xJ8PtY+yXE3gHT/D8Oj6p8NPB8dtPZ6ZdeNvFbeN9Zn8TJr1vZ/DEaNothq3iPSz5407S 5nl9fNJLkqKVPA4XMaWV4mtOk4e2Tp4zEYaNOlGnKti6GKwmLwFPFYXFUK1TO6VJ1bx5P7QoZXF8 8Gp47FYDFZnhqMJKTh+9weCxU5zlKNPCzw9ejjZ4atRrU6f61UV4J+zT8cD+0H8JtN8f3vhO58A+ KLPxH46+HvxC8B3Wq2+vnwZ8S/hb40134d/EHw5aeIrW1sLfxJpGn+LPDWqDQPEkWn6aPEGgvpms tpemSXr6fbe905xcJcrcXpGUZQnGpTnCcVKFSnUpuVOrSqQlGdOrTlKnUhKM4SlGSbUZc3NpKMoT qUqkJxlTqUqtGpKlWo1ac1GdKtRqwnSrUpxjUpVYTpzjGcWkUV+bOifHj9tT9oJPGfxI/Zd8H/s2 aJ8GPCfjr4g+AvBFn8d9R+Jsvjr49X/ws8W6z4D8W67a6x4ESLRfgb4Q1Pxn4b1/RvBmsaj4b+NO r6zotla+MdQ8MaPb6nbaCtjW/wBrn9oe0+Dn7KGjxfs6aF4Z/bY/avtbi1tfgX448e3lt8PPgre+ GPCtz4u+Knin4k+PdF8N6hrmq+D/AIbabFZ2NvZ+GvC7a5448W+IfCPhe2Phmy1vUPFPh3OMualC rGMr1Hg1CjJKFWSzDmeDk1UcY04zUZPFOrODyqNpZwsvU4OWjXLVnSco2p/W1Uqp81KMsDpioKUF KU5wfu4dU4z/ALRkpRyz67KE1H9HqK/N3RP2hP2uPhx8T7H9nv8AaK8LfADU/Hvxb+HXxK8V/s1/ Gf4USfEPw98KfFHjn4Z6TZax4j+FHxV+Hfiu78V+MvAms2uj6lD4s8O6/wCG/HXjjTfG/hjRPGnm 2fgnWfDun6d4j+W/g3+2/wD8FF/jHYfsoxwfBv8AZC8I6t+2h8E/Fnxt8ET3fjn4s+ItO+CXhj4d 2fw/vtWn8d2tro+i3PxX1Hx/bfEfw43h/QPC158OV8BXNxeWus+IfGsOmG/v3eLcuR86jThUlJXS jz/2n+7lGajOFVLJ8xnyVIx56VGnWpOpRxWDqYhJOzbTjabg09XZU8NV548vNGcHTxdF3puUo1Pa YacY4qjVoQ/caivA/wBlr4z3X7RH7O/we+NuoeH4PCuqfEjwNo3iPWPDdnqEmrWOi61PEYNZ07Tt UmtbCfUtMttUt7tNNvrmwsbm6sRbz3NlaTvJbx++VpUg6dSdOTi3TnKDcJKUW4ScW4yWkotrSS0a s0TF80Yy5ZR5knyyVpRur8slraS2avowoooqBhRRRQAUUUUAFFFFABRRRQAUUUUANDoXaIOpkVVd oww3qjl1R2TO4K7RyKrEYYo4BJVsOr83PApY/wDBXL9pkbm2j/gnt+xjhcnaC37Q37cGSB0ycda/ SOlTfPh8PiNvbvGrk35fqeaY/Lfi0v7T6j7bZcntPZ+9ye0nVZexxuMwd+b6pHKX7Tb2n9p8PZPn tuTXl9g81+q/FL2nsPb/ALv2vsaZRRRTJCiiigAooooAKKKKACiiigAr4U+Ffwz8d6J/wUQ/bJ+K +q+GtQsvh38QP2b/ANiTwj4N8VzeR/ZviDxH8OvFf7X17420iy2TNcfavDlr478IT34mgij2a/Ym F5iZRH911zNl408H6l4t8QeAtO8U+Hr/AMceE9H8N+IfFPg+z1nT7nxN4c0HxjceILTwlrWuaHDc PqWlaX4muvCfii30C/vraC21abw7rUdjLO+mXghqLavZXvFr0T3f3BLWnOD0jN0eZ9vZ4mhXh5e9 UpQhrupNLVo+XfjB+zx8Upfi4n7RX7MnxN8H/DH4t6n4N0r4d/Evw/8AE7wHq/xF+E3xj8FeGdR1 rWPBMPiPSPDfjb4feKfCvjfwHqXiXxOPCXj3w94huok0jxPrmieKvCHi+0Xw63hvltX/AGcf2oPH /wAE/wBo7wj8Tf2nvBepfFL9oDwDe/DrRZ9H+CGrQ/s/fBHw5qOi6voN6vhD4TN8YLL4g+MPEWpW XiHVbnxF4t8VfG+CXW9Xt9Am0/RfDPh7Rk8KXH2laeK/C2oa9qXhaw8S6Be+J9GghudY8OWms6dc 69pNtcCJre41LSIbl9QsYJ1mhaGW6t4o5RNEUZhImaPh/wAfeBfFl/qeleFvGnhLxLqmisU1nTfD /iPR9Zv9JYTPbldTs9OvLm4sGFxHJARdRxETRvERvVlHPOhSr4atg6kXVw2Lw+JpypylKV8Piakq mL9jNP2lKNSpOfPOjKLp+0rQpypxxGIjV2p4mth8VQxtKfssVhMRg60KyjBP6xhFSWBdeLi4VpUY 0qKpQrxmpwp0IzjUjh8OqX5x/Gf/AIJ2+Mf2gvgD8APh78Rvjx4X0f43fAHxL4Lk0r42/Cz4Kav4 Q0DxN8MtA8QeFLvxV8KNd+F/ij42fELU5NC+IGgeDvDy6xct8Ubi30/x/wCHfCXxE03R428NWvhu f1zwv+yf8SG/a5+Lv7RXxc+I3wM+K/gP4geC/Cnw+8FfDK4/Zq17S/Gnwx8JeBdT8Tax4c0yw+Ke u/tB+N/DertqGreM/Euq+OLu3+DXh658VX76F9lk8P6f4ftdOl+qbL4vfCfUvFuseANO+KHw7v8A x34eEDa/4KsvGvhq68W6GLm4t7S2OseG4NTk1nTBcXd3a2sBvbKAS3Fzbwx7pJo1b0SuudapWrPG VJKpUxFbG4tVXGDjKtmFCnhsXVpLl9nH2tOk7eyjGFOtXxuIpKniMfjquI4qWHo4fDrA0ounQoUc FhPYRnUXLRy/ESx2Do1Pe52qNapCaVRuU6dHBUqnPQwWCp0Px+8Y/wDBPD9p7W9I/as8IeE/2pv2 bPAnw/8A2lPij8PPippXg7Tf2JPiFPZfDXXfh/feBFM0Btf24dIs9fvfGGg/DTwfZ+Lrix0zwjp1 74htdV8Vadoulzazdaav0f8AtL/srfGD49fs6eL/AIU+G/in+z/8NPi38YPDeleFvjv8aD+y34o8 Tad4403S9OubW2PhvwPYftM+DfE3hyfTriVD4ePjH4s/FG30LS2v9Ljt7t74ahbfeVFYKKWHp4a8 vY0oYWlTTnN1IUsFRpYfDUVWcnW9jToUaNH2PtPZzpUqdOpGcIRS6L/vZVkoqc3XlO0YxpyniKnt atSVFJUnUlVbqRqOHtKdRynTlCUpN/nL4k/Zn/bXm/aKl/aD8D/tT/st6BezfBHwz8F5PDHiv9iX 4s+MbX7Ppetf8JbrniBNU0j9vnwLKs2reLbrVbjSdNaydNC8OT6fod5e+IdTsLjxLqftH7OfwQ+N fw48b/G74k/HX40+Afi54s+MN78P2tbT4YfBnxZ8E/Bfg7S/AHhq68PwWll4c8YfHz9oHUr/AFDW ZLuTUNT1KPxLpVu0iRRJpW5GuH+sqKuD5KUaMVFUqf1lU4OEZKn9czDEZpifZOSbputj8Via8nBx a9tUpxaoydMzlTjOq68ub2snhXOanOLqfUstw2UYX2vLJKr7LL8HhcOvaKXN7CnVnzVl7QK+GvF3 7Pf7Qvgr4ufEv4rfsp/Fz4UeD7T45Xfh7XPix8Ofjj8KfFXxH8MD4heHPC+keBLP4p+BdV8DfFL4 X67omrah4J8N+FdA8X+D9Xk1zQfEw8K6FqOj6j4I1Q+IL7xF9y0VHKudTTlGShOk3Gc4c9Gq4OpQ qcko89KcqdKpySuoV6OHxNPkxOGw9alqpNRlHRqXK9Yxk4yhJShODknyzi7x5o256U6tCpz0K1al U/Lj4Qf8E6/GHh34d/tWfCr49/tHN8dPDH7TnxZT4+ReKtH+F0/wp+Lnwz+Mk9l4HuT4q8OeMrb4 m+NPC0un+B/GPw88J+KfgppFj8OvD938O49D0vSPEGtfEX7K+o3HqGkfBz9vbW77wt4X+KH7W3wl j+G/hnWtC1PXvFPwZ/Z7134f/HT4raZ4fvbe/h8O69r/AIn+MfxC+Hvw9tfETWkNj8Q9S8FeBLnU PEmnXGqw+Cf+FUte2z6d970VpCTp/VlG3s8HhstweHouMXQp4fKMNRwWXU/YtOnNUMHh8PhZucZP FYfD4ehjHiKVCjCGc4qar8zlzYnEY7FV6qlJVp4jMqrr46r7W/tIyr15Tr3jJexr1a1fD+xr1alS X59eMP2bP2uov2pPij+0V8G/2lv2cfBek/Eb4YfCj4VQeBPiZ+x98TPipqWhaJ8KtY+JHiSz1CXx n4X/AG2vg3a6tq2r698U/Er3Lr4M0uztdItdC06OzlvLPUNX1blviB+wX8QvEX7OnxL+GXhb9oTQ 4vjn8cvi14F+MHxq/aB+KXwYvPiFY+K9d8Daz4M1PSdD8OfCvwZ8Xvg7B4L8KaJpfw98HeC/Bmi2 /jjV08P+EtLujrE3izxhrOreMbv9KpporeGW4nljhggjeaaaV1jiiiiUvJLJI5CpHGil3diFVQWJ ABrzr4U/GP4T/HXwknj34MfEbwX8U/BT6rq2hp4q8BeItL8UaA2s6DdvYa1pX9qaRc3Vp/aGlXsb 2l/aGXzrWdTFMiMMVnTilGVGm5N0qUXNqUpV6eHePpYtKda7rxw9XMKVCpVjKfscRWp0oVVUUYQV 1JOVRV6luarVpwTcYxp1K9HLngqSVNJUp16WXUpxp+66lOnTnWhaalUPj34rfsM6x8YfjP8Asjft E+Ifi5pPhz4vfADxDo2ofGG48B/DO80XwJ+0V4d0DTvEk+geGZ/Cet/ErxRrPgE+D/GfiTUfEvgH W73xn8RdQ8Ladr/jrw041aHxnc6lYaX7U/7OX7WHx18X/D+++G/7R37PPww8B/DD4o+Afi94V8N+ N/2SPiT8WfF0vivwPbahH9l8QeNtB/bP+D2jaj4e1S61O6m+wad8P9E1Kyt1gtv7Zu5I5Lub75oq orkVBQ/dxwucPP8ADwp/u6dHNnXwWK+t06cOWnC2Ky/CYlUFH6tHE0pV40VWrV51JmlUdd1P3ssV ky4exE6v7ypWydQx9JYSpUnzVJfuczxuHeIcvrTw1ZYZ1nQo0KdPkPAdl4907wjoll8T/EvhDxf4 9gtpE8R+JfAXgjWfhx4R1W8NxM0U+ieCfEPxB+Kms+H7ZLRreF7S/wDiB4llkuIprpb2KKdLS2+V /wBjX4HftY/BU/Hs/tTfteP+1ePiB8afEfjb4PB/hV4a+GP/AAp34Yakf+JR8NQfD1zcf8JGNO+U fb7vyxD5GbdT9qnx9r1803P7Z37IVl8VR8C7z9qT9nq0+NDeILbwkvwpufjH8PoPiC3i69MQs/CK +EpfECa23iy6+0QNb+GRZHXJkngkjsGjmjZnFueLco2licVh62FjRhFWnTq4vA4mcqGFglTjWjXw uGp061GkqtGjVrYWnOFHF1qdVSilh1zOUaGGr0sTKq5yXLOnhsZh4KtXb5pUZUsTXnOjWnKlVq06 OInCVbC0KlPxnxH+zp+018Nviv8AFj4jfskfGH4NeHfDnx68R6Z47+JXwu/aA+E/jT4gaNovxQsv CmgeBr74h/DfxN8Pvit8NdX0i28SeGfCfhhPFvw/1+w17TdW13Sf+Eg0HxJ4PutT16HV9LxL+yp8 Y/HHws8Fx+N/2nH179pz4Z/Ft/jl8NfjjbfB/wAN6H4B8EeMpNG1rwnP4J0r4KaZ4hTUNR+CmoeA /E/inwNq3hfxR8WvEPxKvtH8S6pqY+MMHii30PXdH+6qKmC9nTpUoOSjQp4SjhnzScsNQwFTD1MD Qw0m26FHBvC0KWGhT5VSwlOGAjbAQhho3J885zaV6v1h10opRxEsXQrYfFyxEElGu8XSxFZ4pVFK OIr1J4urGeMnOvL8utd/ZG/bS+J3x9/Zu/aJ+Jv7VvwS0fV/2bfFvijUND+EvgH9mzxxP8K/FHh3 x/4J1vwH48vdfudd/aQtvGR+Jl5ourIvgPxTHq7+Efh5CNTtNQ+HnxAn1efVIvcPgx+z18ffhd8S v2vfiBrHxx+EHimD9pDxrbfEHwPoumfs7eNPC8vwv8R6L8NPBvwp8Nx+K9Vuv2mvFKfFLRLXw14A 8M3WuWGkaZ8Kb/WdcbXbyw1fw/Yajp+laL9q0UNJpxtZPD4vCuzabo46eHqYmPNfm5pVcLRq0Zpq eEnGUsJKh7SfMldS5rtvnw01fVJ4SVWVCKi/d5P31RVoNcuLT/2xV7Jny/8AsdfArxz+zV+zh8Ov gX48+JHhX4p658O9Lu9CtPHPg/4Z6t8KdL1HSfttzdaX5/gzW/if8XbqDU7SO5MV9eJ4xltNRkQT QaZpiEwVxP7DvwP/AGsfgR4D+Ivh/wDa6/a7f9sTxj4k+L3i7xh4I8Zv8KvDXwnPgf4caumnroPw 7Gk+Grq6ttUGlXNtqOpDUJ3U2v8Aa39j2YbT9NtJH+1q8w1f41/CHw/8UfCnwR1z4meB9I+MPjvR 9T8QeC/hjqPiXSbTxz4p0PRob641bVtB8MzXSatqlhp1vpmoz3l1aWssUENheSyMqW0zJalKWInU 0lWxOGnhHHli4unCdHHVJ0qKXs6eIisAp1MVRhHEfVlioTquhWxEZjX7nld/Z0sTDGSm2+aNRxxG EgqlZvn+rylmEoLDSn9XlXeFkqftcPhnT+PIf2bv2tfgv4m+I9r+yd8cfgNonwj+KXxE8YfFY+A/ 2gfgf49+I2qfCbx78SdZufFPxJvvAfiL4efHD4U/8JP4K8VeNNS1rxwngHxTY2OqaJ4l8Qa+mnfE YeG7vSPDvh70Txn8B/2otT+Dfws8MeDv2xrrTfjh4A+JFl8RfFPxe8YfBrQtZ8K/FS0jTxZJqXwu 8S/Cf4f+LvhTb6b8L7ubxHp+n6ZYWPjG58VaVoXhbQ/7Q8V+I/FaXPi64+kfFvxV+F/gHVfD2g+O viR4C8F654uufsfhTRvFvjDw94c1XxPeeYkX2Xw9p2sajZ3mtXPmyRx+RpsNzL5kiJt3MoOnr3jr wR4W0uPW/E/jHwr4c0WW+k0yLV9e8Q6RpGly6lE9zHLp8d/qF5b2j30UlndxyWiymdHtblWjDQSh c4pRoUIpv2eHq4KOHqSk5OEsrnReEoKrJycoUJQowq0JuUcTT5MPjYV6ChSVylKVavOSTqYmnjpY iHKkqqzWniKeOxE4JL97iY1sRUWJjy1KOIc8Zhp0cXz138Y/Dj9nP42XH7ReiftT/tLeP/gVP4n+ Hnwr8c/C/wAKaN8CfhX4l8AwXeg+ONY8Ja94h1f4n+P/AB18RPGviDxbp+mN4J02Twj4OtLHw34f 8J3l5rus3954n1C702fRPzm/Yb1TVfi/48/bGP7HP/BRf4WaNqPj/wDat/aH+IPi/wCEmq+D/BX7 SX9g+Gbzx2mg6F8X/g5Z6b8TvAOt+AofFWkxaMkl74nHxO+FWq6pDY65Y+CYNT1bXZ/EH73eHPGH hHxhp0mseEvFPhzxTpEMskE2qeHNb0zW9OinhRZJYZL7TLq6tklijdHkjaUOiMrMAGBNSz+IHgPU fDt74v0/xt4RvvCemtcJqPiiz8SaNdeHdPa0KC6W91qC9fTbVrYyRi4E9zGYS6eYF3Ll00qWIdWd 1SpZLj8sjRpuVB06WaZvgM6rYmtUTftqc8wwVOr7KtTcOatKVKdOVLCPDzUbq4aOHh8cs7y/NHVm lWU55dlOa5NSwtOnJXpy+qZlNe0pVFO+HiqsKsa2KVbzH4V/Aax+CHwLb4OfDPxd4httXSw8bX4+ KPi2PTfFXi/V/ib8QNU1zxX4p+K/iu3NppWh654k17x94h1Txnq+m22naT4elvLqTS9N0zStES1s Lbz/APYc+Dn7TPwI/Z78PfDr9rj9qB/2vvjTp2ueKL/V/jS/w70T4YtqejarrNxe+H9D/wCEa0G4 ubRv7A06SOz/ALRlk+03X+rZRDbwE+76n8YPhJovgfUPidrHxS+HWk/DbSVmfVfiFqfjfwzYeB9M S3fy7htQ8WXWpxaDZrBJ+7ma5v4xE/yuVbitL4e/EXwD8W/BXh34kfC3xp4X+Inw+8XWA1Xwp438 Fa5p3iXwp4l0ppZYI9U0DX9IuLvS9X02aWGVYL+wuri1nCF4ZZEIY2nL2uNrJXlXpYXDYiPKnRoQ hUq4nCqhh7ewwFSp+8SqYWnh6tfC01hnOeFoxpRzkouGFpSk0qVfFYqjL2klWxFWUI0MVPEVlJVs fGDqxnUhi54inSxdVYrljiqntZfCuj/s0/th/A668Y+Df2V/j5+z/o3wR8X+PPHHxC8O+G/j38BP iB8SPGHwX1n4meKNU8ceN9I8Ka54C+PXwp03x74Gn8Z6/r2veE/C3ibTvD+seEU1SbQ38ba/oFto +naP2nxP/ZM+J/jPwP8AAXWdC/aR1OL9q39nDXdV8VeCf2hvHXw18L69oPjDUfFuj6n4e+Ifg/4n /B/wHefC7StW+FXjXQtV/sxvDHhHxN4N8SeH5tA8F+INO8az+I/DT6nqv3TRWaio0adFOVqUsLKn NtyrR+pW+rxdWV6k4q1sRGcpRx0fdx6xUUktXLmqzqtR5qn1r2kVFKnJ4y/1mfs1aCnNtunKKi8L JynhPYTlOUvzs8Nfsv8A7T3jH4kQ/Hr9oz45fBjXPiv8Pfhz8QvA37OXhD4X/BXxrovwP+FOvfEq ysLDxT8UfHOieJvjTqvj74w+M9RsdI07QrOCy8b/AAr0fw74MuvEnh3SLb+2PEeo+MXyvgT+w78V /g9bfsIjVPj78PPFl/8AsdfB/wCJXwK8TXFh8APEnhe0+LPgHxtYfDiw0a40KyuP2hvE83wx8YeH 0+F3h2TU9a1C/wDidoviJ7vWhaeF/DQurH+zf0ori/iJ8R/APwj8Ga98Rfij4y8NfD7wF4XtUvfE fjHxfrFjoHhzQ7SW4hs4rjVNX1Ka3srOKS6ube2jeeZA880US5d1BbnCjGU26dKmoUvaSlyxhy0J ZlOMqkp6N3zfMY1JzbdSliFRqOVGhh6dJRhOo/ZxVScqk6ijGHM5uVehh8K401D3k/Z4ah7KMLOG Ii8VT5cXUq1p+QfsjfA7xT+zZ8AfAvwQ8V+PvD/xKn+HsGpaNovivw94B1H4cRXPhhtUu7zQrPVP D+pfEH4kvPr2n2dytpq+t2mu2On6zcxm9s/DmgxSCwj+k6xfDXiTw/4y8O6D4u8J61pniTwt4p0b TPEXhvxFol7b6lo2vaDrVlBqWkazpOo2kktrf6bqen3Nve2N7bSyW91azRTwu8bqx2q0qRqQnKnV jKFWm/ZVITi4VIzpL2co1FJKXtU42qOf7yVTmlUbm5NzGcai9rCUZxrOVZTg04SVaTqXp8vuKm+b 93CnalCHLClGNOMYooooqBhRRRQAUUUUAFFFFABRRRQAUUUUAfC/hD4aeOrD/gpP8ffi/eeG9Qt/ ht4o/Ys/ZW+HegeLn8j+y9U8aeCvjX+1x4i8VeHrfbMbn7fomi+OfCOo3gkt0h8jXrIxSyP5qR/d FczB408IXXjDVPh7beKfD1x490Pw5ofjDWfBcOsafL4q0rwn4m1LXtG8O+JtR0BLg6pZ6DrureFf E2maRq1xax2Oo3/h/WbS0nln027SLpqIe7QoUo6wpPGckusvrGZY3G1btaP2eIxVairfCqajK84y bqs3UxuLxM1y1sRHK1Vp7KmsDkOU5Vhmov3l7fA5fhcW+ZvmliHUp2ozppFFFFBIUUUUAFFFFABR RRQAUUUUAFfmz8Fh/wAbVf2+z/1aX/wTuH/l7ft2V+k1fHPw4+CPjjwv+3L+1V8f9Uj0ofD/AOL3 wG/ZG+Hng+W31ATaw/iL4M+JP2oNU8apqWmeSpsbOK1+K/hFtMuvPlF+8uoIEiNk3mXB25tbe5Jf erW/EU9aFaK+KTwtl35MwwdSVv8ADThOT7KLfQ/Pj9qL4Sa1oP8AwUg1n9p/4AeELSX48/BH9j3w N8RtS8PeG7Cy03Vf2g/AFx8YPH+gfFj4Q+IZ7eO2PiDXfFfgPSrG4+HN1rM0g0r4m+CfhrNLdRaN YXttN6j+x9pPwN8c/Fv/AIKE/Ev4AJ4E8BeHPi74b/Z813wv8VPA3hbw94bubLR/Hf7OOmeIYfFD zW1lpkkdxa6nqR8Saja6nJC6a7FcS6osd+tw6/aF1+y3cTftXD9q6z/aF+Oek6hL4A0X4Y6l8GLC x+AEvwc1fwdod/rGt2unXsuq/AfUvjJBNL4k1y+8R3N/pXxh02+e/MVlFPD4fj/sVvM/D/8AwTk+ APhXwZ+218PfD2pfEfSvBn7d914uuvif4ftfEekLZeAf+E78E3ng3xTa/BkN4aaXwfp+pTarrnjB NP1iTxVZ6d4u13UrjS4bLQzaaDacKoc2SPLqlPnksDxFCnTVaeHnCeacQ5lingY4ukp1aWEx2WY3 BVKbw86dLLMXgsxkqFevmnto9M6ilnzx6qOFCpieGvaVPYwrQVHLeGcmwNTFSwlRxp1sZgM2y3HL lq05yzHC5hhOfFQp5fDDn5/3/wCz98JPhL8Gf2ffhV+2J+wbo/hHw18B/iX+z/4j0r9sz9nK/wDh R428IaL8U/BHxE8Iaj4d+Lni/UtfPhP9pjwpH8UPHFnYD4uakPhn4/tILHxd4oXxz8RLvRP7Q8cv +/Ffnhb/ALBniTVNM8K/Dr4m/tjftG/F79n/AMG6n4S1Gy+DnjPT/glaTeLbfwLqmm614R8NfFL4 p+FfhN4f+Jvj3wpo+p6PpNzdWMniDSNb8ZJpsNn8SfEXjewvtetda/Q+vTrVfaqtNzU5YjMcXjZP 2MMNOo69DA0vrGJwuHbwOHxVX6t7OdLAXw1PD0MLRg3GlG3n0ISh7OMocip4PDULKtPFQpyp1MTU lRoYrEJY7EUKcqznGrjf31WrWrVpJVKtW+Tr9pquoaHrNjoOsL4e1u90u/tdH159Og1hNF1S4tZY rDVW0m5lgt9TXT7p4rttPnnhhvBEbeSWNJC4/JL9mDXv+Ckf7Q3h7xnqWu/H/wCCnw00L4P/AB6+ PXwl8O+LLX4GxePPEv7Qb/CL43eM/AsXiH4h+FF8a+EdD+Ffg1NI8PQ+HX8JeBdZu/G3iDWLa88X D4g+E9Pe08NXn6x+K9G1HxF4a1zQtI8W+IPAeqatpl3YWHjTwpbeFbzxL4XurmJo4db0O18c+GfG fg641PT3YXFpF4l8J+IdGeVFW/0i9gLwt8b/ALO37Fnij9nPV/O0n9tf9q74i+D7vx38SviRr/wy +I+g/sZf8Ih4m8WfFfxP4j8beL73VdU+Hf7IXw8+I9nBN4w8Ual4hsLHw54+0G1sbhLXT0ibQon0 mXmoe7jJTlpTWEapur+8ofXFiqE6M3RXO5Onho42lVhUpSw9b63QdWnXnh6NXBdVdqWChTh/HWYU 6s/ZpQqywCwGPp4iiqr5VetjKuW1aVpqdNYWu4VaHtJRxXyX+0T+2r471H9qT4q/s7eE/iH8efgP 4K+AmjfD6PxZ48+BH/BPz9on9srx18QPiH8Q/C8XjmDR7LxH4H+B/wAZfg58NPBfhXwrqfh1tQ0/ xBouu/EHxjrGtXY09/BWjeHYNQ8XdN8Pv28vi/ov7KP7SnxJ+IHw78YeLvHfwG8aaF8PPhX4x8ef s7fHv9jjw9+0hdfEj/hCtH+FPiO4+Hfx+8HaH4x8ExWvjnxzaeBfivf6DbeIvDFpe+HtY8V+Fntt O1ay8L6P9cfFr9lG88XfE26+OHwa+OfxK/Zq+L+t+GdH8GeOfEHgDSvh14v8K/FHwz4budRuvCtn 8RPh98UvBvjLQL/VvB8ms6yvhjxh4YPhLxnaWep3Giaj4g1bw0kGhxaGk/so6Vq3we+Knwd+Pfxb +Lv7T+m/GmzvdO8fa38WNU8J6FeR6Ze6VDpUek+BND+Dng/4XeEfhvYaQIE1HRL3wjoFh4pg1xIf EWp+JtX8RwRauudJSWDxcKilKtLD14KPP7N1K8sfTq062FxH+0VaEng1VowvVw1HDuvOLw+IeGwl V3Nw+t4OcLLDwrYSVT3faONGngfZYmFalfD06injE6tn9bqVYqnJ1qLrV4UfCNY+FP8AwUt8Hz/D zxb4W/az+GPxg1PUPiZ8Lo/jZ8LPGX7PvhbwP8PLD4WX/jnQF+LNz8Bte8NeJoPiB4V8Q6B4MfXb jwzD8VvFnxnGsxwfYZPsms3NnqdszxD4t/ab/ad/aF+Pfwm+B/xysf2XvhV+y7rPgnwB4t8ZaL8M fB3xP+LfxP8AjB4y+G3hX4vXFlpq/EuLWvAXgv4VeEPBHj7wRbXLnwXr/jDxz4m1XXINP1/wLpvh SKXxV1+g/sZ/Foaj4YsPiL+39+1p8S/hp4N1jQ9X0vwCw+B/wz1fxT/wjd7b6houm/FL4tfB/wCE HgP4reMNJtrmztBqdhofirwTF40tIptN+I//AAmmm6lrFpqO/wDFr9jrV/E3xY1346/Ab9o74s/s r/FLxxoGgeGPipd/D3QvhR468EfFfTfCaXVt4R1fxl8PvjD4A8d6Lb+O/COnX13o+g+PPCEvhbXr vQ2sfD/jKTxh4d0Hw1pGjbScbUk1KpS+s46tTjBKlicO62GwNHDfWpqpGNfCUnh8W1gvb4ydHE41 46OKrKnDBxxp8/73mcY1fq2FhKcrVKFapTxNSpiPYL2V6NWdKcUsQsLhY1YU44b6vh+eWKhj/sz/ ABX+OnxS0D9p34DfE7xR4N0v9on9mv4hf8KhvPjR4D8GSw+CfGVv4u+Fvgr4rfDL4s2Xwy17xDrY 8P603hn4gaVZeNfh7d+LdW0238XaBrE2k6qPDWr6PFB87/sieI/+CjX7R/gW0+IPjL47fBT4Z+H/ AAH8Xfi78PNKi0j4KDx3rfx/0r4S/Hnxz8OtU8XfEq2k8Z+EtP8AhVp+uaB4UfSPD/gn4cXt3rWn avCvjnWvHt9Z6gfhvYfaHwq/ZS0f4MfCXx18PvAfxa+Ltl8Qfih4l1bx/wDEj9pXVbj4a+KPjr40 +J2uQaTYaj8RNYfxV8NNb+Ef9rR6HoOieFdB8N2vwlt/h34Q8H6LovhXwj4L0PQ9F0qzs+K/Zn/Y y8R/syS6fp+k/tl/tS/FDwDZa78RPE83wu+KOh/sfDwlqev/ABO8VeJfHXiXU77Wfhj+yZ8MviUj r4w8V6vr+m2um+P9P0+1meDT5LO40SBdLOkWlWpSnKnKrSwGXKvW9nbBV80w2EprGYmjQjTheFfF LGqNKpgcHl+JhjaNatlWElhcFRymZpPDzjCNSEZ43FOnS574unl9WpV9lRqV3KSg1CWDkuTGYnGY WWFq0aeZYmNbE18z4eHxB+1B+038UPjvb/CX46aN+zh8LfgH8SJvg54djsPhR4Y+J3jL4n/EPQPC vhjxN4w8R+PrjxveNp+ifDWx1DxVa+FdE8G+DtP8O+NNYGi6t4ok+JWn2Wt6Lpmm+GfsZ+Kf2m9G /Y3/AG3PE+ieCvh/4v8A2sPDv7T37bUmgeDtAu7xfhv4y+Kvh3xfqlpoa6THrWu6RqFn4f8AFWp2 NnqVr4c1jxdYXumxainhvUvGUM9tP4jH1x45/ZD1y8+JPjj4nfA39pb4yfs0ap8Wp9Jvfi9oPw+0 X4OeMvCXjXxBo2iWPhey+IFjoXxi+GXxEg8HfExfCuk6L4bufEnhyS20XXNM0PRW8WeFPEd/pOn3 1t5T4F/4JkfDz4e/AP42fs4aB+0R+1U3w/8AjV8Rh8Wn1K+8cfDef4h/Dj4h3vj+x+KHinxR4C+J EXwjt/GV/qXjfxzp8WueJpfijq3xKO+W6tNA/sKwuZbZuTDxlCjX5+eFWtwjLKMROMubE186qZjw vi8fjcJUdT/ZsJi62VZnjcJQ+tUYUI1cFhJU8MsPT9l0V2pzwUU6c4UOLsLnEVKDjh6WT0co4oy+ hhcRSUUsVisLHOMuoYmsqTeJ9hjsVByniXSn4d8Bv2gfjff/ALQXwJ8D63+1l4r1yHxzqHio/FP4 N/tcfsKfEP8AZH8X62uk/DnxXq0em/so+NtQ+Hvgbwb431Tw34tt9F1HxV4NPij4037eALHWvENh 8QPI0W4fXf2Zr4c8OfsfeNrz4h/Dfxz8dv2svjJ+0Lp3wZ8TT+Nfhl4I8TeD/gV4A8O2vjd/Deu+ EbDxv41m+E3wr8Faz4z8S6JoPibX7fSLVNR0DwRBe6rNq9x4JutVstDvNI+467JzjOlSuqcailV5 o0o2gqcpKUOZyhGoqnPKtFUpVcaoUI4eSxspVJ4TB8sYyjVlZ1JUlQoR5qso88q8ZV1VaUH7OcHS +rS9uqWDlUryr0ngoQoU8VjOP8f6P4u1/wAHa/o/gPxlH8PfF9/ZeToXjObw1Y+MI/D9550Tm9fw 1qV3Y2GrjyUlhFtc3cMYMol3ExhW/K3/AIJQ/C79oTQfgF8M/Fvij9pPTfF3w91HxF8ddT1b4a2/ wL8IeF7vVPEOr/GL4ktqOv3nj3TteuNZm1C+8SSXPiW/lmsJpb2e5ks7iZ1zcN+qHxB8L634z8H6 14Z8OfEXxl8JtZ1SGGKy+IPw/sfh9qXi/wAOPFdQXElxo1l8VPAnxM8AzzXMMMlhOviHwRr1utrd TvbQW98tteW/yx+y7+xvr/7LVnoXhzSv2wf2nviz8OvD0Picaf8ADH4saL+yOvhf7b4r1vUvEd/q s+tfCn9lT4VfEiS9tta1fUb6xhHjxNMQ3P2a5066s4YLeLGj7terP4L0JU+ar+8pSXLOXLCl+9UJ ydoqo6UGqvsajqL2UalLSrd06S0nGNVz9nTtCtGTdKKqSq/u+aEY83uKtK0PbxjTvWlGr4xp/iH9 rX9rv4jfHq6+Dv7RWl/srfB34D/FvxJ8CvB1voXwd8FfFfx/8VPiD4A0/Rn8feMfiRffEmS90fQP hxa+KdUufCXhnwD4J0Tw74y1Wx8PX3jK7+KVrbeKNH0PQOs+Ffxp+Pvxz/Zd+NcF74p8G/CT9pv4 BfEb4nfBnx9448G+DD4w+G+reL/hDeWupnxh4M8GeLtenurLw58TPBN7oGtr4Y1rxLreqfD7UPEW o+F7nxB4lvvDJ1nUui8efsUeJJfib8Qfij+zr+1b8bv2UtS+M2oabrXxm8MfDzw58D/iD4G8a+Ld N0LTvC0XxM0rw38cPhX8SYvAnxRm8L6Loeg6jr/ha4tPDHiS10PSbzxl4I8T6zYQamnbaJ+x94e8 Dfs7H9nb4SfF34y/CO1v9U8Q+IPFfxc8O3Xwv8bfGTx74m8c6tq3iD4k+KfG2u/G34W/FbwlrXiP 4j+INc1PWfE+rL4Jtbm2uLiO08Knw1pNnZadbcFeni5ZNiKFCfJjp8OYfBwcpWrvi2Ky1Vs+him6 vssndelnld5bGUFOjmmXwjgKccrhgYdUZUlmFGrLldCOe1cW2ofuY8M+zzP2OS1aFoRrZrH2uR0n mDoP2lXLMfWeLorMasq3z7+xRrf7fPx9+F37OP7S/wAaPi58Gvh7oXxA+HHw58Y61+z74J+FM3jG 013wt4o8C2OqXeu678V7/wAW+HNX0b4jeIdTv7bxLp1j4V0AeBPh9p8svgq+0v4oXUI8bN+n1fJP 7Lv7LPiD9mDw54a8DR/tU/tE/G74e+CPh94c+G3gjwL8ZNH/AGXbbSPCmieFLHTNJ0K8sdY+Cn7N Xwa8aanq9no2lQ6U0/ibxVr1lc281xc3WnzamYb+D62r3syqYWrjMTPAQVPA1MXi62Eoygo1qNCr XmqNKvL3lzqlCnP2dOrVw9F1HGg4Jypx83CwrRpU1iW5YiNGhSqzUr0pyp005SpRTWinOcHVqQji a3IpYiVWSjUl8l/tX/Fv4keArb4L/DX4MyeFtM+LX7R/xci+Efg7xh450m+8Q+D/AIe2un+AfHXx U8a+ONW8M6bq/h688V3+j+Bfhz4ig8K+Fo9f0WDWfF19oUWqala6JFqkg+HfH3hL9pz4d/t0f8E5 /D3xR+M2iftA/DLWviP+0DqumeMNb8C+Gfht8VPCHjfTf2WvitC/h+7svAUOn+CPGPgjxFpeo3t7 pV5B4Z8N+I/Bt9oD2Os6n43h8TWl14d/Sj49/Afwv+0D4P03wzr2ueLfBmueFvFWjePvh18Sfh7q Vho/xB+GXxA8Oi6j0fxj4P1DV9K1/QzfxWWoarouqaR4k8P+IfCnijw1rWueFvFfh/W/Dus6npl1 8kXH/BPHWfFfxk+Cn7Q3xT/bR/ag8dfGL9n7xBrGofDXWbLTv2c/CXg7TvDXinQL/wAMeOvBN98N tP8AgNe+EdQsviJo17FB4u8XS2a/Eu1fTdPj8BeNvAunJPp1xw4ZqFWXtE482KqOVSpavT+qVcDh 6GHVKknF054XMFXxddRhTrQov6xDG5o3TyKl04n36SVPVfUXBU4fuqrx8cVi6tWpUqXXNSr4KeCw 1JOrOk6tKrSngsFGdXM8Vx/7E/7PnwK+PfwR8bfG744fCj4bfGf4o/tF/Ez45H4weIPij4K8M+Pd SuNK8M/F/wAeeAPDnwgZvE+mam2neAvhb4X8N6d4J0TwRCtvo+nz6dqmqXGnnxDrevX99w37UP7H XwG+AH7BPwr/AGc/C/hC18U/CzwV+2X+y5rHhbRfiTaaR43l0dfif+358PvFWv6Vbz6npQjfTLWL x/4h8KaaJ4JdQbwfMmj6vqGryTaheX31R4i/Yy8Q6b4z8b+Kf2ev2pvjZ+zDpPxT8QXni34j/D/w B4e+B/jfwLfeNNXA/wCEk+IPgnSPjL8KPiHN8OPHPiqVV1DxNL4eu28D+INfa78W614C1Dxfq2t6 9qdj4kfsNeGPHn7PHgn9nLRfjn+0N8NdF8GfEXwV8VZfiN4b8R/Dnx58WvGXjbwN8Q7X4t2GreNf E/7QHwu+NGlaq2p/E+w0/wAZ6ylj4d0oTXVjBoNgdO8HtceG55ovkhlsnBwp4THcL1a+CjyvmpZN jsLWqxpLmVCrhsHSpYmOXzqzpYirSrRcsJhKtavRp1K/tq/v+0dV5rVhipcy1xtKslKorOpTxWJ5 6MMTRpQnhacoThHFVKFDDzq+O/HX4G/B79nL4x/snfFv4BfDbwD8IPGvjn9oHw38AviDpfw08JeH vBOmfGX4UfEPwn42l1vwr490Pw5YabY+Lh4Gu9FtPiV4V1LUrW81XwjN4Z1lNLvLLQ/EPiu01T4j /Zn8EeCv2YfiP8e/FE3g/wAKH9j/APac/bh+PnwC+O3w5ufDukS/Db4efFWP4mSeH/gJ8T/+ETls 28O6d4X8evNZ/An4gRiw+xyazJ8ENReG1stI1++f9Xvh9+yJbeHviT4e+LnxY+Pvx5/af8e+BbLW LP4Y6l8b5PgtpWi/C+XxHYy6V4i1vwh4H+APwX+BngKTxdrOj3FzoUvjfxR4Y8S+MtO8PX2reHdC 13SdC17XtO1Pl/hx+wl4V8HeB/2iPhf49+Nnxt/aC+Gn7S2tfEHxD428D/GC0+AlnpWh6x8Ub/Ut R8a33g7Ufg18CvhD4mspdSn1FDZ/29r3iMaC+m6bd6ANL1CKe8uYoxnh54icuXFOpl2dUoU3KSpP D5hjeEakchtUg6fs50slz3MKOMq4arQy/Pc8WKhQrzwcMVUWJ5cTSw9ODnhVTzHIqlWUIxdV1Muw PG9KpncHCcHKvSrZ/wAP4WeFdejVx2VZE8LUrxo1/qcPOP8Agm/8IPhLf/sB/s2aDffC74dXmh6X FqXjPTNGu/BPhq40rTvGFp4v8UR2viux06bTHs7TxLbRyPHb67bwx6pCjusd0qsQfSP+CbP/ACZV 8Ff9z4g/+rV8c11fgP8AZLb4SfswfDD9l/4P/tE/H34aaf8ACvSdL0TSfi/po+BXjL4xa/p2nyX0 10niu7+K/wADfiF8NdRudcub5rrWdRsfhnpeoyTwxPYXWnh7pbmH9lD9kvVP2UfD1v4Lsv2ov2h/ jZ4D0zTdQsPDvgv4zaX+zJDpfhq51XxBdeJL/WNN1X4Lfs3/AAa8XXupXF9f38Ji8ReJdc0iK0vJ Eg0qKaK1nt+iVpYjExjVfsVUm6dWopRjiOSmlCpGnD2k4SqU4UsPFVVGUXTjCbjRhCoYxU1Tw1SV OKq+xUalGnLmdCVWspzp+0nGlGcKdSVavJw0mqkpxi605019gV8e/tX/ABc+KHhDU/gL8GfgjdeF 9A+Kn7SvxL1fwDo/xB8a6Lc+KPDXww8L+Efh34v+J/jrxu3hC01jw9L4y8RQ6D4Rfw/4O8OS67pe mP4m8QadrWuy3mgaJqmlajlfG79jBPjV+1R+zB+1C37Rv7SXw4f9mc+LinwV+G3xD/4R74K/F/8A 4Sq0FsR8WfCH9nXH/CR/2fjbHi6g8+1WO0byhGJT6z+0L+zz4a/aH8N+GNO1LxR41+HHjT4eeMbD 4i/Cf4t/DS/0bTviH8LvHunabquhx+I/DUnibQfFXhPU4tR8Oa/4g8LeI/DPjLwr4o8IeKfC+v6x ofiDQNQs7wqnPrKhRqVIzVT69bEYWnP3/qOHxtK1SFaNSjGcsbhFUmsOq2GnG/1eeLw8p/WKe93G tWp03DleBbw+KqwvTjj6+FrqMJ0XGrKMMFivYOWIlQxdOSbqrA4yNOWEreE+BfBX7cfwn+Nfhk+O P2hvCv7RH7Lc3w++I+q/EHU/GPwm8I+APjr4S+IemN4Vm8C23h/VPhhN4c8D+J/Aur2D+MDd6dL8 OLDxLod5p1l9r8U+IIdUhi035nOv/t0/Hf8AZK1r9r/wd8bPhx4dtviT8Gtd+LHw1/ZT1L4X6Nc/ Da5+FHiPwne+IfCfg/x/8XW1KT4mwfFnXvB1zZNqvxD8N6jp/gHwd4svzGvwp8X6Jokv9vfZ3wq/ Zk+Ivhfx9pvxJ+Mn7XXx9/aC1nw9puraX4W8I63F8NPhV8JdGXWrZbLUdZ1H4d/BPwL4Dg+IHiSe xDW8F78U9Y8c6T4eeSW+8FaD4V1Ge4vJvGdY/wCCc8N74N8TfA3Qv2qv2j/BX7J/i2DxBp2o/s4e Fp/hPa6bo/hXxRLdya38MvBPxavPhjffGrwd8KbwX95a23hXS/HR1bw7pFx/wi3g7xR4Z8G21j4b tOPN8LVxuV5lgqbpzxOMyjE4TA1ZJRw2GrV55iqscxpOny411o18u9jVWHq/VcPgsRhZvELGSmun Lq9LDYzC4irGp7ChmWFxGKppt169ClChd4KpGrGWH5HCtGVL6xhvb1qsMRGdCVCLqfNem+PP2ovC f7Iv/BHjw9+zT8Q/hz4D1D43eE/gf8HPG6/Ev4fXPj7R7fw/qf7IniT4iv4t0tdL8QeHdTPiPwYP hvcXGg6Gt/Z6N4o1K/t7HX9R0/S0lmP2b8BfF3xw8F/tJ/En9mT4wfFaH47adpvwW+Hnxx8E/EnU fAnhf4feNbBPFPjTx94F8TeCvE+neBYNN8Ga3p9ne+ENN1rwtrOl+HfD+p29rqmo6Rri61NZ2mrz 8zY/8E9YdM8DfsfeAdP/AGuv2qLXS/2K9bsNa+G1+mn/ALJcmreLV0XwVrXwz8OaR8R3uP2U5tO1 DTPDvw28SeIPBNg3g/TfBOq3mnatNrOvaprHi+00vxLYe92P7Nkdj+1Vrn7Vf/C5fi5c6nr3wq0b 4Pz/AAeubf4Oj4Q2fhnQdY1LxFpt7ZPbfCK2+Lw1yLxBrWtau9zefFu8sJp9UntJNMbS7bTbCx+k zLF0cbnuZ4+nzfUszz/iXHSjXi5V4Zdissq1cnopXqqjNZ66Ve+HqOrGlKvRxNd4Jww54+HoVKGU YPB2tjMDkPDeDpzpSUaVTNcNxKnnldtKm61OrwvKeGpvEUlB1I0ZUaFLFwVaP0tXxP8AtLfFD4wT fF74H/st/AjxH4e+HHjf4z+Gfiz8SvFHxf8AEnhiPxwfh78K/g1cfDvRvEY8FeDLvUdL0fXfiR4m 8U/FjwRpPh248TzXnhXw5pS+I/EWr6D4nl07T/Dupnif9i9PEv7dPw6/bf8A+Gjv2lNFk+Hvwk1n 4Uj9mvRfiJ9j/Zq8VLq82ty/8Jh4p+Hv9nP/AGj4ng/tzzjdfb0E1/4f8I337s6CIbz0X9oT9mvS vjtP4B8U6V8QvH/wV+MHwl1PWdU+F3xm+F0nhV/FvhdPE2nxaX4t8Najovjzwv418C+M/AfjOwtd Ph8VeDvF/hXV9Ou7nSdC1/Sn0Xxb4c8N+I9H8hpOODqTjUleriHi8LSnyVacaeIxuHwUoV+eEKkZ KGX5tXpXSqYadbK5tVZTqx9BO1XEQi4cqo01QxFSPNCc6uEo1a8XS5JzpulXnXwMKrjK1SnDHQjK HLTfnvwU8Ffts/D/AOOGq6B8W/jb4K+P37NU3wwnv/DXjPVfht4e+HXx40v4tnxTpkLaB4t/4QO7 034d+JvCB8KDUL7SNV8PfD7wXfWt9JJp+sR6m0Npfz/nP8Xv2mv2xPBz/GXWvG/7Qeu/sqfEjw94 5+IOjfDDwb8Uf2F/iB4t/YIj8C2PijVdK+FPib4nftgeDvCfiyw0qLxt4TTQfEHiDxzqnxv+HVp4 L1/WLix1n4QRQ6JcaHqP6i/Bf9nPxt8PvGWofEn4q/tRfHX9ofxrd+HZ/CmmWnjGfwN4B+FvhLRL zULLUr8eG/hD8HvB/gPwhf67f3Wm2DS+NPiHF4/8c6dbxXOk+HPEuhaBqepaPd/Ntj/wTm8W6b8L 7j9ne2/br/anvf2a9U0TWfCuvfDfXtL/AGedY8Zah4L8RveDxF4CtfjQ3wRtfH2meE9astR1DR5b iO4n8d6Po99LZ+FPHXh02mjzaVpFzhPApexqyw9DFRlOfNCjOWIzWpjqSxdSNGftKuGw86WDhXeV Y6NLBQqYX2eMnRjiccoeyaxUp+2pwqYvBVFCCjVqqlRy5YPEfVac60IxpVasZYqeG/tLAyr42cMQ q+EpSnh8PQ/aJ8b/ALZbftp/s/fAX4H/ABs+GPgn4afHr4GfGnxx4v1PxH8MLDxd4m+GbfBfW/gp Yz+I/he8uv2Fp4z8R+M5fimdJtLHxlBP4U8JWYPii60rxS2np4d1T174PeOfjl8N/wBpOf8AZc+N vxG0n45ad4r+DeufG34UfFaPwVo/gDx7Z2Hgjxl4U8E+P/BXxT0PwnJD4G1SdL3x94O1jwP4v8J+ HvBkOpWMviXQ9X8NC98PW+u678cftl+A/Aniv9uP9j/RLzwh+2F4U0j4IfA742+HvB/xv/Zr+Cf7 Q2sW/wAIviJ8SvFH7Oml/DmOy+JXgr4ZeNfhzfaffeDfB/xA03xjpHjSHxX8P7LQoprX4l6RFDf6 ak36OfA/9l/wt8F/Eni74h3/AI7+KHxr+MPjvTtI0LxV8Y/jTr2ha341u/C3h64vrzQfBuiaZ4N8 L+BPh14F8IaZf6pqeqf8I78PvAfhTTdT1m/utb1yDVNYkF8t4X2apYOveU8M6vE8MSqsYyrYy+Pz 3DZVBScq0sDXwNeeUY+rSpzpx/s/CUMNSr4nD5lXo08Kqqez9jPljjVhskklSm4wws4/2fVx1SX7 ul9boYzB08bhqNerSqTrYqvVqzoYSth6WNf0tXw9+0L8SPjR4h+O/wALP2UfgR4v0P4Ta543+Gvx E+NPxF+M+r+FLHx5rPhD4feAfEXgXwZZeHfhx4O1m8tfDV3488Y+J/HtrIniTxfbeIvDHhPw/wCH NYa78I+INT1vRxY2j+xgh/buH7cn/DRv7SXmD4L/APCnP+Gaf+Fh/wDGNBX+0De/8Jt/wr3+zs/8 JZk7/tf2/b9uxf8A3h5Ndz+0B+zLZfGvXfAHxE8L/E/4hfAj43fCqLxLYeAfjD8MU8HX2t2vhvxo ukf8Jn4C8VeF/iJ4V8beBfG/w/8AFlx4d8N6hrGga94clvbPV/Dmh6/4W1rw14i0y01eLnS5ngKt aNR0/aY947B0p8lZcsM1wmVShiVUpxlCOKWT55iqabVXBLE5TUhUqTqRlvdp4unTdOMlDCrCYmrH npS54YDEY5Tock5wlySzHKaFTeniY0Mzg/ZxhA+dpPGP7W/7IOlftSfFX9pX4oeFf2jf2Xvgp+zb ffGHwH4o0v4daF8OPj7qPi/wRb+PvEnxH8HeOLTwrqcXw716A+GdF8MP4T8SeGvBngGzabVLnT9S 0Sa40ufV9R8f+Iet/wDBRf4H/s9+Jf22vGX7RHwu8aaj8PPh3qPxz+KH7Hmm/Bzw9ovwX/4Vv4e0 GTxl4x+G/wAMvjIdUPxjtviZofhO21Cy8OfFjxnr2veB/FniuwhvNR+D3hPQdb+weH/tD4afsr6h ocvjzUvjt8f/AIxftU6r8R/Bd58Otf0j4qyeCPDvwn07wLqnnDWvDXhv4JfCnwh4D+HKLryTvDrX inxfpHjT4iX1izaI3jVPDhTRY/nhf+Cat3qHhXTvgb4y/bJ/af8AH37Hukx6dpkX7MHihvg3NY6/ 4G0eaF9K+Dnj343WPwpsvj745+D1la21po93oGs/EQ+MfGHh21/4Rj4kfEDxx4a1DXNH1fSCqKXL 7Wkq6pYJYTFzpOtg8K4Y7Nq+NWNwyjQeOqTw+JyWEFUwmIVWGX4nBRxeDjGpj89pSoc9OpUo1p4X 6xiJZhgqVVUMVjKSwGSYXCRy/Et1v7OSqYPPKlaUcVSbxGaUMdLD1ZRp4PKPAf2lfj7+2hp/xR/a u8R/Br9oHwN4R+DHwG/Ya+Hn7aHgvwVrnwJ0rxB4p8R+Jdbt/jc8Hw18UeKNQ8SQtF8N9dt/g5Le +KJ9M0nTPiFb3niC1tfDPinw7b6Pdf2v9R/sq/Ej9o6L46+IPhB8fvif4W+LMniL9mj4R/tIadqP hv4dWHw5sfAXiDx34w8e+FvFPw98NW1lqmrX2t/D+xTw9otz4VvPF99q3ji2lXVm1zxLrceoWVvo 3deOf2GvDPxD+I/7R/j3xD8bvjj/AGR+0z+zhb/sv+LPhfpyfA+x8AeEPh/p9l40tdI1TwBcx/BE /Eaz8WaPc/Ebx3qlne+KviD4v0Oa98Szw6l4ev8AStK8O6bo3beAf2VrHwF8V/BPxhX4zfGHxT4m 8Kfs/wChfs765YeJYvg4mhfEnw54Y17VfEfh/wAX+Nbbwx8H/DOoWPjnTNS1vVCk3w61TwD4Qu4L rytR8HXnk2zQ3h3CFaN4yjhJfWP3deSxGIpU6mG4vlRpVK6jepWpYt8IxlWg/goS5JqnVzZV8MSp ywtoTUsaoYFSrUofV6FStQq+HkcTVp0eZqnSrUKHiBL2U03KWNoe0UqkMslhfBPAo/425/tNH0/4 J6/sYD8/2hv24f8ACv0kr478L/BLxvpP7fPxq/aLu49LHw58dfsm/s4/BzQZY9QD603jL4Y/Fr9p vxl4pju9L8kNbabHo3xV8JNYX/nuLy5k1CARRmyLSfYlZ0fdwOCpvSdN5tzxejj7biHOcTS5l056 FelVj3pzhJaSRti3z5tmtaL5qVWHDapVE7xn9W4J4XwNdRa0fscXhcThqi+xWoVIOzi0FFFFMgKK KKACiiigAooooAKKKKACuZsvGng/UvFviDwFp3inw9f+OPCej+G/EPinwfZ6zp9z4m8OaD4xuPEF p4S1rXNDhuH1LStL8TXXhPxRb6Bf31tBbatN4d1qOxlnfTLwQ9NX5s/BYf8AG1X9vs/9Wl/8E7h/ 5e37dlVFKV7u1oyfzSul89gl7tOpPrB0LLo/bYvD4d/cqzkvOKT0bP0mor8x/wBs/wDav+MHwk+J nhP4T6ZB4f8A2ZPg94x0e3m139v74x6Dc+PvhL4Q12+vmsE+Hug+GvDV2nhzwd46uYngfS/iD+09 4w+FXwptdVvNMs/D2jfGfUnvfCcX0l8Lfgvof7OngHx/408EXHxZ/aS+J/ivRW8W+I/Ffjb4j6T4 m+J3xu1zRNJv7rw1oWi6t4o1fwb8IfAmnag93NYeEvCvhK1+F3wc8NT6xNd2ul+H7O71K/bOE1LD 1sU+ZUKTr0o8sJ1a1Wvh6nJUprD01KrTUIwrStWVPE108HWweFxeCxtPGQqcXGvSwycXXqxo1bSn CnRhQrRjKFR4ipKNObbqU4t0nUoUJxxNHGYjC4rDTw8vqaivzd0X9sr9sTUtY0nTtS/4JF/te+Ht Ov8AU7Cyv9f1H4/f8E4bvT9Dsrq6igutYvrTRv21NT1i6s9Mgkkvbm30rTdQ1KaGB47Gyu7pooJP Wvj3+0Z+0P8ACnxrb+GvhZ/wT+/aD/ad8NzaFZapN8RPhf8AFf8AY58FeHLXU7m5vobnw1LpHx5/ aT+E3jWTU9Ohtba7uby38MS6HNDqVtHY6rdXMN9Da1L3I0pPVVqk6UOX35KVOn7WTqxhzSoU3HSF asqdGpU/c05yq+4TH3pVIrR0qcKsnJckXGc3TSpzlaNWopK86VJzq04Wq1IRptTPsiivlb4dfHb4 5eMPhF8QfiD4v/Ym+N/wm8f+ETqv/CJ/Afxb8Sf2WNe8e/FT7Do9rqNifCnij4d/Hzxl8I9DGtah PNoFl/wsH4ieDjbahZz3WqCw0eS11KfxLwp+2F+13r3ijw5oeu/8Em/2tfBGiazruk6VrHjPXPjx /wAE7dT0XwlpeoX9vaX/AIm1fTfCv7Zev+J7/TNCtZZdUv7Lw5oWta7dWtrLDpGk6jfvb2c1KLdd YdcvtHGhNScoqhbEX9mniW1hoyjZ+3g6qnhdPrMaV1eXJKi63vcilWi4qMnWvQtz2w6TryjK/wC5 lGm44jV4d1UmfotRXxv8e/2jP2h/hT41t/DXws/4J/ftB/tPeG5tCstUm+Inwv8Aiv8AsdeCvDlr qdzc30Nz4al0j48/tJfCbxrJqenQ2tteXN5B4Yl0OaHUraOy1W6uYb6G10vBXx/+PfiX4M/ED4j+ JP2Ffjv8OviL4Tu5rfwp+z74j+J37Jer/EL4pQR2umzx33hXxZ4K/aG8T/BvRLeee9vLJI/H/wAS vCF2k+kXkktslrcabPfZqadKtWSnyUFUlNOE41ZKnV9jL2NCUVXxEnPWnGhTqSq0v39JTo/vDRxa q0qV481aVOMGpwdJOpD2kXVrKTo0IqOlSdepThSn+6qyhV9w+tqK/PbwJ+1z+1n4p8aeFvDfij/g lX+1b8M/Dmu69pmla58QvE3xz/4J8614e8FaXfXcVve+Jtb0jwL+2F4q8Z6lpejQO99e2Xhbw1r2 vXEELxaZpN/dtFbydp8cf2lf2kPhh49ufCnwy/4J2/tF/tI+FodN029h+J/w2+Ln7Fvg7wveXt7E 0l5pEOi/G/8Aac+FvjyO80hwsF5cXPhKDTbiRw2m3t7EGkFS9yNKT1VapUpQ5ffkpU6aqSdWMOaV Cm4ySp1qyp0qtS9KlOdWMoKY+86kVo6VOFWXN7icZ1PZpU5T5Y1qilrOlRc6tOn+9qQjS98+1aK+ VfCHx2+OXiH4HeMvif4g/Yl+N/gP4meHLy/t/Dv7N2v/ABJ/ZX1T4k/EG3tYdLktb/w94x8I/H3x F8ENJt9Tkvr2C2i8ZfFLw1eQSaLetfW1rDc6XJf+QeBP2uf2s/FPjTwt4b8Uf8Eq/wBq34Z+HNd1 7TNK1z4heJvjn/wT51rw94K0u+u4re98Ta3pHgX9sLxV4z1LS9Ggd769svC3hrXteuIIXi0zSb+7 aK3ktQbrxw6cfaSjh5KTnCNC2JV6fNipSWGjKK/3iMqylhHpilRehLklRdd83IpVouKjJ1r4e3O1 h0niJRlf9zONJwxOv1eVWzt+hNFfDnxm/ae/aZ+HHxC1nwj8Ov8Agm5+0p+0H4S02LTX074q/D34 xfsQeE/CniGS9062vLyHTtC+Mn7U3w1+INo+kXc82k3jaz4O0yK4vLOefTXvdNktb247rSPjt8ct Q+AGt/Fi/wD2JvjfoXxW0y/ltdN/ZcvviT+yxdfFPxFapqthYR6npvjfSfj5qHwCtLWaxu7rW0h1 r4uaXfpY6ZdW0lomqzWGn3mUZKVKdZKXJCKlJShKNVp1I0rQoSSrVJc003CnTlNU1Ks4+xhOcdHF xq06T5earKMYtSjKknKm6qdStFujRiopqU61SEIVLUZSVWUYP6por4D+Gn7V/wC1V408eeF/CvjP /gl5+1J8HvC2uapHY638TfGPxt/YH8Q+GPBlk8cjPrOtaL8Nf2uPG/jvUbKF0SJ7fwx4T13VGaVG jsHRZGS78Wv2p/2ofAHxC8R+EfAX/BM39pz45+EtGntItH+KvgX4z/sKeGPCni2K4060vLi50jQv ix+1f8PviDYRWN3cXGlTp4j8H6LPLd2FxPaQ3Gny2l5cU9OS/wDy89ry2963sfY8/Py39lf28PZe 05Pb8tb2PtPq9f2cr3nNL/l2qblf3U1VdRR5HKyqtOlL2kabnKknTdVQVWk5/d9FfK3/AAvb45f8 M9/8Lc/4Ym+N/wDwtn7cbX/hlX/hZP7LH/C1vs3/AAkR0f8AtP8A4Tn/AIX5/wAM+/ZTpH/FWCH/ AIXD9v8A7IIsDZjxFnRh5z8Jf2p/2ofH/wAQvDfhHx7/AMEzP2nPgZ4S1me8i1j4q+OvjP8AsJ+J /CnhGK3068vLe51jQvhP+1f8QfiDfxX95b2+kQJ4b8H63cRXmoW893Db6bFeXttUYuVWdFOPPCSi 3KcY0m3TjVThXk1RnHlmk5wqSjGopUZNVYThGXJRpe1fNy2qOyjKVX93OUJfuYp1rtxbpr2d6sHG pSU6c4Sl930V8IfFr9qf9qHwB8QvEfhHwF/wTN/ac+OfhLRp7SLR/ir4F+M/7Cnhjwp4tiuNOtLy 4udI0L4sftX/AA++INhFY3dxcaVOniPwfos8t3YXE9pDcafLaXlx3N38f/j3B8ANO+LEH7Cvx3vf itea22mXf7LsHxO/ZLi+KWk6auq3tiPEd343uv2hoPgFPpr2Ntba2tpp3xcvNcFjqNtbPpS6pFe2 FrmpqVFV0pcj9j7rhONb9/ONOF8PKKrrllNOtemvq8FKpiPZU4TlHRxaqeybjzfvNVOEqf7unOrL 99GTpK8YSVO8/wB7UcKNLnrVKcJfW1FfDnwZ/ae/aZ+I/wAQ9F8I/EX/AIJuftKfs+eEtSi1N9R+ KvxC+MX7D/izwp4ekstNur2yh1HQvg3+1N8SviFdvrF5BBpFm2i+DtTjt7y9guNSey02O6vrfG+J f7WH7VXgvx54o8K+DP8Agl5+1J8YPC2h6pLY6J8TfB/xt/YH8PeGPGlkiRsmtaLovxK/a48E+O9O spmd40tvFHhPQtUVomaWwjRo2epe5KlF6utTnVhy+/FRp1FTkqsoc0aFRyacKNZ06tWnerShOlFz Ux95VGtqc4Qlze626kZTi6cZWdWCUGp1KSnClJxhUlCc4Rl963V1bWVtcXt7cQWlnaQS3V3d3Usd vbWttbxtLPcXE8rJFDBDEjySyyOsccas7sqqSPlG/wD2lLTUvj98GPhv8Pde+HvjTwF8QdM+IU3i TxHoWqReI7vTtW8H+Hp9atrDT9Y0TXZNGtJf+POTUbW/sb25+yXMbxm286KWvJv2kNQ+O/xw/Y3i msP2c/il8PfiL4w1fTD4u+C2seLPg3rvjfwX4c0PXb+/vrrX9W+HnxP8WeB/Ette2eh6dfW2j/Dr xZ408RXv9t6XYRaJLfx6rZ6f4N8PvBeo+L/2kPgpr3h39lLxn8APBlr4D+IfhHxDq9x4Um0u2ubm 78E+KNIttU1+CLSdNt9PvEmvo7e11PxA66v4nlu40Et2trbM/wCD+IfG/F+XcaZbwnkeVyhRoZtw bWni4LMp1c+p5lmmOpZlhcJi8Nl+IyWlk+BjhMHhM1xmLzKj7+a05wlTjhrYv+gPDDgXhDNODs+4 vz7MoV8TDIvEjD4fKpyyunRyfEZVwRiMbkWZZhh8XmWFzitj8wzTEVKmRYXLsvxEvrGST+sJ08VC dD6li/a28e+PLzxDefs+fs4+I/jF4E8M3Nxpt348vPHfh74e6drGrWc98t3H4RsdY0/U7nxNpq21 tbTxXdlKmomW7S2u9Fsmeykv5fEP7U/xSHxZ1v4RfDn9nOb4ha/4d8IeGvF+sed8VdD8Ez2Vp4g0 vSb2a3ltPEnhtIjNpt7q0WmyJHfyXU7oZzZ26744vAPgz8Sfjn+yp4If4IeIP2Wfij8QJ/Cms+IZ dB8W+ALC61fw54h0vVtWvdRsbuXUNF0fW7a1e5lneXy5riTVbOxmtodV0yxv7ea0rOs/iX8YvAn7 THj/AONGs/snfHeRvHHw38K+H/8AhEtI0W08VvomoWaaK1wt34u8ES+KvCN+nl6R50Y0jVL6aJby K31KHTdRgvLC3+HhxxxHWyHgvHYzxE4wy3HZzxJkmE8Q6UOBskwVTgOdfgnj7M8dkmW4TM+BcbVj hlxTleVZXiK2a/2/jqcMvwzpZjhqebSnivvnwHwlS4h4qwGXeHvCGcZLlXC2dY/w8zKvxxn2Il4g VsPmvClDAZlm9XLeOctpRxNTKswxmPjgcoocOUcNUxlXB4vC4nEYGPsvpDTv21tD1P4L/FP4kDwB rukeOvg1Jpln48+E3iS+bRtT07UdT1K102JItbOkXRewaeS/iiubjQrTURc6Vcw3ujWEc1ncXG1Z ftfaBq/7M/iP9oTR/DEl1qHg9Fs/FPw5u9b+w6jofiOPWNP0q80O91g6PcMipHqEOp2V62iK15Yy 24ms7G6e5trT86vEmi/tQ67d/tT6h4g/Y5+MWmaf+0P4K8IeJtH8caF4m+DWu+D/AAv/AGFrVjPY eBdV8C2HxKj/AGgdU8eX1ktvLeTQ/A+10bSPLnk1TU7S6udUstI434s6Z+1bqeueMNM8F/sL/tCe AfAfif4a6D4C+I/j3UvEv7OnivwX8Urvwfe+Ho/B/jfwt8N/ht8cvF/x60XXtRW2YtH4q+EOh3Gm 6NDef8JPbeHtTutTE/m4/wAQPGvBZFnmbPC46rLCeEH1yng4cMUMHmmF4ozHPvFTKeH+MYYDGYOp UjjZUuGuDMTnnB+PhOlhcFnlTNKGAhh8DVw+Y9+H8PPBDG5tl2Ue3y/AYnHeJuS4J4hcVYjMcoo4 OlwtwFnXE3Ak8xw2O9niMqlj874pyvKeL8JJ4ilm+V4TK8Xm0o1q+Lw/7e2vxd8ARaPod/4n8YeD /CGpav4L0zx1PoeveLNFsL3TtA1C3geTUpU1C4sJ30i0upjYvrD2sFk1xGUYxSExL2ugeIdA8V6T Z6/4X1zR/EmhagJmsNa0DU7LWNJvhb3EtpcGz1LTp7izuRBd289rMYZnEVxDLC+2SN1X8e/iVZfF iP4hfBH4jXH7Cnxc/aBbQP2dtK8M6l8FLS7+CNhcR6za+Itb0eO41jxJ8Wfib4O+BpnttJaHxZD4 b13x8viK2tb7T3TQovFFgbGx9d/4J+a38afDUevfDLxj+yd8ZfhX4L1fW/GHxDtfHfjLXPhPB4W8 C6lft4atbX4KzeHbT4laj8Q9Z8QWUQvL9fGfgrwh4l+Dmorb3o0z4jX1+xhl/bOG+NuJc24xrZFj 8gw+EyWWJ40wODzKMswp4v6zwlicmdGvioYrCUcEsHnOBzWs8JWw+InT+u5dLCU6tXE4ynhKP47x d4f8IZRwpXzzKuIsTXzmlhOH84qZU1l9bALBZ/nmfZJLAYWtRxlbMZY/LKmWYLGVoYmiqv8AZ2Kn iqlJYalLGn6f0V+dXiv9sH9rvQfFHiPQ9B/4JN/ta+N9E0fXdW0vR/Geh/Hj/gndpmi+LdMsL+e1 sPEukab4q/bL0DxPYaZrlrFFqdjZ+ItC0bXLa1uYodW0rT75J7SL2z4i/Hb45eD/AIQ/D34g+EP2 Jvjf8WPH/i4aV/wlnwH8J/En9ljQfHvwr+36PcajfDxZ4p+Ifx88HfCPXDomoQw6Bff8K++InjEX OoXcV1pRv9HjuNSh/VFNOhHEJT9nKVCKi4TVe+JdqblhnFYmMY/8v5ypKGFWuJlRTTPxZxarOj7v Oo1pOSlF0bULc9sQm6EpSv8AuYxqOWI1WHVVpn1TRXxv8BP2jP2h/it41uPDXxT/AOCf37Qf7MPh uHQr7VYfiL8UPiv+xz418OXeqWt1YQW3hmLSPgN+0n8WfGseqalDdXV5bXtx4Xi0KGHTLqO+1a0u ZrCC78l1r9sr9sTTdY1bTtO/4JF/te+IdPsNTv7Kw1/T/j9/wThtLDXLK1upYLXWLG01n9tTTdXt bPU4I0vba31XTrDUoYZ0jvrK1ullgjqXuypxerq051YuPvxUYVPZNVJw5o0ajlrCjVcK1Sn+9hCV L3yY+9GpJaKlUhTlze5JynB1IunGfLKtTUVadWkp0qc7Uqk41GoP9IqK+Vfiz8dvjl4B+Hnw48Xe A/2Jfjf8cfFvjK0tLjxh8KvA3xJ/ZX8MeK/hHcXGjW2o3Fh4v134r/H34f8Aw91+4sNRnm8Pzy/D jxj41s5dQs5ru0ubjR5LbUp8v4AftC/tAfFjxRrGh/Fb9gv4+fsuaJp3h+fVtP8AGfxS+KX7Ifjf Rdf1aK+sraPwtYad8Av2i/i54otNVuba5udRivtX0HTvD6W2nXMM+sRXs1la3Ts/aV6enNhnVVR8 0fZydGk6s/YVb+yxSlFWpSws60cRVtRoOpWapickqdGrry1405QSjJ1IqpU9lH21FJ1cPJS1qRxE KUqVP99VUKPvn19RX5o3X7aX7ZcFzcwwf8EfP2xb2CGeaKG8h/aD/wCCa0UN3FHIyR3MUdz+25Dc xxzoBKiXEMM6K4WWKOQMg+hfjd8dvjl8M/D3w+1f4a/sTfG/9o3VvF1hNdeLPCvw4+JP7LHg/Vfh XdRWWl3MemeK7742fHz4X+H9curi5vr3Topvh9q/jCwS40W+mnu4rK40q51Cbr2aq68rnTppWftO arGcot0re1jBKEvaVJQVOjJwjWlCVSmpU01VdHTnUa021KLpWocqmlXT9g5y5l7GCqOeI950I1FG Vvqmivk79nz49/Hf4uav4k0/4s/sO/HP9lbT9G0m3v8AR9e+KvxM/ZR8c2Hi6/luTBLoekWv7P37 QPxg1fT761hAvJbnxHp2i6S8J8uDUJbkGCvArr9tL9suC5uYYP8Agj5+2LewQzzRQ3kP7Qf/AATW ihu4o5GSO5ijuf23IbmOOdAJUS4hhnRXCyxRyBkDl7soRe86bqx5feioqpKnaco3jTqc0G1RqONV 03GqoeynCclH3lUktFSqRpS5vcblKmqidOM+WVWmotKVakp0oVL0pTjVTgv0uor5J+N3x/8Aj18M 9O+H158Nf2Fvjv8AtGXfi3RJtT8WaV8OPid+yZ4Pu/hZqUcGlyx+HPFU/wAa/wBoX4YafrmpTy31 7bR3fw/vPF+iJJo1682qRw3GmS31z4A/Hf45/FdfGh+Kv7Evxw/ZePhvT7C78OL8UviT+yv43PxD ursaj9q0vw6fgJ8ffi2NJu9LNnZi6m8Znwzp8/8Aa1n9gvLsQaj9iHoq7f8AzD+39pbVy+rylGp7 BK7xXM4N0PqyrfWouM8N7aE4Skk7xoy1tXVFwumpR+sOKh7aLSlh3HnXtlXVN4ZKTxCpKE+X6qor 8zD+2t+2fv2/8Odv2yCu7HmD9oX/AIJo4K5xv2n9uANjHzYIDdsZr6J+P3x2+OXwnHgw/Cr9iX43 /tQnxJYX934iX4W/En9lfwR/wr26tRp/2XS/EJ+Pnx8+Eg1a71P7Xdi1m8G/8JLp8P8AZV39uvLT z9P+2DfLGEne06nsopJykpezlUvOEbzp0+WDXtqkY0vaONLn9rOEJVa83DrGE6jd0ocsJQg0qj9y U26kXCnGTqTipzhGUKdSUfqqivkn4JfH/wCPfxM074hXnxK/YV+O/wCzneeEdEh1PwnpPxH+J37J fjC7+KmpSQapLJ4c8KT/AAU/aG+J+n6HqdvLY2NtJd/EG88H6G8mtWLw6rLBbarLYeD2v7af7Zk9 zbwz/wDBHz9sWzhmniimu5v2g/8AgmrJFaxSSKklzLHbftuTXEkcCEyulvDLMyqViikcqpqMXKtC gnHnnGlJSlOMaKVac4QU8RJqhTknTk6sJ1IzoQcKleNOnUpylLaUJVNeWE5waSbm3Tp06knGkk6k 4uNWKhOEJQqVFUpU5Sq0a0IfpdRXyd+0J8e/jv8ACPWPDmnfCb9hz45/tU6frOk3F/rGv/Cr4mfs o+BtP8JX8V0IItD1e1/aB/aB+EGsX9/dQZvIrnw5putaTHCPLn1CK6/cVufs6/Gj4y/GCDxVJ8Xf 2P8A4xfsny6FLpCaHb/Fr4g/s1+PJPG0eoJqDX82hv8As8fG34yQ6amhNaWiX6+KpNAkujqlqdJT UVg1BrOaf72NSUdFS5+ZVH7GT9nW9jL2cK3JKreb5oeyU/aUf9op81BOoOb9m4KV37RU3HkTqJe0 pqpHndPnVNqLtUVTkdKpelVUKqcF7fB408IXXjDVPh7beKfD1x490Pw5ofjDWfBcOsafL4q0rwn4 m1LXtG8O+JtR0BLg6pZ6DrureFfE2maRq1xax2Oo3/h/WbS0nln027SLpq/NvwKP+Nuf7TR9P+Ce v7GA/P8AaG/bh/wr9JKVP38Nhq70dd4+8VtH6pm+Y5bGz39+GCjUl2lOSWiRVdKlj8dg43ccJHJ3 Gb+KbzLhrJM8qcyWi9lWzWpQhbelShKXvOQUUUUyQooooAKKKKACiiigAooooAK+Ofhx8EfHHhf9 uX9qr4/6pHpQ+H/xe+A37I3w88Hy2+oCbWH8RfBnxJ+1BqnjVNS0zyVNjZxWvxX8Itpl158ov3l1 BAkRsm8z7GrmbLxp4P1Lxb4g8Bad4p8PX/jjwno/hvxD4p8H2es6fc+JvDmg+MbjxBaeEta1zQ4b h9S0rS/E114T8UW+gX99bQW2rTeHdajsZZ30y8ELTavbqmn5J7g9YTi/hl7Lm/7h16VaGvS9WnTX nflWrRuX1jZanZXem6lZ2uoadqFtPZX9hfW8V3ZXtndRNBc2l3azpJBc21xC7wzwTRvFNE7RyIyM QfE/gl+zd8JP2c08Vab8GND1LwN4P8U6ha6qvw007xL4huPhb4Nv4ftn2s/C/wCHmoaleeFfhVpm sPd/adY8NfDzTfDfha81CBNV/sSPVLjUL297zxP8UPhn4JvodL8Z/ETwL4S1K4tlvLfTvE/i3QNB vp7N5JIUuobTVdQtLiW2eaGaJZ0jaJpIpEDFkYDY1Dxf4T0jw+PFuq+KPDumeFWgtboeJtQ1vTbL w+ba+aNLK4Gs3NzFpxgu3mhS1lFz5dw0saxM5dQZi1HnqRajzxVCpUjpzwVVTVGcl8UVWgpqnJtK rBSS5oppyTlyU5Jy5Ze2pwevLPk5fawi9pezny88Vfkm435ZWfRUVyGvfEHwD4V03TdZ8T+N/CHh zR9Z8s6PquveJdF0fTdV82AXUX9m32oXtva33mWzLcR/ZZZd8DCVcxkNUHjH4l/Dj4d+H4fFvxA8 f+CfAvhW5mtbe38TeMfFWheGPD889+hksYYdZ1u/sdOlmvEBe1jS5Z7hAWhVwM037t+bTlnGnK+n LUk0o03facm0oxfvNtWWol73Ly680XONteaEfinG28Y9ZLRdWdtRWZpOtaPr1nHqOhatpmtafMkE kV9pN/a6jZyx3Vrb31tJHc2cs0LpcWV3a3kDK5Wa1ube4jLQzRu2nTacXZpp9mrPXVaPy1EmpJOL TT1TTun6NaMKKK8x+GXxp+EXxpg8V3Xwj+Jfgj4l23gTxdqPgHxpP4I8S6T4ki8K+NtItrK81Pwp rz6VdXK6Xr9jaajp91c6XdmK7itr20naIRXETMlrJxWso05VZRWslSjUpUpVWlqqcatajTlN+6ql WlBvmqQTb0Sk9IuappvROpKFSpGCeznKFKrNR+Jwp1JJWhJr06ivO9F+L/wm8SeIPEHhLw78UPh3 r3irwlcQ2nirwzovjbw1qniDwzd3F5Hp0Fr4g0ax1OfUdGuJ9QmhsYYdStraSS8ljtUVp5FQya/8 WfhX4U1VtC8U/Ez4f+GtcRIJH0bX/GXhzR9VSO5UPbO2najqVtdqlwjB4GMIEqkNGWBBovdQa1VV KVN9KiaunB/bTSbTjdNIdneas703aousGuW6mvstc0dJW+KPdHoFFc7rvi/wn4W0yDW/E3ijw74d 0a6mtre21fXdb03SNMuLi8RntIIL/ULm3tJprpFZ7aKOVnnRWaJWAJqn4k8f+A/B0mmw+LvG3hHw rLrJcaRF4k8SaNocmqmNolkGmpqd7atfGNriBXFqJSjTRBsGRMltbdXP2aXV1LKXJbfns0+X4rNO 1mLpfo486fRwTac7/wAqaa5trpq+h11FAOeRyDyCO9FABRRRQAUUV5j4k+NXwi8H/EXwH8IvFfxL 8D+Hfil8Uk1iT4b/AA91nxLpOneMPHUfh+wutV1tvCvh+6uo9S1saVpthfX99/Z9vP8AZ7Syu7iT EVtMyC1lCC1nUbjTgvinKMJVJRhHeTVOE5tJNqEJSfuxbQ9Izm9IU4udSb+GnBNJznLaMU5RTlJp XaV7tHp1FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAfHfhf4JeN9J/b5+NX7Rd3HpY+HPjr9k39nH4OaDLHqAfWm8ZfDH4tftN+MvFMd3pf khrbTY9G+KvhJrC/89xeXMmoQCKM2RaT7ErmYPGnhC68Yap8PbbxT4euPHuh+HND8Yaz4Lh1jT5f FWleE/E2pa9o3h3xNqOgJcHVLPQdd1bwr4m0zSNWuLWOx1G/8P6zaWk8s+m3aRdNRD3aNGlHWnSe K9m97+3x+Lxdf3tpcuKxOIgrfAoqm7yhJuqzdTF4rETXLXrxy1V4apRWCyXLMswbUHeUPaZdgcFW d3ao6jrwtTqwiiiiigkKKKKACiiigAooooAKKKKACvzZ+Cw/42q/t9n/AKtL/wCCdw/8vb9uyv0m r45+HHwR8ceF/wBuX9qr4/6pHpQ+H/xe+A37I3w88Hy2+oCbWH8RfBnxJ+1BqnjVNS0zyVNjZxWv xX8Itpl158ov3l1BAkRsm8y4O3Nrb3JL71a34inrQrRXxSeFsu/JmGDqSt/hpwnJ9lFvoeH/AB8+ DPwf+Jf/AAUg/ZVf4j/Cj4a/EB5/2S/2v1mbxt4F8L+K2mXRviX+yQdHWVtd0u/Mi6Udb1o6aHJF idX1Q2vlfb7vzfm/48/Bz4WfCnUP2/v2dvAXgPwbp3wC8e/8E+fF37RGq/BG18N6Ifhj4A+MOl3P xH8Ljxn4R8ECzOgeD7n4k2umWGsapZ6Tp1hp194u+HE3jOytk8T6h4m1XUPvv43/ALIWr/GD43+B Pj34d/at/aQ+Avi34d/Drxl8M/D+k/CLSf2WdU8MNofxB13wl4g8Y31/afHP9mX406xc6zrV34D8 GwtOmuQWGn2mgQppGm6fPqOt3GqZ6/sNeED8J/j74Au/jJ8ctV+If7TXh2Twp8YP2l9a1H4W6z8d dc0D+zL/AEKx0XR49S+FFz8FfB/h3RNB1fXdL8PeD/CXwZ0XwXoMviLxF4g0vw5a+Ltd1TxDdeZi 8NUr5RLC00ozhl3FWEqYWTUY5hWzmvxA8uU5xvCOHweIzPLc8lUqSVSOOynC0lh5uTr0PTwWKpYf MsHXquThDM+GcX9ajHnlgqOU4/JsZmDpwny1JVcVgcDj8kcKSSlhszxLdV0b0cR+N3j7wf4R+Gv7 FTfsV/GDwr4Z8beGNA8Ffs3/ABv/AGK9d8daDpXiaWP4O6/8XPgrpXxJ+Emk3uvWl9Jb678AvEXi WDw3ax2rwzTfBDxz8MdOL6hJo/iOaP8AUT9oH4F+KE/aT8H/AB28NfAP4Y/tVeDvBHwRj+Fdl8D9 d8ReD/DPjX4N3t14ov8AWLnx58F9H8f6VJ8Lry5+I2hLYeD/ABZa+IPE3wxvbbSvAPhuHRvEmp6d NrGkQdR8Rv8Agnd8NfjJ8Avg/wDAf4wfFj43fEWX4G+PfA/j/wCH3xj1G7+EfhX4v2Fz4D1K2l0/ w3d3nw3+EHgj4eXfhPWfDUE3gLxVpn/CuYrrxB4Tvbh7zUD4ph0/xNZdD8R/2NNX1748+Lv2lvhD +018b/gJ8UvHngHwF8NPGFh4as/hV45+FviPwt8ONQ8Y6n4YfUvh58S/h34oW38R2F346194vE2h a9omrGOWGwnmuNJFzp1z7WY1oYjMamNpOo3/AGtmVWNWKhz1cLiMtxGBwmKxFKsmqmJlgcdPKsfU q1q2LqYijis6hXnWxNKhH57KsPWwuV0sDX5G1leV0asJSnyRxeFx+ExeNo4atR/eUcK8Zl8M2wUa cKGHcMRSySthaGCpVpy5z/gn34X/AGdvBnh39obQ/gF8JPGX7PWoXn7RniLxX8bf2fvG+keDtBv/ AIT/ABc8T+APhzdXumaJpfw51fxN8Ok8JeJvCFv4R8b6JeeAfGHjDwpfv4kv59O1xJftWj6T+gVe Bfs//s/aN8BNH8YqvjTxv8UfHnxN8ZT/ABC+KvxW+I9x4ek8Y+P/ABhLoeieF7W+vbHwd4e8I+DP D2k6H4V8NeHvC/hvwz4Q8K6BoWj6Jo1mi2dxqU2panqHvtZVJXhhIc0X9Xy7K8G1TdV0KTwOW4XB uhhPb/v1gcO6DoYBV/30cFToRq/vFI7IJ81ebU/32Mx2IvU9n7ap9ZxlfEe2xHsf3TxNb2ntcS6f uSrzqNaM/PzxL4q/aI/aC/aA+Mnwk+DXxh0/9nb4cfs6L4F0Dxf4x034d+GPiL8TviD8VfHXg/T/ AIjR6PpkPj8aj4L8KfDXwr4L8QeEm1G6/wCEV1vxR408Qa7qVhpWueCrXwnLP4j/ADUj1z47ab8N P+Ckfg34t+KtD0fx347/AOCmP7IH7OfxF+JXwcl1rwXa6n8KfjD4F/YR+E/iLxl4bhn1fVNd+GPi Txf8LPFtxbXdpa+J9WuvAnibWLqXw/4mvF0/S9Sb9cfin+ypqfij4n6j8avg38fPij+zb8S/FHhv RPB/xEv/AADpHwy8YeFPiVoXhmbUJPCt14s8D/FfwL440SPxd4Rj1fVbPw74z8NDw/rbaberovie TxRoGm6NpOm+WfCL/gmz8J/hfpn7TPhrxB8U/jr8cvBH7XOpt4r+Nvgn42a98Ote03XPiPe+FPCv g/X/AIm6P4k8JfDDwV8RvDfijW9N8GaDPbaZpPjiDwJ4FvbK0f4WeDfAVrpmjWum82FjyVHOtSp1 qP1KVPE4PEtVIZlWpcR5DnE8JOryVqlHLc2y3KswyuslLlwv9o4ajUwGLp0FjsL0VJ+/TdOdSlOO Iw06eIw/uTwtF5ZisFVqxpc9GFTGYXH4nD5hSTvKvHB1ascwws6jy3F9N8Rf+Ca/7FnxC8MfCnwx D8A/hz8Oh8EPiD8LfiP8KvEPwp8E+DPAvizwTq/wn8deHPHuj6Vomvad4de6tvDPiK98M2ui+NtD ANv4l8P3uo21w0V+9pqVn5T4l+A3wN+JX/BTbxnc/Eb4MfCjx/c3P7Efw9vLi48bfDrwh4qnuLyP 42fEHS47qaXXdHv5JbmPTLa305J3ZpUsIIbRWFvEka+k6R+xT45nvvC2j/E79tn9qP4v/CTwTrWh a7onwt8Ry/B3wnL4iufC97b6l4a0/wCKvxQ+GHwq8D/FP4kaFol/Z2Nw2k3nivSYfGS2aQfFaT4i Q3Wppf7XxK/Y08ReOP2gNY/aK8I/tkftR/BDxVrHw40H4VyeGfhjon7IGr+C7PwloGs6j4jggs7f 40fsnfF3xP8AbrzX9W1HVb69vPFV5IZrk2lmtlpkNvYw6ppYzAYmTnVpQxmfYqvTmk6qnmXCuYZL SxVdSnKn9brYqvg44iNGriIww+Fp1liKtT9zDFpyy/MsHFU6VatheH6FCpBy9i45Zxfkud4jC0Zq nGqsNTweBxbwzrUcPz4jESpuhRjKVSX5f/tXfBz4XeFvgR/wVf8A2UdL8DeFdQ/Z18DfA34R/Gz4 dfDK/wBD0zUPBnwb8cfGOw+KmieO/Cfw10ea3ksPAvh9k8AaV480jw3oUWnw+GdV+IniW50OLTtL 121tIrXxc8M+F9O8P/Cf9jr4++F/DPxH+IH7NX7YP7FLfA3x38RPD2j+KvEXxD/ZI8e/tF+CtJ8F arFrWv2V9e3mveD/AOy7n4LfF7y7l7rW9U8I6B4y8RRpD8RNGjk/SHxT/wAE/vh94k/Zw+Ln7PFt 8Xfjp4du/j7q0mvfG34+WGr/AAz8R/Hr4m61dW+mabqF94g1z4jfCvxx8PrOK50HRdI8L6do/hv4 baFoHg3wvpmn6F8P9J8JafZWsMO18T/2F/h98a3/AGX9b+K/xH+LfjP4kfsqfEvQPiZ4R+Lj3fw1 8LeOfHdzoeuaZ4kn8HfE+z8CfDLwr4A1fwB4h1zw94P1bX/DXhfwP4PWbVfBPhTV9NvNM1fTDfz1 hX7HNMlxU5r2GBz7gvE5lGPO/bYfIM0y7MJYvBSsp1nldPDYjLcJPGww9fEZZi8dShgKFbGQnhYx C9rhMwpwhy1cRlnEVPBOXKnRrZlgq2F+r4pRb5f7WnUeOxVPD1atChmiwmJq4rE08DyYjwrVL79t b4oftr/tFfAnwZ+0v4R+EXwN+G/wx+AvxM0HVNB+CXhfxT8YbHXfilc/FnRW8E2ep+M7nWPAcngq 3b4ZNrur6xq/hHVfFd/capBomiTeGbWzm1O9+p/2Nvi145+MvwNtfEXxMfQLr4geFfiR8bvg94u1 jwtpl1ofh7xRrfwM+Mvjv4PXXjLStAvdR1i58O23jH/hCU8THw7JrGrroU2qS6VDqmoQWkd3M3wV +y9J4L/aT+MX7Ssfx9+NviHU/jP4Q8JeCdX+F2v2fwHX4X+F9I8A3fiS88ES+EW8P/A7Qfiel/4a m8ZeLfs03ij4m+KYdTTX7hfENtrJ0/QzpWt+y7+zfB+y94C8Q+AbP4vfFf4yWviL4m/En4qS698X ofhJDr+na98V/GGreP8Axlp2nf8ACnvhR8ItB/sO78ZeINf12zg1HQdR1Kwk1efTrfVBo1ppem6f NFpUlTaaTwlOp+9/eV1iY4hQp0J1U6j9pSwsqvtZU6jw+IiqNWtWxONjKa0rq9Ryp7xxtKEfZ+5R eC/s6p9ZqQp2hdVcyjh50vaw+sUk61OlChg5Kk/pKvzfHiH9pv8Aal+Ln7QGhfCf49W/7Mfwo/Z0 +JNt8GbC78NfC/wN8S/iN8UviNZ+AfBfj7xZ4g8S3/xMt9d8M+GfhxpH/CeaR4V0Xwr4f8LWnjHW r3R9e8RXHjzTdO1HRtLtvSP2UP2L0/ZW+IH7Ufj5P2jv2lPjkf2nPi3cfFZvC3x1+In/AAm3hX4O tcS6rN/wh/wh0z+zrL/hGfDCf2t9gW1Mk5OiaH4W0s8aGLm7i8f/ALHniS5+KHjj4t/s/ftN/Fz9 mDxH8WZdFvPi/oPgrw18HfiD4B+IHiHw/odh4V0r4gyeFPjB8OfHH/CL/Eq28J6Ronhi48R+E9S0 jSvEGjaFoUXjLwz4nudE0m6sskv3mHqVVOdOplKcqNKbg8FnWI/suu3Wqe0hHF4XAUI51lcoxjOG JxWJwWY0qcY4aMoW2+XEQpyhF08fKMK1SHOsZltGeKpxdKHJKWExGLm8Bjoyk1Kjh6GJwNRuWJco +Uaj8WP23PhF8CPBHgz4uX/wK8Q/tafGf9p/XPgD8KvHnh3wj4j0b4MWvg7U9Y8a+JPCXxY8V/D3 /hOdV8QpqWl/BHwRrHivUPhzbfESF9b8dxWHgyPxbpVnqL63aeJ/GjwZ+1N8OP2rP+Caml/Ev456 F+0L8LvEf7VvjOa51rX/AId+F/hl8SvA3juw/Y8/ahmsLTR08AJZeE/Ffw91/TpdZT+z9T0G08Ye EtQ0zT5LnxZ4ys9ZnTRPt66/Yx8Ha38Dbn4MeM/iv8fPH2tT+N7P4q2/x48X/EWK++N+g/FvSdXs 9d8P/EXwZqtnoOn+AfAV34b1LTrP+w/Avgn4eaB8IbXS1vfDk3w5ufDet6/pGq+J+If+CdXiD4i/ EX4LfGD4t/twftVeM/id+zr44ufGfwc13SNM/Zo8GeH/AAy2reEvEngXxZZap8PdP/Z8v/Aniy98 c+FPFF/pHiPxP4h0G88SaLBFGvww1H4cR32vx61vQ9yvRdWcJ1KWYZfUq4pQvhpYDD4HKKMoUaCp wviaeZ4fNsdVxH1HBVq9LF0MRGo6kKOTZflX9/D45UozhTxeVZ5Qp4Vz/fwzHMa2eOlOVfmbp4D6 hjcowNHBvGYyGF+oYmk/aQr1Mbi+Zsrj9uP4v/tXftY/CXw9+1J4P+Evwc+DV98LtU8Dan4b+Bfh XxR8VrjU/iV4IfxKvg3XLzxpeat4LfwF4Z+zLLc6jB4ek8deLrjVGtbXXfA1toaz+IPrv9j34u+L fjl+zv4C+Inj+30K38dXFz418JeMpPC9reaf4b1LxT8NPH/in4a69rugaZqN9ql/pGjeItU8JXWu 6bot7qurXWjWeow6ZPqupyWjX1xlfDr9lm6+HPxq/aB+Nlt+0R8dfE2pftCw6UuseC/E1h+z4PBP gG68N6aNE8I6h8Pv+Ea+AnhvxoLrwpoe7SdNj8e+M/HlhqNu7XXiey1/VAl+vRfsvfs6Wv7L3wli +EWn/Ff4pfF3TbfxR438VWvir4sp8LIfF1rceP8AxNqfjHXdNif4RfC/4S+GG0xPEut61qmnmfwx Nqls2pzWb6nPp9tptpZZUuaGHVNWusLRqtVXz1pV4TqU1hnXaqzVaMJSqV5qp9WrU3RnOtXxVPlg 6icq3tG0/wDaK1N+yvCiqU4RqOvGl+7Xs51YqNKMoe2oS9tTpUcPhJRT+jK/NTRtc/am/ay8bfG7 V/hX+0NZ/sx/Cb4N/F7xh8D/AAPp3hz4SeB/ib4z+JHi74Zmy0rx94y+Jep/EhdU07SvBh8avq3h nwx4E8D6R4X8Sz6N4fk8V3/xJc+KtP0Xw16r+w7+xin7E3gP4i+BU/aM/aR/aTHxC+L3i74snxN+ 0v8AEP8A4WL4n8KnxUmnxnwb4X1H+ztO/s/wrYHT/tyWflubjWdR1bUz5Jvvs8Wb4v8A2NPFUHxF +IHxE/Z5/aq+M37ML/GDWrXxR8WPBngvwv8ABH4h+BfEfjWHR9N8PXPxH8PaH8Zvhf4+n8CeP9V0 PRtH0/Xbvw/qC+DPEE2l2ut+IPAuq+JJb/Wb1KKValOop1KVTKbezpzcPqmc4ieUV+as1On9Yw+C w0M7yxyi69OticRhcXDBvlpYvA6ya9nVp0pQjUp5ppWqQ544vKKEczoctKDp1Hh8RjMRPJ8yi5On OhhsNi8DUqydedKtz2oeJv8AgoH4G/Yi8Wa74r0P4W+P/wBszRPEPiy0iHwp8G6lc+B9Q8Cf8Lpv 9K0Xx14R+GGt/Ea21TW/EulfASS18c2Xwuv/AIowXuveM7FfBsnidrm88+Txj9mH45fFrxL+0boH w0vf2s9f+IfhfV/hb8QPEniL4Z/tTfsYfEH9kT9o6LxXpl94OtfD3iP4MweJPhf8G/C/xP8AhZoP 9oeILXx7Bp/hzxLqHhy+ufCsj+OdUtdVZIfqLxR+xfpPij4CeH/gfL+0J+0/Yav4d+JHhv4v23x6 X4k6Lr/xxu/iL4Z8ZxePLTV73VfGngvxR8Pk0G61+JIbj4b6Z8OdN+F9n4cH/CIaD4L0XwssekJH 4D/ZU8U6L8UPCvxq+Of7S3xX/aL8SfCvTPFtv8LtF1/wd8JvA3hPwVceLtKXRPEviqLw38I/h54Y 1fxZ471Pw2tz4cjvtb1bU9HsNM1LU4fDXhPSL/VLq6m0jKLrYyripwjC+JpuVO9LD1KKyimo4jDO MIrDJ5lXxcY0/wCz8HXhHC0MZ9coLEUsLlWUrulRhQpzbdb28YyanXhKrmTf1atHmvUjRwNHDzjb H4ukpYnEYR0cWqMq2Y/Iv7Nlx/wUM/aJX49DxH+174C+HWmfAv8AaL+MPwP8A6r4F/Z88E6/rnxP /wCFe66lvF4p+MmmeKdY1HTNB0hftcOhW3gP4cN4T8RXVppdx4nu/iWreJLDSPDv3n+yP8ZvFfxy +DNv4o+IGl+H9J+Inhbx78WPhB8RI/CBvz4L1Hxz8E/ib4r+FXifxD4MXVbi81S28KeJtU8JT+IN D0zU77UNT0Sy1KPQ9T1LUb/Tbm9n/Kn9j74EaR8WPH37VmreGvGf/BRP9kLxh8Vv2jPjj8UPGkWl /Cj4ofAzwF8Xvh/4h8bfZPA2v/a/2j/gDrfhDQPHtx4VfTtOl1j4Q6j4B+Mp8PWOnRazqb23hnTH 0f8AaL4a/CDwH8Hvhhofwf8AhnpU/hHwT4b0e60fRrey1PUb3WIDqEt1d6lrl54i1i51LW9a8Vat qt9fa/rfinXb7U9d13xFfXuu6zfX+p3t1czTTlVhlWXVZ0r4mtw5kFarQlyqtWzj+ycLLM68sRJW w8amP+uUquGioxji61anUw+ChldCliKxCpyzPNaVKXLRocU8RU6FaLl7GnksM2zKll+Fhh0/3zeF eXYjC4y808Dhqc6NSv8A2rWlh/Ta/MfwfrP7Wn7Xd98VPiP8MP2j9M/Zm+GPgX4x/Fv4M/Crwfov wZ8E/FDVvGmo/A3x3rnws8Y+NvjTq/j24uLmXRdf+IfhPxPF4d8C/DJ/hzq+neDbPTdQ1H4gXuta 7JbeHvaf2E/2OE/Yc+Ct78GY/wBob9or9pdb3x/4t8ef8LB/aa8f/wDCxfH9mfFU1rIfDVjrX2DT hb+HdN+yfa4LIQt5ms6jreqlojqZtoOc179izxfpHjbx94n/AGd/2uPjj+zL4e+LPiq/8dfET4c+ CvC3wF+IPgxvHmuLCPFPj74e23xo+EnxDvvh34r8YTwLqnim1sb3VPAGr+I3vPFkngFPFOteJNZ1 t1IQjiItSqVqUsuajKDdKNDMqzy6s3VpuUJVKeGpRzPBKspYmm6s6VWOXVfa0sdlgpSdGcY8lOpD MruU4qbxOV0Y5lRSpPkqKlVxVeWVY/2bVCpChRr0JY2FqmDzDyXxB8X/ANuPQ/Af7Jf7OvirVPgh 4T/bV/aQ8RfFix8e/FfQ/CWteIvg38Mfh/8ACiLXPE3iLx14G+HV/wCLoNS8UeK9W8MXXgDw/wCC fCHiLxsbHSde8UXvijxVceI9J8Hal4a8QbGg+K/2p/gJ8f8A4e/s4/Fv486Z8fPCP7THgj4tf8Ke +M+q/Crwd4H+LPwo+Lnwx8OWXii80Txt4c8AnQvht8RvAHiDwtd6rrvhrVNO8IeBtX8La34Sfwz4 mufGMPjTS9T8Pew+Mv2IPBfi34SfDD4ex/Fz4/aP8Qfgp4vu/iR8Kf2mG+IcPi/9oLwn8SdVj8QW 3iLxZJ4h+ImheMPBviKw8WaZ4s8TeHfEfw38SeBtU+Ek/hHWX8JaX4C0jw/pXh2w0Wh8M/2M9Z8O +PNS+M/xf/aZ+Mnx/wDjrF8P/Evwx+HXxH8V6F8G/Cem/A3wp4vm0278TSfCP4a+Bvhlo3w9tPE/ iTUdC8N6l4k8W/EHQviJrmrv4d0rQ2ubbwXFJ4VlmXM6mObafO8e5OmrU8TSq5a6WFp5fTvReDqw zBxqRs8t+rwg8c8VilOWSSlK1PCRg3HkWFjBVfeqUalPMZVatXHzvWeKhLAezhUXtMwVacZ4NYSl Z5tiPzf+Cnxd/wCCkXxK0r9jGTxD+1l8L9PuP2yB8ZLHxLceH/2bPDsL/CTw78ItO1DxDoPiL4YJ qnifU4NU+I/jHTdBl0vxk/xGi8WeAbC719tR8K+DNOi8Ox2HiD9Xv2MPip41+M37OHgTxz8RrnSt Q8cjUviF4M8U6xommHRNM8Q6v8MPiX4w+Gd14ntdD+1XyaJ/wk58IjX5tGhvbu20qfUZbC1uJba3 ic+U/C79gHw58KtA/Za0TTv2hf2hvElx+yZ4o8da74H8QeKF/Z9bWfF+h/EPSr/R/EXw/wDiFF4b +AHhvQLzwkbPUbgWV94P0PwV48tZfLkPjaXaQ30J+zv8BdK/Zx8Bah8OdA8dePfHPh+48ffETx3p D/EE+BpNR8Lr8SPGOseOtV8I6Lc+BvA/gWK68L6T4g1/V5dDl8TW/iHxZHbXhttW8VaulvaeRrey qU1KDhdzjJxvJunHDeyhGpKDqx5licTGUW4wnPB1pVm7ZfPEZvmlOFRxkndwcVK0VCcsS5SlDn5J NSoUHF+9OFLE0IwSk8fGj7tRRRUGoUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfm34FH/G3P 9po+n/BPX9jAfn+0N+3D/hX6SV8d+F/gl430n9vn41ftF3celj4c+Ov2Tf2cfg5oMseoB9abxl8M fi1+034y8Ux3el+SGttNj0b4q+EmsL/z3F5cyahAIozZFpPsSlR93A4Km9J03m3PF6OPtuIc5xNL mXTnoV6VWPenOElpJF4t8+bZrWi+alVhw2qVRO8Z/VuCeF8DXUWtH7HF4XE4aovsVqFSDs4tBRRR TICiiigAooooAKKKKACiiigArmbLxp4P1Lxb4g8Bad4p8PX/AI48J6P4b8Q+KfB9nrOn3Pibw5oP jG48QWnhLWtc0OG4fUtK0vxNdeE/FFvoF/fW0Ftq03h3Wo7GWd9MvBD01fmz8Fh/xtV/b7P/AFaX /wAE7h/5e37dlVFKV7u1oyfzSul89gl7tOpPrB0LLo/bYvD4d/cqzkvOKT0bP0mor5D/AGgv2g/j /wDCXxVpOg/Cf9g749/tTaHf6FFql/42+FfxR/ZG8D6HoeqPfXtq/hm+034//tE/CHxVdapDbW1t qUl5pWgX+hNa6jbQxatJfRX1pa6fwm+O3xy8ffD34j+LvHn7E3xv+Bvi3wdaXdx4Q+FXjn4k/sse J/Fnxbnt9HudRgsfCGu/Cj4+fED4e6DcX2oQw6BBJ8RvGPgu0i1C7huru5t9HjudSgzUk6VaslLk oRqSmnCUaslTqeykqNCSVbESctacMPTqzq0/31KM6K5ynFxqUaT5eavKnGDUoypxdSn7WLrVot0c PFR0qTr1KcKVT91VlCr7h9U0V+bui/tlftialrGk6dqX/BIv9r3w9p1/qdhZX+v6j8fv+CcN3p+h 2V1dRQXWsX1po37amp6xdWemQSSXtzb6VpuoalNDA8djZXd00UEnrXx7/aM/aH+FPjW38NfCz/gn 9+0H+074bm0Ky1Sb4ifC/wCK/wCxz4K8OWup3NzfQ3PhqXSPjz+0n8JvGsmp6dDa213c3lv4Yl0O aHUraOx1W6uYb6G1qXuRpSeqrVJ0ocvvyUqdP2snVjDmlQpuOkK1ZU6NSp+5pzlV9wmPvSqRWjpU 4VZOS5IuM5umlTnK0atRSV50qTnVpwtVqQjTamfZFFfK3w6+O3xy8YfCL4g/EHxf+xN8b/hN4/8A CJ1X/hE/gP4t+JP7LGvePfip9h0e11GxPhTxR8O/j54y+EehjWtQnm0Cy/4WD8RPBxttQs57rVBY aPJa6lP4l4U/bC/a717xR4c0PXf+CTf7WvgjRNZ13SdK1jxnrnx4/wCCdup6L4S0vUL+3tL/AMTa vpvhX9svX/E9/pmhWssuqX9l4c0LWtdurW1lh0jSdRv3t7OalFuusOuX2jjQmpOUVQtiL+zTxLaw 0ZRs/bwdVTwun1mNK6vLklRdb3uRSrRcVGTrXoW57YdJ15Rlf9zKNNxxGrw7qpM/Raivjf49/tGf tD/Cnxrb+GvhZ/wT+/aD/ae8NzaFZapN8RPhf8V/2OvBXhy11O5ub6G58NS6R8ef2kvhN41k1PTo bW2vLm8g8MS6HNDqVtHZardXMN9Da6Xgr4//AB78S/Bn4gfEfxJ+wr8d/h18RfCd3Nb+FP2ffEfx O/ZL1f4hfFKCO102eO+8K+LPBX7Q3if4N6Jbzz3t5ZJH4/8AiV4Qu0n0i8kltktbjTZ77NTTpVqy U+SgqkppwnGrJU6vsZexoSiq+Ik56040KdSVWl+/pKdH94aOLVWlSvHmrSpxg1ODpJ1Ie0i6tZSd GhFR0qTr1KcKU/3VWUKvuH1tRX57eBP2uf2s/FPjTwt4b8Uf8Eq/2rfhn4c13XtM0rXPiF4m+Of/ AAT51rw94K0u+u4re98Ta3pHgX9sLxV4z1LS9Ggd769svC3hrXteuIIXi0zSb+7aK3k7T44/tK/t IfDDx7c+FPhl/wAE7f2i/wBpHwtDpum3sPxP+G3xc/Yt8HeF7y9vYmkvNIh0X43/ALTnwt8eR3mk OFgvLi58JQabcSOG029vYg0gqXuRpSeqrVKlKHL78lKnTVSTqxhzSoU3GSVOtWVOlVqXpUpzqxlB TH3nUitHSpwqy5vcTjOp7NKnKfLGtUUtZ0qLnVp0/wB7UhGl759q0V8q+EPjt8cvEPwO8ZfE/wAQ fsS/G/wH8TPDl5f2/h39m7X/AIk/sr6p8SfiDb2sOlyWt/4e8Y+Efj74i+CGk2+pyX17BbReMvil 4avIJNFvWvra1hudLkv/ACDwJ+1z+1n4p8aeFvDfij/glX+1b8M/Dmu69pmla58QvE3xz/4J8614 e8FaXfXcVve+Jtb0jwL+2F4q8Z6lpejQO99e2Xhbw1r2vXEELxaZpN/dtFbyWoN144dOPtJRw8lJ zhGhbEq9PmxUpLDRlFf7xGVZSwj0xSovQlySouu+bkUq0XFRk618Pbnaw6TxEoyv+5nGk4YnX6vK rZ2/Qmivhz4zftPftM/Dj4haz4R+HX/BNz9pT9oPwlpsWmvp3xV+Hvxi/Yg8J+FPEMl7p1teXkOn aF8ZP2pvhr8QbR9Iu55tJvG1nwdpkVxeWc8+mve6bJa3tx3WkfHb45ah8ANb+LF/+xN8b9C+K2mX 8trpv7Ll98Sf2WLr4p+IrVNVsLCPU9N8b6T8fNQ+AVpazWN3da2kOtfFzS79LHTLq2ktE1Waw0+8 yjJSpTrJS5IRUpKUJRqtOpGlaFCSVapLmmm4U6cpqmpVnH2MJzjo4uNWnSfLzVZRjFqUZUk5U3VT qVot0aMVFNSnWqQhCpajKSqyjB/VNFfAfw0/av8A2qvGnjzwv4V8Z/8ABLz9qT4PeFtc1SOx1v4m +Mfjb+wP4h8MeDLJ45GfWda0X4a/tceN/Heo2ULokT2/hjwnruqM0qNHYOiyMl34tftT/tQ+APiF 4j8I+Av+CZv7Tnxz8JaNPaRaP8VfAvxn/YU8MeFPFsVxp1peXFzpGhfFj9q/4ffEGwisbu4uNKnT xH4P0WeW7sLie0huNPltLy4p6cl/+XnteW3vW9j7Hn5+W/sr+3h7L2nJ7flrex9p9Xr+zle85pf8 u1Tcr+6mqrqKPI5WVVp0pe0jTc5Uk6bqqCq0nP7vor5W/wCF7fHL/hnv/hbn/DE3xv8A+Fs/bja/ 8Mq/8LJ/ZY/4Wt9m/wCEiOj/ANp/8Jz/AML8/wCGffsp0j/irBD/AMLh+3/2QRYGzHiLOjDzn4S/ tT/tQ+P/AIheG/CPj3/gmZ+058DPCWsz3kWsfFXx18Z/2E/E/hTwjFb6deXlvc6xoXwn/av+IPxB v4r+8t7fSIE8N+D9buIrzULee7ht9NivL22qMXKrOinHnhJRblOMaTbpxqpwryaozjyzSc4VJRjU UqMmqsJwjLko0vavm5bVHZRlKr+7nKEv3MU6124t017O9WDjUpKdOcJS+76K+EPi1+1P+1D4A+IX iPwj4C/4Jm/tOfHPwlo09pFo/wAVfAvxn/YU8MeFPFsVxp1peXFzpGhfFj9q/wCH3xBsIrG7uLjS p08R+D9Fnlu7C4ntIbjT5bS8uO5u/j/8e4PgBp3xYg/YV+O978VrzW20y7/Zdg+J37JcXxS0nTV1 W9sR4ju/G91+0NB8Ap9NextrbW1tNO+Ll5rgsdRtrZ9KXVIr2wtc1NSoqulLkfsfdcJxrfv5xpwv h5RVdcspp1r019XgpVMR7KnCco6OLVT2Tceb95qpwlT/AHdOdWX76MnSV4wkqd5/vajhRpc9apTh L62or4c+DP7T37TPxH+Iei+EfiL/AME3P2lP2fPCWpRam+o/FX4hfGL9h/xZ4U8PSWWm3V7ZQ6jo Xwb/AGpviV8Qrt9YvIINIs20XwdqcdveXsFxqT2Wmx3V9b43xL/aw/aq8F+PPFHhXwZ/wS8/ak+M HhbQ9UlsdE+Jvg/42/sD+HvDHjSyRI2TWtF0X4lftceCfHenWUzO8aW3ijwnoWqK0TNLYRo0bPUv clSi9XWpzqw5ffio06ipyVWUOaNCo5NOFGs6dWrTvVpQnSi5qY+8qjW1OcIS5vdbdSMpxdOMrOrB KDU6lJThSk4wqShOcIy+/KK+VdW+O3xy0/4AaJ8WLD9iX43678VtTv47TUv2XLH4k/sr2vxS8OWr 6rqFg+p6l431b4+6f8Ary1isLS01todE+LmqX7WOqWltHZtqsGoafZ8N8Gf2nv2mfiP8Q9F8I/EX /gm5+0p+z54S1KLU31H4q/EL4xfsP+LPCnh6Sy026vbKHUdC+Df7U3xK+IV2+sXkEGkWbaL4O1OO 3vL2C41J7LTY7q+t6UHKrWopx56Epwm3OEaUnTpKrJ0a8pKhiIuDtCdCpUhUq3o05SrJ01Lko0qd V83LUipRSjKVVJ1JUrVKMU61KXNFtwq04TVPlrOKpSjN/cdFfnt47/a5/az8LeNPFPhvwv8A8Eq/ 2rfiZ4c0LXdT0vQ/iF4Z+Of/AAT60Xw9400uyupILPxNomk+Ov2wvCvjPTdM1iBEvbKz8UeGtB12 3gmSPU9JsbtZbeP2Dxf8dvjl4e+B3g34n+H/ANib43+PfiZ4ju7C38Rfs3aB8Sf2WNL+JPw/guot Tkur7xD4x8X/AB88O/BDVrfTHsrKC5j8G/FLxLdzyazZNY211Db6nJYZqSdFV0pckpUIqLhNVr4i 6pt4ZxWIjGNv385UlDDaPEypJq+ji1WdB8vOo1pOSlF0bYe3OliE3h5Slf8AcwjVc8Tr9XjVs7fV NFfFXwN/aV/aQ+J/j228KfE3/gnd+0X+zb4Wm0zUr2b4nfEr4ufsW+MfC9pe2cSvZ6PNovwP/ab+ KXjyS81d2aGzuLbwlPptu6FtSvbKIrI3zz+03pVn+xNdX3xr+Cf7SsPwq1j4i+KtTvV/ZO+Lp8df Gj4VftD+P9Wnn1fVdB+Cfw18LReKfj98O/il4hnmubwRfs2aX4p8Jx3N1qXizxV+z9461A3N+jqS jRdKVZ8tGrF2qU/9onCo6qpU41MNQ58S/actVRp0KVfHTqPCwoYKvTxXtqSpxlW9pGinKtSl/Dmn RjOCpOrUlTr1VGh7ilTbqValLBwgsRKvjKEsNKnP9W65rwh4y8I/EHw7p/i/wJ4o8P8AjPwpq32v +yvEvhbWNP1/QdS/s++utLvvsOraXcXVjd/Y9SsrzT7ryJ38i9tbi2l2zQyIvn/7P3xG8efFr4Oe BfiJ8Tfgv4q/Z78deKNFTUPEPwh8Z654a8R6/wCD7xpJYxa3GseFb270+7tryFI9R0/7bBoniGCx u7e38T+GPDHiCLUdB0/5F/4JHjH/AAT2/Z+9x8VT+fxs+JBq6sJ0a9WhUUVOi+WajOFRKalOMkp0 5ShJJw3jKSfRmVOrGrGlUptuFWEpxbjKLaXJyu0knaSndXWqs1dM/R+iiipNAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKAOZg8aeELrxhqnw9tvFPh648e6H4c0PxhrPguHWNPl8VaV4T8T alr2jeHfE2o6AlwdUs9B13VvCvibTNI1a4tY7HUb/wAP6zaWk8s+m3aRdNX5t+BR/wAbc/2mj6f8 E9f2MB+f7Q37cP8AhX6SUqfv4bDV3o67x94raP1TN8xy2Nnv78MFGpLtKcktEiq6VLH47Bxu44SO TuM38U3mXDWSZ5U5ktF7KtmtShC29KlCUvecgooopkhRRRQAUUUUAFFFFABRRRQAV8c/Dj4I+OPC /wC3L+1V8f8AVI9KHw/+L3wG/ZG+Hng+W31ATaw/iL4M+JP2oNU8apqWmeSpsbOK1+K/hFtMuvPl F+8uoIEiNk3mfY1eaaJ8X/h74i+K/wAQPgho+vG7+Jvwu8IfDnx3448Of2Xq8C6L4W+LN/4+03wF qQ1e4sItE1FtbvPhj41iay0vUb2+0waQkmq21jHqOmPeVFtXsr3i09L2XV/d16BLWnOL0hL2PO+3 JiaNSnq9FzV4UoL+ZyUF70kel0UUVIBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABXz/8ADv8AZg+C/wAM/iL4z+MWi+F59b+MPj651E+Ivix4813XPiB8RF0O /wBQk1GLwL4d8U+L7/WNS8F/DTSJXRNE+GvgyTQPA2meSl1BoP8AaMt1e3H0BRRH3ZqpH3aip1KS mtJqlW5VVpqS1UKqhFVI35ZqKUk0gfvQdOXvQc6dRwesHUpNulNxejnTbbpyteDd4tPUQ8gj2r5A /YI+Cfjb9nX9kz4T/Bv4ippcfjLwcvjgaymi3/8AammA6/8AEjxh4osDa33kweeG0vW7Jpf3KeVO ZYcHy9x+wK82+EXxc+H3x2+Hnh/4q/CzXj4m8CeKf7W/sLWzpmr6Ob3+w9c1Pw5qf/Eu12x0zVbf 7NrOkahaD7VZQ+cIPtEHm20sM0isuZvq0k15Jyt6bv1+QmlzRd9UpJLum4czt1taPpfzPSaKKKYw ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAPjvwv8EvG+k/t8/Gr9ou7j0sfDnx1+yb+z j8HNBlj1APrTeMvhj8Wv2m/GXimO70vyQ1tpsejfFXwk1hf+e4vLmTUIBFGbItJ9iV5rYfF74e6n 8X/E/wAB7LXjN8U/Bvw78FfFbxF4Z/szV41sPAfxD8R+OvCfhHWxrMlgmhXTapr3w28ZWTabZ6nP qtiNKS51CytbTUNOnu/SqUNKFCEdaMHjPZT3Uva5ljcRibSWkvZ42tiqLt/DdJ0ZfvKcyqzc8bi6 1RcuJqxytYmnrF01hshynBYBum/eh7fKcLl2KXNpWjiFiadqNemkUV5j8NvjJ8N/i9oHiTxX8PPE sPiLwz4U8a+Ofh9rHiCOx1Sw0ceKfhtrt74Y8cWmm6hqllZW2t2Ph3xHpeq6Fea5o0l/ob6ppWp2 dtqM81hdLF85eEP2/fgV4x8WeDvD8Wi/G/wv4b+JevWvhX4WfFzx/wDAb4p+A/g58SvE2oxzS6Lo 3hfx94p8M6ZYRS+Klt5R4E1HxFDoGifEWQ2kPgDVPE0up6Ul84fvZ0qdP3514YapRjH3nVhjVGWC lTt8axqlH6ny3+tOSVD2jaRM37ONac/cjh6mIpV3LRUamDlUjjIVb/BLCSpVVi1K31b2VR1+RQk1 9t0V5t4g+Lvw98K/Er4d/CLxD4gXSfH3xY0zxrqvw80i707VVtPFEfw8t9GvvFthYa6ti2gLr2m6 ZrlrrEPhy51ODXtT0Sz1zWdK0690zw5r11p3pNC1jGS1jLm5ZdJclSdKdns+SpCdOVtpwlF6poOt uqs2utmrp281qu61QUUUUAFFFFABRRRQAV+bPwWH/G1X9vs/9Wl/8E7h/wCXt+3ZX6TV8veBf2f9 U8I/td/tFftKT+ItPvNH+Nvwc/Zo+GOm+GIbO5i1LQr34Ea9+0Hq+qape3zyta3dr4gj+M2mw2EE EUc1o+iXzXDSLcwbbg0ua7t7kl6tq1vxFPWjWivik8Lyrv7PH4StP7qdOctd7W3aT+oaKKKgYUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAIeh+h/lX5w /wDBJAY/4J7fs++4+Kh/P42fEg1+j55BHrXzF+xt8AtT/Zf/AGbvhv8AAvWPENh4r1LwMvi1bnX9 MsrjT7HUP+Ek8deJ/F0Jhs7qWaeH7NBr8VnL5kjb5reSRSEdQJSfPJ9HGCXqnO/3XXrfS9naXfmg +ijUv6t0rffyv7nfofTtFFFUUFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB+bngUf8A G3P9po+n/BPb9i8fn+0N+3Ef6V9Nfte+OPFvwy/ZP/ab+I/gGKSfxz4B/Z++MfjPwdFDGZpX8UeG Ph54h1rQRHCATK41SytSsQBMhAQAk4rJ8P8AwB1TRf2y/it+1DJ4hsJ9G+In7N3wL+Blp4VSzuU1 TTdS+EnxJ+P/AI61DXri/aQ2k9jrNr8Y9NsLO0jhW4tp9EvZZpHjuYFT6VvrGz1OxvNN1G2gvdP1 C1uLG+s7mNZra7s7uF7e5triFwySwTwyPFLG4KvG7KwIJFefmGFrYvh+tltGoqOLr4HiDDQm5Tiq NXH5tndfDVJTp++l7LF4etzU3zxjJJWqRaXfh8TRw/EtTM6tFYrBQxXCmIdJ8rjiqWWcKcLYHG0e Waa/3vL8ZhJKpDllKnKSU6Uoyl8df8E5vCPhrwP+wN+xp4c8Izpe6Hb/ALNHwZ1GHVVcTSa/feIP AWh+INa8TXlyCzXmpeJtb1TUNf1S+kZ5r7UdSurueSSaZ3b56/b+0L42aR4r+C3xa8T/ABC8G+Iv 2NvAP7QP7POrfEP9n3RPAtz4U+LOreKZ/il4Q0H4a+NP+FyX/i3xTp/jHQfAnxf1Xwd49uvhFonw 5+G2s+KLXQ009fiPqSW03hPxZ9P/ALLf7Mi/AL9m62/Za8VaxpnxI+GPhA+N/APw8tNR06YSwfs+ anqepp8Pfhl4sivJrmLWLrwL4G1K1+HM2qRMkOvaLoOn6jcW9ve3d3CnOeEv2AP2ffCfifwd4hkv Pjj440z4b6zYeJPhp8Pviz+0l8evi58L/h/4j0hWGia/4f8AAHxH+IXibw/cat4aZvN8GXfiG11x vAU0cE3gYeHJLa3aL6DMMXSxvEDzejTeFw0s7wufYWlaMqmHg8w/tF4Sth4ezoxxOEpOlSpOjVXs cbGVbC4nA18JhMaeJgsPUwmTrLqtV4vEwy3EZRiK7vTWKlTwywUcdQxD5qsYYyrGeIlOdGM/qs4x r4bFRxGJwJ4N/wAFa57jwz8Gv2bviv4dLxfEj4U/t+/sR6l8OZrZil/cX3xH+PvhH4HeONAtmX53 t/Ffwo+KXj7w5qlv80c2m6jcmRCIwV/VGvlX47/s53nx5+Ln7MXiPxJ4hsIvhP8As9/EDWvjbqHg H7BPNqHjn4xaNoEvhz4N6hfX5nWyg8L/AA8k8SeL/Gr6e1tNe3vjnT/AOpW89tBoV1HdfVVefhl7 LBYijN3niM/zDNIJXahhq2S8NZTThNyd41Xicjxlb2cV7JYatha0W61evGHZW9/F0aqd40smwWAl KWklWo5rn+PnTgldSoRo5ph5xqOXO8TUxdJwjCjTnUKKKKACiiigAooooAK800T4v/D3xF8V/iB8 ENH143fxN+F3hD4c+O/HHhz+y9XgXRfC3xZv/H2m+AtSGr3FhFomotrd58MfGsTWWl6je32mDSEk 1W2sY9R0x7z0uvzZ+Cw/42q/t9n/AKtL/wCCdw/8vb9uyqik73vpGT07pXXyvuEvdpVZ9YPD27fv cZhsPK+z0hWk1Zq0lFu6Ti/pr49ftcfs3fsvx6bN+0B8XPC/wst9X07UtWsbrxO2oQ2kml6O0K6n fzXdpY3VtZ2lkZ4vPnvJbeNQ27cVVyu38Pf2k/gb8Vfh54l+LHw9+IujeKPh34PbVl8TeKbGHVIr DSDoWlw61qwuY7ywtrw/YtLuIb2Qw20oaKRfL3vlR4b/AMFMv+Ue/wC2Z/2bl8Vf/UU1Gvtqz/48 7T/r2g/9FLUqMvY1W5RdV80aMlFqnTk5c1OVWm5uVZQprknGFWg6k/3kZU4r2TqXKp4ZpS9nOVX2 0XJc8o0I4dTVKpyqNOVSeI5oylTqqnGHI41HLnj8WeBv+Ckf7CPxI1rQfD/g/wDal+Emo6p4q1mP w34ZivPEP9g23iHxJNfyaVb+G9F1HxDBpWm6n4iu9Vik0uz0Kzu5tWvNTjfT7Wzmu1aEfblfgH8F PDf7VX7Rv7Dnjn9lvwz+z/8AC3Q/hd8VfF/7WHw6uv2gPiR8YodUttE8LeJP2iPi9Y6n420H4MeH vAWqa7rvjbw99qnvvB/hzV/FnhDTH8Q6dp2o33jHSYIl3/Un7TXiDUPGnxRsPgb8M9L/AG+/jFrn we8D+GpPib4e/ZY+L3we+AHgfw7eeKIJbnwlqPxM+Lfj74gfBvxzrvxD1rSNMm1Sy8E+APHHiHSr PRp7HWPG3hjR7fxBo2papEainRw81TnzYiceS7fM6bw08RVdTD+z+sYZ0FTjDnrxjTr1MTCF6EcN iaqlRfPNOcLUoVnWSStSlDE4bDYbkxDqfV8V9blXrP2dGXPho4KUpe3ljcJSf6sV4n8av2gfh1+z /beBb/4knxhaaZ8QviJ4N+Fui6v4c+Hvjjxro+m+LviB4j0rwh4Qi8Yat4Q0DWtP8D6PrXifXdH0 K28Q+LbjR9D/ALS1G2tnv1dzt/Nb4bftV/HjQf8Agm/8VvidrUniSx+MPw6+OPxW/Z58Oa98ck+H viLxZ4HtLD9p26+A/gzxt8bJfhNr2p/DjxZqPwr8PappviT4gaj4V8RS6P4pt/Ct/e3WrpPqN/fj g/26P2cPGnwU+FXwS8Yad+158dfG8mp/tm/sIaH8V/Dfx68X6P448MfF3+1v2u/gwIrvwl4dh0TQ dL+EfjbTdcjs9d0ay+EFp4U8EzaLaa3omr+CNSim07U9C1goyxmWUedfVsfmXDWFjXVpOtQz/GZf GHsowlNQl9Tx1FyrS54Uq+Kw3saeNjTxiwyk3Glj24v6xgVn1KtS96PscRkX1qjieZ1Iwco/WsNV 9jDlh7Wlh631ipgOfDyq/ujXifwb/aB+HXx1uvihYeBD4wg1P4N/ES5+FvxB0jxv8PfHHw41jR/F 0Hhzw74vhih0nx5oHh7UNU0fU/DHizw9rujeItLt7vQ9Y03VLe506/uELbfknVtD8aftV/tPftCf DfXvjZ8XvhD8Lf2bYfhd4a0LwB8EvGc3wu8T+O/FfxC8DW/xDvvix4y8d6HbL44vPC9jFqtr4H8D eEtF1nRvCVxrXhPx9e+MLLxfNJpVn4b8u/YD8E+MJvEv/BUb4X+Nfjj4h+IevWP7Xtj4Jj+M2gDw /wCF/iVHpJ/Y5/Zih0C51i68O6VD4Xtvih4W0a6stL1zXdI8N6Vp2o6/pkmtjw3pcl5NpsGeHk60 8TFr3oZJi80oULpVKjoZxkWX0pVKnvQgqlLM5VfY2bUMRhJ1K1LEU8VgYaVIqCo+97s8dhsLUrWb jH22Ax2Mkow0nPkeHVOVRuMva0K8KVCth6lLGn650V+NH7EHwb/aU+Nvwxs/iT8Y/wBuH4+yweB/ jb8dvB/wk0H4eTeCvD0jeD/hP+0l8R/Bmnah8ddZ8Q+DPFT/ABs8Y+I9E8LR+HdVTU7DRfAmkeFP sUOheDbfxxb3XxAvv2XrRxSjGXNrNuSg01ONNxhKlKp9mNSak+elGU/ZOPLKXM3GOV3z1IOP8KUq cp3XLKrTnOnVVP7UqcJQSjVlGCq3coRdNRqTKK+QP27/AIz+N/gJ+zF428ffDe60XSPHF54j+FHw 18N+LPE1gNV8MfDzUfjR8XPA3wfj+KHiXSmntItV0D4ZL45fx3qul3N5Y2Wp2nh+Swvr6ys7ie6h +Ovjb8M/iX+wpoHw0/aG8E/ta/tMfGDV3+Of7Pvwv+L/AMOf2gviDpfxF8G/HnQ/jt8ZPBHwb1iT wz4RTw3o2j/Bz4kaBdeOo/GvgWP4F2Pw/wDB095oT+F/EPg7VfD2pFtLmj+9rUqb9yFbH4TK4VXr zY7HVMNSo01TjefsaTxmEeKrWuliqMcJSxtSGMhhLmnGlKcf3lSNHE4j2StF+ywtP2krzm4wVWul Ujho39lzUarxlbBUnQqV/wBI/jV8ePhn+z74Z0vxR8TNV1q1t/EPiOw8HeFNB8JeC/GvxK8deNfF 2p2t9f2XhjwR8O/hx4f8V+OvGGuSabpWq6vcWHh3w9qMun6HpOr69qX2PRdJ1K/tbPwg+MvhX42+ Hr7xJ4T0H4seHbTTdVk0W80/4v8AwO+MnwH8Qi+htbW7d7Hw38afAvgPW9a0ryruJI/EOhWOp+Hb i6S6srfVpbyxvYLf85f2+fgFN8Sf2qv+CeusJ8cv2gvh8uu/H3x14ZXSfhp4+sPDWjaI2l/slftL 64fEeg2dx4a1SSx8UaiLc6NqmqSXFzHdaFcXNitpC8i3Cfpp8MfAb/DTwXpPg2Txv4++IjaU16T4 u+J2vQeJfGmp/bb64vQurazbabpMN2tmLj7HZbbGEw2MFvAxkMZkZ0lelWnW0m604YeEdOWEPY2l Ul76qOSdWo7eytGrQhZSw9V4hVvdq4enS1i8NTrV5S1vKpVxlO0F7nJGDoUoK/tG5RrTbcKtJUO+ qnqF7Fpthe6jPFeTQ2Fpc3s0On2N5qd/LFawvPJFZabp0Fzf6hdyIhW2sbG2uLy7mKQW0Ms0iI1y vy88B+B/H/7Y3ir4/wDj/wAVftI/Hv4R2Hw2+O/xJ+CHwl+G3wN8Z6f8PbD4bw/CbUYfDreOvHVo uhap/wALS8afEHVIpfHtro/xPj8TfDSz8A6z4M03TvARlfW9c8R5OU51KlCkm6sMDicwm7RlyYfD YnAYOcoQlUpRq1XiszwdOnRlVoU5+0k6mIoQi5q7Rp06deq0qVTHYfL4ayXPisThsfjadOUowqSp U/qmV46tUrqlU5FR5Y06tapRo1Psb4ZftN/Bn4q/BnU/j9o3ie58LfC3QL34haf4r8QfFbQde+D8 3gq7+FPibXvCHxDj8caR8TNO8Lav4OXwnr/hnXLTV5vEVlp0FvHYS3jSfYyk7eZ+Af8AgoR+xb8T fF2h+AfB/wC0V8Prnxr4rvLWy8E+FtautR8Ia58Qjevstb34baf4w07Qbj4kaNKxjA1/wMniDQ1+ 0WhfUFF5amb8kfgyl/rH7HH7L/h34y+LPDvxI8E69/wWJ+PPh34/eMNM0230fwD4/k0n9rT9qS7+ H+oazpMNzeaXp3h/xd+0doXweU6Cbq40O51/UNM8Of6Rp94ltN+7nxT+GHwe+IV38L9a+LGgeHdV vfhX8UPDvxB+FWq65fSaZceF/inDban4Z8O6noN5De2Dyave2viTUtCg0p5Lm21mPVX0+fT73zY4 hvS5KjpYjmU8G81wOAqxo8zqyoTy7h7NMbiMNVqwhz4mWHz3kwGAr4ahKVXD4f6xiKcMffB5Ynnp TxmEiksXTweb4rCzq2dFVKGdcS5JluGxsKcnKkvrHD3tcyxNCrWUMNjPa4ahUnh/Y1/EvHf/AAUI /Yt+GHj/AMU/C34gftFfD7wn4+8EPYJ4x8Oaxd6hb3PhZdUt2u9PuNfuf7PbT9Ksrq1jmniv727h svKt7p2uALW48rufHH7YH7Lnw30H4U+LPG3x6+F+g+EPjlqmjaL8IfGU/izTLnwZ8QtR8RXel2Hh +Dwz4usJrvw5fx65e63pNrpF0upraajcajaRWc8zzKD5L8H/APk/79tj/sjX7GX/AKM/aPr80vi7 8Ofh5448H/tO/AuTQ9M1z9nDWP8Agr1+y/4MsvB0KhvB8Z+Ia/s6a1+0B4Z8Pxwbbazsbn4u+Kvi DqHiC00t449M8e6x4tRRa6pFdxQ4UZTnisuwPIq1fGY7I8PKUJeyi6eZcV8O8M17U5KtKgk+IIYi lipzq0qFWhSwtWjXeNhVo6VeSNLHYjndKjhcNmNVKcVUlzYbh/M86pWnz0Y16sZZd7OWCjGhLFYe WJxMMVhfqbhX/ZXxx+1V+zz8Nviz4I+BXjv4r+GPDHxc+JMthb+A/AmpyXseteKrjU3vksoNIEdn Ja3M839mahIYftKyRW9nPczLHbxmWvoGvw78JePfF+nftP8A7D37K/xh1u81740fsyfHf4q6EfFm ruDqfxh+CHiH9kf4+H4J/G2SQhRe6p4j0TRtS8G/EW5iSOKP4ueBPHvkQQ6XcaQ9z6F8O/gb8VPj p+0f+3lo3jL9sr9qnR/ht8K/jt4a0H4PeAvh5470zwFJ4C1Pxj+z58HvijreqT+LtE0FPEPjLQtL 13xvLb+C/h34pmv/AADotnDfrr2g+LpdTifTNJyhH+Hz16f1XFZnDEKMaPtMBCpl6w9L6pUqSnQz CUMdGlVw9evH2WNjLC43+zpUq8qcRUm5xqclGpTeHoVaHNOryYqUsTTr1IYlU6ca2CcqMMTQrwoJ 1svqRxWF+u+0oQrfrR4k8Q6L4R8Pa94s8Sajb6R4d8MaNqniHXtWu2KWumaLotjPqWqahcsAxW3s rG2nuZmAJEcbEAnivB/2S/2s/gj+278DvC/7R37Omv674r+EHjW71y18KeKNe8E+MfAUmvL4d1a6 0LU77TtE8c6J4f12bSk1axvbK21Q6ctjfSWk7WU88abz80+CvDHjT/goH/wS103wD8RviVqng/xj +01+zXffDvx/8U/COi6VDrcMninSLzwf4u8T6RoY+y6LYarr2njUbgW1skGnaZd6m5sLeO3toLcf b3wa+EfgH4BfCb4cfBL4WaDbeGPhz8KPBfh3wD4K0C0GIdM8OeF9LttJ0y3Ln557g21qkl3dSlp7 y7kmurh3nmkdrUPZ1syhWnGpCl9QpZbKgpRjVqe1zP8AtWtXdWKn7KNOnlMcDS9lRnJ4jGVK0v3N Ok1NydPAOnBwqTnj55jGq4y9lThSy9ZdQo+zlyurVrVsxlia3PVpwhg6FOEP9p9rH0qivxY+Oehf tIa38Yfjx4w1Cf8Abe+JPw4tNfisvgN4u/YG+PPwA0fw18DtJ8OeE9D0vxbovxK+BPjj4ifDPW/i X8U9C+Jll4w1bWdH13w/+0XY63pVzonh/TfDOg3FtdeFx+lH7KfiaPxj+zP8A/EyfFW8+OT6v8I/ ANzd/GPUfC0ngbVPibqS+G9Ph1Txtq/giWOGfwbrHiHUorrUdX8KXEMNz4c1Ke60e5iinspEWKH7 /CvE39m1DL6nsZa1FDMaOKrU4zS96lUw6wsqdf2sYYetUqJ5XicypUcXVw1Vv3VdUfjTeJi6i+FV MJOhCrG/wtSliFyRjOVel7OpHH4fBVJUIV/f6+JNd/4KRfsKeFvFvi3wP4o/af8AhZ4a8SeAPEV3 4U8dWviDWZ9FsPBfiCwWGS90/wAV69qdna6B4ea1guba6nudW1O0s47K5t75rgWk8Uz/AG3Xwh+y jHHN8f8A/gpLFLGksUv7V/gSOWKRVeOSN/2Lv2WFeORGBV0dSVZWBVlJBBBpU1OpiKtNcvJRyzFY 9xd1KpUo5jk2ChTVT3lTg45lUnOXsqsuanCyS5lKvdVNSfNzPEUqSaatGEqOJqTbhZOUr0YKPvwS XMne6cfuHTNT03W9N0/WdG1Cx1fSNWsrXUtK1XTLu3v9N1PTr6BLmyv9PvrWSW1vLK8tpY7i1ura WSC4gkSWKR43Vjer+cD/AIXJ8WfAfhr4Zfsvfs3eG/jjqfwa+Kf7Zn7cvhrwjqn7MGrfs/aN8TtP +CPwN12TV5PhH8FvE/7SnxL+F/w08J6Nc+P9Z8aaJpmq6FrGq+K/C3wq+HGvaR8K9H0z7HYeL/Bv 2x+yVL+1j4S/aGtfCl18Ff24fDn7LPib4feKb3xJe/tsfF79kv4u6z8N/ilot/4ek8IP8OPHPwo/ af8Ajf8AGvXtD8e6Td+KbPxX4a8fQ69ovh/U9G8N6n4V1rw3a3eu6Vql0OTEqhVhzUKOLwWHx+HW J9ypThiMooZxGhitIxp14Rr/ANluNP2lR5xRrYeVKlh/ZYurnW5sO69Odq1XC4/G5fW9hFuNSeBz vF5HUrUItyn7KdTCTzJe29nCOVVaVaNariHPDR+2f+Gp/hfF+0Bpv7NV/p3xV0b4j67a6/deGtQ1 /wCC3xX0L4aeLF8L6JY+IfEEHhL4uar4QtPhp4mu9K0rUYJrq10XxRezLKl1bKrXNncxRfRUsiwx SSsGKxRvIwUFmKopYhVHLNgcAck8V8OfHz/k9L9gX/rr+1D/AOql06vqT4p/D9/id4L1LwdH47+I Xw3bUJbGYeLfhb4gt/DHjOw+w3cV4YdO1m50zV4raG98n7LfIbGQz2cs0KtGX3jCcqiw65LOvGDh OdlyOp7SUXWjSb92EINS9i6s3JwaVT30o3DllWqKT5aXtFyLVyjD2NOXJKS+OUqjl76hBJSiuT3W 5ZfwM+Mfhb9oL4S+BfjN4JsPE+meFfiDow1zRLDxpoF14W8U21mbq5sxHrXh++LXel3fm2sjfZp2 L+U0cnRxXq9fEX7C+seMPid+xV8N5/Hfj7xj4i8Wa1o3xE8M6l8RL3UbQeO7kaX488aeE9O159Xh 0+K0/wCEjs9M0+ykh1Eab5f262juXtX+ZG/OPVPFHxc+DP7N37b37NWu/tGftEeNv2sdB+O3hXwD +z54x1/x9pq+OfE1n+0lr1if2Rda8N39l4Wtl0vwRazXeqeCvjBcW2m3HnyfBn4v+IIX02zGLbSv Ne3xFPDUp1XyQqYCipQVTH1K+ZYLLsPl+GnWdGnPMK1TMMN9Ww0pQq4pe2dKHJh686SoR56OFqVq kKUalZUsbVmpOngKKwWJxdXMMT7JVZRwNFYSrDEVoRnGhKdBSu61NP8AfmivxT/aY8RftC/BLVf2 MP2J/BWu/tjfHiP4geA/jT46+MPxb+Eni/8AZq0b9p74hw/CGf4aWx8Jad49+P8A8Rfgd4H8Had4 l1b4pz634h1bwBcXHxO0jwp4UtNF8GR6Pb3GteL9E9a/Y3uf2rvDPx31vwV4i+Df7Znhn9ljWfhr qev2etftp/FT9lL4qeM/h58XNG8Q+HrPTfC3gbxv8GP2kvjf8WPGPhH4g+GNX8Qavqlt8VF1L/hC 9b8F266H4tXTvFa+H9P1hCNSrOFOpGVBzzCGGxclOjRxKyz61HEVV9YjSqUqVavg8Rg8Dzw9tisZ TVL2NKFbC1cRm5yjQpVZ0pxqThhKlXDXhOtQ+uVadOnSl7KVSEq1CFWGKxiU/ZUcJL2kK1arCrQp fqlRX43+B/g3+0P8TP2s/wBrz4PX/wC2h8evD/7OHw31z4SeJNP0Hw/rGiw/GfUfFXxH8AP4lv8A wvZ/GC40CS78D/B7QJxHf2Hhjwfo9l4w1jVpYba/8d2XhjTb7w94n9g/bL8NfE74PfD/APZ0+N+n /tBfHe78D/steN/COpftNQ2GteEtI1L4y/A6WO20Dx14++I1t4Z8D6Ro17qXw6uTpfxY8T2/hfRP Demar4M0Hx9oNhpFtc61pslhlSkprCuo/Y/WcTgsPL2jVsPHF1PYyxGInG9Knh8NVcJVqsqihTws /rdWVKFOvGjo1K9dU4us6VDF1oKGrxE8PTdWjhqEH788TioJ06VNR/3q2GTnOSb/AEwor86fhlc+ MPjT+3l8X/iT4R+MXxMX9nn4BeD9B+Dl58P7HxHptx8JfiL+0Fr+l2/ivxdqVppf9jyXLWfwp8D6 v4MsJb7TdbNvqvj7xf4hsb8JceBPsj/otVRTdDDVpJweJouuqUvihRnXrRwlXmV6dSlj8FDDZnha lKdSEsFjsM5uFb2tKmm4+1rU4tTjRlTp+1i7wnUeHo1cRTj9pTweJqVcBiIzUXHF4XERScFGcvEL /wDaU+AulfHLQ/2Z9U+K3g7Tfj34n8Pah4q8M/CrUNUSy8XeI/D+kWq32rajoNhcrEusppdiwvtR h06W5ubGyP2u5hit/wB5Wb4M/aq/Z5+Ifxg8YfADwX8VvDHiH4zeALO61Hxl8O7GS9HiHw9p9nqb 6NPe6hBPZwwraDVYZ7CK4jnkiubm2u47Z5TaXPlfBP7dXwOu/jz+2N+y9oHhjW4vB/xV8Hfsy/tc /Ez4G/EB4GnPgL4xeCvil+xtqPgzXriKIpPdeH76Zrrwt450eGWIeJvh/wCIvFXhe4cWmszg8f8A An9qf/hOvjr+17+0Jb+B9Sg8efDf/gn/APAtviR8GEm+0eI/C3xk+EHxS/bgh8ffCWWWOMtc31p4 q0O70rRNUhgNt4i0a80XxLpIudK1nT5p+d4mhQy95hjJOFPDYXiDG42FOLlJYHLK2dU8NjcO3ec1 Snk86GZYaFKuqU8Rl9X63RnmmHwlLpeGq1Z+ywkVOpWr5Hg8L7SUYRePzLHZTg62CrSbhTi69HNH jMuryq0nKOEzClUw06eX1MZW/aeivxBb4WfHBv2MP+G9l/b7+Mq/tEf8KB/4ahXWv+Ex0c/sXiI+ Af8AhZ3/AAq1v2expB8BN8BP7O/4pI+Ldx+PP/CNf8VUPjH/AMJn/wATmvd7zxz8Qf2vfi38G/hN N46+Jn7N/wAO9W/ZD8B/tU+PfDvw51xfBfxV+IGv/E/W5NB074cQ/EOKyfxT4Q8LfCZtKvLvx+/g O48OeLtY17xZ4DtJvEmk6FFquj+Je2rh69HG4nLKkIxzLAYqODzDDOacMLVngc+zCMvrEFKGIp/V +GM9hJ4dVJQxOAlCUPq+KwGKxfFDEUKmEw+ZQnKWW43DTxeCxSpyU8RSp4/h/LH/ALNU5KtGU8Xx TkKpRr+zbo5gqtX2M8LjqWE+2/Bf7QPw68efF/4qfArRD4wtPiP8HNJ8G+IPGOmeJfh7448JaXP4 e8fXPiix8LeIPCHiXxLoGl+HvHehajqPgvxRpp1fwdqWtWFtf6Nd2tzcRSqiv7ZX4GJ4q+JP7GX7 Qf8AwVW8aW3xE179p3UP2f8A/gnP+z/8VvhVovj6fTtR+JWnWGgar+2p4r0n4bfEPxTpKaJJ4xij 17Sru60fxRrMFn4vuvCGqWVr4j1nXdVsH8TalyFre/t8af4C0L4u/Cn4N/8ABVX4hftKNpmjeMRq vxI+Nv8AwTOn/ZZ+MF1dR2uqX/gnVfgpof7b974N+G/ws8UWks+k+H/Evws8P6f8T/B2nz6Vr0ni vxlqVhqUHiHGg41vYpOSSo4V4mvODhCFXF43M8HC8U5wgqDyyvUx8I163sopvL55ouW+2IjKjWrQ tF81VxwdL2keapChk+Q5lib1Z+zupTzyhSwdSdGhGop0/rkcDapOP9EVFQWsk01tbzXFu1pPLBDJ Pau8cr20zxq0lu0kLPDI0Llo2eJ3jcqWRmUgmem1ZtO102nZqS000lFtNdmm0902iISU4xmlJKcV JKcZQklJJpShNRnCSvrGUVKLupJNNHj3gz48fDTx58Ufip8F9B1PXIfiZ8GYfCd/458MeIvBXjTw hKmg+OotXbwl4t8K6j4q0DR9H8f+C9buvDviTR7bxh4E1DxH4cj8QeG/EHh661KDWtHvrGH2GvzO s9b8Q6P/AMFd/FujaF4PvPFnh/xv+wX8IT8QvFljq2kaZbfBuTwV8bf2hbn4enXtK1i4tNR8VwfF +58TeMdM0c+C11i88K3fw9vLjxZY6fpev6PqD/pjSpe/g8DiXviYY1SW37zL83zLJ6s1Tfv0o16u WzxFOnUu1SqwcKlejKliKuldKlj8fhE7wwryuVOTVpOGZ8P5PnnJPpKVF5q8OpxUVVjRjV5IObhE ooooJCiiigAooooAKKKKACiiigAr5e8C/s/6p4R/a7/aK/aUn8RafeaP8bfg5+zR8MdN8MQ2dzFq WhXvwI179oPV9U1S9vnla1u7XxBH8ZtNhsIIIo5rR9EvmuGkW5g2/UNeaaJ8X/h74i+K/wAQPgho +vG7+Jvwu8IfDnx3448Of2Xq8C6L4W+LN/4+03wFqQ1e4sItE1FtbvPhj41iay0vUb2+0waQkmq2 1jHqOmPeVFvW3VNPS+nX003fRBLWE0/gfsud9PdxFGdK76XrxpJarmk4w15rPzH9o/8AZF+C37WG iN4Y+NZ+MGoeF59C1nwzqvhf4e/tL/tKfAzwx4l0LX1jTVdN8Y+HfgX8Wvhvo3jWG5ijECN4tsda ltLaS4trKS3t7q5jl67wB8AfAnw1+H/iL4Z+HNc+NN/4b8UHVP7S1Dx5+0l+0V8VPHtoNY0uHSLp fDXxW+J/xT8YfFHwYkFpAkukp4Q8Y6Gmg6kZda0NdO1i4nv5Pa6x7XxF4fvta1bw3Za7o954i0C2 0y813QbXU7K41rRbTWxdnRrrVtLhne+0221caffnTJ7yCGK/Fldm1aUW02yFGKp1aUYpUqymq1JJ KnVjUn7SoqsF7s1Op781NNSn70ry1KcpOdOq5Sc6DjKjUbbnRklGnF05vWm0uWnFxaduWK0sj5v/ AGd/2M/gd+yw90Pg1L8b7Cwu7fWLdvD3xA/ar/am+N3g+1fxD4gm8Va5qOleCvjf8ZviJ4S0XXdV 8QXN5qd94h0jRbHXbifUNSR9RMOpX8VxT+Kv7F3wg+LPj7U/iXe678b/AIfeLPE2jaL4d8fXnwQ/ aB+MvwQt/iRoXhwXqaBZeNrT4X+NPDEWpX+jW+pX1hpviqyGm+NLTSrj+x4fEa6VBa2UH1pRRNKp 7JVFzqimqSn70acWqilGEZXUYSVWqpwS5ZqrUUk1OScx9z2nJ7ntbOpye65tOEoyk42blGVKlKEv ihKnTlFqUItfJfwZ/YZ/Zb+AHw5+JXwd+F/wzuNN+EPxcuPEVz47+FPifx98TPiT8M79vGL6tL4y g0bwF8S/GXi/wp4NsfGV1rur3/jDTfBek+H9O8Valfz6nr9rqOoFblfG9e/4JX/sj+M9N0nQviJB +0B8SvD3hHVPD+t/DHQ/HX7XP7Uut2/wa1vwpq+na34a8Q/CHUv+FvW3iHwF4t0C90qzg0Pxxo+s p430XQzfeFtJ8RWXhfVtW0a+/RiiqbbmqrbdSMMNSjNu8o08FFxwUYyd3FYODlDCWt9WhOcKPJGc 0zo4rRSq4ivJLTmrYyaqYuq7b1MXUjGpipv3sRUjCdZzlGLXyl8Tf2NPg58UNd8PeMrm/wDi94E+ IfhzwfYfD2L4m/Cb46fF34ZfEXxB4D02eW6svCfj7xf4T8Y6fq3xK0yzvbm/1LTLj4gzeJdX0TWN V1rXNB1PS9a1vVtQveY+F/8AwT4/Zc+Cll8WNP8AhL4d+Knw7t/jiLS4+KB8JftNftO6Lc+JfEVv ZaNp9z8QYryz+MUV34e+LOv2ugaWPGPxg8Lz6L8UfHE0VxdeMPF2uXWoajNdfalFF3+8/wCnyrxq 96scVUlWxMKj3nDEVpzrV4SbhVrVKlWcZVKk5SP5Ht7J0HTtpyPCxpww0oW+GWHhSpQoSVpUYUqU KbjGnBR+PfgX+wp+z/8As36zYaz8Jbv9ojS10298V6nbeG/Fv7Z37ZHxU+Hz6n441LVta8Vape/D H4rfHrxt8OdT1PWdc13V9en1HUvC13exa/fz65azwaqVvF+wqKKblKSipSlJQXLBNtqEXJycYp/C uaUpWVlzSb3bEoxTlJJKU3zTkkk5yta8nvJ20u7uxy3jjwR4P+Jfg7xT8PPiF4Z0Pxp4F8b6Bqvh bxf4R8S6ba6x4f8AEnhzXLKbTtX0XWdLvY5rS/07UbG4mtbu1uI3jlikZWHNfH/w4/4J2/s7fDjx v4K8dHUPjx8TLr4WXr6j8HPDfx2/aX+PXx18CfB/Ujp11o8Os+AfBfxV+IPirQLTxPpuj3t7o/h/ xnrdnrnjLwro17f6P4X8QaNpeoX9nc/dNFTD91Vdan7lZqmnVj7s/wBy6jovmWvNRdat7GV+al7a sqbiq1Tmc/3lP2NT36X7z93LWFq0YQrx5Xpy140qUa8PhrRpUlUUlThy/Inxt/Yd+Af7QnxA8M/E /wCJdx8f28YeCrkX/g65+H37YX7XvwY0Twpqp8P614Un1vw54O+DPxz8A+DdE8QX/hrxHr2hap4g 03QLbWtW0vVr2z1O/u4Z2Wvoj4e+AtD+GXhDR/A/hu+8aalouhR3EVle/EL4j/EP4t+L51ubue9k OsfEL4reKPGnj7xFIs1zIlvN4g8S6nNaWiwafavDYWtrbQ9nRRD93CVOHuU5TdSVOHuwlUblJzlF Wi5uU5tya5rzk73k7kvflGc/fnCCpxnL3pRpxSUYRk7tQSSSimopJJIK+QfiV+w/8DviZ468SfEW e8+MXw88S+PYdNtfig/wR+Pvxn+COl/Fe30fTotG02T4h6N8LvG/hbTNd1q10S3ttAj8YpbWfjn/ AIRyzsPDjeJm0KwstOt/r6ipcISalKMZOKkk5RUvdlZTi7ppwmklODvGcfdmmtClKSTSlKKla6Ta u4tSg9GvehNKcJL3oTjGcWpRTXyH8Mv2Dv2Ufg/8IfiL+z/4D+FK2XwL+KV74gvvFfwd17xt8RvH Hwytn8VahqGr+ILPwR4H8c+L/Enhv4X6PqWsapfa1JoPwy07whokWtTLq9vp8OpQW91Fm+Af2Dfg P4F8a+E/Hl3qHxt+KesfDm8k1D4V2Xx7/aJ+N/x28OfC3UZLG40tda8E+G/ir478VaNa+K7bTLu7 0vTvHmrWmsePtK0u9v8ATNM8UWen6jf21z9nUVpzz9r7fnl7ZQowVXmftFHDRcMOlO/Mvq9Nyp0G mnRpzqU6bjCpOMocYunKi4x9lOdepKnZckqmKkp4qco2s5YqajPEtr9/OMJVeeUItfFfjH/gn/8A s6eOPij48+MuqXv7Sui/EL4mweH7Pxvqfw8/bi/bb+FGka3YeFbe/tfDml/8Ib8Lv2hfB/grTdJ0 WLVtWOn6TpHh6w023n1fVrpLUXOp301xs+N/2FP2Y/Hnwn+HHwOvfBfizwh8L/hL4q0rxx4C8N/B z40fHD4CS6T4x0TU5Nd0zxNe+IPgf8R/h74m8Sa3B4jll8UvqPifWdZubrxbLL4ru5J/EUj6m313 RWcYxjCnTjGMadKrha9KnFJQp18DVjXwVanBe7Crg68Y1sLUilPD1YxqUnCaTKcpSnKpJuVScK9K c225zp4mk6OJpyk9ZQxFFulXg241aTdOopQbR4FrH7L/AMDPEHxU+CHxw17wS+tfF39nTw74q8Kf CP4h6p4p8Z3/AIo0DQPG+gw+GvFNhrOpXXiKWTx6dX0qECW7+IX/AAlV9BqU15rlnc2+uX97qNxh eAv2Q/gr8M/E/wAdPGXg7/hcFj4i/aQvbnVPi3fan+0t+0n4ni1XVrnSLXw8us+FNO8U/FrWdL+F ut6f4f0/StA0PWfhXZeC9U8PaHouhaPoV3p2naHpFtZfTVFVL378/v3pYug+b3r0MwryxOPou9/3 WNxMpYjF0/gxNeUqtZTqNyFH3UlH3VGeGqRUdFGeCioYOattPCQjGGGktaEUo0nBJI8b+AfwD+Gf 7M3wv8P/AAa+D9j4q0r4e+Ffti+HtJ8YfEz4m/FnVNLgvbmS7lsoPF3xb8YeOfGLabFPLIbHS5tf l07TI3MGm2trB+7r2SiiqlOU3zTlKcmknKTcnaKUYq7bdlFKK7JJLRCjGMVaMVFNylaKSXNOTlKV l1lJuUnu5Nt3bZ8Jav8A8E7PgBd+I/HviLwz4k/aS+Fq/Fjxl4k8f/FXw58Iv2rv2i/hz4Q8feL/ ABfdNd+Jtev/AA54c+JNpp/hnVNbkcpqOo/D1PBuoXNvHa2sl0bexsI7b7C8CeBfCHwx8F+Ffh18 P/D2m+E/A/gfQNK8LeE/DOjwfZtL0Lw/olnFp+l6ZYw5ZlgtLSCKJWkeSWTaZJpJJXd26uiph+7p RoU/coxhh6caUfdhGlhKcqOEpKK0VLCUZzpYWkv3eGpznCjGEZyTqo3Vqzr1G6lapUr1alWfvVJ1 sXVVbF1pzfvSrYqtGNXFVZN1MRUjGdaU5Ri0V8Kap/wTi/Zg1bxd8TPG80v7TFjrXxj8V3PjT4n2 mgft1/tzeF/CfjPxBd6Rpnh2WXWPAPhv9ozSfAj6WvhrRNH8MW/hyDw5B4ctPC+lad4atNKh0Oyt 7CP7roqeSPNz8sef2c6PPZc3sqk6VSpS5rX9nUqUKM5wvyynRpSkm6cGmpSUeVSkoucZuKbUeeCn GE7bc8I1KijLeKnNJpSd/nvxx+yr8AfH/wAJvCfwR1b4dadonw5+Hsnh+6+GWmfD3UNb+Fur/CnU /CdtJZeGNc+FHi34b6n4W8W/DPX9Bsprmw03W/BGt6HqcOnXuoaY10+nalqFrc818Iv2Pfhb8IfG ifEmDxP8dPib8QbXSNR0DSfFPxz/AGgvjF8ZH8N6Lqz2j6lZeEvDnjvxjq3gnwlPqQsLSHVtb8N+ GNL8R61bQRWutaxqNtHHEv1TXm3wi+Lnw++O3w88P/FX4Wa8fE3gTxT/AGt/YWtnTNX0c3v9h65q fhzU/wDiXa7Y6Zqtv9m1nSNQtB9qsofOEH2iDzbaWGaS1OSq1aqk/bV51KtapdupUq1qSoVatSfx Sq1qEVQq1G+erRj7GcpU1ymbjBwpUXGPs6MIQo0+VclOnRqKtTpwja0adKs1Wp00uSnWaqxjGpaR 8xeNv+CdX7NnxD8f23xQ8U6t+1bP4207VvE2taFqukf8FAf2+PCtr4UvPGMbQeJIvBOg+Ff2ltF8 O+B9L1O0YWDaF4R0nRdEttMjh0yz0+30+CG2j9z8afs8eAfHvw68LfC7XPEHxzsfDPg/+zP7J1Pw X+0/+0t8N/iLef2Tp02l2v8AwlPxf+Hfxa8LfFrxz5ttO8up/wDCbeNvEH9t6isOsaz9v1a2t72L 3OioUIqkqCjFUU6UlRSSpKVHWjJU7cidJtuk7Xp392xd26jrNv2slUUqt37Rqskqqc/iaqpJVE3a aS5r2Pk/9nr9ir4Ffstzxt8G5/jtp2n2+mappNp4Y8efta/tYfGnwLp9trWrDXdTuNM+H3xq+Nfx B8D6Zq11qpmvDr2n+H7bXInvNRjg1GKHUtQjuex8XfsufAnx18d/ht+0x4q8CLqnxq+EmlajovgT xePEni+wtdNstRsvEGnBtV8IaZr9n4I8W6ho9l4u8XW/hPWPF/hvXtX8FJ4u8VnwffaG/iXW2v8A 3+itOaXPQqc0vaYb2n1apd8+H9rTr0avsJfFS9pRxOJpVPZuPPTxFeErxq1FKeWPs69LlXssSoxx NOy9niIwnRqQjXh8NVQqYehUiqikozoUZK0qcHHxb43/ALPvws/aH8PaP4f+Jui6rcv4X1+DxZ4J 8VeE/Fvi34dfET4feLbazvNOh8UfD/4kfD/W/DXjnwXrh0zUdR0i8vfDuv6edW0PUtU8P6wmoaFq mo6ddcP8Hv2Rvhf8GvFd78QLDxF8a/iN8Q77QLvwqPG3xu+Pfxe+MeraT4bv7yxv7/RvCenePPGG seF/AtrqV3pemXGsS+CPD/h2812XTdPl1y61KSxtXi+oaKiCUHUcEourz+0aSXO6tGOGqt/3quHj HD1ZfFVw8Y0JuVKKgnN86gp+8qagoKWvKqdV4inFX+zTxEpV6cfhhXk60Uqjcj4W0D/gnN+zX4X8 dax8StC1f9rCw8Z+JNX0DXPE2qj/AIKC/t+XFv4ov/C0SW/h9fFGi3f7TM+heJNO0uyjXTbfRdb0 y/0Y6Tu0iSwk0x3tG739rP4g/Gfwj8Ote0L4K/soeMP2o/EvjDwX430qz0nTfGHwK8J+A9L1mXRm stD0z4lS/GD4r/D3U7rwz4ivL4wal/wh+i+L7iLSbTUxdWkU0thBe/VlFY4nDwxWEngarmsJUp1q U6EGowlSr0fYVYJWfs+enyJypclT93TXPyxs9qFZ4fExxkYwniIzp1FUqKTk50qjq05SlGUZT5Zy lJKUnG85tq8mfHv7AfwK0/8AZr/Y9+A/wYs/BHib4fX3g3wTbQeKdA8a6j4U1jxjN441C6utU8b+ IvE2q+CPGPxB8L3+r+K/FN7qviSaXSfGniK3hi1SG0F9utjbwfYVFFd+LxNTGYrEYuryqria9WvN QTUIyqzc3GClKTjCN+WEXKXLFJXdjjw1COGoUcPCUpxo0401OpyupUcVZ1KjjGEZVKjvOpJRjzTl KVlc+b/Hv7J/wb+JPxv+H37RXidPitH8WPhdot14c8Gar4T/AGiP2hvh74XstA1HXNI8R6zo2rfD L4f/ABS8MfC/xXpniPVvD3h+bxVZeLfBuuW/iu20DQ9N8RpqmmaPp1nbdH4P/Zx+CngD4y/GD9oL wd4DsNB+Lvx90rwFo3xf8W2eoa4f+E4svhjZ6xp3gl9S0CfVJvDFtqWkadruo2E2taXothrOs2X2 C012/wBTg0jSI7H22iuaKUIxhBKMIfWeWEVyxj9dn7TGcsVZL63U/eYmyXt5+/V55am8m5c7k3J1 Fh41HLX2kcJKE8LGd/iWGnTpyw6ldUZQhKnyuMWvzw/4ddfsk/b/ALF/Zfxf/wCFS/8ACRHxb/wz D/w0P8cv+GTv7fOs/wDCQkf8M5f8J7/wq3/hEv7dJ1j/AIVWPD//AAqH+1T/AGp/wgP9of6VX0d8 bv2ZPhX8fJvCOreMIfGHh7xp8PW1Y+APiZ8LPiB40+E3xM8HQa/DaW/iDStH8bfD7W9A1mbw14hi 07Tf+Ei8HavPqng/X5tK0e61jQb270fSp7P6BoosvZ06W1OjP2lKC0VKpyQpKdO3wTjSp0qMZxtK FGlSoxapUqcInM/aVKzd6tVSjVm9ZVIzlKc4zbvzxqTqVKlWMrxqVKtWpUUp1akpfGPwi/YB/Zi+ CHxN1z4z+BPDXxC/4Wt4x8MQ+EviT428U/Hn48eN7z4vabaya1JYXXxk0Xxd8SdZ8J/FfXdGTxDq 9h4Z8QePfD+vax4Q0K4t/DPhK80Pw1pmlaRY8fF/wTU/ZqtoF8OWOpftD6V8JYnJtv2fNE/as/aN 0L4A2Vo0plPhyx+F2jfEyw0Gz+HuCbVPhJbrH8JYtNJ0iHwNHpP+g19/UVSk1KnJOzowjSpcuipU 4VKlanTpxVowp0q1WpXpQilGlWnKtTUaj5hW/ibt1ZqpVbbcqlRUoUPaVJO8p1HQpwoOcm5yoRVG TdL3SOKKOCKOGGNIoYY0iiijUJHHHGoRI0RQFVEUBVUABVAAGBUlFFDbbbbbbd23q23u2+4klFKM UoxikoxSSSSVkklokloktEj5O+HnwL8eaT+1r8fv2lfG/iLwjNpvj74Z/B74KfDPwf4W07WVvtH8 DfCrXvih40uPEfjnXNWu/s+oeK/Enij4tazZxaVoOlWekaJoPh7S3bUdY1DVbz+z/rGvNbD4vfD3 U/i/4n+A9lrxm+Kfg34d+Cvit4i8M/2Zq8a2HgP4h+I/HXhPwjrY1mSwTQrptU174beMrJtNs9Tn 1WxGlJc6hZWtpqGnT3fpVTCyoUIQ1o04VIUpLVTccTX+tT5lpOpPHfWpYhrRYp14Wg4uEaqXeKxU 6t/rVSWEliYy0nCP9mYGOXxlDR04LJ45d9VTS9pgvq1a9RVVVqFFFFMQUUUUAFFFFABRRRQAUUUU AFfmz8Fh/wAbVf2+z/1aX/wTuH/l7ft2V+k1fL3gX9n/AFTwj+13+0V+0pP4i0+80f42/Bz9mj4Y 6b4Yhs7mLUtCvfgRr37Qer6pql7fPK1rd2viCP4zabDYQQRRzWj6JfNcNItzBtuDS5ru3uSXq2rW /EU9aNaK+KTwvKu/s8fhK0/up05y13tbdpP5e/bd8a/tTaD4/wDD2mBviB8N/wBh658OiT4rfG79 lTwyfiv+1LpGvm6lW70vWfC97pd7rvwt+Ez6YY49R+IfwQ+HPx7+KiNLd6hHP8D7PR18aS/Qf7PP g/4BeDv2fdW8SfsFab8H/GOm+NdM1zxZ4b8YW/j/AFHXdE+MfxG+xXFvaa/8X/jpaWvxM+IXi/Wd Q1i3g0zxj498SL8QPHVhFFcrcWWp3tgmlt9f1534R+Efwv8AAHifx7408DfD/wAI+DvFXxT1HTta +JOueGNB07Q77x3rmlW89nY694rk02C2XXNfis7h7J9c1BZ9WuLOO1tLm8mt7KzjgypRcKOJoc8o yrRq2xdPlWLl7TEKtHD4iU4zhWw2H5nLBQiqdLCyoQ58Niq2Jr4qF1Jc9bD1uWMo0ZUr4Wpd4Vez peylXpRg4Tp4ivZ/W6kpVKmIjVlCnWwtKjToy+IdF8af8Fe5dY0mPxF+zX/wTdsvD8mp2Ca7eaL+ 29+07qmsWmjvdRLqdzpOm33/AAT50iy1HU4LIzy2Fjeatpdrd3SRW9xqNlFI9zF618e/En/BQbSf Gtva/svfBj9jfx/8OjoVlLd638e/2mvjZ8IfGsfiZ7m+XUrC38LfD39kn43aFNoUFmmmyWWrSeMI NQu7me+gn0WyitILi9+yKKqXvRpJe46dSdSUo/FVU6fIqVXm5l7Om/3sPZqnU9o/fqTh7hMfdlUk 3zKdOEFGXw0nGbm6tO1pe0mv3c+eU4ciXLCM7zPlb4da/wDtu3nwi+IOo/Fr4UfsreHPj1ZnVf8A hVXg/wCHX7QXxb8a/CLxEI9HtZNE/wCFg/EjxL+zL4B8Z+DDdeIGvLLVR4c+Ffjz7Bo8VrqdodSv biXSbbxLwp4y/wCCtdx4o8OQeOf2cf8AgnTpPgqbXdJi8Xap4U/bV/aW8QeKNN8MyX9umu3/AIc0 HV/2BPDOk63rtnpZurjSdI1PxJ4f0/Ur+O3s7zW9Kt5pL6D9FqKpSSrKtyxcVGhH6u7+xbo35puz VXmxF/39qqjovYxo63lxboulzSUnKtL2yt7ZKrblirp0+Wh/y5vTb1ftHUPjf49+JP8AgoNpPjW3 tf2Xvgx+xv4/+HJ0Kylu9c+Pf7TXxs+EPjWPxM1zfLqNhb+Fvh5+yV8b9Cm0KCzTTZbLVpPGMGoX dzPfQT6LZRWkFxe6XgrxD+3ddfBn4gal8RvhD+yTon7QtndzL8LPBfgr9oz4xeKfgz4hsRa6a0E3 xA+Juu/steD/ABv4Ou2vX1iKa28O/CTx1DHa2um3CXckt9dW2nfW1FZqLVKtT55OVWNRRrPl9rQ5 6vtFKjaKp81OP7mn7WnVXsvjU6n7w0ck6tKpyxSpSpylSXN7KsoQ5HGr73tOWo/3lT2dSnLn+CUI e4fnt4E8Yf8ABVu68aeFrb4m/s7/APBPbQfh3Pr2mReNta8CftmftIeLPGmleGJLuJdZv/C3hjxB +wf4L0PxBr1rYmabTNI1bxd4a0+/u0itrrW9Nhke6i7T44+Jv+Ci+l+Pbm0/Zr+CX7FXjr4Xrpum vZ6/8cf2pPjn8KfHsusPEx1e2ufCHgL9j74zeHoNNtp9iabfReN7m6voi0l1p+nuBE32rRVS96NJ L3HTqVKkpR+Ksp01BUqvNzL2dNp1Kfs1Tn7ST55zhaCmPuuo373tKcIKMtqTjU53Vp8vK/aTX7uf O5w9n8MIz98+VfCGv/tvXHwO8Zap4++FH7Kuj/tKW15fr8PfAvhD9oP4ueJPgdrVgsOlnTJvGXxW 1r9mXwr498MXk88mtJf22ifBnxdDaw2mlyW93ePqF3FpnkHgTxh/wVbuvGnha2+Jv7O//BPbQfh3 Pr2mReNta8CftmftIeLPGmleGJLuJdZv/C3hjxB+wf4L0PxBr1rYmabTNI1bxd4a0+/u0itrrW9N hke6i/QmirUkq8a3JGUFHDxeGfN7CToq05StJVubE74i1ZK/8BUVoS4t0XS5pKTlWl7dW9slWtyx V06XLh7fub0nLV+1lV0t8OfGbxT/AMFKNN+IWs2f7PPwL/Yc8afCiKLTT4e8RfGb9q749/DH4hXs 76dbPrC6z4M8EfsZfFzw3pcVtq7Xltpr2PjzWHvtOitr66j065uJdPtu60jX/wBt2T4Aa3q+u/Cj 9la0/amiv5U8OfD7SP2gvi5qPwAvtMGq2EcFxrfxhvP2ZdL+IulX7aI+qXctnY/A3WLdNVt7DT0v ntLy41Ox+qaKyimqU6blKUpRUVWly+1g1UhU54WiqfM4xdJ81OUfZznaKqctSNtp1KVTlUY05RlK kr+zrKNNwcKt26nLJv2svZ1KcvaJcso07038B/DTxb/wVJvfHnhe0+Mf7P37Afhn4YT6pHH401/4 aftg/tEeOfHml6KY5DNdeF/CPin9hz4d+Htf1RZREsdhq3jbw3aSRtI7alGyKkl34teK/wDgpxp/ xC8R2fwJ+Av7CHi74Uwz2g8I+Ivi1+1v+0D8O/iFqVs2nWj30niPwZ4O/Yn+KPhvRJ4tWa/trSHT PHniCO406G0vZp7W5uZrC1+76Kp6+z+zye1vb/l57T2PL7S9/wCD7KXsuTk/j1vae0/deyS0c3fm 51TST2p+zdRuULWd6vOlU53NWpU+RQfO5/K39v8A7bv/AAz3/bH/AAqj9lb/AIat+3FP+Fd/8NBf Fv8A4Z7/ALM/4SIwi4/4XL/wzL/wsj7d/wAIljUjZ/8ACh/s48RZ0T7cdNH9vnzn4S+K/wDgpxqH xC8N2fx2+An7CHhH4UTz3g8X+IvhL+1v+0D8RPiFplsunXj2EnhvwZ4x/Yn+F3hvXJ5tXXT7a8h1 Px54ejttOmvL6Ge6ubWDT7v7voqoyUas6jjGUZSUlRlf2UEqcKfLCzVTlbi6r56kpe0nO0lT5YRl xbpez5pRdqi9qre19+cpJ6pwvSUlCn7luSEedTlzSl8IfFrxX/wU40/4heI7P4E/AX9hDxd8KYZ7 QeEfEXxa/a3/AGgfh38QtStm060e+k8R+DPB37E/xR8N6JPFqzX9taQ6Z488QR3GnQ2l7NPa3NzN YWvc3fiH9u5fgBp2r2Pwh/ZJl/amfW2i1b4fXf7Rnxit/gBbeGxqt7Gl/p3xhh/ZaufiLe622iLp 122k3PwNsLBdVnvdPGtPaWsGp3n1tRWcYtUVSc5ykvY/v5cvtn7KcZyvaKpfv1FwrWpL3Jy9l7KX LKOjknU9pyxS/efulzez9+nOmt5Of7uUlVp+/wDxKcOfnp89Ofw58GfFP/BSjUviHotn+0N8C/2H PBfwoli1M+IvEXwZ/au+PfxO+IdjOmm3T6Oui+DPG/7GXwj8N6pFc6wtlbam99480d7HTZbq+tY9 RureLTrrG+Jfi3/gqTZePPFFp8Hf2fv2A/E3wwg1SWPwXr/xL/bB/aI8DePNV0UJGYbrxR4R8Lfs N/EPw9oGqPIZRLp+k+NvElpGixsupSs7In35RVS950mvc9nTqU5RjtWc6imqtXm5n7Sml7Kn7N04 ezb54TnaamOiqJ+9zzhJOW9NQjKLhTtZclRyU586nLmhHklCPNGXyrq2v/tvR/ADRNX0L4Ufsq3f 7U0t/GniT4fat+0H8XNO+AFjpZ1XUI5rjRPjDZ/sy6p8RdVv10NNKu47O/8Agbo1u+q3Goae1+ln ZW2p3/DfBnxT/wAFKNS+Iei2f7Q3wL/Yc8F/CiWLUz4i8RfBn9q749/E74h2M6abdPo66L4M8b/s ZfCPw3qkVzrC2Vtqb33jzR3sdNlur61j1G6t4tOuvuOirUkq1aq4RlGrKco0HzexoKdJU1CjaSq8 tOS9tD2tWrL2rfPKdO1NS4t0qdPmlFwiouqre1qNVJT5ql06fM01SfJThH2cY2ip3m/z28d+MP8A gq3a+NPFNt8Mv2d/+Ce2vfDyDXdTi8Fa147/AGy/2kPCXjTVfDMd1Iuj3/inwx4f/YP8a6HoGu3V kIZtT0jSfF3iXT7C6eS2tdb1KGNbqT2Dxfr/AO27b/A7wbqngH4Ufsrax+0nc3dgvxC8C+L/ANoL 4ueG/gdoti8WpnU5vBvxW0X9mXxX498T3cE8ejJYW2t/BnwjDdxXWpy3F3ZPYWsWpfVNFZKLVFUu aTkpUJe3fL7aSo35ou0VS5cRe1e1JS0XspUtb6Np1nV5UouNaPsFzexTq25ZK8nV5qFv3N6rjq/a xq6W+Kvgb4m/4KLap49trT9pT4JfsVeBfhe2mak93r/wN/aj+OfxX8exawkSnSLa28IePf2Pvgz4 en0y5m3pqV9L43t7qxiCyWun6g7GJeL8d+MP+Crdr408U23wy/Z3/wCCe2vfDyDXdTi8Fa147/bL /aQ8JeNNV8Mx3Ui6Pf8Ainwx4f8A2D/Guh6Brt1ZCGbU9I0nxd4l0+wunktrXW9ShjW6k/Qmiql7 0qbXuKnTnBxj8NVyqc6q1ObmftIL93D2bpw9n8UJT98mPuqon7zqVITUpb0lGnyOlT5eVezm/wB5 P2inP2nwzjD3Dg/hnd/E2+8A+GLv4y6D4E8L/FCfS1fxpoHwy8W+IPHfgLS9Y8yUSW3hfxf4q8Ff DnxDr2mCEQul9q3gjw3dNK8sbaeqRpLJ8Of8EkBj/gnt+z77j4qH8/jZ8SDX6PnkEetfMX7G3wC1 P9l/9m74b/AvWPENh4r1LwMvi1bnX9MsrjT7HUP+Ek8deJ/F0Jhs7qWaeH7NBr8VnL5kjb5reSRS EdQCT5q1SahGEZ2ahDm5I+9UfJHmlKXLFSSjzSlK1ryk02Zxi4+yi5SnyU5RlOfLzSf7pKU+WMY8 0uWTfLGMb3tFKyPp2iiig0CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA/NzwKP+Nuf7 TR9P+Ce37F4/P9ob9uI/0r9I6+YPD/wB1TRf2y/it+1DJ4hsJ9G+In7N3wL+Blp4VSzuU1TTdS+E nxJ+P/jrUNeuL9pDaT2Os2vxj02ws7SOFbi2n0S9lmkeO5gVPp+lS93BYOk9J0nmnPHrH6xn2b4y ldrR8+HxNGorN2U1GVpKSV4pqea5niIe9Rrx4eVKa2m8Hwbw1luJst17LHYHFYd8yV5UXKPNTlCc iiiimQFFFFABRRRQAUUUUAFFFFABXmmifF/4e+Iviv8AED4IaPrxu/ib8LvCHw58d+OPDn9l6vAu i+Fvizf+PtN8BakNXuLCLRNRbW7z4Y+NYmstL1G9vtMGkJJqttYx6jpj3npdfmz8Fh/xtV/b7P8A 1aX/AME7h/5e37dlVFJ3vfSMnp3SuvlfcJe7Sqz6weHt2/e4zDYeV9npCtJqzVpKLd0nF/pNRRRU gFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABXm3wi +Lnw++O3w88P/FX4Wa8fE3gTxT/a39ha2dM1fRze/wBh65qfhzU/+Jdrtjpmq2/2bWdI1C0H2qyh 84QfaIPNtpYZpPSD0P0P8q/OH/gkgMf8E9v2ffcfFQ/n8bPiQam/vOPRRi//AAJyX4cv4sTdpRXd Tf8A4C6aX/pb/C3U/R+iiiqGFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB5rYfF74e6 n8X/ABP8B7LXjN8U/Bvw78FfFbxF4Z/szV41sPAfxD8R+OvCfhHWxrMlgmhXTapr3w28ZWTabZ6n PqtiNKS51CytbTUNOnu/Sq/NzwKP+Nuf7TR9P+Ce37F4/P8AaG/biP8ASv0jpUvfwuFrv467zDmS +FfVM5zLLqfKndrmoYOlOd271JTlHlg4wjWISpZjmGEjd08LHJHTctZt5lwtkOdV+dq0Xy4vNMRC laMeXDxown7SpGdWoUUUUyQooooAKKKKACiiigAooooAK/Nv4Lf8pUv2+v8As03/AIJ4f+pr+3VR RVw3l/gl+Qqn+74j1wX/AKtMAfpJRRRUDCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigBD0P0P8q/OT/gkl/yj3/Z8/wCufxR/9XT8RqKKhfxJf4Kf/pVQ l/HD/DV/Oifo5RRRVlBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfm94F/5S4ftN/8A aPj9i/8A9aE/bir9IaKKVD/kX4D1zn/1ps8Lxv8AyO85/wAHCv8A67/hAKKKKZAUUUUAFFFFABRR RQB//9k= ------=_001_NextPart325326163058_=------ From nobody Thu Feb 20 19:40:28 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F1B1A03CC for ; Thu, 20 Feb 2014 19:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ukg3Ctg43gYj for ; Thu, 20 Feb 2014 19:40:23 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id A38471A02E4 for ; Thu, 20 Feb 2014 19:40:23 -0800 (PST) Received: from [192.168.1.55] (unknown [118.209.8.95]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B9466509B5; Thu, 20 Feb 2014 22:40:16 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Mark Nottingham In-Reply-To: Date: Fri, 21 Feb 2014 14:40:39 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <5CDF18BF-B0E8-4808-8F12-3333EE6B9010@mnot.net> References: <20140214010816.22518.21143.idtracker@ietfa.amsl.com> <294BC0AD-FABA-42DA-ADDB-91F9279ACD31@mnot.net> To: "Kent Leung (kleung)" X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/Abu8NtJhDSA6FofkFQoqFfZKqFo Cc: "cdni@ietf.org" Subject: Re: [CDNi] New Version Notification for draft-leung-cdni-uri-signing-04.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: Fri, 21 Feb 2014 03:40:26 -0000 On 20 Feb 2014, at 7:56 am, Kent Leung (kleung) = wrote: > E.g., in section 3: >=20 >> 5. Append the parameter name used to indicate the URI Signing=09 >> Package Attribute. This parameter name is communicated = via the=09 >> CDNI Metadata Interface. Alternatively, it is set to=09 >> 'URISigningPackage' by configuration. Append the string=09= >> "URISigningPackage=3D" to the message. >=20 > This would be more clear as something like: >=20 > """ > 5. Append the parameter name used to indicate the URI Signing Package = Attribute, as communicated via the CDNI Metadata interface, followed by = an "=3D". If non is communicated by the metadata interface, it defaults = to "URISigningPackage". For example, if the CDNI Metadata interface = specifies "SIG", append the string "SIG=3D" to the message. > """ >=20 > and so forth. >=20 >> KL> OK. We can add an example. For your text, ""=3D". If non is = communicated by the metadata interface, it defaults to = "URISigningPackage"", are you saying it's OK to default to an attribute = name specified in the draft? Think so. >> If so, would this attribute name need to be IANA-based? I'd like the = clarify the language. Don't think so... Happy to talk about it in London, though. > More deeply, the draft assumes that URIs always have query strings = encoded in the format specified by HTML = . While = that format is extremely common, it isn't a constraint on URIs -- even = HTTP URIs. >=20 > One way to avoid this would be to have the CDNI Metadata Interface = convey a URI Template to specify where the signature goes: > http://tools.ietf.org/html/rfc6570 > https://code.google.com/p/uri-templates/wiki/Implementations >=20 >> KL> OK. We'll need to look at this when the CDNI Metadata interface = section is filled in. Thanks. Thanks, -- Mark Nottingham http://www.mnot.net/ From nobody Fri Feb 21 00:44: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 37C511A04DF for ; Fri, 21 Feb 2014 00:44:29 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 6vfvxVIRvhIu for ; Fri, 21 Feb 2014 00:44:26 -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 B374C1A0030 for ; Fri, 21 Feb 2014 00:44:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16740; q=dns/txt; s=iport; t=1392972262; x=1394181862; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=z/m7NWkbjzrLMmiPiymcqeTrwLjR8CCd+yXIfx7uuKc=; b=fqSv+T13c4mHfRHugIztD4/dJrXJTtJLFPtB1ifUSHhcxmKgQyAWvHXN gmK0/prTUBllG8LgHhTK1jzw1yo5ATcTSJHNZNzyTdKs5yBcNT0r9buZ5 IPGy9u/n4yYNLDGRU5g7dj3gbeMRzCcVjzNwT3jEqdy/+oBdApgYwXhGu Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4bAK4QB1OtJV2a/2dsb2JhbABZCoI4RDtRAwODA4EepjGNDYhYGHgWWxmCJQEBAQMBAQEBawsFCwIBCBEDAQIoBQICJQsUCQgCBAENBQmHdAgIBY8Xm3oIoUMXjjkQCg0EBgEEAgOCYjmBFASYNIEykHWBQYFsgio X-IronPort-AV: E=Sophos;i="4.97,517,1389744000"; d="scan'208,217";a="305600551" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 21 Feb 2014 08:44:21 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1L8iLaL000535 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Feb 2014 08:44:21 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.67]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 02:44:21 -0600 From: "Francois Le Faucheur (flefauch)" To: yiqiuchao , "draft-ietf-cdni-framework@tools.ietf.org" Thread-Topic: some comments.//Re: Re: [CDNi] I-D Action: draft-ietf-cdni-framework Thread-Index: AQHPLuEalanHljgFZUOGQifkxmN5MQ== Date: Fri, 21 Feb 2014 08:44:17 +0000 Message-ID: <87114F5A-16C8-4C77-BE73-3FA13D0D715E@cisco.com> References: <20140213131011.12134.40084.idtracker@ietfa.amsl.com>, <201402211137118185825@chinamobile.com> In-Reply-To: <201402211137118185825@chinamobile.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.200] Content-Type: multipart/alternative; boundary="_000_87114F5A16C84C77BE733FA13D0D715Eciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/8NG-Hiwy-UZctVmmBkYXOW-xmuI Cc: "cdni@ietf.org" Subject: Re: [CDNi] some comments.//Re: Re: I-D Action: draft-ietf-cdni-framework 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 Feb 2014 08:44:29 -0000 --_000_87114F5A16C84C77BE733FA13D0D715Eciscocom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgdGhpbmsgdGhlc2UgY29tbWVudHMgYWN0dWFsbHkgcmVsYXRlZCB0byBjZG5p LWZyYW1ld29yayAoYW5kIG5vdCBjZG5pLWxvZ2dpbmcpLCBzbyBoYW5kaW5nIG92ZXIgdG8gdGhl IGNvcnJlc3BvbmRpbmcgZWRpdG9ycy4NCg0KQ2hlZXJzDQoNCkZyYW5jb2lzDQoNCk9uIDIxIEZl YiAyMDE0LCBhdCAwNDozOCwgeWlxaXVjaGFvIDx5aXFpdWNoYW9AY2hpbmFtb2JpbGUuY29tPG1h aWx0bzp5aXFpdWNoYW9AY2hpbmFtb2JpbGUuY29tPj4gd3JvdGU6DQoNCkhpIEZyYW5jb2lzLA0K SSBoYXZlIHJlYWQgdGhlIGRyYWZ0IGFuZCBsZWFudCBhIGxvdCwgdGhhbmtzLg0KQW5kIEkgaGF2 ZSBzb21lIGNvbW1lbnRzIGFzIGJlbG93IHdoaWNoIGFyZSBoaWdobGlnaHRlZCBpbiByZWSjug0K MS4gUGFnZSA3Og0KICAgNi4gICBBc3N1bWluZyB0aGF0IGRDRE5uIGlzIHNlbGVjdGVkIGFzIGEg c2VydmluZyBkQ0ROIHByb3ZpZGVyLCB0aGUNCiAgICAgICAgZW5kLXVzZXIgZG9lcyBhIEROUyBs b29rdXAgdXNpbmcgZENETm6hr3MgZGlzdGluZ3Vpc2hlZA0KICAgICAgICBDRE4tZG9tYWluIChw ZWVyLWRDRE5uLTEuZENETm4ubmV0PGh0dHA6Ly9wZWVyLWRDRE5uLTEuZENETm4ubmV0PikuICBk Q0RObi0xoa9zIChkQ0RObidzKUROUyByZXNvbHZlcg0KICAgICAgICByZXR1cm5zIHRoZSBJUCBh ZGRyZXNzIG9mIGEgcmVxdWVzdCByb3V0ZXIgZm9yIGRDRE5uLg0KICAgNy4gICBUaGUgcmVxdWVz dCByb3V0ZXIgZm9yIGRDRE4xKGRDRE5uKSBwcm9jZXNzZXMgdGhlIEhUVFAgcmVxdWVzdCBhbmQN CiAgICAgICAgc2VsZWN0cyBhIHN1aXRhYmxlIGRlbGl2ZXJ5IG5vZGUgdG8gc2VydmUgdGhlIGVu ZC11c2VyIHJlcXVlc3QsDQogICAgICAgIGFuZCByZXR1cm5zIGEgMzAyIHJlZGlyZWN0IG1lc3Nh Z2UgZm9yIGEgbmV3IFVSTCBjb25zdHJ1Y3RlZCBieQ0KICAgICAgICByZXBsYWNpbmcgdGhlIGhv c3RuYW1lIGJ5IGEgc3ViZG9tYWluIG9mIHRoZSBkQ0RObqGvcw0KICAgICAgICBkaXN0aW5ndWlz aGVkIENETi1kb21haW4gdGhhdCBwb2ludHMgdG8gdGhlIHNlbGVjdGVkIGRlbGl2ZXJ5DQogICAg ICAgIG5vZGUuDQogICBhbmQgdGhlIGZpZ3VyZSAxIGluIFBhZ2UgNiBzaG91bGQgYmUgbW9kaWZp ZWQgYXMgd2VsbC4NCg0KMi4gUGFnZSAxMCwgdHlwb3M6DQo8Q2F0Y2guanBnPg0KDQozLiBJIHRo aW5rIHRoZSBDTkFNRWVkIGRvbWFpbiBuYW1lIHNob3VsZCBiZSBhZGRlZCB0byB0aGUgZW5kIG9m IHRoZSBvcmlnaW5hbCBvbmUsIHNvIHRoZSBkQ0ROMS5jZG4uY3NwLmNvbTxodHRwOi8vZENETjEu Y2RuLmNzcC5jb20+IHNob3dlZCBpbiB0aGUgYWJvdmUgZmlndXJlIHNob3VsZCBiZSBjZG4uY3Nw LmNvbS5kQ0ROMS5uZXQuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KeWlxaXVj aGFvIGZyb20gQ2hpbmEgTW9iaWxlDQoNCkZyb206IEZyYW5jb2lzIExlIEZhdWNoZXVyIChmbGVm YXVjaCk8bWFpbHRvOmZsZWZhdWNoQGNpc2NvLmNvbT4NCkRhdGU6IDIwMTQtMDItMTMgMjE6MTkN ClRvOiBLZXZpbiBKIE1hPG1haWx0bzprZXZpbi5tYUBhenVraXN5c3RlbXMuY29tPg0KQ0M6IGNk bmlAaWV0Zi5vcmc8bWFpbHRvOmNkbmlAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0NETmldIEkt RCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS1sb2dnaW5nLTA5LnR4dA0KSGkgS2V2aW4gYW5kIGFs bCwNCg0KV2UganVzdCBwb3N0ZWQgdGhlIHVwZGF0ZWQgdmVyc2lvbiBvZiBjZG5pLWxvZ2dpbmcg dGhhdCBhZGRyZXNzZXMgS2V2aW4ncyByZXZpZXcgY29tbWVudHMgYXMgZGlzY3Vzc2VkIG9uIHRo ZSBsaXN0IChpbmNsdWRpbmcgbGF0ZXN0IGNvbW1lbnQgYWJvdXQgcHJpdmFjeSkuDQoNCkNvdWxk IHlvdSBwbGVhc2UgcmV2aWV3IGFuZCBsZXQgdXMga25vdyBpZiB5b3UgaGF2ZSBhZGRpdGlvbmFs IGNvbW1lbnRzIGJlZm9yZSB3ZSBtb3ZlIG9uIHRvIHRoZSBuZXh0IHN0ZXAgKGFzIGFncmVlZCBp biBWYW5jb3V2ZXIpIHdoaWNoIGlzIHRvIHN1Ym1pdCB0aGUgZG9jdW1lbnQgdG8gV29ya2luZyBH cm91cCBMYXN0IENhbGw/DQoNClRoYW5rcw0KDQpGcmFuY29pcyAmIEl1bmlhbmENCg0KDQpPbiAx MyBGZWIgMjAxNCwgYXQgMTQ6MTAsIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4+IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4+IHdyb3RlOg0KDQo+DQo+IEEgTmV3IEludGVybmV0 LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJl Y3Rvcmllcy4NCj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29udGVudCBEZWxp dmVyeSBOZXR3b3JrcyBJbnRlcmNvbm5lY3Rpb24gV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4N Cj4NCj4gICAgICAgIFRpdGxlICAgICAgICAgICA6IENETkkgTG9nZ2luZyBJbnRlcmZhY2UNCj4g ICAgICAgIEF1dGhvcnMgICAgICAgICA6IEZyYW5jb2lzIExlIEZhdWNoZXVyDQo+ICAgICAgICAg ICAgICAgICAgICAgICAgICBHaWxsZXMgQmVydHJhbmQNCj4gICAgICAgICAgICAgICAgICAgICAg ICAgIEl1bmlhbmEgT3ByZXNjdQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgUm95IFBldGVy a29mc2t5DQo+ICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWNkbmktbG9nZ2luZy0wOS50 eHQNCj4gIFBhZ2VzICAgICAgICAgICA6IDQ1DQo+ICBEYXRlICAgICAgICAgICAgOiAyMDE0LTAy LTEzDQo+DQo+IEFic3RyYWN0Og0KPiAgIFRoaXMgbWVtbyBzcGVjaWZpZXMgdGhlIExvZ2dpbmcg aW50ZXJmYWNlIGJldHdlZW4gYSBkb3duc3RyZWFtIENETg0KPiAgIChkQ0ROKSBhbmQgYW4gdXBz dHJlYW0gQ0ROICh1Q0ROKSB0aGF0IGFyZSBpbnRlcmNvbm5lY3RlZCBhcyBwZXIgdGhlDQo+ICAg Q0ROIEludGVyY29ubmVjdGlvbiAoQ0ROSSkgZnJhbWV3b3JrLiAgRmlyc3QsIGl0IGRlc2NyaWJl cyBhDQo+ICAgcmVmZXJlbmNlIG1vZGVsIGZvciBDRE5JIGxvZ2dpbmcuICBUaGVuLCBpdCBzcGVj aWZpZXMgdGhlIENETkkNCj4gICBMb2dnaW5nIEZpbGUgZm9ybWF0IGFuZCB0aGUgYWN0dWFsIHBy b3RvY29sIGZvciBleGNoYW5nZSBvZiBDRE5JDQo+ICAgTG9nZ2luZyBGaWxlcy4NCj4NCj4NCj4g VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2RuaS1sb2dnaW5nLw0K Pg0KPiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4gaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jZG5pLWxvZ2dpbmctMDkNCj4NCj4g QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiBodHRw Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWNkbmktbG9nZ2luZy0wOQ0K Pg0KPg0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmll dGYub3JnPi4NCj4NCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9u eW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBDRE5p IG1haWxpbmcgbGlzdA0KPiBDRE5pQGlldGYub3JnPG1haWx0bzpDRE5pQGlldGYub3JnPg0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNETmkgbWFpbGluZyBsaXN0DQpD RE5pQGlldGYub3JnPG1haWx0bzpDRE5pQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jZG5pDQoNCg0K --_000_87114F5A16C84C77BE733FA13D0D715Eciscocom_ Content-Type: text/html; charset="gb2312" Content-ID: <5CDF9D25AB14E1488203B93D3674406C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hello,

I think these comments actually related to cdni-framework (and not cdn= i-logging), so handing over to the corresponding editors.

Cheers

Francois

On 21 Feb 2014, at 04:38, yiqiuchao <yiqiuchao@chinamobile.com> wrote:

Hi Francois,

I have read the draft and leant a lot,= thanks.

And I have some comments as below whic= h are highlighted in red=A3=BA

1. Page 7:

   6.   Assuming that dCDNn&nb= sp;is selected as a serving dCDN provider,&nb= sp;the

        end-user does&nbs= p;a DNS lookup using dCDNn=A1=AFs distinguished
        CDN-domain (peer-dCDNn-1.dCDNn.net). &nbs= p;~~dCDNn-1=A1=AFs~~ (dCDNn's)D= NS resolver

        returns the = IP address of a request router for dCDNn= .

   7.   The request router&nbs= p;for ~~dCDN1~~(dCDNn) processes the HTTP request= and

        selects a su= itable delivery node to serve the end-user&nb= sp;request,

        and returns = a 302 redirect message for a new URL&nbs= p;constructed by

        replacing the&nbs= p;hostname by a subdomain of the dCDNn=A1=AFs=

        distinguished CDN= -domain that points to the selected delivery<= /div>
        node.

   and the figure 1 in Page 6 should be modified as well.

2. Page 10, typos:

<Catch.jpg>

3. I think the CNAMEed domain name should be added to the end of the o= riginal one, so the dCDN1.cdn.csp.com showed in the ab= ove figure should be cdn.csp.com.dCDN1.net.

yiqiuchao from China Mobile

From: Francois Le Fa= ucheur (flefauch)

Date: 2014-02-13 21:19

To: Kevin J M= a

CC: cdni@ietf.org
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-logging-09= .txt

Hi Kevin and all,

We just posted the updated version of&nb= sp;cdni-logging that addresses Kevin's review comm= ents as discussed on the list (including = ;latest comment about privacy).

Could you please review and let us = know if you have additional comments before&n= bsp;we move on to the next step (as = ;agreed in Vancouver) which is to submit = ;the document to Working Group Last Call?

Thanks

Francois & Iuniana

On 13 Feb 2014, at 14:10, <internet-drafts@ietf.org> <= ;internet-drafts@ietf.org&g= t; wrote:

>

> A New Internet-Draft is available f= rom the on-line Internet-Drafts directories.

> This draft is a work item of&n= bsp;the Content Delivery Networks Interconnection = Working Group of the IETF.

>

>        Title  &= nbsp;        : CDNI Loggi= ng Interface

>        Authors  = ;       : Francois Le Fau= cheur

>           =             &nb= sp;  Gilles Bertrand

>           =             &nb= sp;  Iuniana Oprescu

>           =             &nb= sp;  Roy Peterkofsky

> Filename        :&n= bsp;draft-ietf-cdni-logging-09.txt

> Pages         =   : 45

> Date         &= nbsp;  : 2014-02-13

>

> Abstract:

>   This memo specifies the Logg= ing interface between a downstream CDN

>   (dCDN) and an upstream CDN&n= bsp;(uCDN) that are interconnected as per the=

>   CDN Interconnection (CDNI) framew= ork.  First, it describes a

>   reference model for CDNI log= ging.  Then, it specifies the CDNI

>   Logging File format and the&= nbsp;actual protocol for exchange of CDNI

>   Logging Files.

>

>

> The IETF datatracker status page fo= r this draft is:

> https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/
>

> There's also a htmlized version ava= ilable at:

> http://tools.ietf.org/html/draft-ietf-cdni-logging-09

>

> A diff from the previous version&nb= sp;is available at:

> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-09=

>

>

> Please note that it may take a= couple of minutes from the time of = ;submission

> until the htmlized version and diff= are available at too= ls.ietf.org.

>

> Internet-Drafts are also available by&nb= sp;anonymous FTP at:

> ftp://ftp.ie= tf.org/internet-drafts/

>

> _______________________________________________

> CDNi mailing list

> CDNi@ietf.org

> https= ://www.ietf.org/mailman/listinfo/cdni

_______________________________________________

CDNi mailing list

CDNi@ietf.org

https://www.iet= f.org/mailman/listinfo/cdni

--_000_87114F5A16C84C77BE733FA13D0D715Eciscocom_-- From nobody Fri Feb 21 01:39:35 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 737EC1A0509 for ; Fri, 21 Feb 2014 01:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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.548, 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 vlesW2Q6tYoH for ; Fri, 21 Feb 2014 01:39:33 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E6CEC1A04BD for ; Fri, 21 Feb 2014 01:39:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=307; q=dns/txt; s=iport; t=1392975569; x=1394185169; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=o1sXsmuY+V+xmrwPPLc/8i05BhU0+OF2PdItfkjCWYc=; b=SSAyTc6tyxKYBWd6Dd9Kc+W4vJVeTTCW63JGyA0PiqqKg3wiH6Ppn6QM 4k14DPK/t0ZX9UwfViHJkwdnVoYVkfncBD7nbAJl4oeaz6TY857p7bDGK tzUyX4jlDaCkNaG4ez5kakHMSdvpKj74NtmbREGwgWKTUAmdNsqDustp3 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAIgeB1OtJV2d/2dsb2JhbABZgwaBEsFHFnSCLIELAYEAJwSIGJwNsGEXjhCDf4EUBJg0kieDLYIq X-IronPort-AV: E=Sophos;i="4.97,517,1389744000"; d="scan'208";a="305543607" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 21 Feb 2014 09:39:16 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1L9dGka022746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 21 Feb 2014 09:39:16 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.67]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 03:39:16 -0600 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: CDNI WG London Presentation Material Thread-Index: AQHPLujIJSyxkOUfAk+9/tdFWDm4Xw== Date: Fri, 21 Feb 2014 09:39:15 +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.200] 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/gkdE5sY_e3V88koGKpLqmGC1qS4 Subject: [CDNi] CDNI WG London Presentation Material 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 Feb 2014 09:39:34 -0000 To all presenters, Please aim to send Daryl and I your presentations by Friday 28 Feb. Please: * include a PDF version (so we don=92t have to go trough conversion) * include < I-D name + your name + version > in the filename * include slide number on every slide Thanks Francois & Daryl= From nobody Fri Feb 21 08:35: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 B451E1A01DC for ; Fri, 21 Feb 2014 08:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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.548, 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 Ro0t8FDeTAn0 for ; Fri, 21 Feb 2014 08:34:54 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEDB1A01BC for ; Fri, 21 Feb 2014 08:34:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4151; q=dns/txt; s=iport; t=1393000490; x=1394210090; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=N7MDDsDemdTXSglr3LslO46RleUAKdmH2U4OvFMj0YE=; b=BqJF/yGA24rMr4s7G3rlr002EndXkr0IBIW8iwXLKscXzEh7P/Ja6yMX eEUpbYfIxroM3v9a/QV+PwvdieoTFbGgWNmmFbWBgu4Lyn/u1SbrQ751p KSIAZ0g5ZPhFvsKPnqUARm/CZLUoxZBfFjUtOuV9G6ra7b4S/pD3UNXSf c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFAMp/B1OtJXG+/2dsb2JhbABagwY7UQbAPYEOFnSCJQEBAQMBdBUCAU4yJQIEARIJh3QICAXLYBeOa4MkgRQEjGSLUIEyhhKKY4Mtgio X-IronPort-AV: E=Sophos;i="4.97,520,1389744000"; d="scan'208";a="305464452" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 21 Feb 2014 16:34:50 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1LGYocN012249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Feb 2014 16:34:50 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.67]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 10:34:49 -0600 From: "Francois Le Faucheur (flefauch)" To: "draft-ietf-cdni-metadata@tools.ietf.org" , "cdni@ietf.org" Thread-Topic: WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 2] Thread-Index: AQHPLyLW+grR8OSmCE+3oXnY+ir15A== Date: Fri, 21 Feb 2014 16:34:49 +0000 Message-ID: References: <20140214214618.22993.11019.idtracker@ietfa.amsl.com> In-Reply-To: <20140214214618.22993.11019.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.200] Content-Type: text/plain; charset="Windows-1252" Content-ID: <34C57EE8ABA10640838BE005C503CDC2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/HFN_R4mCZUTAzynTiDUjEEqY9Gk Subject: [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: Fri, 21 Feb 2014 16:34:56 -0000 *** section 3.1: Table 2: "A PathMetadata object contains the CDNI GenericMetadata objects=94 Should this say =93contains or references=94? Same comment for =93GenericMetadata=94? Because of the inconsistencies in the description, I guess I am not 100% cl= ear at this stage as to whether it is always possible to "either contain or= reference=94, or whetehr there are some cases where it =93always contains= =94. Please make sure this is made clear. *** section 3.2: OLD: =93 If the dCDN does not understand or support the property type and the property type is not mandatory to enforce, then the GenericMetadata object may be safely ignored. =93 NEW: =93 If the dCDN does not understand or support the property type and the property type is not mandatory to enforce, then the GenericMetadata object may be safely ignored and the dCDN MUST process the content request in accordance with the rest of the CDNI metadata. =93 *** section 3.2:=20 " If the dCDN does not understand or support the property type it is also not going to be able to properly propagate the Metadata for cascaded distribution.=20 =93 This sentence is placed in the middle of the 2nd paragraph while it discuss= es metadata redistribution which is not the subject of the 2nd paragraph an= d is fully discussed in the 3rd paragraph. So that sentence should be remov= ed from 2nd paragraph and merged with 3rd paragraph (or removed altogether = it it is redundant with 3rd paragraph).=20 *** section 3.2 s/optimially/optimally/ ***section 3.2: I would suggest capitalizing the two terms you define everywhere to make it= clear that these are very precise terms that you define here.=20 =93Mandatory To Enforce=94 (or =93Mandatory-To-Enforce=94) =93Safe To Redistribute=94 (or =93Safe-To-Redistribute=94) another option coudl to quote the corresponding property names defined late= r ie =93madatory-to-enforce=94/=93safe-to-redistribute=94. *** section 3.3: OLD: =93 the TimeWindowACL defined in the PathMetadata would override the TimeWindowACL defined in the HostMetadata =93 NEW: =93 the TimeWindowACL defined in the PathMetadata would override the TimeWindowACL defined in the HostMetadata for all User Agent requests for content under "example.com/movies" =93 *** section 3.3: =93 The PathMetadata defined TimeWindowACL would override the TimeWindowACL defined in the HostMetadata for all User Agent requests for movies. =93 This seems 100% redundant with the previous example. If this is correct, ju= st remove. If this is not correct, clarify what extra information it brings= . *** section 3.4: =93The type SHOULD be descriptive, and MAY be hierarchical to support aggregating groups of properties for the purpose of readability and for avoiding name conflicts between vendor extensions. A dotted alpha-numeric notation is suggested for human readability.=94 I think all the normative language about metadata types shoudl be moved to = the relevant IANA sub-section (unless we conclude differently in the threa= d about that question started in the context of cdni-logging). So I=92d see= all the quoted text above be merged into the appropriate IANA sub-section.= =20 *** section 3.4: " Metadata types defined by this document are not hierarchical." I suggest adding an explanation or example about what you mean by =93hierar= chical=94. On 14 Feb 2014, at 22:46, Internet-Drafts@ietf.org wrote: >=20 > A new version (-06) has been submitted for draft-ietf-cdni-metadata: > http://www.ietf.org/internet-drafts/draft-ietf-cdni-metadata-06.txt >=20 >=20 > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata/ >=20 > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-metadata-06 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > IETF Secretariat. >=20 From nobody Fri Feb 21 10:21:11 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 1176C1A04AD for ; Fri, 21 Feb 2014 10:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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.548, 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 sTCyDlL6CmvO for ; Fri, 21 Feb 2014 10:21:07 -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 3133A1A0209 for ; Fri, 21 Feb 2014 10:21:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1018; q=dns/txt; s=iport; t=1393006863; x=1394216463; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=STo7QUYERoAlmqZBcBV/ZSE6Zd9k4uKKfcotJxGZ+Mw=; b=Szd73Dvt0WwFgeUPMrm+F72aRqgjNo9n2Uhn/qBuZeV66cF2raLssuJq F7Dz1vzN6OOri1DCfl8w6NnldbgWbnN8U5HZ+wHC3yX4vHHvkU8/45hEB tIITw6/jwTrYamPbWd1yIECsa7DlrNHDOWoVXm67gcHEzZMtBitl4rwm5 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFANqXB1OtJXG//2dsb2JhbABagwaBEsA9gQ8WdIIlAQEBAwE6PQIQAgEIDhQUEDIlAgQODYd1BwHLWBeOECMxB4MkgRQBA6pbgy2CKg X-IronPort-AV: E=Sophos;i="4.97,520,1389744000"; d="scan'208";a="305701711" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 21 Feb 2014 18:21:02 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1LIL2VJ013799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Feb 2014 18:21:02 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.138]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 12:21:02 -0600 From: "Kent Leung (kleung)" To: Mark Nottingham Thread-Topic: [CDNi] New Version Notification for draft-leung-cdni-uri-signing-04.txt Thread-Index: AQHPLbURn5JUUyTIEUaAm7vNBa9RCpq/douAgACLufA= Date: Fri, 21 Feb 2014 18:21:00 +0000 Message-ID: References: <20140214010816.22518.21143.idtracker@ietfa.amsl.com> <294BC0AD-FABA-42DA-ADDB-91F9279ACD31@mnot.net> <5CDF18BF-B0E8-4808-8F12-3333EE6B9010@mnot.net> In-Reply-To: <5CDF18BF-B0E8-4808-8F12-3333EE6B9010@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.231.219] 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/6AfHtsCgBK4Os2I9j6sszHU6fMw Cc: "cdni@ietf.org" Subject: Re: [CDNi] New Version Notification for draft-leung-cdni-uri-signing-04.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: Fri, 21 Feb 2014 18:21:09 -0000 >=20 > This would be more clear as something like: >=20 > """ > 5. Append the parameter name used to indicate the URI Signing Package Att= ribute, as communicated via the CDNI Metadata interface, followed by an "= =3D". If none(sic) is communicated by the metadata interface, it defaults t= o "URISigningPackage". For example, if the CDNI Metadata interface specifi= es "SIG", append the string "SIG=3D" to the message. > """ >=20 > and so forth. >=20 >> KL> OK. We can add an example. For your text, ""=3D". If non is communic= ated by the metadata interface, it defaults to "URISigningPackage"", are yo= u saying it's OK to default to an attribute name specified in the draft? Think so. >> If so, would this attribute name need to be IANA-based? I'd like the cla= rify the language. Don't think so... Happy to talk about it in London, though. KL>> OK. I see what you meant. What you said is fine so we are in agreement= . :) Thanks for the clarification. Kent From nobody Sat Feb 22 00:51:02 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0FB1A0104 for ; Sat, 22 Feb 2014 00:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.649 X-Spam-Level: X-Spam-Status: No, score=-8.649 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, 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 MD9oTg6bJc1i for ; Sat, 22 Feb 2014 00:50:57 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 334C81A001A for ; Sat, 22 Feb 2014 00:50:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13298; q=dns/txt; s=iport; t=1393059053; x=1394268653; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=R8lgoUX+rRjKQZUUZSKOUhNOK5wZrk9zWNZURyzpP5k=; b=jTxAK66Er6fq/LWQ9c53zN5P1DwncXGFy7gr2MrbtuqP2SdlZpjJNREt 2+WYVyFiSSqCSOFmaayiJXCkzvyKeXaSybm43Hu9XQMABFGj2Eika9nqg y71blqMmXCRPTGPHMKdQ/GWd1ZGHAswTvu2vrUckrxWmvOBB6JbMNsM9G 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAA9kCFOtJXG9/2dsb2JhbABZgwY7V8BJgQwWdIInAQQ6UQEqFEImAQQbE4dqmkuRIZ8WF414CgoHAR+DXIEUBJMqgR+WEoMtgWgJFyI X-IronPort-AV: E=Sophos;i="4.97,523,1389744000"; d="scan'208";a="22390065" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-5.cisco.com with ESMTP; 22 Feb 2014 08:50:52 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1M8oqpV021669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 22 Feb 2014 08:50:52 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.138]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Sat, 22 Feb 2014 02:50:52 -0600 From: "Matt Caulfield (mcaulfie)" To: "cdni@ietf.org" Thread-Topic: FCI Analysis Thread-Index: Ac8vqy17bD6x1Rx9Q5m5OP+H19cCRA== Date: Sat, 22 Feb 2014 08:50:51 +0000 Message-ID: <166EBB70C264A9479E459B01B1BA6C924E0D0B0F@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.86.249.138] 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/0z9krFqKkOEVfQVFyx3XfkwZyRc Subject: [CDNi] FCI Analysis 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, 22 Feb 2014 08:51:00 -0000 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 th= e following analysis.=20 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 fee= l are) the key points from each draft. Finally, my analysis comparing the d= rafts based on their approach to FCI (and not the quality or the level of d= etail in the documents). If you have not done so already, then I would also recommend reading Jon P= eterson's email from February 6 ("footprint and capabilities mechanisms").= =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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)=20 ------------------------------------------------------------- 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 cli= ent request) or state replication?=20 4) Avoiding / Handling Cheating dCDNs - capabilities should be eventually v= erifiable 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 capabi= lities are only available for specific footprints. Important to note that most footprint information will be agreed upon out o= f band (e.g. via contracts). FCI can be considered a means for providing ch= anges or updates to that previously agreed upon set of footprints and capab= ilities. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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)=20 ------------------------------------------------------------- This proposal is based on the ALTO (Application Layer Traffic Optimization)= protocol (draft-ietf-alto-protocol), currently under development by the AL= TO working group. ALTO protocol specification is currently an Active Intern= et-Draft in the "Submitted to IESG for Publication" state.=20 Each dCDN hosts an ALTO server. The uCDN uses an ALTO client to determine f= ootprint 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 t= he same capabilities.=20 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-room= e-alto-pid-properties (an active Internet-Draft). The same draft defines ru= les for implicit inheritance of properties for overlapping PIDs (e.g. one P= ID 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 a= ccessing 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 requ= irements but does not describe their encoding in depth. The ALTO protocol only registers IPv4 and IPv6 endpoint types. Assuming tha= t this draft would register ISO Country Codes and AS numbers as new endpoin= t 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).=20 The PID concept offers a level of indirection between footprints and capabi= lities allowing them to vary independently. ALTO also offers filtered querying in order to avoid fetching an entire net= work map or pid property map.=20 Future extensions to ALTO will include asynchronous notifications and incre= mental updates as described by draft-schwan-alto-incr-updates (currently an= Expired Internet-Draft). Expecting progress soon in this area from the ALT= O 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)=20 ------------------------------------------------------------- This proposal is based on a CDNI-specific representation of footprints and = capabilities. Footprints and capabilities are encoded in JSON and transport= ed via HTTP. Stated objective is to distill dCDN resource knowledge into simple set of c= apabilities and their footprints. That is, each capability has an associate= d footprint. The draft defines the same basic set of capabilities as defined in the requ= irements and provides some examples of their encoding. Each capability has a name, a list of values, and an optional list of footp= rints. 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 includ= es country code, AS number, and IP prefix. The footprint mode may be set to "replace", "include", or "exclude" which i= ndicates how the footprint should be treated with respect to "previous" foo= tprint information. In this context, "previous" refers to incremental updat= es which are sent asynchronously from the dCDN to the uCDN. The "replace" m= ode indicates that any previous information about the footprint should be d= iscarded and replaced entirely with the new information. The "include" mode= indicates an addition to the footprint while "exclude" indications a subtr= action. 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 respon= se 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 f= or updating the F&C. Updates may use "include" and "exclude" modes for part= ial updates. Each update includes a sequence numbers (via an CDNI-FCI-seq H= TTP header) in order to detect loss. Lost updates result in a reset and a r= e-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 enco= ding. This is a good starting point and is in line with current CDNI WG doc= uments (e.g. triggers and metadata drafts).=20 Data Representation: in the case of draft-seedorf, the existing ALTO repres= entations for network and property maps are leveraged. These data structure= s clearly fit the CDNI use case and have the benefit of prior review. In th= e case of draft-ma, a new CDNI-specific representation is defined. There is= no clear technical deficiency with either approach given that a newly defi= ned representation can be as flexible as needed and the ALTO representation= is generic enough to support the CDNI use case. Leveraging an existing pro= tocol 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 t= he case of draft-ma, capabilities have footprints. In the single CDN case, = neither option is deficient. In the cascaded CDN case, the draft-seedorf ap= proach seems more intuitive. Aggregated footprint and capability informatio= n is constructed simply by appending the footprints of all dCDNs.=20 Cost Information: in the case of draft-seedorf, a loose description is prov= ided 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 dC= DNs can claim the same end clients in their footprint advertisements. Howev= er, regardless of the use case, business logic is likely to kick in before = such cost metrics would be useful. Neither approach includes a definitive p= roposal in this area. Extensibility and Versioning: Versioning of the FCI protocol is not discuss= ed by either draft. Extensibility is alluded to and is clearly possible. Ho= wever, the details are lacking in this area. Dependence on ALTO WG: In the case of draft-seedorf, a dependency is introd= uced 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 th= e 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.=20 Capability Inheritance: in the case of draft-seedorf, the PID Property Map = defines rules for implicit inheritance between multiple overlapping PIDs. I= n the case of draft-ma, no special inheritance rules exist. These inheritan= ce rules may complicate implementation of FCI. Completely explicit capabili= ties, such as in draft-ma, may be a better approach. Update Notifications: in the case of draft-seedorf, no strong story for upd= ate notifications is provided. The ALTO Incremental Updates draft is refere= nced. 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. Assum= ing that update notifications is a real requirement, then draft-ma has a mo= re concrete approach in this area. However, a bidirectional HTTP interface = breaks the RESTful nature of the interface.=20 Incremental Updates: in the case of draft-seedorf, the ALTO Incremental Upd= ate draft is referenced. This draft describes the use of JSON Patch for enc= oding incremental changes to ALTO information. Additionally, ALTO allows fo= r filtered queries which could be used for obtaining partial information. I= n the case of draft-ma, a scheme including sequence numbers, a new HTTP hea= der, and a "mode" is used for conveying incremental changes via HTTP POST. = Like the update notifications, the draft-ma proposal is more concrete in th= is area. However, again, the ALTO approach is more RESTful. Additionally, a= dding a new HTTP header for this purpose may not be workable. Draft Maturity: both draft-seedorf and draft-ma require another level of de= tail. Neither describe versioning and extensibility. Neither discuss the en= coding of logging and metadata capabilities which may pose significant chal= lenges.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Conclusion ------------------------------------------------------------- All in all, both drafts are well-written and viable candidates as a startin= g point for our FCI standard.=20 I would suggest that the working group must first decide whether the benefi= ts of reusing the ALTO syntax and semantics outweigh the costs or if defini= ng something CDNI-specific is a better option. As far as I can tell, the da= ta 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-specif= ic representation provides maximum flexibility. I would also recommend that we first focus on a simple HTTP GET interface a= nd then, once stable, turn our attention to incremental updates. Cheers, Matt =20 From nobody Tue Feb 25 16:52: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 85EBC1A07A0 for ; Tue, 25 Feb 2014 16:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 aYVc0PcOSNqr for ; Tue, 25 Feb 2014 16:52:36 -0800 (PST) Received: from p01c11o148.mxlogic.net (p01c11o148.mxlogic.net [208.65.144.71]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6CD1A07C2 for ; Tue, 25 Feb 2014 16:52:36 -0800 (PST) Received: from unknown [69.25.75.234] (EHLO HUB023.mail.lan) by p01c11o148.mxlogic.net(mxl_mta-7.2.4-1) with ESMTP id 4da3d035.2b00f6c5d940.74863.00-562.200009.p01c11o148.mxlogic.net (envelope-from ); Tue, 25 Feb 2014 17:52:36 -0700 (MST) X-MXL-Hash: 530d3ad423541302-2f08313050f7f1c32a3ad8c5bfc7778ac9bbf723 Received: from unknown [69.25.75.234] (EHLO HUB023.mail.lan) by p01c11o148.mxlogic.net(mxl_mta-7.2.4-1) over TLS secured channel with ESMTP id 2da3d035.0.74856.00-364.199990.p01c11o148.mxlogic.net (envelope-from ); Tue, 25 Feb 2014 17:52:35 -0700 (MST) X-MXL-Hash: 530d3ad319145059-44874709ee4dca05d8962628a2dc5fec0e175c55 Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Tue, 25 Feb 2014 19:52:16 -0500 From: Kevin J Ma To: "Kent Leung (kleung)" , "cdni@ietf.org" Date: Tue, 25 Feb 2014 19:52:14 -0500 Thread-Topic: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-04.txt Thread-Index: AQHPKSE/6bfrvz+NZUu2V+2oz9AUzpqz8KrAgBLJqTA= Message-ID: <291CC3F9E50E7641901A54E85D0977C6D5429F1632@MAILR002.mail.lan> References: <20140214010816.22518.21143.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/wlietjsMOe0N9pMNW9t9Ute2YNQ Subject: Re: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-04.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: Wed, 26 Feb 2014 00:52:42 -0000 Hi Kent, Read through the updated draft; couple of comments below. thanx. -- Kevin J. Ma - general: "CDNI Interface" -> "CDNI interface" Francois made this comment on the metadata draft, so I assume it would apply to url signing as well. - section 2.4: "encoding sheme" -> "encoding scheme" - section 3: "step 5a-5b" -> "step 5" note: step 4 just says "step 4" step 6(A)(c): "an URI" -> "a URI" steps 6(A)(e) and 6(B)(e) are not really steps? They're just making statements about what the messages look like up through steps 6(A/B)(d)? Should they just be a comments? steps 6(A)(f) and 6(B)(g): Since the values in the "query string" are not actually going to go into the actual URI, there's no need to perform URL encoding. We should just remove that text (and possibly add a note about it)? step 6(B)(f): Where is the message digest used? second step 2: I decoded the base64 encoded value and it does not match the value in second step 1? "VER=3D1&ET=3D1209422976&CIP=3D10.0.0.1&KID=3Dfoobar:keys:123& HF=3DSHA-1&MD=3D4fb1c1adf1588fbe11cc6a04c6e69f35" !=3D "VER=3D1&ET=3D1209422976&CIP=3D10.0.0.1&KID=3Dexample:keys:123= & HF=3DSHA-256&MD=3D4fb1c1adf1588fbe11cc6a04c6e69f35" "VkVSPTEmRVQ9MTIwOTQyMjk3NiZDSVA9MTAuMC4wLjEm S0lEPWZvb2JhcjprZXlzOjEyMyZIRj1TSEEtMSZNRD00 ZmIxYzFhZGYxNTg4ZmJlMTFjYzZhMDRjNmU2OWYzNQ=3D=3D" -> "VkVSPTEmRVQ9MTIwOTQyMjk3NiZDSVA9MTAuMC4wLjEm S0lEPWV4YW1wbGU6a2V5czoxMjMmSEY9U0hBLTI1NiZN RD00ZmIxYzFhZGYxNTg4ZmJlMTFjYzZhMDRjNmU2OWYzNQ=3D=3D"? - section 4: The first paragraph discusses signing being enabled. Should it also mention checking the allowable set of dCDNs? in the first step 3, should we check that the VER is within the allowable VER set? If it's not, I assume we would want to deny the request? Should we state that? in step 8, if both MD and DS are specified, should we deny the request? in the second step 1 or 2, not only does the scheme need to be removed, but any query string parameters after the first URISigningPackage parameter also need to be discarded before beginning step 3? steps 4(A)(a) and 4(B)(a): if the KID is found but doesn't match the metadata config, or if a KID cannot be found in either the URISigningPackage or the metadata/config, or if the specified KID is not in the allowable KID set, I assume we would want to deny the request? Should we state that? step 4(A)(b): HF has a default. Is it expected that the default would be part of the config/metadata? If the specified HF is not in the allowable HF set, I assume we would want to deny the request? Should we state that? steps 4(A)(f) and 4(B)(e): Since the values were never actually in the actual URI, there's no need to perform URL decoding. We should just remove that text (and possibly add a note about it)? step 4(B)(b): Should there be an extraction step for DSA, with consideration for the default value? step 4(B)(e): Should this be a digital signature using the EC DSA algorithm? - section 5.4: "URI for a content" -> "URI for content" - section 5.5: "allowed values are:" should be before the list of values. - sections 6.1 and 6.2: missing periods in the steps inconsistent "z" usage for authori[s|z]ation (step 4 of figure 4: capitalize Authori[s|z]ation) - section 6.2: "URI Signing does match" -> "URI Signing does not match" "With DNS-based request routing, URI Signing does match well the general chain of trust model of CDNI when used with symmetric keys because the symmetric key information needs to be distributed across multiple CDNI hops including non-adjacent hops." - section 9: "approriate" -> "appropriate" "In general it" -> "In general, it" > -----Original Message----- > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Kent Leung (kleung= ) > Sent: Thursday, February 13, 2014 8:27 PM > To: cdni@ietf.org > Subject: [CDNi] FW: New Version Notification for draft-leung-cdni-uri- > signing-04.txt >=20 > FYI. This new version addressed some of the issues and comments raised > during last IETF session. The key changes are: >=20 > - Updated the document to be in line with the new approach of mandatory > packaging and encapsulated information elements. > - Only one attribute in the URI query string is used for URI Signing. The > attribute name is provided by CDNI metadata or via configuration. > - Adjusted section 2 to make a clear distinction between an information > element (the three categories) and the packaging attribute. > - Fixed inconsistencies and errors in the document which addressed Kevin'= s > comments >=20 > Kent >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, February 13, 2014 5:08 PM > To: Ray van Brandenburg; Kent Leung (kleung); Bill Downey; Bill Downey; > Scott Leibrand; Scott Leibrand; Kent Leung (kleung); Francois Le Faucheur > (flefauch); Ray van Brandenburg; Francois Le Faucheur (flefauch) > Subject: New Version Notification for draft-leung-cdni-uri-signing-04.txt >=20 >=20 > A new version of I-D, draft-leung-cdni-uri-signing-04.txt > has been successfully submitted by Kent Leung and posted to the IETF > repository. >=20 > Name: draft-leung-cdni-uri-signing > Revision: 04 > Title: URI Signing for CDN Interconnection (CDNI) > Document date: 2014-02-13 > Group: Individual Submission > Pages: 34 > URL: http://www.ietf.org/internet-drafts/draft-leung-cdni-uri- > signing-04.txt > Status: https://datatracker.ietf.org/doc/draft-leung-cdni-uri- > signing/ > Htmlized: http://tools.ietf.org/html/draft-leung-cdni-uri-signing-0= 4 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-leung-cdni-uri- > signing-04 >=20 > Abstract: > This document describes how the concept of URI signing supports the > content access control requirements of CDNI and proposes a URI > signing scheme. >=20 > The proposed URI signing method specifies the information needed to > be included in the URI and the algorithm used to authorize and to > validate access requests for the content referenced by the URI. Some > of the information may be accessed by the CDN via configuration or > CDNI metadata. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Thu Feb 27 06:17: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 2AB791A028D for ; Thu, 27 Feb 2014 06:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 u_308yBo1yHH for ; Thu, 27 Feb 2014 06:17:24 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id C5DB31A01E8 for ; Thu, 27 Feb 2014 06:17:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id B40DE106D38; Thu, 27 Feb 2014 15:17:21 +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 D1slO0EilJlX; Thu, 27 Feb 2014 15:17:21 +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 94158106E8A; Thu, 27 Feb 2014 15:17:11 +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; Thu, 27 Feb 2014 15:16:50 +0100 From: Jan Seedorf To: "Matt Caulfield (mcaulfie)" , "cdni@ietf.org" Thread-Topic: FCI Analysis Thread-Index: Ac8vqy17bD6x1Rx9Q5m5OP+H19cCRAEGDfig Date: Thu, 27 Feb 2014 14:16:50 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE63B272BC@PALLENE.office.hd> References: <166EBB70C264A9479E459B01B1BA6C924E0D0B0F@xmb-aln-x03.cisco.com> In-Reply-To: <166EBB70C264A9479E459B01B1BA6C924E0D0B0F@xmb-aln-x03.cisco.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.5.89] 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/_t5oLVWLvFsgr4hvVyY4nK5NXSA Subject: Re: [CDNi] FCI Analysis 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, 27 Feb 2014 14:17:29 -0000 Hi Matt, Thanks for your detailed analysis and summary below. Regarding the ALTO pro= posal (draft-seedorf-cdni-request-routing-alto), I can confirm that each ti= me you state "presumably" or similar below (where the draft is not 100% cle= ar and you assume something), your assumptions are correct regarding the AL= TO draft. Thanks for the nice to-do list for the next revision, telling us = where we need to be more precise and also match the requirements. I also agree with your conclusion (I stated this before on this list): ALTO= is mature (error handling, security, encoding) and RESTful, but at the sam= e time may bring some baggage plus dependency on the ALTO WG. > I would also recommend that we first focus on a simple HTTP GET interface > and then, once stable, turn our attention to incremental updates. Actually, I have wanted to comment on this issue for some time now in a sim= ilar fashion: For me, incremental updates are useful for CDNI FCI, but not = a must-have for the initial CDNI specifications. After all, everything woul= d work without incremental updates, it is just an optimization to avoid hig= h traffic volumes for ALTO. And compared to e.g. ALTO for P2P, there will o= nly be a few dCDNs per uCDN (certainly not in the range of 10.000s), and it= is also not clear that footprint/capability information will change on a h= igh frequency. Do not get me wrong, incremental updates are very useful for= CDNI FCI, just in my view not a must-have for the initial specification. T= hus I am not worried about this dependency on the ALTO WG. Btw, draft-schwa= n-alto-incr-updates (the document on ALTO incremental updates) has only exp= ired because the ALTO WG decided to focus on finalizing the core ALTO speci= fication first, before turning its attention on enhancements. Right now, th= e ALTO WG is re-chartering and incremental updates are on top of the list; = and in my view draft-schwan-alto-incr-updates is quite mature and will make= progress now. Again, Matt: thanks for your efforts! - 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 >=20 > As promised in Vancouver, I have read through the two current FCI proposa= ls > (along with some of their normative references) and I have put together t= he > following analysis. >=20 > The text below first reviews the CDNI Requirements for FCI as well as som= e > of the highlights from the FCI Semantics. Next, a short list of (what I f= eel 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 detai= l in > the documents). >=20 > If you have not done so already, then I would also recommend reading Jon > Peterson's email from February 6 ("footprint and capabilities mechanisms"= ). >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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. capabiliti= es, > 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) >=20 > The FCI must also support extensibility and versioning for new capabiliti= es > and footprints. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > FCI Semantics (draft-ietf-cdni-footprint-capabilities-semantics) > ------------------------------------------------------------- > Design Decisions > 1) Advertising Limited Coverage - should footprints be binary or rated vi= a > qualitative score? > 2) Capabilities and Dynamic Data - what capabilities are static vs dynami= c? 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 >=20 > Mandatory footprint types: > 1) List of ISO Country Codes > 2) List of AS numbers > 3) Set of IP-prefixes >=20 > FCI must be able to convey the entire footprint/capabilities and optional= ly > dynamic updates. >=20 > Footprints and Capabilities are dependent and tied together. Certain > capabilities are only available for specific footprints. >=20 > 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. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > FCI using ALTO (draft-seedorf-cdni-request-routing-alto-06) > ------------------------------------------------------------- > This proposal is based on the ALTO (Application Layer Traffic Optimizatio= n) > protocol (draft-ietf-alto-protocol), currently under development by the A= LTO > working group. ALTO protocol specification is currently an Active Interne= t- > Draft in the "Submitted to IESG for Publication" state. >=20 > Each dCDN hosts an ALTO server. The uCDN uses an ALTO client to determine > footprint and capabilities of dCDN. >=20 > 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. >=20 > Each PID is associated with a set of properties. Each property correspond= s 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 ru= les > 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 t= his > 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)). >=20 > 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. >=20 > The draft defines the same basic set of capabilities as defined in the > requirements but does not describe their encoding in depth. >=20 > 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. >=20 > ALTO Cost Map could be used to determine the cost of the dCDN delivering > to each group of endpoints (PID). >=20 > The PID concept offers a level of indirection between footprints and > capabilities allowing them to vary independently. >=20 > ALTO also offers filtered querying in order to avoid fetching an entire > network map or pid property map. >=20 > 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 ar= ea > from the ALTO WG. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > FCI using HTTP and CDNI-specific Representation (draft-ma-cdni-capabiliti= es- > 04) > ------------------------------------------------------------- > This proposal is based on a CDNI-specific representation of footprints an= d > capabilities. Footprints and capabilities are encoded in JSON and transpo= rted > via HTTP. >=20 > Stated objective is to distill dCDN resource knowledge into simple set of > capabilities and their footprints. That is, each capability has an associ= ated > footprint. >=20 > The draft defines the same basic set of capabilities as defined in the > requirements and provides some examples of their encoding. >=20 > Each capability has a name, a list of values, and an optional list of foo= tprints. > The list of values is specific to the capability name. >=20 > 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 fo= otprint > type. A registry is defined for footprint types and includes country code= , AS > number, and IP prefix. >=20 > 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 footprin= t > should be discarded and replaced entirely with the new information. The > "include" mode indicates an addition to the footprint while "exclude" > indications a subtraction. >=20 > The draft does not provide a means for conveying footprint cost informati= on. >=20 > 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 th= e > state of the uCDN. In response to a GET, all modes are set to "replace". >=20 > 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 a= n > CDNI-FCI-seq HTTP header) in order to detect loss. Lost updates result in= a > reset and a re-initialization. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Analysis > ------------------------------------------------------------- >=20 > 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). >=20 > 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 re= view. > In the case of draft-ma, a new CDNI-specific representation is defined. T= here > 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 wheth= er > or not adding a dependency on the ALTO WG will be problematic in any way. >=20 > Hierarchy: in the case of draft-seedorf, footprints have capabilities. In= the > case of draft-ma, capabilities have footprints. In the single CDN case, n= either > 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. >=20 > Cost Information: in the case of draft-seedorf, a loose description is pr= ovided > 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 dCDN= s > can claim the same end clients in their footprint advertisements. However= , > regardless of the use case, business logic is likely to kick in before su= ch cost > metrics would be useful. Neither approach includes a definitive proposal = in > this area. >=20 > Extensibility and Versioning: Versioning of the FCI protocol is not discu= ssed > by either draft. Extensibility is alluded to and is clearly possible. How= ever, the > details are lacking in this area. >=20 > 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 dr= aft- > ma, no such dependency is required. The benefits of leveraging ALTO inclu= de > the ability to easily reuse the work that the ALTO WG has done in hardeni= ng > the error handling, security, encoding, and processing of the ALTO protoc= ol. > However, the difficulty of these efforts is not insurmountable and could = be > reproduced in a CDNI-specific proposal. >=20 > Capability Inheritance: in the case of draft-seedorf, the PID Property Ma= p > defines rules for implicit inheritance between multiple overlapping PIDs.= In > the case of draft-ma, no special inheritance rules exist. These inheritan= ce > rules may complicate implementation of FCI. Completely explicit capabilit= ies, > such as in draft-ma, may be a better approach. >=20 > Update Notifications: in the case of draft-seedorf, no strong story for u= pdate > notifications is provided. The ALTO Incremental Updates draft is referenc= ed. > 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. >=20 > Incremental Updates: in the case of draft-seedorf, the ALTO Incremental > Update draft is referenced. This draft describes the use of JSON Patch fo= r > encoding incremental changes to ALTO information. Additionally, ALTO allo= ws > for filtered queries which could be used for obtaining partial informatio= n. 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 concre= te > in this area. However, again, the ALTO approach is more RESTful. Addition= ally, > adding a new HTTP header for this purpose may not be workable. >=20 > Draft Maturity: both draft-seedorf and draft-ma require another level of > detail. Neither describe versioning and extensibility. Neither discuss th= e > encoding of logging and metadata capabilities which may pose significant > challenges. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Conclusion > ------------------------------------------------------------- > All in all, both drafts are well-written and viable candidates as a start= ing point > for our FCI standard. >=20 > I would suggest that the working group must first decide whether the > benefits of reusing the ALTO syntax and semantics outweigh the costs or i= f > 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. >=20 > I would also recommend that we first focus on a simple HTTP GET interface > and then, once stable, turn our attention to incremental updates. >=20 > Cheers, > Matt >=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Thu Feb 27 06:30: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 C11DB1A02CB for ; Thu, 27 Feb 2014 06:30:32 -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 HgXapECWNdDU for ; Thu, 27 Feb 2014 06:30:29 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 510941A02E0 for ; Thu, 27 Feb 2014 06:30:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 8BBAC106E8B; Thu, 27 Feb 2014 15:30:27 +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 xE2FPYiXkLgA; Thu, 27 Feb 2014 15:30:27 +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 6C1BC106E86; Thu, 27 Feb 2014 15:30:12 +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; Thu, 27 Feb 2014 15:29:51 +0100 From: Jan Seedorf To: "cdni@ietf.org" Thread-Topic: CDNI FCI meeting at IETF-89 Thread-Index: Ac8zyF3Yu5l8TaDNRtCX/eqLbyHWsA== Date: Thu, 27 Feb 2014 14:29:51 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE63B28309@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.1.5.89] 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/uGHIjfONsbk5kkM37Ha5pw-S2Sg Subject: [CDNi] 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: Thu, 27 Feb 2014 14:30:33 -0000 Dear all, I took the liberty of setting up a doodle to have some discussions on how t= o 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 afrai= d 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 ho= pefully enlighten us on the ALTO WG timeframe and re-chartering, as depende= ncy 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 meet= ing 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 >=20 > As promised in Vancouver, I have read through the two current FCI proposa= ls > (along with some of their normative references) and I have put together t= he > following analysis. >=20 > The text below first reviews the CDNI Requirements for FCI as well as som= e > of the highlights from the FCI Semantics. Next, a short list of (what I f= eel 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 detai= l in > the documents). >=20 > If you have not done so already, then I would also recommend reading Jon > Peterson's email from February 6 ("footprint and capabilities mechanisms"= ). >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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. capabiliti= es, > 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) >=20 > The FCI must also support extensibility and versioning for new capabiliti= es > and footprints. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > FCI Semantics (draft-ietf-cdni-footprint-capabilities-semantics) > ------------------------------------------------------------- > Design Decisions > 1) Advertising Limited Coverage - should footprints be binary or rated vi= a > qualitative score? > 2) Capabilities and Dynamic Data - what capabilities are static vs dynami= c? 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 >=20 > Mandatory footprint types: > 1) List of ISO Country Codes > 2) List of AS numbers > 3) Set of IP-prefixes >=20 > FCI must be able to convey the entire footprint/capabilities and optional= ly > dynamic updates. >=20 > Footprints and Capabilities are dependent and tied together. Certain > capabilities are only available for specific footprints. >=20 > 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. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > FCI using ALTO (draft-seedorf-cdni-request-routing-alto-06) > ------------------------------------------------------------- > This proposal is based on the ALTO (Application Layer Traffic Optimizatio= n) > protocol (draft-ietf-alto-protocol), currently under development by the A= LTO > working group. ALTO protocol specification is currently an Active Interne= t- > Draft in the "Submitted to IESG for Publication" state. >=20 > Each dCDN hosts an ALTO server. The uCDN uses an ALTO client to determine > footprint and capabilities of dCDN. >=20 > 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. >=20 > Each PID is associated with a set of properties. Each property correspond= s 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 ru= les > 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 t= his > 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)). >=20 > 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. >=20 > The draft defines the same basic set of capabilities as defined in the > requirements but does not describe their encoding in depth. >=20 > 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. >=20 > ALTO Cost Map could be used to determine the cost of the dCDN delivering > to each group of endpoints (PID). >=20 > The PID concept offers a level of indirection between footprints and > capabilities allowing them to vary independently. >=20 > ALTO also offers filtered querying in order to avoid fetching an entire > network map or pid property map. >=20 > 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 ar= ea > from the ALTO WG. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > FCI using HTTP and CDNI-specific Representation (draft-ma-cdni-capabiliti= es- > 04) > ------------------------------------------------------------- > This proposal is based on a CDNI-specific representation of footprints an= d > capabilities. Footprints and capabilities are encoded in JSON and transpo= rted > via HTTP. >=20 > Stated objective is to distill dCDN resource knowledge into simple set of > capabilities and their footprints. That is, each capability has an associ= ated > footprint. >=20 > The draft defines the same basic set of capabilities as defined in the > requirements and provides some examples of their encoding. >=20 > Each capability has a name, a list of values, and an optional list of foo= tprints. > The list of values is specific to the capability name. >=20 > 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 fo= otprint > type. A registry is defined for footprint types and includes country code= , AS > number, and IP prefix. >=20 > 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 footprin= t > should be discarded and replaced entirely with the new information. The > "include" mode indicates an addition to the footprint while "exclude" > indications a subtraction. >=20 > The draft does not provide a means for conveying footprint cost informati= on. >=20 > 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 th= e > state of the uCDN. In response to a GET, all modes are set to "replace". >=20 > 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 a= n > CDNI-FCI-seq HTTP header) in order to detect loss. Lost updates result in= a > reset and a re-initialization. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Analysis > ------------------------------------------------------------- >=20 > 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). >=20 > 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 re= view. > In the case of draft-ma, a new CDNI-specific representation is defined. T= here > 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 wheth= er > or not adding a dependency on the ALTO WG will be problematic in any way. >=20 > Hierarchy: in the case of draft-seedorf, footprints have capabilities. In= the > case of draft-ma, capabilities have footprints. In the single CDN case, n= either > 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. >=20 > Cost Information: in the case of draft-seedorf, a loose description is pr= ovided > 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 dCDN= s > can claim the same end clients in their footprint advertisements. However= , > regardless of the use case, business logic is likely to kick in before su= ch cost > metrics would be useful. Neither approach includes a definitive proposal = in > this area. >=20 > Extensibility and Versioning: Versioning of the FCI protocol is not discu= ssed > by either draft. Extensibility is alluded to and is clearly possible. How= ever, the > details are lacking in this area. >=20 > 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 dr= aft- > ma, no such dependency is required. The benefits of leveraging ALTO inclu= de > the ability to easily reuse the work that the ALTO WG has done in hardeni= ng > the error handling, security, encoding, and processing of the ALTO protoc= ol. > However, the difficulty of these efforts is not insurmountable and could = be > reproduced in a CDNI-specific proposal. >=20 > Capability Inheritance: in the case of draft-seedorf, the PID Property Ma= p > defines rules for implicit inheritance between multiple overlapping PIDs.= In > the case of draft-ma, no special inheritance rules exist. These inheritan= ce > rules may complicate implementation of FCI. Completely explicit capabilit= ies, > such as in draft-ma, may be a better approach. >=20 > Update Notifications: in the case of draft-seedorf, no strong story for u= pdate > notifications is provided. The ALTO Incremental Updates draft is referenc= ed. > 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. >=20 > Incremental Updates: in the case of draft-seedorf, the ALTO Incremental > Update draft is referenced. This draft describes the use of JSON Patch fo= r > encoding incremental changes to ALTO information. Additionally, ALTO allo= ws > for filtered queries which could be used for obtaining partial informatio= n. 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 concre= te > in this area. However, again, the ALTO approach is more RESTful. Addition= ally, > adding a new HTTP header for this purpose may not be workable. >=20 > Draft Maturity: both draft-seedorf and draft-ma require another level of > detail. Neither describe versioning and extensibility. Neither discuss th= e > encoding of logging and metadata capabilities which may pose significant > challenges. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Conclusion > ------------------------------------------------------------- > All in all, both drafts are well-written and viable candidates as a start= ing point > for our FCI standard. >=20 > I would suggest that the working group must first decide whether the > benefits of reusing the ALTO syntax and semantics outweigh the costs or i= f > 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. >=20 > I would also recommend that we first focus on a simple HTTP GET interface > and then, once stable, turn our attention to incremental updates. >=20 > Cheers, > Matt >=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Fri Feb 28 05:43: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 DDF141A0291 for ; Fri, 28 Feb 2014 05:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.401 X-Spam-Level: X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 YNqlK28tww65 for ; Fri, 28 Feb 2014 05:43:17 -0800 (PST) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 976941A01F7 for ; Fri, 28 Feb 2014 05:43:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1393595090; x=1708950308; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=cN9EEeXF9FHzx/rW0UgURd540JT9JIiD7hODTTDG8XE=; b=CJgP0rFe4faolxI0ZOsM7D5UmQjB5wooVkRKwH8JJgH6KqkIMRAFHylJuYk1TE DC4rWUncTb+LQAo2NoHVD2ng== Received: from ([10.31.58.71]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.36053014; Fri, 28 Feb 2014 08:44:48 -0500 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.252]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Fri, 28 Feb 2014 08:43:07 -0500 From: "Peterson, Jon" To: "'Francois Le Faucheur (flefauch)'" Thread-Topic: IANA instructions Re: [CDNi] I-D Action: draft-ietf-cdni-logging-09.txt Thread-Index: AQHPKLz4hJUBc0CObkCC9igyaGXLXJqzfu6AgAifPoCAAmmxgIAMPK4F Date: Fri, 28 Feb 2014 13:43:07 +0000 Message-ID: <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.31.15.96] Content-Type: multipart/alternative; boundary="_000_596979554D802045BBD45C051A4399E40D441952STNTEXMB10cisne_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/Zt3DfDkZ5mvPpEBAROOitNZXIuU 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: Fri, 28 Feb 2014 13:43:19 -0000 --_000_596979554D802045BBD45C051A4399E40D441952STNTEXMB10cisne_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8sIEkgcmVjb21tZW5kZWQgcmVtb3ZpbmcgdGhlIG5vcm1hdGl2ZSBsYW5ndWFnZSBiZWNhdXNl IFJGQzIxMTkgbGFuZ3VhZ2UgaXMgbm90IGFwcGxpY2FibGUgdG8gSUFOQSBDb25zaWRlcmF0aW9u cy4gU3RyaWN0bHkgc3BlYWtpbmcsIFJGQzIxMTkgbm9ybWF0aXZlIHByaW1pdGl2ZXMgYXJlIGlu dGVuZGVkIHRvIGNvbnN0cmFpbiBpbXBsZW1lbnRhdGlvbiBiZWhhdmlvciwgZm9yIGNvbmZvcm1h bmNlIHRlc3RpbmcsIGFuZCBub3QgdG8gc2hhcGUgaW50ZXJuYWwgSUVURiBwcm9jZXNzLiBXZSBz b21ldGltZXMgc2VlIG5vcm1hdGl2ZSBsYW5ndWFnZSBpbiByZXF1aXJlbWVudHMgZm9yIGZ1dHVy ZSBzcGVjaWZpY2F0aW9ucyAoZS5nLiwgInRoZSBldmVudHVhbCBzb2x1dGlvbiBTSE9VTEQgc3Vw cG9ydCBhbnljYXN0IikgYnV0IGV2ZW4gdGhpcyBpcyBhIGJpdCBkb2RneS4NCg0KTm93IHRoYXQg bXVjaCBzYWlkLCBJIGRvdWJ0IElBTkEgd291bGQgYmUgY29uZnVzZWQgYnkgTVVTVCBzdGF0ZW1l bnRzLCBidXQgSSB3b3VsZCBzdGlsbCByZWNvbW1lbmQgY2hhbmdpbmcgdGhlIGxhbmd1YWdlIGlu IHRoZSBsb2dnaW5nIGRyYWZ0IHRvIGxvd2VyIGNhc2UgdGVybXMgcmF0aGVyIHRoYW4gMjExOSBw cmltaXRpdmVzLCBhbmQgYXZvaWRpbmcgYW55dGhpbmcgdGhhdCBsb29rcyBsaWtlIGEgTUFZIG9y IFNIT1VMRC4gSWYgeW91IHdhbnQgdG8gZW5mb3JjZSBjb25zdHJhaW50cyBvbiBwYXJhbWV0ZXIg cmVnaXN0cmF0aW9ucywgeW91IG5lZWQgdG8gc2V0IGEgcG9saWN5IG90aGVyIHRoYW4gIlNwZWMg UmVxdWlyZWQiLCBwcm9iYWJseSAiRXhwZXJ0IFJldmlldyIgYnkgc29tZW9uZSB3aG8gdW5kZXJz dGFuZHMgdGhlIGNvbnN0cmFpbnRzLiBXZSBjYW4ndCBleHBlY3QgSUFOQSB0byB1bmRlcnN0YW5k IHdoZW4gY29uZGl0aW9ucyBsaWtlIHRob3NlIGluIHRoZSBsYXN0IHBhcmFncmFwaCBvZiA1LjMg YXJlIG1ldC4NCg0KSm9uIFBldGVyc29uDQpOZXVzdGFyLCBJbmMuDQoNCg0KDQpTZW50IHdpdGgg R29vZCAod3d3Lmdvb2QuY29tKQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBGcmFuY29pcyBMZSBGYXVjaGV1ciAoZmxlZmF1Y2gpIFtmbGVmYXVjaEBjaXNjby5jb208bWFp bHRvOmZsZWZhdWNoQGNpc2NvLmNvbT5dDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMjAsIDIw MTQgMDg6NTEgQU0gRWFzdGVybiBTdGFuZGFyZCBUaW1lDQpUbzogUGV0ZXJzb24sIEpvbg0KQ2M6 IEZyYW5jb2lzIExlIEZhdWNoZXVyIChmbGVmYXVjaCk7IGNkbmlAaWV0Zi5vcmc7IEtldmluIEog TWENClN1YmplY3Q6IElBTkEgaW5zdHJ1Y3Rpb25zIFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJh ZnQtaWV0Zi1jZG5pLWxvZ2dpbmctMDkudHh0DQoNCg0KSGkgSm9uLA0KDQpJbiBoaXMgcmV2aWV3 IGNvbW1lbnRzIG9uIGNkbmktbG9nZ2luZywgS2V2aW4gc2FpZDoNCg0KT24gMTkgRmViIDIwMTQs IGF0IDAyOjAwLCBLZXZpbiBKIE1hIDxrZXZpbi5tYUBhenVraXN5c3RlbXMuY29tPiB3cm90ZToN Cj4NCj4gc2VjdGlvbiA1Lng6IEpvbiBoYWQgYSBjb21tZW50IG9uIHRoZSBGQ0kgc2VtYW50aWNz IGRyYWZ0IHRvIHJlbW92ZQ0KPiAgICAgICAgICAgICBub3JtYXRpdmUgbGFuZ3VhZ2UgZnJvbSBJ QU5BIGluc3RydWN0aW9ucyAod2hpY2ggd2UgYWxzbw0KPiAgICAgICAgICAgICBhcHBsaWVkIHRv IHRoZSBNSSBkcmFmdCkuICBXZSBwcm9iYWJseSB3YW50IHRvIGRvIHRoZQ0KPiAgICAgICAgICAg ICBzYW1lIGhlcmU/DQo+DQoNCldhcyB0aGUgcmVhc29uIGZvciB3aGljaCB5b3UgcmVjb21tZW5k ZWQgdGhhdCB0aGUgRkNJIHNlbWFudGljcyBJLUQgcmVtb3ZlcyBub3JtYXRpdmUgbGFuZ3VhZ2Ug ZnJvbSBJQU5BIGluc3RydWN0aW9ucyB0aGUgZmFjdCB0aGF0IEZDSSBzZW1hbnRpY3MgaXMgZ29p bmcgZm9yIEluZm9ybWF0aW9uYWwgVHJhY2s/DQpJZiB5ZXMsIHRoZW4gdGhhdCB3b3VsZCBub3Qg YXBwbHkgdG8gY2RuaS1sb2dnaW5nLg0KSWYgbm8sIGNhbiB5b3UgZGVzY3JpYmUgdGhlIHJlYXNv biBhbmQgd2hldGhlci9ob3cgeW91IHNlZSB0aGF0IGltcGFjdGluZyAob3Igbm90KSBjZG5pLWxv Z2dpbmcsIGdpdmVuIHRoZSBjdXJyZW50IElBTkEgc2VjdGlvbiB3b3JkaW5nPw0KDQpUaGFua3MN Cg0KRnJhbmNvaXMNCg== --_000_596979554D802045BBD45C051A4399E40D441952STNTEXMB10cisne_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPGh0bWw+ DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVudD0iSFRN TCBUaWR5IGZvciBXaW5kb3dzICh2ZXJzIDI1IE1hcmNoIDIwMDkpLCBzZWUgd3d3LnczLm9yZyI+ DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1TIEV4Y2hhbmdlIFNlcnZlciB2ZXJz aW9uIDE0LjAzLjAxNTcuMDAwIj4NCjx0aXRsZT5JQU5BIGluc3RydWN0aW9ucyBSZTogW0NETmld IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS1sb2dnaW5nLTA5LnR4dDwvdGl0bGU+DQo8L2hl YWQ+DQo8Ym9keT4NCk5vLCBJIHJlY29tbWVuZGVkIHJlbW92aW5nIHRoZSBub3JtYXRpdmUgbGFu Z3VhZ2UgYmVjYXVzZSBSRkMyMTE5IGxhbmd1YWdlIGlzIG5vdCBhcHBsaWNhYmxlIHRvIElBTkEg Q29uc2lkZXJhdGlvbnMuIFN0cmljdGx5IHNwZWFraW5nLCBSRkMyMTE5IG5vcm1hdGl2ZSBwcmlt aXRpdmVzIGFyZSBpbnRlbmRlZCB0byBjb25zdHJhaW4gaW1wbGVtZW50YXRpb24gYmVoYXZpb3Is IGZvciBjb25mb3JtYW5jZSB0ZXN0aW5nLCBhbmQgbm90IHRvIHNoYXBlDQogaW50ZXJuYWwgSUVU RiBwcm9jZXNzLiBXZSBzb21ldGltZXMgc2VlIG5vcm1hdGl2ZSBsYW5ndWFnZSBpbiByZXF1aXJl bWVudHMgZm9yIGZ1dHVyZSBzcGVjaWZpY2F0aW9ucyAoZS5nLiwgJnF1b3Q7dGhlIGV2ZW50dWFs IHNvbHV0aW9uIFNIT1VMRCBzdXBwb3J0IGFueWNhc3QmcXVvdDspIGJ1dCBldmVuIHRoaXMgaXMg YSBiaXQgZG9kZ3kuPGJyPg0KPGJyPg0KTm93IHRoYXQgbXVjaCBzYWlkLCBJIGRvdWJ0IElBTkEg d291bGQgYmUgY29uZnVzZWQgYnkgTVVTVCBzdGF0ZW1lbnRzLCBidXQgSSB3b3VsZCBzdGlsbCBy ZWNvbW1lbmQgY2hhbmdpbmcgdGhlIGxhbmd1YWdlIGluIHRoZSBsb2dnaW5nIGRyYWZ0IHRvIGxv d2VyIGNhc2UgdGVybXMgcmF0aGVyIHRoYW4gMjExOSBwcmltaXRpdmVzLCBhbmQgYXZvaWRpbmcg YW55dGhpbmcgdGhhdCBsb29rcyBsaWtlIGEgTUFZIG9yIFNIT1VMRC4gSWYgeW91IHdhbnQNCiB0 byBlbmZvcmNlIGNvbnN0cmFpbnRzIG9uIHBhcmFtZXRlciByZWdpc3RyYXRpb25zLCB5b3UgbmVl ZCB0byBzZXQgYSBwb2xpY3kgb3RoZXIgdGhhbiAmcXVvdDtTcGVjIFJlcXVpcmVkJnF1b3Q7LCBw cm9iYWJseSAmcXVvdDtFeHBlcnQgUmV2aWV3JnF1b3Q7IGJ5IHNvbWVvbmUgd2hvIHVuZGVyc3Rh bmRzIHRoZSBjb25zdHJhaW50cy4gV2UgY2FuJ3QgZXhwZWN0IElBTkEgdG8gdW5kZXJzdGFuZCB3 aGVuIGNvbmRpdGlvbnMgbGlrZSB0aG9zZSBpbiB0aGUgbGFzdCBwYXJhZ3JhcGgNCiBvZiA1LjMg YXJlIG1ldC48YnI+DQo8YnI+DQpKb24gUGV0ZXJzb248YnI+DQpOZXVzdGFyLCBJbmMuPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KU2VudCB3aXRoIEdvb2QgKHd3dy5nb29kLmNvbSk8YnI+DQo8YnI+ DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCjxiPkZyb206Jm5ic3A7PC9i PkZyYW5jb2lzIExlIEZhdWNoZXVyIChmbGVmYXVjaCkgWzxhIGhyZWY9Im1haWx0bzpmbGVmYXVj aEBjaXNjby5jb20iPmZsZWZhdWNoQGNpc2NvLmNvbTwvYT5dPGJyPg0KPGI+U2VudDombmJzcDs8 L2I+VGh1cnNkYXksIEZlYnJ1YXJ5IDIwLCAyMDE0IDA4OjUxIEFNIEVhc3Rlcm4gU3RhbmRhcmQg VGltZTxicj4NCjxiPlRvOiZuYnNwOzwvYj5QZXRlcnNvbiwgSm9uPGJyPg0KPGI+Q2M6Jm5ic3A7 PC9iPkZyYW5jb2lzIExlIEZhdWNoZXVyIChmbGVmYXVjaCk7IGNkbmlAaWV0Zi5vcmc7IEtldmlu IEogTWE8YnI+DQo8Yj5TdWJqZWN0OiZuYnNwOzwvYj5JQU5BIGluc3RydWN0aW9ucyBSZTogW0NE TmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS1sb2dnaW5nLTA5LnR4dDxicj4NCjxicj4N CjwhLS0gQ29udmVydGVkIGZyb20gdGV4dC9wbGFpbiBmb3JtYXQgLS0+DQo8cD48Zm9udCBzaXpl PSIyIj5IaSBKb24sPGJyPg0KPGJyPg0KSW4gaGlzIHJldmlldyBjb21tZW50cyBvbiBjZG5pLWxv Z2dpbmcsIEtldmluIHNhaWQ6PGJyPg0KPGJyPg0KT24gMTkgRmViIDIwMTQsIGF0IDAyOjAwLCBL ZXZpbiBKIE1hICZsdDtrZXZpbi5tYUBhenVraXN5c3RlbXMuY29tJmd0OyB3cm90ZTo8YnI+DQom Z3Q7PGJyPg0KJmd0OyBzZWN0aW9uIDUueDogSm9uIGhhZCBhIGNvbW1lbnQgb24gdGhlIEZDSSBz ZW1hbnRpY3MgZHJhZnQgdG8gcmVtb3ZlPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBub3JtYXRp dmUgbGFuZ3VhZ2UgZnJvbSBJQU5BIGluc3RydWN0aW9ucyAod2hpY2ggd2UgYWxzbzxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgYXBwbGllZCB0byB0aGUgTUkgZHJhZnQpLiZuYnNwOyBXZSBwcm9i YWJseSB3YW50IHRvIGRvIHRoZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2FtZSBoZXJlPzxi cj4NCiZndDs8YnI+DQo8YnI+DQpXYXMgdGhlIHJlYXNvbiBmb3Igd2hpY2ggeW91IHJlY29tbWVu ZGVkIHRoYXQgdGhlIEZDSSBzZW1hbnRpY3MgSS1EIHJlbW92ZXMgbm9ybWF0aXZlIGxhbmd1YWdl IGZyb20gSUFOQSBpbnN0cnVjdGlvbnMgdGhlIGZhY3QgdGhhdCBGQ0kgc2VtYW50aWNzIGlzIGdv aW5nIGZvciBJbmZvcm1hdGlvbmFsIFRyYWNrPzxicj4NCklmIHllcywgdGhlbiB0aGF0IHdvdWxk IG5vdCBhcHBseSB0byBjZG5pLWxvZ2dpbmcuPGJyPg0KSWYgbm8sIGNhbiB5b3UgZGVzY3JpYmUg dGhlIHJlYXNvbiBhbmQgd2hldGhlci9ob3cgeW91IHNlZSB0aGF0IGltcGFjdGluZyAob3Igbm90 KSBjZG5pLWxvZ2dpbmcsIGdpdmVuIHRoZSBjdXJyZW50IElBTkEgc2VjdGlvbiB3b3JkaW5nPzxi cj4NCjxicj4NClRoYW5rczxicj4NCjxicj4NCkZyYW5jb2lzPC9mb250PjwvcD4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_596979554D802045BBD45C051A4399E40D441952STNTEXMB10cisne_-- From nobody Fri Feb 28 08:38: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 1E6A91A02FF for ; Fri, 28 Feb 2014 08:38:53 -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 DZDb9yE-98kq for ; Fri, 28 Feb 2014 08:38:49 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC031A0238 for ; Fri, 28 Feb 2014 08:38:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id E4BB9106EB4 for ; Fri, 28 Feb 2014 17:38:45 +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 ocf9RLlPL0k5 for ; Fri, 28 Feb 2014 17:38:45 +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 BDDD6106EB3 for ; Fri, 28 Feb 2014 17:38:40 +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; Fri, 28 Feb 2014 17:38:40 +0100 From: Jan Seedorf To: "cdni@ietf.org" Thread-Topic: CDNI FCI meeting at IETF-89 Thread-Index: Ac8zyF3Yu5l8TaDNRtCX/eqLbyHWsAA2g9zQ Date: Fri, 28 Feb 2014 16:38:40 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE63B28B24@PALLENE.office.hd> References: <2779C9F0771F974CAD742BAE6D9904FE63B28309@PALLENE.office.hd> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE63B28309@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.200] 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/gn9ZLSoBH_-E0oPJ3pZ9LF1YAp8 Subject: Re: [CDNi] 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: Fri, 28 Feb 2014 16:38:53 -0000 Thanks to all who filled in the doodle so far, it seems that TUE 13:00-15:0= 0 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 >=20 > Dear all, >=20 > 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 afr= aid it > will not be enough if we want to make some progress): >=20 > http://www.doodle.com/xfn59dgm5nit9v4a#table >=20 > 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. >=20 > Please all fill in the doodle if you would like to participate in this me= eting at > IETF-89. >=20 > - Jan >=20 > > -----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 s= ome > > 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 draf= ts > > based on their approach to FCI (and not the quality or the level of det= ail in > > the documents). > > > > If you have not done so already, then I would also recommend reading J= on > > 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. capabili= ties, > > 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 capabili= ties > > 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 dyna= mic? 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 eventual= ly > > 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 option= ally > > 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 o= ut > 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 Optimizat= ion) > > protocol (draft-ietf-alto-protocol), currently under development by the > ALTO > > working group. ALTO protocol specification is currently an Active Inter= net- > > 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 sing= le > PID > > share the same capabilities. > > > > Each PID is associated with a set of properties. Each property correspo= nds > to > > a capability. The concept of a PID Property Map is defined by draft-roo= me- > > alto-pid-properties (an active Internet-Draft). The same draft defines = rules > > for implicit inheritance of properties for overlapping PIDs (e.g. one P= ID 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. short= er 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 deliverin= g > > 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 asso= ciated > > 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 f= ootprints. > > The list of values is specific to the capability name. > > > > The optional footprint list restricts its capability. Each footprint ha= s 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 co= de, AS > > number, and IP prefix. > > > > The footprint mode may be set to "replace", "include", or "exclude" whi= ch > > indicates how the footprint should be treated with respect to "previous= " > > footprint information. In this context, "previous" refers to incrementa= l > > updates which are sent asynchronously from the dCDN to the uCDN. The > > "replace" mode indicates that any previous information about the footpr= int > > 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 CDN= I 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 newl= y > > defined representation can be as flexible as needed and the ALTO > > representation is generic enough to support the CDNI use case. Leveragi= ng > > an existing protocol has obvious advantages but it is unclear to me whe= ther > > 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 approa= ch > > seems more intuitive. Aggregated footprint and capability information i= s > > 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 dC= DNs > > can claim the same end clients in their footprint advertisements. Howev= er, > > regardless of the use case, business logic is likely to kick in before = such cost > > metrics would be useful. Neither approach includes a definitive proposa= l in > > this area. > > > > Extensibility and Versioning: Versioning of the FCI protocol is not dis= cussed > > by either draft. Extensibility is alluded to and is clearly possible. H= owever, > 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 prot= ocol. > > However, the difficulty of these efforts is not insurmountable and coul= d 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 PID= s. In > > the case of draft-ma, no special inheritance rules exist. These inherit= ance > > 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 m= ay > be > > sent from dCDN to uCDN which includes the incremental update. Assuming > > that update notifications is a real requirement, then draft-ma has a mo= re > > 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 informat= ion. 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 conc= rete > > 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 o= f > > detail. Neither describe versioning and extensibility. Neither discuss = the > > encoding of logging and metadata capabilities which may pose significan= t > > 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 sta= rting > 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 te= ll, 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 interfa= ce > > 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 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Fri Feb 28 08:52:10 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 CAB9C1A00C0 for ; Fri, 28 Feb 2014 08:52:08 -0800 (PST) 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 F8RAESjL2zcI for ; Fri, 28 Feb 2014 08:52:05 -0800 (PST) Received: from p01c11o142.mxlogic.net (p01c11o142.mxlogic.net [208.65.144.65]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDBE1A0058 for ; Fri, 28 Feb 2014 08:52:05 -0800 (PST) Received: from unknown [69.25.75.234] (EHLO HUB027.mail.lan) by p01c11o142.mxlogic.net(mxl_mta-7.2.4-1) with ESMTP id 3beb0135.2b72ae410940.10980.00-540.31865.p01c11o142.mxlogic.net (envelope-from ); Fri, 28 Feb 2014 09:52:03 -0700 (MST) X-MXL-Hash: 5310beb339312b01-46d9d5929d52a39cb740682072385d7d10466249 Received: from unknown [69.25.75.234] (EHLO HUB027.mail.lan) by p01c11o142.mxlogic.net(mxl_mta-7.2.4-1) over TLS secured channel with ESMTP id 7aeb0135.0.10846.00-307.31463.p01c11o142.mxlogic.net (envelope-from ); Fri, 28 Feb 2014 09:52:00 -0700 (MST) X-MXL-Hash: 5310beb06982ccc0-0bce3796dc21222234a30ec099d2a9cd90df3fdd Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB027.mail.lan ([10.110.17.27]) with mapi; Fri, 28 Feb 2014 11:51:44 -0500 From: Kevin J Ma To: Jan Seedorf , "cdni@ietf.org" Date: Fri, 28 Feb 2014 11:51:42 -0500 Thread-Topic: CDNI FCI meeting at IETF-89 Thread-Index: Ac8zyF3Yu5l8TaDNRtCX/eqLbyHWsAA2g9zQAABvDdA= Message-ID: <291CC3F9E50E7641901A54E85D0977C6D542AF6AF2@MAILR002.mail.lan> References: <2779C9F0771F974CAD742BAE6D9904FE63B28309@PALLENE.office.hd> <2779C9F0771F974CAD742BAE6D9904FE63B28B24@PALLENE.office.hd> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE63B28B24@PALLENE.office.hd> 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/N34g9ptyFwgyQdhBmo1WliFQ2bA Subject: Re: [CDNi] 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: Fri, 28 Feb 2014 16:52:08 -0000 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 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 (th= e > > 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 ca= n > 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 rate= d > 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 providin= g > > > 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 define= s > 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 th= e > > > 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 ne= w > > > 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 thi= s > 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 footprint= s > and > > > capabilities. Footprints and capabilities are encoded in JSON and > > transported > > > via HTTP. > > > > > > Stated objective is to distill dCDN resource knowledge into simple se= t > 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 th= e > > > 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 th= e > > 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 initializ= e > > 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 resul= t > 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 JSO= N > > > 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 prio= r > > 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 i= s > > 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 befor= e > 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 o= f > > 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 Propert= y > 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. Assumin= g > > > 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 Patc= h > 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 discus= s > 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 From nobody Fri Feb 28 09:05: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 2692D1A026F for ; Fri, 28 Feb 2014 09:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-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 zsWqorvjA3kq for ; Fri, 28 Feb 2014 09:05:36 -0800 (PST) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 683201A0204 for ; Fri, 28 Feb 2014 09:05:36 -0800 (PST) Received: by mail-pb0-f53.google.com with SMTP id rp16so996846pbb.26 for ; Fri, 28 Feb 2014 09:05:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=XPc1Lv1fsOzboyua0F/Rh1OEF1xGNHm2BPDmRMqU8/Q=; b=nKKIPDwaCRq1MdkjJLim4Fus/kbposS1ypmxJx6fvJxi27yDqAvROFJVtC3pahOIOc w29Nrb8OjBC80G/0y4yvnhVwDtY4cM0VZI57VMZQwMxy8k05V++HsdnwvR810FkQoPkA lSw9BtUiEneDZERIzeBHXBKhRSbxZph3nbADWuJdkwYLstmVQR21LNJRLCJPpH6OXxoY 5W73tNe+e7GiTOSePiDh0CMRnLEq/UUlTyN4oUFnBbnImM1WXK96dRyXIY5U1wyd97UC UMIpYEVqSf6/L8UG6iirXCydOoms3Bsu5tAEBwLZ81Cqhl8Njrd0OhUgdFzBjwfeEgwH jd1g== MIME-Version: 1.0 X-Received: by 10.66.144.200 with SMTP id so8mr4755327pab.15.1393607134512; Fri, 28 Feb 2014 09:05:34 -0800 (PST) Sender: yang.r.yang@gmail.com Received: by 10.68.144.168 with HTTP; Fri, 28 Feb 2014 09:05:34 -0800 (PST) In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6D542AF6AF2@MAILR002.mail.lan> References: <2779C9F0771F974CAD742BAE6D9904FE63B28309@PALLENE.office.hd> <2779C9F0771F974CAD742BAE6D9904FE63B28B24@PALLENE.office.hd> <291CC3F9E50E7641901A54E85D0977C6D542AF6AF2@MAILR002.mail.lan> Date: Fri, 28 Feb 2014 12:05:34 -0500 X-Google-Sender-Auth: pQrgMseX4XzpQkSX6-e12TPuLow Message-ID: From: "Y. Richard Yang" To: Kevin J Ma Content-Type: multipart/alternative; boundary=047d7b6d9284358d5904f37a72db Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/fTJ8eHg2ioXTUF6KUfPgHju-DUA Cc: "cdni@ietf.org" Subject: Re: [CDNi] 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: Fri, 28 Feb 2014 17:05:41 -0000 --047d7b6d9284358d5904f37a72db Content-Type: text/plain; charset=ISO-8859-1 Hi all, Is there any way that one can participate remotely, say by Skype? Thanks. Richard On Fri, Feb 28, 2014 at 11:51 AM, Kevin J Ma wrote: > 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 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"). > > > > > > > > ======================================= > > > > 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. > > > > > > > > ======================================= > > > > 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. > > > > > > > > ======================================= > > > > 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. > > > > > > > > ======================================= > > > > 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. > > > > > > > > ======================================= > > > > 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. > > > > > > > > ======================================= > > > > 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 > -- -- ===================================== | Y. Richard Yang | | Professor of Computer Science | | http://www.cs.yale.edu/~yry/ | ===================================== --047d7b6d9284358d5904f37a72db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

Is there any way that one can p= articipate remotely, say by Skype?

Thanks.
Richard

On Fri, Feb 28, 2014 at 11:51 AM, Kevin J Ma <kevin.ma@azukisyste= ms.com> wrote:
I can make Wed if that is easiest.

> -----Original Message-----
> From: CDNi [mailto:cdni-bounc= es@ietf.org] On Behalf Of Jan Seedorf

> Sent: Friday, February 2= 8, 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 chanc= e
> 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.<= br> > Kevin?
>
> Darly, Kevin, any chance that you guys can in fact make the respective=
> slot above?
>
> =A0- 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 discussion= s on
> how to
> > continue with the two current FCI proposals during the IETF-89 we= ek (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 t= hey can
> hopefully
> > enlighten us on the ALTO WG timeframe and re-chartering, as depen= dency
> > on the progress of the ALTO WG has repeatedly been mentioned as b= eing 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.
> >
> > =A0- 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 curren= t FCI
> > proposals
> > > (along with some of their normative references) and I have p= ut
> together
> > the
> > > following analysis.
> > >
> > > The text below first reviews the CDNI Requirements for FCI a= s 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 compari= ng the
> drafts
> > > based on their approach to FCI (and not the quality or the l= evel of
> detail in
> > > the documents).
> > >
> > > If you have not done so already, then I would also =A0recomm= end reading
> Jon
> > > Peterson's email from February 6 ("footprint and ca= pabilities
> > 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<= br> > > > 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 re= quests)
> > > 5) Specific capabilities including:
> > > =A0 a) delivery protocol
> > > =A0 b) acquisition protocol
> > > =A0 c) redirection mode (DNS vs HTTP)
> > > =A0 d) logging options
> > > =A0 e) metadata options
> > > 6) Delivery authorization mechanisms (e.g. uri signing)
> > >
> > > The FCI must also support extensibility and versioning for n= ew
> 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-semant= ics)
> > > ------------------------------------------------------------= -
> > > Design Decisions
> > > 1) Advertising Limited Coverage - should footprints be binar= y or rated
> via
> > > qualitative score?
> > > 2) Capabilities and Dynamic Data - what capabilities are sta= tic vs
> dynamic? If
> > > dynamic, how dynamic?
> > > 3) Advertisement vs Queries - synchronous query response mod= el (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 ag= reed 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 foo= tprints
> 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
> > > =A0FCI using ALTO (draft-seedorf-cdni-request-routing-alto-0= 6)
> > > ------------------------------------------------------------= -
> > > This proposal is based on the ALTO (Application Layer Traffi= c
> Optimization)
> > > protocol (draft-ietf-alto-protocol), currently under develop= ment by
> the
> > ALTO
> > > working group. ALTO protocol specification is currently an A= ctive
> Internet-
> > > Draft in the "Submitted to IESG for Publication" s= tate.
> > >
> > > 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 group= s of
> > > endpoints. Endpoints are grouped into PIDs. All endpoints wi= thin a
> single
> > PID
> > > share the same capabilities.
> > >
> > > Each PID is associated with a set of properties. Each proper= ty
> corresponds
> > to
> > > a capability. The concept of a PID Property Map is defined b= y draft-
> roome-
> > > alto-pid-properties (an active Internet-Draft). The same dra= ft 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 anot= her 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 I= RD
> > > (Information Resource Directory) per dCDN. The IRD in turn p= rovides
> two
> > > URIs. One for accessing the dCDN's Network Map and anoth= er for the
> > > dCDN's PID Property Map. However, this is not described = explicitly.
> > >
> > > The draft defines the same basic set of capabilities as defi= ned in the
> > > requirements but does not describe their encoding in depth.<= br> > > >
> > > The ALTO protocol only registers IPv4 and IPv6 endpoint type= s.
> Assuming
> > > that this draft would register ISO Country Codes and AS numb= ers as new
> > > endpoint types, but not clear from the text.
> > >
> > > ALTO Cost Map could be used to determine the cost of the dCD= N
> delivering
> > > to each group of endpoints (PID).
> > >
> > > The PID concept offers a level of indirection between footpr= ints and
> > > capabilities allowing them to vary independently.
> > >
> > > ALTO also offers filtered querying in order to avoid fetchin= g an
> entire
> > > network map or pid property map.
> > >
> > > Future extensions to ALTO will include asynchronous notifica= tions and
> > > incremental updates as described by draft-schwan-alto-incr-u= pdates
> > > (currently an Expired Internet-Draft). Expecting progress so= on 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-cd= ni-
> > capabilities-
> > > 04)
> > > ------------------------------------------------------------= -
> > > This proposal is based on a CDNI-specific representation of = footprints
> and
> > > capabilities. Footprints and capabilities are encoded in JSO= N 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 defi= ned in the
> > > requirements and provides some examples of their encoding. > > >
> > > Each capability has a name, a list of values, and an optiona= l list of
> footprints.
> > > The list of values is specific to the capability name.
> > >
> > > The optional footprint list restricts its capability. Each f= ootprint
> has a type,
> > list
> > > of values, and an optional mode. The list of values is speci= fic 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 t= o
> "previous"
> > > footprint information. In this context, "previous"= refers to
> incremental
> > > updates which are sent asynchronously from the dCDN to the u= CDN. The
> > > "replace" mode indicates that any previous informa= tion about the
> footprint
> > > should be discarded and replaced entirely with the new infor= mation.
> The
> > > "include" mode indicates an addition to the footpr= int while "exclude"
> > > indications a subtraction.
> > >
> > > The draft does not provide a means for conveying footprint c= ost
> > 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 t= o
> "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 n= umbers
> (via
> > an
> > > CDNI-FCI-seq HTTP header) in order to detect loss. Lost upda= tes 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 transpor= t 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 exist= ing ALTO
> > > representations for network and property maps are leveraged.= These
> data
> > > structures clearly fit the CDNI use case and have the benefi= t 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 cas= e.
> Leveraging
> > > an existing protocol has obvious advantages but it is unclea= r to me
> whether
> > > or not adding a dependency on the ALTO WG will be problemati= c in any
> > way.
> > >
> > > Hierarchy: in the case of draft-seedorf, footprints have cap= abilities.
> In the
> > > case of draft-ma, capabilities have footprints. In the singl= e CDN
> case,
> > neither
> > > option is deficient. In the cascaded CDN case, the draft-see= dorf
> approach
> > > seems more intuitive. Aggregated footprint and capability in= formation
> is
> > > constructed simply by appending the footprints of all dCDNs.=
> > >
> > > Cost Information: in the case of draft-seedorf, a loose desc= ription 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 advertisem= ents.
> However,
> > > regardless of the use case, business logic is likely to kick= in before
> such cost
> > > metrics would be useful. Neither approach includes a definit= ive
> 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 depen= dency is
> > > introduced on the ALTO WG and a few drafts in progress. In t= he case of
> > draft-
> > > ma, no such dependency is required. The benefits of leveragi= ng ALTO
> > include
> > > the ability to easily reuse the work that the ALTO WG has do= ne in
> > hardening
> > > the error handling, security, encoding, and processing of th= e ALTO
> protocol.
> > > However, the difficulty of these efforts is not insurmountab= le and
> could be
> > > reproduced in a CDNI-specific proposal.
> > >
> > > Capability Inheritance: in the case of draft-seedorf, the PI= D Property
> Map
> > > defines rules for implicit inheritance between multiple over= lapping
> PIDs. In
> > > the case of draft-ma, no special inheritance rules exist. Th= ese
> inheritance
> > > rules may complicate implementation of FCI. Completely expli= cit
> > capabilities,
> > > such as in draft-ma, may be a better approach.
> > >
> > > Update Notifications: in the case of draft-seedorf, no stron= g story
> for
> > update
> > > notifications is provided. The ALTO Incremental Updates draf= t 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 HTT= P
> interface
> > > breaks the RESTful nature of the interface.
> > >
> > > Incremental Updates: in the case of draft-seedorf, the ALTO<= br> > Incremental
> > > Update draft is referenced. This draft describes the use of = JSON Patch
> for
> > > encoding incremental changes to ALTO information. Additional= ly, ALTO
> > allows
> > > for filtered queries which could be used for obtaining parti= al
> information. In
> > > the case of draft-ma, a scheme including sequence numbers, a= new HTTP
> > > header, and a "mode" is used for conveying increme= ntal changes via
> HTTP
> > > POST. Like the update notifications, the draft-ma proposal i= s more
> concrete
> > > in this area. However, again, the ALTO approach is more REST= ful.
> > Additionally,
> > > adding a new HTTP header for this purpose may not be workabl= e.
> > >
> > > Draft Maturity: both draft-seedorf and draft-ma require anot= her level
> of
> > > detail. Neither describe versioning and extensibility. Neith= er 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 candidat= es as a
> starting
> > point
> > > for our FCI standard.
> > >
> > > I would suggest that the working group must first decide whe= ther the
> > > benefits of reusing the ALTO syntax and semantics outweigh t= he 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. Star= ting 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 upd= ates.
> > >
> > > 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
ht= tps://www.ietf.org/mailman/listinfo/cdni

--
=
--=A0
=A0=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

| Y. Richard Yang <yry@cs.yale.edu> =A0 |
| Professor of Compute= r Science =A0 =A0 =A0 |

| http://www.cs.yale.edu/~yry/ =A0 =A0 =A0 = =A0|
=A0=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

--047d7b6d9284358d5904f37a72db--