Subject: [CDNi] Spencer Dawkins' Yes on draft-ietf-cdni-metadata-18: (with COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 05 Jul 2016 18:51:14 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-cdni-metadata-18: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with Ben's Discuss, and several comments from Ben and other ADs,
but I'm balloting Yes, assuming those get sorted.

I did have a couple of questions, of course.

I'm a little bit mystified by this SHOULD:

   If any metadata not supported
   by the dCDN is marked as "mandatory-to-enforce", the dCDN SHOULD NOT
   accept the content redirection request, in order to avoid receiving
   content requests that it will not be able to satisfy/serve.
   
so, why _would_ a dCDN accept the content redirection request? If this
isn't a MUST, it would be nice to explain that - I'm reading this text as
"you SHOULD NOT do this unless you like getting unnecessary support
calls".

This next one is probably my lack of understanding about CDNI
implementations, but the document mentions the HTTP HEAD method exactly
twice:

   The HTTP Method in the request defines the operation the request
   would like to perform.  A server implementation of the CDNI metadata
   interface MUST support the HTTP GET and HEAD methods.
   
 and
 
   The CDNI metadata interface specified in this document is a read-only
   interface.  Therefore support for other HTTP methods such as PUT,
   POST, DELETE, etc. is not specified.  A server implementation of the
   CDNI metadata interface MUST reject all methods other than GET and
   HEAD.
   
The MUST support for GET, and the MUST reject for all methods other than
GET and HEAD, make perfect sense with your explanation, but I'm not sure
why support for HEAD is a MUST.
   
Is that just so a client can check the HTTP metadata for the CDNI
metadata without GETting it? Or is there more to it than that? I won't be
surprised if you say "no, nothing more to it than that" ... but if that's
the answer, it might be worth saying so.