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

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

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?

    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?  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?  Is there a concept of
    leaf vs. branch objects for override purposes?

    In general, if there are an arbitrary number of levels below each
    object, and an arbitrary number of levels of PathMetadata which
    may contain objects with arbitrary levels of metadata which may
    override previous levels, is there a need to check that duplicate
    Metadata do not exist within a given subtree, and/or should that
    restriction be stated explicity?

  - I see that the PathMetadata defines some restrictions to what it
    may contain, however, this does not seem like a scalable method of
    managing object restrictions.  As we move forward and more vendor
    specific metadata are defined, managing metadata collisions using
    the such a method seems complex, in that the CDNI Metadata RFC
    could need to be continuously updated to add more restrictions.
    It would be nice if there was a general set of rules for how and
    where to define new metadata, rather than creating highly
    customized objects which have complex modification restrictions?

  - I assume that the inheritance model requires that PathMatch
    objects must match the path of all PathMatch objects above it in
    the hierarchy?  i.e., I cannot add a PathMatch for "/bar/baz"
    inside a PathMetadata whose PathMatch was for "/foo"?  It is
    probably worth stating explicitly?

    How are ambiguous patterns (e.g., "/*/foo/*") handled?  Are there
    defined restrictions on the PathMatch objects to guarantee that
    all lookups will be deterministic?

  - In the ACLRule object, if you can only have either an allow or a
    deny Property but not both, and the ACLRule list can only have
    either Location or TimeWindow properties but not both, it is not
    clear that much is gained by combining them into the same ACL and
    ACLRule objects?  In the future, if new types of ACLs are added,
    would we modify these existing objects (and rev the CDNI Metadata
    RFC), or just add separate object definitions?

    The reuse of object definitions, in this case, does not seem to
    buy us anything?  Defining separate LocationACL/LocationACLRule
    objects and TimeWindowACL/TimeWindowACLRule objects, where
    allow/deny is just an attribute/property would result in
    essentially the same implementation, but without the
    interdependendies, which would simplify future revisions?

  - In the Property definitions, I assume that the "key" is the term
    that follows the "Property:" tag, and that the "Description:" and
    "Type:" indented below describe the "value"?

    It was not clear to me what the "Mandatory:" tag implied?
    Mandatory to specify the Property in every object?  Mandatory to
    implement support for the Property?  or Mandatory to enforce the
    Property?  It might be useful to explicitly define Mandatory?

  - In the HostMatch object, the hostname Property is defined as a
    String?  Should there be Pattern support for hostnames?  Also,
    does hostnames support both IP and DNS values?  Also, does the
    hostname support a URI prefix that should be matched as part of
    the hostname, and not be included in the PathMatch?

  - For Lists of objects, I did not see a specific ordering defined?
    Is there a way to enforce ordering?

  - With respect to extensibility, can an "x-" object be added to any
    other object, or are there restrictions on where a new custom
    object may be added into the hierarchy?

    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?

  - With respect to the "ignorable" Property, does that affect the
    entire parent object to which it is added?  If it is a Property
    itself (rather than an attribute of a Property), then does that
    require a wrapper object around the actual Property and the
    "ingnorable" Property, for all new Properties?  Should it be a
    standard attribute like Mandatory?

  - Is there a way for the client to request metadata for a given URI,
    rather than recursively checking and requesting PathMetadata?
    Doesn't this lead to alot of lookups (even local cache lookups)
    for each request, to find all of the applicable PathMetadata?
    Are there optimizations for local cache lookup?

  Note: I have also uploaded an updated version of my draft:
        http://tools.ietf.org/html/draft-ma-cdni-metadata-03

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