Subject: Re: [CDNi] Proposal for a CDNI Metadata model & interface

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 6 Oct 2011 12:07:39 -0500

Hi, Ben,

Just checking - would this draft be the place where text on handling of 
unknown metadata elements would be included?

Thanks,

Spencer

> Colleagues,
>
> We just uploaded a proposal for a CDNI Metadata model and an interface 
> specification for distributing CDNI Metadata (see below).
>
> This initial version does not attempt to articulate all the CDNI Metadata 
> that would be required to satisfy all CDNI use cases. Instead, we have 
> proposed a smaller set of properties that should be sufficient to 
> implement a minimal interconnect of basic HTTP delivery.
>
> This is because, at this stage the important thing in our opinion is to 
> focus any discussion on the overall structure of the interface rather than 
> on the details or omission of particular properties.
>
> Our proposal is available here:
> http://tools.ietf.org/html/draft-jenkins-cdni-metadata-00
>
> Thanks
> Ben, David & Grant
>
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni
>

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 17 Oct 2011 13:10:54 -0700

Hi Ben, David, Grant,

[Individual hat on]

One quick question:
"
  The CDNI Metadata interface specified in this document is a read-only
   interface.  Therefore support for other HTTP methods such as PUT,
   POST and DELETE etc. is not specified.  Server implementations of
   this interface SHOULD reject all methods other than GET and HEAD.
"
So to deal with metadata changes/invalidation reactively, the uCDN/dCDN would play with TTL and conditional gets.
So we end up with deployment trade-offs requiring tuning between reactivity and revalidation load.
Support of update/removal in the CDNI interface would allow to ensure high reactivity for the important changes (eg immediately stop serving content to a given region) while setting TTLs higher to ensure low revalidation load.
Is your motivation to exclude support for update/removal to keep things as simple as possible so the group can define a minimum solution asap, or do you think update/removal won't be needed at all even if we picture large scale deployments.

Cheers

Francois

On 12 Sep 2011, at 07:07, Ben Niven-Jenkins wrote:

> Colleagues,
> 
> We just uploaded a proposal for a CDNI Metadata model and an interface specification for distributing CDNI Metadata (see below).
> 
> This initial version does not attempt to articulate all the CDNI Metadata that would be required to satisfy all CDNI use cases. Instead, we have proposed a smaller set of properties that should be sufficient to implement a minimal interconnect of basic HTTP delivery.
> 
> This is because, at this stage the important thing in our opinion is to focus any discussion on the overall structure of the interface rather than on the details or omission of particular properties.
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 18 Oct 2011 09:00:05 +0100

Francois,

Good question, see below.

> Is your motivation to exclude support for update/removal to keep things as simple as possible so the group can define a minimum solution asap, or do you think update/removal won't be needed at all…

Neither. Although we don't say so explicitly in the draft our thinking was to model explicit CDNI Metadata invalidation/removal in the same manner as explicit invalidation/removal of actual content and have that performed via a request over the CDNI Control interface rather than having two separate approaches - one for CDNI metadata and a different one for the content itself.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 18 Oct 2011 11:36:37 +0100

Spencer,

Apologies for the delay in responding, your mail got buried in my inbox.

On 6 Oct 2011, at 18:07, Spencer Dawkins wrote:

> Hi, Ben,
> 
> Just checking - would this draft be the place where text on handling of unknown metadata elements would be included?

Good question.

It depends what you mean by "unknown".

I think our draft is definitely the place to specify handling of malformed responses.

The actual properties associated with the metadata can be split into two parts:
1) Delivery protocol independent properties (e.g. ACLs/Locations/Origin properties)
2) Delivery protocol dependent properties (e.g. specific features associated with a particular delivery protocol or version of a delivery protocol)

Currently the draft defines some protocol independent properties but doesn't really define any protocol dependent properties.

The metadata draft uses a well-known (i.e. has to be registered in a registry somewhere) URI to identify the Delivery Protocol where the URI is really just a different form of codepoint. The metadata draft assumes that a sister specification defines the interoperable feature set (for CDNI) associated with that URI. That sister specification could be for example the RFC that defines the Delivery Protocol (e..g RFC2616 for HTTP/1.1) and a separate specification could define the CDNI Metadata properties used to describe the protocol features, or a single specification could for example define a profile of the Delivery protocol along with the associated CDNI metadata properties.

If by "unknown" you mean "does not support the underlying protocol feature but does recognise the property name" then the specification that defines the profile/properties for that protocol (either the metadata draft itself or the sister draft specifying the metadata properties for a particular protocol) should define which features are mandatory and must be applied and which features are left to the dCDN as to whether they enforce them or not. Therefore whether a dCDN can ignore a feature it doesn't support and still deliver the content or whether it must reject request routing/delivery for that content is defined in the appropriate delivery protocol profile/specification document.

If by "unknown" you mean "does not recognise the property name" then I don't think the dCDN can do anything but reject request routing/delivery because it can not determine if the property that it doesn't recognise is a mandatory feature to be applied or not.

One caveat to the case of "does not recognise the property name" is if for a given delivery protocol, the property that is not recognised is not defined in the the associated profile/property specification for that Delivery Protocol, which could be considered a form of malformed response. In that case it would probably be reasonable to apply Postel's law and just ignore that property.

We're happy to try and add some text to the next revision that articulates the expected behaviour for malformed responses and the expected behaviour for properties defined in the metadata draft itself.

Ben

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 19 Oct 2011 08:17:57 -0700

On 18 Oct 2011, at 01:00, Ben Niven-Jenkins wrote:

> Neither. Although we don't say so explicitly in the draft our thinking was to model explicit CDNI Metadata invalidation/removal in the same manner as explicit invalidation/removal of actual content and have that performed via a request over the CDNI Control interface

That can work also. Regardless of the actual approach to do so, there seems to be agreement that we do need to be able to trigger "delete/purge" metadata. Good.
Thanks
Francois

> rather than having two separate approaches - one for CDNI metadata and a different one for the content itself.
> 
> Ben
> 

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619
Mobile: +33 6 19 98 50 90

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html