Re: [CDNi] Early AD review of draft-ietf-cdni-metadata-17

Hi Alexey,

  inline:

> -----Original Message-----
> From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Alexey Melnikov
> Sent: Thursday, June 02, 2016 6:02 AM
> To: cdni@ietf.org
> Subject: [CDNi] Early AD review of draft-ietf-cdni-metadata-17
> 
> 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)?

Essentially, yes.  We had considered trying to define a way to pass certs and keys around, but in general it seemed like a bad idea.  A LURK-like solution would help.

> 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.

I actually just removed the references, since they seemed redundant.  The host property is of type "Endpoint" which is defined in 4.3.3.  I can add it back if you feel it's not readable as is.

> In 4.1.5: does "case insensitive" only applies to ASCII range? I.e.,
> encoded UTF-8 sequences in URIs are not affected.

I would expect this to apply to the percent encoded values, not the decoded values, i.e., I would expect "%4A" to be compared as "%4a" and not "j".  Is that what you mean?  

Ben, do you agree?

We can clarify that.

> In 4.2.6: URI needs a Normative Reference (RFC 3986).

Done.  I assume you mean wrt the ignore-query-string property description "URI query string parameters"?

> In 4.3.7: need a reference to a document/registry defining ASNs.

Added reference to RFC6793.

> In 6.1: need a reference to HTTP/1.1 spec.

Added a reference to RFC7230.

> Should OPTIONS method be allowed?

I'll defer to Ben on this one.

> 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?

This is similar to Triggers (https://tools.ietf.org/html/draft-ietf-cdni-control-triggers-15#section-4) in that it is assumes the CDNs would exchange that information out-of-band, or that some other bootstrap API would be defined.

wrt .well-known, the dCDN (in the case of metadata; the uCDN in the case of triggers) would still need to have a hostname configured?  There was some discussion a while back (https://mailarchive.ietf.org/arch/msg/cdni/9JUdlQk0fD4_0Lhm1lj7_U7QfcM) about using a "well-known" URI for retrieving bootstrap information for all interfaces, but it was not followed up.

> In 7.3: Nit: HTTP/1.1 over TLS needs 2 references, not just one.

The other reference being?
What if we just used 7230?
More generally, though, do you think we need to adjust the registry structure to have a list of Protocol Specs?

> 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)?

Sections 8.1-8.4 were intended to lead into 8.5
Changed the SHOULDs to MUSTs and added references to 8.5

thanx.

--  Kevin J. Ma

> 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.
> 
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni