Content Delivery Network Interconnection (CDNI) Metadata
draft-ietf-cdni-metadata-21

- Sec 4.2.2.1: It seems odd to me that deny is the default given that footprints are mandatory to specify. It seems like if footprints are going to be specified, the more common case would be to specify footprints where access is allowed, rather than where access is not allowed.

- Sec 6.3: "the HostIndex URI could be discovered" seems like conjecture unless some discovery mechanism has been specified somewhere. I would suggest either citing an existing discovery mechanism or not saying this.

- Sec 6.7: It seems like saying that CSPs and CDNs should avoid metadata conflict isn't quite enough. If a dCDN encounters conflicting metadata, what is it supposed to do? I think some sort of error condition would be useful to specify.

- I support Stephen's DISCUSS.

The authors have proposed text to address my discuss comments (Thanks!), so I am clearing it on the assumption that people will do the right thing.  (See the document history for reference if needed.)

Substantive Comments:

- 4.1, example (applies to all examples of referenced objects): Given the rather strong guidance to use TLS to move metadata around, shouldn't the examples that show referenced objects use HTTPS URLs?

- 4.1.3, "paths" property: Am I correct to assume that _only_ the first match is used?

- 7.4: If the Auth type registry is initially unpopulated, doesn't that make the Auth property useless for the time being? Why even specify it now?

- 8.1, 2nd bullet: Could this sort of attack be used to distribute compromised content (e.g. malware) to  end users?

- 8.3: Couldn't lack of integrity protection enable theft-of-content, in addition to DoS? For example, if a MiTM changes the ACLs for a piece of content?

- 11.1, reference to 6706: This is another normative downref that does not appear to have been called out in the IETF last call announcement. I will leave it to the authors and AD to decide if that's okay.

Editorial Comments and Nits:

- General: I don't expect action on this in general, but this draft seems to have a lot of repeated material, which makes it considerably longer and harder to digest than necessary for the content. (Note that, for _normative_ text, such redundancy makes future updates error prone, even if the text is consistent now.)

- 3, first paragraph: I’m not sure what you mean by “aggregated” in this context.

- 3.2, third paragraph, last sentence: The MUST seems unneeded. Please consider simply saying " ... the dCDN processes the content request in accordance with the rest of the metadata.

- 4, paragraph 5: The MUST seems unneeded. There's no choice to make here;  this is simply the way CDNI metadata objects are encoded. (Recurs in 6.4, which seems redundant to this section.)

- 4.1.2, "Note" in definition of Host property: I usually think of "Note" to designate parenthetical or "sidebar" content. Please consider dropping the "Note" prefix for text that contains 2119 keywords. (There are multiple occurrences throughout.) 

- 7.1.x Do you expect IANA to do something with these subsections? I don’t see this sort of detail in the IANA registry. Otherwise, they seems to belong in the main body, not the IANA considerations.

My review flagged the same DISCUSS point 1 as Ben: the downref (The writeup mentions the two downrefs though).

Secondly, the writeup, https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata/shepherdwriteup/, is not really readable.

And finally, Sheng Jiang's OPS DIR review flagged: 
The example of footprint object has examples using IPv4. Because the other parts of this document does have IPv6 example, I think this is probably a mistake rather than not supporting IPv6 here on purpose (if it is on purpose, an explanation for reasons are necessary).

I can see why unauthorized access to content isn't a concern since this draft is just about the metadata, but wouldn't billing/theft be a possible avenue of attack to be listed as a consideration through alterations of the metadata?

Two comments:

1) It's still not really clear to me why the use of HTTPS is not mandatory... maybe that's related to my second comment below...?

2) I'm a little confused with the use of the term 'caching'. Maybe I'm assuming a wrong scenario, but to my understanding a dCDN would request metadata from an uCDN and simply store them. Or would the dCDN re-distribute the metadata it got from the uCDN to other dCDNs?

Thanks for the discussion. Old comments below, I didn't
check if those were handled. If they were, thanks. If you
want to chat about any, feel free to but you don't need to.

------------

- general: I agree with Ben's discuss about use of TLS. I
also wonder if IPsec is really going to be used here. And
even if so, you might be better off to say that TLS with
mutual-auth SHOULD be used in all cases.

- general: Don't you need some guidance for the dCDN to say
when to stop following (what might be circular) links?

- general: I think it'd be better if the examples given used
https in all cases, assuming we do think that'd be better.
And if it'd not be better, saying why would I think be good.

- 1.2, last para: I don't get what this is saying. What
additional things need specifying? If all you mean is that
the dCDN and uCDN need to be able to setup TLS sessions, and
hence need to agree on what CAs and ciphersuites to use,
then maybe just say that. (You do already refer to RFC7525
so most of that is covered there I think.)

- 4.1.1: I don't think I-JSON requires that order be
preserved, but you seem to need that here, e.g. if a tCDN
decodes and re-encodes, or if a uCDN round-trips a data
structure. Is there a missing "MUST preserve order"
somewhere?

- 4.1.x, 4.2.x, 4.3.x: I wonder if the specification is a
bit too loose in places here, e.g. what does "$$" mean in
4.1.5 and why is that special?  In the same section I also
wasn't clear if "/movies/" is the same as "/movies/*" or
not, nor if you consider that "/movies/*" does or doesn't
match "/movies/1/2/3". Isn't a reference needed in 4.3.4?
I'd guess that a lot of this is close enough that
implementations will likely get a lot, but not all, of this
right, and that that might lead to corner-cases where
interop isn't so good.  Improving that would seem like a
good idea, but perhaps it's better to wait and see what
deployments do and then tidy this up? Not sure.  In reading
I spotted a number of places where such things occurred to
me (but didn't write them all down, sorry;-). 

- 6.8: I didn't follow this, sorry;-) I assume it's
considered clear enough for implementers, so feel free to
ignore me, but I didn't get how to know whether or not e.g.
".v2.2.2" is newer than ".v2" or ".fixed-v1".

- 8.3: did the WG consider (possibly future) uses of JOSE to
provide e2e security from uCDN to dCDN even via tCDN? I'm ok
that you don't define that now, but wondered, as it seems
like a fairly obvious thing to want. (To this security nerd
anyway:-) I also wondered the same for 8.4, but I get that
that'd be less likely of widespread utility. If using IPsec
to security inter-CDN links, something like JOSE would seem
to me to add quite a bit of value, if the CDNs insist on not
using TLS.