Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection
draft-ietf-cdni-redirection-20

My AD review:

RTMP needs an informative reference.

In 4.2: can you clarify syntax of cdn-path? A forward reference to section 4.8 would suffice.

In 4.4.1: is there a suitable reference for allowed qtype values? I.e. are you expecting anything other than "a" or "aaaa" here?

In 6.2: the IANA registration policy is "Specification Required", yet the "specification" field is optional. Are you envisioning that some values would be fully defined in the "description" field?

A-Label needs a normative reference (on first mention).

[Ballot comment]

Thanks for handling my discuss point. I didn't check the comments
below but am happy to chat about them if needed.

----- OLD COMMENTS BELOW


- I support Alissa's discuss points.

- section 3: false-negative? don't you mean false-positive?
And in any case, those warnings are not false from the browser
perspective. I'd suggest s/false-negative//

- section 3: phrases like "trusted re-direction" are a bad
idea - you need to say who is trusting whom for what for this
to be meaningful and not misleading (people get misled by such
phrases all the time). I'd just delete the sentence or
s/trusted//

- 4.4.2: a JSON "string" is not the same as a DNS name is it?
What about i18n? (ULABEL or ALABEL?) what about odd characters
allowed in JSON but not in DNS names?  In general the fields
in this dictionary (and others) seem underspecified to me.

[Ballot comment]
Thanks for explaining the parts I didn't get and addressing the rest of my DISCUSS.

I do still think the CGN example in 5.2 is not clear as written -- probably needs further explanation or removal as Ben suggested.

[Ballot discuss]

The basic idea of the uCDN sending everything to the dCDN so
that the dCDN can reply with all the details of a request
that'll work (i.e. the sc-* stuff) seems broken as it requires
that the uCDN expose all security and privacy sensitive data
to the dCDN in pretty much all cases. I fail to see why that
is an acceptable approach. Can you point me at where the WG
disucssed the issues with that approach and considered less
security/privacy unfriendly potential alternatives? 

Some examples:
- section 4.1 says "SHOULD convey as much information as
possible" that is surely wrong - there is no reason to
encourage sending cookies and other security/privacy sensitive
information and in fact sending such should be discouraged
(SHOULD NOT) or even, if possible, prohibited (MUST NOT). 
- The cs-(cookie) in 4.5.1 is one specific case of sending too
much. 
- 4.4.1 Resolver IP addr is liable to be that of an end user's
machine (if they operate a recursive).

But the examples are just that, I'd like to DISCUSS the WG's
consideration of the overall design first before we dive into
those.

[Ballot comment]

- I support Alissa's discuss points.

- section 3: false-negative? don't you mean false-positive?
And in any case, those warnings are not false from the browser
perspective. I'd suggest s/false-negative//

- section 3: phrases like "trusted re-direction" are a bad
idea - you need to say who is trusting whom for what for this
to be meaningful and not misleading (people get misled by such
phrases all the time). I'd just delete the sentence or
s/trusted//

- 4.4.2: a JSON "string" is not the same as a DNS name is it?
What about i18n? (ULABEL or ALABEL?) what about odd characters
allowed in JSON but not in DNS names?  In general the fields
in this dictionary (and others) seem underspecified to me.

[Ballot discuss]
(1)
There is some ambiguity in the document about whether the uCDN passes the IP address of the UA or its prefix to the dCDN. Sec 4.4.1 says that for DNS redirection, the uCDN passes "IP address or prefix" of the UA, but then in the definition of resolver-ip specifies it only as the IP address of the UA. Then in Sec 4.5.1 for HTTP redirection the equivalent field is specified as the IP address of the UA and the possibility of sending only a prefix is not mentioned. Then 5.2 has the para that begins "While it is technically possible to mask some information in the RI Request, such as the last bits of the UA IP address ..." which makes it seem like prefixes really shouldn't be sent.

I think the document needs some consistency and clarity here about whether prefixes are expected to be used for either redirection method. It's also not obvious to me why the document shouldn't recommend to uCDNs that if they are polling multiple candidate dCDNs as described in Sec 5.2, they should use only a prefix for such requests. The arguments given against this seem pretty thin -- isn't preventing correlation of multiple requests to a single UA a good thing, especially when it's being done by a bunch of dCDNs? And I don't understand the CGN example -- isn't the root of the problem here that topologically dispersed UAs are sharing the same public-facing IP address, in which case the dCDN may have the same problem when passed a full IP address as it does a prefix?

(2)
Ben noted the weakness of the recommendation in 5.1 regarding TLS. I see that the language here is the same as it is in draft-ietf-cdni-logging-22. But I thought the agreement on that document was MUST use TLS, full stop. So there is ambiguity in both documents I think. "In an environment where ..." and "When TLS is used ..." seem inconsistent with "TLS MUST be used ...." I'm happy to clear on this if I'm missing something from the previous discussion, which I think happened when I was on leave and resulted from one of Stephen's ballots.

