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

From: "Ben Campbell" <[email-masked]>
Date: Thu, 19 May 2016 07:56:54 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-cdni-control-triggers-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cdni-control-triggers/

----------------------------------------------------------------------
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?
-------------

 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.

- 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..."

-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.
Also, the first sentence is a fragment.

= 4.8, first paragraph:
I suggest s/transform/"similarly transform"

- 5.1.3, staleresourcetime, mandatory:
Doesn't this effectively mean the value must be the same across all
collections? 

- 5.2.1, content.ccid:
Seems like the reference to [I-D.ietf-cdni-metadata] should be
normative.

- 6.2.5:
it looks like the dCDN is sending the request to itself. Is that the
intent?

- 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?

---

From: "Murray, Rob (Nokia - GB)" <[email-masked]>
Date: Thu, 19 May 2016 15:15:40 +0000

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.

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

Cheers,
Rob.

>draft-ietf-cdni-control-triggers-15: No Objection

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.

Changed to MAY in "-13".

>"MUST". For example, "The dCNI MUST report the expiration times if..."

Changed in "-13".

>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".

>I suggest s/transform/"similarly transform"

Fixed in "-13".

>Doesn't this effectively mean the value must be the same across all

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.

>Seems like the reference to [I-D.ietf-cdni-metadata] should be

Made normative in "-13".

>it looks like the dCDN is sending the request to itself. Is that the

Typo, fixed in "-13".

>This seems like a place where local policy might reasonably vary. Is a

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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/cdni

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 19 May 2016 10:50:29 -0500

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 

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" 
> <[email-masked] on behalf of [email-masked]> wrote:
>
> 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.
>
>
>> -------------
>>
> In 
> http://mailarchive.ietf.org/arch/msg/cdni/D7bQMQmBhMuMIe1L5EpaH1nC6sk 
> I replied ...
>
> In 
> http://mailarchive.ietf.org/arch/msg/cdni/D7bQMQmBhMuMIe1L5EpaH1nC6sk 
> I replied ...
>
> In 
> http://mailarchive.ietf.org/arch/msg/cdni/D7bQMQmBhMuMIe1L5EpaH1nC6sk 
> I replied ...
>