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

["Murray, Rob (Nokia - GB)" <[e-mail]>]

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.


On 19/05/2016, 15:56, "CDNi on behalf of Ben Campbell" <[e-mail] on behalf of [e-mail]> 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/cdni