[Ballot comment]
I have a few comments and questions:

# Substantive: #

- 3, last paragraph: "Any operational
  mechanisms this requires, e.g., private key distribution to
  surrogates and request routers in dCDNs, are outside the scope of
  this document.  Further mechanisms to notify User Agents of trusted
  redirection are also outside the scope of this document."

Is it in scope _somewhere_? As it is, this seems like an excuse to avoid HTTPS, which is not optimal.

-4, first paragraph:
Was any thought given to using or supporting HTTP/2?

-- step 1 after figure 1:
I am I correct to infer an assumption that CDN A acts as the UAs DNS server? Is that assumption documented somewhere?

- 4.2, last paragraph (note)
This explicitly makes an IPv6 only CDN non-compliant. Is that the intent?

- 4.4.1, table, entry for dns-only:
The description says "MUST include RTs". That doesn't seem to consider error cases.

- 4.8, 3rd and 4th paragraph:
I'm curious why they SHOULDs are not MUSTs. Are there times it might be reasonable to do something different; maybe even choosing not to send an error at all? I wonder if these should be of the form of "MUST send an error which SHOULD be XXX"

-5.1, 2nd to last paragraph:
" In an environment where any such protection is required...," is a pretty weak recommendation. Would you consider making the default behavior secure? Or at least saying something to the effect of "Except in networks where similar protections are provided by some other means,..."?

-5.2, First paragraph:
I have trouble imagining situations where information passed over the RI might not be sensitive.
-- third paragraph:
I wish the text wasn't so dismissive of attempts to anonymize some RI request data. I agree doing so may reduce RI effectiveness in some cases. But that needs to be balanced with privacy needs, and that balance may not always land on the side of RI effectiveness. And  the inability to correlate UAs between requests can be a feature in some circumstances.

# Editorial: #

- General:
There's quite a bit of repetition and redundant text, including redundant normative text.

- abstract:
s/"The Request Routing Interface..."/ "The Content Delivery Network Interface (CDNI) Request Routing Interface..."
s/"comprises of"/"comprises"

- 4, 2nd paragraph: "The same HTTP interface is used for both DNS and HTTP redirection of
User Agent requests,..."
From the rest of the sentence, I assume this means the RI uses the same interface to communicate information about DNS and HTTP redirects—but the first part sounds like it is saying that the actual redirection (i.e. interacting with the UA) occurs over the same interface.

-- 4th paragraph:
s/"try and"/"try to"

- 4.1, 2nd to last paragraph: "... signaled the HTTP response body
      of the RI response ..."
Missing word? (perhaps "... signaled in the HTTP response body ..."

-4.2, paragraph 4:
This paragraph is redundant to section 4.8.

-4.5.1, last paragraph before example: "For example, it MAY only
  send the contents of the first occurrence of the HTTP Headers
  instead."
s/MAY/might.

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

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

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the CDNI Payload Type Parameter registry, located at:

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

two new payload types are to be registered as follows:

Payload type: redirection-request
Reference: [ RFC-to-be ]

Payload type: redirection-response
Reference: [ RFC-to-be ]

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.

Second, also in the CDNI Payload Type Parameter registry, located at:

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

a new subregistry is to be created called the CDNI RI Error response code subregistry. The registry will be managed using Specification Required as defined in RFC 5226.

There are initial registrations in this new subregistry as follows:

+------+--------------+---------------------------------------------+---------------+
| Code | Reason | Description | Reference |
+------+--------------+---------------------------------------------+---------------+
| 100 |  | Generic informational error-code meant for | [ RFC-to-be ] |
| | (see | carrying a human-readable string | |
| | Description) | | |
| 400 |  | Generic error-code for uCDN errors where | [ RFC-to-be ] |
| | (see | the dCDN can not or will not process the | |
| | Description) | request due to something that is perceived | |
| | | to be a uCDN error. The reason field may be | |
| | | used to provide more details about the | |
| | | source of the error. | |
| 500 |  | Generic error-code for dCDN errors where | [ RFC-to-be ] |
| | (see | the dCDN is aware that it has erred or is | |
| | Description) | incapable of satisfying the RI request for | |
| | | some reason. The reason field may be used | |
| | | to provide more details about the source of | |
| | | the error. | |
| 501 | Unable to | The dCDN is unable to retrieve the metadata | [ RFC-to-be ] |
| | retrieve | associated with the content requested by | |
| | metadata | the UA. This may indicate a configuration | |
| | | error or the content requested by the UA | |
| | | not existing. | |
| 502 | Loop | The dCDN detected a redirection loop (see | [ RFC-to-be ] |
| | detected | Section 4.8). | |
| 503 | Maximum hops | The dCDN detected the maximum number of | [ RFC-to-be ] |
| | exceeded | redirection hops exceeding max-hops (see | |
| | | Section 4.8). | |
| 504 | Out of | The dCDN does not currently have sufficient | [ RFC-to-be ] |
| | capacity | capacity to handle the UA request. | |
| 505 | Delivery | The dCDN does not support the (set of) | [ RFC-to-be ] |
| | protocol not | delivery protocols indicated in the CDNI | |
| | supported | Metadata of the content requested content | |
| | | by the UA. | |
| 506 | Redirection | The dCDN does not support the requested | [ RFC-to-be ] |
| | protocol not | redirection protocol. This error-code is | |
| | supported | also used when the RI request has the dns- | |
| | | only flag set to True and the dCDN is not | |
| | | support or is not prepared to return a RT | |
| | | of a surrogate directly. | |
+------+--------------+---------------------------------------------+---------------+

IANA understands that these are the only actions 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,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: "Kevin J. Ma" , cdni-chairs@ietf.org, draft-ietf-cdni-redirection@ietf.org, kevin.j.ma@ericsson.com, barryleiba@gmail.com, cdni@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Request Routing Redirection interface for CDN Interconnection) to Proposed Standard


