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

[Ballot discuss]
RFC 3490 is an obsoleted RFC, need to reference the latest IDNA RFC.

-- You updated description in the document to read (in 2 places):

Internationalized Domain Names (IDN) must first be
transformed to the IDNA encoding as per [RFC5891].

However this is not clear enough, because you are not saying whether you want to use A-labels or U-labels. I suggest:

in 4.1.2, change:

        Internationalized Domain
        Names (IDN) must first be transformed to the IDNA encoding as
        per [RFC5891].

to:

        Internationalized Domain
        Names (IDN) must first be transformed to the A-label form as
        per [RFC5891].

You can also add "[RFC5890]" to the end of the sentence (and add it to Normative References), as it defines A-labels.


Similarly, in 4.3.3, change:

  Internationalized Domain Names (IDN) must first be
  transformed to the IDNA encoding as per [RFC5891].

to:

  Internationalized Domain Names (IDN) must first be
  transformed to the A-label form as per [RFC5891].

[Ballot discuss]
RFC 3490 is an obsoleted RFC, need to reference the latest IDNA RFC.

-- You updated description in the document to read (in 2 places):

Internationalized Domain Names (IDN) must first be
transformed to the IDNA encoding as per [RFC5891].

However this is not clear enough, because you are not saying whether you want to use A-labels or U-labels. I think the former.


IANA Auth type registry no longer created? Has this been moved to another draft?


Issues from my earlier review (these might be already fixed):

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

[Ballot discuss]
RFC 3490 is an obsoleted RFC, need to reference the latest IDNA RFC.

-- You updated description in the document to read (in 2 places):

Internationalized Domain Names (IDN) must first be
transformed to the IDNA encoding as per [RFC5891].

However this is not clear enough, because you are not saying whether you want to use A-labels or U-labels. I think the former.


IANA Auth type registry no longer created? Has this been moved to another draft?


Issues from my earlier review (these might be already fixed):

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

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-cdni-metadata-19. If any part of this review is inaccurate, please let us know.

IANA understands that there are three actions that are required to be completed upon approval of this document.

First, in the CDNI Payload Types registry under the Content Delivery Network Interconnection (CDNI) Parameters heading at

https://www.iana.org/assignments/cdni-parameters/

twenty (20) new payload types are to be registered as follows:

+--------------------------+---------------+
| Payload Type | Specification |
+--------------------------+---------------+
| MI.HostIndex | [ RFC-to-be ] |
| MI.HostMatch | [ RFC-to-be ] |
| MI.HostMetadata | [ RFC-to-be ] |
| MI.PathMatch | [ RFC-to-be ] |
| MI.PatternMatch | [ RFC-to-be ] |
| MI.PathMetadata | [ RFC-to-be ] |
| MI.SourceMetadata | [ RFC-to-be ] |
| MI.Source | [ RFC-to-be ] |
| MI.LocationACL | [ RFC-to-be ] |
| MI.LocationRule | [ RFC-to-be ] |
| MI.Footprint | [ RFC-to-be ] |
| MI.TimeWindowACL | [ RFC-to-be ] |
| MI.TimeWindowRule | [ RFC-to-be ] |
| MI.TimeWindow | [ RFC-to-be ] |
| MI.ProtocolACL | [ RFC-to-be ] |
| MI.ProtocolRule | [ RFC-to-be ] |
| MI.DeliveryAuthorization | [ RFC-to-be ] |
| MI.Cache | [ RFC-to-be ] |
| MI.Auth | [ RFC-to-be ] |
| MI.Grouping | [ RFC-to-be ] |
+--------------------------+---------------+

As this document requests registrations in a Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, a new registry is to be created called the CDNI Metadata Footprint Types registry. This registry will be located in the existing Content Delivery Network Interconnection (CDNI) Parameters registry located at:

https://www.iana.org/assignments/cdni-parameters/

The new registry will be managed through Specification Required as defined by RFC 5226. These are the initial registrations:

