Re: [CDNi] New Metadata Interface Draft (draft-cjlmw-cdni-metadata-00)

[Kevin J Ma <[e-mail]>]

Hi Ben,

  thanx for the response.  comments inline:

> -----Original Message-----
> From: Ben Niven-Jenkins [mailto:[e-mail]]
> Sent: Tuesday, July 17, 2012 4:06 PM
> To: Kevin J Ma
> Cc: Matt Caulfield (mcaulfie); [e-mail]; Ben Niven-Jenkins
> ([e-mail])
> Subject: Re: [CDNi] New Metadata Interface Draft (draft-cjlmw-cdni-
> metadata-00)
> 
> Hi Kevin,
> 
> Thanks for reading the draft, some good questions. My opinion inline.
> 
> 
> On 16 Jul 2012, at 21:40, Kevin J Ma wrote:
> 
> > Hi Matt,
> >
> >   A couple of initial comments/questions about the merged draft:
> >
> >   - I do not understand the need for a heirarchical separation of the
> >     Acquisition and Delivery objects?  Why is the property "key" not
> >     sufficient for designating the function of the metadata?
> 
> This is a good question and something we discussed at length amongst the
> authors but probably don't really talk about in the draft.
> 
> We discussed a lot the trade offs between embedding all CDNI metadata
> properties together versus splitting some out into different object that
> could be independently cached/retrieved.
> 
> We decided not to try to optimise too early so we took an approach of
> allowing any object to be embedded or independently addressable. This
> leads to the data model being slightly more convoluted and it can
> certainly be optimised a bit IMO. But we decided on an approach where we
> first had a stable/agreed model with the WG and then we could revisit it
> see what optimisations make sense.

Understood.  My specific concerns were with:
a) how extra levels might impact local cache implementations, i.e.,
   which objects can be compacted locally vs. how much the structure
   must be maintained, in order to understand how to update individual
   objects without traversing the entire recursion tree, and
b) how error prone inheritance-based override might be if there are
   alot of levels at which errant overrides could be applied.

> >     Though it could be argued that these are logically different
> >     functions, the extra layer seems unnecessary, and introduces some
> >     complexity to the inheritance model?
> >
> >     With inheritance-based override, can a lower level PathMetadata
> >     object override just an Auth List, or does it have to replace the
> >     entire Delivery object?
> 
> This is an area where we need to flesh out the specification and not one
> we've fully fleshed out yet.
> 
> My current thinking is to only have to specify those properties which you
> want to override compared to the parent PathMetadata object.
>
> >  Does it have to place the Auth List
> >     inside a lower level Delivery object, or can it just define a new
> >     Auth List with no Delivery object wrapper?
> 
> Currently yes but when we revisit the data model to look for optimisations
> this is a good candidate.
> 
> >  Is there a concept of
> >     leaf vs. branch objects for override purposes?
> 
> I'm not exactly sure what you mean by leaf vs branch

My confusion comes from whether or not a Delivery object with an Auth List
inside it overrides the Delivery object or just the Auth object.  It could
be that the Delivery object is just a logical/organizational object that is
never overriden in its entirety, in which case it could be considered a
"branch", but the Auth List is a metadata object that requires actions,
which could classify it as a "leaf".

If my root Delivery object has a protocol, location ACL, and auth list,
and a Delivery object further down only specifies a location ACL:
a) is it valid, since it does not have a protocol?
b) does it only override the location ACL?
   or does it imply that no auth list should be used?
   i.e., do you have to re-specify every field?
         if not are there rules for what falls through?
c) if it only overrides the location ACL, if one wanted to not have an
   auth list at the lower level, does that require specifying an empty
   auth list to override the root level auth list?

As has been noted, we probably need to expand the discussion of the
inheritance rules.

[snip]
> >
> >   - In the HostMatch object, the hostname Property is defined as a
> >     String?  Should there be Pattern support for hostnames?
> 
> I'd need to think about that a bit more first but I think there might be
> some value to that.
> 
> >  Also,
> >     does hostnames support both IP and DNS values?
> 
> I'm not sure of the use case for IP values as clients connecting to CDNs
> aren't typically given a URL with an IP address as a hostname.

