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

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

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" <[e-mail]> 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?

--