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

From: Alexey Melnikov <[email-masked]>
Date: Thu, 02 Jun 2016 11:02:14 +0100

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.

---

From: Kevin Ma J <[email-masked]>
Date: Thu, 2 Jun 2016 13:49:58 +0000

HI Alexey, 

  (As and author) Thanks for the review.  We will review and respond shortly.

thanx!

--  Kevin J. Ma

> -----Original Message-----
> From: CDNi [mailto:[email-masked]] On Behalf Of Alexey Melnikov
> Sent: Thursday, June 02, 2016 6:02 AM
> To: [email-masked]
> Subject: [CDNi] Early AD review of draft-ietf-cdni-metadata-17
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: Kevin Ma J <[email-masked]>
Date: Thu, 2 Jun 2016 14:15:35 +0000

> > authentication mechanism. Has this been discussed in the WG?

The thought behind this was that URI Signing would be the primary delivery auth mechanism, and could also be used for acquisition auth; but thank you for reminding me that I missed the Auth Type registration in https://tools.ietf.org/html/draft-ietf-cdni-uri-signing-07#section-8.  :)

We originally considered including an auth object for HTTP basic auth, just to have something, but it's already inherently supported in the URL [RFC3986], and it felt better to just wait for URI Signing (which should follow quickly after) [https://mailarchive.ietf.org/arch/msg/cdni/FygOsoddUfcqD2PmVXpC_XJIasM].

thanx.

--  Kevin J. Ma

> From: Kevin Ma J
> Sent: Thursday, June 02, 2016 9:51 AM
> To: 'Alexey Melnikov'; [email-masked]
> Subject: RE: [CDNi] Early AD review of draft-ietf-cdni-metadata-17
> 
> HI Alexey,
>

---

From: Kevin Ma J <[email-masked]>
Date: Thu, 2 Jun 2016 19:51:52 +0000

Hi Alexey,

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

> least by reference). You also need to say whether IDN domain names are

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.

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

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

> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 03 Jun 2016 12:59:25 +0100

Hi Kevin,

On Thu, Jun 2, 2016, at 08:51 PM, Kevin Ma J wrote:
> 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.

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

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

Yes.

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

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

> Changed the SHOULDs to MUSTs and added references to 8.5

Much better!

---

From: Kevin Ma J <[email-masked]>
Date: Sat, 11 Jun 2016 19:15:52 +0000

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

> From: Alexey Melnikov [mailto:[email-masked]]
> Sent: Friday, June 03, 2016 7:59 AM
> To: Kevin Ma J; [email-masked]
> Subject: Re: [CDNi] Early AD review of draft-ietf-cdni-metadata-17
> 
> Hi Kevin,
> 
> > Done.  I assume you mean wrt the ignore-query-string property
> description
> > "URI query string parameters"?
> 
> Yes.
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 12 Jun 2016 22:13:10 +0100

Alexey, Kevin,

I’m coming to the party a bit late (unfortunately I have very little time for IETF work these days). This caught my eye and I wanted to comment on it.

> On 2 Jun 2016, at 15:15, Kevin Ma J <[email-masked]> wrote:
> 
> wrt:

URL signing provides authorisation, not authentication.

At the time my opinion/thinking (and it hasn’t changed since) was:

- The vast majority of HTTP content is delivered without authentication.
- Defining authentication is hard - by which I mean the auth itself is not hard, specifying a secure way to distribute secrets etc is hard, as illustrated by the need for a LURK WG for doing something similar for related but not identical use cases to CDNI.
- I was worried trying to define a secure way to distribute auth secrets etc would delay the work unnecessarily both in terms of time spent in the WG and time spent getting whatever mechanism we defined past the IESG.

Authenticating the channel over which the CDNI metadata is distributed (as opposed to authenticating the User Agent/user requesting the content from the dCDN) is already specified/mandated in the document IIRC.

Ben

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 13 Jun 2016 13:52:56 +0100

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

---

From: Kevin Ma J <[email-masked]>
Date: Mon, 13 Jun 2016 21:01:05 +0000

Hi Alexey,

  We will address and upload a new diff.

thanx!

--  Kevin J. Ma

> Sent: Monday, June 13, 2016 8:53 AM
> To: [email-masked]
> Subject: [CDNi] Early AD review of draft-ietf-cdni-metadata-18
>

---

From: Kevin Ma J <[email-masked]>
Date: Mon, 13 Jun 2016 21:01:34 +0000

s/diff/draft

> Sent: Monday, June 13, 2016 5:03 PM
> Subject: RE: [CDNi] Early AD review of draft-ietf-cdni-metadata-18
> 
> Hi Alexey,
>