+----------------+-------------------------------+---------------+
| Footprint Type | Description | Specification |
+----------------+-------------------------------+---------------+
| ipv4cidr | IPv4 CIDR address block | [ RFC-to-be ] |
| ipv6cidr | IPv6 CIDR address block | [ RFC-to-be ] |
| asn | Autonomous System (AS) Number | [ RFC-to-be ] |
| countrycode | ISO 3166-1 alpha-2 code | [ RFC-to-be ] |
+----------------+-------------------------------+---------------+

Third, a new registry is to be created called the CDNI Metadata Protocol Types registry. This registry will also be located in the existing Content Delivery Network Interconnection (CDNI) Parameters registry located at:

https://www.iana.org/assignments/cdni-parameters/

The new registry will be managed through Specification Required as defined by RFC 5226. These are the initial registrations:

+-----------+----------------------+---------------+----------------+
| Protocol | Description | Type | Protocol |
| Type | | Specification | Specifications |
+-----------+----------------------+---------------+----------------+
| http/1.1 | Hypertext Transfer | [ RFC-to-be ] | RFC7230 |
| | Protocol -- HTTP/1.1 | | |
| https/1.1 | HTTP/1.1 Over TLS | [ RFC-to-be ] | RFC7230, |
| | | | RFC2818 |
+-----------+----------------------+---------------+----------------+

IANA understands that these three actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Thank you,

Amanda Baber
IANA Lead Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: alexey.melnikov@isode.com, flefauch@cisco.com, cdni@ietf.org, draft-ietf-cdni-metadata@ietf.org, cdni-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (CDN Interconnection Metadata) to Proposed Standard


The IESG has received a request from the Content Delivery Networks
Interconnection WG (cdni) to consider the following document:
- 'CDN Interconnection Metadata'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-07-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

This is the Second IETF Last Call to point out that the document has a DownRef to RFC 6707.

Abstract


  The Content Delivery Networks Interconnection (CDNI) metadata
  interface enables interconnected Content Delivery Networks (CDNs) to
  exchange content distribution metadata in order to enable content
  acquisition and delivery.  The CDNI metadata associated with a piece
  of content provides a downstream CDN with sufficient information for
  the downstream CDN to service content requests on behalf of an
  upstream CDN.  This document describes both a base set of CDNI
  metadata and the protocol for exchanging that metadata.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata/ballot/


No IPR declarations have been submitted directly on this I-D.

[Ballot discuss]
IANA Auth type registry no longer created? Has this been moved to another draft?

RFC 3490 is an obsoleted RFC, need to reference the latest IDNA RFC.

Some outstanding issues in 6.8 (Versionning)

Check remaining AD review comments reported earlier.

In regards to Spencer's comment:

  A server implementation of the
  CDNI metadata interface MUST reject all methods other than GET and
  HEAD.

I think this text needs to be deleted, because it puts extra requirements on generic HTTP servers that might be used to serve CDNI Metadata, which I think is a wrong thing to do.

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

[Ballot discuss]

(1) cleared, was just a document split issue

(2) 6.5: I think you're missing a MUST in the list here.
I'd suggest something like: "5. Describe the security and
privacy (for the person/user-agent, not only xCDN)
consequences of the extension." I'm assuming that we agree
that it'd be a bad idea if e.g. some extension were defined
that allowed a uCDN tell a dCDN to try to track and report
on all of a user's activities. (Or at least, that'd need to
be documented/justified.)

[Ballot discuss]
I will need to re-Last Call the document due to 2 DownRefs:

RFC 5861 (HTTP Cache-Control Extensions for Stale Content).
RFC6707 (terminology).


In regards to Spencer's comment:

  A server implementation of the
  CDNI metadata interface MUST reject all methods other than GET and
  HEAD.

I think this text needs to be deleted, because it puts extra requirements on generic HTTP servers that might be used to serve CDNI Metadata, which I think is a wrong thing to do.

[Ballot comment]
I will need to re-Last Call the document due to 2 DownRefs:

