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

Hi Alexey,

  We will address and upload a new diff.

thanx!

--  Kevin J. Ma

> -----Original Message-----
> From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Alexey Melnikov
> Sent: Monday, June 13, 2016 8:53 AM
> To: cdni@ietf.org
> Subject: [CDNi] Early AD review of draft-ietf-cdni-metadata-18
> 
> 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.
> 
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni