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

From: "Murray, Rob (Nokia - GB)" <[email-masked]>
Date: Fri, 18 Mar 2016 16:10:51 +0000

Hi Alissa and all,

I've just posted a "-12" of the CDNI Triggers draft, hopefully addressing these issues. Responses inline below.

Cheers,
Rob.

URL:            https://www.ietf.org/internet-drafts/draft-ietf-cdni-control-triggers-12.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-cdni-control-triggers/
Htmlized:       https://tools.ietf.org/html/draft-ietf-cdni-control-triggers-12
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-control-triggers-12

On 06/01/2016, 19:26, "CDNi on behalf of Alissa Cooper" <[email-masked] on behalf of [email-masked]> wrote:

>Alissa Cooper 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:
>----------------------------------------------------------------------
>
>= Section 5.1.8 =
>
>Name: staleresourcetime
>
>         Description: The length of time for which the dCDN guarantees
>         to keep a completed Trigger Status Resource.  After this time,
>         the dCDN SHOULD delete the Trigger Status Resource and all
>         references to it from collections.
>
>I'm not clear on why this is a SHOULD rather than a MUST. If the dCDN
>tells the uCDN it's going to delete resources after a specified period of
>time, why shouldn't it follow through on that? For a uCDN that relies on
>resources not sticking around after a specified period of time (because
>of security or competitive concerns), doesn't this need to be a firm
>requirement so that the uCDN doesn't have to issue purge requests to be
>sure that its resources get deleted?

I don't think there are any security or competitive concerns, a uCDN's CI/T data is only visible to that uCDN (that's a MUST in sections 3 and 8.3).

There's no inter-op reason to hold the dCDN to any strict commitment on the timing ... for example, for simplicity, a dCDN implementation might always advertise a "staleresourcetime" of 24 hours but only actually do the tidy-up once a day, removing anything that's over 1-day old.

So SHOULD seemed like the right thing here, inter-op won't be affected even if the dCDN forgets to schedule its delete for a week.

If the uCDN is getting annoyed with the clutter it can explicitly delete CI/T resources its not interested in (note it's an "HTTP DELETE" not a "CI/T purge", this is just about the CI/T tracking data, not the content or metadata in the CDN).

I've not updated the wording in "-12", but happy to make changes if there's still an issue.

>= Section 8.1 =
>
>I had the same confusion as Ben and the secdir reviewer concerning
>whether TLS is always required to use or not. If there are cases in which
>TLS is not mandatory to use, then I think this should be phrased as a
>SHOULD with the exceptions clearly enumerated. For example, it's not
>clear to me whether the only exception is environments where equivalent
>protections are afforded by a different protocol, or if just being within
>a single administrative domain is considered protection enough (not sure
>I agree with the latter).

I've updated that text to align with the other CDNI docs where the same discussion has been had.

>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>= General =
>
>I think the examples in the document should use https URIs.

It's a fair cop! Done.

>= Section 3 =
>"Trigger Status Resources belonging to a uCDN MUST NOT
>   be visible to any other CDN.  The dCDN could, for example, achieve
>   this by offering different collection URLs to each uCDN, and/or by
>   filtering the response based on the uCDN with which the HTTP client
>   is associated."
>
>Using different URLs for different uCDNs is not sufficient for this,
>correct? I think the "and/or" needs to be just "and".

Ok, done.

>= Section 4.1 =
>I don't understand the difference between when status is used in quotes
>and not in quotes, e.g., 'Once processing has started the "status" MUST
>be "active"' vs. 'once the CI/T Command is complete, the status MUST be
>set to "complete" or "failed"'.

There isn't one, looks like I just got a bit carried away with the quote button. Tidied up now I think.

>= Section 4.3 =
>s/requires no processing in the dCDN, its status MUST NOT be
>changed/requires no processing in the dCDN. Its status MUST NOT be
>changed/

Done.

>= Section 5.1.1 =
>
>"Name: cdn-path
>
>         Description: The CDN Provider Identifiers of CDNs that have
>         already accepted the CI/T Command."
>        
>I find the phrase "already accepted" somewhat confusing, since a uCDN is
>supposed to insert its own on ID here, and in that sense hasn't
>"accepted" anything, but is making the request itself.

Changed to "... that have already issued the CI/T Command to their dCDNs".

>
>= Section 8.3 =
>s/parties other party than the authorised dCDN/parties other than the
>authorised dCDN/

Done.

>
>
>_______________________________________________
>CDNi mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/cdni