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

[Ben Niven-Jenkins <[e-mail]>]

Alissa, Kevin,

> On 7 Jul 2016, at 20:52, Kevin Ma J <[e-mail]> wrote:
>> From: Alissa Cooper [mailto:[e-mail]]
>> ----------------------------------------------------------------------
>> 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.
> 
> 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.

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