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

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

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.




On 09/04/2016, 15:29, "Murray, Rob (Nokia - GB)" <[e-mail]> 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!
>
>
>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?
>
>--
>