[CDNi] Early AD review of draft-ietf-cdni-metadata-18

[Alexey Melnikov <[e-mail]>]

Thank you for addressing most of my concerns. Here is the updated list
of issues:

In 4.1.2: hostname need to have defined syntax (at least by reference).
You also need to say whether IDN domain names are
allowed here.

In 6.1:

   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.

I think the change to the MUST is too strong and is a wrong thing to do,
because that means that existing HTTP/1.1 software might have to be
modified to
support this specification.

So I would prefer that you either delete the last sentence or reword to
say
"doesn't have to support any methods other that ..."

In 8.3:

   An implementation of the CDNI metadata interface MUST use strong
   encryption and mutual authentication to prevent undetectable

Encryption doesn't necessarily provide integrity of data, so I would
change "strong encryption" to TLS.

   modification of metadata (see Section 8.5).


On Thu, Jun 2, 2016, at 11:02 AM, Alexey Melnikov wrote:
> In order to speed up publication of this draft, I decided to do early AD
> review. Here are my comments. My apologies if they are a bit cryptic, if
> you are unsure of what I meant, please ask!
> 
> In 1.2: content can only be delivered using HTTP/1.1 and not HTTP/1.1
> over TLS? Is last para saying that this is an unsolved problem (e.g.
> LURK BOF solution is needed)?
> 
> In 4.1.2: hostname and IP addresses need to have defined syntaxes (at
> least by reference). You also need to say whether IDN domain names are
> allowed here.
> 
> In 4.1.5: does "case insensitive" only applies to ASCII range? I.e.,
> encoded UTF-8 sequences in URIs are not affected.
> 
> In 4.2.6: URI needs a Normative Reference (RFC 3986).
> 
> In 4.3.7: need a reference to a document/registry defining ASNs.
> 
> In 6.1: need a reference to HTTP/1.1 spec.
> 
> Should OPTIONS method be allowed?
> 
> In 6.2/6.3: Is discovery of the initial URI truly out of scope? You can
> define a .well-known URI to allow bootstrapping.
> If it is defined, is it likely to be used?
> 
> In 7.3: Nit: HTTP/1.1 over TLS needs 2 references, not just one.
> 
> In 7.4: I think I am sad that you haven't defined any initial
> authentication mechanism. Has this been discussed in the WG?
> 
> In 8.1, last para: a requirement to implement mutual authentication is
> underspecified. Do you mean TLS mutual authentication? If yes, say so.
> If other mechanisms can be used, say so as well.
> If you meant to reference 8.5 here, please do so.
> 
> Why is this only a SHOULD (and not a MUST)?
> 
> In 8.2: similarly, how can the SHOULD be satisfied? Do you mean TLS or
> something else? Reference 8.5?
> 
> In 8.3: similar issue.
> 
> Also encryption doesn't necessarily provide integrity of data, so the
> last sentence sounds wrong.
> 
> In 8.4: similar issue.