Subject: [CDNi] Alissa Cooper's No Objection on draft-ietf-cdni-metadata-18: (with COMMENT)

From: "Alissa Cooper" <[email-masked]>
Date: Wed, 06 Jul 2016 14:52:44 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-cdni-metadata-18: No Objection

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-metadata/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- Sec 4.2.2.1: It seems odd to me that deny is the default given that
footprints are mandatory to specify. It seems like if footprints are
going to be specified, the more common case would be to specify
footprints where access is allowed, rather than where access is not
allowed.

- Sec 6.3: "the HostIndex URI could be discovered" seems like conjecture
unless some discovery mechanism has been specified somewhere. I would
suggest either citing an existing discovery mechanism or not saying
this.

- Sec 6.7: It seems like saying that CSPs and CDNs should avoid metadata
conflict isn't quite enough. If a dCDN encounters conflicting metadata,
what is it supposed to do? I think some sort of error condition would be
useful to specify.

- I support Stephen's DISCUSS.

---

From: Kevin Ma J <[email-masked]>
Date: Thu, 7 Jul 2016 19:52:03 +0000

Hi Alissa,

  Thanks for the review.  Responses inline.

--  Kevin J. Ma

> -----Original Message-----
> From: Alissa Cooper [mailto:[email-masked]]
> Sent: Wednesday, July 06, 2016 5:53 PM
> To: The IESG
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Alissa Cooper's No Objection on draft-ietf-cdni-metadata-18:
> (with COMMENT)
[snip] 

This is a fair point.  I believe the thinking was that, anyone who wants to set a restriction (LocationACL, TimeWindowACL, or ProtocolACL) is concerned about making sure that content does not go out under certain conditions, so the safest thing to do is have a default deny and require an explicit allow (so that an errant omission does not violate any license agreement).  From a message verbosity perspective, you are probably correct that a default of allow would be more efficient.  I could be persuaded either way.

> suggest either citing an existing discovery mechanism or not saying

This is also a fair point.  There had been a proposal for a bootstrap interface (draft-choi-cdni-control-init-bootstrapping), but it never materialized.  We will remove "discovery".

> what is it supposed to do? I think some sort of error condition would be

IIRC, the tricky part is knowing whether or not two pieces of metadata conflict or not?  As a human reading RFCs and config I might be able to tell, but we didn't come up with a good way to generically detect conflicts.  I suppose we could have a registry of all metadata conflicts (with the specific property values that cause the conflicts), and require that metadata interface users validate the configured combinations, but it seems unwieldy.  Do you have any specific thoughts here?

I suppose we could add another bullet to the extensibility section, requiring that new GenericMetadata objects describe any obsolescence of or conflict with any other GenericMetadata objects, but that still doesn't get us to being able to flag an error condition at run time.  I am open to suggestions.

> - I support Stephen's DISCUSS.

understood.

thanx!

--  Kevin J. Ma

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 12 Jul 2016 22:37:29 +0100

Alissa, Kevin,

> On 7 Jul 2016, at 20:52, Kevin Ma J <[email-masked]> wrote:

LocationRules (within LocationACLs) align with TimeWindowRules and ProtocolRules with a default of deny. I’d like to keep them aligned as having different semantics for different ACL rules based on type of ACL is bound to lead to implementations getting it wrong. I think the best choice is to fail closed (default deny).

As software will be producing the on the wire format, failing closed IMO gives a higher chance of the buggy implementation being caught & fixed. I don’t consider verbosity to be a worthwhile goal to optimise for in this case, the difference is minimal and if response size is a concern compress over the wire with Accept-Encoding: gzip

Ben