Subject: Re: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 2]

From: Kevin J Ma <[email-masked]>
Date: Mon, 10 Mar 2014 16:59:39 -0400

Hi Francois,

  Thanks for the comments (looking forward to the rest); responses inline:

> -----Original Message-----
> From: CDNi [mailto:[email-masked]] On Behalf Of Francois Le
> Faucheur (flefauch)
> Sent: Friday, February 21, 2014 11:35 AM
> To: [email-masked]; [email-masked]
> Subject: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch
> 2]
> 
> 
> *** section 3.1: Table 2:
> "A PathMetadata object contains the CDNI GenericMetadata objects"
> Should this say "contains or references"?
> Same comment for "GenericMetadata"?
> Because of the inconsistencies in the description, I guess I am not 100%
> clear at this stage as to whether it is always possible to "either contain
> or reference", or whetehr there are some cases where it "always contains".
> Please make sure this is made clear.

Changed PathMetadata to include "or references".

wrt GenericMetadata, imo, the GenericMetadata object should be the minimum atomic
unit for the MI.  HostMetadata and PathMetadata objects reference GenericMetadata
objects, but the Generic Metadata object contains a full object, references to
which should've been made at a higher level (i.e., in the HostMetadata or 
PathMetadata object in which it is contained).  It may contain references to
member data, but not to another GenericMetadata object.  I have clarified the text.

> *** section 3.2:
> OLD:
> "
> If the
>    dCDN does not understand or support the property type and the
>    property type is not mandatory to enforce, then the GenericMetadata
>    object may be safely ignored.
> "
> NEW:
> "
> If the
>    dCDN does not understand or support the property type and the
>    property type is not mandatory to enforce, then the GenericMetadata
>    object may be safely ignored and the dCDN MUST process
>    the content request in accordance with the rest of the CDNI metadata.
> "

Done.
 
> *** section 3.2:
> "
> If the dCDN does not understand
>    or support the property type it is also not going to be able to
>    properly propagate the Metadata for cascaded distribution.
> "
> This sentence is placed in the middle of the 2nd paragraph while it
> discusses metadata redistribution which is not the subject of the 2nd
> paragraph and is fully discussed in the 3rd paragraph. So that sentence
> should be removed from 2nd paragraph and merged with 3rd paragraph (or
> removed altogether it it is redundant with 3rd paragraph).

Removed that sentance and added normative text for handling metadata which
is not safe to redistribute.

One question I have is:
  If the content is both "mandatory-to-enforce" and not "safe-to-redistribute",
  and the transit CDN doesn't understand/support it, then the transit CDN MUST
  instruct the downstream CDN to reject all requests for that content?

  We do not have a defined mechanism for this today.
  Should we define and return a well known auto-reject Metadata object?
  (An HTTP response code seems too heavy handed, e.g., if the dCDN just
   requested all metadata, and only 1 sub-path has a metadata issue.)

> *** section 3.2
> s/optimially/optimally/

Done.

> ***section 3.2:
> I would suggest capitalizing the two terms you define everywhere to make
> it clear that these are  very precise terms that you define here.
> "Mandatory To Enforce" (or "Mandatory-To-Enforce")
> "Safe To Redistribute" (or "Safe-To-Redistribute")
> another option coudl to quote the corresponding property names defined
> later ie "madatory-to-enforce"/"safe-to-redistribute".

Done.  Went with quotes and dashes ("madatory-to-enforce"/"safe-to-redistribute").

> *** section 3.3:
> OLD:
> "
>       the TimeWindowACL defined in the PathMetadata would override the
>       TimeWindowACL defined in the HostMetadata
> "
> NEW:
> "
>       the TimeWindowACL defined in the PathMetadata would override the
>       TimeWindowACL defined in the HostMetadata for
>       all User Agent requests for content under "example.com/movies"
> "

Done.

> *** section 3.3:
> "
> The PathMetadata defined TimeWindowACL would override the
>    TimeWindowACL defined in the HostMetadata for all User Agent requests
>    for movies.
> "
> This seems 100% redundant with the previous example. If this is correct,
> just remove. If this is not correct, clarify what extra information it
> brings.

Removed.

> *** section 3.4:
> "The type
>    SHOULD be descriptive, and MAY be hierarchical to support aggregating
>    groups of properties for the purpose of readability and for avoiding
>    name conflicts between vendor extensions.  A dotted alpha-numeric
>    notation is suggested for human readability."
> I think all the normative language about metadata types shoudl be moved to
> the relevant IANA sub-section  (unless we conclude differently in the
> thread about that question started in the context of cdni-logging). So I'd
> see all the quoted text above be merged into the appropriate IANA sub-
> section.