The IESG has received a request from the Content Delivery Networks
Interconnection WG (cdni) to consider the following document:
- 'Request Routing Redirection interface for CDN Interconnection'
  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-03-16. 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 Request Routing Interface comprises of (1) the asynchronous
  advertisement of footprint and capabilities by a downstream Content
  Delivery Network (CDN) that allows an upstream CDN to decide whether
  to redirect particular user requests to that downstream CDN; and (2)
  the synchronous operation of an upstream CDN requesting whether a
  downstream CDN is prepared to accept a user request and of a
  downstream CDN responding with how to actually redirect the user
  request.  This document describes an interface for the latter part,
  i.e., the CDNI Request Routing Redirection interface.

This Standards Track document has a normative reference to the
Informational RFC 6707, "Content Distribution Network Interconnection
(CDNI) Problem Statement", which is used to define terminology.


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

When IESG discussion begins, it can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection/ballot/

The following IPR Declarations may be related to this I-D:
  https://datatracker.ietf.org/ipr/2657/

1. Summary

  The document shepherd is Kevin J. Ma.  The responsible AD is Barry Leiba.

  This document is a standards track submission that defines a
  protocol by which an upstream CDN (uCDN) may query a downstream CDN
  (dCDN), in a CDN Interconnection (CDNI), as to whether the dCDN
  will accept a client redirected from the uCDN, and if so, to where in the
  dCDN the client should be redirected.  It is necessary for the recursive
  redirection mode of CDNI.  The WG believes that a standardized
  method/protocol for determining if a dCDN is able and willing to
  serve content for the uCDN is needed and will be useful.

2. Review and Consensus

  The protocol is a straightforward RESTful API with JSON payloads
  that contain key/value pairs, for extensibility.  Currently known
  parameters needed for DNS and HTTP redirection are defined.  CDNI
  supports two types of redirection: iterative redirection and
  recursive redirection.  This document specifically addresses
  recursive redirection.  Because iterative redirection is simpler
  and more widely used today, the WG's focus was primarily on
  iterative redirection; consequently, there was less discussion on
  recursive redirection, but a smaller group of individuals within
  the WG agreed that the parameters defined would be necessary and
  useful.

  Independent reviews were performed by Kevin J. Ma and Bert
  Greevenbosch citing editorial and consistency issues; all comments
  were addressed.  A WG Chair review was performed by Francois Le
  Faucheur citing editorial changes; all comments were addressed.  An
  appsdir early review was performed by Matt Miller, specifically
  looking at the JSON encoding; all comments/nits were addressed.  As
  document shepherd, I performed a final review focusing on IANA
  considerations and normative references, as well as citing
  editorial and consistency issues; all comments were addressed.

  A security concern was raised and discussed by the WG.  The
  protocol supports DNS redirection because CDNs use DNS redirection
  today.  Without DNSSEC, however, a client may not be able to
  distinguish legitimate DNS redirection from a DNS-based attack.
  The WG agreed that the concern should be documented (which it has
  been), but that the existing functionality should move forward with
  the understanding that DNSSEC is not a reasonable requirement for
  all DNS redirection.  The security aspects are being pursued in a
  separate draft.

3. Intellectual Property

  Each author has confirmed conformance with BCP 78/79.

  There was one IPR disclosure from Juniper Networks.  The disclosure
  was announced on the list with only one response on the list
  stating that the RAND terms seemed reasonable.  The disclosure was
  also discussed in the WG meeting at IETF94.  The chairs agreed that
  the RAND terms seemed reasonable and that there was no reason to
  hold up the document.  There were no objections from the WG.

4. Other Points

  There are no downward references in the document.

  The IANA Considerations registers two new CDNI Protocol Types.  The
  document shepherd and one of the editors are the two designated
  expert reviewers for the CDNI Protocol Types registry and have
  approved the addition.

  The IANA Considerations also creates a new registry for error codes
  for the protocol with sufficient guidelines provided to both IANA
  and the designated expert reviewer.