Subject: Re: [CDNi] Ben Campbell's Discuss on draft-ietf-cdni-control-triggers-11: (with DISCUSS and COMMENT)

From: "Murray, Rob (Nokia - GB)" <[email-masked]>
Date: Sat, 9 Apr 2016 14:29:46 +0000

Hi all,

Sorry, it took me ages to get to the comments before and in the end I had to push out a doc update along with my responses because I was up against the submission deadline - I got a comprehensive telling-off from the ADs during the CDNI WG meeting!

Ben - apologies, I completely missed your comments, and only found out in the meeting. Responses inline below.

Alissa - I'm afraid I was also asked to chase responses, are you happy with my responses to your comments, and the updates in "-12"?

Francois/Kevin - there's a question about making the metadata ref normative below, are you ok with that?

Many thanks,
Rob.

On 06/01/2016, 03:40, "Ben Campbell" <[email-masked]> wrote:

>Ben Campbell has entered the following ballot position for
>draft-ietf-cdni-control-triggers-11: Discuss
>
>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/
>
>
>
>----------------------------------------------------------------------
>DISCUSS:
>----------------------------------------------------------------------
>
>I've got two concerns that I think  leave  ambiguity around important
>normative requirements. Hopefully they will be easy to resolve:
>
>- 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?

That's an internal problem for the CDN, not something CDN interconnection can deal with. (The CDNI interface is between CDNs, not between individual caches.)

When a cache (surrogate) comes online it needs to check-for, or be told about, any CI/T commands, metadata, or other config changes it missed. I think this is normal behaviour for CDNs - I'm not sure any clarification is needed, but happy to add something if others do.

>- 8.1,  4th paragraph from the end:
>The language here is ambiguous about whether the use of TLS is _always_
>required, or just when "such protection is required." From context, I
>assume the latter to be the case. But "To that end..." can be interpreted
>to mean "In that case, one MUST do X", or to mean "In order to make that
>possible when needed, one MUST _always_ do X"
>
>I propose the following:
>OLD:
>   In an environment where any such protection is required, mutually
>   authenticated encrypted transport MUST be used to ensure
>   confidentiality of the CI/T information.  To that end, TLS MUST be
>   used by CI/T, including authentication of the remote end.
>NEW:
>   In an environment where any such protection is required, mutually
>   authenticated and encrypted TLS MUST be used to ensure
>   confidentiality of the CI/T information. 
>END.

This text has been discussed at-length in the context of this draft and the others.

Hopefully the version in "-12" is clearer?

>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>- 3, paragraph 5:
>SHOULD should not be equated with "optional to implement". MAY means
>that. SHOULD is intended to be stronger.

I'll change it to MAY.

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

How about:

  "If the dCDN does remove Trigger Status Resources automatically,
  it MUST report the length of time after which it will do so,
  using a property of the collection of all Trigger Status Resources"

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

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?

>Also, the first sentence is a fragment.

Oops, I'll join it to the second sentence.

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

Ok, ta.

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

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?

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

Oh, ok... that makes sense, though the logging draft also uses ccid
with an informative ref to metadata.

I guess a normative ref will mean this draft has a dependency on the
metadata draft, but perhaps that's the right thing to do.

Francois/Kevin/anyone - any views? Is there another way to fix this,
or shall I just make the ref normative?

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

The first sentence is:

  "The dCDN can delete completed and failed Trigger Status Resources..."

Which is a mistake, I'll change it to:

  "The uCDN can delete completed and failed Trigger Status Resources..."

Is that what you meant, or is there something else wrong in the example?

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

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?

--

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 15 Apr 2016 17:37:53 -0500

Hi,

Responses inline. I remove sections that don't seem to need further 
discussion (replaced with [...])

Thanks!

Ben.

On 9 Apr 2016, at 9:29, Murray, Rob (Nokia - GB) wrote:

> Hi all,
>
> Sorry, it took me ages to get to the comments before and in the end I 
> had to push out a doc update along with my responses because I was up 
> against the submission deadline - I got a comprehensive telling-off 
> from the ADs during the CDNI WG meeting!
>
>
> Alissa - I'm afraid I was also asked to chase responses, are you happy 
> with my responses to your comments, and the updates in "-12"?
>
>> Please refer to 
>> https://www.ietf.org/iesg/statement/discuss-criteria.html
> That's an internal problem for the CDN, not something CDN 
> interconnection can deal with. (The CDNI interface is between CDNs, 
> not between individual caches.)
>
> When a cache (surrogate) comes online it needs to check-for, or be 
> told about, any CI/T commands, metadata, or other config changes it 
> missed. I think this is normal behaviour for CDNs - I'm not sure any 
> clarification is needed, but happy to add something if others do.
>

The text I referred to says surrogates MUST NOT use affected data 
without revalidating if an invalidate command happened when they are 
offline. So at least this part of draft does seem to be about 
surrogates. This seems like a "MUST NOT" that is contingent upon 
something that happened when the surrogate wasn't looking. Maybe the 
"If" part is misleading, and surrogates _always_ need to revalidate any 
cached data when they come back from an offline state?

> Hopefully the version in "-12" is clearer?

Yes, thanks.

>> that. SHOULD is intended to be stronger.

I didn't mean to suggest the "SHOULD" should change, as much as the 
"optional-to-implement" description should change. But I am okay with 
whichever the working group prefers.

>   using a property of the collection of all Trigger Status Resources"

WFM.

> Does that help? Are any mods or explanations needed in the draft?

No, your explanation is fine. No change needed.

[...]

> don't think there'd be anything to gain from the extra flexibility?

I wasn't suggesting the flexibility, just that the requirement that the 
value be the same across collections might be stronger than the text 
seemed to suggest. But on reflection, I don't think the text needs to 
change.

> or shall I just make the ref normative?

I'm not sure one might fix it short of locally redefining ccid, which 
doesn't seem optimal.

> Is that what you meant, or is there something else wrong in the 

That would fix it.

> So I'd prefer to leave the MUST, is that ok?

I think the my confusion was in the "could have been required" (now "may 
have acquired") clause. Do you assume that the content may only be 
acquired from uCDNs that are authorized to also delete it?

Thanks!

Ben.

---

From: "Murray, Rob (Nokia - GB)" <[email-masked]>
Date: Sun, 17 Apr 2016 11:40:30 +0000

Hi again all - I didn't see any objections or further discussion so I've made an update ("-13") with the changes outlined below, including making the metadata reference normative.

---

From: "Murray, Rob (Nokia - GB)" <[email-masked]>
Date: Sun, 17 Apr 2016 16:20:00 +0000

Sorry Ben - somehow I missed your email before making that "-13" update earlier, just found it. Not sure how I managed to miss your email for a second time, I promise I'm not trying to ignore you! Your comments are much appreciated.

Responses inline.

Many thanks,
Rob.

>cached data when they come back from an offline state?

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.

>whichever the working group prefers.

The intent was "optional to implement" and that was spelled out explicitly, but I'd used the wrong normative language. So the change to "MAY" should be uncontentious - but if anyone disagrees, please let me know.

>I'm not sure one might fix it short of locally redefining ccid, which 

We went for making it normative, the metadata draft is nearly done as well so the dependency shouldn't be a big problem.

>acquired from uCDNs that are authorized to also delete it?

Yes, if a dCDN acquires content from a uCDN, that uCDN has to have permission to delete it (on behalf of the origin/content-owner). A CDN doesn't own the content it's serving.

Should I make that more clear in the doc?