RFC 5861 (HTTP Cache-Control Extensions for Stale Content).
RFC6707 (terminology).


In regards to Spencer's comment:

  A server implementation of the
  CDNI metadata interface MUST reject all methods other than GET and
  HEAD.

I think this text needs to be deleted, because it puts extra requirements on generic HTTP servers that might be used to serve CDNI Metadata, which I think is a wrong thing to do.

[Ballot comment]
- 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.

[Ballot comment]
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.

1. Summary
 
The document shepherd is Francois Le Faucheur. The responsible AD is Alexey Melnikov. The requested RFC status is Standards Track.
 
This document defines a protocol by which a downstream CDN (dCDN) may query an upstream CDN (uCDN), in a CDN Interconnection (CDNI), to retrieve metadata related to a specific content asset being delivered by the dCDN, on behalf of the uCDN.  The metadata provides basic content delivery information, e.g., how to acquire the content asset, as well as optional content delivery policy information, e.g., geographic, time, and delegation restrictions.  The WG believes that a standardized method/protocol for organizing and conveying metadata from a uCDN to a dCDN is needed and will be useful.
 
2. Review and Consensus
 
The protocol is a straightforward RESTful API with JSON payloads.

The metadata is organized hierarchically, starting with the host and further differentiated by URI path of the content.  There was a lot of discussion early on as to whether a generic metadata interface was feasible or needed; there was concern that the complexity of designing a generic metadata interface would be prohibitive.

Much effort was put into defining how the metadata should be organized, so as to allow inheritance and override within the hierarchy, as well as metadata object reuse between hierarchies. There was broad discussion in the WG on this topic.  There were requirements for being able to exchange core pieces of metadata (e.g., how to acquire content), but there was also a desire to create an extensible protocol.  Multiple drafts were submitted and merged to arrive at the final design.  In addition to the extensible structure of the metadata, much discussion and effort was put into making sure that transit CDNs, which may or may not understand how to enforce the metadata, are able to safely redistribute the metadata or are able to recognize when redistribution of the metadata may violate content delivery policies.
 
The focus of the document is on providing metadata for delivering content via HTTP.  While the same metadata can be used to deliver content via HTTPS, there is no metadata defined for conveying metadata specific to setting up TLS connections between the dCDN and the end user.  It was discussed within the WG, but a secure solution was not deemed within the expertise of the WG.  Other solutions (e.g., LURK) could be used to address the TLS connection setup problem, and a CDNI metadata extension could be added once such a solution is available.
 
The metadata interface provides the same TLS guidelines as the CDNI logging, redirection, and control triggers interfaces.  There has been much discussion on privacy, with respect to CDNI logging and redirection and this has been considered for the CDNI metadata interface.  It should be noted that the metadata interface provides information about the uCDN and CSP policies to the dCDN. Though the metadata may contain private information, none of the information is third party end user information.
 
An early chair review was performed by Francois Le Faucheur, raising many editorial issues and requesting clarification on path matching, metadata override, and policy enforcement in cascaded CDN scenarios; all comments were addressed.  A subsequent independent review was performed by Vijay Gurbani, raising editorial comments, ambiguities, and requests for more details and more examples; all comments were addressed.  A final chair review was provided by Francois Le Faucheur, raising editorial and consistency issues; all comments were addressed.  Two additional independent reviews were performed by Linda Dunbar and Jan Seedorf, raising editorial comments which were all addressed.  An AppsDir early review was performed by Matt Miller, raising JSON issues, the need for more examples, and editorial issues; all comments were addressed. An early AD review was conducted by Alex Melnikov, raising a number of comments around security, proper use of RFC2119 terminology, references and autodiscovery; most comments have been addressed and the remaining ones have been discussed and are to be addressed in an upcoming version.
 
3. Intellectual Property
 
Each author has confirmed conformance with BCP 78/79.

There were no IPR disclosure made against this document.
 
4. Other Points
 