Moved and merged.

> *** section 3.4:
> " Metadata types defined by this document are not hierarchical."
> I suggest adding an explanation or example about what you mean by
> "hierarchical".

Removed.

--  Kevin J. Ma

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 11 Mar 2014 13:07:12 +0000

Hi Kevin,

Thanks for addressing the comments. 

>  instruct the downstream CDN to reject all requests for that content?

Right.

>   requested all metadata, and only 1 sub-path has a metadata issue.)

If the metadata object is both "mandatory-to-enforce" and not "safe-to-redistribute”, then how about we indicate that:
	*A* a transit CDN request routing function is expected to attempt to not redirect request for corresponding content further to downstream CDNs, and
	*B* a transit CDN CDNI metadata function MUST update the metadata to add a newly defined “do-not-serve” object that will instruct the dCDN (and we specify somewhere that any cDN that sees that object MUST not serve the content, regardles of what the other metadata says). We need to think about whetehr we want to leave the initial object that was "mandatory-to-enforce" and not "safe-to-redistribute” , or wehether it should be removed (on the grounds that it contains non-sensical information since it has not been properly “updated” by the transit CDN).

I am not sure if *B* is what you also meant. ie the word “return” confused me, since teh approach I describe above does not return anything new, but just adds something in the propagated metadata.

Makes sense?

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 11 Mar 2014 09:17:33 -0400

Hi Francois,

  "*B*" was precisely what I was thinking, replacing all of the existing
  metadata for the Hosts/Paths that had unsupported MtE and non-StR 
  metadata with a well known do-not-serve metadata object.  I will add
  that and some additional text for "*A*" unless someone objects?

thanx!

--  Kevin J. Ma

> From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
> Sent: Tuesday, March 11, 2014 9:07 AM
> To: Kevin J Ma
> Cc: Francois Le Faucheur (flefauch); draft-ietf-cdni-
> [email-masked]; [email-masked]
> Subject: Re: WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 2]
> 
> Hi Kevin,
> 
> If the metadata object is both "mandatory-to-enforce" and not "safe-to-
> redistribute", then how about we indicate that:
> 	*A* a transit CDN request routing function is expected to attempt to
> not redirect request for corresponding content further to downstream CDNs,
> and
> 	*B* a transit CDN CDNI metadata function MUST update the metadata to
> add a newly defined "do-not-serve" object that will instruct the dCDN (and
> we specify somewhere that any cDN that sees that object MUST not serve the
> content, regardles of what the other metadata says). We need to think
> about whetehr we want to leave the initial object that was "mandatory-to-
> enforce" and not "safe-to-redistribute" , or wehether it should be removed
> (on the grounds that it contains non-sensical information since it has not
> been properly "updated" by the transit CDN).
> 
> I am not sure if *B* is what you also meant. ie the word "return" confused
> me, since teh approach I describe above does not return anything new, but
> just adds something in the propagated metadata.
> 
> Makes sense?

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 11 Mar 2014 18:16:43 +0000

>  that and some additional text for "*A*" unless someone objects?

Sounds good.
Regarding the "do-not-serve metadata object”, it may have applicability completely independently of the "MtE and non-StR” situation, eg if an uCDN wants to explicitely tell dCDN to no longer serve some content on its behalf. So we want to define that object in its own right , and then simply specifiy it is to be used  in the "MtE and non-StR” situation ie we don;t want to have the "do-not-serve metadata object” definition tie to the "MtE and non-StR” situation.
I think that is exactly what you meant by "well known” but thought it was worth making that explicit to everyone.

Cheers

Francois

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 11 Mar 2014 14:18:24 -0400

> I think that is exactly what you meant by "well known" but thought it was
> worth making that explicit to everyone.

Good clarification.  Correct, that's what I meant by "well known".  thanx.

> Sent: Tuesday, March 11, 2014 2:17 PM
> To: Kevin J Ma
> Regarding the "do-not-serve metadata object", it may have applicability
> completely independently of the "MtE and non-StR" situation, eg if an uCDN
> wants to explicitely tell dCDN to no longer serve some content on its
> behalf. So we want to define that object in its own right , and then
> simply specifiy it is to be used  in the "MtE and non-StR" situation ie we
> don;t want to have the "do-not-serve metadata object" definition tie to
> the "MtE and non-StR" situation.
> I think that is exactly what you meant by "well known" but thought it was
> worth making that explicit to everyone.
> 
> Cheers
> 
> Francois
> 
> >
> > thanx!
> >
> > --  Kevin J. Ma
> >
> >>> and the transit CDN doesn't understand/support it, then the transit
> CDN
> >> MUST