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

[Kevin Ma J <[e-mail]>]

Hi Alexey,

> > Should OPTIONS method be allowed?

The authors conferred and decided that only GET and HEAD are allowed; we have updated the draft accordingly.

thanx!

--  Kevin J. Ma

> -----Original Message-----
> From: Alexey Melnikov [mailto:[e-mail]]
> Sent: Friday, June 03, 2016 7:59 AM
> To: Kevin Ma J; [e-mail]
> Subject: Re: [CDNi] Early AD review of draft-ietf-cdni-metadata-17
> 
> 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.