Subject: Re: [CDNi] First batch of comments from review of draft-ietf-cdni-metadata-00.txt

From: Kevin J Ma <[email-masked]>
Date: Sun, 4 Nov 2012 15:07:23 -0500

Hi Francois,

  All great comments.  Some quick answers to a couple of the questions:

  > why does "\" have to be escaped if it does not have ay special meaning (like "*" and "?") ?

  The backslash has the special meaning as the escape character; it
  needs to be escapeable to allow the literal backslash character
  to appear directly adjacent to wildcards, e.g., "\\*".

  > can you discuss your assumptions here for how content would be acquired in that case?

  The thinking was that if content was all pre-positioned, there may
  be no need to acquire it.

  > when there are multiple sources listed: is it in descending order of preference from viewpoint of dCDN? is it left to the dCDN?

  The thought is that lists are ordered from highest to lowest precedence.
  The use of explicit priorities for list entries was discussed, but not
  added.  There is still question imo as to who is allowed to alter the
  order (or explicit priorities).  Certain security properties set by
  the content provider should probably not be reordered by dCDNs, but
  perhaps a dCDN should be allowed to add or modify the priority of
  acqusition sources.

  From your second batch of comments, about section 4.3.2:
  > * section 4.3.2 Protocol:

  I think this section probably just needs some general cleanup.
  Looks like it may have come directly from draft-jenkins-cdni-metadata
  and probably lost some of its original context.

  wrt your final comment on framework section 4.6:
  > I'd picture the "Check-with-uCDN" as something that can be used "in addition" to access control rules that may be distributed to dCDN and not "instead of".

  My interpretation of the framework text was that Metadata revalidation
  was required.  The existing metadata properties already contain the
  ability to specify deny rules?

  While the check-with-me flag is easy to add, what would be the protocol
  used in the check?  Does a protocol need to be defined here, or at least
  a protocolID specified so that the dCDN knows how to check?  There are
  also a number of security issues that come to mind with the check api,
  which are probably beyond the scope of the metadata interface.

thanx.

--  Kevin J. Ma

