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

"Ben Campbell" <ben@nostrum.com> Fri, 15 April 2016 22:37 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF56E12DF84; Fri, 15 Apr 2016 15:37:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Level:
X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHTP2B_LVef2; Fri, 15 Apr 2016 15:37:57 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8FE912DF1F; Fri, 15 Apr 2016 15:37:56 -0700 (PDT)
Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u3FMbrZC001758 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 15 Apr 2016 17:37:54 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10]
From: Ben Campbell <ben@nostrum.com>
To: "Murray, Rob" <rob.murray@nokia.com>
Date: Fri, 15 Apr 2016 17:37:53 -0500
Message-ID: <F2BBD6F8-257D-47A1-A5FC-2BCD7F8B7D66@nostrum.com>
In-Reply-To: <2B2272E2-8204-4F9D-B3BD-C91AAD1D95A5@alcatel-lucent.com>
References: <20160106034020.10393.24093.idtracker@ietfa.amsl.com> <2B2272E2-8204-4F9D-B3BD-C91AAD1D95A5@alcatel-lucent.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <http://mailarchive.ietf.org/arch/msg/cdni/tw4loNl1bnEnB-UgPmdpcih6pdg>
Cc: "cdni@ietf.org" <cdni@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [CDNi] Ben Campbell's Discuss on draft-ietf-cdni-control-triggers-11: (with DISCUSS and COMMENT)
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" <cdni.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cdni>, <mailto:cdni-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cdni/>
List-Post: <mailto:cdni@ietf.org>
List-Help: <mailto:cdni-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cdni>, <mailto:cdni-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Apr 2016 22:37:58 -0000

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" <ben@nostrum.com> 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?

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

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

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


Thanks!

Ben.