There is a downward reference for RFC5861, which is not in the DownrefRegistry.
 
There is a downward reference for RFC6707, which is not (yet) in the DownrefRegistry. RFC6707 is identified as a Normative Reference because its terminology is reused in this document.
 
The IANA Considerations registers 20 new CDNI Payload Types, one for each of the GenericMetadata objects defined in the document. Both of the designated expert reviewers for the CDNI Payload Types registry are authors of this document and have approved the additions.
 
The IANA Considerations creates a new "CDNI Metadata Footprint Types" registry with sufficient guidelines provided to both IANA and the designated expert reviewer.  The registry defines footprint types used by both the Metadata LocationACL, as well as the footprints defined in the Footprint and Capabilities Semantics document (already approved by the IESG).
 
The IANA Considerations creates a new "CDNI Metadata Protocols" registry with sufficient guidelines provided to both IANA and the designated expert reviewer.  The registry defines delivery and acquisition protocols used by both the Metadata ProtocolACL, as well as the DeliveryProtocol and AcquisitionProtocol capabilities defined in the Footprint and Capabilities Semantics document (already approved by the IESG).
 
The IANA Considerations creates a new "CDNI Metadata Auth Types" registry with sufficient guidelines provided to both IANA and the designated expert reviewer.  The registry is initially empty.  The initial Auth type is being defined in the URI Signing document which is preparing for WGLC.

[Ballot comment]
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).

[Ballot discuss]

(1) I don't get the model for telling a dCDN that the user
agent has to have authenticated or that some authorization
is needed before content is to be delivered. Can you
explain?  For example, neither 4.2.5 nor 4.2.7 tell me how
to do anything but allow open-access, and the relevant IANA
registry (section 7.4) is empty, so I'm puzzled.

(2) 6.5: I think you're missing a MUST in the list here.
I'd suggest something like: "5. Describe the security and
privacy (for the person/user-agent, not only xCDN)
consequences of the extension." I'm assuming that we agree
that it'd be a bad idea if e.g. some extension were defined
that allowed a uCDN tell a dCDN to try to track and report
on all of a user's activities. (Or at least, that'd need to
be documented/justified.)

[Ballot comment]

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

[Ballot comment]
I agree with Ben's Discuss, and several comments from Ben and other ADs, but I'm balloting Yes, assuming those get sorted.

I did have a couple of questions, of course.

I'm a little bit mystified by this SHOULD:

  If any metadata not supported
  by the dCDN is marked as "mandatory-to-enforce", the dCDN SHOULD NOT
  accept the content redirection request, in order to avoid receiving
  content requests that it will not be able to satisfy/serve.
 
so, why _would_ a dCDN accept the content redirection request? If this isn't a MUST, it would be nice to explain that - I'm reading this text as "you SHOULD NOT do this unless you like getting unnecessary support calls".

This next one is probably my lack of understanding about CDNI implementations, but the document mentions the HTTP HEAD method exactly twice:

  The HTTP Method in the request defines the operation the request
  would like to perform.  A server implementation of the CDNI metadata
  interface MUST support the HTTP GET and HEAD methods.
 
and

  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.
 
The MUST support for GET, and the MUST reject for all methods other than GET and HEAD, make perfect sense with your explanation, but I'm not sure why support for HEAD is a MUST.
 
Is that just so a client can check the HTTP metadata for the CDNI metadata without GETting it? Or is there more to it than that? I won't be surprised if you say "no, nothing more to it than that" ... but if that's the answer, it might be worth saying so.

[Ballot discuss]
I have two concerns that I would like to see discussed prior to publication:

1) Section 6.2 cites a normative reference to RFC 5861. That's an ISE stream informational RFC. The text as written seems to normatively require implementation of that RFC to enable the "caching" feature. Did the working group discuss the implications of that? (I also note that this doesn't appear to have been called out at IETF last call. While there has been some discussion about relaxing that requirement, I'm not sure this is an appropriate place to do so.)

