Subject: Re: [CDNi] 2nd batch of comments on cdni-framework

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 8 Mar 2013 18:05:35 +0000

Hi Larry,
I just had a quick look at cdni-framework-03 and can confirm this version addresses my last comment.
Thanks
Francois

On 21 Dec 2012, at 22:40, "Peterson, Larry" <[email-masked]> wrote:

> You aren't missing anything. I was probably trying to sweep too much
> under the rug. I've added the additional message to figures 3 and 4.
> 
> Larry
> 
> On Dec 21, 2012, at 9:57 AM, Francois Le Faucheur (flefauch) wrote:
> 
>> Hi Larry,
>> 
>> On 21 Dec 2012, at 15:14, Peterson, Larry wrote:
>> 
>>> Francois,
>>> 
>>> You're right. I should have warned you. My reading is that the explanation
>>> in the text covers (explains) that case, which we don't need to trace explicitly.
>> 
>> There seems to be a disconnect. Let me try clarify (and please let me know if I am missing something)
>> I am not talking about some special case. In the message flow that is shown, I believe there is simply one single mandatory message that is missing.
>> 
>> The figure currently shows:
>> "
>>            |                         |HTTP op-b-acq.op-a.net   |
>>            |                         |------------------------>|
>>            |                         |                         |(8)
>>            |                         |302 node2.op-b.acq.op-A.net
>>            |                         |<------------------------|
>>            |                         |DNS node2.op-b-acq.op-a.net
>>            |                         |------------------------>|
>>            |                         |                         |(9)
>>            |                         |IPaddr of A's Delivery Node
>>            |                         |<------------------------|
>>            |                         |                         |(10)
>>            |                         |Data                     |
>>            |                         |<------------------------|
>> "
>> 
>> I believe it should show:
>> "
>>            |                         |HTTP op-b-acq.op-a.net   |
>>            |                         |------------------------>|
>>            |                         |                         |(8)
>>            |                         |302 node2.op-b.acq.op-A.net
>>            |                         |<------------------------|
>>            |                         |DNS node2.op-b-acq.op-a.net
>>            |                         |------------------------>|
>>            |                         |                         |(9)
>>            |                         |IPaddr of A's Delivery Node
>>            |                         |<------------------------|
>> 
>>            |                         |HTTP node2.op-b-acq.op-a.net
>>            |                         |------------------------>|
>> 
>>            |                         |                         |(10)
>>            |                         |Data                     |
>>            |                         |<------------------------|
>> "
>> 
>> The message flows always show every DNS message and every HTTP message, it does not make sense to me to omit one single HTTP request message when all the ones are shown.
>> In step 2, 3 and 4 above, you have the exact same sequence of HTTP redirect, DNS , HTTP request and the HTTP request is shown. Why would you not show in step (9).
>> 
>> BTW, the text that follows the figure also makes the same omission i.e. it describe the HTTP redirect, the corresponding DNS, and then just says that the content is served. But the content won't be served until operator B issues a HTTP request following the 302 redirect.
>> If Operator A was to use DNS for intra-CDN request routing, then you don't need to show this HTTP request, but you example does not assume DNS redirection since it shows a 302 node2.op-b.acq.op-A.net.
>> As shown the message flow is a cross-breed between the DNS message flow and the HTTP message flow and does not seem correct to me.
>> 
>> Same applies to Figure 4.
>> 
>> What am I missing?
>> 
>> Thanks
>> 
>> 
>>> 
>>> Larry
>>> 
>>> On Dec 20, 2012, at 10:48 AM, Francois Le Faucheur (flefauch) wrote:
>>> 
>>>> To the WG,
>>>> I just realized that I had inadvertently omitted to copy the cdni alias when I sent my 2nd batch of comments on cdni-framework last October. So here it is below, just for the records.
>>>> 
>>>> To Larry, Bruce,
>>>> Thanks very much for incorporating my two batches of comments.
>>>> I noticed that you did not reflect the comments about a missing message in the message flows of Figure 3 and Figure 4. Is this an omission on your end, or am I missing something and these messages are actually not needed?
>>>> 
>>>> "
>>>>> section 3.2, Figure 3:
>>>>> I believe a HTTP request is missing in the acquisition phase (i.e. after step 8). After the uCDN issues the "302 node2.op-b.acq.op-A.net", the dCDN will follow the redirect and issue a "HTTP node2.op-b.acq.op-A.net" which is missing from the figure. This "HTTP node2.op-b.acq.op-A.net" should happen just before the "Data" message.
>>>> "
>>>> "
>>>>> Figure 4: same comment as for Figure 3 wrt "HTTP node2.op-b.acq.op-A.net" request missing from the figure.
>>>> "
>>>> 
>>>> Thanks
>>>> 
>>>> Francois
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Begin forwarded message:
>>>> 
>>>>> From: Francois Le Faucheur <[email-masked]>
>>>>> Subject: 2nd batch of comments on cdni-framework
>>>>> Date: 31 October 2012 18:44:51 CET
>>>>> To: <[email-masked]>
>>>>> 
>>>>> Larry, Bruce,
>>>>> 
>>>>> Below is the second batch of my detailed comments on cdni-framework-01 (as an Individual).
>>>>> I don't think there is anything major missing from the document.
>>>>> 
>>>>> I hope these comments are useful and can be addressed in a new version soon.
>>>>> 
>>>>> Cheers
>>>>> 
>>>>> Francois
>>>>> 
>>>>> 
>>>>> ===============================================================
>>>>> 
>>>>> 
>>>>> As discussed off-line, one general change needed is to reflect the IETF-84 decisions with respect to HAS.
>>>>> 
>>>>> 
>>>>> section 1.1:
>>>>> OLD:
>>>>> "
>>>>> Recursive CDNI request routing: When an Upstream CDN elects to
>>>>> redirect a request towards a Downstream CDN, the Upstream CDN can
>>>>> query the Downstream CDN Request Routing system via the CDNI Request
>>>>> Routing interface (or use information cached from earlier similar
>>>>> queries) to find out how the Downstream CDN wants the request to be
>>>>> redirected, which allows the Upstream CDN to factor in the Downstream
>>>>> CDN response when redirecting the user agent.  This approach is
>>>>> referred to as "recursive" CDNI request routing.  Note that the
>>>>> Downstream CDN may elect to have the request redirected directly to a
>>>>> Surrogate inside the Downstream CDN, to the Request-Routing System of
>>>>> the Downstream CDN, to another CDN, or to any other system that the
>>>>> Downstream CDN sees as fit for handling the redirected request.
>>>>> "
>>>>> NEW:
>>>>> "
>>>>> Recursive CDNI Request Redirection: When an Upstream CDN elects to
>>>>> redirect a request towards a Downstream CDN, the Upstream CDN can
>>>>> query the Downstream CDN Request Routing system via the CDNI Request
>>>>> Routing Redirection interface (or use information cached from earlier similar
>>>>> queries) to find out how the Downstream CDN wants the request to be
>>>>> redirected, which allows the Upstream CDN to factor in the Downstream
>>>>> CDN response when redirecting the user agent.  This approach is
>>>>> referred to as "Recursive" CDNI Request Redirection.  Note that the
>>>>> Downstream CDN may elect to have the request redirected directly to a
>>>>> Surrogate inside the Downstream CDN, to the Request-Routing System of
>>>>> the Downstream CDN, to another CDN, or to any other system that the
>>>>> Downstream CDN sees as fit for handling the redirected request.
>>>>> "
>>>>> 
>>>>> 
>>>>> OLD:
>>>>> "
>>>>> Iterative CDNI Request Routing: When an Upstream CDN elects to
>>>>> redirect a request towards a Downstream CDN, the Upstream CDN can
>>>>> base its redirection purely on a local decision (and without
>>>>> attempting to take into account how the Downstream CDN may in turn
>>>>> redirect the user agent).  In that case, the Upstream CDN redirects
>>>>> the request to the request routing system in the Downstream CDN,
>>>>> which in turn will decide how to redirect that request: this approach
>>>>> is referred to as "iterative" CDNI request routing.
>>>>> "
>>>>> NEW:
>>>>> "
>>>>> Iterative CDNI Request Redirection: When an Upstream CDN elects to
>>>>> redirect a request towards a Downstream CDN, the Upstream CDN can
>>>>> base its redirection purely on a local decision (and without
>>>>> attempting to take into account how the Downstream CDN may in turn
>>>>> redirect the user agent).  In that case, the Upstream CDN redirects
>>>>> the request to the request routing system in the Downstream CDN,
>>>>> which in turn will decide how to redirect that request: this approach
>>>>> is referred to as "Iterative" CDNI Request Redirection.
>>>>> "
>>>>> 
>>>>> 
>>>>> 
>>>>> section 3:
>>>>> I suggest tweaking titles of the example sections to make them more consistent and explicit:
>>>>> * section 3.2:  "HTTP Redirect Example" --> "Iterative HTTP Redirection Example"
>>>>> * section 3.3:  "Recursive Redirection Example" --> "Recursive HTTP Redirection Example"
>>>>> * section 3.4:  "DNS-based redirection example" --> "Iterative DNS-based Redirection Example"
>>>>> * section 3.5:  "Dynamic Footprint Discovery" --> "Dynamic Footprint Discovery example"
>>>>> * section 3.6:  "Content Removal" --> "Content Removal Example"
>>>>> 
>>>>> 
>>>>> section 3:
>>>>> All figures are titled as "Request Trace for …"
>>>>> I'd suggest titling them with something like "Message Flow for…". This is not really a "trace" and I am not sure what "request" is, because the message flows contain both "requests" and "responses", and there are message flows that don't relate to any "content request".
>>>>> 
>>>>> 
>>>>> section 3.2, Figure 3:
>>>>> I believe a HTTP request is missing in the acquisition phase (i.e. after step 8). After the uCDN issues the "302 node2.op-b.acq.op-A.net", the dCDN will follow the redirect and issue a "HTTP node2.op-b.acq.op-A.net" which is missing from the figure. This "HTTP node2.op-b.acq.op-A.net" should happen just before the "Data" message.
>>>>> 
>>>>> 
>>>>> section 3.2:
>>>>> OLD:
>>>>> "
>>>>> it is at this point that Operator A processes the rest of the URL:
>>>>> "
>>>>> NEW:
>>>>> "
>>>>> Operator A processes the rest of the URL:
>>>>> "
>>>>> (rationale: Operator A may have looked at the rest of the URL in earlier steps e.g. to look at metadata to decide if/how to redirect etc, so better leave it open).
>>>>> 
>>>>> 
>>>>> section 3.2.1:
>>>>> OLD
>>>>> "
>>>>> For example, obtaining information from dCDN regarding the set of client
>>>>> IP addresses or geographic regions it might be able to serve is an
>>>>> aspect of the request routing interface.
>>>>> "
>>>>> NEW:
>>>>> "
>>>>> For example, obtaining information from dCDN regarding the set of client
>>>>> IP addresses or geographic regions it might be able to serve is an
>>>>> aspect of the CDNI request routing interface (specifically of the CDNI Footprint & Capabilities advertisement interface).
>>>>> "
>>>>> 
>>>>> 
>>>>> section 3.2.1:
>>>>> OLD
>>>>> "
>>>>> Hence, there is no explicit metadata interface invoked in this example.
>>>>> "
>>>>> NEW:
>>>>> "
>>>>> The example also assumes that the CSP does not require any distribution policy (e.g. time window, geo-blocking) or delivery processing to be applied by the interconnected CDNs. Hence, there is no explicit metadata interface invoked in this example.
>>>>> "
>>>>> 
>>>>> 
>>>>> section 3.3:
>>>>> OLD:
>>>>> "
>>>>> The following example builds on the previous one to illustrate the
>>>>> use of the Request Routing interface to enable "recursive" CDNI
>>>>> request routing.
>>>>> "
>>>>> NEW:
>>>>> "
>>>>> The following example builds on the previous one to illustrate the
>>>>> use of the Request Routing interface (specifically the CDNI Request Routing Redirection interface) to enable "recursive" CDNI request routing.
>>>>> "
>>>>> 
>>>>> section 3.3:
>>>>> OLD:
>>>>> "
>>>>> The operators still must agree on some distinguished
>>>>> CDN-domain that will be used for inter-CDN acquisition of CSP's
>>>>> content by dCDN.
>>>>> "
>>>>> NEW:
>>>>> "
>>>>> We assume that the operators agree on some distinguished
>>>>> CDN-domain that will be used for inter-CDN acquisition of CSP's
>>>>> content by dCDN.
>>>>> "
>>>>> (Rationale: I made the same comment about section 3.2. While it is convenient to do it that way, it is not an absolute requirement.)
>>>>> 
>>>>> 
>>>>> section 3.3:
>>>>> "
>>>>> DNS must be configured in the following way:
>>>>> "
>>>>> Again, I suggest the text is tweaked in multiple places so that the "must" is replaced by something like "we assume that". Because a lot of those are just how the example works, but is not a "must" in itself.
>>>>> This carries into all other examples (e.g. section 3.4 and so on).
>>>>> I believe this needs to be fixed because an issue that has been brought up multiple times wrt current framework is a need to clarify what is example from what is prescription.
>>>>> 
>>>>> 
>>>>> Figure 4: same comment as for Figure 3 wrt "HTTP node2.op-b.acq.op-A.net" request missing from the figure.
>>>>> 
>>>>> section 3.3, step 2:
>>>>> OLD:
>>>>> "
>>>>> so it queries the CDNI Request Routing interface of Operator B
>>>>> "
>>>>> NEW:
>>>>> "
>>>>> so it queries the CDNI Request Routing Redirection interface of Operator B
>>>>> "
>>>>> (more generally, you need to check all occurrences of "Request Routing Interface" or "RRI" throughout the document and align to our finalized nomenclature of "CDNI Request Routing Redirection interface" and "CDNI Footprint & Capabilities advertisement interface".
>>>>> In Figure 4, "RRI REQ" needs to be changed to something like "RR-RI REQ")
>>>>> 
>>>>> 
>>>>> section 3.4.1:
>>>>> OLD:
>>>>> "
>>>>> The advantages of this approach are that it is more transparent to
>>>>> the end-user and requires fewer round trips than HTTP-based
>>>>> redirection.
>>>>> "
>>>>> NEW:
>>>>> "
>>>>> The advantages of this approach are that it is more transparent to
>>>>> the end-user and requires fewer round trips than HTTP-based
>>>>> redirection (in its worst case i.e. when none of the needed DNS information is cached).
>>>>> "
>>>>> (Rationale: in the HTTP redirection case, the extra RTTs have to do with DNS request for very stable information such as the IP address of the CDN domains or delivery nodes. Those can be appropriately handled with long TTLs - certainly compared to the TTL that needs to be applied in case of DNS redirection. So in practice, for many requests the nb of real RTTs would be similar. In fact, I'd suggest you bring up this point).
>>>>> 
>>>>> 
>>>>> OLD:
>>>>> "
>>>>> In this case, one option is for the upstream CDN to treat the end-user
>>>>> as it would any user not connected to a peer CDN.
>>>>> "
>>>>> NEW:
>>>>> "
>>>>> In this case, and assuming the uCDN is capable of detecting that situation, one option is for the upstream CDN to treat the end-user
>>>>> as it would any user not connected to a peer CDN.
>>>>> "
>>>>> 
>>>>> 
>>>>> OLD:
>>>>> "
>>>>> Note that this
>>>>> problem affects existing CDNs that rely on DNS to determine where to
>>>>> redirect client requests, but the consequences are arguably less
>>>>> serious since the LDNS is likely in the same network as the dCDN
>>>>> serves.
>>>>> "
>>>>> I don't quite get that sentence.
>>>>> First, I suggest you make it explicit as to whether you mean  "the consequences are arguably less serious in existing CDNs" or  "the consequences are arguably less serious CDNI".
>>>>> Second, I don't quite see the difference between the two: if an enduser uses a global DNS, then a single CDN just cannot make any reasonable decision, nor can an uCDN in CDNI.
>>>>> 
>>>>> 
>>>>> section 3.5, Figure 6:
>>>>> OLD:
>>>>> "
>>>>> RRI REQ
>>>>> "
>>>>> NEW:
>>>>> "
>>>>> RR-F&CAI REQ
>>>>> "
>>>>> (in line with earlier comment: for "Request Routing - Footprint and Capabilities Advertisement interface)
>>>>> 
>>>>> 
>>>>> section 3.5:
>>>>> The notion of Footprint discovery could be illustrated with either DNS or HTTP. The document currently illustrates it with DNS. However, it gets a little confusing because (i) the example interaction mentioned is "Can you
>>>>> serve clients from this IP Prefix?" and (ii) the text just before section 3.5 just discussed the issue of identifying the client IP address in case of HTTP redirection (which is why a note was added : "(Note that the issues of determining the client's subnet from DNS requests, as described above, are exactly the same here as
>>>>> in Section 3.4.) ".
>>>>> I would suggest simply using HTTP redirection (instead of DNS) in the example of section 3.5. I think it would make the concept of footprint discovery easier to get for the reader.
>>>>> 
>>>>> 
>>>>> Figure 7:
>>>>> you included step numbers (e.g "(1)") in the Figure but did not refer to those in the description text.
>>>>> 
>>>>> 
>>>>> section 3.7:
>>>>> OLD:
>>>>> "
>>>>> The following example illustrates how the Control interface may be
>>>>> used to pre-position an item of content in the dCDN.
>>>>> "
>>>>> NEW:
>>>>> "
>>>>> The following example illustrates how the Control interface may be
>>>>> used to achieve pre-positioning of an item of content in the dCDN.
>>>>> "
>>>>> 
>>>>> 
>>>>> section 3.7, Figure 8:
>>>>> Figure 8 actually shows a scenario where dCDN performs DNS redirection for intra-CDN request routing (i.e. in step 6). This is in contradiction with the statement "Steps 4, 5, 6, 7 are exactly the same as steps 1, 2, 3, 4 of
>>>>> Figure 3," since Figure 3 actually showed HTTP redirection in dCDN and involved an additional step 5. Also it is the first time where an example mixes HTTP redirection across CDNs with DNS redirection inside a CDN, and while I don't have a problem in showing such a combination, I don't think it should be introduced in the middle of the example illustrating prepositioning.
>>>>> My recommendation is to tweak the current example in Figure 8 to show HTTP redirection in dCDN (as is done in the referenced Figure 3).
>>>>> 
>>>>> 
>>>>> section 3.8:
>>>>> We have progressed on the topic of "metadata push" and this is now seen as "triggered pull" initiated by the Control interface.
>>>>> While it is logically close to a metadata push, I recommend that:
>>>>> * the terminology be updated to current one e.g. as per RFC6707 : "Pre-positioned CDNI Metadata acquisition: "
>>>>> * the "MI push" in the figure be replaced with a "CI pre-position" + "CI OK" + "MI pull"  (the "CI" messages would be analogous to those of Figure 7).
>>>>> If you feel it is useful you could put a note that this could have been realized via a push mechanism, but that CDNI solution has selected a triggered Pull solution at least initially. But I suggest the description be made using triggered Pull.
>>>>> 
>>>>> 
>>>>> section 3.9:
>>>>> " 1.   Operator A initially uses the Metadata Interface to
>>>>>     asynchronously push seed metadata to Operator B. For example,
>>>>>     this seed information may include a URI indicating where CDNI
>>>>>     Metadata can later be pulled from for some content set.
>>>>> "
>>>>> We have progressed on the topic of "metadata seed". As discussed in ietf-cdni-metadata, there is only one single bit of info that needs to be known ahead of time which is the URI of the Metadata server, from which everything can be learnt. And this info is expected to be known via config, or learnt via some future CDNI auto discovery protocol. This basically removes the need for any seed info related to a content or content range.
>>>>> So I recommend removing step 1 from the Figure and from the text.
>>>>> 
>>>>> 
>>>>> section 3.10:
>>>>> OLD:
>>>>> "
>>>>> 3.10.  Content Acquisition with Multiple Upstream CDNs
>>>>> "
>>>>> NEW:
>>>>> "
>>>>> 3.10.  Content Acquisition and Metadata Acquisition with Multiple Upstream CDNs
>>>>> "
>>>>> 
>>>>> 
>>>>> OLD:
>>>>> "
>>>>> Given that the dCDN has established a business relationship with each of its uCDNs, assume
>>>>> that the dCDN can trust any uCDN to acquire the content.  The dCDN
>>>>> may narrow the set of viable uCDNs by examining the CDNI metadata
>>>>> from each to determine which uCDNs are hosting metadata for the
>>>>> requested content."
>>>>> NEW:
>>>>> "
>>>>> The dCDN may narrow the set of viable uCDNs by examining the CDNI metadata
>>>>> from each to determine which uCDNs are hosting metadata for the
>>>>> requested content. If there is a single uCDN hosting metadata for the requested content, the dCDN can assume that the request redirection is coming from this uCDN and can acquire content from that uCDN. If there are multiple uCDNs hosting metadata for the requested content, the dCDN may be ready to trust any of these uCDNs to acquire the content (provided the uCDN is in a position to serve it). If the dCDN is not ready to trust any of these uCDNs, it needs to ensure via out of band arrangements that, for a given content, only a single uCDN will ever redirect requests to the dCDN. "
>>>>> 
>>>>> 
>>>>> OLD:
>>>>> "
>>>>> tightly c coupled
>>>>> "
>>>>> NEW:
>>>>> "
>>>>> tightly coupled
>>>>> "
>>>>> 
>>>>> 
>>>>> section 4:
>>>>> OLD:
>>>>> "
>>>>> Figure 1 illustrates the four main interfaces that are in scope for
>>>>> the CDNI WG, along with several others.
>>>>> "
>>>>> NEW:
>>>>> "
>>>>> Figure 1 illustrates the four CDNI interfaces, along with several other relevant interfaces.
>>>>> "
>>>>> 
>>>>> 
>>>>> OLD:
>>>>> "
>>>>> The detailed specifications
>>>>> of these interfaces are left to other documents (mostly still to be
>>>>> written, but see [I-D.ietf-cdni-problem-statement] and
>>>>> [I-D.ietf-cdni-requirements] for some discussion of the interfaces).
>>>>> "
>>>>> NEW:
>>>>> "
>>>>> The detailed specifications
>>>>> of these interfaces are left to other documents, but see [I-D.ietf-cdni-problem-statement] and
>>>>> [I-D.ietf-cdni-requirements] for some discussion of the interfaces.
>>>>> "
>>>>> 
>>>>> 
>>>>> OLD:
>>>>> "
>>>>> There is also an important interface between the user and the Request
>>>>> Routing function of both uCDN and dCDN.  As we saw in some of the
>>>>> preceding examples, that interface can be used as a way of passing
>>>>> information such as the metadata that is required to obtain the
>>>>> content in dCDN from uCDN.
>>>>> "
>>>>> NEW:
>>>>> "
>>>>> There is also an important interface between the user and the Request
>>>>> Routing function of both uCDN and dCDN (shown as the "Request" interface in Figure 1).  As we saw in some of the
>>>>> preceding examples, that interface can be used as a way of passing
>>>>> information a subset of metadata such as the minimum information that is required for dCDN to obtain the
>>>>> content from uCDN.
>>>>> "
>>>>> 
>>>>> section 4.2:
>>>>> OLD:
>>>>> "
>>>>> While in the the limit
>>>>> "
>>>>> NEW:
>>>>> "
>>>>> While in the limit
>>>>> "
>>>>> 
>>>>> 
>>>>> section 4.2:
>>>>> I recommend the text in this section:
>>>>> * be aligned to our finalized nomenclature of "CDNI Request Routing Redirection interface" and "CDNI Footprint & Capabilities advertisement interface".
>>>>> * be structured to separate discussion on these two interfaces
>>>>> * refers to draft-spp-cdni-rr-foot-cap-semantics ( CDNI Request Routing: Footprint and Capabilities Semantics)  when discussing the information to advertise as footprint
>>>>> 
>>>>> 
>>>>> section 4.4:
>>>>> OLD:
>>>>> "
>>>>> It is necessary for the upstream CDN to have visibility into the
>>>>> delivery of content it originates to end-users connected to the
>>>>> downstream CDN.
>>>>> "
>>>>> NEW:
>>>>> "
>>>>> It is necessary for the upstream CDN to have visibility into the
>>>>> delivery of content that it redirected to a downstream CDN.
>>>>> "
>>>>> 
>>>>> section 4.4:
>>>>> [I-D.lefaucheur-cdni-logging-delivery] has been incorporated into [I-D.bertrand-cdni-logging], so you only need to refer to the latter.
>>>>> 
>>>>> section 4.6:
>>>>> [I-D.ma-cdni-metadata] and [I-D.cjlmw-cdni-metadata] are now merged into ietf-cdni-metadata, so you only need to refer to that document.
>>>>> 
>>>>> section 4.6:
>>>>> OLD:
>>>>> "
>>>>> Such metadata includes geo-blocking
>>>>> restrictions, availability windows, access control policies, and so
>>>>> on.  It may also include policy information such as the desire to
>>>>> pre-position content rather than fetch it on demand.
>>>>> "
>>>>> NEW:
>>>>> "
>>>>> Such metadata includes geo-blocking
>>>>> restrictions, availability windows, access control policies, and so
>>>>> on.  It may also include information to facilitate acquisition of content by dCDN (e.g. alternate sources for the content, authorization information needed to acquire the content from the source).
>>>>> "
>>>>> (Rationale: just aligning metadata examples to what is likely supported by the metadata interface, to avoid confusion).
>>>>> 
>>>>> 
>>>>> section 4.6:
>>>>> OLD:
>>>>> "
>>>>> Some metadata may be able to be conveyed using in-band mechanisms.
>>>>> For example, to inform the downstream CDN of any geo-blocking
>>>>> restrictions or availability windows, the upstream can elect to
>>>>> redirect a request to the downstream CDN only if that CDN's
>>>>> advertised delivery footprint is acceptable for the requested URL.
>>>>> Similarly, the request could be forwarded only if the current time is
>>>>> within the availability window.
>>>>> "
>>>>> NEW:
>>>>> "
>>>>> Some distribution metadata may be partially emulated using in-band mechanisms.
>>>>> For example, in case of any geo-blocking
>>>>> restrictions or availability windows, the upstream CDN can elect to
>>>>> redirect a request to the downstream CDN only if that CDN's
>>>>> advertised delivery footprint is acceptable for the requested URL.
>>>>> Similarly, the request could be forwarded only if the current time is
>>>>> within the availability window. However, such approaches typically come with shortcomings such as inability to prevent from replay outside the time window or inability to make use of a downstream CDN that covers a broader footprint than the geo-blocking restrictions.
>>>>> "
>>>>> 
>>>>> 
>>>>> OLD:
>>>>> "
>>>>> All of these in-band techniques serve to illustrate that uCDNs have
>>>>> the option of enforcing their access control policies themselves,
>>>>> rather than delegating enforcement to dCDNs using the Metadata
>>>>> interface.
>>>>> "
>>>>> NEW:
>>>>> "
>>>>> All of these in-band techniques serve to illustrate that uCDNs have
>>>>> the option of enforcing some of their access control policies themselves (at the expense of increased inter-CDN signaling load),
>>>>> rather than delegating enforcement to dCDNs using the Metadata
>>>>> interface.
>>>>> "
>>>>> (Rationale: the text is toned down a little bit because I think there are shortcomings with that approach, such as difficulty in preventing replays that bypass the access control policies)
>>>>> 
>>>>> 
>>>>> OLD:
>>>>> "
>>>>> to express this its desire
>>>>> "
>>>>> NEW:
>>>>> "
>>>>> to express its desire
>>>>> "
>>>>> 
>>>>> section 5:
>>>>> OLD:
>>>>> "
>>>>> and that may other models
>>>>> "
>>>>> NEW:
>>>>> "
>>>>> and that many other models
>>>>> "
>>>> 
>>> 
>> 
>