> -----Original Message-----
> From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
> Sent: Tuesday, October 23, 2012 2:11 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: First batch of comments from review of draft-ietf-cdni-metadata-
> 00.txt
>
> Hello,
>
> I started doing a review of draft-ietf-cdni-metadata-00.txt (as an
> Individual).
>
> This document is shaping up very well.
>
> My specific comments/questions/suggestions are listed below (I stopped
> just before section 4.3).
>
> I hope this is useful.
>
> Francois
>
>
> Comments/Suggestions
> ==================
>
> OLD:
> "
> Cacheability improves the latency of acquiring metadata
> "
> NEW:
> "
> Cacheability improves the latency of acquiring metadata while maintaining
> its freshness
> "
>
>
> OLD:
> "
> Deterministic mappings from content requests to metadata properties
>    eliminates ambiguity and ensures that the same policies are applied
>    consistently by all downstream CDNs.
> "
> NEW:
> "
> Deterministic mappings from content to metadata properties
>    eliminates ambiguity and ensures that policies are applied
>    consistently by all downstream CDNs.
> "
> (the policies may not be exactly the same for all dCDNs, but they need to
> be deterministic so uCDN can achieve consistent operation)
>
>
> OLD:
> "
> describes a data structure for mapping
>    content requests to metadata properties
> "
> NEW:
> "
> describes a data structure for mapping
>    redirection requests and content requests to metadata properties
> "
> (Note: this occurs many times throughout the documents)
>
>
> OLD:
> "
> A HostIndex object contains a list of Hostnames (and/or IP addresses)
>    that may be delegated to the downstream CDN.
> "
> NEW:
> "
> A HostIndex object contains a list of Hostnames (and/or IP addresses)
>    for which content requests may be delegated to the downstream CDN.
> "
>
>
> OLD:
> "
> When looking up CDNI Metadata, the downstream CDN looks
>    up the requested Hostname (or IP address) in the HostIndex, from
>    there it can find HostMetadata which describes delivery rules for a
>    host and PathMetadata which may override those rules for given URI
>    paths within the host.
> "
> NEW:
> "
>  When looking up CDNI Metadata, the downstream CDN looks
>    up the requested Hostname (or IP address) in the HostIndex, from
>    there it can find HostMetadata which describes properties for a
>    host and PathMetadata which may override those properties for given URI
>    paths within the host.
> "
> (rationale: there is more to metadata than just delivery rules, e.g.
> acquisition info).
>
>
> OLD:
> "
>    | HostIndex       | A HostIndex object lists the Hostnames (and/or  |
>    |                 | IP addresses) that an upstream CDN can provide  |
>    |                 | CDNI Metadata for and the URIs to use for       |
>    |                 | retrieving that CDNI Metadata.  For example, if |
>    |                 | "example.com" is a content provider, the        |
>    |                 | HostIndex object may include an entry for       |
>    |                 | "example.com" with the URI of the associated    |
>    |                 | HostMetadata object.  These hostnames are       |
>    |                 | contained inside a list of HostMatch objects.   |
>    | HostMatch       | A HostMatch object defines a hostname to match  |
>    |                 | against a requested host, and contains or       |
>    |                 | references a HostMetadata object which contains |
>    |                 | CDNI Metadata objects to be applied when a      |
>    |                 | content request matches against the hostname.   |
> "
> NEW:
> "
>    | HostIndex       | A HostIndex object lists HostMatch objects|
>    | HostMatch       | A HostMatch object defines a hostname (and/or IP
> addresses)  to match  |
>    |                 | against a requested host, and contains or       |
>    |                 | references a HostMetadata object which contains |
>    |                 | CDNI Metadata objects to be applied when a      |
>    |                 | request matches against the hostname.   |
>   |              | For example, if |
>    |                 | "example.com" is a content provider, a        |
>    |                 | HostMatch object may include an entry for       |
>    |                 | "example.com" with the URI of the associated    |
>    |                 | HostMetadata object.
> "
> (Rationale: as currently written, I had a hard time follow the structure.
> Because it first says that the HostIndex lists the hostnames and then
> explains that those are actually contained inside HostMatch)
>
>
>
>
> OLD:
> "
>    | PathMatch       | A PathMatch object defines a pattern to match   |
>    |                 | against the requested path, and contains or     |
> "
> NEW:
> "
>    | PathMatch       | A PathMatch object defines a pattern to match   |
>    |                 | against the requested URI path, and contains or
> |
> "
>
>
>
> In Figure 1, I think it would help a bit if you indicated next to each
> reference, the valid number of such references.
> For example, from HostIndex to HostMatch it would say: " ---(0-N)--->"
> From HostMatch to HostMetadata it would say :"---(1)-->"
>
>
> OLD:
> "
>    | GenericMetadata | A GenericMetadata object contains individual    |
>    |                 | CDNI Metadata property objects which define the |
> "
> NEW:
> "
>    | GenericMetadata | A GenericMetadata object contains individual    |
>    |                 | CDNI Metadata objects which define the |
> "
>
>
> section 3.2, 1st and 2nd paragraph:
> "serialization rules, etc.)": this is the first time "serialization" is
> mentioned (and "deserialization" is then mentioned in 2nd paragraph). I
> think this terms need some description.
>
>
> section 3.2, 2nd & 3rd paragraph:
> 2nd paragraph specifies behavior when property is not supported and
> mandatory.
> I think the third paragraph implies that when it is not mandatory then
> whether or not it can be re-distributed in a cascaded CDNs scenario
> depends on the specific "redistribution friendliness" of the object. If I
> am correct then:
>       * you shoudl first indicate that when object is not understood and
> not mandatory, the request can be served.
>       * and then explain that with respect to redistribution in case of
> cascaded CDNs, here is the rule.
> Have you considered using the term "Transitive" instead of "Redistribution
> safety" (i.e. as used in BGP)  (this would also impact text in section
> 4.1.7)?
>
>
> section 3.3.
> You define precisely the scenarios where override happens. While implied,
> it may be worth explicitly saying when inheritance happens. Something
> like:
> "
> Objects of a given type previously defined by a parent object in
>    the tree are inherited when no object of the same type is defined by
> the child object.
>
> "
> And I'd suggest using your existing example to illustrate that also. So,
> OLD:
> "
> GenericMetadata objects of a given type override all GenericMetadata
>    objects of the same type previously defined by any parent object in
>    the tree.  For example, if HostMetadata for the host "example.com"
>    contains GenericMetadata objects of type LocationACL and
>    TimeWindowACL, while a PathMetadata object which applies to
>    "example.com/movies/*" defines an alternate GenericMetadata object of
>    type TimeWindowACL, The PathMetadata defined TimeWindowACL would
>    override the TimeWindowACL defined in the HostMetadata for all User
>    Agent requests for movies.
> "
> NEW:
> "
> GenericMetadata objects of a given type override all GenericMetadata
>    objects of the same type previously defined by any parent object in
>    the tree.  Objects of a given type previously defined by a parent
> object in
>    the tree are inherited when no object of the same type is defined by
> the child object.
> For example, if HostMetadata for the host "example.com"
>    contains GenericMetadata objects of type LocationACL and
>    TimeWindowACL, while a PathMetadata object which applies to
>    "example.com/movies/*" defines an alternate GenericMetadata object of
>    type TimeWindowACL, then:
>       * the TimeWindowACL defined in the PathMetadata would
>    override the TimeWindowACL defined in the HostMetadata
>       * the LocationACL defined in the HostMetadata would be inherited
>  for all User Agent requests for content under "example.com/movies".
> "
>
>
> OLD:
> "
> 3.3.  Metadata Inheritance
> "
> NEW:
> "
> 3.3.  Metadata Inheritance and Override
> "
>
>
> section 3.4.
> While it is useful to provide an example of naming for vendor extensions,
> it is a little confusing to only provide such an example.
> I suggest you first include an example of Metadata Name actually specified
> by this document (e.g. "HostMetadata"?) and only then go into further
> details for vendor extensions.
>
>
> section 4.1.1:
> OLD:
> "
> The HostIndex object is the entry point into the CDNI Metadata
>    hierarchy. An incoming content request is matched against the list
>    of hosts to find the HostMatch object which applies to the request.
> "
> NEW:
> "
> The HostIndex object is the entry point into the CDNI Metadata
>    hierarchy. It contains a list of HostMatch objects. An incoming request
> is matched against the hostname inside each of the listed HostMatch
> objects to find the HostMatch object which applies to the request.
> "
>
> section 4.1.2:
> OLD:
> "
> The HostMatch object contains a hostname or IP address to match
>    against content requests.  The HostMatch object references Metadata
>    objects to apply if a match is found.
> "
> NEW:
> "
> The HostMatch object contains a hostname or IP address to match
>    against content requests.  The HostMatch object also contains a
> reference to Metadata
>    objects to apply if a match is found.
> "
>
>
> section 4.1.2:
> I think you need to specify behavior in case there are separate HostMatch
> objects for a domain and one of its subdomain. e.g. "video.example.com"
> and "premium.video.example.com".  "first match applies" or "more specific
> match"?
>
>
> section 4.1.6:
> "The three literals \ , * and ? should be escaped as \\, \* and \?"
> why does "\" have to be escaped if it does not have ay special meaning
> (like "*" and "?") ?
>
>
> section 4.2.1:
> "
>       Property: sources
> ...
>          Mandatory-to-Specify: No.
> "
> So how would content be acquired in the absence of a "sources" property?
> via some out-of-scope configuration? in any case, can you discuss your
> assumptions here for how content would be acquired in that case?
>
>
> section 4.2.1:
> You need to indicate expected behavior when there are multiple sources
> listed: is it in descending order of preference from viewpoint of dCDN? is
> it left to the dCDN? something else? I would assume the 1st option.
>
>
> section 4.2.1.1:
> Since the sources property contains a list of sources, do we also need to
> allow multiple endpoints within each source?
> Is the targeted benefit to avoid replication when you have multiple
> endpoints that can be used with the exact same auth and protocol
> properties?
>
>
> section 4.2.2:
> "
>    LocationACL Metadata defines location-based restrictions.
>       Property: locations
> "
> Should the Property not be called "Property: locationACL"?
> If not, does this not conflict with the "Property: locations" of section
> 4.2.2.1?
>
>
> section 4.2.2:
> OLD:
> "
>    A LocationRule contains or references a list of Location objects.
>    LocationRule objects are used to construct a LocationACL to apply
>    restrictions to content delivery.
> "
> NEW:
> "
>    A LocationRule contains or references a list of Location objects and
> the corresponding action.
> "
> (Note: the 2nd sentence is redundant with the description text in section
> 4.2.2)
>
>
> section 4.2.2.1:
> "
>       Property: action
>          Description: Defines whether the rule specifies locations to
>          allow or deny.
>          Type: Enumeration [allow|deny]
>          Mandatory-to-Specify: Yes.
> "
> Why not specify a Default action and make this a "Mandatory-to-Specify:
> No"?
>
>
> section 4.2.2.2:
> OLD:
> "
>    A Location object describes a Location which may be applied by an
>    ACLRule, e.g. a Location may be an IPv4 address range or a geographic
>    location.
> "
> NEW:
> "
>    A Location object describes a location which may be used as part of a
> LocationRule,
>  e.g. a Location may be an IPv4 address range or a geographic
>    location.
> "
>
>
> section 4.2.3:
> "
>    TimeWindowACL Metadata defines time-based restrictions.
>       Property: times
> "
> shoudl the Property not be named something like  "Property:
> TimeWindowACL"?
> If not, does this not conflict with the "Property: times" of section
> 4.2.3.1?
>
>
> section 4.2.3.1:
> OLD:
> "
>    A TimeWindowRule contains or references a list of TimeWindow objects.
>    TimeWindowRule objects are used to construct a TimeWindowACL to apply
>    restrictions to content delivery.
> "
> NEW:
> "
>    A TimeWindowRule contains or references a list of TimeWindow objects
> and the corresponding action
> "
>
> section 4.2.3.1:
> "
>       Property: action
>          Description: Defines whether the rule specifies time windows to
>          allow or deny.
>          Type: Enumeration [allow|deny]
>          Mandatory-to-Specify: Yes.
> "
> Why not specify a Default action and make this a "Mandatory-to-Specify:
> No"?
>
>
> Table 3:
> "Table 3: MIME Media Types for CDNI Metadata resources"
> You have been using the terms of objects and properties before. Is
> "resource" really the right term here?
>
>
>
>
>
>
> Editorials:
> =======
>
> OLD:
> "
> [I-D.ietf-cdni-problem-statement]
> "
> NEW:
> "
> RFC 6707
> "
>
>
> OLD:
> "
> are specified in [I-D.ietf-cdni-requirements]
> "
> NEW:
> "
> are specified in [I-D.ietf-cdni-requirements].
> "
>
>
> OLD:
> "
> The proposed CDNI Metadata Interface aims to achieve the following design
> principles:
> "
> NEW:
> "
> The CDNI Metadata Interface was designed to achieve the following
> objectives:
> "
>
>
> OLD:
> "
> Deterministic mapping from content requests to CDNI metadata properties
> "
> NEW:
> "
> Deterministic mapping from content to CDNI metadata properties
> "
> OR
> "
> Deterministic mapping from redirection requests and content requests to
> CDNI metadata properties
> "
>
>
>
> OLD:
> "
> Different Hostnames and URI paths will contain different sets of CDNI
>    Metadata properties
> "
> NEW:
> "
> Different Hostnames and URI paths will be associated with different sets
> of CDNI
>    Metadata properties
> "
>
>
>
> OLD:
> "
>       Property: pattern
>          Description: >A pattern for string matching.
> "
> NEW:
> "
>       Property: pattern
>          Description: A pattern for string matching.
> "
>
>
> section 4.1.7:
> OLD:
> "
> the the property
> "
> NEW:
> "
> the property
> "
>
>
> section 4.2.1
> OLD:
> "
> how to contact an uCDN Surrogate or an Origin Server.
> "
> NEW:
> "
> how to contact an uCDN Surrogate or an Origin Server in order to obtain
> the content to be served.
> "
>
>
> section 4.2.1/4.2.1.1/4.2.2/4.2.2.1
> "Type: List of Source"/ "List of EndPoint"/"List of LocationRule"/"Type:
> List of Location"
> The singular after |list" reads off to me. I can see that those are object
> names, but still I would consider using plural (e.g. List of Sources") or
> possibly something like  "List of Source properties"
>
>
>
>
> On 2 Oct 2012, at 19:40, Matt Caulfield (mcaulfie) wrote:
>
> > Hi everyone,
> >
> > We have posted the first revision of the Metadata Interface Draft which
> was accepted as a WG doc in Vancouver: draft-ietf-cdni-metadata.
> >
> > Your comments and feedback are appreciated.
> >
> > Regards,
> > Matt Caulfield
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Tuesday, October 02, 2012 1:35 PM
> > To: Matt Caulfield (mcaulfie)
> > Cc: [email-masked]; Kent Leung (kleung); [email-masked];
> [email-masked]; [email-masked]
> > Subject: New Version Notification for draft-ietf-cdni-metadata-00.txt
> >
> >
> > A new version of I-D, draft-ietf-cdni-metadata-00.txt has been
> successfully submitted by Matt Caulfield and posted to the IETF
> repository.
> >
> > Filename:    draft-ietf-cdni-metadata
> > Revision:    00
> > Title:               CDN Interconnect Metadata
> > Creation date:       2012-10-02
> > WG ID:               cdni
> > Number of pages: 35
> > URL:             http://www.ietf.org/internet-drafts/draft-ietf-cdni-
> metadata-00.txt
> > Status:          http://datatracker.ietf.org/doc/draft-ietf-cdni-
> metadata
> > Htmlized:        http://tools.ietf.org/html/draft-ietf-cdni-metadata-00
> >
> >
> > Abstract:
> >   The CDNI Metadata Interface enables interconnected CDNs to exchange
> >   content distribution metadata in order to enable content acquisition
> >   and delivery.  The CDNI metadata associated with a piece of content
> >   provides a downstream CDN with sufficient information for the
> >   downstream CDN to service content requests on behalf of an upstream
> >   CDN.  This document describes both the core set of CDNI metadata and
> >   the protocol for exchanging that metadata.
> >
> >
> >
> >
> >
> > The IETF Secretariat
> >
> > _______________________________________________
> > CDNi mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/cdni