Re: [CDNi] Ben Campbell's No Objection on draft-ietf-cdni-control-triggers-15: (with COMMENT)

On 19 May 2016, at 10:15, Murray, Rob (Nokia - GB) wrote:

> Thanks Ben.
>
> I replied to these comments in 
> http://mailarchive.ietf.org/arch/msg/cdni/D7bQMQmBhMuMIe1L5EpaH1nC6sk, 
> and addressed most of them in "-13" of the draft.

Hmm. Somehow I missed the more extended response to my offline cache 
question. The explanation makes sense. It might or might not be worth 
adding some text to the draft about it--I will leave that to the authors 
to respond.

>
> It'd be worth you checking you're happy with my other responses though 
> - repeated below.

The rest of the points are fine--The bit about "old" comments should 
have been more to the effect of "These have been handled in email 
discussion; but I did not double-check them in the draft today".

Thanks,

Ben.

>
> Cheers,
> Rob.
>
>
> On 19/05/2016, 15:56, "CDNi on behalf of Ben Campbell" 
> <cdni-bounces@ietf.org on behalf of ben@nostrum.com> wrote:
>
>> Ben Campbell has entered the following ballot position for
>> draft-ietf-cdni-control-triggers-15: No Objection
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> Thanks for handling my DISCUSS point related to the TLS requirement.  
>> I
>> had one remaining DISCUSS point that I am not sure has been 
>> resolved--but
>> after the conversation that did happen, it is probably no longer
>> DISCUSS-worthy:
>>
>> - 4.7, 2nd bullet under handling of offline surrogates:
>>
>> I assume I am missing something here. How does a surrogate know that 
>> the
>> situation exists in the first place? How would a surrogate know about
>> invalidate commands that happened while it was offline?
>
> I replied in 
> https://mailarchive.ietf.org/arch/msg/cdni/nPz4CuJXuxk5dXhEP2n-gtcx7Ag 
> with ...
>
> A CDN implementation could decide to revalidate all of its content if 
> it's been offline, that'd work but it'd be a bit extreme.
>
> In our implementation, individual caches query for commands or config 
> changes they missed when they come online (before they start taking 
> traffic).
>
> The point is that it's an implementation decision ... from a 
> CDN-interconnect point-of-view it doesn't matter how the dCDN makes 
> sure it's not serving invalidated/deleted content, but there's a 
> requirement for it to do so somehow - which is what I was trying to 
> state in the draft.
>
> Once a CDN gets big enough, there's a fair chance that at least one 
> cache is offline at any given time for maintenance, because of 
> hardware or network failure, etc. So CDNs have to deal with individual 
> caches missing internal invalidate/purge commands, and should do the 
> same when interconnected.
>
>
>> -------------
>>
>> The remaining comments are old. I think they've mostly been 
>> addressed,
>> but did not recheck them:
>>
>> - 3, paragraph 5:
>> SHOULD should not be equated with "optional to implement". MAY means
>> that. SHOULD is intended to be stronger.
>
> Changed to MAY in "-13".
>
>
>> - 4.5, 2nd paragraph, 1st sentence:
>> This is pretty convoluted. I suggest reformulating without the past 
>> tense
>> "MUST". For example, "The dCNI MUST report the expiration times 
>> if..."
>
> Changed in "-13".
>
>
>> -4.6: "If CDNs B and C delegate delivery of CDN A’s content to each
>> other"
>> Is this a reasonable configuration? It seems like they might already 
>> have
>> a delegation loop before the trigger interface got involved.
>
> In 
> http://mailarchive.ietf.org/arch/msg/cdni/D7bQMQmBhMuMIe1L5EpaH1nC6sk 
> I replied ...
>
>   Perhaps it could happen if two CDNs use each other for extra
>   Capacity during periods of high load.
>
>   But it's certainly not an impossible configuration. The request
>   routing draft deals with loops, so it seemed best to do so here
>   as well.
>
>   Does that help? Are any mods or explanations needed in the draft?
>
> ... so, no change in the draft yet.
>
>
>> Also, the first sentence is a fragment.
>
> Fixed in "-13".
>
>
>> = 4.8, first paragraph:
>> I suggest s/transform/"similarly transform"
>
> Fixed in "-13".
>
>
>> - 5.1.3, staleresourcetime, mandatory:
>> Doesn't this effectively mean the value must be the same across all
>> collections?
>
> In 
> http://mailarchive.ietf.org/arch/msg/cdni/D7bQMQmBhMuMIe1L5EpaH1nC6sk 
> I replied ...
>
>   Yes, but the filtered collections are described as filtered views
>   of the collection of all triggers.
>
>   I think it'd be odd to use different times for the filtered
>   collections (especially longer times) and a little more fiddly
>   to implement. I don't think there'd be anything to gain from
>   the extra flexibility?
>
> ... so, no change in the draft yet.
>
>
>> - 5.2.1, content.ccid:
>> Seems like the reference to [I-D.ietf-cdni-metadata] should be
>> normative.
>
> Made normative in "-13".
>
>
>> - 6.2.5:
>> it looks like the dCDN is sending the request to itself. Is that the
>> intent?
>
> Typo, fixed in "-13".
>
>
>> - 8.1, last paragraph: "In this case, the dCDN MUST allow each uCDN 
>> from
>> which the content could have been acquired to act upon that content 
>> using
>> CI/T Commands."
>> This seems like a place where local policy might reasonably vary. Is 
>> a
>> MUST really appropriate?
>
> In 
> http://mailarchive.ietf.org/arch/msg/cdni/D7bQMQmBhMuMIe1L5EpaH1nC6sk 
> I replied ...
>
>   That moved to section 2.2.1 para 4 in "-12", and became...
>
>     "CI/T commands originating in the single source uCDN affect 
> metadata
>     and content in all dCDNs but, in a diamond configuration, it may 
> not
>     be possible for the dCDN to determine which uCDN it acquired 
> content
>     from. In this case a dCDN MUST allow each uCDN from which it may
>     have acquired the content to act upon that content using CI/T 
> Commands."
>
>   I think a MUST is right though ... if a uCDN wants its data gone, 
> and
>   the dCDN thinks it might have some of that data, it had better 
> delete
>   it.
>
>   So I'd prefer to leave the MUST, is that ok?
>
> ... so, no change in the draft yet.
>
>>
>>
>> _______________________________________________
>> CDNi mailing list
>> CDNi@ietf.org
>> https://www.ietf.org/mailman/listinfo/cdni