[CDNi] Stephen Farrell's No Objection on draft-ietf-cdni-metadata-19: (with COMMENT)

["Stephen Farrell" <[e-mail]>]

Stephen Farrell has entered the following ballot position for
draft-ietf-cdni-metadata-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


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.