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

["Matt Caulfield (mcaulfie)" <[e-mail]>]

Hi Kevin,



Thank you for the comments, please see my responses inline below.



Regards,

Matt

From: Kevin J Ma [mailto:[e-mail]]
Sent: Monday, July 16, 2012 4:40 PM
To: Matt Caulfield (mcaulfie); [e-mail]
Cc: Ben Niven-Jenkins ([e-mail])
Subject: RE: New Metadata Interface Draft (draft-cjlmw-cdni-metadata-00)

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?
[Matt>] The separation was created to categorize metadata properties. It's not essential. It may be useful if one server in a CDN is delivery a piece of content and another server is acquiring. The acquisition server could limit itself to looking at the acquisition metadata while the delivery server could limit itself to looking at the delivery metadata. Would you suggest removing this distinction?

    Though it could be argued that these are logically different
    functions, the extra layer seems unnecessary, and introduces some
    complexity to the inheritance model?
[Matt>] I don't think that the extra layer introduces any additional complexity. In our model, objects can contain objects which can contain objects, the delivery/acquisition objects aren't a special case.

    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?
[Matt>] Any object at any level can be overridden. So yes, just the Auth list could be overridden, there is no need to override the entire delivery object. Yes, the schema must be preserved - so to override the auth list it would be wrapped by a delivery object. No, there is no concept of leaf vs. branch. Based on your comment, I think we could spend more time on the description of inheritance.

    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?
[Matt>] I'm not sure what you mean by duplicate metadata. Each PathMetadata object defines a bunch of metadata properties, each one is unique. Each PathMetadata object either inherits or overrides the metadata properties of its parent.

  - 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?
[Matt>] I agree, this approach is not scalable. The general rule is that for DNS-redirection, only the HostMetadata object can be referenced by a request router. Any metadata properties which are added and need to be available at request-routing time should be restricted to the HostMetadata object. I think we could consider relaxing the restrictions on the PathMetadata object and allow the operator to choose which properties to place in each object. Will look into this further.

  - 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?
[Matt>] I don't think this is a requirement. The interface doesn't break if someone adds what is effectively an unreachable child node. In practice it should be avoided and we could add a note stating so.

    How are ambiguous patterns (e.g., "/*/foo/*") handled?  Are there
    defined restrictions on the PathMatch objects to guarantee that
    all lookups will be deterministic?
[Matt>] I don't think we've specified the exact behavior of the regex. This will need to be added.

  - 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?
[Matt>] Using a common ACL and ACLRule definitions only avoids redundancy in the draft. A better description may have kept the TimeWindow ACL completely separate from the Location ACL (separate object definitions). If more metadata properties fit the "ACL" model, then they should be added alongside TimeWindow and Location.

    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?
[Matt>] Agree.

  - 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"?
[Matt>] Correct.

    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?
[Matt>] Will need to add some definition of Mandatory to the text before we start using it. Mandatory means that that property must be defined in the metadata for a piece of content - there is no default value.

  - 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?
[Matt>] We debated whether or not to allow patterns in hostnames and decided against it. Ben can provide some of the background there. Yes, the hostname should support both IP an DNS values. No, the hostname does not include any other part of the URI. Will need to add some clarification on the hostname to the draft.

  - For Lists of objects, I did not see a specific ordering defined?
    Is there a way to enforce ordering?
[Matt>] I'm not sure I understand your question. All lists are ordered. Can you clarify?

  - 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?
[Matt>] An "x-" object can be added anywhere.

    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?
[Matt>] It is intended for adding new metadata properties, however it could be used for changing the structure of the metadata tree or changing how we do path matches as you suggest.

  - 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?
[Matt>] Yes, the ignorable property affects the entire object and all the objects it contains. The "ignorable" property can be thought of as an attribute. In the XML encoding, it would likely be an attribute (and not an element). In JSON, yes, it can lead to wrapper object.

  - 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?
[Matt>] No, there's no way to get the metadata for a specific URL without traversing the tree. This approach enforces cacheability. As for local lookups, it's up to the CDN how it store metadata internally. The local lookup speed is independent of the metadata interface speed.

  Note: I have also uploaded an updated version of my draft:
        http://tools.ietf.org/html/draft-ma-cdni-metadata-03
[Matt>] Thanks, I will check it out.

thanx.

--  Kevin J. Ma


From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]<mailto:[mailto:[e-mail]]> On Behalf Of Matt Caulfield (mcaulfie)
Sent: Monday, July 09, 2012 3:45 PM
To: [e-mail]<mailto:[e-mail]>
Cc: Ben Niven-Jenkins ([e-mail]<mailto:[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