2) Section 8.5 contains the "In an environment where any such protection is required" language that has been discussed for several CDNI drafts. But in this particular case, the implication that there may be environments where such protection is _not_ required seems to conflict with the multiple occurrences of "MUST use strong encryption/mutual authentication" in sections 8.1-8.4.

[Ballot comment]
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.

[Ballot comment]
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?

[Ballot comment]
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?

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-cdni-metadata-18.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are four actions which much be completed.

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

First, in the CDNI Payload Types subregistry of the Content Delivery Network Interconnection (CDNI) Parameters registry located at:

http://www.iana.org/assignments/cdni-parameters/

twenty new payload types are to be registered as follows:

+--------------------------+---------------------+
| Payload Type | Specification |
+--------------------------+---------------------+
| MI.HostIndex | [ RFC-to-be ] |
| MI.HostMatch | [ RFC-to-be ] |
| MI.HostMetadata | [ RFC-to-be ] |
| MI.PathMatch | [ RFC-to-be ] |
| MI.PatternMatch | [ RFC-to-be ] |
| MI.PathMetadata | [ RFC-to-be ] |
| MI.SourceMetadata | [ RFC-to-be ] |
| MI.Source | [ RFC-to-be ] |
| MI.LocationACL | [ RFC-to-be ] |
| MI.LocationRule | [ RFC-to-be ] |
| MI.Footprint | [ RFC-to-be ] |
| MI.TimeWindowACL | [ RFC-to-be ] |
| MI.TimeWindowRule | [ RFC-to-be ] |
| MI.TimeWindow | [ RFC-to-be ] |
| MI.ProtocolACL | [ RFC-to-be ] |
| MI.ProtocolRule | [ RFC-to-be ] |
| MI.DeliveryAuthorization | [ RFC-to-be ] |
| MI.Cache | [ RFC-to-be ] |
| MI.Auth | [ RFC-to-be ] |
| MI.Grouping | [ RFC-to-be ] |
+--------------------------+---------------------+

Second, a new subregistry is to be created called the CDNI Metadata Footprint Types registry. The new registry will be a subregistry of the Content Delivery Network Interconnection (CDNI) Parameters registry located at:

http://www.iana.org/assignments/cdni-parameters/

The registration rules for the new registry are "Specification Required" as defined by RFC 5226. There are initial registrations in the new registry as follows:

+----------------+-------------------------------+---------------------+
| Footprint Type | Description | Specification |
+----------------+-------------------------------+---------------------+
| ipv4cidr | IPv4 CIDR address block | [ RFC-to-be ] |
| ipv6cidr | IPv6 CIDR address block | [ RFC-to-be ] |
| asn | Autonomous System (AS) Number | [ RFC-to-be ] |
| countrycode | ISO 3166-1 alpha-2 code | [ RFC-to-be ] |
+----------------+-------------------------------+---------------------+

Third, a new subregistry is to be created called the CDNI Metadata Protocol Types registry. The new registry will be a subregistry of the Content Delivery Network Interconnection (CDNI) Parameters registry located at:

http://www.iana.org/assignments/cdni-parameters/

The registration rules for the new registry are "Specification Required" as defined by RFC 5226. There are initial registrations in the new registry as follows:

+-----------+----------------------+---------------------+----------------+
| Protocol | Description | Type | Protocol |
| Type | | Specification | Specifications |
+-----------+----------------------+---------------------+----------------+
| http/1.1 | Hypertext Transfer | [ RFC-to-be ] | RFC7230 |
| | Protocol -- HTTP/1.1 | | |
| https/1.1 | HTTP/1.1 Over TLS | [ RFC-to-be ] | RFC7230, |
| | | | RFC2818 |
+-----------+----------------------+---------------------+----------------+

Fourth, a new subregistry is to be created called the CDNI Metadata Auth Types registry. The new registry will be a subregistry of the Content Delivery Network Interconnection (CDNI) Parameters registry located at:

http://www.iana.org/assignments/cdni-parameters/

