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

[Alexey Melnikov <[e-mail]>]

Hi Kevin,

On Thu, Jun 2, 2016, at 08:51 PM, Kevin Ma J wrote:
> Hi Alexey,
> 
>   inline:
> 
> > -----Original Message-----
> > From: CDNi [mailto:[e-mail]] On Behalf Of Alexey Melnikov
> > Sent: Thursday, June 02, 2016 6:02 AM
> > To: [e-mail]
> > 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.

Ok.

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

I would rather you do. I like references :-).

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

Yes.

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

Ok, I will read this.

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

+ RFC 2818.

> More generally, though, do you think we need to adjust the registry
> structure to have a list of Protocol Specs?

I am not sure what you mean. The current table looks fine to me (other
than missing references).

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

Much better!

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