For the public Internet I would agree, however, there are cases where MSOs
building internal CDNs prefer (for whatever reason) IP addresses.

> >   Also, does the
> >     hostname support a URI prefix that should be matched as part of
> >     the hostname, and not be included in the PathMatch?
> 
> No, the hostname is essentially the HTTP Host: header. All URL prefixes
> are via PathMetadata.

So, in a case where a given CDN requires some type of URI path prefix,
would the CDN specific URI path prefix live in the PathMatch, or would
it be up to the local CDN to recognize the URI path prefix, and then
match against the remainder of the URL?  e.g.,

  client requests cdn1.com/cdn1_prefix/video/x.m3u8
  cdn1 redirects to cdn2.com/cdn2_prefix/video/x.m3u8

Do we think this a valid use case?  If so, should the PathMatch have
a URI of "video/*.m3u8" or "cdnN_prefix/video/*.m3u8"?  If the latter,
whose responsibility is it to properly construct that PathMatch and
what information would need to be passed between CDNs to do that?

> >   - For Lists of objects, I did not see a specific ordering defined?
> >     Is there a way to enforce ordering?
> 
> Lists are ordered. In JSON they would be an array with N entries, with
> index[0] being first and index[N-1] being last.

XML is a little more problematic with unordered lists.

For this to work, the list itself must be cached as an object, as it
contains the explicit ordering?  It is not just the objects which it
references that need to be cached and refreshed, i.e., the list order
could change even if none of the objects in the list have changed?

If using the native JSON directly, it is probably implied, but as a
generic model for other implementations it might be worth explicitly
defining the properties of a list?

[snip]
> >     Can I add a new ACL type?  Can I add a new pattern matching option
> >     to the HostMatch and/or PathMatch objects (fundamentally changing
> >     the way hosts and paths are matched)?  Can I add new types of
> >     location algorithms (e.g., GPS coordinates or zip code) to the
> >     Location object?  Or is it intended more for just creating a new
> >     hierarchy under the Delivery object?
> 
> IMO you can potentially do all those things. I think if you had lots of
> them as mandatory extensions you might be better off minting a vendor
> specific delivery protocol identifier to give dCDNs a heads-up that they
> needed to support a lot of vendor/extension-specific capabilities, but
> there are certainly other ways to do that too (depending how the
> capabilities advertisement interface evolves).

Agreed.  Being overly flexible here could open up some interesting issues
wrt being able to fundamentally change the way mandatory properties behave.
But it does come down to how well the capabilities are advertised.

thanx.

--  Kevin J. Ma

> >   Note: I have also uploaded an updated version of my draft:
> >         http://tools.ietf.org/html/draft-ma-cdni-metadata-03
> 
> Thanks. I'll give it a read when I get a chance.
> 
> Ben
> 
> >
> > thanx.
> >
> > --  Kevin J. Ma
> >
> >
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Matt Caulfield (mcaulfie)
> > Sent: Monday, July 09, 2012 3:45 PM
> > To: [e-mail]
> > Cc: Ben Niven-Jenkins ([e-mail])
> > Subject: [CDNi] New Metadata Interface Draft (draft-cjlmw-cdni-metadata-
> 00)
> >
> > Hi everyone,
> >
> > As we announced in April, a group of us (Ben Niven-Jenkins, Kent Leung,
> Rob Murray, Grant Watson, and I) have been working on a merge of two of
> the CDNI metadata interface proposals:
> > -       draft-caulfield-cdni-metadata-core-00
> > -       draft-jenkins-cdni-metadata-00
> >
> > The merged draft has now been submitted:
> http://tools.ietf.org/html/draft-cjlmw-cdni-metadata-00
> >
> > We will be presenting on this draft in Vancouver. Any feedback on the
> list is also appreciated.
> >
> > Thanks,
> > Matt
> >
> >
> >
> > _______________________________________________
> > CDNi mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/cdni