The registration rules for the new registry are "Specification Required" as defined by RFC 5226. There are no initial registrations in the new registry.

IANA understands that, upon approval of this document, these are the only actions that need to be completed by IANA.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

{\rtf1\ansi\ansicpg1252\cocoartf1404\cocoasubrtf470
{\fonttbl\f0\fmodern\fcharset0 CourierNewPSMT;\f1\froman\fcharset0 TimesNewRomanPSMT;}
{\colortbl;\red255\green255\blue255;}
\paperw11900\paperh16840\margl1440\margr1440\vieww34140\viewh25560\viewkind0
\deftab720
\pard\pardeftab720\partightenfactor0

\f0\fs36 \cf0 \expnd0\expndtw0\kerning0
1. Summary
\f1 \

\f0 \'a0
\f1 \

\f0 The document shepherd is Francois Le Faucheur.\'a0The responsible AD is Alexey Melnikov. The requested RFC status is Standards Track.
\f1 \

\f0 \'a0
\f1 \

\f0 This document defines a protocol by which a downstream CDN (dCDN) may query an upstream CDN (uCDN), in a CDN Interconnection (CDNI), to retrieve metadata related to a specific content asset being delivered by the dCDN, on behalf of the uCDN.\'a0 The metadata provides basic content delivery information, e.g., how to acquire the content asset, as well as optional content delivery policy information, e.g., geographic, time, and delegation restrictions.\'a0 The WG believes that a standardized method/protocol for organizing and conveying metadata from a uCDN to a dCDN is needed and will be useful.
\f1 \

\f0 \'a0
\f1 \

\f0 2. Review and Consensus
\f1 \

\f0 \'a0
\f1 \

\f0 The protocol is a straightforward RESTful API with JSON payloads.
\f1 \

\f0 \
The metadata is organized hierarchically, starting with the host
\f1 
\f0 and further differentiated by URI path of the content.\'a0 There was a lot of discussion early on as to whether a generic metadata interface was feasible or needed; there was concern that the complexity of designing a generic metadata interface would be prohibitive. \
\
Much effort was put into defining how the metadata should be
\f1 
\f0 organized, so as to allow inheritance and override within the hierarchy, as well as metadata object reuse between hierarchies. There was broad discussion in the WG on this topic.\'a0 There were requirements for being able to exchange core pieces of metadata (e.g., how to acquire content), but there was also a desire to create an extensible protocol.\'a0 Multiple drafts were submitted and merged to arrive at the final design.\'a0 In addition to the extensible structure of the metadata, much discussion and effort was put into making sure that transit CDNs, which may or may not understand how to enforce the metadata, are able to safely redistribute the metadata or are able to recognize when redistribution of the metadata may violate content delivery policies.
\f1 \

\f0 \'a0
\f1 \

\f0 The focus of the document is on providing metadata for delivering
\f1 
\f0 content via HTTP.\'a0 While the same metadata can be used to deliver content via HTTPS, there is no metadata defined for conveying metadata specific to setting up TLS connections between the dCDN and the end user.\'a0 It was discussed within the WG, but a secure solution was not deemed within the expertise of the WG.\'a0 Other solutions (e.g., LURK) could be used to address the TLS connection setup problem, and a CDNI metadata extension could be added once such a solution is available.
\f1 \

\f0 \'a0
\f1 \

\f0 The metadata interface provides the same TLS guidelines as the CDNI logging, redirection, and control triggers interfaces.\'a0 There has been much discussion on privacy, with respect to CDNI logging and redirection and this has been considered for the CDNI metadata interface.\'a0 It should be noted that the metadata interface provides information about the uCDN and CSP policies to the dCDN. Though the metadata may contain private information, none of the information is third party end user information.
\f1 \

\f0 \'a0
\f1 \

\f0 An early chair review was performed by Francois Le Faucheur, raising many editorial issues and requesting clarification on path matching, metadata override, and policy enforcement in cascaded CDN scenarios; all comments were addressed.\'a0 A subsequent independent review was performed by Vijay Gurbani, raising editorial comments, ambiguities, and requests for more details and more examples; all comments were addressed.\'a0 A final chair review was provided by Francois Le Faucheur, raising editorial and consistency issues; all comments were addressed.\'a0 Two additional independent reviews were performed by Linda Dunbar and Jan Seedorf, raising editorial comments which were all addressed.\'a0 An AppsDir early review was performed by Matt Miller, raising JSON issues, the need for more examples, and editorial issues; all comments were addressed. An early AD review was conducted by Alex Melnikov, raising a number of comments around security, proper use of RFC2119 terminology, references and autodiscovery; most comments have been addressed and the remaining ones have been discussed and are to be addressed in an upcoming version.
\f1 \

\f0 \'a0
\f1 \

\f0 3. Intellectual Property
\f1 \

\f0 \'a0
\f1 \

\f0 Each author has confirmed conformance with BCP 78/79.
\f1 \
\

\f0 There were no IPR disclosure made against this document.
\f1 \

\f0 \'a0
\f1 \

\f0 4. Other Points
\f1 \

\f0 \'a0
\f1 \

\f0 There is a downward reference for RFC5861, which is not in the DownrefRegistry.
\f1 \

\f0 \'a0
\f1 \

\f0 There is a downward reference for RFC6707, which is not (yet) in the DownrefRegistry. RFC6707 is identified as a Normative Reference because its terminology is reused in this document.
\f1 \

\f0 \'a0
\f1 \

\f0 The IANA Considerations registers 20 new CDNI Payload Types, one for each of the GenericMetadata objects defined in the document. Both of the designated expert reviewers for the CDNI Payload Types
\f1 
\f0 registry are authors of this document and have approved the additions.
\f1 \

\f0 \'a0
\f1 \

\f0 The IANA Considerations creates a new "CDNI Metadata Footprint Types" registry with sufficient guidelines provided to both IANA and the designated expert reviewer.\'a0 The registry defines footprint types used by both the Metadata LocationACL, as well as the footprints defined in the Footprint and Capabilities Semantics document (already approved by the IESG).
\f1 \

\f0 \'a0
\f1 \

\f0 The IANA Considerations creates a new "CDNI Metadata Protocols"
\f1 
\f0 registry with sufficient guidelines provided to both IANA and the designated expert reviewer.\'a0 The registry defines delivery and acquisition protocols used by both the Metadata ProtocolACL, as well as the DeliveryProtocol and AcquisitionProtocol capabilities defined in the Footprint and Capabilities Semantics document (already approved by the IESG).
\f1 \

\f0 \'a0
\f1 \

\f0 The IANA Considerations creates a new "CDNI Metadata Auth Types" registry with sufficient guidelines provided to both IANA and the designated expert reviewer.\'a0 The registry is initially empty.\'a0 The initial Auth type is being defined in the URI Signing document which is preparing for WGLC.
\f1 \
}

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: alexey.melnikov@isode.com, flefauch@cisco.com, cdni@ietf.org, draft-ietf-cdni-metadata@ietf.org, cdni-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (CDN Interconnection Metadata) to Proposed Standard


The IESG has received a request from the Content Delivery Networks
Interconnection WG (cdni) to consider the following document:
- 'CDN Interconnection Metadata'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-06-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The Content Delivery Networks Interconnection (CDNI) metadata
  interface enables interconnected Content Delivery Networks (CDNs) to
  exchange content distribution metadata in order to enable content
  acquisition and delivery.  The CDNI metadata associated with a piece
  of content provides a downstream CDN with sufficient information for
  the downstream CDN to service content requests on behalf of an
  upstream CDN.  This document describes both a base set of CDNI
  metadata and the protocol for exchanging that metadata.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata/ballot/


No IPR declarations have been submitted directly on this I-D.

Most of my issues from AD review were fixed in -18. Here are the remaining 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).