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

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

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.



On 15/04/2016, 23:37, "EXT Ben Campbell" <[e-mail]> wrote:

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

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.


>>> - 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?
>
>Yes, thanks.
>
>>
>>
>>> ----------------------------------------------------------------------
>>> 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.
>
>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.

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.


>>> - 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"
>>
>
>WFM.
>
>>
>>> -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?
>>
>
>No, your explanation is fine. No change needed.
>
>[...]
>
>
>>
>>
>>> - 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?
>>
>
>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.
>
>>
>>> - 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?
>
>I'm not sure one might fix it short of locally redefining ccid, which 
>doesn't seem optimal.

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


>>> - 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?
>
>That would fix it.
>
>>
>>
>>> - 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?
>
>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?

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?

>
>Thanks!
>
>Ben.